Главная | Обратная связь
МегаЛекции

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




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

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

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

· Функциональные требования (Часть 2) – соответствуют активному аспекту защиты и предъявляются к функциям безопасности ОО и реализующим их механизмам.

· Требования доверия (Часть 3) – предъявляются к технологии и процессу разработки, эксплуатации и оценки ОО и призваны гарантировать адекватность реализации механизмов безопасности.

При формулировании требований к ОО могут быть разработаны два документа:

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

Именно каталог утверждённых профилей защиты должен послужить заменой традиционных руководящих документов Гостехкомиссии России.

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

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

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

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

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

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

3. В ОК не рассматриваются ни методология оценки, ни административно- правовая структура, в рамках которой критерии могут применяться органами оценки.

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

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

 

3.4.3. Структура и содержание профиля защиты

Структура профиля защиты приведена на рис. 3.4.3.

Рис. 3.4.3. Структура профиля защиты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· итерация, позволяющая неоднократно использовать компонент при различном выполнении в нем операций;

· назначение, позволяющее специфицировать параметр, устанавливаемый при использовании компонента;

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

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

Требования доверия к безопасности ОО обычно формулируются как один из приведённых в части 3 ОК оценочных уровней доверия (ОУД) – стандартных наборов требований доверия. При этом допускается:

· усиливать выбранный уровень доверия компонентами из других ОУД;

· явным образом формулировать требования доверия, не содержащиеся в части 3 ОК.

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

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

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

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

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

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

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

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

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

3. Выбор требований безопасности строго обоснован. Каждое из перечисленных ниже условий должно быть строго обосновано:

· выбор требований, не содержащихся в частях 2 или 3 ОК;

· выбор требований доверия, не включенных в какой-либо ОУД;

· случаи неудовлетворения зависимостей.

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

 

3.4.4. Структура и содержание задания по безопасности

 

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

Рис. 3.4.4. Структура задания по безопасности

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

Раздел Соответствие ОК должен содержать все поддающиеся оценке утверждение о соответствии ОО Общим критериям. Такие утверждения могут звучать следующим образом:

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

· расширение части 2, если в изложение функциональных требований включены компоненты, отсутствующие в части 2 ОК;

· соответствие части 3, если требования доверия представлены в виде ОУД из части 3 ОК или пакета требований доверия, включающего только компоненты доверия из части 3 ОК;

· усиление части 3, если требования доверия представлены в виде ОУД или пакета требований доверия и включают другие компоненты доверия из части 3 ОК.

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

· соответствие ПЗ - ОО соответствует ПЗ только в том случае, если он соответствует всем частям этого ПЗ.

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

Краткая спецификация должна включать:

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

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

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

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

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

Если сделано утверждение о соответствии одному или нескольким ПЗ, то изложение утверждений о соответствии должно содержать следующий материал для каждого ПЗ:

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

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

· Дополнение ПЗ, идентифицирующее цели и требования безопасности ОО, которые дополняют цели и требования ПЗ.

Случай, когда в ЗБ утверждается о частичном соответствии ПЗ, не приемлем для оценки в рамках ОК.

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

· сочетание специфицированных для ОО функций безопасности ИТ при совместном использовании удовлетворяет функциональным требованиям безопасности ОО;

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

· строго обосновано утверждение, что изложенные меры доверия соответствуют требованиям доверия.

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

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

 





©2015- 2017 megalektsii.ru Права всех материалов защищены законодательством РФ.