2.5.2.2. Разработка изделия ит

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• план УК;

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

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

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

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

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

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

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

• анализ уязвимостей;

• анализ скрытых каналов;

• оценку стойкости функций безопасности;

• анализ возможного неправильного применения.

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

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

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