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

Требования доверия к этапу разработки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Затем следует обосновать выбор инструментальных средств и методов (семейство ALC_TAT). Это относится, в частности, к используемым языкам программирования, средствам подготовки документации, стандартам реализации и т.п.

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

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

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

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

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

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

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