Требования доверия: управление конфигурацией

Новые нормативные документы ФСТЭК России (требования к антивирусам и системам обнаружения вторжений), основанные на методологии стандарта «Общие критерии», предъявляют значительно больше требований к процедуре разработки объекта сертификации, чем «классические» РД. Например, при сертификации на соответствие требованиям 4 класса защиты, помимо документации (тестовой, конструкторской, эксплуатационной) и проведении процедуры внутреннего тестирования (требуемых, например 5 классом защищенности РД СВТ), требуется разработка большого количества документов и процедур. Одна из таких процедур — процедура управления конфигурацией (УК, configuration management).

Для 4 класса защиты данные требования представлены в виде компонентов доверия ACM_CAP.3 «Средства контроля авторизации» и ACM_SCP.1 «Охват УК объекта оценки». Компонент ACM_CAP.3 предъявляет требования к возможностям системы управления конфигурацией, функционирующей у предприятия-разработчика, компонент ‑ ACM_SCP.1 предъявляет требования к тому, что данной системой должно контролироваться (файлы дистрибутива, документация, исходные тексты и т д.).

Рассмотрим некоторые требования более подробно.

ACM_CAP.3.1D Разработчик должен предоставить маркировку для объекта оценки (ОО).

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

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

Если ОО состоит из нескольких частей, то маркировки этих частей должны быть согласованы друг с другом.

ACM_CAP.3.3D Разработчик должен представить документацию УК.

Документация УК, как правило включает документы по эксплуатации системы УК (как с ней должны работать разработчики ОО) и выходные документы системы управления конфигурацией (требования к их составу и содержанию предъявляет компонент ACM_SCP.1). При проведении сертификационных испытаний ИЛ должна установить, что разработчик действительно использует систему УК. Для 4 класса защиты разработчиком должны быть, как правило, разработаны следующие документы:

• эксплуатационная документация на систему УК (содержит описание того, как с данной системой работают разработчики ОО);
• список конфигурации, содержащий описание контролируемых элементов конфигурации (файл с исходными текстами, план тестирования и т.д.);
• документ содержащий методы идентификации элементов конфигурации (например, «… файл с исходными текстами имеет наименование aaa_XXXXX.cpp, где «aaa» — наименование компоненты, «XXXXX» — версия ОО»);
• план УК: является одним из основных документов, используемым разработчиком при работе системой УК (например, каким образом в элементы конфигурации вносятся изменения);
• описание механизма контроля доступа: описание реализации механизма, гарантирующего внесение изменений только уполномоченным субъектом.

ACM_SCP.1.1D. Разработчик должен представить документацию УК.

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

Далее по тексту приведены примеры списка УК.