"Общие критерии", часть 3. Требования доверия безопасности

Требования к этапу получения, представления и анализа результатов разработки

Мы переходим к рассмотрению трех следующих классов требований доверия безопасности: AGD ( руководства ), ATE ( тестирование ) и AVA ( оценка уязвимостей ).

Класс AGD состоит из двух однокомпонентных семейств, где сформулированы требования к руководствам администратора (AGD_ADM) и пользователя (AGD_USR).

Руководство администратора должно содержать:

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

В руководство пользователя необходимо включить:

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

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

Разработчик выполняет функциональное тестирование (семейство ATE_FUN), обосновывает достаточность глубины (семейство ATE_DPT) и покрытия (ATE_COV) тестов.

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

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

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

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

Один из ключевых моментов оценки безопасности изделия ИТ - оценка уязвимостей (класс AVA), отправным пунктом которой является анализ уязвимостей (семейство AVA_VLA), выполняемый разработчиком и оценщиком. Четыре компонента этого семейства ранжированы по уровню строгости анализа и потенциалу предполагаемого нарушителя.

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

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

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

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

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

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

Анализ скрытых каналов, регламентируемый семейством AVA_CCA, крайне сложен и концептуально, и технически (см., например, статью [8]). Здесь легко требовать, но трудно выполнять. Согласно "Общим критериям", разработчик проводит исчерпывающий поиск скрытых каналов для каждой политики управления информационными потоками и предоставляет документацию анализа, в которой идентифицированы скрытые каналы и оценена их пропускная способность, описаны наиболее опасные сценарии использования каждого идентифицированного скрытого канала.

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