2.5.2. Требования по безопасности, предъявляемые к изделиям ит

Требования предъявляемые к изделиям ИТ, рассмотрим на примере современного нормативного документа «Безопасность информационных технологий» (Далее - Положение) [39]. Насколько известно авторам,! данный документ анализируется впервые в литературе

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

В Положении приведены ссылки на следующие РД ФСТЭК-

«Концепция обеспечения безопасности изделий информационных технологий»; «Критерии оценки безопасности информационных технологий»;

В Положении рассмотрены следующие вопросы:

• порядок задания требований;

• порядок разработки изделий ИТ;

• подтверждение соответствия изделий ИТ требованиям без­опасности информации;

• поставка и ввод в действие;

• эксплуатация;

• снятие с эксплуатации;

• характеристика требований раздела ТЗ;

• структура документа «Программа обеспечения безопасности прии разработке и сопровождении», а также «Программы… при эксплуатации изделий ИТ»;

• состав документов, предъявляемых разработчиком для сертификации;

• базовая модель обеспечения безопасности в жизненном цикле изделий ИТ (отдельная книга).

Рассмотрим особенности Положения.

Порядок задания требований

Здесь рассмотрены три сценария. Если закупается готовый продукт, то требования задаются в спецификациях на покупку изделии. Если разработка инициативная, то требования формируются Разработчиком с учетом предполагаемого применения изделия. Цели имеется заказчик изделия, то требования задаются им в ТЗ, Причем отмечена целесообразность в максимальной степени использовать стандартизованные требования, встречающиеся в технических регламентах, стандартах, РД ФСТЭК. Указано, что регламентация задания необходимых требований к изделиям, предназначенным для обработки информации ограниченного досту­па, осуществляется в нормативных документах ФСТЭК — профи-Лях зашиты (ПЗ). Таким образом, ПЗ отнесены к нормативным документам ФСТЭК.

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

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

Еще одна проблема состоит в следующем. В Положении указа­но, что в составе предположений о среде на данном этапе «...должны быть учтены проектные ограничения, определяемые общи­ми проектными решениями по изделию ИТ». Но ведь на данном этапе еще нет проектных решений! Впрочем, как указано далее, в ТЗ необходимо указать лишь ссылку на ПЗ, а откуда она появилась — это «на совести» заказчика.

Возможны два случая. Если основным назначением изделия ИТ является обеспечение безопасности информации, то требования к безопасности изделия ИТ составляют основное содержание разделов ТЗ. Если обеспечение безопасности информации — частная задача изделия, то требования должны содержаться в отдельном разделе ТЗ или в Приложении к нему, либо в частном (специальном) ТЗ.

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

Таким образом, при наличии соответствующего зарегистрированного ПЗ, все требования по безопасности к изделию ИТ могут:, состоять в ссылке на этот ПЗ плюс необходимые обоснования, уточнения и дополнения. В Приложении А к Положению приведена более подробная характеристика разделов ТЗ. В Положении отмечена целесообразность экспертизы ТЗ в организациях, специализирующихся на разработке или оценке ПЗ, как было отмечено ранее, нормативных документов ФСТЭК.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

план УК;

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

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

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

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

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

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

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

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

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

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

Обеспечение поддержки доверия к безопасности изделия ИТ при эксплуатации

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

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

• посредством оценки новой версии изделия ИТ;

• посредством реализации процедур поддержки доверия без­опасности к изделию ИТ, определенных в требованиях поддерж­ки доверия в «Критериях...».

Выбор разработчиком стратегии поддержки зависит от него самого. В последнем случае в ЗБ должны быть внесены соответ­ствующие требования поддержки доверия к безопасности из «Критериев...».

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

• план поддержки доверия, определяющий процедуры, кото­ рые должен выполнять разработчик;

» отчет о категорировании компонентов изделия ИТ по их от­ношению к безопасности.

Содержание этих документов описано в Положении.

В плане указываются контрольные точки, когда разработчик должен выдавать владельцу изделия ИТ свидетельство поддержа­ния доверия. К документации поддержки доверия также относятся:

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

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

• свидетельство следования процедурам поддержки доверия, определенным в плане ПД.

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

В цикле поддержки доверия должны предусматриваться четы­ре типа процедур: » управление конфигурацией;

»поддержка свидетельств, в которых отражены вопросы функционального тестирования;

• анализ влияния изменений в изделии ИТ на безопасность

• устранение недостатков безопасности.

Подтверждение соответствия изделий ИТ требованиям безопасности информации

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

Заявителем может быть разработчик или другое заинтересованное лицо, которое обязано в этом случае оформить договорные отношения с разработчиком.

Работы, выполняемые при сертификации:

• подготовка к оценке изделия ИТ (работы разработчика предварительное рассмотрение ЗБ лабораторией);

• оценка изделия ИТ (выполняет испытательная лаборатория);

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

Перечень документов, представляемых разработчиком для проведения сертификации, приведен в Приложении. Этот список впечатляет. Требуется представлять не только конечные материалы, но и материалы эскизного, технического и рабочего проекта. Всего имеется 27 категорий документов, разработка которых'¹ потребует от разработчика значительных усилий.

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

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

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

Поставка и ввод в действие. Эксплуатация изделия

Данные процедуры могут быть описаны в отдельном документе или включены в ЭД. Инструментальные средства контроля за идентичностью изделия при поставке должны быть сертифицированы.

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

Конкретные требования к поставке и вводу в эксплуатацию будут указаны в «Критериях...» в зависимости от ОУД.

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

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