Присоединяйтесь!
Зарегистрированных пользователей портала: 506 311. Присоединяйтесь к нам, зарегистрироваться очень просто →
Законодательство
Законодательство

"ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. ОЦЕНКА БЕЗОПАСНОСТИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ. ГОСТ Р ИСО/МЭК ТО 19791-2008" (утв. Приказом Ростехрегулирования от 18.12.2008 N 525-ст)

Дата документа18.12.2008
Статус документаДействует
МеткиПриказ · Стандарт · Гост р · Исо/мэк

    

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

 

ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ

 

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

 

ОЦЕНКА БЕЗОПАСНОСТИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ

 

Information technology. Security techniques. Security assessment of operational systems

 

ГОСТ Р ИСО/МЭК ТО 19791-2008

 

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

 

Предисловие

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

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

 
    1 ПОДГОТОВЛЕН Федеральным государственным учреждением "Государственный научно-исследовательский испытательный институт проблем технической защиты информации Федеральной службы по техническому и экспортному контролю" (ФГУ "ГНИИИ ПТЗИ ФСТЭК России"), Обществом с ограниченной ответственностью "Центр безопасности информации" (ООО "ЦБИ") на основе собственного аутентичного перевода стандарта, указанного в пункте 5
    2 ВНЕСЕН Управлением технического регулирования и стандартизации Федерального агентства по техническому регулированию и метрологии
    3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 18 декабря 2008 г. N 525-ст.
    4 ВВЕДЕН ВПЕРВЫЕ
    5 Настоящий стандарт идентичен международному стандарту ИСО/МЭК/ТО 19791:2006 "Информационная технология. Методы и средства обеспечения безопасности. Оценка безопасности автоматизированных систем" (ISO/IEC/TR 19791:2006 "Information technology - Security techniques - Security assessment of operational systems").
    При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении E
    Информация об изменениях к настоящему стандарту публикуется в ежегодно издаваемом информационном указателе "Национальные стандарты", а текст изменений и поправок - в ежемесячно издаваемых информационных указателях "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячно издаваемом информационном указателе "Национальные стандарты". Соответствующая информация, уведомления и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет
 

Введение

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

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

 
    Настоящий стандарт содержит рекомендации и критерии оценки безопасности автоматизированных систем (далее - АС), а также обеспечивает расширение области применения стандартов серии ИСО/МЭК 15408, включая ряд критических аспектов, касающихся оценки среды эксплуатации объекта оценки и декомпозиции составных АС на домены безопасности, которые должны оцениваться отдельно.
    Настоящий стандарт устанавливает:
    a) определение и модель АС;
    b) описание расширений концепции оценки безопасности с помощью стандартов серии ИСО/МЭК 15408, необходимых для оценки АС;
    c) методологию и процесс выполнения оценки безопасности АС;
    d) дополнительные критерии оценки безопасности, охватывающие те аспекты АС, которые не были охвачены критериями оценки безопасности в стандартах серии ИСО/МЭК 15408.
    Настоящий стандарт дает возможность включать продукты безопасности, оцененные в соответствии с требованиями стандартов серии ИСО/МЭК 15408, в автоматизированные системы и проводить оценку как единого целого с использованием настоящего стандарта.
    Настоящий стандарт ограничивается оценкой безопасности автоматизированных систем и не распространяется на другие формы оценки систем. Настоящий стандарт не определяет методы и средства идентификации, оценки и принятия эксплуатационного риска.
 

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

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

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

 
    В настоящем стандарте применены следующие термины с соответствующими определениями:
    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): Недостатки или слабости в проекте или реализации информационной системы, включая меры обеспечения безопасности, которые могут быть преднамеренно или непреднамеренно использованы для оказания неблагоприятного воздействия на активы организации или ее функционирование.
 

4 Сокращения

 
    В настоящем стандарте используют следующие сокращения:
    ТОО (ETR) - технический отчет об оценке;
    СМИБ (ISMS) - система менеджмента информационной безопасности;
    ОФБ (OSF) - организационные функциональные требования безопасности;
    СП (SP) - специальная публикация;
    ПЗС (SPP) - профиль защиты системы;
    ДБС (SSA) - доверие к безопасности системы;
    ФБС (SSF) - функции безопасности системы;
    ЗБС (SST) - задание по безопасности для автоматизированной системы;
    СОО (STOE) - система как объект оценки;
    ИТ (IT) - информационная технология;
    ОО (TOE) - объект оценки;
    ТФБ (TSF) - технические функции безопасности;
    ОФБ (OSF) - функции безопасности, реализуемые организационными мерами;
    ЗБ (ST) - задание по безопасности;
    ПЗ (SP) - профиль защиты.
 

5 Методологический подход к решению проблемы безопасности

 

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

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

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

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

 

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

 
    В настоящем стандарте рассматривается только второй этап процесса, а именно - уменьшение рисков посредством выбора, применения и оценки мер обеспечения безопасности. Для этого в нем используется подход к оценке безопасности, основанный на модели оценки безопасности для ИТ-мер обеспечения безопасности, определенной в стандартах серии ИСО/МЭК 15408, но распространенный на все типы мер обеспечения безопасности.
    Способы и методы оценки рисков находятся вне области действия настоящего стандарта. Для получения большей информации по оценке рисков см. часть 3 ИСО/МЭК 13335 [1].
    Примечание - ИСО/МЭК 13335-3 [2] является техническим отчетом. После опубликования международного стандарта ИСО/МЭК 27005 [5] он заменит ИСО/МЭК 13335 [1], [2], [3], [4].
    Способы и модели аттестации являются прерогативой менеджмента и находятся вне области действия настоящего стандарта. Для получения большей информации об одном возможном из подходов см. [6].
    Модель оценки безопасности, описанная в ИСО/МЭК 15408-1, исключает рассмотрение среды функционирования (эксплуатации), окружающей часть информационной системы, связанной с ИТ. Среда эксплуатации рассматривается (учитывается) (при оценке в соответствии со стандартами серии ИСО/МЭК 15408) в качестве предположений, но не может не приниматься во внимание для автоматизированных систем. Обычно автоматизированные системы используют меры обеспечения безопасности, не связанные с ИТ, например, организационные меры или меры физической защиты. Следовательно, существует потребность в определении путей выражения и оценки таких требований и мер обеспечения безопасности в виде расширения спецификации критериев стандартов серии ИСО/МЭК 15408. В этих целях настоящий стандарт расширяет критерии оценки безопасности стандартов серии ИСО/МЭК 15408.
    В целом расширения стандартов серии ИСО/МЭК 15408 в рамках настоящего стандарта включают в себя (но не ограничиваются):
    а) оценку рисков в общую методологию оценки безопасности автоматизированных систем с учетом условий их эксплуатации;
    b) методологию определения внутренней структуры автоматизированных систем, в том числе подробности о внутренних и внешних интерфейсах в объеме, необходимом для понимания, каким образом взаимодействуют различные части автоматизированной системы;
    c) каталог критериев доверия для выражения расширений области оценки (см. приложение А);
    d) каталог функциональных критериев для выражения дополнительных мер обеспечения безопасности при эксплуатации (см. приложение В);
    e) каталог критериев доверия для выражения дополнительных задач по оценке, необходимых для оценки автоматизированных систем (см. приложение С).
    Распространение подхода стандартов серии ИСО/МЭК 15408 к оценке законченных автоматизированных систем обладает тем преимуществом, что использование некоторого существующего показателя облегчает общее и взаимное понимание результатов оценки. Для конкретной автоматизированной системы представление результата оценки способом, соответствующим стандартам серии ИСО/МЭК 15408, может принести деловую выгоду клиентам, не только предоставляющим услуги таких систем, как банковские системы в Интернете, но и с точки зрения социальной ответственности.
    При оценке автоматизированных систем требуется идентификация рисков безопасности, применимых для автоматизированной системы, во время предшествующей оценки риска и определение рисков, которые являются неприемлемыми и должны быть уменьшены или устранены посредством технических и организационных мер безопасности. Тогда оценка автоматизированных систем состоит из следующих этапов:
    a) определение целей безопасности для автоматизированной системы, которые уменьшат неприемлемые риски до приемлемого уровня;
    b) выбор и спецификация технических и организационных мер безопасности, которые соответствуют целям безопасности автоматизированной системы, принимая во внимание уже реализованные меры обеспечения безопасности;
    c) определение конкретных измеримых требований доверия как к техническим, так и организационным мерам обеспечения безопасности для достижения необходимого уровня уверенности в том, что автоматизированная система соответствует целям безопасности;
    d) фиксирование принятых решений в ЗБС;
    e) оценка конкретной автоматизированной системы с тем, чтобы сделать вывод о ее соответствии ЗБС;
    f) периодическая переоценка рисков безопасности автоматизированной системы, так и способности автоматизированной системы противостоять этим рискам.
    Хотя эта модель является расширением модели в соответствии со стандартами серии ИСО/МЭК 15408, она совместима с этой моделью и, таким образом, результаты оценки по стандартам серии ИСО/МЭК 15408 могут быть использованы повторно.
 

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

 
    5.3.1 Общие положения
    Считается, что жизненный цикл автоматизированной системы состоит из следующих стадий: разработка/интеграция, установка, эксплуатация системы и модификация. Меры обеспечения безопасности автоматизированной системы должны подвергаться оценке в течение всего жизненного цикла системы.
    5.3.2 Стадия разработки/интеграции
    На стадии разработки/интеграции первым действием по обеспечению безопасности должна быть идентификация рисков для автоматизированной системы. Риски, считающиеся неприемлемыми, должны уменьшаться или устраняться мерами обеспечения безопасности, интегрированными в систему. Следом за оценкой риска и идентификацией рисков, которые должны быть устранены, доверенное должностное лицо организации (аттестующее лицо) должно рассмотреть предполагаемые остаточные риски, общее число имеющихся остаточных рисков и подтвердить, что они являются приемлемыми.
    После этого проектируется автоматизированная система с помощью программных и аппаратных изделий, физических мер, коммерческих программ и технических мер безопасности. Проект автоматизированной системы должен быть записан в ЗБС. В ЗБС содержится описание требований по безопасности, включая риски, которым надо противодействовать, и цели безопасности, которые необходимо реализовать с помощью технических и организационных мер безопасности. Цели безопасности системы конкретизируются в перечне технических и организационных мер безопасности.
    Для корректности в ЗБС необходимо обозначать цели безопасности, которые определяют риски, идентифицированные как неприемлемые. В ЗБС должны обозначаться требования по безопасности, полностью соответствующие целям безопасности без каких-либо дополнений или пропусков. В проектной документации автоматизированной системы должны быть определены конкретные контрмеры обеспечения безопасности самой автоматизированной системы, соответствующие всем требованиям безопасности, определенным в ЗБС. Этими контрмерами могут быть: функции безопасности, оборудование, процедуры или правила. Контрмеры обеспечения безопасности в системе должны адекватно контролироваться, управляться и использоваться. Контрмеры обеспечения безопасности нельзя реализовывать с какими-либо несанкционированными дополнениями, удалениями или изменениями. Реализация должна контролироваться посредством тестирования системы или проверки документации. Функционирование контрмер обеспечения безопасности должно быть адекватно описано в руководящей документации.
    В целях повышения эффективности риски безопасности, идентифицированные при оценке рисков как неприемлемые, должны быть уменьшены в соответствии с выбранными требованиями по безопасности до приемлемого уровня остаточных рисков. Каждая контрмера безопасности должна эффективно функционировать совместно с другими контрмерами для удовлетворения общих требований по безопасности автоматизированной системы. Стойкость механизмов безопасности должна быть достаточной, чтобы соответствовать предполагаемому потенциалу нападения на систему. При наличии потенциала нападения может потребоваться анализ уязвимости и испытание на проникновение.
    Оценщики должны быть задействованы в начале жизненного цикла системы на стадии разработки/ интеграции для упрощения их ознакомления с системой и ее предполагаемой средой, получения исходных данных путем просмотра проектной документации и составления руководства по оценке и руководящей документации, которые будут использоваться как часть свидетельств доверия. В идеальном случае полное ЗБС должно оцениваться на стадии предварительной оценки для подтверждения отсутствия каких-либо несоответствий или пробелов в требованиях по безопасности и предлагаемых мерах обеспечения безопасности.
    Затем создается или приобретается программное обеспечение для систем и бизнес-приложения, включая технические меры безопасности, и система интегрируется, конфигурируется и испытывается разработчиком. Одновременно создается организационная структура безопасности, формируются политики, правила и процедуры безопасности, которые интегрируются в систему. Должны быть определены и внедрены соответствующие параметры конфигурации безопасности.
    После тестирования интеграции автоматизированная система должна проверяться разработчиком как часть проверочных испытаний. Обычно специфические для системы меры обеспечения безопасности, такие как управленческие меры доступом, могут проверяться разработчиком перед их развертыванием на рабочем месте. Тестирование специфических для рабочего места мер обеспечения безопасности (технических и организационных) откладывается до завершения установки системы в ее предполагаемой эксплуатационной среде. Проверочные испытания должны подтвердить стабильность механизмов безопасности, а также правильное функционирование мер обеспечения безопасности.
    Затем осуществляется оценка автоматизированной системы. Оценка должна подтвердить, что все риски, детализированные в ЗБС, которым должны противодействовать меры обеспечения безопасности, определены как приемлемые для системы. Результат оценки является независимым подтверждением для владельца системы приемлемости мер обеспечения безопасности.
    В отчете о сертификации указывают все подтвержденные уязвимости, обнаруженные при оценке, и, при необходимости, определяются любые рекомендованные корректирующие действия. Затем владелец системы подготавливает план корректирующих действий по уменьшению или устранению выявленных уязвимостей, если это необходимо. Результат сертификации системы представляется аттестующему лицу для определения приемлемости фактических остаточных рисков для функционирования системы и ее активов. Выходные данные на стадии сертификации будут разрешением на эксплуатацию системы.
    5.3.3 Стадия установки (внедрения)
    На стадии установки (внедрения) для использования в среде эксплуатации внедряют и подготавливают технические и организационные меры безопасности. Испытывают специфические для рабочего места меры обеспечения безопасности, а остальные меры обеспечения безопасности проверяют повторно для подтверждения их правильного функционирования в конкретной рабочей среде.
    Для соблюдения корректности меры обеспечения безопасности должны соответствовать требованиям безопасности, документированным в ЗБС, и должны быть санкционированы для применения компетентным лицом. Для повышения эффективности мер обеспечения безопасности все задействованные в этом обеспечении лица должны быть обучены использованию мер и процедур обеспечения безопасности в среде эксплуатации.
    5.3.4 Стадия эксплуатации системы
    На стадии эксплуатации системы необходимо собирать и оценивать записи об эксплуатации технических и организационных мер безопасности. Журналы аудита и записи мониторинга всего доступа к активам должны регистрироваться. Необходимо подтвердить правильность функционирования мер обеспечения безопасности. Необходимо также проверять отсутствие несанкционированных операций и неприемлемых рисков. Состояния незащищенности должны быть переведены в состояния защищенности в назначенный срок. Необходимо контролировать и оценивать на наличие проблем с безопасностью изменения, внесенные в ходе регламентного обслуживания. Записи о фактическом доступе и использовании активов должны проверяться. О проблемах с безопасностью необходимо сообщать, они должны быть проверены и проанализированы.
    Целью сбора и оценивания записей об эксплуатации технических и организационных мер безопасности является установление обратной связи системы с аттестующим лицом при внесении изменений, которые могут повлиять на безопасность автоматизированной системы. Обычно при эксплуатации системы необходимо определить ряд критически важных мер обеспечения безопасности автоматизированной системы с целью непрерывного мониторинга для проверки их постоянной эффективности. Кроме того, владелец системы должен иметь систему конфигурационного управления, контроля и отчетности, которая документирует текущие активы автоматизированной системы, ее конфигурацию и представляет эту информацию ответственным сторонам.
    5.3.5 Стадия модификации
    На стадии модификации любые предполагаемые или фактические изменения автоматизированной системы, выходящие за рамки регламентного обслуживания, должны изучаться, анализироваться, и при необходимости, тестироваться для определения их воздействия на безопасность автоматизированной системы перед внедрением в процесс эксплуатации. Эти изменения включают в себя изменения в политиках и процедурах. Для проверки эффективного функционирования модифицированных мер обеспечения безопасности необходимо проводить испытание на проникновение.
    Для определения необходимости повторной оценки безопасности результаты анализа воздействия и испытаний должны представляться аттестующему лицу. Если допустить, что модификации незначительно увеличили остаточные риски (возможно, потому, что они уже были оценены как часть процесса поддержания доверия к продукту), то повторное санкционирование может осуществляться без повторной оценки. Однако если результаты оценки были признаны недействительными, может потребоваться повторная оценка.
    Конечным действием по модификации системы является прекращение ее эксплуатации после выключения системы, при этом данные системы архивируются, уничтожаются или передаются другим системам. От аттестующего лица требуется подтверждение успешной остановки системы.
 

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

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

6 Распространение принципов оценки безопасности автоматизированных систем, установленных в стандартах серии ИСО/МЭК 15408

 

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

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

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

 
    Для многих организаций информация является главным активом и нуждается в защите от угроз несанкционированного разглашения, модификации или уничтожения. Этот актив защищен посредством объединения технических мер безопасности и вспомогательных инфраструктур организационного управления, состоящих из персонала организации, политики организации, процедур и физических мер защиты. Основная концепция стандартов серии ИСО/МЭК 15408 заключается в том, что угрозы активам организации должны быть четко сформулированы, и им должна противодействовать комбинация из инфраструктур технических и организационных мер безопасности. Требования к техническим мерам безопасности по отношению к угрозам включены в стандарты серии ИСО/МЭК 15408. В этих стандартах требования к техническим мерам безопасности рассматривались отдельно как часть процесса аттестации и, следовательно, не учитывались при оценке безопасности автоматизированной системы. В настоящем стандарте делается попытка стандартизировать эти требования с тем, чтобы их можно было оценивать как часть оценки организационных мер безопасности.
    В стандартах серии ИСО/МЭК 15408 меры безопасности делятся на предоставляемые, связанные с безопасностью услуги, и меры, предпринимаемые для обеспечения уверенности в том, что эти меры обеспечения безопасности будут реализованы правильно и эффективно. При оценке продукта связанные с безопасностью услуги являются функциями ИТ, реализованными для соответствия целям этой области технологии. В контексте автоматизированных систем можно также оценить процедурное и физическое содействия обеспечению безопасности. Процедурное и физическое содействия обеспечению безопасности аналогичны выполняемым функциям ИТ, поскольку представляют собой потенциальные возможности безопасности автоматизированной системы, которые вместе отвечают целям безопасности. Однако обычно процедурное и физическое содействия обеспечению безопасности не основаны на технологии и больше соответствуют оценки эксплуатационного этапа жизненного цикла автоматизированной системы, чем этапа разработки автоматизированной системы. Поэтому считается, что они должны быть отделены от функциональных требований.
    Меры, принятые для должной реализации потенциальных возможностей безопасности и состоящие из сформированного свидетельства и независимой оценки пригодности этих возможностей, в стандартах серии ИСО/МЭК 15408 обозначены термином "доверие". Его можно расширить для включения части организационных мер безопасности автоматизированной системы с помощью документации, описывающей организационные меры безопасности как реализованные.
    Процесс разработки, внедрения и поддержания функционирования самой автоматизированной системы и связанных с безопасностью услуг оказывает значительное влияние на правильность и эффективность связанной с безопасностью услуги и ее общий вклад в общую безопасность автоматизированной системы. Это влияние также содействует уверенности в оказании связанной с безопасностью услуги. Таким образом, процесс разработки, внедрения и поддержания функционирования самой автоматизированной системы и связанных с безопасностью услуг способствует общему доверию к комплексной автоматизированной системе. А именно, чем выше уровень производительности процесса, тем больше уверенность в правильности и эффективности связанной с безопасностью услуги и, следовательно, общее оказываемое доверие.
    Функциональные требования обеспечения организационной безопасности реализуются нетехническими средствами, внедренными в автоматизированную систему в интересах обеспечения общих целей безопасности, тогда как требования доверия к ней отражены в свидетельствах соответствия этим требованиям.
    Следовательно, оценку безопасности автоматизированной системы можно разделить на несколько этапов:
    a) проблема безопасности четко сформулирована как набор рисков, которые должны быть уменьшены или смягчены, и набор политик безопасности организации, которые должны быть реализованы. Для определения цели автоматизированной системы требуется предварительный анализ, а для определения рисков, которым должны противодействовать технические и организационные меры безопасности, требуется оценка рисков. Результаты анализа фиксируются в ЗБС;
    b) проблема безопасности делится на высокоуровневое решение по безопасности, представленное совокупностью целей безопасности. Цели безопасности записывают в ЗБС;
    c) далее цели безопасности детализируют в требованиях безопасности, которые могут быть оценены независимым оценщиком. Некоторые цели относят к техническим мерам обеспечения безопасности, некоторые - к организационным. Например, контроль за несанкционированным доступом к информационному активу часто осуществляется через обеспечение физической защиты оборудования, содержащего актив (например, замки, охрана), и выполняемые функции ИТ (например, аутентификация пользователя и механизмы управления доступом). Требования безопасности записывают в ЗБС;
    d) на основе общих целей и общего доверия к требуемым мерам защиты определяется совокупность действий оценщика во время проведения оценки. Эти требования доверия записаны в ЗБС;
    e) оценка независимым оценщиком определяет соответствие автоматизированной системы ее требованиям по безопасности на основе требований, документированных в ЗБС;
    f) могут проводиться текущие оценки для обеспечения уверенности в соответствии автоматизированной системы установленным требованиям в ходе эксплуатации. Текущие оценки сосредоточены в основном в области организационных мер безопасности автоматизированной системы, поскольку эти меры зависят от поведения человека, которое является менее контролируемым и последовательным, чем поведение ИТ;
    g) периодическая переоценка автоматизированной системы может определить, продолжает ли система соответствовать установленным требованиям, несмотря на изменения в ней или в ее среде. Периодическая переоценка состоит из выявления того, какие изменения имели место, оценки воздействия этих изменений на безопасность, обновления ЗБС, при необходимости, и определения наличия поддержки безопасности в ходе этого процесса.
    Данный процесс подобен процессу оценки по стандартам серии ИСО/МЭК 15408. Типичное различие между оценкой автоматизированной системы и оценкой продукта по стандартам серии ИСО/МЭК 15408 заключается в том, что при оценке автоматизированной системы фактическая среда эксплуатации рассматривается полностью, тогда как при оценке продукта среда эксплуатации подробно не рассматривается, а описывается как предположения, которые не подтверждаются во время оценки.
    Основной целью оценки автоматизированной системы является получение доверия к правильности и эффективности реализации целей безопасности автоматизированной системы. Однако оценка мер обеспечения безопасности как технических, так и организационных, никогда не сможет обеспечить абсолютного доверия к постоянному должному функционированию в любое время и при всех обстоятельствах. В результате оценки выносится положительное или отрицательное заключение. Даже в случае, если при оценке не обнаруживаются неприемлемые уязвимости, всегда будет остаточный риск того, что меры обеспечения безопасности не функционируют должным образом. Риск можно снизить добавлением дополнительных мер доверия или использованием различных мер доверия, что придает большую уверенность в безопасности. Остаточный риск неправильного или неэффективного функционирования мер обеспечения безопасности можно выявить только посредством непрерывного мониторинга и оценки. Этот остаточный риск необходимо учитывать при принятии решения об аттестации автоматизированной системы для ее реального функционирования.
    Факторы среды могут привести к различиям в средах критичности/угроз для различных компонентов автоматизированной системы. Возможно, что для некоторых частей автоматизированной системы может потребоваться большее доверие, тогда как для других частей требуется меньшее доверие. Поскольку при оценке риска можно установить различные уровни его приемлемости, автоматизированную систему можно разделить на домены безопасности с различными требованиями доверия. Оценка риска определяет приемлемость риска для различных частей автоматизированной системы и оказывает содействие при определении соответствующих мер доверия для каждой части автоматизированной системы.
 

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

 
    Принцип доверия по стандартам серии ИСО/МЭК 15408 основан на предоставлении свидетельства о существовании правильной и эффективной реализации мер обеспечения безопасности. Более высокие уровни доверия предъявляют более подробные требования к содержанию и способу представления свидетельства. Кроме того, для большего доверия иногда требуется более строгий анализ свидетельства как со стороны разработчика, так и оценщика.
    Оценка продукта по стандартам серии ИСО/МЭК 15408 осуществляется способом, который предполагает общую среду эксплуатации, в которой продукт можно использовать. Оценка продукта сконцентрирована на проверке возможностей обеспечения безопасности, реализованных продуктом, независимо от любой конкретной среды эксплуатации. Для обоснования заключения о правильности при оценке применяются различные детализация, конструкция и тестовая документация.
    Главной целью оценки продукта является получение уверенности в том, что возможности обеспечения безопасности продукта реализуются корректно. Основу корректности определяют требования безопасности, содержащиеся в ЗБ продукта. ЗБ включает в себя определенную степень прослеживаемости проблемы безопасности, разрешаемой результирующим набором требований безопасности. Предполагается, что проблема безопасности, сформулированная в ЗБ, основана на оценке угрозы для типов сред, пригодных для ввода в действие продукта. Область оценки продукта ограничивается требованиями безопасности ИТ, определенными для продукта этой оценкой угрозы. Кроме того, оценка продукта устанавливает границы "безопасных значений" для конфигурируемых аспектов продукта под названием "оцененная конфигурация". Однако подобные конфигурации не учитывают какую-либо конкретную среду, поскольку она неизвестна на момент оценки. После завершения оценки продукта остается необходимость должным образом интегрировать оцененный продукт с другими продуктами для создания автоматизированной системы и, наконец, проверить, обеспечивает ли автоматизированная система нужные характеристики безопасности и поведение в среде, в которой она эксплуатируется, при существующей конфигурации системы.
    При оценке используются одинаковые меры доверия, применяемые ко всем выполняемым функциям безопасности. Хотя технически возможно наличие различных доменов безопасности в продуктах, обычно при общих оценках продукта домены безопасности не применяются.
    Свидетельства оценки и отчеты об оценке, полученные из оценки продукта, можно использовать для поддержки интеграции автоматизированной системы и проверочных действий.
    В принципе, разница между характеристиками продукта ИТ и автоматизированной системы с точки зрения оценки безопасности невелика. Однако оценка автоматизированной системы может быть значительно сложнее оценки продукта по стандартам серии ИСО/МЭК 15408 по следующим причинам:
    a) автоматизированная система может состоять из коммерческих продуктов и заказных разработок ИТ, объединенных в доменах безопасности. Состав каждого домена безопасности системы может основываться на нескольких факторах, таких как используемая технология, предоставленные функциональные возможности и критичность защищаемых активов;
    b) автоматизированная система может содержать многочисленные примеры одного и того же продукта (например, многочисленные копии автоматизированной системы, предоставляемые одним и тем же продавцом) или различные многочисленные примеры продуктов одинакового типа (например, многочисленные межсетевые экраны, поставляемые различными продавцами);
    c) автоматизированная система может иметь политики безопасности, применимые к одним доменам безопасности и не применимые к другим;
    d) различные остаточные риски могут быть приемлемыми в различных доменах, тогда как продукт противостоит конкретным угрозам для конкретных типов актива без учета риска.
    Основное различие между оценками продукта по стандартам серии ИСО/МЭК 15408 и оценками автоматизированной системы заключается в том, что при оценке автоматизированной системы должны рассматриваться все меры обеспечения безопасности, включая меры, реализованные в среде эксплуатации, которые при оценке продукта считаются предположениями. Вообще тип требований доверия для технических мер безопасности, документированных в ИСО/МЭК 15408-3, можно применить непосредственно или легко расширить для применения к организационным мерам безопасности. Например, концепция оценки проектной документации по техническим мерам безопасности становится оценкой описания способов функционирования организационных мер безопасности. Действия лиц, реализующих организационные меры безопасности, можно проверить способом, аналогичным способу проверки действия программ, реализующих технические меры безопасности.
    Особым вопросом является доверие к эффективности мер обеспечения безопасности, реализующих функции безопасности системы. Доверие в данном аспекте технических мер безопасности достигается методами архитектурного проектирования, такими как разделение доменов безопасности, невмешательство и отсутствие возможности обхода мер обеспечения безопасности. Что касается организационных мер безопасности, применяются методы, аналогичные методам, используемым для достижения технических мер безопасности, такие как разделение обязанностей, проверка и мониторинг.
    Областями, для которых требуются дополнительные компоненты доверия к управлению автоматизированными системами, являются:
    a) общая структура безопасности и размещение компонентов в структуре;
    b) конфигурация компонентов, составляющих автоматизированную систему;
    c) политики, правила и процедуры менеджмента, управляющие функционированием автоматизированной системы;
    d) требования и правила взаимодействия с другими доверенными и недоверенными автоматизированными системами;
    e) мониторинг не связанных с ИТ мер обеспечения безопасности во время стадии эксплуатации жизненного цикла системы.
    Из-за своей направленности на продукт стандарты серии ИСО/МЭК 15408 предполагают, что ОО будет разрабатываться в единой среде разработки, которая отличается от предполагаемой среды эксплуатации системы. Это предположение вряд ли является справедливым для большинства автоматизированных систем. Даже если автоматизированная система разрабатывается в отдельной среде испытаний, конечной стадией разработки является интегрирование в среду эксплуатации, в которой автоматизированная система дополнена организационными мерами безопасности. Некоторые подсистемы или компоненты, особенно коммерческие продукты, могут также разрабатываться в особых отдельных от основной среды средах разработки.
    Это означает, что некоторые требования доверия к среде разработки по ИСО/МЭК 15408-3 нельзя выполнить при разработке некоторых автоматизированных систем, или их применение должно быть отложено до стадии установки жизненного цикла системы. Уверенность в организационных мерах по обеспечению безопасности полностью достижима только в среде эксплуатации.
 

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

 
    Многие автоматизированные системы являются большими и сложными, обладают многочисленными функциями и сложной внутренней структурой. Часто они состоят из многих отличных друг от друга компонентов и подсистем. Каждый компонент может содержать одну функцию, предоставленную одним продуктом, один продукт с многочисленными функциями или множество функций, выполняемых с помощью изготовленного по заказу программного обеспечения и эксплуатационных процедур. Некоторые компоненты можно сгруппировать в подсистемы, способные к самостоятельному расширению. Такие подсистемы могут содержать одного клиента или сервер, состоящий из многочисленных продуктов, многочисленные серверы и/или клиенты и сети или неоднородные клиенты и/или серверы. Некоторые компоненты и подсистемы могут быть подвергнуты безопасной оценке, другие нет.
    При вводе в действие новых составных автоматизированных систем у владельцев систем могут возникнуть определенные временные и стоимостные ограничения. Таким образом, процессы, осуществляющиеся во время выполнения технической части разрешения на эксплуатацию (иногда называемые сертификацией сайта или частью аттестации автоматизированной системы), должны быть адаптируемыми для фактических потребностей.
    Обычно составные автоматизированные системы:
    a) состоят из нескольких подсистем или компонентов с различными степенями и типами доверия;
    b) имеют хорошо определенные структуры управления. Примером хорошо определенной структуры управления может быть единоличный "владелец" автоматизированной системы или определенный набор взаимоотношений во время управления различными частями автоматизированной системы;
    c) созданы для конкретных потребностей конкретной операции;
    d) отдельные компоненты обладают большим числом возможных вариантов конфигураций, некоторые из которых не соответствуют политикам безопасности автоматизированной системы;
    e) используют владельца для использования различного соотношения технических и организационных мер безопасности в различных частях автоматизированной системы.
    Для различных вышеупомянутых комбинаций политика безопасности может быть различной за исключением тех редких случаев, когда автоматизированная система выполняет одну единственную функцию. Логически все части автоматизированной системы с одним набором политик безопасности можно обозначить как домены безопасности. Декомпозиция подсистем и компонентов автоматизированной системы, управляемых одной политикой (политиками) безопасности, затем характеризуется политикой безопасности согласно соответствующим для этого домена рискам. В каждом домене безопасности можно определить функциональные требования безопасности и требования доверия к безопасности. В этом случае каждый домен безопасности будет обладать собственной политикой безопасности, определением проблем безопасности, целями безопасности, требованиями безопасности и документацией по безопасности. Однако у каждого домена безопасности могут быть собственные требования доверия, основанные на степени уверенности, необходимой в этом домене безопасности, и ее общее участие в автоматизированной системе. В задании по безопасности обозначают требования безопасности автоматизированной системы, которые являются представительной компиляцией доменов безопасности, создающих автоматизированную систему из общего контекста автоматизированной системы. Концепция домена безопасности показана на рисунке 2.
 

 

Рисунок 2 - Пример концепции доменов безопасности

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

 

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

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

 

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

 

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

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

 

Рисунок 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_INF.1.7; и приложение В, пункт B.2.2.4, FOD_PSN.1.19). В основном правила и процедуры функции технической безопасности, которые должны считаться правильными и применимыми для оценки по стандартам серии ИСО/МЭК 15408, оценивают как часть оценки автоматизированной системы.
 

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

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

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

 
    После оценки продукта могут появиться свидетельства, которые допускаются повторно использовать при оценке автоматизированной системы. Однако подробные свидетельства могут и не быть общедоступными. В некоторых случаях их можно получить непосредственно по соглашению с разработчиком продукта или непосредственно из реестра проверенных продуктов. В других случаях невозможно получить значимые подробности, необходимые для определения, применимо ли свидетельство к функции, которое оно выполняет в автоматизированной системе, и тогда владелец системы должен определить, может ли он принять результаты оценки без доступа к свидетельствам, которые способствовали получению этих результатов.
    Результаты оценки продукта необязательно применимы к оценке автоматизированной системы. Некоторыми причинами этого являются:
    a) конфигурация продукта во время его оценки и при его интегрировании в автоматизированную систему могут быть различными;
    b) доверие, при котором оценивался продукт, является неадекватным по сравнению с доверием, которое требуется для продукта при его интегрировании в автоматизированную систему в качестве компонента. В этом случае может существовать свидетельство, которое можно использовать повторно, помимо нового свидетельства, которое еще предстоит создать.
    На этих примерах при оценке автоматизированной системы необходимо определить степень, с которой можно использовать имеющиеся результаты, и необходимые меры доверия. В худшем случае эти компоненты придется рассматривать как неоцененные.
    Если оценка продукта не завершена, неизвестно, какой объем информации будет доступен для поддержки оценки автоматизированной системы, и будет ли подтверждена имеющаяся информация о продукте его оценкой. Если продукт не был оценен, информация, обычно необходимая для оценки продукта, может быть недоступна для поддержки оценки автоматизированной системы. Эти соображения надо учитывать при оценке автоматизированной системы.
    Важно также наличие информации о характеристиках безопасности интерфейсов между продуктами, т.е. какие функции безопасности одного продукта зависят от функций безопасности другого продукта. При оценке системы необходимо подтвердить, что все продукты, зависящие от функций безопасности других продуктов, используют эти продукты безопасным образом. Часто необходимая информация документируется в ТОО другого продукта, но не может быть представлена как совместимая. В этом случае необходимо просмотреть другую документацию, такую как спецификации интерфейсов, и документацию проектирования архитектуры как часть оценки системы и подтвердить наличие требуемых характеристик безопасности.