Национальный стандарт РФ ГОСТ Р ИСО/МЭК ТО 19791-2008 "Информационная технология. Методы и средства обеспечения безопасности. Оценка безопасности автоматизированных систем" (утв. приказом Федерального агентства по техническому регулированию и метрологии от 18 декабря 2008 г. N 525-ст)

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

3.2 внешняя автоматизированная система (external operational system): Отдельная автоматизированная система, которая имеет связи с автоматизированной системой, являющейся объектом оценки.

3.3 управленческие меры безопасности (management controls): Меры безопасности информационной системы, направленные на менеджмент рисков и менеджмент информационной безопасности информационных систем.

Примечание - Меры безопасности - меры защиты и контрмеры.

3.4 организационные меры безопасности (operational controls): Меры безопасности информационной системы, которые, главным образом, реализуются и выполняются операторами, а не системами.

[НИСТ СП 800-53]

Примечание - Меры безопасности - меры защиты и контрмеры.

3.5 автоматизированная система (operational system): Информационная система, включая элементы, не связанные с информационной технологией, рассматриваемые с учетом условий ее эксплуатации.

3.6 остаточный риск (residual risk): Риск, который остается после обработки рисков.

[ИСО/МЭК 13335-1.2004]

3.7 риск (risk): Потенциальная возможность нанесения ущерба организации в результате реализации некоторой угрозы с использованием уязвимостей активов или группы активов организаций.

Примечание - Риск измеряется в терминах сочетания вероятности события и его последствий.

[ИСО/МЭК 13335-1:2004]

3.8 анализ рисков (risk analysis): Системный подход к определению величины риска.

[ИСО/МЭК 13335-1:2004]

3.9 оценка рисков (risk assessment): Процесс, включающий в себя идентификацию рисков, анализ рисков и оценивание рисков.

[ИСО/МЭК 13335-1:2004]

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

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

3.11 обработка рисков (risk treatment): Процесс выбора и реализации мер обеспечения безопасности (security controls) для изменения рисков.

Примечание - Адаптированный термин из ИСО/МЭК 13335-1 [1].

3.12 меры обеспечения безопасности (security controls): Управленческие, организационные и технические меры обеспечения безопасности, применяемые в информационной системе для защиты и доступности системы и ее информации.

[НИСТСП 800-53]

Примечания

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

2 Меры безопасности - меры защиты и контрмеры.

3.13 домен безопасности (security domain): Часть автоматизированной системы, которая реализует одни и те же политики безопасности.

3.14 подсистема (subsystem): Один или более компонентов автоматизированной системы, которые допускают их выполнение отдельно от остальной системы.

3.15 система как объект оценки (system target of evaluation): Автоматизированная система, которая эксплуатируется в соответствии с рекомендациями по эксплуатации, включая технические и организационные меры обеспечения безопасности, и является предметом оценки.

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

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

[НИСТ СП 800-53]

Примечание - Меры безопасности - меры защиты и контрмеры.

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

3.18 уязвимость (vulnerability): Недостатки или слабости в проекте или реализации информационной системы, включая меры обеспечения безопасности, которые могут быть преднамеренно или непреднамеренно использованы для оказания неблагоприятного воздействия на активы организации или ее функционирование.

5.1 Сущность автоматизированных систем

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

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

Автоматизированные системы обычно:

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

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

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

- состоят из значительного (даже большого) числа компонентов;

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

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

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

5.2 Обеспечение безопасности автоматизированных систем

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

Требования настоящего стандарта базируются на трехэтапном подходе к обеспечению необходимого уровня безопасности автоматизированной системы:

Концептуально этот трехэтапный процесс показан на рисунке 1.

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

Способы и методы оценки рисков находятся вне области действия настоящего стандарта. Для получения большей информации по оценке рисков см. часть 3 ИСО/МЭК 13335 [1].

Примечание - ИСО/МЭК 13335-3 [2] является техническим отчетом. После опубликования международного стандарта ИСО/МЭК 27005 [5] он заменит ИСО/МЭК 13335 [1], [2], [3], [4].

Способы и модели атестации являются прерогативой менеджмента и находятся вне области действия настоящего стандарта. Для получения большей информации об одном возможном из подходов см. [6].

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

В целом расширения стандартов серии ИСО/МЭК 15408 в рамках настоящего стандарта включают в себя (но не ограничиваются):

        Оценивание рисков

       /---------------------------------------\

       |           Идентификация рисков.       |

       |             Анализ рисков.            |

       |             Оценка рисков             |

       \---------------------------------------/

                            |

/-- - - - - - - - - - - - - - - - - - - - - - - - - -  - - - - - - - \

                                                                     |

|       Выбор мер безопасности

       /---------------------------------------\                     |

|      |  Выбор мер безопасности в задании по  |

       |    безопасности для системы (ЗБС)     |                     |

|      \---------------------------------------/

                                                                     |

|       Применение мер безопасности                                  |

       /---------------------------------------\                     |

|      |    Применение мер безопасности по     |Уменьшение рисков

       |отношению к системе как объекту оценки |(область применения  |

|      |                 (СОО)                 |настоящего

       |                                       |стандарта)           |

|      \---------------------------------------/

                                                                     |

|       Оценивание рисков

       /---------------------------------------\                     |

|      |         Идентификация рисков.         |

       |            Анализ рисков.             |                     |

|      |             Оценка рисков             |

       \---------------------------------------/                     |

|                           |

\- -  - - - - - - - - - - - | - - - - - - - - - - - - - - - - - - - -/

                            |

        Аттестация          

       /-------------------------------\

       |Принятие остаточных рисков     |

       \-------------------------------/

Рисунок 1 - Трехэтапный процесс обеспечения безопасности автоматизированных систем

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

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

5.3 Безопасность в жизненном цикле автоматизированных систем

5.4 Взаимосвязь с другими системами

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

6.1 Общие положения

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

6.2 Основные принципы оценки безопасности

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

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

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

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

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

Следовательно, оценку безопасности автоматизированной системы можно разделить на несколько этапов:

6.3 Доверие к автоматизированным системам

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

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

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

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

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

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

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

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

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

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

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

6.4 Комбинированные автоматизированные системы

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

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

Обычно составные автоматизированные системы:

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

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

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

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

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

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

Рассмотрим построение системы, приведенной на рисунке 3. В отношении домена безопасности А, который создан из собственного программного обеспечения, можно, вероятно, предоставить свидетельства, необходимые для оценки по стандартам серии ИСО/МЭК 15408. Что касается домена безопасности В, то можно получить свидетельства для удовлетворения некоторых критериев по стандартам серии ИСО/МЭК 15408 (например, классы ADO и AGD и ATE_FUN), но доступность других критериев (например, классы ADV и AVA и FNT_COV/DPT) маловероятна, поскольку необходимые свидетельства были уничтожены или вообще не существовали. Необходимо получить альтернативное доверие или принять остаточные риски.

 CОО
 /- - - - - - - - - - - - - - - - - - -\
 Домен А
    |    /---------------------------\    |     
         |    Новая разработанная    |          
    |    | прикладная программа для  |    |     
         |автоматизированной системы |          
    |    \---------------------------/    |     
                                                
    \- - - - - - - - - - - - - - - - - - -/     
                                                
    /- - - - - - - - - - - - - - - - - - -\     
                    Домен В                     
    |    /---------------------------\    |     
         |Новые продукты, для которых|          
    |    |  свидетельства оценки не  |    |     
         |были предоставлены. Пример |          
    |    |- Универсальная ОС или СУДБ|    |     
         \---------------------------/          
    |                                     |     
    \ - - - - - - - - - - - - - - - - - - /     
                                                
 

Рисунок 3 - Гетерогенное построение системы

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

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

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

 СОО
 /- - - - - - - - - - - - - - - - - - - - - - - \
    |                   Домен X                    |    
          /-----------------------------------\         
    |     |  Новая разработанная прикладная   |    |    
          | программа для автоматизированной  |         
    |     |              системы              |    |    
          \-----------------------------------/         
    |                                              |    
          /-----------------------------------\         
    |     |  Оцененные продукты, для которых  |    |    
          |   имеются ТОО, или неоцененные    |         
    |     |продукты, для которых свидетельства|    |    
          |  оценки могли быть представлены.  |         
    |     | Пример - Собственные ОС или СУДЕ  |    |    
          |            поставщика             |         
    |     \-----------------------------------/    |    
                                                        
    \- - - - - - - - - - - - - - - - - - - - - - - /    
                                                        
 

Рисунок 4 - Гомогенное построение системы

6.5 Типы мер обеспечения безопасности

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

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

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

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

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

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

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

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

Примеры

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

2 Для ЗБС может потребоваться специфическое распределение функциональных возможностей безопасности конкретным компонентам в пределах доменов безопасности. Это будет означать, что потребуется уточнение для конкретных частей функций безопасности ОО, например, "Домен безопасности с межсетевым экраном должен обеспечить механизм для...".

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

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

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

6.6 Функциональные возможности обеспечения безопасности систем

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

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

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

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

Важно отметить, что только связанные с безопасностью части СОО включены в оцененную ФБС и СОО, не надо представлять всю автоматизированную систему. Меры обеспечения безопасности системы представлены на рисунке 6.

 Автоматизированная система в целом
 
 /- - - - - - - - - - - - - - - - - - - - - - - - - - -
 Система как объект оценки (СОО)
         |                                                     
                                                               
         |                                                     
                       Функциональные возможности              
         |             безопасности системы (ФБС)              
                      (вся совокупность ТФБ и ЭФБ)             
         |                         |                           
             Технические функции   |   Функции безопасности,   
         |   безопасности (ТФБ)    |        реализуемые        
                                   | эксплуатационными мерами  
         |                         |           (ОФБ)           
         \ - - - - - - - - - - - - - - - - - - - - - - - - - - 
                                                               
 

Рисунок 6 - Меры обеспечения безопасности системы

При оценке по стандартам серии ИСО/МЭК 15408 функции технической безопасности часто зависят от аспектов организационной безопасности. Примером такой зависимости является элемент управления доступом FDP_ACC по ИСО/МЭК 15408-2:

FDP_ACC.1.1 ФБО должны осуществлять [назначение: ПФБ управления доступом] для [назначение: список субъектов, объектов и операций субъектов на объектах, на которые распространяется ПФБ].

При оценке по стандартам серии ИСО/МЭК 15408 политика управления доступом и список субъектов, объектов и операций должны документироваться и только в этом случае считаются правильными. При оценке автоматизированных систем политика управления доступом и список оцениваются как часть оценки защиты данных и ролей и обязанностей персонала (см. приложение В, пункт В.4.2.4, FOA_IFF.1.7; и приложение В, пункт В.2.2.4, FOD_PSN.1.19). В основном правила и процедуры функции технической безопасности, которые должны считаться правильными и применимыми для оценки по стандартам серии ИСО/МЭК 15408, оценивают как часть оценки автоматизированной системы.

6.7 Определение времени оценки

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

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

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

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

6.8 Использование оцененных продуктов

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

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

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

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

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

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

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

6.9 Требования к документации

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

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

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

6.10 Действия по тестированию

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

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

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

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

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

6.11 Управление конфигурацией

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

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

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

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

7.1 Общие положения

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

Большей частью, дополнительные процессы, документация и задания, требуемые для оценки автоматизированных систем, были определены расширением аналогичных концепций в соответствии со стандартами серии ИСО/МЭК 15408. Дополнительные критерии оценки касаются в первую очередь аспектов эксплуатационной интеграции и интеграции системы информационной безопасности и взяты из действующих стандартов по информационной безопасности, не связанных с оценкой. В частности, настоящий стандарт содержит значительные заимствования из двух стандартов безопасности ИСО/МЭК 17799 [8] и НИСТ СП 800-53 [9]. Принимая во внимание наличие и широкое признание этих стандартов, было принято решение считать разработку новых критериев и их структур нецелесообразным.

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

Наряду с ИСО/МЭК 17799 [8] и НИСТ СП 800-53 [9] существует группа других стандартов ПК 27, например, ИСО/МЭК 13335 [1], [2], [3], [4] и ИСО/МЭК 21827 [10], применяемых в качестве источников. Стандарты серии ИСО/МЭК/ТО 15443 [7] предлагают альтернативные потенциальные подходы в отношении требований доверия. В ИСО/МЭК/ТО 15446 [11] предлагаются руководства по разработке профилей защиты и заданий по безопасности.

Другие относящиеся к данной предметной области документы включают в себя Руководство по оценке средств обеспечения безопасности в федеральных информационных системах [12] и Руководство по защите базы ИТ Германии [13].

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

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

7.2 Взаимосвязь со стандартами серии ИСО/МЭК 15408

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

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

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

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

7.3 Взаимосвязь со стандартами, не связанными с оценкой

Стандарт ИСО/МЭК 17799 [8] является Сводом правил, рекомендующим методы и средства обеспечения безопасности, которые должны рассматриваться организацией для управления безопасностью информационных активов. В стандарте содержатся рекомендации по менеджменту информационной безопасности для инициирования, осуществления и поддержания информационной безопасности.

ИСО/МЭК 17799 [8] предоставляет принятую повсеместно организационную структуру безопасности для руководства. В качестве основного источника идентификации и обозначения аспектов организационной безопасности там, где требуются меры обеспечения безопасности и формулирования конкретных требований организационного управления, принималась редакция 2005 г.

В НИСТ СП 800-53 [9] представлены руководства по выбору и обозначению мер обеспечения безопасности информационных систем, предназначенных для использования в федеральных системах правительства США. Применение этих руководств рекомендуется системам управления штатами и местным самоуправлениям, а также организациям частного сектора, составляющим критически важную инфраструктуру США. Предполагается их замена федеральным стандартом по обработке информации США, FIPS Publication 200. Меры минимальной безопасности федеральных информационных систем. НИСТ СП 800-53 [9] использует не только определение мер обеспечения безопасности по ИСО/МЭК 17799 [8], но также охватывает другие области, не связанные непосредственно с менеджментом информационной безопасности.

Следовательно, НИСТ СП 800-53 [9] использовался как второй основной источник для организационных мер безопасности, особенно в областях организационной безопасности, которые находятся вне области применения ИСО/МЭК 17799 [8].

В стандартах серии ИСО/МЭК 13335 [1], [2], [3], [4] также используются требования к мерам обеспечения безопасности. Однако в них меры обеспечения безопасности задействованы на слишком высоком уровне, чтобы применяться в качестве источника конкретных требований к организационным мерам безопасности.

7.4 Взаимосвязь с разработкой Общих критериев

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

В данное время Совет по разработке Общих критериев разрабатывает новую версию Общих критериев под названием "Версия 3". Став установившейся, эта версия, по-видимому, будет использоваться в качестве основы для будущего пересмотра стандартов серии ИСО/МЭК 15408. Самым последним проектом на момент подготовки настоящего стандарта была Версия 3.0 [14]. Данная версия была издана только для комментариев, т.е., в качестве рабочего проекта ИСО/МЭК.

Хотя Версия 3.0 [14] предназначена только для комментариев, она включает в себя существенные разработки технологии оценки, основанные на практическом применении Общих критериев и стандартов серии ИСО/МЭК 15408. Таким образом, значительные изменения, внесенные в эту новую версию Общих критериев, и оценка их потенциального влияния на требования настоящего стандарта рассматриваются в приложении D.

8.1 Введение

Автоматизированные системы должны оцениваться с использованием общей модели оценки, определенной в ИСО/МЭК 15408-1, с расширениями (дополнениями), определенными в настоящем разделе.

8.2 Роли оценки и обязанности

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

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

- оценка (включая сертификацию результатов оценки);

- аттестация.

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

Таблица 1 - Роли и обязанности по оценке автоматизированных систем

8.3 Оценка риска и определение неприемлемых рисков

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

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

Примечание - В настоящем стандарте не предписывается какая-либо определенная модель или форма оценки риска. Дальнейшую информацию относительно риска для систем информационных и телекоммуникационных технологий можно найти в ИСО/МЭК 13335-1 [1].

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

- принятия риска;

- принятие повышенного риска и осознание ответственности за последствия, если риск будет реализован;

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

- избежания риска; отказ от деятельности, которая приводит к риску;

- уменьшения или устранения рисков; уменьшение рисков до приемлемого уровня путем применения в рамках автоматизированной системы оцененных контрмер для уменьшения вероятности и/или последствий риска.

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

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

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

- имеются ли изменения в бизнес-активах;

- имеются ли новые риски или изменения в рисках для активов;

- остаются ли надлежащими реализованные контрмеры.

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

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

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

- результаты оценки риска;

- политики безопасности организации, применимые к системе.

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

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

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

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

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

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

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

8.7 Задание по безопасности для системы

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

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

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

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

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

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

Сравнение элементов ЗБ, определенного в стандартах серии ИСО/МЭК 15408, и ЗБС, определенного в настоящем стандарте, а также их применимость для оценки автоматизированных систем приведены в таблице 4.

Таблица 4 - Сравнение элементов заданий по безопасности

8.8 Периодическая переоценка

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

Спецификация может быть выполнена следующими способами:

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

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