4. Критерии аудита.

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

4.1 Регистрация и учет событий в системе

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

Уровень WA-0. Недостаточная регистрация и учет событий в системе.

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

Уровень WA-I. Регистрация и учет событий в системе.

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

^

Требования Канадских критериев

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

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

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

Сопряженные уровни: WI-1.

Уровень YVA-2. Регистрация и учет событий в системе и защита журнала

аудита.

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

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

Сопряженные уровни: IS-1.WI-1.

Уровень WA-3. Регистрация и учет событий в системе, защита журнала ау- дита и оповещение администратора.

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

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

Уровень WA-4. Детальная регистрация и учет событий в системе.

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

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

Сопряженные уровни: IS-1.W1-1.

Уровень WA-5. Выявление вторжений.

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

Сопряженные уровни: 1S-1,VVI-1.

4.2 Идентификация и аутентификация

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

Приложение 2

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

Уровень WI-0. Недостаточная идентификация и аутентификация.

Зарезервирован для систем с примитивными возможностями идентифика-

:;:;п :: :\\ юшпфикнши. не >.:юнлсторяющнх требованиям более высоких уровнен

Уровень WI-I. Внешняя идепшфнкация и аутентификация.

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

Каждый пользователь должен иметь уникальный идентификатор.

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

Уровень WI-2. Индивидуальная идентификация и аутентификация.

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

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

Уровень WI-3. Множественная идентификация и аутентификация.

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

4.3 Прямое взаимодействие с ТСВ

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

Уровень WT-0. Недостаточное прямое взаимодействие с ТСВ. Зарезервирован для систем с примитивными возможностями прямою взаимодействия с ТСВ, не удовлетворяющих требованиям более высоких уровней.

Уровень WT-1. Базовые механизмы прямого взаимодействия с ТСВ.

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

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

Требования Канадских критериев

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

Сопряженные уровни: WI-2.

Уровень WT-2. Усовершенствованные средства прямого взаимодействия с

К'В.

i;;::a; а;;с Прямое взанмодемспше с ГСП должно использования для на- чальной идентификации и аутентификации пользователя, а также всегда иниции- роваться пользователем при необходимости передачи информации от пользовате- ля к ТСВ, или от ТСВ к пользователю.

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

Сопряженные уровни: WI-2.

Уровень WT-3. Полное обеспечения прямого взаимодействия с ТСВ.

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

Сопряженные уровни: WI-2.

5. Критерии адекватности реализации

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

5.0 Уровень Т-0. Недостаточная адекватность реализации. Зарезервирован для систем с недостаточным уровнем обеспечения адек- ватности, не удовлетворяющих требованиям более высоких уровней.

5.1 Уровень Т-1.

5.1.1 Архитектура.

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

Приложение 2

5.1.2 Среда разработки.

Процесс разработки.

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

.' Hr/iicit'iiiic конфигурацией <: и/чии'гсе /ч'инаоотки.

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

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

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

5.1.3 Контроль процесса разработки. Разработка спецификаций.

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

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

Разработка архитектуры.

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

Описание архитектуры компьютерной системы должно включать описание исех компонентов ТСВ.

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

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

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

Создание рабочего проекта.

Разработчик обязан составить неформальное описание рабочего проекта ТСВ.

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

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

Реализация.

Для данного уровня требования этого раздела не предъявляются.

Требования Канадских критериев

5.1.4 Поставка и сопровождение.

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

Разработчик должен определить и документировать псе параметры компь- ютерной системы. iieiici.n-iyeMi.ie для ее настройки системы и холе инсталляции, leiiepaiiini и запуска.

5.1.5 Документация.

Руководство по безопасности для пользователя.

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

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

Руководство администратора безопасности.

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

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

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

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

5.1.6 Тестирование безопасности.

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

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

5.2 Уровень Т-2.

5.2.1 Архитектура. Без изменений.

Приложение 2

5.2.2 Среда разработки. Процесс разработки. Без изменений.

Управление конфигурацией в процессе разработки. Без изменений.

5.2.3 Контроль процесса разработки. Разработка спецификаций.

Дополнение. Функциональные спецификации должны включать нефор- мальное описание модели безопасности.

Дополнение. Разработчик должен обеспечить полное соответствие между моделью безопасностью и реализованной политикой безопасности и показать, что модель безопасности полностью обеспечивает политику безопасности.

Разработка архитектуры.

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

Создание рабочего проекта.

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

Изменение. Должны быть описаны назначение и параметры интерфейсов всех компонентов ТСВ.

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

Реализация.

Для данною уровня требования :>тото раздела не предъявляются.

4. Поставка и сопровождение. Без изменений.

5. Документация.

Руководство по безопасности для пользователя. Без изменений.

Руководство администратора безопасности. Без изменений.

5.2.6 Тестирование безопасности.

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

Требования Канадских критериев