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

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

 

Information technology. Security techniques. Security assessment of operational systems

 

Дата введения - 1 октября 2009 г.

Введен впервые

 

Предисловие

 

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

Введение

 

Настоящий стандарт содержит дополнительные правила (процедуры) к международным стандартам ИСО/МЭК 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) - задание по безопасности для автоматизированной системы;

COO (STOE) - система как объект оценки;

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

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

ТФБ (ТЭР) - технические функции безопасности;

ОФБ (OSF) - функции безопасности, реализуемые организационными мерами;

3B (ST) - задание по безопасности;

ПЗ (SР) - профиль защиты.

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

a) оценивание рисков безопасности применименительно к рассматриваемой системе;

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

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

Концептуально этот трехэтапный процесс показан на рисунке 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) каталог критериев доверия для выражения дополнительных задач по оценке, необходимых для оценки автоматизированных систем (см. приложение С).

 

        Оценивание рисков
       /---------------------------------------\
       |           Идентификация рисков.       |
       |             Анализ рисков.            |
       |             Оценка рисков             |
       \---------------------------------------/
                            |
                            
/-- - - - - - - - - - - - - - - - - - - - - - - - - -  - - - - - - - \
                                                                     |
|       Выбор мер безопасности
       /---------------------------------------\                     |
|      |  Выбор мер безопасности в задании по  |
       |    безопасности для системы (ЗБС)     |                     |
|      \---------------------------------------/
                                                                     |

 

|       Применение мер безопасности                                  |
       /---------------------------------------\                     |
|      |    Применение мер безопасности по     |Уменьшение рисков
       |отношению к системе как объекту оценки |(область применения  |
|      |                 (СОО)                 |настоящего
       |                                       |стандарта)           |
|      \---------------------------------------/
                                                                     |
|       Оценивание рисков
       /---------------------------------------\                     |
|      |         Идентификация рисков.         |
       |            Анализ рисков.             |                     |
|      |             Оценка рисков             |
       \---------------------------------------/                     |
|                           |
\- -  - - - - - - - - - - - | - - - - - - - - - - - - - - - - - - - -/
                            |
        Аттестация          
       /-------------------------------\
       |Принятие остаточных рисков     |
       \-------------------------------/

 

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

 

Распространение подхода стандартов серии ИСО/МЭК 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 (например, классы ADO и AGD и ATE_FUN), но доступность других критериев (например, классы ADV и AVA и FNT_COV/DPT) маловероятна, поскольку необходимые свидетельства были уничтожены или вообще не существовали. Необходимо получить альтернативное доверие или принять остаточные риски.

 

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

 

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

 

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

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

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

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

а) уровень доверия, требуемый для подсистемы;

b) уровень доверия, уже установленный (или не установленный) для продуктов, составляющих подсистему;

c) выбранная архитектура и продукты, составляющие архитектуру;

d) используемая технология;

e) размещение компонентов в физической среде.

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

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

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

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

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

7 Взаимосвязь с существующими стандартами безопасности

 

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

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

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

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

 

РИСУНОК 7. ВЗАИМОСВЯЗЬ МЕЖДУ СРЕДОЙ ЭКСПЛУАТАЦИИ И КРИТЕРИЯМИ ОЦЕНКИ

 

Наряду с ИСО/МЭК 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 Оценка автоматизированных систем

 

8.1 Введение

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

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

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

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

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

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

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

 

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

 

Вид деятельности

Роль

Обязанность

Разделы ЗБС

Разработка свидетельств для оценки

Высший менеджмент

Общая ответственность за безопасность.

Определяет приемлемые риски.

Санкционирует действия уполномоченных должностных лиц

Не определено

Уполномоченные должностные лица организации

Оценивают и принимают остаточные риски

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

Агентство безопасности

Устанавливает политики безопасности всей организации

Владелец системы

Проводит оценку рисков.

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

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

Санкционирует переоценку, связанную с изменениями в системе или ее среде.

Анализирует состояние системы на основе отчетов о непрерывном мониторинге

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

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

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

Описание СОО

Разработчик/интегратор/проектировщик системы

Разработка или поддержка разработки ЗБС на основе проблемы безопасности, определенной владельцем системы.

Разработка свидетельств разработки.

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

Описание СОО. Технические меры безопасности. Требования доверия, относящиеся к разработке.

Архитектура и краткая спецификация

Оператор/администратор/ответственный за сопровождение

Поддержка разработки СЗБ.

Разработка эксплуатационных свидетельств.

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

Организационные меры.

Требования доверия, относящиеся к эксплуатации.

Архитектура и краткая спецификация

Оценка

Оценщик/лицо, осуществляющее сертификацию (сертификатор)

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

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

Сертифицирует результаты оценки.

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

Все

Аттестация

Аттестующий

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

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

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

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

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

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.6.1 Введение

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

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

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

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

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

 

Таблица 2 - Сравнение функциональных классов

 

Стандарты серии ИСО/МЭК 15408

Автоматизированная система: ИСО/МЭК ТО 19791

Применимость и область применения

Аудит безопасности (FAU)

Аудит безопасности (FAU)

Применимо

Связь (FCO)

Связь (FCO)

Криптография (FCS)

Криптография (FCS)

Защита данных пользователя (FDP)

Защита данных пользователя (FDP)

Идентификация и аутентификация (FIA)

Идентификация и аутентификация (FIA)

Управление безопасностью (FMT)

Управление безопасностью (FMT)

Приватность (FPR)

Приватность (FPR)

Защита ФБО (FPT)

Защита ФБО (FPT)

Применимо

Доступ к 00 (FTA)

Доступ kOO (FTA)

Доверенный маршрут/канал (FTP)

Доверенный маршрут/канал (FTP)

Аудит безопасности (FAU)

Аудит безопасности (FAU)

-

Организационные меры безопасности (FOD)

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

-

Меры обеспечения безопасности систем ИТ (FOS)

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

-

Меры обеспечения безопасности активов пользователей (FOA)

Защита приватности данных, активы пользователей

-

Меры обеспечения безопасности бизнес-процессов (FOB)

Политика, непрерывность

-

Меры обеспечения безопасности аппаратуры и оборудования (FOP)

Мобильное оборудование, съемное оборудование, удаленное оборудование, система, аппаратура

-

Меры обеспечения безопасности по отношению к третьей стороне (FOT)

Управление

-

Управление (FOM)

Параметры безопасности, классификация активов, обязанности персонала, организация безопасности, отчеты о безопасности

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

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

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

 

Таблица 3 - Сравнение классов доверия

 

Стандарты серии ИСО/МЭК 15408

Автоматизированная система: ИСО/МЭК ТО 19791

Применимость

АРЕ: оценка профиля защиты

Оценка профиля защиты для системы (ASP)

Зависит от отличий ПЗС

ASE: оценка задания по безопасности

Оценка задания по безопасности для системы (ASS)

Зависит от отличий ЗБС

ACM: управление конфигурацией

Управление конфигурацией автоматизированных систем (АОС)

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

Управление конфигурацией (изменение, отслеживание, сопровождение).

Подтверждение и верификация (во время эксплуатации)

ADO: поставка и эксплуатация

Безопасная установка системы (ASI)

Информирование и связь ФБС.

Подтверждение и верификация (во время эксплуатации)

ADV: разработка

Документация по проектированию архитектуры автоматизированных систем и конфигурационная

Интерфейсы и конфигурация компонентов.

Внешние интерфейсы.

Архитектура, информационные потоки, доступ к СОО.

Режим эксплуатации/условия развития

AGD: руководства

Руководства для автоматизированных систем (AOD)

Правила и процедуры для пользователя и администратора.

Конфигурация.

Подтверждение и верификация (во время эксплуатации)

ALC: поддержка жизненного цикла

Поддержка жизненного цикла автоматизированных систем (AOL)

Аналогично мерам обеспечения безопасности для среды разработки/интеграции.

Подтверждение и верификация (во время эксплуатации)

ATE: тестирование

Тестирование автоматизированных систем (АОТ)

Функциональное тестирование, глубина тестирования и покрытие тестами ФБС.

Независимое тестирование ФБС.

Регрессивное тестирование на этапе поддержки (сопровождения)/моди-фикации

AVA: Оценка уязвимостей

-

Анализ уязвимостей автоматизированных систем (AOV)

-

Регистрация и запись в автоматизированных системах (ASO)

Записи в журналы ФБС.

Административный анализ ФБС.

Независимая верификация ФБС.

Подтверждение и верификация записей

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

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

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

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

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

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

a) аспекты реализованной среды автоматизированной системы, не согласующиеся со средой АС, которая специфицирована в ЗБС;

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

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

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

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

 

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

 

Стандарты серии ИСО/МЭК 15408

Автоматизированная система: ИСО/МЭК ТО 19791

Применимость к автоматизированным системам

Введение

Введение

Должны быть определены ИТ/эксплуатационные части СОО и интерфейсы с внешними автоматизированными системами.

Может быть определена доменная организация

Описание ОО

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

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

Вместо угроз следует определить риски.

Предположения не должны быть определены, так как среда является реальной

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

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

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

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

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

Функциональные требования для ИТ-частей СОО.

Эксплуатационные требования для эксплуатационных частей СОО.

Должны быть определены требования доверия

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

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

Должна быть описана функциональная, эксплуатационная спецификация и спецификации доверия

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

Утверждение о соответствии

Могут быть определены утверждения о соответствии ПЗС, ПЗ и/или ЗБ

-

Введение (доменная часть)

Должны быть определены ИТ/эксплуатационные части домена

-

Проблемы безопасности (доменная часть)

Должны быть определены риски и ПБОр

-

Цели безопасности (доменная часть)

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

-

Требования безопасности (доменная часть)

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

-

Краткая спецификация (доменная часть)

Должна быть описана функциональная, эксплуатационная спецификация и спецификации доверия для домена

-

Утверждение о соответствии (доменная часть)

Могут быть определены утверждения о соответствии ПЗС, ПЗ и/или ЗБ для домена

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

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

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

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

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

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

 

[1]

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

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

 

(ISO/IEC 13335-1:2004)

(Information technology. Security techniques. Part 1: Concepts and models for information and communications technology security management)

[2]

ИСО/МЭК ТО 13335-3:1998*

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

 

(ISO/IEC TR 13335-3): 1998

(Information technology. Security techniques. Part 3: Techniques for information technology security)

[3]

ИСО/МЭК ТО 13335-4:2000* (ISO/IEC TR 13335-4):2000

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

(Information technology. Security techniques. Part 4: Selection of safeguards)

[4]

ИСО/МЭК 13335-5:2001*

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

 

(ISO/IEC 13335-5):2001

(Information technology. Security techniques. Part 5: Management guidance on network security)

[5]

ИСО/МЭК 27005:2008

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

 

(ISO/IEC 27005):2008

(Information technology. Security techniques. Information security risk management)

[6]

Руководство по сертификации и аккредитации безопасности федеральных информационных систем, Специальная публикация НИСТ СП 800-37, Министерство торговли, США

(Guide for the Security Certification and Accreditation of Federal Information Systems, NIST Special Publication SP 800-37, Department of Commerce, United States)

[7]

ИСО/МЭК TO 15443 (все части)

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

 

[(ISO/IEC TR 15443 (all parts)]

(Information technology. Security techniques. A framework for IT security assurance)

[8]

ИСО/МЭК 17799:2005

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

 

(ISO/IEC 17799):2005

(Information technology. Security techniques. Code of practice for information security management)

[9]

Рекомендуемые средства обеспечения безопасности для федеральных информационных систем, Специальная публикация НИСТ СП 800-53, Второй публичный проект, сентябрь 2004 года, Министерство торговли, США

 

(Recommended Security Controls for Federal Information Systems, NIST Special Publication SP 800-53, Second Public Draft, September 2004, Department of Commerce, United States)

[10]

ИСО/МЭК 21827:2002

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

 

(ISO/IEC 21827):2002

(Information technology. Security techniques. System security engineering. Capability maturity model)

[11]

ИСО/МЭК TO 15446:2004

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

 

(ISO/IEC/TR 15446):2004

(Information technology. Security techniques. Guide for the production of protection profiles and security targets)

[12]

Руководство по оценке средств обеспечения безопасности в федеральных информационных системах, Специальная публикация НИСТ СП 800-53А, Министерство торговли, США

(Guide for Assessing the Security Controls in Federal Information Systems, NIST Special Publication. SP 800-53A, Department of Commerce, United States)

[13]

Руководство по защите базы ИТ, Федеральное ведомство по безопасности технологии сбора, обработки и передачи информации, Германия, 3-88784-915-9

(IT Baseline Protection Manual, Bundesamt fur Sicherheit in der Informationstechnik, Germany. ISBN 3-88784-915-9)

[14]

Общие критерии оценки безопасности информационных технологий, Версия 3.0, редакция 2, июнь 2005 г., Совет по разработке общих критериев

(Common criteria for Information technology security evaluation, Version 3.0, Revision 2, June 2005, Common criteria development board)

[15]

ИСО/МЭК 18045:2005

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

 

(ISO/IEC 18045):2005

(Information technology. Security techniques. Methodology for IT security evaluation)

 

* Стандарты серии ИСО/МЭК 13335 заменяются стандартами из серии ИСО/МЭК 27000.

 

Откройте актуальную версию документа прямо сейчас или получите полный доступ к системе ГАРАНТ на 3 дня бесплатно!

Получить доступ к системе ГАРАНТ

Если вы являетесь пользователем интернет-версии системы ГАРАНТ, вы можете открыть этот документ прямо сейчас или запросить по Горячей линии в системе.


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


Текст ГОСТа приводится по официальному изданию Федерального агентства по техническому регулированию и метрологии, Москва, Стандартинформ, 2010 г.


1 Подготовлен Федеральным государственным учреждением "Государственный научно-исследовательский испытательный институт проблем технической защиты информации Федеральной службы по техническому и экспортному контролю" (ФГУ "ГНИИИ ПТЗИ ФСТЭК России"), Обществом с ограниченной ответственностью "Центр безопасности информации" (ООО "ЦБИ") на основе собственного аутентичного перевода стандарта, указанного в пункте 5


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


3 Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 18 декабря 2008 г. N 525-ст.


4 Введен впервые


5 Настоящий стандарт идентичен международному стандарту ИСО/МЭК/ТО 19791:2006 "Информационная технология. Методы и средства обеспечения безопасности. Оценка безопасности автоматизированных систем" (ISO/IEC/TR 19791:2006 "lnformation technology - Security techniques - Security assessment of operational systems").


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