Единые критерии безопасности информационных технологий кратко
Обновлено: 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, временные меры).
Читайте также: