5.2 Критерии оценки безопасности компьютерных систем министерства обороны сша ("оранжевая книга")

"Критерии оценки безопасности компьютерных систем" (Trusted Computer System Evaluation Criteria -TCSEC) [8], получившие неформальное, но прочно закрепившееся название "Оранжевая книга", были разработаны и опубликованы Министерством обороны США в 1983 г. с целью определения требований безопасности, предъявляемых к аппаратному, программному и специальному программному и информационному обеспечению компьютерных систем, и выработки методологии и технологии анализа степени поддержки политики безопасности в компьютерных системах в основном военного назначения.

В данном документе были впервые формально (хотя и не вполне строго) определены такие понятия, как "политика безопасности", "корректность" и др. Согласно "Оранжевой книге" безопасная компьютерная система – это система, поддерживающая управление доступом к обрабатываемой в ней информации так, что только соответствующим образом авторизованные пользователи или процессы (субъекты), действующие от их имени, получают возможность читать, записывать, создавать и удалять информацию. Предложенные в этом документе концепции защиты и набор функциональных требований послужили основой для формирования всех появившихся впоследствии стандартов безопасности.

Общая структура требований TCSEC

В "Оранжевой книге" предложены три категории требований безопасности: политика безопасности, аудит и корректность, в рамках которых Сформулированы шесть базовых требований безопасности. Первые четыре требования направлены непосредственно на обеспечение безопасности информации, а два последних – на качество средств защиты. Рассмотрим эти требования подробнее.

Политика безопасности

Требование 1. Политика безопасности. Система должна поддерживать точно определенную политику безопасности. Возможность доступа субъектов к объектам должна определяться на основании их идентификации и набора правил управления доступом. Там, где это необходимо, 157

должна использоваться политика мандатного управления доступом, позволяющая эффективно реализовать разграничение доступа к информации различного уровня конфиденциальности.

Требование 2. Метки. С объектами должны быть ассоциированы метки безопасности, используемые в качестве исходной информации для процедур контроля доступа. Для реализации мандатного управления доступом система должна обеспечивать возможность присваивать каждому объекту метку или набор атрибутов, определяющих степень конфиденциальности (гриф секретности) объекта и режимы доступа к этому объекту.

Подотчетность

Требование 3. Идентификация и аутентификация. Все субъекты должны иметь уникальные идентификаторы. Контроль доступа должен осуществляться на основании результатов идентификации субъекта и объекта доступа, подтверждения подлинности их идентификаторов (аутентификации) и правил разграничения доступа. Данные, используемые для идентификации и аутентификации, должны быть защищены от несанкционированного доступа, модификации и уничтожения и должны быть ассоциированы со всеми активными компонентами компьютерной системы, функционирование которых критично с точки зрения безопасности.

Требование 4. Регистрация и учет. Для определения степени ответственности пользователей за действия в системе, все происходящие в ней события, имеющие значение с точки зрения безопасности, должны отслеживаться и регистрироваться в защищенном протоколе (т.е. должен существовать объект компьютерной системы, потоки от которого и к которому доступны только субъекту администрирования). Система регистрации должна осуществлять анализ общего потока событий и выделять из него только те события, которые оказывают влияние на безопасность для сокращения объема протокола и повышения эффективности его анализа. Протокол событий должен быть надежно защищен от несанкционированного доступа, модификации и уничтожения.

Гарантии (корректность)

Требование 5. Контроль корректности функционирования средств защиты. Средства защиты должны содержать независимые аппаратные и/или программные компоненты, обеспечивающие работоспособность функций защиты. Это означает, что все средства защиты, обеспечивающие политику безопасности, управление атрибутами и метками безопасности, идентификацию и аутентификацию, регистрацию и учет, должны находиться под контролем средств, проверяющих корректность их функционирования. Основной принцип контроля корректности состоит в том, что средства контроля должны быть полностью независимы от средств

защиты.

Требование 6. Непрерывность защиты. Все средства защиты (в том числе и реализующие данное требование) должны быть защищены от несанкционированного вмешательства и/или отключения, причем эта защита должна быть постоянной и непрерывной в любом режиме функционирования системы защиты и компьютерной системы в целом. Данное 158

требование распространяется на весь жизненный цикл компьютерной системы. Кроме того, его выполнение является одной из ключевых аксиом, используемых для формального доказательства безопасности системы.

Классы защищенности компьютерных систем по TCSEC

"Оранжевая книга" предусматривает четыре группы критериев, которые соответствуют различной степени защищенности: от минимальной (группа D) до формально доказанной (группа А). Каждая группа включает один или несколько классов. Группы D и А содержат по одному классу (классы D и А соответственно), группа С-классы С1, С2, а группа В три класса -В1, В2, В3, характеризующиеся различными наборами требований защищенности. Уровень защищенности возрастает от группы D ik группе А, а внутри группы-с увеличением номера класса. Усиление требований осуществляется с постепенным смещением акцентов от положений, определяющих наличие в системе каких-то определенных механизмов защиты, к положениям обеспечивающих высокий уровень гарантий того, что система функционирует в соответствии требованиям политики безопасности (табл. 5.3). Например, по реализованным механизмам защиты классы В3 и А1 идентичны.

Таблица 5.3

Базовые требования "Оранжевой книги"	Классы защиты
	C1	C2	B1	B2	B3	A1
Политика безопасности
1. Дискреционная политика безопасности	+	+	+	=	=	=
2. Мандатная политика безопасности	–	–	+	+	=	=
3. Метки секретности	–	–	+	+	=	=
4. Целостность меток	–	–	+	=	=	=
5. Рабочие метки	–	–	–	+	=	=
6. Повторение меток	–	–	+	=	=	=
7. Освобождение ресурсов при повторном использований объектов	–	+	=	+	=	=
8. Изолирование модулей	–	+	=	=	=	=
9. Пометка устройств ввода/вывода	–	–	+	=	=	=
10. Пометка читаемого вывода	–	–	+	=	=	=
Подотчетность
11. Идентификация и аутентификация	+	+	=	=	=	=
12. Аудит	–	+	+	+	+	=
13. Защищенный канал (доверенный путь)	–	–	–	+	=	=

Окончание табл. 5.3

Базовые требования "Оранжевой книги"	Классы защиты
	C1		C2		B1	B2	B3		A1
Гарантии
14. Проектная спецификация и верификация		-		-	+	+		+		+
15. Системная архитектура		+		=	=	+		+		=
16. Целостность системы		+		=	=	=		=		=
17.Тестирование системы безопасности		+		+	+	+		+		=
18. Доверенное восстановление после сбоев		-		-	-	-		+		=
19.Управление конфигурацией системы		-		-	-	+		+		+
20. Доверенное дооснащение системы		-		-	-	+		+		=
21. Доверенное распространение		-		-	-	-		+		=
22. Анализ скрытых каналов		-		-	-	+		+		+
Документация
23. Руководство пользователя		+		=	=	=		=		=
24. Руководство по конфигурированию системы защиты		+		+	+	+		+		=
25. Документация по тестированию		+		=	=	=		=		+
26. Проектная документация		+		=	+	+		=		+
Примечания: "–" – нет требований к данному классу; "+" – новые или дополнительные требования; "=" – требования совпадают с требованиями к СВТ предыдущего класса.

Рассмотрим основные требования классов защищенности по указанным выше четырем категориям:

• политика безопасности;

• подотчетность;

• гарантии;

• документация.

Центральным объектом исследования и оценки по TCSEC является доверительная база вычислений (ТСВ).

Группа D. Минимальная защита

Класс D. Минимальная защита. Класс D зарезервирован для тех систем, которые были представлены на сертификацию (оценку), но по какой-либо причине ее не прошли. 160

Группа С. Дискреционная защита

Группа С характеризуется наличием доступом и аудитом действий субъектов.

дискреционного управления

Класс С1. Системы на основе дискреционного разграничения доступа. ТСВ систем, соответствующих этому классу защиты, удовлетворяет неким минимальным требованиям безопасного разделения пользователей и данных. Она определяет некоторые формы разграничения доступа на индивидуальной основе, т.е. пользователь должен иметь возможность защитить свою информацию от ее случайного чтения или уничтожения. Пользователи могут обрабатывать данные как по отдельности, так и от имени группы пользователей.

Политика безопасности. ТСВ должна определять и управлять доступом между поименованными объектами и субъектами (пользователями или их группами) в компьютерной системе (например, при помощи матрицы доступа). Механизм защиты должен позволять пользователям определять и контролировать распределение доступа к объектам по поименованным пользователям, их группам или по тем и другим.

Подотчетность. Пользователи должны идентифицировать себя перед ТСВ в случае выполнения ими любых действий, ею контролируемых, при этом должен быть использован хотя бы один из механизмов аутентификации (например, пароль). Данные аутентификации должны быть защищены от доступа неавторизованного пользователя.

Гарантии. ТСВ обеспечивает ее собственную работу и защиту от внешнего воздействия. Ресурсы системы, контролируемые ТСВ, являются подмножеством множества всех ресурсов. Должны быть предоставлены АО и ПО для периодической проверки правильности работы ТСВ. Тестирование ТСВ должно выполняться согласно документации для обеспечения гарантии того, что нет явных путей обхода системы защиты неавторизованным пользователем или иного расстройства системы защиты.

Документация должна включать:

• описание реализованных в ТСВ механизмов защиты, их взаимодействия и руководство пользователя по их использованию;

• руководство для администратора системы на гарантирование системы защиты;

• документацию по тестам, включающую описание того, как механизмы безопасности должны тестироваться и как интерпретировать результаты тестов;

• документацию по проекту, описывающую философию системы защиты и того, как эта философия реализована в ТСВ (если ТСВ состоит из нескольких модулей, то должен быть описан интерфейс между ними).

Класс С1 рассчитан на многопользовательские системы, в которых осуществляется совместная обработка данных одного уровня конфиденциальности.

Класс С2 Системы, построенные на основе управляемого дискреционного разграничения доступа.

161

Системы, сертифицированные по данному классу, должны удовлетворять всем требованиям, изложенным в классе С1. Однако, системы класса С2 поддерживают более тонкую, чем в классе С1, политику дискреционного разграничения доступа, делающую пользователя индивидуально ответственным за свои действия после процедуры аутентификации в системе, а также аудит событий, связанных с безопасностью системы.

Политика безопасности. ТСВ должна осуществлять контроль за распространением прав доступа. Механизм дискреционного контроля доступа должен при каждом действии пользователя или его отсутствии обеспечивать защиту объектов от неавторизованного воздействия. При этом должен определяться доступ для каждого отдельного пользователя. Наделять пользователей правом доступа к объекту могут только авторизованные для этого пользователи. Никакая информация (в том числе шифрованная) о предшествующих действиях субъекта не может быть получена субъектом, получившим после первого доступ к системе. Реализация этого требования обеспечивает очищение ресурсов после освобождения их процессами системы.

Подотчетность. ТСВ должна обеспечивать индивидуальную ответственность пользователей за осуществляемые ими действия, обеспечивая возможность ассоциировать пользователя с любым событием аудита. При этом должен поддерживаться и защищаться журнал аудита, доступ к нему разрешаться только тем, кто специально для этого авторизован. Аудиту подлежит следующий стандартный набор событий, среди которых:

• идентификация и аутентификация пользователя;

• размещение объектов в адресном пространстве процессов пользователей (например, чтение информации из файлов);

• уничтожение объектов;

• действия, осуществляемые администраторами системы.

При этом запись журнала аудита должна снабжаться необходимым набором атрибутов:

• дата и время события;

• идентификатор пользователя, инициировавшего событие;

• тип события (например, вход в систему, получение доступа к файлу на чтение и т.д.);

• результат: успех или неуспех выполнения события.

Если требуется, надо указывать дополнительные сведения, например имя объекта, к которому происходит обращение. Для удобства изучения данных журнала аудита должны быть предусмотрены средства фильтрации записей по заданным признакам.

Гарантии. ТСВ должна изолировать подлежащие защите ресурсы так, чтобы выполнялись требования контроля доступа и аудита.

Тестирование должно включать поиск и просмотр очевидных брешей системы защиты, позволяющих нарушить изолированность ресурсов или допустить неавторизованный доступ к данным аутентификации или журнала аудита.

Документация должна дополнительно (по сравнению с классом С1) включать описание событий, заносимых в журнал аудита. 162

Группа В. Мандатное управление доступом

Основные требования этой группы – мандатное (полномочное) управление доступом с использованием меток безопасности, реализация некоторой формальной модели политики безопасности, а также наличие спецификаций на функции ТСВ. В системах этой группы постепенно к классу ВЗ должен быть реализован монитор ссылок (или МБО в терминологии гл.4), который должен контролировать все доступы субъектов к объектам системы.

Класс В1. Системы класса В1 должны удовлетворять требованиям класса С2. Кроме того, должны быть выполнены следующие дополнительные требования.

Политика безопасности. ТСВ должна обеспечивать пометку каждого субъекта и объекта системы. Метки секретности должны представлять уровень доступа субъекта и уровень секретности объекта, которым они соответствуют. Именно эти метки должны служить основой для принятия решения ТСВ при запросе субъекта доступа к объекту. При передаче информации по каналам ввода/вывода ТСВ должна снабжаться соответствующими метками секретности. ТСВ должна также соответствующе маркировать метками секретности весь читаемый вывод. Доступ на чтение от субъекта к объекту может быть разрешен, только если уровень допуска субъекта не ниже уровня секретности объекта, а неиерархические категории первого включают все неиерархические категории второго Доступ на запись от субъекта к объекту, контролируемый ТСВ, может быть разрешен, только если уровень допуска субъекта не выше уровня секретности объекта, а все неиерархические категории первого входят в неиерархические категории второго.

Подотчетность. Аудиту подлежат любые изменения меток секретности читаемого вывода.

Гарантии. ТСВ должна обеспечивать изоляцию процессов системы, через выделение им соответствующего адресного пространства.

Целью тестирования является:

• Поиск всех каналов проникновения внешних субъектов с целью получения несанкционированного доступа к информации.

• Получение гарантии того, что никакой неавторизованный для этого специально пользователь не может ввести ТСВ в состояние, в котором она не способна отвечать на запросы других субъектов.

ТСВ должна быть построена на основе неформальной или формальной политики безопасности, которая должна поддерживаться на протяжении всего жизненного цикла системы.

Документация должна дополнительно включать:

• Для системного администратора описание функций, относящихся к безопасности ТСВ, а также описание путей и методов наилучшего использования защитных свойств системы; указание, как безопасно создать новую ТСВ; описания выполняемых процедур, предупреждений и привилегий, необходимых для контроля за безопасной работой системы.

• Описание формальной или неформальной политики безопасности, а

также то, как она реализована в системе.

163

Класс В2. Структурированная защита. Выполняются все требования класса защиты В1. Кроме того, в системах класса В2 ТСВ основывается на четко определенной и хорошо документированной формальной модели политики безопасности, требующей, чтобы мандатная и дискреционная системы разграничения доступа были распространены на все субъекты и объекты компьютерной системы. ТСВ должна быть четко структурирована на элементы, критичные с точки зрения безопасности и некритичные. Интерфейс ТСВ должен быть хорошо определен и ее проект и конечный результат должны быть подвергнуты полной проверке и тестированию. Механизм аудита должен быть усилен, введен контроль за конфигурацией системы. Система должна быть устойчива к внешнему проникновению.

Политика безопасности. ТСВ должна уведомлять каждого работающего в системе пользователя о любых изменениях его уровня секретности, а последний должен иметь возможность запрашивать у системы полную информацию о своей метке секретности. ТСВ должно поддерживать минимальные и максимальные метки секретности любого присоединенного физического устройства, которые должны определять непосредственное физическое окружение этого устройства.

Подотчетность. ТСВ должна обеспечить защищенный канал между собой и пользователем, осуществляющим вход в систему и аутентификацию. Инициатором осуществления соединения через такой защищенный канал может выступать только пользователь.

Гарантии. ТСВ должна быть внутренне структурирована на хорошо определенные, в большой степени независимые модули. Это достигается с помощью эффективного использования имеющегося в системе АО с целью разделения критичных и некритичных с точки зрения защиты модулей ТСВ. Все элементы ТСВ должны быть идентифицированы, а интерфейс между ними полностью определен. ТСВ должна обеспечить разделение функций оператора и администратора системы.

Разработчики системы должны полностью выявить скрытые каналы утечки и провести их инженерное обследование с целью измерения информационного потока для каждого канала. ТСВ должна быть рассмотрена по всем положениям, относящимся к ее устойчивости к проникновению. Тестирование ТСВ должно показать, что она функционирует согласно представленной в описании высокоуровневой спецификации

Формальная модель политики безопасности должна поддерживаться ТСВ на протяжении всего жизненного цикла компьютерной системы. Должна существовать служба управления конфигурацией системы и должны быть предоставлены средства для создания новых версий ТСВ.

Документация должна дополнительно включать:

• для системного администратора-описание того, как безопасно создать новую ТСВ;

• результаты проверки эффективности использованных методов по сокращению мощности скрытых каналов утечки информации.

Проектная документация должна включать описание интерфейса между модулями ТСВ. Должно быть представлено описание высокоуров-

164

невых спецификаций и того, что они точно соответствуют интерфейсу ^"ТСВ, описание концепции монитора ссылок и показано, почему он корректно выполняется и устойчив к модификации и блокировке. Документация должна представлять результаты анализа скрытых каналов и затрат, необходимых для их сокращения.

Класс ВЗ. Домены безопасности. В системах класса ВЗ ТСВ должна ' удовлетворять всем требованиям предыдущего класса и дополнительно требованиям монитора ссылок, который должен быть:

• защищен от несанкционированного изменения или порчи;

• обрабатывать все обращения;

• прост для анализа и тестирования.

ТСВ должна быть структурирована таким образом, чтобы исключить кор., не имеющий отношения к безопасности системы. Дополнительно должно быть обеспечено:

• поддержка администратора безопасности;

• расширение механизма аудита с целью сигнализации о любых собы-'' тиях, связанных с безопасностью;

• поддержка процедуры восстановления системы.

Политика безопасности. Не включает существенных дополнительных требований по сравнению с предыдущим классом защиты.

Подотчетность. Должно быть обеспечено создание защищенного канала для любого соединения пользователя с ТСВ (вход в систему, аутентификация, изменение секретных свойств объектов). Должен быть реализован механизм, осуществляющий анализ и накопление данных о событиях, имеющих отношения к безопасности и могущих послужить причиной нарушения политики безопасности. Этот механизм должен уведомлять администратора безопасности, когда превышается некоторый порог срабатывания. Если это событие или последовательность событий продолжается, то система должна предпринять наименее разрушительное действие для их блокирования.

Гарантии. ТСВ должна быть разработана и структурирована с использованием полного, концептуально-целостного механизма защиты с точно определенной семантикой. Сложность ТСВ должна быть минимизирована. Должен быть исключен код, не имеющий отношения к безопасности системы.

Функции, не связанные с управлением безопасностью и выполняемые пользователем, выступающим в роли администратора безопасности системы, должны быть ограничены набором только тех функций, которые делают более эффективным выполнение этой роли.

Должен быть обеспечен механизм восстановления при сбоях компьютерной системы без нарушения ее безопасности.

На этапе тестирования не должно быть найдено проектных брешей в системе защиты.

Должно быть четко показано, что высокоуровневая спецификация

ТСВ соответствует модели политики безопасности.

165

Документация дополнительно должна включать:

•для системного администратора-описание процедур, которые могут дать гарантию, что система начала свою работу безопасно;

•неформальное доказательство того, что все элементы ТСВ соответствуют высокоуровневой спецификации.

Группа А. Верифицированная защита

Данная группа характеризуется применением формальных методов верификации корректности работы механизмов управления доступом (дискреционного и мандатного). Требуется, чтобы было формально показано соответствие архитектуры и реализации ТСВ требованиям безопасности.

Класс А1. Формальная верификация. Критерий защиты класса А1 не определяет дополнительные по сравнению с классом ВЗ требования к архитектуре или политике безопасности компьютерной системы. Дополнительным свойством систем, отнесенных к классу А1, является проведенный анализ ТСВ на соответствие формальным высокоуровневым спецификациям и использование технологий проверки с целью получения высоких гарантий того, что ТСВ функционирует корректно.

Наиболее важные требования к классу А1 можно объединить в пять групп.

• Формальная модель политики безопасности должна быть четко определена и документирована, должно быть дано математическое доказательство того, что модель соответствует своим аксиомам и что их достаточно для поддержания заданной политики безопасности.

• Формальная высокоуровневая спецификация должна включать абстрактное определение выполняемых ТСВ функций и аппаратный и(или) встроенный программный механизм для обеспечения разделения доменов.

• Формальная высокоуровневая спецификация ТСВ должна демонстрировать соответствие модели политики безопасности с использованием, где это возможно, формальной технологии (например, где имеются проверочные средства) и неформальной во всех остальных случаях.

• Должно быть неформально показано и обратное - соответствие элементов ТСВ формальной высокоуровневой спецификации. Формальная высокоуровневая спецификация должна представлять собой универсальный механизм защиты, реализующий политику безопасности. Элементы этого механизма должны быть отображены на элементы ТСВ.

• Должны быть использованы формальные технологии для выявления и анализа скрытых каналов. Неформальная технология может быть использована для анализа скрытых временных каналов. Существование оставшихся в системе скрытых каналов должно быть оправдано.

Более строгие требования предъявляются к управлению конфигурацией системы и конкретному месту дислокации (развертывания) системы.

Перечисленные требования не затрагивают группы Политика безопасности и Подотчетность и сконцентрированы в группе Гарантии с соответствующим описанием в группе Документация.

Интерпретация и развитие TCSEC

Опубликование TCSEC стало важным этапом как в постановке основных теоретических проблем компьютерной безопасности, так и в указании направления их решения. Тем не менее, в ходе применения ее основных положений выяснилось, что часть практически важных вопросов осталась за рамками данного стандарта. Кроме того, с течением времени (с момента опубликования прошло пятнадцать лет) ряд положений устарел и потребовал пересмотра.

Круг специфических вопросов по обеспечению безопасности компьютерных сетей и систем управления базами данных нашел отражение в отдельных документах, изданных Национальным центром компьютерной безопасности США в виде дополнений к "Оранжевой книге":

• "Интерпретация TCSEC для компьютерных сетеГ;" (Trusted Network Interpretation [9]).

•"Интерпретация TCSEC для систем управления базами данных" (Trusted Database Management System Interpretation [10]).

Эти документы содержат трактовку основных положений "Оранжевой книги" применительно к соответствующим классам систем обработки информации.

Устаревание ряда положений TCSEC обусловлено прежде всего интенсивным развитием компьютерных технологий и переходом с вычислительных комплексов типа IBM-360/370 (советский аналог-машины серии ЕС) к рабочим станциям, высокопроизводительным персональным компьютерам и сетевой модели вычислений. Именно для того, чтобы исключить возникшую в связи с изменением аппаратной платформы некорректность некоторых положений "Оранжевой книги", адаптировать их к современным условиям и сделать адекватными нуждам разработчиков и пользователей программного обеспечения, и была проделана значительная работа по интерпретации и развитию положений этого стандарта. В результате возник целый ряд сопутствующих "Оранжевой книге" документов, многие из которых стали ее неотъемлемой частью. К наиболее часто упоминаемым относятся:

• "Руководство по произвольному управлению доступом в безопасных системах" (A guide to understanding discretionary access control in trusted systems [10]),

• "Руководство по управлению паролями" (Password management guideline[12]).

• "Руководство по применению "Критериев оезопасности компьютерных систем" в специфических средах" (Guidance for applying the Department Of Defence Trusted Computer System Evaluation Criteria in specific environment [13]).

• "Руководство по аудиту в безопасных системах" (A Guide to Understanding Audit in Trusted Systems) [14].

• "Руководство по управлению конфигурацией в безопасных системах"

(Guide to understanding configuration management in trusted systems

[15]).

Количество подобных вспомогательных документов, комментариев и интерпретаций значительно превысило объем первоначального документа, и в 1995 г. Национальным центром компьютерной безопасности США был опубликован документ под названием "Интерпретация критериев безопасности компьютерных систем"[16], объединяющий все дополнения и разъяснения. При его подготовке состав подлежащих рассмотрению и толкованию вопросов обсуждался на специальных конференциях разработчиков и пользователей защищенных систем обработки информации. В результате открытого обсуждения была создана база данных, включающая все спорные вопросы, которые затем в полном объеме были проработаны специально созданной рабочей группой. В итоге появился документ, проинтегрировавший все изменения и дополнения к TCSEC, сделанные с момента ее опубликования; что привело к обновлению стандарта и позволило применять его в современных условиях. ,

В заключение отметим, что критерии TCSEC Министерства обороны США представляют собой первую попытку создать единый стандарт безопасности, рассчитанный на проектировщиков, разработчиков, потребителей и специалистов по сертификации систем безопасности компьютерных систем. В свое время этот документ явился значительным шагом в области безопасности информационных технологий и послужил отправной точкой для многочисленных исследований и разработок. Основной отличительной чертой этого документа, как уже отмечалось, является его ориентация на системы военного применения, причем в основном на операционные системы. Это предопределило доминирование требований, направленных на обеспечение конфиденциальности обрабатываемой информации и исключение возможностей ее разглашения. Большое внимание уделено меткам конфиденциальности (грифам секретности) и правилам экспорта секретной информации.

Требования по гарантированию политики безопасности отражены достаточно поверхностно, соответствующий раздел по существу ограничивается требованиями контроля целостности средств защиты и поддержания их работоспособности, чего явно недостаточно.

Тем не менее "Оранжевая книга" послужила основой для разработчиков всех остальных стандартов информационной безопасности и до сих пор используется в США в качестве руководящего документа при сертификации компьютерных систем обработки информации. 168

5.3. ЕВРОПЕЙСКИЕ КРИТЕРИИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

Вслед за выходом критерия TCSEC страны Европы разработали согласованные "Критерии безопасности информационных технологий" (Information Technology Security Evaluation Criteria (ITSEC), далее "Европейские критерии"). Рассмотрим версию 1.2 данного документа, опубликованную в июне 1991 г. от имени соответствующих органов четырех стран: Франции, Германии, Нидерландов и Великобритании [17].

Основные понятия

"Европейские Критерии" рассматривают следующие задачи средств Ц, Информационной безопасности:

• защита информации от несанкционированного доступа с целью обеспечения конфиденциальности (поддержание конфиденциальности);

• обеспечение целостности информации посредством защиты от ее несанкционированной модификации или уничтожения (поддержание целостности);

• обеспечение работоспособности систем с помощью противодействия угрозам отказа в обслуживании (поддержание доступности).

Для того чтобы удовлетворить требованиям конфиденциальности, целостности и доступности, необходимо реализовать соответствующий набор функций безопасности, таких как идентификация и аутентификация, управление доступом, восстановление после сбоев и т.д. Чтобы средства защиты можно было признать эффективными, требуется высокая степень уверенности в правильности их выбора и надежности функционирования. Для решения этой проблемы в "Европейских критериях" впервые вводится |йонятие адекватности (assurance) средств защиты.

Адекватность включает в себя два аспекта: эффективность, отра-ающую соответствие средств безопасности решаемым задачам, и корректность, характеризующую процесс их разработки и функционирования. Эфективность определяется соответствием между задачами, поставными перед средствами безопасности, и реализованным набором функций защиты - их функциональной полнотой и согласованностью, простотой использования, а также возможными последствиями использования злоумышленниками слабых мест защиты. Под корректностью понимается правильность и надежность реализации функций безопасности (в инятой терминологии - гарантирование избранной политики безопасности).

Общая оценка уровня безопасности системы складывается из функциональной мощности средств защиты и уровня адекватности их реализации.

Основным объектом проверки и оценки, аналогом ТСВ в "Оранжевой книге", в "Европейских Критериях" является цель оценки (Target оf Evaluation -TOE).

1i

Пути реализации политики безопасности, предъявляемые требования к защитным механизмам зависят от того, является ли TOE в терминологии "Европейских Критериев" системой или продуктом. Это разделение систем аналогично используемому в Руководящих документах Гостехкомиссии делению компьютерных систем на АС и СВТ (см. § 5.1).

В случае системы фактическая среда, внутри которой будет использоваться TOE, известна. Могут быть определены цели защиты, угрозы

информации и меры им противодействия.

В случае продукта среда, внутри которой будет использоваться TOE, не известна разработчику, так как он может быть составным элементом различных систем. Вместо политики безопасности вводится обоснование рациональности продукта, где дается необходимая информация для предполагаемого покупателя чтобы он мог решить, будет ли продукт обеспечивать выполнение целей защиты системы.

Функциональные критерии

В ''Европейских критериях" средства, имеющие отношение к информационной безопасности, рассматриваются на трех уровнях детализации. На первом уровне рассматриваются цели, которые преследует обеспечение безопасности, второй уровень содержит спецификации функций защиты, а третий-реализующие их механизмы. Спецификации функций защиты предлагается рассматривать с точки зрения следующих требований

• идентификации и аутентификации;

• управления доступом;

• подотчетности;

• аудита;

• повторного использования объектов;

• целостности информации;

• надежности обслуживания;

• безопасности обмена данными.

Большинство из перечисленных требований совпадает с аналогичными требованиями "Оранжевой книги". Остановимся лишь на специфичных для "Европейских критериев".

Требования безопасности обмена данными регламентируют работу средств, обеспечивающих безопасность данных, передаваемых по каналам связи, и включают следующие разделы:

• аутентификация;

• управление доступом;

• конфиденциальность данных;

• целостность данных;

• невозможность отказаться от совершенных действий

Набор функций безопасности может специфицироваться с использованием ссылок на заранее определенные классы-шаблоны. В "Европейских критериях таких классов десять. Пять из них {F-C1, F-C2, F-B1, F-B2,170

F-B3) соответствуют классам безопасности "Оранжевой книги" с аналогичными обозначениями. Рассмотрим подробнее другие пять классов, так как их требования отражают точку зрения разработчиков стандарта на проблему безопасности.

Класс F-IN предназначен для систем с высокими потребностями в обеспечении целостности, что типично для систем управлания базами данных. Его описание основано на концепции "ролей", соответствующих видам деятельности пользователей, и предоставлении доступа к определенным объектам только посредством доверенных процессов. Должны различаться следующие виды доступа: чтение, запись, добавление, удаление, создание, переименование и выполнение объектов (имеется в виду порождение субъекта из соответствующего объекта-источника).

Класс F-AV характеризуется повышенными требованиями к обеспечению работоспособности. Это существенно, например, для систем управления технологическими процессами. В требованиях этого класса указывается, что система должна восстанавливаться после отказа отдельно го аппаратного компонента таким образом, чтобы все критически важные функции постоянно оставались доступными. В таком же режиме должна происходить и замена компонентов системы. Независимо от уровня загрузки должно гарантироваться определенное максимальное время реакции системы на внешние события.

Класс F-DI ориентирован на распределенные системы обработки информации. Перед началом обмена и при получении данных стороны должны иметь возможность провести идентификацию участников взаимодействия и проверить ее подлинность. Должны использоваться средства контроля и исправления ошибок. В частности, при пересылке данных должны обнаруживаться все случайные или намеренные искажения адресной и пользовательской информации. Знание алгоритма обнаружения искажений не должно позволять злоумышленнику производить нелегальную модификацию передаваемых данных. Должны обнаруживаться попытки повторной передачи ранее переданных сообщений.

Класс F-DC уделяет особое внимание требованиям к конфиденциальности передаваемой информации. Информация по каналам связи должна передаваться только в зашифрованном виде. Ключи шифрования должны быть защищены от несанкционированного доступа.

Класс F-DX предъявляет повышенные требования и к целостности, и к конфиденциальности информации. Его можно рассматривать как функциональное объединение классов F-DI и F-DC с дополнительными возможностями шифрования и защиты от анализа трафика. Должен быть ограничен доступ к ранее переданной информации.

Критерии адекватности

"Европейские критерии" уделяют значительно больше внимания адекватности средств защиты, чем функциональным требованиям. Адекватность складывается из двух компонентов - эффективности и корректности работы средств защиты.

171

"Европейские критерии" определяют семь уровней адекватности от ЕО до Е6 (в порядке возрастания). Уровень ЕО обозначает минимальную адекватность. При проверке адекватности анализируется весь жизненный цикл системы-от начальной фазы проектирования до эксплуатации и управления. Уровни адекватности от E1 до Е6 выстроены по нарастанию требований тщательности контроля. Так , на уровне Е1 анализируется лишь общая архитектура системы, а адекватность средств защиты подтверждается функциональным тестировагием. На уровнэ ЕЗ к анализу привлекаются исходные тексты программ и схемы аппаратного обеспечения. На уровне Е6 требуется формальное описание функций безопасности, общей архитектуры, а также политики безопасности.

Степень безопасности системы определяется самым слабым из критически важных механизмов защиты. В "Европейских критериях" определены три уровня бечопасности: базовый, средний, высокий. Безопасность считается базовой, если средства защиты способны противостоять отдельным случайным атакам (злоумышленник-физическое лицо). Безопасность считается средней, если средства защиты способны противостоять злоумышленникам, обладающим ограниченными ресурсами и возможностями (корпоративный злоумышленник). Наконец, безопасность можно считать высокой, если есть уверенность, что средства защиты могут быть преодолены только злоумышленником с высокой квалификацией, набор возможностей и ресурсов которого выходит за рамки возможного (злоумышленник-государственная спецслужба).

Таким образом, "Европейские критерии безопасности информационных технологий" появившиеся, вслед за "Оранжевой книгой" оказали существенное влияние на стандарты безопасности и методику сертификации. Главное достижение этого документа - введение понятия адекватности средств защиты и определение отдельной шкалы для критериев адекватности. Необходимо отметить, что "Европейские критерии" тесно связаны с "Оранжевой книгой", что делает их не вполне самостоятельным документом.

На первый взгляд, довольно странным представляется факт, что "Европейские критерии" признают возможность наличия недостатков в сертифицированных по некоторому классу защищенных системах (критерий возможности использования недостатков защиты), однако на самом деле данный подход свидетельствует о реалистичном взгляде на существующее положение дел.

5.4. ФЕДЕРАЛЬНЫЕ КРИТЕРИИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

"Федеральные критерии безопасности информационных технологий" (Federal Criteria for Information Technology Security) разрабатывались как одна из составляющих "Американского федерального стандарта по обра-172

ботке информации" (Federal information Processing Standard), призванного " заменить критерий TCSEC -"Оранжевую книгу". Разработчиками стандарта выступили Национальный институт стандартов и технологий США (National Institute Of Standards and Technology) и Агентство национальной безопасности США (National Security Agency). Данный обзор основан на версии 1.0 этого документа, опубликованной в декабре 1992 г. [18].

Этот документ разработан на основе результатов многочисленных исследований в области обеспечения безопасности информационных технологий 80-х-начала 90-х годов, а также на основе анализа опыта использования "Оранжевой книги". Документ представляет собой основу для разработки и сертификации компонентов информационных технологий с точки зрения обеспечения безопасности.

Основные положения

"Федеральные критерии безопасности информационных технологий" (далее "Федеральные критерии") охватывают практически полный спектр проблем, связанных с защитой и обеспечением безопасности, так как включают все аспекты обеспечения конфиденциальности, целостности и доступности.

Основными объектами применения требований безопасности "Федеральных критериев" являются продукты информационных технологий (Information Technology Products) и системы обработки информации (Information Technology Systems). Под продуктом информационных технологий (ПИТ) понимается совокупность аппаратных и программных средств, которая представляет собой поставляемое конечному потребителю готовое к использованию средство обработки информации. Как правило, ПИТ эксплуатируется не автономно, а интегрируется в систему обработки информации, представляющую собой совокупность ПИТ, объединенных в функционально полный комплекс, предназначенный для решения прикладных задач (т.е. для реализации некоторой целевой функции компьютерной системы). В ряде случаев система обработки информации может состоять только из одного ПИТ. обеспечивающего решение всех стоящих перед системой задач и удовлетворяющего требованиям безопасности.

С точки зрения безопасности принципиальное различие между ПИТ и системой обработки информации определяется средой их эксплуатации. Продукт информационных технологий обычно разрабатывается в расчете на то, что он будет использован во многих системах обработки информации, и, следовательно, разработчик должен ориентироваться только на самые общие предположения о среде эксплуатации своего продукта, включающие условия применения и общие угрозы. Напротив, система обработки информации разрабатывается для решения прикладных задач в расчете на требования конечных потребителей, что позволяет в полной мере учитывать специфику воздействий со стороны конкретной среды эксплуатации.

173

Положения "Федеральных критериев" касаются только собственных средств обеспечения безопасности ПИТ, т.е. механизмов защиты, встроенных непосредственно в эти продукты в виде соответствующих программных, аппаратных или специальных средств. Для повышения их эффективности могут дополнительно применяться внешние системы защиты и средства обеспечения безопасности, к которым относятся как технические средства, так и организационные меры, правовые и юридические нормы. В конечном счете, безопасность ПИТ определяется совокупностью собственных средств обеспечения безопасности и внешних средств, являющихся частью компьютерной системы.

Ключевым понятием концепции информационной безопасности "Федеральных критериев" является понятие "профиля защиты" (Protection Profile) Профиль защиты - это нормативный документ, который регламентирует все аспекты безопасности ПИТ в виде требований к его проектированию, технологии разработки и сертификации. Как правило, один профиль защиты описывает несколько близких по структуре и назначению ПИТ. Основное внимание в профиле защиты уделяется требованиям к составу средств защиты и качеству их реализации, а также их адекватности предполагаемым угрозам безопасности.

"Федеральные критерии" представляют процесс разработки систем обработки информации, начинающийся с формулирования требований потребителями и заканчивающийся введением в эксплуатацию, в виде следующих основных этапов:

1. Разработка и анализ профиля защиты. Требования, изложенные в профиле защиты, определяют функциональные возможности ПИТ по обеспечению безопасности и условия эксплуатации, при соблюдении которых гарантируется соответствие предъявляемым требованиям. Кроме требований безопасности профиль содержит требования по соблюдению технологической дисциплины в процессе разработки, тестирования, анализа и сертификации ПИТ. Профиль безопасности анализируется на полноту, непротиворечивость и техническую корректность.

2. Разработка и сертификация ПИТ. Разработанные ПИТ подвергаются независимому анализу, целью которого является определение степени соответствия характеристик продукта сформулированным в профиле защиты требованиям и спецификациям.

3. Компоновка и сертификация системы обработки информации в целом. Успешно прошедшие второй этап ПИТ интегрируются в систему обработки информации. Полученная в результате система должна удовлетворять заявленным в профиле защиты требованиям при соблюдении указанных в нем условий эксплуатации.

"Федеральные критерии" регламентируют только первый этап этой схемы - разработку и анализ профиля защиты, процесс создания ПИТ и компоновка систем обработки информации остаются вне рамок этого стандарта. 174

Профиль защиты

Как уже говорилось, профиль защиты является центральным понятием "Федеральных критериев", большая часть содержания которых представляет собой описание разделов профиля защиты, включающее набор требований безопасности и их ранжирование. Рассмотрим назначение, структуру и этапы разработки профиля защиты.

Профиль защиты предназначен для определения и обоснования состава и содержания средств защиты, спецификации технологии разработки и регламентации процесса сертификации ПИТ. Профиль защиты состоит из следующих пяти разделов:

• описание;

• обоснование;

• функциональные требования к ПИТ;

• требования к технологии разработки ПИТ;

• требования к процессу сертификации ПИТ.

Описание профиля содержит классификационную информацию, необходимую для его идентификации в специальной картотеке. "Федеральные критерии" предлагают поддерживать такую картотеку на общегосударственном уровне. Это позволит любой организации воспользоваться созданными ранее профилями защиты непосредственно или использовать их в качестве прототипов для разработки новых. В описании профиля защиты должна быть охарактеризована основная проблема или группа проблем обеспечения безопасности, решаемых с помощью применения данного профиля.

Обоснование содержит описание среды эксплуатации, предполагаемых угроз безопасности и методов использования ПИТ. Кроме того, этот раздел содержит подробный перечень задач по обеспечению безопасности, решаемых с помощью данного профиля. Эта информация дает возможность определить, в какой мере данный профиль защиты пригоден для применения в той или иной ситуации. Предполагается, что данный раздел ориентирован на службы безопасности организаций, которые изучают возможность использования ПИТ, соответствующего данному профилю защиты.

Раздел функциональных требований к ПИТ содержит описание функциональных возможностей средств защиты ПИТ и определяет условия, в которых обеспечивается безопасность в виде перечня угроз, которым успешно противостоят предложенные средства защиты. Угрозы, лежащие вне этого диапазона, должны быть устранены с помощью дополнительных, не входящих в состав продукта, средств обеспечения безопасности. Очевидно, что чем сильнее и опаснее угрозы, тем более мощными и стойкими должны быть средства, реализующие функции защиты.

Раздел требований к технологии разработки ПИТ охватывает все этапы его создания, начиная от разработки проекта и заканчивая вводом готовой системы в эксплуатацию. Раздел содержит требования как к самому процессу разработки, так и к условиям, в которых она проводится, к 175

используемым технологическим средствам, а также к документированию этого процесса. Выполнение требований этого раздела является непременным условием для проведения сертификации ПИТ.

Раздел требований к процессу сертификации ПИТ регламентирует порядок сертификации в виде типовой методики тестирования и анализа. Объем и глубина требуемых исследований зависят от наиболее вероятных типов угроз, среды применения и планируемой технологии эксплуатации.

"Федеральные критерии" содержат подробное описание всех трех разделов профиля защиты, включающее набор требований и их ранжирование для каждого раздела. В данном обзоре основное внимание уделено функциональным требованиям, так как этот вопрос проработан в "Федеральных критериях" значительно глубже, чем в предшествующих стандартах.

Разработка профиля защиты осуществляется в три этапа: анализ среды применения ПИТ с точки зрения безопасности, выбор профиля-прототипа и синтез требований.

На первом этапе проводится анализ информации о среде предполагаемого применения ПИТ, действующих в этой среде угрозах безопасности и используемых этими угрозами недостатках защиты. Анализ проводится с учетом технологии использования продукта, а также существующих стандартов и нормативов, регламентирующих его эксплуатацию.

Второй этап состоит в поиске профиля, который может быть использован в качестве прототипа. Как уже говорилось, "Федеральные критерии" предусматривают создание специальной, доступной для разработчиков ПИТ, картотеки, в которую должны быть помещены все разработанные когда-либо профили защиты. Это позволит минимизировать затраты на создание профилей и учесть опыт предыдущих разработок.

Этап синтеза требований включает выбор наиболее существенных для условий функционирования продукта функций защиты и их ранжирование по степени важности с точки зрения обеспечения качества защиты. Выбор специфичных для среды требований безопасности должен быть основан на их эффективности для решения задачи противодействия угрозам. Разработчик профиля должен показать, что выполнение выдвинутых требований ведет к обеспечению требуемого уровня безопасности посредством успешного противостояния заданному множеству угроз и устранения недостатков защиты.

При разработке профиля защиты необходимо анализировать связи и взаимозависимости, существующие между функциональными требованиями и требованиями к процессу разработки, а также между отдельными требованиями внутри этих разделов. По завершению разработки Профиль защиты подвергается проверке, целью которой является подтверждение его полноты, корректности, непротиворечивости и реализуемости.

Функциональные требования к продукту информационных технологий

"Федеральные критерии" предлагают набор функциональных требований, реализация которых позволяет противостоять наиболее распро-176

страненным угрозам безопасности, воздействующим на широкий спектр |ПИТ. Данные требования разработаны с учетом возможности расширения и адаптации к конкретным условиям эксплуатации ПИТ, и допускают совершенствование параллельно процессу развития информационных технологий. Требования, изложенные в "Федеральных критериях", разработаны на основе обобщения существовавших на момент их создания стандартов информационной безопасности -"Оранжевой книги" и "Европейских критериев" (см. выше §§ 5.1 и 5.2).

Функциональные требования, приведенные в "Федеральных критериях", определяют состав и функциональные возможности ТСВ. Она объединяет все компоненты ПИТ (аппаратные, программные и специальные средства), реализующие функции защиты. Таким образом, функциональные требования, направленные на обеспечение безопасности, относятся либо к внутренним элементам ТСВ, либо к ее внешним функциям, доступным через специальные интерфейсы. Для того чтобы расширить спектр енциального применения профиля защиты в "Федеральных критериях", описании функциональных требований предполагается, что ТСВ яв-тся единственной частью ПИТ, которая нуждается в защите и обладает такой характеристикой, как уровень защищенности. По этой причине полагается достаточным установить множество требований, касающихся только безопасности ТСВ. Функциональные требования профиля защиты задаются в виде общих положений и косвенным образом определяют множество угроз, которым может успешно противостоять удовлетворяюий этим положениям ПИТ.

Структура функциональных требований

Функциональные требования "Федеральных критериев" разделены на восемь классов и определяют все аспекты функционирования компьютерных систем. Реализация политики безопасности должна быть поддержана средствами, обеспечивающими надежность функционирования как самой ТСВ, так и механизмов осуществления политики безопасности. Эти средства также входят в состав ТСВ, хотя с точки зрения противодействия угрозам, вносят только косвенный вклад в общую защиту ПИТ.

Поскольку "Федеральные критерии" по сравнению с "Оранжевой книгой" являются стандартом нового поколения и, кроме того, никогда не рассматривались в отечественных публикациях, остановимся на функциональных требованиях более подробно.

1. Требования к реализации политики безопасности. Описывают функцииии компьютерной системы, реализующие политику безопасности, и состоят из четырех групп требований: к политике аудита, политике управления доступом, политике обеспечения работоспособности и управлению безопасностью. Эти требования носят весьма общий характер, что позволяет рассматривать их в качестве прототипа, обеспечивающего поддержку широкого спектра политик и моделей безопасности.-177

Политика аудита включает разделы, относящиеся к идентификации и аутентификации, регистрации пользователя в системе, обеспечению прямого взаимодействия с компьютерной системой, а также к регистрации и учету событий. Основная задача политики управления аудитом - обеспечить однозначную идентификацию субъекта, ответственного за те или иные действия в системе.

• Идентификация и аутентификация позволяют установить однозначное соответствие между пользователями и представляющими их в компьютерной системе субъектами (т.е. субъектами, инициированными от имени конкретного пользователя), а также подтвердить подлинность этого соответствия.

• Регистрация пользователя в системе означает создание субъекта взаимодействия, с идентификатором которого будут ассоциироваться все последующие действия пользователя. К процедуре регистрации также относится учет места, времени и других параметров подключения к системе и ее блокирование во время отсутствия пользователя.

• Обеспечение прямого взаимодействия с компьютерной системой гарантирует, что пользователь взаимодействует с компонентами системы напрямую, т.е. информация, которая передается в нее и обратно, не подвергается перехвату или искажению. Поддержка прямого взаимодействия с компьютерной системой особенно важна для управления безопасностью (например, при администрировании прав доступа и полномочий пользователей).

• Регистрация и учет событий в системе позволяют распознавать потенциально опасные ситуации и сигнализировать о случаях нарушения безопасности. Регистрация событий включает распознавание, учет и анализ действий пользователя, представляющих интерес с точки зрения безопасности.

Политика управления доступом содержит следующие разделы: произвольное управление доступом (дискреционное), нормативное управление доступом и контроль скрытых каналов утечки информации. Политика управления доступом является основным механизмом защиты, так как непосредственно обеспечивает конфиденциальность и целостность обрабатываемой информации.

• Произвольное управление доступом позволяет осуществлять назначение прав доступа с точностью до идентифицируемых субъектов и объектов, а также поддерживаемых типов доступа и, кроме того, обеспечивает контроль за распространением прав доступа среди субъектов.

• Нормативное управление доступом, в отличие от произвольного, основано на контроле информационных потоков между субъектами и объектами и их атрибутах безопасности, что позволяет регламентировать порядок использования информации в системе.

• Контроль скрытых каналов утечки информации включает технические и административные меры, направленные на ликвидацию таких каналов посредством минимизации объема совместно используемых ресурсов и введения активных "шумовых помех".-178

Политика обеспечения работоспособности системы включает контроль над распределением ресурсов и обеспечение отказоустойчивости. 0беспечение работоспособности позволяет гарантировать доступность ресурсов и сервиса системы, а также корректное восстановление системы после сбоев.

• Контроль над распределением ресурсов осуществляется посредством введения ограничений (квот) на их потребление или приоритетной системы распределения ресурсов.

• Обеспечение отказоустойчивости входит в сферу безопасности наравне с другими требованиями, так как противостоит угрозам работоспособности.

• Управление безопасностью регламентирует следующие аспекты нкционирования системы:

• компоновка, установка, конфигурация и поддержка компьютерной системы;

• администрирование атрибутов безопасности пользователей (идентификаторов, полномочий, доступных ресурсов и т.д.);

• администрирование политики управления доступом;

• управление потреблением ресурсов системы;

• аудит действий пользователей.

2. Мониторинг взаимодействий. Требования этого раздела регламентируют порядок взаимодействия между компонентами системы и прохождения информационных потоков через компьютерную систему. Реали-политики безопасности будет эффективна только в том случае, если без исключения взаимодействия в системе, т.е. доступ к объектам, сам и сервису, осуществляются при обязательном посредничестве ТСВ (следовательно, требуется, чтобы ядро защиты представляло собой МБО-см.гл.З).

3. Логическая защита ТСВ. Требования данной группы устанавливают порядок доступа к внутренним компонентам ТСВ (данным и программам). ТСВ должна быть защищена от внешних воздействий со стороны непривилегированных пользователей, в противном случае искажение программ и данных, находящихся в ТСВ, может привести к полному подавлению функций защиты (данное требование включает требование корректности внешних субъектов относительно субъектов ядра защиты и требование к интерфейсам взаимодействия - см. гл.З).

Необходимо подчеркнуть, что политика безопасности, мониторинг взаимодействий и логическая защита ТСВ являются обязательными компонентами всех профилей защиты вне зависимости от назначения и среды применения ПИТ.

4. Физическая защита ТСВ. Требования этой группы задают ограничения на физический доступ к компонентам ТСВ, а также допустимые физические параметры среды функционирования компьютерной системы.179

5. Самоконтроль ТСВ. Требования, касающиеся самоконтроля компьютерной системы, определяют возможности обеспечения контроля корректности выполнения функций системы и целостности программ и данных, входящих в систему. Выполнение этих требований позволяет вовремя обнаруживать нарушения целостности компонентов ТСВ, произошедшие в результате либо целенаправленного воздействия, либо сбоя в работе аппаратных или программных средств, и осуществлять восстановление целостности ТСВ.

6. Инициализация и восстановление ТСВ. Требования данной группы устанавливают возможности компьютерной системы по контролю за процессом собственной инициализации и способности к самовосстановлению после сбоев. Процесс восстановления после сбоя должен происходить без нарушений функционирования, даже временного, средств защиты. Восстановленное состояние ТСВ должно соответствовать требованиям политики безопасности, мониторинга взаимодействий и самоконтроля целостности.

7. Ограничение привилегий при работе с ТСВ. Требования этой группы устанавливают порядок назначения полномочий для работы с компьютерной системой. Основным принципом назначения таких полномочий является принцип минимальной достаточности. Это обеспечивается посредством постоянного контроля и при необходимости автоматического понижения привилегий пользователей при обращении к компонентам или сервису ТСВ. Соблюдение этого принципа позволяет минимизировать нарушения целостности в случае возникновения сбоев или нарушений безопасности.

8. Простота использования ТСВ. Выполнение этих требованиий обеспечивает удобство пользования возможностями ТСВ как для высококвалифицированных администраторов, ответственных за функционирование и безопасность системы, так и для рядовых пользователей, а также для разработчиков прикладных программ, взаимодействующих с системой. К этому классу требований относятся: порядок реагирования ТСВ на ошибки в действиях пользователей и попытки нарушения безопасности, устанавливаемые по умолчанию полномочия, интерфейс пользователей и администратора.

Объем и глубина реализации функциональных требований зависит от того, какую степень защищенности должно обеспечивать ядро защиты конкретного ПИТ, а также от того, какие угрозы безопасности возможны в среде его эксплуатации. Степень обеспечения требуемого уровня защищенности зависит от реализованной политики безопасности, от квалификации ответственного за безопасность персонала, от правильности администрирования системы и соблюдения рядовыми пользователями правил политики безопасности. 180

Ранжирование функциональных требований

Состав и содержание включенных в профиль защиты функциональных требований определяются средой эксплуатации ПИТ. Чтобы обосновать выбор тех или иных требований и не вступать в противоречие с существующими стандартами в области безопасности ПИТ, функциональные требования, приведенные в "Федеральных критериях", ранжируются по уровням с помощью следующих четырех критериев: широта сферы применения, степень детализации, функциональный состав средств защиты, обеспечиваемый уровень безопасности.

Широта сферы применения определяется множеством сущностей, к которому могут быть применены данные требования, а именно:

• пользователи системы, субъекты и объекты доступа;

• функции ТСВ и интерфейс взаимодействия с компьютерной системой;

• аппаратные, программные и специальные компоненты ТСВ;

• множество параметров конфигурации ТСВ.

Например, требования из разделов управления доступом, аудита, обеспечения работоспособности, мониторинга взаимодействий и простоты использования компьютерной системы, могут относиться только к определенному подмножеству объектов доступа и параметров конфигурации. Обеспечение прямого взаимодействия с компьютерной системой требуется только для некоторого подмножества функций ТСВ.

Степень детализации требований определяется множеством атрибутов сущностей, к которым применяются данные требования,-либо ко всем атрибутам пользователей, субъектов или объектов, либо только к некоторому подмножеству этих атрибутов. Например, требования из разделов управления доступом, аудита и мониторинга взаимодействий могут относиться только к некоторому подмножеству атрибутов субъектов и объектов - к правам доступа, групповым идентификаторам пользователей, но не к атрибутам состояния субъектов и объектов и не к индивидуальным идентификаторам.

Функциональный состав средств защиты определяется множеством функций, включенных в ТСВ для реализации той или иной группы функциональных требований. Например, политика управления доступом может включать либо произвольное, либо нормативное управление доступом, или и то, и другое одновременно.

Обеспечиваемый уровень безопасности определяется условиями, в которых функциональные компоненты компьютерной системы способны противостоять заданному множеству угроз, отказам и сбоям. Например, нормативное управление доступом обеспечивает более высокий уровень безопасности,чем произвольное.

Ранжирование всегда предполагает установление некоторого отношения порядка. Однако независимое ранжирование функциональных требований по каждому из описанных критериев, хотя и дает некоторое представление о различиях между функциональными возможностями средств защиты, но не позволяет установить четкую, линейную шкалу уровней 181

безопасности. Строгого отношения порядка, определенного на множестве функциональных требований, не существует, так как значение требований и уровень обеспечиваемой ими защиты зависят не только от их содержания, но и от назначения ПИТ и среды его эксплуатации. Для одних систем наиболее важными будут идентификация и аутентификация пользователей, а для других-реализация политики управления доступом или обеспечение доступности.

Таблица 5.4

Функциональное требование	Широта сферы применения	Степень детализации	Функциональный состав средств защиты	Обеспечиваемый уровень безопасности
Политика безопасности	*	*	*	*
Политика аудита	*	*	*	*
Идентификация и аутентификация			*
Регистрация в системе			*
Обеспечение прямого взаимодействия с компьютерной системой	«
Регистрация и учет событий
Политика управления доступом
Контроль скрытых каналов	*
Политика обеспечения работоспособности	*		*
Контроль над распределением ресурсов	*			*
Отказоустойчивость	*	*	*	*
Управление безопасностью				*
Мониторинг взаимодействий	*	*	*
Логическая защита компьютерной системы			*
Физическая защита компьютерной системы			*
Самоконтроль компьютерной системы	*		*
Инициализация и восстановление компьютерной системы			*
Ограничение привилегий при работе с компьютерной системой
Простота использования компьютерной системы	*		*

182

В связи с этим в "Федеральных критериях" отсутствуют рекомендации как по выбору и применению тех или иных функциональных требовали так и по определению их роли в системе обеспечения безопасности. Вместо жестких указаний этот документ содержит согласованный с предшествующими ему стандартами ("Оранжевая книга", "Европейские критерии") ранжированный перечень функциональных требований и предоставляет разработчикам профиля защиты возможность самостоятельно сделать выбор необходимых методов и средств обеспечения безопасности, основанный на назначении и специфике среды эксплуатации ПИТ.

Приводимое ранжирование не противоречит предшествующим стандартам и вводится для исключения ошибок в определении степени защищенности системы из-за неправильной оценки значимости отдельных групп требований. Кроме того, ранжирование предоставляет разработчикам и пользователям возможность для обоснованной оценки реально обеспечиваемого уровня безопасности.

Применение критериев ранжирования к различным группам функциональных требований представлено в табл. 5.4 Знак "*" указывает, на какие значимые свойства компьютерной системы (широта сферы применения, степень детализации и т.д.) влияет реализация того или иного защитного механизма.

Требования к процессу разработки продукта информационных технологий

Основное назначение требований к технологии разработки ПИТ-обеспечить адекватность условий разработки функциональным требованиям, выдвинутым в соответствующем разделе профиля защиты, и установить ответственность разработчика за корректность реализации этих требований. Данные требования регламентируют процесс создания, тестирования, документирования и сопровождения ПИТ и включают четыре группы требований; к процессу разработки, среде разработки, документированию и сопровождению.

Требования к процессу разработки содержат подразделы, относящиеся к проектированию, реализации, тестированию и анализу ПИТ. Особую роль играют требования адекватности реализации функций компьютерной системы, обеспечивающие корректность выполнения функциональных требований Профиля защиты.

Требования к среде разработки позволяют обеспечить качество процесса создания ПИТ с помощью применения современных технологий проектирования, программирования и тестирования, а также регламентируют управление процессом разработки и дистрибуцию конечного продукта.

Требования к документированию определяют состав и содержание технологической документации, позволяющей производителю ПИТ доказать соответствие самого продукта и технологии его изготовления выдвинутым требованиям.

Требования к сопровождению ПИТ содержат обязательства производителя перед пользователями, выполнение которых позволяет обеспечить эффективную и надежную эксплуатацию ПИТ. Данные требования регламентируют состав пользовательской и административной документации, процедуру обновления версий и исправления ошибок, а также инсталляцию продукта.183

"Федеральные критерии" содержат ранжированный перечень типовых требований к технологии разработки ПИТ [17]. Выполнение требований к технологии разработки является необходимым условием для проведения процедуры сертификации.

Требования к процессу сертификации продукта информационных технологий

Требования к процессу сертификации ПИТ призваны обеспечить соответствие процесса выдвинутым функциональным требованиями и требованиям к технологии разработки. В критериях описываются три группы требований, регламентирующих анализ, контроль и тестирование ПИТ.

Требования к анализу ПИТ содержат требования к проведению независимого анализа предложенного решения (архитектуры) и его реализации как конкретного средства.

Требования к контролю регламентируют проверку соответствия среды разработки ПИТ и обеспечиваемого производителем сопровождения требованиям к технологии разработки.

Требования к тестированию описывают процедуру тестирования функций компьютерной системы как самим разработчиком ПИТ, так и независимыми экспертами.

Рассмотренные требования регламентируют процесс сертификации только в общих чертах и, по замыслу разработчиков стандарта, должны послужить основой для разработки специализированных методик сертификации, ориентированных на различные области применения и классы ПИТ.

В заключение отметим, что "Федеральные критерии безопасности информационных технологий" являются первым стандартом в области безопасности систем обработки информации, в котором определены и рассмотрены три независимые группы требований: функциональные требования к средствам защиты, требования к технологии разработки и требования к процессу сертификации. Авторами этого документа предложена концепция профиля защиты-документа, содержащего полное описание всех требований безопасности; к процессу разработки, сертификации и эксплуатации ПИТ.

Функциональные требования к средствам защиты четко структурированы и описывают все аспекты функционирования компьютерной системы. Требования к технологии разработки, впервые появившиеся в этом документе, позволяют разработчикам использовать современные технологии программирования в качестве основы для подтверждения безопасности своего продукта. Требования к процессу сертификации носят довольно общий характер и не содержат конкретных методик тестирования и исследования ПИТ.

Разработчики "Федеральных критериев" отказались от используемого в "Оранжевой книге" подхода к оценке уровня безопасности ПИТ путем введения обобщенной универсальной шкалы классов безопасности. Вместо этого предлагается независимое ранжирование требований по каждой группе, т.е. вместо одной шкалы используется множество частных критериев, характеризующих обеспечиваемый уровень безопасности. Данный подход позволяет разработчикам и пользователям ПИТ выбрать наиболее 184

приемлемое решение и определить необходимый и в ряде случаев достаточный набор требований для каждого конкретного случая.

"Федеральные критерии безопасности информационных технологий" вместе с "Европейскими критериями безопасности информационных технологий" и "Канадскими критериями безопасности компьютерных систем" [19] послужили основой при создании "Единых критериев безопасности информационных технологий". Целью "Единых критериев" стала разработка на основе накопленного в разных странах опыта имеющихся стандартов, разрозненных документов и подходов единого согласованного стандарта, лишенного концептуальных и технических различий, имевшихся у его предшественников. Работа над проектом началась в 1993г., в конце 1996г. была опубликована первая версия документа, а в марте 1998 г.-вторая, доработанная и исправленная [20]. "Единые критерии" адресованы трем группам специалистов: потребителям, производителям и экспертам по классификации. Они представляют новый, межгосударственный уровень в стандартизации информационных технологий. Подробная информация о первой версии "Единых критериев" приведена в [2].

СПИСОК ЛИТЕРАТУРЫ К ГЛАВЕ 5

1 ГрушоА.А., ТимонинаЕ.Е. Теоретические основы защиты информации.-М.:

Изд-во агентства "Яхтсмен".-1996.

2 ЗегждаД.П., ИвашкоА.М. Как построить защищенную информационную систему? / Под ред. Д. П. Зегжды и В. В. Платонова. - СПб: Мир и семья, 1997.

3 Гостехкомиссия России. Руководящий документ. Концепция защиты средств

вычислительной техники от несанкционированного доступа к информации.-М.:

Военное издательство, 1992. 4. Гостехкомиссия России. Руководящий документ. Средства вычислительной

техники. Защита от несанкционированного доступа к информации. Показатели

защищенности от несанкционированного доступа к информации.-М.: Военное

издательство, 1992.

5 Гостехкомиссия России. Руководящий документ. Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации.-М.: Военное издательство, 1992.

6 Гостехкомиссия России. Руководящий документ. Временное положение по организации разработки, изготовления и эксплуатации программных и технических средств защиты информации от несанкционированного доступа в автоматизированных системах и средствах вычислительной техники.-М.: Военное издательство, 1992.

7 Гостехкомиссия России. Руководящий документ. Защита от несанкционированного доступа к информации. Термины и определения.-М.: Военное издательство, 1992.

8 Trusted Computer System Evaluation Criteria. US Department Of Defense. CSC-

STD-OOI-83, Aug. 1983.

9 Trusted Network Interpretation. National Computer Security Center. NCSC-TG-005 Version 1, July 1987.

10 Trusted Database Management System Interpretation. National Computer Security Center. NCSC-TG-021 Version 1, April 1991.

11 A guide to understanding discretionary access control in trusted systems. National Computer Security Center. NCSC-TG-003 Version 1, September 1987.

185

12. Password management guideline. US Department Of Defense. CSC-STD-002-85, April 1985.

13. Guidance for applying the Department Of Defense Trusted Computer System Evaluation Criteria in specific environment. US Department Of Defense. CSC-STD-003-85, June 1985.

14. A Guide to Understanding Audit in Trusted Systems. National Computer Security Center. NCSC-TG-001, July 1987.

15. Guide to understanding configuration management in trusted systems. National Computer Security Center. NCSC-TG-006-88, March 1988.

16. The Interpreted Trusted Computer System Evaluation Criteria Requirements. National Computer Security Center. NCSC-TG-007-95, Jan. 1995.

17. Information Technology Security Evaluation Criteria. Harmonized Criteria Of France-Germany-Netherlands-United Kingdom.- Department Of Trade and Industry. London, 1991.

18. Federal Criteria for Information Technology Security. National Institute of Standards and Technology & National Security Agency. Version 1.0, December 1992.

19. Canadian Trusted Computer Product Evaluation Criteria. Canadian System Security Center Communication Security Establishment, Government of Canada. Version З.Ое. January 1993.

20. Common Criteria for Information Technology Security Evaluation. Communication Security Establishment (Canada), Service Central de la Securite des Systemes d'lnformation (France), Bundesamt fur Sicherheit in der Informationstechnik (Germany), Netherlands National Communication Security Agency (Netherlands), Communication-Electronics Security Group (United Kingdom), National Institute of Standards and Technology (United States), National Security Agency (United States). Version 2.0. May 1998.

186

ЗАКЛЮЧЕНИЕ

В заключении рассмотрения теории компьютерной безопасности необходимо отметить, что на настоящий исторический момент это одна из г.амых развивающихся естественных наук. Постоянно появляются новые пеоспективные направления исследований, а уже имеющиеся получают еще более глубокую научную проработку.

К числу перспективных направлений следует отнести следующие.

• Формализация положений теории компьютерной безопасности.

• Разработка моделей безопасности, более точно отражающих существующий уровень развития компьютерной техники и информационных технологий и более удобных для практического использования и анализа защищенности реальных АС.

• Разработка средств и методов противодействия угрозам информационной войны.

• Вопросы обеспечения безопасности в глобальных информационных сетях, например Internet.

• Безопасность систем электронной коммерции.

• Вопросы безопасности обработки информации мобильными пользователями.

В то же время следует отметить, что содержание настоящего пособия отражает существующее состояние теории компьютерной безопасности и, не претендуя на ее полный охват, представляет комплексную, методологически обоснованную концепцию изложения положений теории. Описанные в данном пособии теоретические основы не несут в себе ответов на вопросы, как защищать конкретную систему. Вместе с тем, они включают общую методологию, позволяющую определить, какими защитными свойствами должна обладать проектируемая система, каким требованиям она должна отвечать, каким образом должна вестись ее разработка. Да, теоретические основы компьютерной безопасности ни в коей мере не могут подменить знания, например, об уязвимости конкретной операционной системы, но в то же время, как говорил Гельвеций, и эта фраза стала эпиграфом к настоящему пособию: "иногда знание общих законов способно заменить незнание конкретных фактов".

Особую роль в развитии теории компьютерной безопасности как науки и отрасли промышленности играют так называемые центры компьютерной безопасности. К ним относятся государственные, общественные и коммерческие организации, а также неформальные объединения, основное направление деятельности которых - координация усилий, направленных на актуализацию проблем защиты информации, проведение тес ретических исследований и разработка конкретных практических решений в области безопасности, аналитическая деятельность и прогнозирование.

В Российской Федерации известными центрами компьютерной безопасности являются кие учреждения, как Государственная Техническая 187

Комиссия при Президенте Российской Федерации (ГТК), Институт Криптографии, Связи и Информатики Академии федеральной службы безопасности (ИКСИ) и Академия криптографии Российской Федерации (АК РФ).

Зарубежные центры компьютерной безопасности широко представлены в сети Internet. По приоритетным для них направлениям деятельности такие центры подразделяются на:

• Информационно-аналитические. В основном, занимаются сбором и распространением информации по известным уязвимым местам АС, атакам и вторжениям, программным и аппаратным средствам профилактики и защиты. Публикуют регулярные информационные бюллетени и поддерживают электронные конференции, списки рассылки и Web-страницы, посвященные защите информации.

• Оперативного реагирования. Для этих центров ключевым аспектом деятельности является оказание практической помощи тем, кто испытал последствия нарушения защиты своих информационных систем или подвергся нарушению работоспособности системы в результате аварии или стихийного бедствия.

• Консультационные. Преимущественно занимаются оказанием консалтинговых услуг организациям, испытывающим трудности с выбором или внедрением программных, аппаратных или комплексных мер защиты, разработкой политики безопасности или использованием нормативно-правовой базы, регламентирующей вопросы их применения.

• Научно-исследовательские. Как правило, функционируют на базе факультетов крупных учебных заведений или подразделений государственных организаций и сосредоточены на изучении и совершенствовании теоретических основ информационной безопасности, исследовании и разработке моделей безопасных систем, синтезе и анализе защитных механизмов, совершенствовании законодательной базы.

• Центры сертификации. Реализуют программы тестирования, сравнения и сертификации средств защиты, а также разрабатывают подходы к сертификации и методики тестирования. Существуют государственные и независимые центры сертификации.

• Виртуальные библиотеки. Представляют собой электронные собрания научных статей, публикаций и материалов конференций, посвященных различным аспектам компьютерной безопасности.

Роль таких центров, российских и зарубежных, в развитии отдельных теоретических и практических областей компьютерной безопасности как отрасли промышленности и науки в целом выражена, в частности, в том, что они являются своего рода "инкубаторами" новых технологий и знаний, определяя перспективные направления дальнейшего движения научной мысли.

ОГЛАВЛЕНИЕ

Предисловие................................................................................ 3

Введение..................................................................................... 4

Глава 1 Структура теории компьютерной безопасности............................ 9

1.1. Основные понятия и определения............................................ 9

1.2. Анализ угроз информационной безопасности............................. 10

1.3. Структуризация методов обеспечения информационной безопасности..................................................................................... 1з

1.4. Основные методы реализации угроз информационной безопасности..................................................................................... -19

1.5. Основные принципы обеспечения информационной безопасности в АС................................................................................. 22

1.6. Причины, виды и каналы утечки информации............................. 24

Список литературы к главе 1........................................................ 26

Глава 2 Методология построения систем защиты информации в АС......... 27

2.1. Построение систем защиты от угрозы нарушения конфиденциальности информации............................................................. 27

2.2. Построение систем защиты от угрозы нарушения целостности информации...................... .................................................... 57

2.3 Построение систем защиты от угрозы отказа доступа к информации........................................................................................ 71

2.4. Построение систем защиты от угрозы раскрытия параметров информационной системы....................................................... 77

25. Методология построения защищенныхАС................................. 81

Список литературы к главе 2........................................................ 87

Глава 3 Политика безопасности................................................................ 89

3.1. Понятие политики безопасности................................................ 89

3.2. Понятия доступа и монитора безопасности................................. 90

3.3. Основные типы политики безопасности...................................... 96

24 Разработка и реализация политики безопасности........................ 98

3.5. Домены безопасности............................................................... 115

Список литературы к главе 3........................................................ 117

189

Глава 4 Модели безопасности.................................................................. 118

4.1. Модель матрицы доступов HRU................................................ 118

4.2. Модель распространения прав доступа Take-Grant..................... 123

4.3. Модель системы безопасности Белла-Лападула......................... 134

4.4. Модель безопасности информационных потоков........................ 144

Список литературы к главе 4........................................................ 148