Разработка изделия ИТ

В разделе «Разработка изделий ИТ» отмечается важность обес­печения безопасности на всех этапах жизненного цикла. Приво­дится ссыпка на документ «Базовая модель обеспечения безопас­ности на этапах жизненного цикла». Отмечено, что «модель жиз­ненного цикла должна быть принята до начала проектирования и разработки изделия ИТ». Требования к этой модели будут предъяв­лены позднее, в документе «Критерии...», и будут ранжированы в зависимости от уровня доверия.

Указано на необходимость разработки документа «Программа обеспечения безопасности при разработке и сопровождении изде­лия ИТ», структура его приведена в Приложении Б Положения. Центральное место в структуре Программы занимают модель обес­печения безопасности изделия ИТ при разработке и сопровождении и план-график работ по обеспечению безопасности изделия ИТ. Также в Программе должна быть детализирована система контроля безопасности изделия ИТ при разработке и сопровождении.

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

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

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

• функциональная спецификация;

• эскизный проект;

• технический проект;

• рабочий проект.

Требования к уровню представления проектных решений так­же будут установлены в «Критериях...».

Как видно из перечисления, новым видом представления про­ектных решений является функциональная спецификация. В По­ложении не уточняется, на каком этапе она разрабатывается, но in текста видно, что имеется в виду этап аванпроекта (если он предусмотрен), либо эскизного проекта. Функциональная специ­фикация должна содержать описание всех функций безопасности изделия (ФБИ), режимов и выполнения, назначение и способы использования всех внешних интерфейсов ФБИ. Может также раз­рабатываться модель политики безопасности изделия.

Эскизный проект уточняет функциональную спецификацию, преобразуя ее в представление ФБИ на уровне подсистем. Опре­деляются все аппаратные, программные, программно-аппаратные средства, требуемые для реализации ФБИ, взаимосвязи, интер­фейсы всех подсистем.

Технический проект уточняет эскизный проект до уровня детализации. Он должен содержать описание внутреннего содержа­нии ФБИ в терминах модулей, их взаимосвязей и зависимостей. Для высоких уровней доверия к внутренней структуре ФБИ предъявляются требования к модульности проектирования и пред­ставлению описания архитектуры ФБИ.

Важным новым элементом проектирования является необ­ходимость проведения анализа соответствия представлений

(ЗБ-ФС-ЭП-ТП-РП). Уровень формализации этого анализа будет зависеть от уровня доверия и он конкретизирован в «Критериях...».

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

• список элементов конфигурации изделия ИТ;

• план УК;

• план приемки элементов конфигурации под управление си­стемы УК;

• процедуры компоновки элементов конфигурации в состав изделия ИТ.

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

Из текста Положения видно, что для управления конфигура­цией необходима разработка инструментальных средств поддерж­ки УК. Конкретные требования по УК будут приведены ФСТЭК в «Критериях...».

Среди эксплутационной документации выделяются руковод­ство пользователя (РП) и руководство администратора (РА). В Р указывается, что делают функции безопасности и какова роль пользователя в ее поддержании. Сюда вносятся все предупрежде­ния пользователю из ПЗ/ЗБ, относящиеся к среде безопасности и целям безопасности изделия.

В Положении приведены требования по функциональному те­стированию. Отмечена необходимость как положительного, так и негативного тестирования. Указано, что разработчик должен со­здавать программу и методики тестирования, глубина проработки которых будет зависеть от уровня доверия и будет обозначена в «Критериях...».

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

Уязвимости должны быть устранены, минимизированы либо отслежены.

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

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