Файл: лекции по ксзи.pdf

•  поставка  и  ввод  в действие;
•  эксплуатация;
•  снятие  с  эксплуатации;
•  характеристика  требований  раздела ТЗ;
•  структура  документа  «Программа  обеспечения  безопасности 

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

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

фикации;

• базовая  модель обеспечения безопасности  в жизненном цик­

ле  изделий  ИТ  (отдельная  книга).

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

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

Здесь рассмотрены три сценария.  Если закупается готовый про­

дукт,  то требования  задаются  в  спецификациях  на  покупку  изде­

лия.  Если разработка инициативная, то требования формируются 

разработчиком  с  учетом  предполагаемого  применения  изделия. 

Если  имеется  заказчик изделия,  то требования  задаются  им  в ТЗ, 

причем  отмечена  целесообразность  в  максимальной  степени  ис­
пользовать стандартизованные требования,  встречающиеся  в тех­
нических регламентах,  стандартах,  РД  ФСТЭК.  Указано,  что рег­

ламентация  задания  необходимых  требований  к  изделиям,  пред­

назначенным  для  обработки  информации  ограниченного  досту­
па, осуществляется в нормативных документах ФСТЭК — профи­

лях  защиты  (ПЗ).  Таким  образом,  ПЗ  отнесены  к  нормативным 
документам  ФСТЭК.

Выделяются  три  группы  требований:  функциональные,  дове­

рия, к среде объекта оценки. Требования задаются в начале разра­
ботки  изделия  ИТ,  на  основе  проведенного  глубокого  информа­
ционного  обследования  среды  применения  изделия  ИТ.  Очевид­

но,  что  это  неприменимо  к  продуктам  ИТ  общего  назначения, 
поэтому  для  них  далее  идут  всяческие  послабления  типа  «...для 
продуктов ИТ общего назначения могут быть сделаны общие утвер­

ждения  в  отношении  политики  безопасности  организации».

В  любом  случае  на  наш  взгляд  представляется  невозможным 

на  этапе  подготовки  ТЗ  выполнять такие  работы,  как  оценка  ак­

тивов,  подлежащих  защите,  оценка  правил  политики  безопасно­

сти  организации,  где  будет функционировать изделие  ИТ,  анализ 
рисков  нарушения  информационной  безопасности.  Кроме  того, 

данные  процедуры требуют разъяснения,  пояснения,  составления 

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

Еще одна проблема состоит в следующем.  В  Положении указа­

но,  что  в составе  предположений  о среде  на данном  этапе  «...дол­

жны  быть  учтены  проектные  ограничения,  определяемые  общи­

ми  проектными решениями по  изделию  ИТ».  Но  ведь на данном 

этапе  еще нет проектных решений!  Впрочем,  как указано далее,  в 

ТЗ  необходимо  указать лишь  ссылку  на  ПЗ,  а  откуда  она  появи­
лась  — это  «на совести»  заказчика.

Возможны  два  случая.  Если  основным  назначением  изделия 

ИТ является обеспечение  безопасности информации,  то требова­
ния к безопасности изделия ИТ составляют основное содержание 

разделов ТЗ. Если обеспечение безопасности информации — част­
ная задача изделия,  то требования должны содержаться  в отдель­

ном  разделе  ТЗ  или  в  Приложении  к нему,  либо  в  частном  (спе­
циальном)  ТЗ.

В ТЗ могут включаться требования соответствия одному или нес­

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

Если в ТЗ отсутствует ссылка на ПЗ или ПЗ уточняется, то должны 

приводиться  не только требования,  но и  цели  безопасности.

Таким  образом,  при  наличии соответствующего зарегистриро­

ванного  ПЗ,  все требования по безопасности к изделию ИТ могут 
состоять  в  ссылке  на  этот  ПЗ  плюс  необходимые  обоснования, 

уточнения и дополнения.  В  Приложении А к Положению приве­
дена более  подробная характеристика разделов ТЗ.  В  Положении 

отмечена  целесообразность  экспертизы  ТЗ  в  организациях,  спе­
циализирующихся на разработке  или  оценке  ПЗ,  как было  отме­

чено  ранее,  нормативных документов  ФСТЭК.

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

В разделе «Разработка изделий ИТ» отмечается важность обес­

печения  безопасности  на  всех  этапах жизненного  цикла.  Приво­

дится  ссылка на документ «Базовая  модель обеспечения безопас­

ности  на  этапах жизненного цикла».  Отмечено, что  «модель жиз­

ненного цикла должна быть принята до начала проектирования и 

разработки изделия ИТ». Требования к этой модели будут предъяв­

лены  позднее,  в документе  «Критерии...»,  и будут ранжированы в 

зависимости  от уровня доверия.

Указано  на  необходимость  разработки  документа  «Программа 

обеспечения  безопасности  при  разработке  и сопровождении  изде­

лия  ИТ»,  структура  его  приведена  в  Приложении  Б  Положения. 

Центральное место в структуре Программы занимают модель обес­

печения безопасности изделия ИТ при разработке и сопровождении 
и  план-график  работ  по  обеспечению  безопасности  изделия  ИТ. 

Также в Программе должна быть детализирована система контроля 
безопасности  изделия  ИТ при разработке  и  сопровождении.

В  Положении  указано  на важность  обеспечения  безопасности 

среды  разработки  изделия  ИТ.  Указано,  что  разработчик должен 

представить  документацию  по  обеспечению  этой  безопасности. 
Конкретные требования будут приведены в «Критериях...» в зави­
симости  от уровня доверия.

Уделено  внимание  используемым  при  разработке  инструмен­

тальным  средствам.  Они  должны  быть  лицензионно  чистыми,  а 
при необходимости сертифицированными. Средства должны осно­

вываться  на  стандартах  (быть  полностью  определенными)  либо 
быть подробно описаны в документации разработчика.  В докумен­

тации должны быть зафиксированы все настройки средств. Также 

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

В  Положении  отмечено,  что  конкретные  виды  разрабатывае­

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

•  функциональная спецификация;
•  эскизный  проект;
•  технический  проект;
•  рабочий  проект.
Требования  к уровню  представления  проектных решений так­

же  будут установлены  в  «Критериях...».

Как видно из перечисления,  новым видом представления про­

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

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

Эскизный  проект  уточняет  функциональную  спецификацию, 

преобразуя  ее  в  представление  ФБИ  на уровне  подсистем.  Опре­

деляются все аппаратные,  программные, программно-аппаратные 

средства,  требуемые  для  реализации  ФБИ,  взаимосвязи,  интер­
фейсы  всех подсистем.

Технический  проект  уточняет  эскизный  проект до  уровня  де­

тализации.  Он должен  содержать описание  внутреннего  содержа­

ния  ФБИ  в  терминах  модулей,  их  взаимосвязей  и  зависимостей. 

Для  высоких  уровней  доверия  к  внутренней  структуре  ФБИ 

предъявляются требования к модульности проектирования и пред­
ставлению  описания  архитектуры  ФБИ.

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

ходимость  проведения  анализа  соответствия  представлений

(ЗБ 

ФС 

эп 

тп 

-»  РП).  Уровень  формализации  этого 

анализа  будет  зависеть  от  уровня  доверия  и  он  конкретизирован 
в  «Критериях...».

В  отличие от других нововведений  необходимая документация 

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

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

стемы  УК;

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

изделия  ИТ.

Содержание  документов  кратко  поясняется  в  тексте  Положе­

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

Из  текста  Положения  видно,  что  для  управления  конфигура­

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

Среди  эксплутационной  документации  выделяются  руковод­

ство пользователя (РП) и руководство администратора (РА).  В  РП 

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

пользователя  в ее  поддержании.  Сюда вносятся все  предупрежде­
ния  пользователю из ПЗ/ЗБ, относящиеся к среде безопасности и 
целям  безопасности  изделия.

В  Положении  приведены требования по функциональному те­

стированию.  Отмечена необходимость как положительного, так и 

негативного  тестирования.  Указано,  что  разработчик должен  со­

здавать программу и методики тестирования,  глубина проработки 

которых  будет  зависеть  от  уровня  доверия  и  будет  обозначена  в 
«Критериях...».

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

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

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

отслежены.

Анализ  уязвимостей  в  зависимости  от  уровня  доверия  может 

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

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

Анализ  скрытых  каналов  проводится  в  случае,  если  изделие 

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

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

описать  скрытые  каналы,  их  пропускную  способность,  процеду­
ры,  применяемые для  выявления  скрытых  каналов  и  их  анализа, 

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

сти.

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

Большим  недостатком  существующей  системы  сертификации 

является  формальная  необходимость  «пересертификации»  изде­
лия  при  внесении  в  него  изменений.  Вместе  с тем  такие  измене­

ния могут вноситься достаточно часто,  в зависимости от предназ­
начения  изделия.

В Положении приведена принципиально новая процедура под­

тверждения  результатов  оценки  при  изменениях  в  сертифициро­

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

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

опасности  к  изделию  ИТ,  определенных  в требованиях  поддерж­

ки доверия  в  «Критериях...».

Выбор  разработчиком  стратегии  поддержки  зависит  от  него 

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

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

рые  должен  выполнять  разработчик;

•  отчет  о  категорировании  компонентов  изделия  ИТ  по  их от­

ношению  к безопасности.

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

должен  выдавать  владельцу  изделия  ИТ  свидетельство  поддержа­

ния доверия.  К документации  поддержки доверия также относятся:

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

определенным  в  плане  ПД.

Указывается также график проведения аудита поддержки дове­

рия.  Этот  аудит  выполняет  испытательная лаборатория,  необяза­

тельно  та же,  что  проводила  сертификацию.

В  цикле  поддержки  доверия  должны  предусматриваться  четы­

ре  типа  процедур: