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

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

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

В Положении приведены ссылки на следующие РД ФСТЭК: «Концепция обеспечения безопасности изделий информационных технологий»; «Критерии оценки безопасности информационных технологий».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• план УК;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• управление конфигурацией;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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