Единые критерии безопасности информационных технологий кратко

Обновлено: 04.07.2024

требования доверия – соответствуют пассивному аспекту – предъявляемые к технологии и процессу разработки и эксплуатации.

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

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

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

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

14. Единые критерии безопасности информационных технологий. Проект защиты. Требования безопасности (функциональные требования и требования адекватности).

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

"Общие критерии" включают следующие классы функциональных требований:

1. Идентификация и аутентификация.

2. Защита данных пользователя.

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

4. Управление безопасностью (требования этого класса относятся к управлению атрибутами и параметрами безопасности).

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

6. Доступ к объекту оценки.

7. Приватность (защита пользователя от раскрытия и несанкционированного использования его идентификационных данных).

Основные положения

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

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

———————— à - информационные потоки

- - - - - - - - - - - - - -à - влияние по принципу обратной связи

Рис 2.11. Схема процесса разработки и кавлифакационного анализа ИТ-продукта с точки зрения "Единых критериев"

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

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

· доказательства возможностей ИТ-продукта. пред­ставленные его разработчиком:

· дополнительные сведения, полученные путем про­ведения различных экспертиз.

Процесс квалификационного анализа включает три стадии:

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

2. Анализ проекта защиты на предмет его соответст­вия требованиям профиля защиты, а также полноты, не­противоречивости, реализуемости и возможности ис­пользования в качестве описания ИТ-продукта.

3. Анализ ИТ-продукта на предмет соответствия проекту защиты.

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

Профиль защиты

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

Рассмотрим назначение и содержание разделов про­филя защиты.

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

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

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

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

Среда эксплуатации. Этот раздел содержит описание всех аспектов функционирования ИТ-продукта, связан­ных с безопасностью.

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

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

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

Задачи защиты отражают потребности пользовате­лей в противодействии указанным угрозам безопасности и/или в реализации политики безопасности.

Задачи защиты ИТ-продукта должны быть четко оп­ределены и отражать потребности в противодействии угрозам безопасности и/или в реализации политики безопасности.

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

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

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

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

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

Обоснование требовании безопасности показывает, что требования безопасности позволяют решить задачи защиты, так как:

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

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

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

· выбранный набор требований и уровень адекват­ности могут быть обоснованы.

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

Проект защиты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· требования адекватности соответствуют функцио­нальным требованиям и усиливают их;

· все требования безопасности успешно реализова­ны;

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

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

· указанные функции защиты соответствуют заяв­ленным задачам защиты;

· совокупность указанных функций защиты обеспе­чивает эффективное решение совокупности задач защиты;

· заявленные возможности функций защиты соот­ветствует действительности.

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

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

· все усовершенствования задач защиты по сравне­нию с профилем защиты осуществлены корректно и в направлении их развития и конкретизации;

· все усовершенствования требований безопасности по сравнению с профилем защиты осуществлены корректно и в направлении их развития и конкре­тизации;

· все задачи защиты профиля защиты успешно ре­шены и все требования профиля защиты удовле­творены;

· никакие дополнительно введенные в проект защи­ты специальные задачи защиты и требования безопасности не противоречат профилю защиты.

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

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

По историческим причинам данный стандарт часто называют " Общими критериями " (или даже ОК). Мы также будем использовать это сокращение.

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

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

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

Как и " Оранжевая книга ", ОК содержат два основных вида требований безопасности:

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

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

На рисунке 5.1 представлена взаимосвязь понятий, используемых при оценке и их взаимосвязь

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

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

По ИСО/МЭК 15408 оценка ЗБ/ОО проходит в два этапа:

  • оценка ЗБ: на этом этапе определяют достаточность ОО и среды функционирования;
  • оценка ОО: на этом этапе определяют корректность ОО; как отмечалось ранее, оценка ОО не включает оценку корректности среды функционирования.

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

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

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

Задание по безопасности либо соответствует рассматриваемому ПЗ, либо не соответствует. ИСО/МЭК 15408 не признает "частичное" соответствие. В стандарте приведены содержания ПЗ и ЗБ.

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

На основе ГОСТ Р 15408 ФСТЭК сформировала профили для систем антивирусной защиты и систем обнаружения вторжений . Профили представляют из себя наборы "деталей" ГОСТ Р 15408. Сами "детали" в терминологии ГОСТ 15408 называются компонентами, которые систематизированы в семейства, а те в свою очередь составляют классы. ГОСТ Р 15408 Часть 2 " Функциональные требования " содержит 11 классов, 66 семейств и 135 компонентов, а ГОСТ Р 15408 Часть 3 " Требования доверия " - 8 классов, 44 семейства, 93 компонента. Компоненты могут состоять из нескольких элементов, но компоненты неделимы при формировании профилей защиты и заданий по безопасности.

Обзор

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

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

Центры сертификации

    (или CCRA), которое включает 28 стран на всех континентах и признает сертификацию до уровня EAL 2 защищенных ИТ-продуктов уполномоченными членами CCRA. (или SOG-IS), которая состоит из 15 стран Европы и признает сертификацию общих критериев до уровня EAL 7 безопасных ИТ-продуктов в зависимости от уровня членов SOG-IS.

Обзор соответствия требованиям

Благодаря этой сертификации клиенты могут использовать модуль nShield XC HSM в качестве сертифицированного EN 419 221-5 криптографического модуля для разработки систем, соответствующих регламенту eIDAS.

Аппаратные модули безопасности nShield Connect, nShield Connect+, nShield Solo и nShield Solo+ (HSM) сертифицированы по стандарту EAL4+ (AVA_VAN.5).

Entrust получила сертификат общих критериев для nShield HSM от итальянского сертификационного агентства Organismo di Certificazione della Sicurezza Informatica (OCSI). Эта сертификация OCSI признает nShield HSM в качестве квалифицированных устройств для создания подписей (QSCD). Благодаря этому признанию QSCD модули nShield HSM соответствуют регламенту eIDAS (статья 51, временные меры).

Читайте также: