ОИБ. основы информ. безопасности. Учебное пособие Томск
 Скачать 1.99 Mb.
|
|
Класс В2. Структурированная защита. Выполняются все требования класса защиты В1. Кроме того, в системах класса В2 ТСВ основывается на четко определенной и хорошо документированной формальной модели политики безопасности, требующей, чтобы мандатная и дискреционная системы разграничения доступа были распространены на все субъекты и объекты компьютерной системы. ТСВ должна быть четко структурирована на элементы, критичные с точки зрения безопасности и некритичные. Интерфейс ТСВ должен быть хорошо определен и ее проект и конечный результат должны быть подвергнуты полной проверке и тестированию. Механизм аудита должен быть усилен, введен контроль за конфигурацией; системы. Система должна быть устойчива к внешнему проникновению. Политика безопасности. В дополнение к В1, помечаться должны все ресурсы системы прямо или косвенно доступные субъектам. Надежная вычислительная база должна немедленно извещать терминального пользователя об изменении его метки безопасности. Пользователь может запросить информацию о своей метке. Надежная вычислительная база должна поддерживать присваивание всем подключенным физическим устройствам минимального и максимального уровня секретности. Эти уровни должны использоваться при проведении в жизнь ограничений, налагаемых физической конфигурацией системы (например, расположением устройств). Все ресурсы системы (в том числе ПЗУ, устройства ввода/вывода) должны иметь метки безопасности и служить объектами принудительного управления доступом. Подотчетность. Надежная вычислительная база должна поддерживать надежный коммуникационный путь к себе для пользователя, выполняющего операции начальной идентификации и аутентификации. Инициатива в общении по этому пути должна исходить исключительно от пользователя. В дополнение к В1, должна быть возможность регистрировать события, связанные с организацией тайных каналов с памятью. Гарантии. В дополнение к В1, надежная вычислительная база должна быть внутренне структурирована на хорошо определенные, относительно независимые модули. Надежная вычислительная база должна эффективно использовать имеющееся оборудование для отделения элементов, критически важных с точки зрения защиты, от прочих компонентов системы. Модули базы должны проектироваться с учетом принципа минимизации привилегий. Для защиты логически раздельных хранимых объектов должны использоваться аппаратные средства, такие как сегментация. Должен быть полностью определен пользовательский интерфейс к надежной вычислительной базе и все элементы базы. Системный архитектор должен тщательно проанализировать возможности по организации тайных каналов с памятью и оценить максимальную пропускную способность каждого выявленного канала. Система должна поддерживать разделение функций оператора и администратора. В дополнение к В1, должна быть продемонстрирована относительная устойчивость надежной вычислительной базы к попыткам проникновения. Модель политики безопасности должна быть формальной. Для надежной вычислительной базы должны существовать описательные спецификации верхнего уровня, точно и полно определяющие ее интерфейс. В процессе разработки и сопровождения надежной вычислительной базы должна использоваться система конфигурационного управления, обеспечивающая контроль за изменениями в описательных спецификациях верхнего уровня, иных архитектурных данных, реализационной документации, исходных текстах, работающей версии объектного кода, тестовых данных и документации. Конфигурационное управление должно обеспечивать соответствие друг другу всех аспектов текущей версии надежной вычислительной базы. 97 Должны предоставляться средства генерации новых версий базы по исходным текстам и средства для сравнения версий, чтобы убедиться в том, что произведены только запланированные изменения. Документация. В дополнение к В1, должны быть указаны модули надежной вычислительной базы, содержащие механизмы проверки обращений. Должна быть описана процедура безопасной генерации новой версии базы после внесения изменений в исходные тексты. В дополнение к С1, тесты должны подтверждать действенность мер по уменьшению пропускной способности тайных каналов передачи информации. Модель политики безопасности должна быть формальной и доказательной. Должно быть показано, что описательные спецификации верхнего уровня точно отражают интерфейс надежной вычислительной базы. Должно быть показано, как база реализует концепцию монитора обращений, почему она устойчива к попыткам отслеживания ее работы, почему ее нельзя обойти и почему она реализована корректно, Должна быть описана структура базы, чтобы облегчить ее тестирование и проверку соблюдения принципа минимизации привилегий. Документация должна содержать результаты анализа тайных каналов передачи информации и описание мер протоколирования, помогающих выявлять каналы с памятью. Класс ВЗ. Домены безопасности. В системах класса ВЗ ТСВ должна удовлетворять всем требованиям предыдущего класса и дополнительно требованиям монитора ссылок, который должен быть: защищен от несанкционированного изменения или порчи; обрабатывать все обращения; прост для анализа и тестирования. ТСВ должна быть структурирована таким образом, чтобы исключить код, не имеющий отношения к безопасности системы. Дополнительно должно быть обеспечено: поддержка администратора безопасности; расширение механизма аудита с целью сигнализации о любых событиях, связанных с безопасностью; поддержка процедуры восстановления системы. Политика безопасности. В дополнение к С2, должны обязательно использоваться списки управления доступом с указанием разрешенных режимов. Должна быть возможность явного указания пользователей или их групп, доступ которых к объекту запрещен. Подотчетность. В дополнение к В2, надежный коммуникационный путь может формироваться по запросу, исходящему как от пользователя, так и от самой базы. Надежный путь может использоваться для начальной идентификации и аутентификации, для изменения текущей метки безопасности пользователя и т.п. Общение по надежному пути должно быть логически отделено и изолировано от других информационных потоков. Должна быть возможность регистрации появления или накопления событий, несущих угрозу политике безопасности системы. Администратор безопасности должен немедленно извещаться о попытках нарушения политики безопасности. А система, в случае продолжения попыток, должна пресекать их наименее болезненным способом. Гарантии. В дополнение к В2, надежная вычислительная база должна быть спроектирована и структурирована таким образом, чтобы использовать полный и концептуально простой защитный механизм с точно определенной семантикой. Этот механизм должен играть центральную роль во внутренней структуризации надежной вычислительной базы и всей системы. База должна активно использовать разделение по 98 уровням, абстракцию и инкапсуляцию данных. Значительные инженерные усилия должны быть направлены на уменьшение сложности надежной вычислительной базы и на вынесение из нее модулей, не являющихся критически важными с точки зрения защиты. Должна быть специфицирована роль администратора безопасности. Получить права администратора безопасности можно только после выполнения явных, протоколируемых действий. Не относящиеся к защите действия администратора безопасности должны быть по возможности ограничены. Должны существовать процедуры и/или механизмы, позволяющие произвести восстановление после сбоя или иного нарушения работы без ослабления защиты. Должна быть продемонстрирована устойчивость надежной вычислительной базы к попыткам проникновения. Не должно быть выявлено архитектурных недостатков. Допускается выявление лишь небольшого числа исправимых недостатков реализации. Должна существовать обоснованная уверенность, что немногие недостатки остались невыявленными. Документация. Руководство администратора по средствам безопасности в дополнение к В2, должна быть описана процедура, обеспечивающая безопасность начального запуска системы и возобновления ее работы после сбоя. Должно быть неформально продемонстрировано соответствие между описательными спецификациями верхнего уровня и реализацией надежной вычислительной базы. Группа А. Верифицированная защита Данная группа характеризуется применением формальных методов верификации, корректности работы механизмов управления доступом (дискреционного и мандатного). Требуется, чтобы было формально показано соответствие архитектуры и реализации ТСВ требованиям безопасности. Класс А1. Формальная верификация. Критерий защиты класса А1 не определяет дополнительные по сравнению с классом ВЗ требования к архитектуре или политике безопасности компьютерной системы. Дополнительным свойством систем, отнесенных к классу А1, является проведенный анализ ТСВ на соответствие формальным высокоуровневым спецификациям и использование технологий проверки с целью получения высоких гарантий того, что ТСВ функционирует корректно. Наиболее важные требования к классу А1 можно объединить в пять групп. 1. Формальная модель политики безопасности должна быть четко определена и документирована, должно быть дано математическое доказательство того, что модель соответствует своим аксиомам и что их достаточно для поддержания заданной политики безопасности. 2. Формальная высокоуровневая спецификация должна включать абстрактное определение выполняемых ТСВ функций и аппаратный и (или) встроенный программный механизм для обеспечения разделения доменов. 3. Формальная высокоуровневая спецификация ТСВ должна демонстрировать соответствие модели политики безопасности с использованием, где это возможно, формальной технологии (например, где имеются проверочные средства) и неформальной во всех остальных случаях. 4. Должно быть неформально показано и обратное - соответствие элементов ТСВ формальной высокоуровневой спецификации. Формальная высокоуровневая спецификация должна представлять собой универсальный механизм защиты, реализующий политику безопасности. Элементы этого механизма должны быть отображены на элементы ТСВ. 5. Должны быть использованы формальные технологии для выявления и анализа скрытых каналов. Неформальная технология может быть использована для анализа скрытых временных каналов. Существование оставшихся в системе скрытых каналов должно быть оправдано. 99 Более строгие требования предъявляются к управлению конфигурацией системы и конкретному месту дислокации (развертывания) системы Перечисленные требования не затрагивают группы Политика безопасности и Подотчетность и сконцентрированы в группе Гарантии с соответствующим описанием в группе Документация. 5.2. Концепции защиты автоматизированных систем и средств вычислительной техники по руководящим документам Гостехкомиссии РФ В 1992 г. Гостехкомиссия (ГТК) при Президенте Российской Федерации разработала и опубликовала пять руководящих документов [9], посвященных вопросам защиты информации в автоматизированных системах (АС) ее обработки. Основой этих документов является концепция защиты средств вычислительной техники (СВТ) и АС от несанкционированного доступа к информации, содержащая систему взглядов ГТК на проблему информационной безопасности и основные принципы защиты компьютерных систем. С точки зрения разработчиков данных документов, основная задача средств безопасности - это обеспечение защиты от несанкционированного доступа к информации. Определенный уклон в сторону поддержания секретности информации объясняется тем, что данные документы были разработаны в расчете на применение в информационных системах силовых структур РФ. Структура требований безопасности Руководящие документы ГТК состоят из пяти частей. 1. Защита от несанкционированного доступа к информации. Термины и определения. 2. Концепция защиты СВТ и АС от НСД к информации. 3. Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации. 4. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации. 5. Временное положение по организации разработки, изготовления и эксплуатации программных и технических средств защиты информации от НСД в автоматизированных системах и средствах вычислительной техники. Наибольший интерес представляют вторая, третья и четвертая части. Во второй части излагается система взглядов, основных принципов, которые закладываются в основу проблемы защиты информации от НСД. Руководящие документы ГТК предлагают две группы требований к безопасности - показатели защищенности СВТ от НСД и критерии защищенности АС обработки данных. Первая группа позволяет оценить степень защищенности отдельно поставляемых потребителю компонентов АС и рассматривается в четвертой части, а вторая рассчитана на более сложные комплексы, включающие несколько единиц СВТ, и представлена в третьей части руководящих документов. Классы защищенности АС В третьей части руководящих документов ГТК дается классификация АС и требований по защите информации в АС различных классов. При этом определяются: 1. Основные этапы классификации АС: разработка и анализ исходных данных; выявление основных признаков АС, необходимых для классификация сравнение выявленных признаков АС с классифицируемыми; 100 присвоение АС соответствующего класса защиты информации от НСД. 2. Необходимые исходные данные для классификации конкретной АС: перечень защищаемых информационных ресурсов АС и их уровень конфиденциальности; перечень лиц, имеющих доступ к штатным средствам АС с указанием их уровня полномочий; матрица доступа или полномочий субъектов доступа по отношению к защищаемым информационным ресурсам АС; режим обработки данных в АС. 3. Признаки, по которым производится группировка АС в различные классы: наличие в АС информации различного уровня конфиденциальности;| уровень полномочий субъектов доступа АС на доступ к конфиденциальной информации; режим обработки данных в АС: коллективный или индивидуальный. Документы ГТК устанавливают девять классов защищенности АС от НСД, распределенных по трем группам. Каждый класс характеризуется определенной совокупностью требований к средствам защиты. В пределах каждой группы соблюдается иерархия классов защищенности АС. Класс, соответствующий высшей степени защищенности для данной группы, обозначается индексом NA, где N- номер группы (от 1 до 3). Следующий класс обозначается NБ и т.д. Третья группа включает АС, в которых работает один пользователь, допущенный ко всей информации АС, размещенной на носителях одного уровня конфиденциальности. Группа содержит два класса - ЗБ и ЗА. Вторая группа включает АС, в которых пользователи имеют одинаковые полномочия доступа ко всей информации, обрабатываемой и хранимой в АС на носителях различного уровня конфиденциальности. Группа содержит два класса -2Б и 2А. Первая группа включает многопользовательские АС, в которых одновременно обрабатывается и хранится информация разных уровней конфиденциальности. Не все пользователи имеют равные права доступа.. Группа содержит пять классов - 1Д, 1 Г, 1 В, 1Б и 1А. В табл. 5.2 приведены требования к подсистемам защиты для каждого класса защищенности. На разработку этих документов наибольшее влияние оказал критерий TCSEC ("Оранжевая книга"), однако это влияние в основном отражается в ориентированности этих документов на защищенные системы силовых структур и в использовании единой универсальной шкалы оценки степени защищенности. К недостаткам руководящих документов ГТК относятся: ориентация на противодействие НСД и отсутствие требований к адекватности реализации политики безопасности. Понятие "политика безопасности" трактуется исключительно как поддержание режима секретности и отсутствие НСД. Из-за этого средства защиты ориентируются только на противодействие внешним угрозам, а к структуре самой системы и ее функционированию не предъявляется четких требований. Ранжирование требований по классам защищенности по сравнению с остальными стандартами информационной безопасности максимально упрощено и сведено до определения наличия или отсутствия заданного набора механизмов защиты, что существенно снижает гибкость требований и возможность их практического применения. Несмотря на указанные недостатки, документы ГТК заполнили "правовой вакуум" в области стандартов информационной безопасности в России и оперативно решили проблему проектирования и оценки качества защищенных АС. 101 5.3. Критерии оценки безопасности информационных технологий (Common Criteria) Основные понятия «Критериев оценки безопасности информационных технологий» [10] (издан 1 декабря 1999 года) - самый полный и современный среди оценочных стандартов. Этот международный стандарт стал итогом почти десятилетней работы специалистов нескольких стран, он вобрал в себя опыт существовавших к тому времени документов национального и межнационального масштаба. По историческим причинам данный стандарт часто называют «Общими критериями» (или даже ОК). Мы также будем использовать это сокращение. «Общие критерии» на самом деле являются метастандартом, определяющим инструменты оценки безопасности информационной системы (ИС) и порядок их использования. В отличие от «Оранжевой книги», ОК не содержат предопределенных «классов безопасности». Такие классы можно строить, исходя из требований безопасности, существующих для конкретной организации и/или конкретной информационной системы. С программистской точки зрения ОК можно считать набором библиотек, помогающих писать содержательные «программы» – задания по безопасности, типовые профили защиты и т.п. Программисты знают, насколько хорошая библиотека упрощает разработку программ, повышает их качество. Без библиотек, «с нуля», программы не пишут уже очень давно; оценка безопасности тоже вышла на сопоставимый уровень сложности, и «Общие критерии» предоставили соответствующий инструментарий. Как и «Оранжевая книга», ОК содержат два основных вида требований безопасности: функциональные, соответствующие активному аспекту защиты, предъявляемые к функциям безопасности и реализующим их механизмам; требования доверия, соответствующие пассивному аспекту, предъявляемые к технологии и процессу разработки и эксплуатации. Требования безопасности предъявляются, а их выполнение проверяется для определенного объекта оценки – аппаратно-программного продукта или информационной системы. Очень важно, что безопасность в ОК рассматривается не статично, а в привязке к жизненному циклу объекта оценки. Выделяются следующие этапы: определение назначения, условий применения, целей и требований безопасности; проектирование и разработка; испытания, оценка и сертификация; внедрение и эксплуатация. В ОК объект оценки рассматривается в контексте среды безопасности, которая характеризуется определенными условиями и угрозами. В свою очередь, угрозы характеризуются следующими параметрами: источник угрозы; метод воздействия; уязвимые места, которые могут быть использованы; ресурсы (активы), которые могут пострадать. Уязвимые места могут возникать из-за недостатка в: требованиях безопасности; проектировании; эксплуатации. 102 Слабые места по возможности следует устранить, минимизировать или хотя бы постараться ограничить возможный ущерб от их преднамеренного использования или случайной активизации. Чтобы структурировать пространство требований, в «Общих критериях» введена иерархия класс – семейство – компонент - элемент. Классы определяют наиболее общую, «предметную» группировку требований (например, функциональные требования подотчетности). Семейства в пределах класса различаются по строгости и другим нюансам требований. Компонент – минимальный набор требований, фигурирующий как целое. Элемент – неделимое требование. Между компонентами ОК могут существовать зависимости. Они возникают, когда компонент сам по себе недостаточен для достижения цели безопасности. Но не все комбинации компонентов имеют смысл. Как указывалось выше, с помощью библиотек могут формироваться два вида нормативных документов: профиль защиты и задание по безопасности. Профиль защиты (ПЗ) представляет собой типовой набор требований, которым должны удовлетворять продукты и/или системы определенного класса (например, операционные системы на компьютерах в правительственных организациях). Задание по безопасности содержит совокупность требований к конкретной разработке, выполнение которых обеспечивает достижение поставленных целей безопасности. Выше мы отмечали, что в ОК нет готовых классов защиты. Сформировать классификацию в терминах «Общих критериев» – значит определить несколько иерархически упорядоченных (содержащих усиливающиеся требования) профилей защиты, в максимально возможной степени использующих стандартные функциональные требования и требования доверия безопасности. Выделение некоторого подмножества из всего множества профилей защиты во многом носит субъективный характер. По целому ряду соображений (одним из которых является желание придерживаться объектно-ориентированного подхода) целесообразно, на наш взгляд, сформировать сначала отправную точку классификации, выделив базовый (минимальный) ПЗ, а дополнительные требования компоновать в функциональные пакеты. Функциональный пакет – это неоднократно используемая совокупность компонентов, объединенных для достижения определенных целей безопасности. «Общие критерии» не регламентируют структуру пакетов, процедуры верификации, регистрации и т.п., отводя им роль технологического средства формирования ПЗ. Базовый профиль защиты должен включать требования к основным (обязательным в любом случае) возможностям. Производные профили получаются из базового путем добавления необходимых пакетов расширения, то есть подобно тому, как создаются производные классы в объектно-ориентированных языках программирования. |