ГОСТ Р 57628-2017 Информационная технология (ИТ). Методы и средства обеспечения безопасности. Руководство по разработке профилей защиты и заданий по безопасности.

ГОСТ Р 57628-2017 Информационная технология (ИТ). Методы и средства обеспечения безопасности. Руководство по разработке профилей защиты и заданий по безопасности.

ГОСТ Р 57628-2017

Группа П80

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

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

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

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

Information technology. Security techniques. Guide for the production of Protection Profiles and Security Targets

ОКС 35.240

Дата введения 2018-01-01

Предисловие

1 РАЗРАБОТАН Обществом с ограниченной ответственностью "Центр безопасности информации" (ООО "ЦБИ")

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 362 "Защита информации"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ

4 Настоящий стандарт разработан с учетом основных положений международного стандарта ISO/IEC TR 15446:2009* "Информационная технология. Методы и средства обеспечения безопасности. Руководство по разработке профилей защиты и заданий по безопасности" (ISO/IEC TR 15446:2004 "Information technology - Security techniques - Guide for the production of Protection Profiles and Security Targets", NEQ)

5 ВЗАМЕН ГОСТ Р ИСО/МЭК TO 15446-2008

Правила применения настоящего стандарта установлены в . Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

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

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

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

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

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

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

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

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

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

б) утверждение о соответствии ЗБ одному или более ПЗ (если применимо);

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

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

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

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

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

Настоящий стандарт не предназначен для использования в качестве вводного материала по оценке безопасности продуктов ИТ в соответствии с ГОСТ Р ИСО/МЭК 15408. Для получения такой информации следует использовать .

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

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

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

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

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

Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности

Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий

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

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

В настоящем стандарте применены термины по .

4 Сокращения

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

БИТ - безопасность информационных технологий;

ЗБ - задание по безопасности;

ЗИ - защита информации;

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

ИФБО - интерфейс ФБО;

НДВ - недекларированные возможности;

ОО - объект оценки;

ОПБ - определение проблемы безопасности;

ОУД - оценочный уровень доверия;

ПБОр - политика безопасности организации;

ПЗ - профиль защиты;

ПО - программное обеспечение;

РД - руководящий документ;

САВЗ - средство антивирусной защиты;

СВТ - средство вычислительной техники;

СКН - средство контроля съемных машинных носителей информации;

СОВ - система обнаружения вторжений;

СУБД - система управления базами данных;

ТДБ - требование доверия к безопасности;

ФБО - функциональные возможности безопасности ОО;

ФТБ - функциональное требование безопасности.

5 Назначение и структура стандарта

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

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

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

Предполагается, что настоящий стандарт полностью соответствует ГОСТ Р ИСО/МЭК 15408, тем не менее в случае любого несоответствия между настоящим стандартом и ГОСТ Р ИСО/МЭК 15408 последнему в качестве нормативного следует отдавать предпочтение.

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

В разделе 5 приведен обзор структуры и назначения настоящего стандарта.

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

В разделах 7-13 приведена информация по спецификации обязательных разделов ПЗ или ЗБ согласно структуре ПЗ и ЗБ, установленной в разделах А.2 и В.2 .

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

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

В приложении А приведен пример определения расширенного (по отношению к ) компонента.

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

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

6.1 Введение

В данном разделе приведен краткий обзор роли ПЗ и ЗБ в процессе оценки безопасности продуктов ИТ в соответствии с комплексом стандартов ГОСТ Р ИСО/МЭК 15408.

6.2 Целевая аудитория

Настоящий стандарт предназначен для использования следующими категориями пользователей:

а) специалистами ИТ, обладающими знаниями в области защиты информации (например, ответственными за защиту информации или архитекторами по вопросам защиты информации, у которых есть знание и понимание требований безопасности), но которые не являются экспертами в области оценки безопасности продуктов ИТ и не имеют предварительных знаний по ГОСТ Р ИСО/МЭК 15408;

б) экспертами в области защиты информации, которые обладают хорошим знаниями ГОСТ Р ИСО/МЭК 15408 и занимаются разработкой ПЗ и ЗБ в рамках профессиональной деятельности.

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

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

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

6.3 Использование профилей защиты и заданий по безопасности

6.3.1 Введение

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

В качестве примера системы ИТ можно, например, привести средства контроля отчуждения (переноса) информации со съемных машинных носителей информации, в состав которых входят следующие компоненты, распределенные по компонентам информационной системы или сами являющиеся законченными изделиями:

- специализированные съемные машинные носители информации;

- программное обеспечение инициализации;

- программное обеспечение управления;

- программное обеспечение взаимодействия со съемными машинными носителями информации.

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

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

В ГОСТ Р ИСО/МЭК 15408 приведены стандартизированные спецификации безопасности для (помимо прочего):

- определения специфического контента, необходимого для оценки продукта ИТ на соответствие спецификации безопасности;

- создания условий для сравнения спецификаций безопасности различных продуктов ИТ.

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

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

Когда заказчику необходимо приобрести продукт ИТ, у него фактически имеются две возможности:

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

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

Процесс приобретения усложняется необходимостью учитывать вопросы безопасности ИТ. Среднестатистическому заказчику достаточно сложно:

- определить, какой уровень безопасности ИТ (функционал безопасности ИТ, класс защиты и т.п.) ему необходим;

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

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

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

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

6.3.2 Процесс приобретения на основе спецификации

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

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

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

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

в) разработчик должен создать (разработать) продукт ИТ на основе данной спецификации.

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

6.3.2.2 Неформализованные требования безопасности

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

ГОСТ Р ИСО/МЭК 15408 предполагает, что заказчик способен определить неформализованные требования безопасности. Если неформализованные требования будут определены неправильно, то приобретаемый продукт ИТ может не отвечать фактически существующим требованиям безопасности.

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

а) неполными (присутствуют не все требования). Например, могут быть не рассмотрены важные угрозы, которым должен противостоять продукт;

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

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

г) не пригодными для тестирования: требования могут быть сформулированы неоднозначным образом, из-за чего не представляется возможным верифицировать, соответствует ли продукт ИТ требованиям;

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

е) насыщенными расплывчатыми формулировками: например, в требованиях может быть указано, что связь должна осуществляться по защищенным каналам, при этом нет определения того, что считать "защищенным" каналом;

ж) несогласованными: требования могут быть внутренне противоречивыми.

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

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

6.3.2.3 Использование профилей защиты в качестве спецификаций

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

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

а) будет однозначно интерпретируемым: в языке ГОСТ Р ИСО/МЭК 15408 содержатся полные и однозначные определения терминов, достаточные для того, чтобы разработчик мог понять требования и правильно их интерпретировать;

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

в) не будет излишне детализированным: язык ГОСТ Р ИСО/МЭК 15408 обеспечивает определенный уровень абстракции, необходимый для выражения требований заказчика;

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

6.3.2.4 Разработка продукта по профилю защиты

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

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

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

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

- задание по безопасности может быть более детализированным, чем ПЗ: если в ПЗ объясняется, "что" должно быть защищено, то в ЗБ указывается и "каким образом": разработчик обобщенно излагает, каким образом он реализует требования заказчика.

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

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

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

6.3.2.5 Роль оценки в процессе приобретения на основе спецификации

В предыдущих пунктах были рассмотрены только роли заказчика и разработчика. Разработчик может просто заявить заказчику (без представления дополнительных свидетельств - документированных материалов), что:

а) ЗБ соответствует ПЗ;

б) продукт ИТ соответствует ЗБ;

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

Если заказчик принимает эти утверждения, процесс завершается.

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

а) ЗБ соответствует ПЗ;

б) продукт ИТ соответствует ЗБ.

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

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

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

6.3.3 Процесс приобретения на основе выбора

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

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

В процессе приобретения продукта ИТ на основе выбора:

а) разработчик должен создать (разработать) продукт ИТ, разработать спецификацию продукта и предоставить спецификацию заказчику;

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

6.3.3.2 Использование предоставленной разработчиком спецификации

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

Если эта спецификация представлена в неформальном стиле изложения, для нее характерны те же перечисленные в 6.3.2.2 потенциально возможные недостатки, что и для неформализованных требований заказчиков. По этой причине спецификация разработчика также подлежит формализации. Для этой цели в ГОСТ Р ИСО/МЭК 15408 используется задание по безопасности (ЗБ), как отмечалось ранее в 6.3.2.4. Задание по безопасности в данном случае используется аналогично описанию использования ЗБ в 6.3.2.4, с одной очевидной разницей: поскольку оно не основано на ПЗ заказчика, нельзя утверждать о соответствии ЗБ такому профилю защиты (но можно утверждать о соответствии другим ПЗ - см. 6.3.4).

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

Разработчик создает (разрабатывает) свой продукт в соответствии с ЗБ: этот процесс аналогичен процессу приобретения на основе спецификации.

6.3.3.3 Сравнение заданий по безопасности разных разработчиков

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

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

6.3.3.4 Роль оценки в процессе приобретения на основе выбора

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

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

Следует отметить, что при использовании оцененных (сертифицированных) продуктов два вопроса по-прежнему останутся открытыми:

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

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

6.3.4 Другие возможности использования профилей защиты

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

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

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

Примерами таких профилей защиты являются профили защиты ФСТЭК России для средств контроля отчуждения (переноса) информации со съемных машинных носителей информации, средств доверенной загрузки уровня базовой системы ввода-вывода и другие.

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

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

а) первоначальное определение проблемы безопасности;

б) идентификация целей безопасности, направленных на решение проблемы безопасности;

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

г) выбор конкретных функциональных возможностей безопасности, направленных на выполнение требований безопасности.

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

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

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

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

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

г) корректировку проблемы безопасности для ОО вследствие изменения предполагаемого потенциала нападения нарушителя.

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

6.5 Вопросы восприятия и понимания профилей защиты и заданий по безопасности

6.5.1 Введение

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

Для детального понимания содержания ПЗ и ЗБ следует изучить , в частности приложения А и В, в которых представлена детальная информация относительно заданий по безопасности и профилей защиты соответственно. Также необходимо изучить опубликованные ПЗ и ЗБ, находящиеся в открытом доступе. Профили защиты, выпущенные ФСТЭК России для целого ряда видов и типов средств защиты информации (например, средств антивирусной защиты, систем обнаружения вторжений, средств доверенной загрузки, средств контроля использования съемных машинных носителей информации, межсетевых экранов), представлены на официальном сайте ФСТЭК России (www.fstec.ru). Существует целый ряд международных реестров, из которых можно получить ПЗ и ЗБ. Самым известным является портал Common Criteria ("Общие критерии") [1]. Этот реестр признан ИСО и МЭК в качестве официального реестра JTC 1 для профилей защиты и пакетов, сформированных в соответствии с ГОСТ Р ИСО/МЭК 15408. Он функционирует в соответствии с [2].

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

К таким подразделам относятся:

а) "Аннотация ОО";

б) "Описание ОО";

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

г) "Утверждения о соответствии".

6.5.2 Подраздел "Аннотация ОО"

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

а) использование и основные характеристики безопасности ОО;

б) тип ОО;

в) требуемые аппаратные средства/программное обеспечение/программно-аппаратные средства, не входящие в ОО.

Простые примеры изложения этих пунктов приведены в , пункт А.4.2.

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

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

Ниже приведен фрагмент содержания пункта "Описание использования и основных характеристик безопасности ОО" на примере профиля защиты ФСТЭК России для средств контроля подключения съемных машинных носителей информации [3].

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

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

В состав средства контроля подключения съемных машинных носителей информации (СКН) входят следующие компоненты:

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

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

В СКН должны быть реализованы следующие функции безопасности:

- разграничение доступа к управлению СКН;

- управление работой СКН;

- управление параметрами СКН;

- контроль подключения съемных машинных носителей информации;

- аудит безопасности СКН;

- сигнализация СКН.

В среде, в которой СКН функционирует, должны быть реализованы следующие функции безопасности среды:

- физическая защита средств вычислительной техники, на которых используются компоненты СКН;

- обеспечение условий безопасного функционирования СКН;

- управление атрибутами безопасности компонентов СКН.

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

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

- функциональные требования безопасности;

- требования доверия к безопасности.

Функциональные требования безопасности СКН, изложенные в ПЗ, включают:

- требования к разграничению доступа к управлению СКН;

- требования к управлению работой (режимами выполнения функций безопасности) СКН;

- требования к управлению параметрами СКН, которые влияют на выполнение функций безопасности СКН;

- требования к контролю подключения съемных машинных носителей информации;

- требования по предупреждению о событиях, связанных с нарушением безопасности;

- требования к аудиту безопасности СКН.

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

- реализация политики управления использованием подключаемых съемных машинных носителей информации по отношению к подключаемым произвольным съемным машинным носителям информации;

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

- возможность со стороны администраторов СКН управлять данными (данными средства контроля подключения съемных машинных носителей информации), используемыми функциями безопасности средства контроля подключения съемных машинных носителей информации;

- поддержка определенных ролей для средства контроля подключения съемных машинных носителей информации и их ассоциации с конкретными администраторами СКН и пользователями информационной системы;

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

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

- возможность чтения информации из записей аудита уполномоченным администраторам СКН;

- возможность реагирования при обнаружении событий, указывающих на возможное нарушение безопасности;

- возможность выборочного просмотра данных аудита.

Требования доверия к безопасности средств контроля подключения съемных машинных носителей информации сформированы на основе компонентов требований .

В целях обеспечения условий для безопасного функционирования СКН в настоящем ПЗ определены цели и требования для среды функционирования СКН".

В пункте "Тип ОО" приводится описание общей категории продуктов ИТ, к которым относится ОО (например, операционная система, межсетевой экран, средство антивирусной защиты, средство обнаружения вторжений, средство доверенной загрузки и т.д.).

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

- средства контроля подключения съемных машинных носителей информации;

- средства контроля отчуждения (переноса) информации со съемных машинных носителей информации.

Ниже приведен фрагмент содержания пункта "Тип ОО" на примере профиля защиты ФСТЭК России для средств контроля подключения съемных машинных носителей информации.

"Объектом оценки в настоящем ПЗ является средство контроля подключения съемных машинных носителей информации.

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

- проверка наличия разрешения или запрета на использование интерфейса ввода (вывода) средства вычислительной техники при попытке подключения съемного машинного носителя информации;

- проверка наличия разрешения или запрета на использование соответствующего типа подключаемых внешних программно-аппаратных устройств при наличии разрешения (отсутствия запрета) на использование интерфейса ввода (вывода) средства вычислительной техники;

- проверка наличия разрешения или запрета на подключение конкретного съемного машинного носителя информации при наличии разрешения (отсутствия запрета) на подключение соответствующего типа внешних программно-аппаратных устройств;

- разрешение или запрет использования подключаемого съемного машинного носителя информации по результатам выполненных проверок;

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

В ГОСТ Р ИСО/МЭК 15408 также установлено, что в "Аннотации ОО" перечисляются любые обоснованные ожидания, которые могут иметься в отношении этого типа ОО, но которые не поддерживаются ОО. В частности:

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

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

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

Если эти предупреждения предоставлены и могут влиять на предполагаемое использование продукта ИТ, то следует внимательно рассмотреть возможность использования данного ОО с этими ограничениями.

Многие ОО (особенно программные ОО) зависят от дополнительных аппаратных средств, программного обеспечения и (или) программно-аппаратных средств, не входящих в ОО. В таком случае в "Аннотации ОО" требуется идентифицировать соответствующие аппаратные средства/программное обеспечение и (или) программно-аппаратные средства, не входящие в ОО.

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

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

6.5.3 Подраздел "Описание ОО"

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

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

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

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

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

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

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

6.5.4 Цели безопасности для среды функционирования

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

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

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

6.5.5 Подраздел "Утверждение о соответствии"

"Утверждение о соответствии" обычно находится в начале ПЗ или ЗБ. В раздел обычно включается одно предложение следующего вида:

Настоящий ПЗ (настоящее ЗБ):

- соответствует ГОСТ Р ИСО/МЭК 15408;

- соответствует или является расширенным по отношению к ;

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

- соответствует или является расширенным по отношению к ;

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

- соответствует перечню пакетов, о соответствии которым утверждается для ОО*;

Наиболее распространенным является использование пакета ОУД1, ОУД2, ..., ОУД6 или ОУД7, часто с пометкой "усиленный" и (или) "расширенный". Более подробно ОУД рассмотрены в 6.5.7.

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

Более подробно это соответствие рассмотрено в 6.5.6.

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

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

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

В ПЗ может содержаться утверждение о "строгом" или "демонстрируемом" соответствии ПЗ или ЗБ.

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

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

В профилях защиты, утвержденных ФСТЭК России, устанавливаются следующие типы соответствия рассматриваемому ПЗ при разработке ЗБ на основе данного ПЗ:

- "строгое" соответствие - если рассматриваемый ПЗ является единственным ПЗ, утверждение о соответствии которому включено в ЗБ;

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

6.5.7 Оценочные уровни доверия и другие вопросы доверия

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

- билет на некоторое число поездок в транспорте;

- кредитная карта с кредитным лимитом в 500000 рублей;

- средство контроля доступа на объект.

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

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

В ГОСТ Р ИСО/МЭК 15408 качество, которое дает основу для уверенности в том, что продукт ИТ отвечает целям безопасности, называется "доверие". Согласно ГОСТ Р ИСО/МЭК 15408 доверие оценивается с использованием активного исследования многих аспектов разработки продукта: процессов разработки и производства, проектов, руководств, объема испытаний (тестов), выполненных разработчиком продукта ИТ, и др.

ГОСТ Р ИСО/МЭК 15408 систематизирует доверие по двадцати семи категориям (так называемым "семействам доверия"). В каждой такой категории ГОСТ Р ИСО/МЭК 15408 определяет различные уровни соответствия.

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

- "0": неизвестно, выполнял ли разработчик тестирование продукта;

- "1": разработчик выполнил некоторое число тестов по отношению к отдельным интерфейсам продукта ИТ;

- "2": разработчик выполнил некоторое число тестов по отношению ко всем интерфейсам продукта ИТ;

- "3": разработчик выполнил очень большое число тестов по отношению ко всем интерфейсам продукта ИТ.

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

Для лица, не являющегося экспертом в области защиты информации, достаточно сложно правильно интерпретировать систему показателей, состоящую из индивидуальных показателей для всех двадцати семи категорий. Для того чтобы позволить лицам, не являющимся экспертами в области защиты информации, оценить доверие к продукту ИТ, в ГОСТ Р ИСО/МЭК 15408 имеются семь предопределенных уровней, называемых оценочными уровнями доверия (ОУД). Им присвоены идентификаторы по порядку от ОУД1 до ОУД7, где ОУД1 является самым низким уровнем доверия, а ОУД7 - самым высоким.

Каждый ОУД можно рассматривать как набор из двадцати семи чисел, по одному числу на каждую подкатегорию. Например, ОУД1 присваивает "1" тринадцати подкатегориям и "0" - остальным четырнадцати, в то время как ОУД2 присваивает "2" семи подкатегориям, "1" - одиннадцати подкатегориям, а оставшимся девяти - "0".

Все ОУД являются строго иерархическими, то есть если ОУД (n) присваивает определенный рейтинг доверия определенной подкатегории, то в ОУД (n+1) этой подкатегории будет присвоен такой же или более высокий рейтинг. Таким образом, ОУД (n+1) обеспечивает в целом больший уровень доверия, чем ОУД (n).

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

В профилях защиты, утвержденных ФСТЭК России, оценочные уровни доверия используются с дополнениями:

- усиливаются компонентами не использовавшейся в данном ОУД категории (семейства);

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

- расширяются с использованием компонентов, не входящих в , то есть расширенных (специальных) компонентов.

При этом итоговые наборы требований доверия (усиленные и расширенные ОУД) применяются для соответствующих классов защиты, устанавливаемых в нормативных правовых актах ФСТЭК России. Типовой состав компонентов доверия в зависимости от класса защиты средств защиты информации представлен в 12.4.1.

7 Спецификация раздела "Введение" в профилях защиты и заданиях по безопасности

В данном разделе представлены рекомендации по спецификации раздела "Введение" в ПЗ и ЗБ.

"Введение" в ПЗ состоит из следующих элементов:

а) ссылка на ПЗ;

б) аннотация ОО.

"Введение" в ЗБ состоит из следующих элементов:

а) ссылка на ЗБ;

б) ссылка на ОО;

в) аннотация ОО;

г) описание ОО.

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

Разработчикам ПЗ или ЗБ проще всего окончательно оформить раздел "Введение" после того, как будут написаны остальные разделы ПЗ или ЗБ.

В (подразделы А.4 и В.4) вопросы разработки раздела "Введение" в ПЗ и ЗБ рассматриваются достаточно подробно.

8 Спецификация раздела "Утверждения о соответствии"

В данном разделе представлены рекомендации по спецификации раздела "Утверждения о соответствии" в ПЗ или ЗБ. Раздел ЗБ "Утверждения о соответствии" описывается в (подраздел А.5), а отличия раздела ПЗ "Утверждения о соответствии" от аналогичного раздела ЗБ описываются в (подраздел В.5).

В разделе "Утверждения о соответствии" в ПЗ или ЗБ описывается соответствие профиля защиты или задания по безопасности:

а) ГОСТ Р ИСО/МЭК 15408. В текст раздела включается указание точной редакции ГОСТ Р ИСО/МЭК 15408, которая была использована для разработки (и, возможно, также для оценки) ПЗ или ЗБ. Если использовался отличный от национального стандарта ГОСТ Р ИСО/МЭК 15408 перевод ISO/IEC 15408 (например, РД БИТ [5]), это также должно быть указано. Если были использованы редакции ГОСТ Р ИСО/МЭК 15408 с какими-либо внесенными исправлениями или иные сопутствующие документы, информация об этом должна быть указана;

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

в) пакетам требований безопасности. В текст раздела включается перечисление пакетов требований безопасности, на которые даны ссылки в ПЗ или ЗБ. Обычной практикой является утверждение соответствия одному из пакетов доверия (ОУД), определенному в , возможно, с усилением и расширением. Использование пакетов рассмотрено далее в 15.3. В данном случае также просто достаточно списка; приводить дополнительную информацию в данном разделе не требуется.

Указанные утверждения также применимы к ОО, основанному на соответствующем ПЗ или ЗБ.

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

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

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

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

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

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

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

В ПЗ, утвержденных ФСТЭК России, принят следующий подход к определению типов соответствия при разработке ЗБ и (или) других ПЗ на основе утвержденного профиля защиты:

- требуется "строгое" соответствие профилю защиты - если рассматриваемый ПЗ является единственным ПЗ, утверждение о соответствии которому включено в ЗБ;

- допускается "демонстрируемое" соответствие профилю защиты - если ОО является комплексным продуктом (изделием) и в ЗБ включено утверждение о соответствии (помимо рассматриваемому ПЗ) другому (другим) ПЗ.

В настоящее время действуют различные типы нормативных и методических документов ФСТЭК России, определяющие требования к средствам защиты информации:

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

- нормативные правовые акты и профили защиты (например, для средств антивирусной защиты, систем обнаружения вторжения, средств доверенной загрузки), разработанные в соответствии с редакцией ГОСТ Р ИСО/МЭК 15408 (2008 г.);

- руководящие документы ФСТЭК (Гостехкомиссии) России, такие как "Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации" (1992 г.), "Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля недекларированных возможностей" (1999 г.);

- другие документы, определяющие в том числе требования к техническим мерам и средствам защиты информации, такие как "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах" [6], "Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных" [7], "Требования к обеспечению защиты информации в автоматизированных системах управления производственными и технологическими процессами на критически важных объектах, потенциально опасных объектах, а также объектах, представляющих повышенную опасность для жизни и здоровья людей и для окружающей природной среды" [8].

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

При этом целесообразно руководствоваться следующими правилами:

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

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

2) При необходимости соответствия ПЗ разным редакциям ГОСТ Р ИСО/МЭК 15408 требования доверия к безопасности в ЗБ можно определить следующим способом.

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

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

Затем в ЗБ следует добавить в пакет доверия требования доверия (расширенные компоненты, уточнения стандартных компонентов) из ПЗ, разработанного по предыдущей редакции ГОСТ Р ИСО/МЭК 15408, для отражения специфики доверия к соответствующим механизмам ЗИ. Для приведенного выше примера с ПЗ для САВЗ и ПЗ для СКН в состав требований доверия в ЗБ комплексного изделия необходимо включить компоненты доверия ALC_UPV_EXT.1 "Процедуры обновления базы данных признаков вредоносных компьютерных программ (вирусов)" и AMA_SIA_EXT.3 "Анализ влияния обновлений на безопасность средства антивирусной защиты" из ПЗ для САВЗ (по ГОСТ Р ИСО/МЭК 15408-2008);

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

9 Спецификация раздела "Определение проблемы безопасности"

9.1 Введение

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

Целью определения проблемы безопасности является формализованное определение характера и масштаба проблемы безопасности, которую должен решать ОО (см. рисунок 1).

Рисунок 1 - Определение проблемы безопасности

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

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

Если проблема определена неправильно или описана нечетко, то остальные части ПЗ или ЗБ также будут являться неправильными. Что еще хуже, на основании технически правильной, но неподходящей спецификации может быть выбран или приобретен продукт не тот, который нужен. Поэтому в настоящем стандарте раздел 9 является одним из самых объемных и наиболее подробных, хотя описанным в нем критериям в ГОСТ Р ИСО/МЭК 15408 отведено только две или три страницы текста. Для разработчика и для заказчика независимо от того, будет ли ПЗ или ЗБ использоваться в процессе приобретения на основе спецификации или в процессе приобретения на основе выбора, правильное определение проблемы безопасности имеет первостепенное значение.

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

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

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

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

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

г) документирование применимых предположений;

д) доработка и проверка спецификации определения проблемы безопасности.

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

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

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

б) разработка обоснования для прослеживания определения проблемы безопасности к неформализованным требованиям безопасности.

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

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

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

9.2 Определение неформализованных требований безопасности

9.2.1 Введение

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

9.2.2 Источники информации

9.2.2.1 Аннотация

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

9.2.2.2 Требуемые функциональные возможности

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

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

9.2.2.3 Оценка риска

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

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

9.2.2.4 Оценка угроз

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

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

9.2.2.5 Политика руководства

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

9.2.2.6 Презентационная политика

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

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

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

9.2.2.7 Политика оценки

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

9.2.3 Документирование неформализованных требований

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

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

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

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

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

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

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

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

б) атрибуты безопасности или характеристики безопасности, которыми должен обладать продукт ИТ;

в) атрибуты или характеристики безопасности, которые не являются необходимыми для продукта ИТ.

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

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

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

9.3.1 Введение

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

Анализ и спецификация угроз обычно являются более сложными и трудными, чем определение политики и предположений, поэтому целесообразнее проводить их в первую очередь. С другой стороны, если неформализованные требования были в основном получены как производные от решений по поводу политик или предписанных требований (см. 9.2), то может быть проще вначале разработать проект политик и предположений (см. 9.4 и 9.5), затем выполнить описываемый в данном разделе анализ угроз, пересмотреть и завершить разработку политик и предположений. Если политики и предположения могут быть легко идентифицированы, в таком случае они могут быть использованы для исключения угроз из дальнейшего рассмотрения, что значительно упростит анализ угроз.

Для проведения анализа угроз необходимо:

а) принять решение, какой методический подход к проведению анализа будет использоваться;

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

в) применить методический подход.

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

9.3.2 Выбор методологии анализа угроз

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

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

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

а) анализ дерева угроз;

б) поиск по базе данных угроз;

в) специальная идентификация.

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

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

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

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

В настоящее время ФСТЭК России разработана и поддерживается национальная база данных угроз безопасности информации с помещением информации на общедоступном ресурсе.

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

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

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

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

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

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

9.3.3.1 Введение

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

9.3.3.2 Источники угроз

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

а) нарушители;

б) уполномоченные пользователи;

в) привилегированные пользователи;

г) администраторы;

д) владельцы и разработчики системы.

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

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

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

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

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

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

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

9.3.3.3 Типы активов

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

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

Активы, связанные с системами ИТ, обычно относятся к одному из трех классов:

а) информационные активы;

б) процессы;

в) физические активы.

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

- данные общего характера;

- системные данные;

- специализированные базы данных;

- клиентские данные.

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

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

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

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

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

- данные конфигурации ФБО;

- база аутентификационных данных;

- записи аудита.

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

- финансовые;

- коммуникационные;

- логистические;

- производственные;

- процессы автоматизации офисной работы.

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

Применительно к системе, как правило, есть возможность идентифицировать наименования и характеристики процессов, подлежащих защите.

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

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

- важные элементы сетевой инфраструктуры;

- портативные персональные компьютеры;

- центры обработки данных.

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

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

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

9.3.3.4 Негативные действия

В ГОСТ Р ИСО/МЭК 15408 отсутствует руководство по поводу того, каким образом следует описывать негативные действия. Что касается источников угроз, лучше всего, чтобы перечень описаний негативных действий был по возможности как можно более простым. Пример простого, но при этом достаточного по области охвата перечня:

- несанкционированный доступ;

- несанкционированная передача прав доступа;

- отказ в доступе субъекту, имеющему право доступа;

- отсутствие подотчетности.

Этот простой перечень включает в себя почти все угрозы, которые могут быть выявлены на практике. Следует учесть, что иногда некоторые негативные действия могут иметь различные последствия, это следует изложить отдельно для достижения полноты и ясности изложения. Могут существовать также другие, особые типы негативных действий, которые не подпадают ни под одну из указанных выше категорий. Наличие таких негативных действий должно быть очевидным при рассмотрении неформализованных требований безопасности. Такие негативные действия также должны быть изложены отдельно.

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

9.3.4 Применение выбранного методического подхода к проведению анализа угроз

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

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

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

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

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

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

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

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

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

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

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

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

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

9.3.5 Практические рекомендации

Угрозы указывают на возможные способы совершить атаку на продукт ИТ. Поэтому их следует формулировать соответствующим образом. Целесообразнее использовать глагол "может". Например:

"Неуполномоченное лицо может попытаться получить доступ и использовать ресурсы ОО".

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

Ниже приведен пример описания угрозы безопасности на базе профиля защиты ФСТЭК России для средств контроля подключения съемных машинных носителей информации.

"Угроза-1

1. Аннотация угрозы - подключение к информационной системе внутренними и (или) внешними нарушителями незарегистрированных (неучтенных) съемных машинных носителей информации с последующей несанкционированной записью (передачей) на эти носители защищаемой информации из информационной системы.

2. Источники угрозы - внутренний нарушитель (пользователь информационной системы), внешний нарушитель (лицо, не являющееся пользователем информационной системы).

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

4. Используемые уязвимости - отсутствие или недостаточность мер контроля за использованием съемных машинных носителей информации в информационной системе.

5. Вид информационных ресурсов, потенциально подверженных угрозе - защищаемая информация, обрабатываемая в информационной системе; другие информационные ресурсы информационной системы.

6. Нарушаемые свойства безопасности информационных ресурсов - конфиденциальность.

7. Возможные последствия реализации угрозы - несанкционированное ознакомление с защищаемой информацией, обрабатываемой в информационной системе; нарушение режимов функционирования информационной системы".

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

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

Информация, указывающая на то, что угрозу можно не принимать во внимание, часто выражается неявным образом. Например:

"Предполагается, что администраторы не относятся к злонамеренным пользователям, они являются доверенными и компетентными пользователями".

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

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

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

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

9.4 Идентификация и спецификация политик

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

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

"Администраторы должны пройти аутентификацию до предоставления им доступа к каким-либо функциям или данным ОО".

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

Ниже также приведены примеры изложения политик на базе профиля защиты ФСТЭК России для средств контроля подключения съемных машинных носителей информации:

"Политика безопасности-1

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

...

Политика безопасности-4

Должен обеспечиваться контроль использования интерфейсов ввода (вывода) в СВТ при подключении съемных машинных носителей информации.

Политика безопасности-5

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

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

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

Политики используются для спецификации:

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

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

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

- уверенность в существовании конкретной угрозы отсутствует, но, несмотря на это, было принято "политическое" решение обеспечить соответствующую защиту;

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

- было принято "политическое" решение о выборе конкретного подхода для противодействия ряду соответствующих угроз.

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

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

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

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

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

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

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

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

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

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

"ОО будет размещен в месте, для которого обеспечивается физическая защита".

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

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

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

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

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

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

В ГОСТ Р ИСО/МЭК 15408 установлено, что предположения "могут быть по отношению к физическим аспектам, персоналу и аспектам связности среды функционирования" (, пункт А.6.4).

Ниже также приведены примеры предположений на базе профиля защиты ФСТЭК России для средств контроля подключения съемных машинных носителей информации:

"Предположения, связанные с физическими аспектами среды функционирования

Предположение-1

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

Предположения по отношению к аспектам связности среды функционирования

Предположение-2

Обеспечивается надежный источник меток времени для записи событий аудита безопасности СКН.

Предположение-3

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

Предположения, связанные с персоналом среды функционирования

Предположение-4

Персонал, ответственный за функционирование ОО, обеспечивает функционирование ОО в соответствии с эксплуатационной документацией".

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

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

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

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

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

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

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

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

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

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

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

9.6 Оформление раздела "Определение проблемы безопасности"

Заключительный этап формирования раздела "Определения проблемы безопасности" состоит в его окончательном оформлении и включает в себя решение следующих двух задач:

- подготовка полного перечня всех угроз, политик и предположений;

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

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

Полная версия документа доступна с 20.00 до 24.00 по московскому времени.

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

Теги документа

гост информационная безопасность гост информационная технология