Предисловие

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. № 184-ФЗ «О техническом регулировании», а правила применения национальных стандартов Российской Федерации — ГОСТ Р1.0 — 2004 «Стандартизация в Российской Федерации. Основные положения»

Сведения о стандарте

1    ПОДГОТОВЛЕН Обществом с ограниченной ответственностью «Центр безопасности информации» (ООО «ЦБИ») на основе собственного аутентичного перевода стандарта, указанного в пункте 5

2    ВНЕСЕН Управлением технического регулирования и стандартизации Федерального агентства по техническому регулированию и метрологии

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 18 декабря 2008 г. № 526-ст

4    ВВЕДЕН ВПЕРВЫЕ

5    Настоящий стандарт идентичен международному стандарту ИСО/МЭК Т0 15446:2004 «Информационная технология. Методы и средства обеспечения безопасности. Руководство по разработке профилей защиты и заданий по безопасности» (ISO/IEC TR 15446:2004 «Information technology — Security techniques — Guide for the production of Protection Profiles and Security Targets»).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении G

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

© Стандартинформ, 2010

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

- оценщики нуждаются в информации, которая будет мотивировать правильность и эффективность ПЗ или ЗБ с технической точки зрения.

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

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

Раздел «Требования безопасности ИТ», относящийся к ПЗ, предназначен прежде всего для разработчиков ОО, хотя информация, содержащаяся в этом разделе, вероятно, также будет интересна потребителям. Раздел ЗБ «Краткая спецификация ОО» предназначен прежде всего для оценщиков и потребителей. Если последние два раздела ПЗ не содержат достаточного количества информации, то в них необходимо поместить ссылку на другие разделы (подразделы) ПЗ (например, «Аннотация ПЗ») и документы, необходимые для полного и точного понимания представленныхтребований безопасности ИТ.

В раздел ПЗ и ЗБ «Обоснование» включают информацию, предназначенную преимущественно для оценщиков. В то же время оценщикам целесообразно ознакомиться со всеми разделами ПЗ и ЗБ.

6.5    Процесс разработки профилей защиты и заданий по безопасности

Анализ приложений В и С ИСО/МЭК 15408-1 и разделов 3 — 5 ИСО/МЭК 15408-3 показывает, что разработка ПЗ и ЗБ осуществляется в следующей (нисходящей) последовательности:

a)    идентификация аспектов среды безопасности;

b)    определение целей безопасности, учитывающих идентифицированные аспекты среды безопасности;

c)    формирование требований безопасности ИТ, направленных на удовлетворение целей безопасности.

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

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

a)    идентификацию новых угроз;

b)    изменение ПБОр;

c)    связанные со стоимостными и временными ограничениями изменения в разделении ответственности обеспечения безопасности, возлагаемой соответственно на ОО и среду ОО;

d)    корректировку требований безопасности ИТ, функций безопасности и/или мер доверия к безопасности, связанную с изменениями в технологии и затратах на разработку ОО.

Также возможно (например, для существующего продукта ИТ), что разработчики ПЗ и ЗБ имеют четкое представление относительно ФТБ, которым соответствует ОО (даже если эти требования не были выражены в стандартах серии ИСО/МЭК 15408). В таких случаях определение аспектов среды безопасности и целей безопасности будет осуществляться, исходя из этих ФТБ. Процесс разработки ПЗ и ЗБ в таком случае будет «восходящим».

6.6    Семейства профилей защиты

Семейство ПЗ представляет собой совокупность тесно связанных ПЗ, которые обычно относятся к одному и тому же типу продукта или системы ИТ (например, операционная система, межсетевой экран и т.д.). Разработка ПЗ может, таким образом, рассматриваться как часть процесса разработки семейства ПЗ. Разработка семейств ПЗ может идти по следующим направлениям:

a)    разработка совокупности иерархически связанных ПЗ для одного и того же типа ОО (ПЗ можно считать иерархическим по отношению к другому ПЗ семейства, если он включает в себя все требования безопасности ИТ, специфицированные в другом ПЗ);

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

ГОСТ Р ИСО/МЭК Т015446 — 2008

Если семейство ПЗ относится к конкретному типу 00, важно, чтобы было четкое различие между различными членами семейства. Другими словами, должны быть четкие различия в требованиях безопасности ОО. Это связано стем, что ПЗ должен, по крайней мере, отличаться целями безопасности, которые определяют выбор требований безопасности ИТ. В качестве примера можно рассмотреть случай, когда два ПЗ специфицируют одну и ту же совокупность ФТБ, но разные ТДБ. Допускается мотивировать более низкое требование безопасности возрастанием безопасности среды 00. Такие различия должны быть отражены в целях безопасности. Там же, где семейство ПЗ применяется к различным компонентам системы ИТ (в конкретной или предполагаемой среде), должны быть четко определены ПЗ, включенные в семейство (см. также раздел 14, в котором рассматриваются вопросы разработки ПЗ для компонентов системы ИТ).

7 Описательные разделы профилей защиты и заданий по безопасности

7.1    Введение

Настоящий раздел содержит рекомендации по формированию следующих описательных разделов ПЗ и ЗБ:

a)    «Введение ПЗ и ЗБ»;

b)    «Описание ОО» в ПЗ и ЗБ;

c)    «Замечания по применению в ПЗ».

7.2    Описательные части профиля защиты и задания по безопасности

7.2.1    Раздел «Введение»

7.2.1.1    Подраздел «Идентификация»

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

a)    ключевые слова;

b)    оценочный уровень доверия (ОУД), если применяется в ПЗ;

c)    утверждение о соответствии версии конкретному стандарту серии ИСО/МЭК 15408;

d)    состояние оценки ПЗ.

7.2.1.2    Подраздел «Аннотация»

В соответствии со стандартами серии ИСО/МЭК 15408 подраздел «Аннотация ПЗ» должен быть представлен в форме резюме, используемого также в реестрах и каталогах ПЗ. В данный раздел необходимо включить высокоуровневый обзор проблемы безопасности, которая подлежит решению в ПЗ. Также желателен краткий обзор того, как ПЗ способствует решению проблемы безопасности. Этот обзор должен соответствовать техническому содержанию ПЗ. В случае необходимости «Аннотация ПЗ» может быть расширена до «Резюме для руководителя» или «Резюме для менеджера». Однако если предполагается, что ПЗ будет включен в реестр ПЗ, то соответствующий краткий обзор (обычно один-два параграфа) должен быть сформирован так, чтобы его можно было перенести в реестр.

При формировании раздела ЗБ «Введение» целесообразно руководствоваться рекомендациями по формированию раздела ПЗ «Введение», за исключением того, что:

a)    утверждение о соответствии ИСО/МЭК 15408 является необязательным для ЗБ;

b)    к ЗБ неприменимы процедуры регистрации ПЗ;

c)    может потребоваться идентификация ЗБ, связанных с рассматриваемым ЗБ, если ОО представляет собой составной ОО либо является частью составного ОО.

7.2.2    Раздел «Описание объекта оценки»

В раздел «Описание ОО» ПЗ включают информацию о следующих видах (первые два вида информации — предписаны ИСО/МЭК 15408, два последних—являются необязательными):

a)    тип продукта ИТ;

b)    основные функциональные возможности ОО;

c)    границы ОО (необязательная информация);

d)    среда функционирования ОО (необязательная информация).

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

7

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

Описание «среды функционирования ОО» (необязательное) — это описание того, где функционирует ОО, включая важные предположения, ограничения, накладываемые процессами деятельности, и другие ключевые параметры, важные сточки зрения пользователей ПЗ.

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

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

7.2.3 Раздел «Замечания по применению»

Раздел «Замечания по применению» является необязательным. Замечания по применению могут быть оформлены как отдельный раздел ПЗ либо сопровождать различные части ПЗ, например, отдельные требования безопасности 00. В замечания по применению целесообразно включать сопроводительную информацию, которая может оказаться полезной при проектировании, оценке и эксплуатации ОО. Основное назначение раздела «Замечания по применению» — пояснить, как конкретные требования безопасности необходимо интерпретировать для рассматриваемого ОО, а также предоставить разработчикам ЗБ рекомендации по выполнению операций (выбор, назначение, уточнение) над функциональными компонентами.

Если замечания по применению распределены по всему тексту ПЗ, то в этих случаях их необходимо однозначно идентифицировать кактаковые, чтобы пользователь ПЗ интерпретировал их именно как «Замечания по применению», а не как, например, уточнения для ФТБ и ТДБ.

8 Среда безопасности объекта оценки

8.1 Введение

В данном разделе представлены рекомендации по спецификации раздела ПЗ и ЗБ «Среда безопасности 00». Требования к содержанию этого раздела ПЗ и ЗБ определены в ИСО/МЭК15408-1, приложение В, подраздел В.2.4 и приложение С, подраздел С.2.4.

Содержание разделов «Среда безопасности ОО» в ПЗ и «Среда безопасности ОО» в ЗБ не имеют серьезных различий.

Цель раздела «Среда безопасности ОО» состоит в определении аспектов безопасности среды ОО (см. рисунок 1).

Аспекты среды безопасности объекта оценки

Рисунок 1 — Определение аспектов среды безопасности объекта оценки

В данном разделе предметом рассмотрения становятся следующие аспекты:

a)    предположения относительно среды безопасности ОО;

b)    активы, требующие защиты (обычно информация или ресурсы в пределах ИТ-среды или непосредственно ОО), идентифицированные источники угроз и сами угрозы, которые они порождают для активов;

c)    ПБОр или правила, которым должен соответствовать ОО.

ГОСТ Р ИСО/МЭК Т015446 — 2008

Следующие разделы ПЗ и ЗБ показывают, как аспекты безопасности среды ОО будут удовлетворяться объектом оценки и его средой. Именно поэтому важно обеспечить ясную и краткую формулировку аспектов безопасности среды 00.

При определении аспектов среды безопасности следует избегать (где возможно) описания того, как ОО учитывает аспекты безопасности среды. Такой подход позволяет акцентировать внимание пользователя ПЗ и ЗБ на наиболее важных аспектах безопасности среды ОО.

8.2    Идентификация и спецификация предположений безопасности

В соответствии со стандартами серии ИСО/МЭК 15408 в раздел «Среда безопасности ОО» ПЗ и ЗБ необходимо включать перечень предположений относительно среды безопасности ОО или предполагаемого использования 00.

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

В ПЗ и ЗБ целесообразно включать следующие группы предположений:

a)    предположения относительно будущего использования ОО;

b)    предположения, связанные с защитой любой части ОО со стороны среды (например, физическая

защита);

c)    предположения связности [например, межсетевой экран должен быть единственным сетевым соединением между частной (защищаемой) и внешней (потенциально враждебной) сетью];

d)    предположения, имеющие отношение к персоналу [например, предполагаемые пользовательские роли, основные обязанности (ответственность) пользователей и степень доверия этим пользователям].

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

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

Наряду с использованием итерационного подхода к идентификации предположений безопасности, необходимо избегать включения в раздел «Среда безопасности ОО» любых предположений, связанных с эффективным использованием конкретных функций безопасности ОО (ФБО), которые идентифицированы в процессе формирования раздела «Обоснование». Соответствующую этим «предположениям» информацию целесообразно включать в ПЗ и ЗБ в виде требований безопасности для не ИТ-среды (см. 10.5.2).

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

Для упрощения осуществления ссылок рекомендуется, чтобы каждое предположение было пронумеровано или имело уникальную метку.

Примеры предположений приведены в приложении В.

8.3    Идентификация и спецификация угроз

8.3.1 Краткий обзор

Согласно ИСО/МЭК 15408-1, приложения В, подраздел В.2.4 необходимо включать в ПЗ и ЗБ описание всех угроз для активов, подлежащих защите. Тем не менее формулировка угроз может быть опущена, если цели безопасности сформулированы, исходя исключительно из ПБОр, то есть формулировка угроз может быть опущена в случае, если аспекты среды безопасности ОО полностью определяются ПБОр и предположениями безопасности.

При этом рекомендуется, чтобы формулировка угроз была включена в ПЗ и ЗБ, поскольку она обеспечивает лучшее понимание аспектов среды безопасности ОО, чем соответствующая им совокупность правил ПБОр. Более того, достаточно опасно полагаться исключительно на ПБОр, так как она не всегда может надлежащим образом отразить текущие угрозы. Если полная совокупность правил ПБОр уже

9

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

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

8.3.2 Идентификация угроз

8.3.2.1    Понятие угрозы

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

Примечание — Нарушения ПБОр не должны трактоваться как угрозы.

В целях идентификации угроз необходимо выяснить:

a)    какие активы требуют защиты;

b)    кто или что является источником угрозы;

c)    от каких методов нападения или нежелательных событий активы должны быть защищены.

8.3.2.2    Идентификация активов

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

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

В примере ПЗ для третьей доверенной стороны (ТДС) (см. приложение F) различные криптографические ключи будут иметь разных владельцев: подписчиков ТДС и владельца самого ТДС. Другой пример — медицинские системы ИТ. Хранимая и обрабатываемая в них информация не имеет одного владельца, а предназначена для использования всеми заинтересованными сторонами в соответствии с заданным набором правил ее использования и контроля такого использования.

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

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

a)    нечеткому пониманию основного предназначения ОО (обеспечение защиты первичных активов или их представлений в пределах ИТ-среды);

b)    слишком раннему (еще до описания угроз и целей безопасности) ознакомлению пользователя ПЗ и ЗБ сдеталями реализации.

8.3.2.3    Идентификация источников угроз

Источником угроз могут быть люди либо иные не связанные с деятельностью человека факторы. При этом основное внимание обычно уделяется угрозам, связанным со злонамеренной или другой деятельностью человека.

При идентификации источников угроз необходимо рассмотреть:

а) кто и по каким причинам может быть заинтересован в компрометации идентифицированных активов;

10

ГОСТ Р ИСО/МЭК Т015446 — 2008

b)    кто (с учетом занимаемой должности) имеет возможность компрометации идентифицированных активов. Другими словами, кто может получить доступ к системе ИТ, в которой хранятся, обрабатываются и передаются идентифицированные активы;

c)    каковы предполагаемые уровень технической компетентности, уровень возможностей нарушителя, доступные ресурсы для реализации угрозы (например, автоматические инструментальные средства взлома и исследования сетей) и мотивация.

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

8.3.2.4    Идентификация методов нападения

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

a)    потенциальных уязвимостях активов, которые могут быть использованы источниками угроз;

b)    возможности нарушителей, имеющихдоступ к среде безопасности ОО.

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

8.3.2.5    Влияние результатов анализа рисков на идентификацию угроз

Проведение анализа рисков целесообразно на этапе идентификации угроз, но методы анализа рисков не определены в ИСО/МЭК 15408. Процесс анализа рисков также необходим на этапе идентификации целей безопасности для ОО и его среды (см. раздел 8) и требуемого уровня доверия к контрмерам, направленным на противостояние возможным угрозам (см. раздел 9). Методы анализа риска должны учитывать следующее:

a)    вероятность и последствия компрометации активов с учетом:

1)    возможности реализации идентифицированных методов нападения,

2)    вероятности успешной реализации нападения,

3)    возможного ущерба (включая величину материального ущерба, явившегося результатом успешного нападения);

b)    другие ограничения, например правовые нормы и стоимость.

8.3.3 Спецификация угроз

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

Для обеспечения четкой спецификации угроз необходимо учитывать следующие аспекты (идентифицированные в соответствии С8.2.1):

a)    источники угроз (например, уполномоченный пользователь ОО);

b)    активы, подверженные нападению (например, конфиденциальные данные);

c)    используемый метод нападения (например, маскировка под уполномоченного пользователя ОО).

Ниже приведены примеры формулирования угроз:

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

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

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

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

11

при использовании ПЗ и ЗБ, а также ненужных повторений, обеспечив тем самым более простое обоснование ПЗ и ЗБ.

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

Каждая угроза должна иметь уникальную метку. Это необходимо для упрощения использования ссылок (например, в тех частях раздела ПЗ «Обоснование», которые показывают связь изложенных целей безопасности и угроз). Угрозы маркируют одним из перечисленных ниже способов:

a)    последовательная нумерация угроз (например, У1, У2, УЗ и т.д.);

b)    присвоение уникальной метки, обеспечивающей краткое, но значащее «имя» (см. примеры в приложении В).

Преимущество подхода Ь) перед а) заключается в том, что уникальная метка является более информативной, так как несет в себе более значимую информацию, чем просто цифра. Неудобство подхода Ь) заключается в том, что не всегда удается нанести уникальную метку (из-за практических ограничений, связанных с ограничением числа символов в метке); так, в некоторых случаях метка может ввести в заблуждение, или ее можно толковать по-разному.

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

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

a)    в результате их включения в раздел «Среда безопасности ОО» преждевременно не рассматривались детали реализации ОО, нарушающие системный подход к решению проблем безопасности;

b)    они (угрозы) не попадали в область действия существующих угроз.

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

При выборе требований безопасности ИТ, к которым (согласно стандартам серии ИСО/МЭК 15408) в свою очередь предъявляются требования взаимной поддержки, существует необходимость рассмотрения атак (например обход или вмешательство в процесс функционирования), направленных против контрмер, реализуемых ОО. Любые возможные атаки также должны быть раскрыты на этапе оценки ОО. Также должны быть выявлены все потенциально реализуемые атаки, направленные против функций безопасности ОО.

Примеры угроз приведены в приложении В.

8.3.4 Окончательное формулирование угроз

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

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

a)    физическое нападение на ОО;

b)    злоупотребление правами со стороны привилегированных пользователей;

c)    неправильное администрирование и функционирование ОО вследствие ненадлежащего исполнения обязанностей или недостаточной подготовки администраторов.

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

ГОСТ Р ИСО/МЭК Т015446 — 2008

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

8.4 Идентификация и спецификация политики безопасности организации

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

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

Если ПЗ и ЗБ определяет и ПБОр, и угрозы, то следует кратко излагать в разделе «Среда безопасности ОО» аспекты среды безопасности ОО. Так, например, нецелесообразно включать в ПЗ и ЗБ правило ПБОр, являющееся простой переформулировкой угрозы.

Например, если идентифицирована угроза «Неуполномоченный субъект может получить логический доступ кОО»,то не имеет смысла включать в ПЗ и ЗБ следующее правило ПБОр: «Пользователи должны быть идентифицированы до предоставления им доступа».

Вышесказанное связано стем, что сформулированное таким образом правило ПБОр не только просто переформулирует угрозу, но и заранее описывает цели безопасности.

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

a)    идентификация применяемых правил управления информационными потоками;

b)    идентификация применяемых правил управления доступом;

c)    определение правил ПБОр для аудита безопасности;

d)    решения, предписанные организацией, например, использование определенных криптографических алгоритмов или следование определенным стандартам.

Каждое правило ПБОр должно иметь уникальную метку.

Примеры правил ПБОр приведены в приложении В.

9 Цели безопасности

9.1 Введение

Данный раздел содержит рекомендации по идентификации и спецификации целей безопасности в ПЗ или ЗБ.

Цели безопасности представляют собой краткую формулировку предполагаемой реакции на проблему безопасности. Краткость формулирования целей безопасности предполагает отсутствие необходимости глубокого рассмотрения деталей ихдостижения.

При этом цели безопасности следует расценивать как промежуточное звено, помогающее пользователю ПЗ и ЗБ отследить взаимосвязь между аспектами среды безопасности ОО и требованиями безопасности (см. рисунок2).

В ПЗ и ЗБ необходимо различать два типа целей безопасности (см. рисунок 2):

a)    цели безопасности для ОО, которые должны достигаться применением контрмер, реализуемых ОО;

b)    цели безопасности для среды ОО, которые должны достигаться применением технических мер, реализуемыхИТ-средой, или не ИТ-мер (например, организационных).

Деление целей безопасности на два типа (для ОО и его среды) позволяет в контексте среды безопасности ОО вкратце изложить, решение каких аспектов проблемы безопасности возлагается на ОО. Разделе-

13

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

Аспекты среды безопасности объекта оценки

9.2 Спецификация целей безопасности для объекта оценки

Цели безопасности ОО должны установить (в заданном разработчиком ПЗ и ЗБ объеме) возлагаемую на ОО ответственность за противостояние угрозам и следование ПБОр. Цели безопасности ОО (см. рисунок 2) можно рассматривать как промежуточный этап формирования требований безопасности ИТ, исходя из идентифицированных аспектов среды безопасности ОО, что необходимо всегда учитывать при спецификации целей безопасности для ОО.

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

a)    с одной стороны, цели безопасности должны помочь пользователю ПЗ и ЗБ без углубленного изучения деталей реализации понять объем решения объектом оценки проблемы безопасности (степень учета аспектов среды безопасности ОО). В идеале цели безопасности для ОО должны быть независимы от реализации. Таким образом, основное внимание необходимо сосредоточить на том, какое решение предпочтительнее, а не на том, как это решение достигается;

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

Окончательную проверку правильности выбора уровня детализации формулировки целей безопасности проводят на этапе обоснования целей безопасности и требований безопасности ИТ. Если какой-либо из шагов на этапе обоснования (обоснование целей безопасности или обоснование требований безопасности) является несложным, в то время как другой вызывает значительные затруднения, то вероятнее всего формулировка целей безопасности является слишком детализированной либо слишком абстрактной.

Сформированный надлежащим образом набор целей безопасности для ОО дает определенную уверенность в том, что формулируемые на его основе требования безопасности ИТ не будут избыточными (в части ФТБ см. 10.1.1; в части ТДБ см. 10.2.1), что в свою очередь служит основой для минимизации средств и времени, затрачиваемых на оценку ОО.

ГОСТ Р ИСО/МЭК Т015446 — 2008

С точки зрения противостояния идентифицированным угрозам существует три типа целей безопасности для 00:

1)    цели предупредительного характера, направленные на предотвращение реализации угроз либо на перекрытие возможных путей реализации данных угроз;

2)    цели обнаружения, определяющие способы обнаружения и постоянного мониторинга событий, оказывающих влияние на безопасное функционирование ОО;

3)    цели реагирования, определяющие необходимость каких-либо действий ОО в ответ на потенциальные нарушения безопасности или другие нежелательные события с целью сохранения или возврата ОО в безопасное состояние и/или ограничения размера причиненного ущерба.

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

объект оценки должен уникально идентифицировать каждого пользователя и выполнять процедуру аутентификации идентифицированного пользователя до предоставления ему доступа к функциональным возможностям ОО.

Цели безопасности, связанные с управлением доступом и информационными потоками, также относят к категории целей предупредительного характера. Если ОО должен реализовывать более одной политики управления доступом и информационными потоками, то рекомендуется для каждой политики идентифицировать отдельные цели безопасности. Такой подход способствует упрощению процесса обоснования требований безопасности.

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

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

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

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

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

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

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

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

Соответствие целей безопасности для ОО угрозам и ПБОр достигается с учетом:

a)    каждой идентифицированной угрозы, направленной против ОО, по крайней мере, одной целью безопасности для ОО;

b)    каждого правила идентифицированной ПБОр, которому должен соответствовать ОО, по крайней мере, одной целью безопасности для ОО.

Наглядность такого соответствия может быть достигнута, например, за счет использования перекрестных ссылок или отображения рассматриваемого соответствия в форме таблицы. Несмотря на то, что демонстрация соответствия целей безопасности угрозам и ПБОр будет приведена в разделе «Обоснование» (см. разделы 12 и 13), для пользователя ПЗ и ЗБ было бы полезно отображение такого соответствия уже в разделе «Цели безопасности». В случае, если цель безопасности предполагает реализацию какого-либо правила ПБОр, предпочтительнее в раздел «Цели безопасности» включить ссылку на соответствующее правило ПБОр, а не повторять установленные ПБОр правила, подлежащие реализации (см. пример цели безопасности O.DAC, приведенный в приложении В).

15

ГОСТ Р ИСО/МЭК Т015446 — 2008

Содержание

1    Область применения........................................ 1

2    Нормативные ссылки....................................... 1

3    Термины и определения...................................... 2

4    Сокращения............................................ 2

5    Цель............................................... 2

6    Краткий обзор профилей защиты и заданий по безопасности.................... 3

6.1    Введение........................................... 3

6.2 Содержание профилей защиты и заданий по безопасности................... 3

6.3 Взаимосвязь между профилями защиты и заданиями по безопасности............. 5

6.4    Учет информационных потребностей потенциальных пользователей профилей защиты и заданий по безопасности ...................................... 5

6.5    Процесс разработки профилей защиты и заданий по безопасности............... 6

6.6    Семейства профилей защиты................................. 6

7    Описательные разделы профилей защиты и заданий    по безопасности............... 7

7.1    Введение........................................... 7

7.2    Описательные части профиля защиты и задания по безопасности............... 7

8    Среда безопасности объекта оценки................................ 8

8.1    Введение........................................... 8

8.2    Идентификация и спецификация предположений    безопасности................. 9

8.3    Идентификация и спецификация угроз............................. 9

8.4    Идентификация и спецификация политики безопасности организации............. 13

9    Цели безопасности........................................ 13

9.1    Введение........................................... 13

9.2    Спецификация целей безопасности для объекта    оценки.................... 14

9.3    Спецификация целей безопасности для среды    объекта оценки................. 16

10    Требования безопасности..................................... 17

10.1    Введение.......................................... 17

10.2    Спецификация функциональныхтребований безопасности в профиле защиты или задании по

безопасности ......................................... 19

10.3    Спецификация в профилях защиты или заданиях по безопасности требований доверия к безопасности ........................................... 27

10.4    Требования безопасности для среды............................. 28

11    Краткая спецификация объекта оценки............................... 30

11.1    Введение.......................................... 30

11.2    Спецификация функций безопасности информационных технологий.............. 31

11.3    Спецификация механизмов безопасности........................... 31

11.4    Спецификация мер доверия к безопасности.......................... 32

12    Утверждения о соответствии профилей защиты.......................... 32

12.1    Введение.......................................... 32

12.2    Ссылка на профили защиты.................................. 32

12.3    Конкретизация профилей защиты............................... 32

12.4    Дополнение профилей защиты................................ 33

13    Разделы «Обоснование» профилей защиты и заданий    по    безопасности.............. 33

13.1    Введение.......................................... 33

13.2    Представление в профилях защиты и заданиях по безопасности обоснования целей безопасности ............................................. 33

13.3    Представление в профилях защиты и заданиях по безопасности обоснования требований безопасности ........................................... 34

14    Профили защиты и задания по безопасности для составных объектов оценки и объектов оценки,

входящих в состав других объектов оценки............................ 38

14.1    Введение........................................... 38

14.2    Составной объект оценки................................... 39

14.3    Объект оценки — компонент................................. 41

Цели безопасности для ОО должны быть уникально маркированы. Маркировка может быть основана на последовательной нумерации (например, Ц1, Ц2, ЦЗ и т.д.) либо на использовании значащих меток (см. примеры, приведенные в приложении В).

9.3 Спецификация целей безопасности для среды объекта оценки

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

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

a)    противостояние угрозам (или отдельным аспектам угроз), которым ОО не противостоит;

b)    поддержку реализации правил ПБОр, которые не соответствуют или не полностью соответствуют ОО;

c)    поддержку идентифицированных целей безопасности для ОО в плане противостояния угрозам и реализации соответствующих правил ПБОр;

d)    поддержку идентифицированных предположений о среде.

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

a)    сформулировать новую цель безопасности для учета рассматриваемого аспекта среды безопасности ОО;

b)    поставить в соответствие рассматриваемому аспекту среды безопасности ОО ранее уже сформулированную цель безопасности, если соответствующая цель уже была сформулирована (при этом может потребоваться доработка формулировки цели безопасности с тем, чтобы расширить ее область действия).

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

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

a)    цели безопасности для ОО должны быть сформулированы так, чтобы соответствующие им требования ИТ не требовали чрезмерно больших затрат на оценку их выполнения;

b)    цели безопасности для среды ОО должны быть сформулированы так, чтобы соответствующие им требования к организационным мерам и не ИТ-средствам были практически реализуемы, а также не накладывали чрезмерные ограничения на действия пользователей ОО.

Типовые не ИТ-цели безопасности для среды могут предусматривать:

a)    разработку и применение организационных мер (методик, процедур, приемов), обеспечивающих эксплуатацию ОО так, чтобы его безопасность не нарушалась (в частности, соблюдались все предположения о среде);

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

Таким образом, в состав целей безопасности для среды необходимо включать в том числе цели безопасности, связанные сдействиями управления, направленными на обеспечение эффективности функций безопасности, предоставляемых объектом оценки. В некоторых случаях требуемые действия управления являются очевидными и могут быть выражены в форме не ИТ-целей безопасности для среды (например, при рассмотрении вопроса о необходимости надлежащего управления функциями аудита). В других случаях требуемые действия управления могут зависеть от детализованных требований безопасности, используемых для реализации целей безопасности ОО. Например, цель безопасности «идентификация и аутентификация» (см. цель Ц1 в 9.1) может быть реализована путем использования механизма пользовательских паролей. Использование механизма пользовательских паролей предполагает необходимость формулирования соответствующего требования к пользователям, связанного с обеспечением последними недоступности паролей для других лиц. Данное требование безопасности представляет собой требование

ГОСТ Р ИСО/МЭК Т015446 — 2008

15 Функциональные пакеты и пакеты требований доверия к безопасности............... 42

15.1    Общая информация..................................... 42

15.2    Формирование функционального пакета........................... 42

15.3    Спецификация пакета требований доверия к безопасности.................. 43

Приложение А (рекомендуемое) Резюме............................... 44

Приложение В (рекомендуемое) Основные примеры......................... 47

Приложение С (рекомендуемое) Спецификация криптографических функциональных возможностей .    66

Приложение D (рекомендуемое) Рабочий пример: профили защиты и задание по безопасности для

межсетевого экрана.................................. 86

Приложение Е (рекомендуемое) Рабочий пример: профили защиты для системы управления базой

данных........................................ 90

Приложение F (рекомендуемое) Рабочий пример: Профиль защиты третьей доверенной стороны ...    94

Приложение G (справочное) Сведения о соответствии национальных стандартов Российской Федерации ссылочным международным стандартам..................... 99

Библиография............................................100

IV

ГОСТ Р ИСО/МЭК Т015446 — 2008

Введение

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

Профиль защиты включает в себя взаимосвязанную информацию, имеющую отношение к безопасности ИТ, в том числе:

a)    формулировку потребности в безопасности, соответствующую проблеме безопасности и выраженную в терминах, ориентированных на пользователей ИТ;

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

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

d)    функциональные требования безопасности и требования доверия к безопасности, направленные на решение проблемы безопасности в соответствии с описанием среды безопасности ОО и целями безопасности для ОО и ИТ-среды. Функциональные требования безопасности выражаютто, что должно выполняться ОО и ИТ-средой для удовлетворения целей безопасности. Требования доверия к безопасности определяют степень уверенности в правильности реализации функций безопасности ОО;

e)    обоснование функциональных требований и требований доверия к безопасности, являющихся надлежащими для удовлетворения сформулированной потребности в безопасности. Посредством целей безопасности должно быть показано, что необходимо сделать для решения проблем безопасности, имеющихся в описании среды безопасности ОО. Функциональные требования безопасности и требования доверия к безопасности должны соответствовать целям безопасности.

Задание по безопасности (ЗБ) во многом похоже на ПЗ, но содержит дополнительную информацию, ориентированную на конкретную реализацию продукта или системы ИТ и разъясняющую, каким образом требования ПЗ реализуются в конкретном продукте или системе. ЗБ содержит следующую дополнительную информацию, отсутствующую в ПЗ:

a)    краткую спецификацию ОО, которая представляет функции безопасности и меры доверия к безопасности для конкретного ОО;

b)    дополнительный раздел, который включается в ЗБ в случаях, если утверждается о соответствии ЗБ одному или более ПЗ;

c)    дополнительные свидетельства в разделе «Обоснование», устанавливающие, что краткая спецификация ОО обеспечивает соответствие требований безопасности, а любые утверждения о соответствии ПЗ—действительны.

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

Поставщики продукта ИТ в соответствии с потребностями безопасности, сформулированными в ПЗ, могут разработать ЗБ, которое будет демонстрировать то, как их продукт ИТ соответствует потребностям безопасности. Тем не менее, соответствие задания по безопасности профилю защиты не является обязательным; например, в ЗБ могут быть определены функции безопасности, заявляемые разработчиком продукта ИТ и представляющие собой основу для оценки продукта ИТ.

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

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология

МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ

Руководство по разработке профилей защиты и заданий по безопасности

Information technology. Security techniques.

Guide for the production of protection profiles and security targets

Дата введения — 2009 —10— 01

1    Область применения

Настоящий стандарт представляет собой руководство по разработке профилей защиты и заданий по безопасности продуктов и систем ИТ в соответствии с комплексом стандартов ИСО/МЭК 15408 (общие критерии).

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

Предполагается, что пользователи настоящего стандарта хорошо знакомы с требованиями ИСО/МЭК 15408-1 и, в частности, с приложениями В и С к нему, в которых приведено описание ПЗ и ЗБ. Авторам ПЗ и ЗБ, конечно, следует быть хорошо знакомыми с другими стандартами комплекса ИСО/МЭК 15408, включая введение, например, с парадигмой функциональных требований, описанной в ИСО/МЭК 15408-2 (подраздел 1.3).

Настоящий стандарт представляет собой информационный технический отчет ИСО, предназначенный для использования только в качестве руководства. По своему содержанию и структуре его не следует рассматривать как стандарт для оценки ПЗ и ЗБ. Предполагается, что настоящий стандарт полностью соответствует ИСО/МЭК 15408; тем не менее, в случае любого несоответствия между настоящим стандартом и ИСО/МЭК 15408 последнему в качестве нормативного следует отдавать предпочтение.

В настоящем стандарте не рассматриваются такие вопросы, как регистрация ПЗ и связанные с этим задачи — обращение с защищаемой интеллектуальной собственностью (например, патентами) в ПЗ. Информацию по регистрации ПЗ см. в [1].

2    Нормативные ссылки

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

ИСО/МЭК 2382-8:1998 Информационная технология — Словарь — Часть 8: Безопасность

ИСО/МЭК 15408-1 —2008 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационныхтехнологий. Часть 1. Введение и общая модель

ИСО/МЭК 15408-2—2008 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационныхтехнологий. Часть 2. Функциональные требования безопасности

ИСО/МЭК 15408-3—2008 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационныхтехнологий. — Часть 3. Требования доверия к безопасности

Издание официальное

3 Термины и определения

В настоящем стандарте применены термины по ИСО/МЭК 15408-1.

4 Сокращения

В настоящем стандарте применяются сокращения, приведенные в ИСО/МЭК 15408-1, подраздел 2.3,

политика безопасности организации; система управления базами данных; требование доверия к безопасности; функциональное требование безопасности; запрос предложения; краткая спецификация ОО; третья доверенная сторона.

5 Цель

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

В остальных приложениях приводятся примеры, иллюстрирующие применение настоящего стандарта.

Разделы 1—4 содержат вводные и ссылочные материалы.

Раздел 5 содержит цели и направленности настоящего стандарта.

Раздел 6 содержит краткий обзор ПЗ и ЗБ, который включает в себя оглавления и отображает содержание, а также потенциальных пользователей различных частей ПЗ или ЗБ. Данный раздел содержит, а также комментирует соотношение между ПЗ и ЗБ и проблемы, связанные с процессом их разработки.

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

Разделы 8—13 придерживаются той структуры ПЗ и ЗБ, которая установлена в ИСО/МЭК 15408-1 (см. приложение В, рисунок В.1, приложение С, рисунок С.1).

Раздел 8 представляет собой руководство по определению среды безопасности ОО в ПЗ и ЗБ в виде исходных «потребностей в безопасности» ОО.

Раздел 9 представляет собой руководство по определению и спецификации целей безопасности в ПЗ или ЗБ в соответствии со сформулированными ранее исходными «потребностями в безопасности». Оба этих раздела представляют интерес не только для авторов ПЗ и ЗБ, но также и для других лиц — пользователей ПЗ и ЗБ.

Раздел 10 представляет собой руководство по выбору и спецификации требований безопасности ин-формационныхтехнологий в ПЗ. В данном разделе подробно описывается использование функциональных компонентов и компонентов доверия к безопасности в соответствии с требованиями стандартов серии ИСО/МЭК 15408, а также компонентов, не предусмотренных стандартами серии ИСО/МЭК 15408, для обеспечения более точного определения требований безопасности ИТ.

Разделы 11 и 12 представляют собой руководство по разработке ЗБ в части краткой спецификации ОО и утверждений о соответствии ПЗ. Разделы 10—13 будут в основном представлять интерес для авторов и оценщиков ПЗ и ЗБ.

Раздел 13 представляет собой руководство по составлению и представлению разделов «Обоснование» в ПЗ и ЗБ.

В разделе 14 рассматриваются проблемы разработки ПЗ и ЗБ для сложных ОО, то есть ОО, состоящих из двух или более ОО-компонентов, для каждого из которых имеются собственные ПЗ и ЗБ.

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

ГОСТ Р ИСО/МЭК Т015446 — 2008

Как упоминалось выше, в приложении А руководство вкратце представлено в виде инструкции. Примеры угроз, политики безопасности организации, предположений и целей безопасности представлены в приложении В, которое также устанавливает соответствие между общими функциональными требованиями и соответствующими функциональными компонентами из стандартов серии ИСО/МЭК 15408. Предполагается, что эти примеры являются достаточно широкомасштабными, но не исчерпывающими.

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

Возможности применения настоящего стандарта при разработке ПЗ и ЗБ для различных типов ОО представлены в приложениях D — F. Так, в приложении D рассмотрена возможность использования настоящего стандарта при разработке ПЗ и ЗБ для межсетевых экранов, в приложении Е — для СУБД, в котором подчеркивается особая важность решения вопросов, связанных с ИТ-средой. В приложении F рассматриваются вопросы, связанные с разработкой ПЗ для третьей доверенной стороны (ТДС).

6 Краткий обзор профилей защиты и заданий по безопасности

6.1    Введение

В настоящем разделе приводится краткий обзор и содержание ПЗ и ЗБ. Рассматриваются взаимосвязи между ПЗ и ЗБ и процесс их разработки (см. также ИСО/МЭК 15408-1, приложения В и С).

6.2    Содержание профилей защиты и заданий по безопасности

Требуемое содержание ПЗ и ЗБ приведено в ИСО/МЭК 15408-1, приложение В. Пример содержания ПЗ представлен ниже:

1    Введение ПЗ

1.1    Идентификация ПЗ

1.2    Аннотация ПЗ

2    Описание ОО

3    Среда безопасности ОО

3.1    Предположения безопасности

3.2    Угрозы

3.3    Политика безопасности организации

4    Цели безопасности

4.1    Цели безопасности для ОО

4.2    Цели безопасности для среды

5    Требования безопасности ИТ

5.1    Функциональные требования безопасности ОО

5.2    Требования доверия к безопасности ОО

5.3    Требования безопасности для ИТ-среды

6    Замечания по применению

7    Обоснование

7.1    Обоснование целей безопасности

7.2    Обоснование требований безопасности.

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

В раздел «Описание ОО» включают сопроводительную информацию об ОО (или типе ОО), предназначенную для пояснения его назначения и требований безопасности.

В раздел ПЗ «Среда безопасности ОО» включают описание аспектов среды безопасности ОО, которые должны учитываться для объекта оценки, в частности —детальное описание предположений безопасности, определяющих границы среды безопасности, угроз активам, требующим защиты (включая описание этих активов), и ПБОр, которой должен соответствовать ОО. Этот раздел ПЗ более подробно рассмотрен в разделе 8.

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

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

3

аппаратного и аппаратного обеспечения ИТ-среды ОО. Требования безопасности ИТ должны быть определены путем использования, где возможно, функциональных компонентов и компонентов доверия к безопасности в соответствии с ИСО/МЭК15408-2 и ИСО/МЭК15408-3. Раздел ПЗ «Требования безопасности ИТ» более подробно рассмотрен в разделе 10.

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

В разделе ПЗ «Обоснование» демонстрируется то, что ПЗ специфицирует полную и взаимосвязанную совокупность требований безопасности ИТ и соответствующий ОО учитывает идентифицированные аспекты среды безопасности. Раздел ПЗ «Обоснование» более подробно рассмотрен в разделе 12.

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

a)    раздел «Введение ПЗ» может включать в себя подраздел, описывающий организацию ПЗ, а также ссылки на другие ПЗ и другие документы;

b)    раздел «Среда безопасности ОО» может включать в себя отдельные подразделы для различных доменов в ИТ-среде для ОО;

c)    раздел «Требования безопасности ИТ» может быть расширен за счет включения, где необходимо, требований безопасности для не ИТ-среды.

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

Содержание ЗБ приведено в ИСО/МЭК 15408-1, приложение С. Пример содержания ЗБ представлен в таблице 2.

В разделе «Введение ЗБ» идентифицируется ЗБ и ОО (включая номер версии) и приводится аннотация ЗБ в форме, наиболее подходящей для включения в перечень оцененных (сертифицированных) продуктов ИТ. Раздел «Введение ЗБ» более подробно рассмотрен в разделе 7.

В раздел ЗБ «Описание ОО» включают сопроводительную информацию об ОО, предназначенную для пояснения его назначения и требований безопасности. Раздел ЗБ «Описание ОО» должен также включать в себя описание конфигурации, в которой ОО подлежит оценке. Раздел ЗБ «Описание ОО» более подробно рассмотрен в разделе 7.

В раздел ЗБ «Среда безопасности ОО» включают описание аспектов среды безопасности ОО, которые должны учитываться объектом оценки, в частности, предположений безопасности, определяющих границы среды безопасности, угроз активам, требующим защиты (включая описание этих активов), ПБОр, которой должен соответствовать ОО. Раздел ЗБ «Среда безопасности ОО» более подробно рассмотрен в разделе 8.

Пример содержания задания по безопасности представлен ниже:

1.1    Идентификация ЗБ

1.2    Аннотация ЗБ

2    Описание ОО

3    Среда безопасности ОО

3.1    Предположения безопасности

3.2    Угрозы

3.3    Политика безопасности организации

4    Цели безопасности

4.1    Цели безопасности для ОО

4.2    Цели безопасности для среды ОО

5    Требования безопасности ИТ

5.1    Функциональные требования безопасности ОО

5.2    Требования доверия к безопасности ОО

5.3    Требования безопасности для ИТ-среды

6    Краткая спецификация ОО

6.1    Функции безопасности ОО

6.2    Меры обеспечения доверия к безопасности

4

ГОСТ Р ИСО/МЭК Т015446 — 2008

7    Утверждения о соответствии ПЗ

7.1    Ссылка на ПЗ

7.2    Уточнение ПЗ

7.3    Дополнение ПЗ

8    Обоснование

8.1    Обоснование целей безопасности

8.2    Обоснование требований безопасности

8.3    Обоснование краткой спецификации ОО

8.4    Обоснование утверждений о соответствии ПЗ.

В раздел ЗБ «Цели безопасности» включают краткое изложение предполагаемой реакции на аспекты среды безопасности как сточки зрения целей безопасности, которые должны соответствовать 00, таки с точки зрения целей безопасности, которые должны соответствовать ИТ- и не ИТ-мерам в пределах среды 00. Данный раздел ЗБ более подробно рассмотрен в разделе 9.

В раздел ЗБ «Требования безопасности ИТ» включают функциональные требования безопасности ОО, требования доверия к безопасности, а также требования безопасности программного, программноаппаратного и аппаратного обеспечения ИТ-среды 00. Требования безопасности ИТ должны быть определены путем использования, где это возможно, функциональных компонентов и компонентов доверия к безопасности в соответствии с ИСО/МЭК 15408-2 и ИСО/МЭК 15408-3. Раздел ЗБ «Требования безопасности ИТ» более подробно рассмотрен в разделе 10.

В раздел «Краткая спецификация ОО» включают описание функций безопасности ИТ, реализуемых ОО и соответствующих специфицированным функциональным требованиям безопасности, а также любых мер доверия к безопасности, соответствующих специфицированным требованиям доверия к безопасности. Раздел ЗБ «Краткая спецификация 00» более подробно рассмотрен в разделе 11.

В разделе «Утверждения о соответствии ПЗ» идентифицируются ПЗ, о соответствии которым заявляется в ЗБ, а также любые дополнения или уточнения целей или требований из этих ПЗ. Раздел ЗБ «Утверждения о соответствии ПЗ» более подробно рассмотрен в разделе 13.

В разделе ЗБ «Обоснование» демонстрируют, что ЗБ специфицирует полную и взаимосвязанную совокупность требований безопасности ИТ, соответствующий ОО учитывает определенные аспекты среды безопасности ИТ и функции безопасности ИТ и меры доверия к безопасности соответствуют требованиям безопасности ОО. Раздел ЗБ «Обоснование» более подробно рассмотрен в разделе 13.

Как и для ПЗ (см. 6.1) при разработке ЗБ допускается отступать от вышеуказанной структуры путем включения дополнительных и исключения необязательных разделов (и/или подразделов) ЗБ.

6.3    Взаимосвязь между профилями защиты и заданиями по безопасности

При сопоставлении таблиц 1 и 2 становится очевидной взаимосвязь между ПЗ и ЗБ вследствие высокой степени общности данных документов, в особенности разделов «Среда безопасности ОО», «Цели безопасности», «Требования безопасности ИТ» и, частично, — раздела «Обоснование». Если в ЗБ утверждается о соответствии ПЗ и при этом не специфицируются дополнительные функциональные требования и требования доверия к безопасности, то содержание упомянутых выше разделов ЗБ может быть идентично содержанию соответствующих разделов ПЗ. В таких случаях рекомендуется ссылка в ЗБ на содержание ПЗ сдобавлением (там, где необходимо) деталей, отличающих ЗБ от ПЗ.

Следующие разделы ЗБ не имеют аналогов в ПЗ и, таким образом, являются специфичными для ЗБ:

a)    раздел «Краткая спецификация ОО» — включает в себя функции безопасности ИТ, механизмы и способы обеспечения безопасности, а также меры доверия к безопасности;

b)    раздел «Утверждения о соответствии ПЗ» — мотивирует и детализирует требования соответствия ПЗ;

c)    подразделы раздела «Обоснование»—демонстрируют адекватность функций безопасности ИТ и мер доверия к безопасности требованиям безопасности ОО.

6.4    Учет информационных потребностей потенциальных пользователей профилей защиты и заданий по безопасности

В ПЗ и ЗБ необходимо учитывать следующие информационные потребности потенциальных пользователей этихдокументов:

-    потребители (дистрибуторы и покупатели) нуждаются в информации, дающей общее представление о том, какОО решает проблемы безопасности;

-    разработчики нуждаются в однозначном понимании требований безопасности с тем, чтобы создавать (формировать) соответствующие ОО;

5