Проект

Общее

Профиль

Действия
История

Wiki » ISM »

Оценочные стандарты в информационной безопасности

Введение

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

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

Эта тема отвечает на вопрос «соответствует ли ваша система требованиям безопасности?» — в отличие от стандартов управления (4. Стандарты управления), которые отвечают на вопрос «как выстроить процесс управления ИБ?».

Зачем нужны стандарты в области ИБ

Стандарт — это обобщение опыта лучших специалистов в своей области. В ИБ стандарты решают три задачи, без которых рынок защищённых продуктов не может функционировать нормально.

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

Все стандарты ИБ делятся на две большие группы.

Оценочные стандарты отвечают на вопрос: «Соответствует ли ваша ИС требованиям безопасности?» Они задают классификацию систем по уровню защищённости. К ним относятся «Оранжевая книга», ITSEC и ISO/IEC 15408 («Общие критерии»).

Стандарты-спецификации отвечают на вопрос: «Как обеспечить информационную безопасность?» Они регламентируют методы и средства защиты. К ним относятся рекомендации X.800 и ISO/IEC 27001.

ISO/IEC 27001 и построение СУИБ подробно рассмотрены в теме 4. Стандарты управления.

«Оранжевая книга» (TCSEC, 1983)

Стандарт «Критерии оценки доверенных компьютерных систем» (TCSEC) был разработан Министерством обороны США в 1983 году. За характерный цвет обложки он получил неофициальное название «Оранжевая книга» и стал первым в истории общедоступным оценочным стандартом в области ИБ.

Именно в «Оранжевой книге» впервые в открытой литературе появились понятия, без которых невозможно представить современную ИБ: «политика безопасности», «монитор безопасности обращений», «администратор безопасности».

Структура требований

Все требования «Оранжевой книги» сгруппированы в три раздела.

Политика безопасности. Система должна поддерживать точно определённую политику. Доступ субъектов к объектам определяется на основе идентификации и правил управления доступом. Объектам присваиваются метки безопасности, задающие степень конфиденциальности и режимы доступа. При необходимости применяется мандатное управление доступом.

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

Гарантии. Средства защиты содержат независимые аппаратные или программные компоненты, проверяющие корректность работы самих механизмов защиты. Средства контроля полностью независимы от средств защиты. Защита непрерывна на протяжении всего жизненного цикла ИС.

Классы защищённости: подробная характеристика

«Оранжевая книга» вводит четыре группы и семь классов. Уровень защищённости возрастает от D к A.

Группа D — минимальная защита

К группе D относятся системы, которые были представлены для сертификации по требованиям одного из более высоких классов, но не прошли испытания. Это не «базовый» уровень защиты — это фактически признание того, что система не соответствует никаким формальным требованиям безопасности.

Группа содержит единственный класс D1.

Примеры систем класса D1: ранние версии MS-DOS, системы без разграничения доступа, одиночные персональные компьютеры без парольной защиты.

Группа C — дискреционная защита

Группа C характеризуется наличием дискреционного управления доступом (DAC — Discretionary Access Control) — механизма, при котором владелец ресурса сам определяет, кому и какой доступ предоставить. Обязательна регистрация действий субъектов.

Класс C1 — дискреционная защита

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

Требования к классу C1:
  • наличие механизма идентификации и аутентификации пользователей;
  • разграничение доступа к объектам на уровне пользователей и групп;
  • изоляция данных конкретного пользователя от других пользователей;
  • возможность задавать ограничения доступа к объектам системы.

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

Примеры: ранние версии UNIX с базовыми механизмами разграничения доступа.

Класс C2 — управление доступом

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

Требования к классу C2 (в дополнение к C1):
  • Избирательное управление доступом — права устанавливаются индивидуально для каждого пользователя, а не только для группы;
  • Аудит — обязательная регистрация событий безопасности: входа/выхода пользователей, создания и удаления объектов, изменения прав доступа. Журнал аудита защищён от модификации;
  • Очистка объектов — перед выделением пользователю памяти или дискового пространства система обязана очистить их от данных предыдущего пользователя (механизм «зачистки остатков информации»);
  • Изоляция ресурсов — более строгое разделение процессов и данных разных пользователей.

Класс C2 — исторически наиболее распространённый класс для коммерческих систем. По требованиям C2 в своё время были сертифицированы Windows NT 3.5, Novell NetWare,
ряд версий UNIX.

Группа B — мандатная защита

Группа B реализует мандатное управление доступом (MAC — Mandatory Access Control) — принудительный механизм, при котором уровень доступа определяется не владельцем ресурса, а системой на основе меток безопасности. Владелец файла не может предоставить другому пользователю доступ выше, чем тот допущен по своему уровню секретности.

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

Класс B1 — защита с применением меток безопасности

Класс B1 — минимальный уровень группы B. К требованиям C2 добавляются механизмы мандатного управления доступом.

Требования к классу B1 (в дополнение к C2):
  • Метки безопасности — каждый субъект (пользователь, процесс) и объект (файл, устройство, сегмент памяти) имеет метку безопасности, определяющую уровень конфиденциальности. Типовые уровни в военных системах: Unclassified (несекретно), Confidential (конфиденциально), Secret (секретно), Top Secret (совершенно секретно);
  • Мандатное управление доступом — доступ субъекта к объекту разрешается только если уровень допуска субъекта не ниже уровня конфиденциальности объекта;
  • Маркировка экспортируемых данных — при выводе информации из системы (на принтер, на съёмный носитель, по сети) данные должны сопровождаться меткой безопасности;
  • Неформальная модель политики безопасности — политика должна быть описана и задокументирована, хотя формальных математических доказательств не требуется.

Класс B2 — структурированная защита

Класс B2 существенно повышает требования к архитектурной проработке системы безопасности.

Требования к классу B2 (в дополнение к B1):
  • Формальная модель политики безопасности — политика безопасности должна быть описана с использованием формальных методов и тщательно задокументирована;
  • Мандатное управление доступом на уровне всех субъектов и объектов — включая устройства, каналы связи и разделяемую память;
  • Контроль скрытых каналов передачи информации — система обязана выявлять и нейтрализовывать побочные каналы утечки (например, через изменение производительности системы или загрузки процессора);
  • Структурирование ядра безопасности — в ядре безопасности должны быть явно выделены критичные с точки зрения безопасности элементы;
  • Строго определённый интерфейс ядра безопасности — архитектура и реализация должны допускать тестирование;
  • Управление конфигурацией — ведётся строгий учёт всех компонентов системы безопасности;
  • Уведомление пользователей — система информирует пользователей об изменениях их уровня безопасности;
  • Администратор безопасности — выделенная роль с исключительными полномочиями по управлению безопасностью.

Класс B3 — домены безопасности

Класс B3 — высший в группе B, предпоследний в общей иерархии. Требования приближаются к A1, но без полной формальной верификации.

Требования к классу B3 (в дополнение к B2):
  • Монитор безопасности обращений — реализация монитора, контролирующего все типы доступа субъектов к объектам, является обязательной. Монитор должен быть защищён от постороннего вмешательства, не поддаваться обходу и быть достаточно компактным для полного тестирования и верификации;
  • Минимизация ядра безопасности — ядро содержит исключительно компоненты, реализующие функции защиты. Всё лишнее вынесено за его пределы;
  • Расширенный аудит — средства аудита включают механизмы оповещения администратора безопасности о потенциально опасных событиях в режиме реального времени. Анализ журналов автоматизирован;
  • Доверенный путь — гарантированный защищённый канал связи между пользователем и монитором безопасности при выполнении критичных операций (аутентификация, изменение прав доступа);
  • Средства восстановления — система обязана иметь задокументированные процедуры безопасного восстановления после сбоев;
  • Анализ скрытых каналов — по сравнению с B2, требования к анализу скрытых каналов ужесточаются: необходима оценка их пропускной способности.

Группа A — верифицированная защита

Группа A — высший уровень иерархии «Оранжевой книги». Содержит единственный класс A1.

Класс A1 — верифицированная защита

Функциональные требования класса A1 совпадают с классом B3 — система должна реализовывать все механизмы защиты B3 в полном объёме. Принципиальное отличие A1 — в методе доказательства того, что эти механизмы работают корректно.

Требования к классу A1 (в дополнение к B3):
  • Формальная модель политики безопасности — политика описана с применением строгого математического аппарата;
  • Формальные спецификации верхнего уровня (Formal Top-Level Specification, FTLS) — архитектура системы безопасности описана на формальном языке спецификаций;
  • Формальное соответствие реализации спецификациям — математически доказано, что реализация соответствует формальным спецификациям;
  • Формальный анализ скрытых каналов — проведён исчерпывающий математический анализ всех потенциальных скрытых каналов;
  • Доверенное распространение — установлены строгие процедуры защиты системы при транспортировке и установке у пользователя (защита от подмены компонентов);
  • Мониторинг конфигурации — непрерывный контроль соответствия установленной системы сертифицированной конфигурации.

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

Сводная таблица классов

Класс Группа DAC MAC Аудит Метки Формальная модель Верификация
D1 D — — — — — —
C1 C базовый — — — — —
C2 C строгий — обязателен — — —
B1 B строгий базовый обязателен обязательны неформальная —
B2 B строгий полный расширенный обязательны формальная —
B3 B строгий полный + оповещения обязательны формальная частичная
A1 A строгий полный + оповещения обязательны формальная полная математическая

«Радужная серия» — расширения «Оранжевой книги»

После публикации «Оранжевой книги» стало очевидно, что один документ не может охватить всё многообразие ИТ-систем. С 1983 по 1995 год Министерство обороны США выпустило более 30 дополнительных руководящих документов с обложками разных цветов — они получили общее название «Радужная серия» (Rainbow Series).

Цвет обложки Название (сокращение) Содержание
Красная TNI — Trusted Network Interpretation Интерпретация TCSEC для защищённых компьютерных сетей
Лавандовая TDI — Trusted Database Interpretation Интерпретация TCSEC для защищённых СУБД
Зелёная Password Management Guideline Руководство по управлению паролями
Жёлтая CSC-STD-003 Требования безопасности для компьютерных систем
Голубая Trusted Product Evaluation Процедуры оценки доверенных продуктов
Розовая Rating Maintenance Phase Поддержание уровня безопасности после сертификации
Бирюзовая Glossary of Computer Security Terms Глоссарий терминов компьютерной безопасности

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

Почему «Оранжевая книга» устарела

К середине 1990-х стали очевидны системные недостатки «Оранжевой книги»:

  • угрозы нарушения доступности практически не рассматриваются — фокус на конфиденциальности, в меньшей мере на целостности;
  • «табличный» подход не учитывает специфику конкретных систем;
  • перечислены требуемые механизмы, но не оговорены методы проверки корректности их реализации;
  • распределённые вычислительные системы и сети, ставшие нормой к 1990-м, не учтены;
  • ряд требований сформулирован неоднозначно.

В настоящее время «Оранжевая книга» не применяется для оценки информационных систем и представляет интерес исключительно как исторический документ — но именно она заложила понятийный фундамент всей последующей теории оценки ИБ.

ITSEC: европейские критерии оценки (1991)

Пока США развивали «Радужную серию», европейские страны шли своим путём. В 1991 году Великобритания, Германия, Франция и Нидерланды совместно опубликовали «Критерии оценки безопасности информационных технологий» — ITSEC (Information Technology Security Evaluation Criteria), версия 1.2.

ITSEC стал первым попыткой создать межнациональный оценочный стандарт и прямым предшественником «Общих критериев».

Ключевые отличия от «Оранжевой книги»

ITSEC принципиально пересмотрел подход к оценке, введя разделение, которого не было в TCSEC.

Разделение функциональности и доверия. «Оранжевая книга» связывала набор функций безопасности и глубину их проверки в единый класс: класс B2 означал одновременно и «какие функции есть», и «насколько глубоко они проверены». ITSEC разрывает эту связь. Функциональность описывается отдельно (что система умеет), а уровень доверия — отдельно (насколько глубоко это проверено). Это позволяет, например, сертифицировать продукт с функциями уровня B2 на доверии уровня E2 — в зависимости от контекста применения.

Охват всей триады КДЦ. В отличие от «Оранжевой книги», ITSEC явно включает требования к доступности и целостности наряду с конфиденциальностью.

Применимость к сетям и распределённым системам. ITSEC разрабатывался с учётом реалий 1990-х и охватывает сетевые и распределённые системы.

Уровни доверия ITSEC

ITSEC вводит шесть уровней доверия — от E1 до E6. Нулевой уровень E0 означает отсутствие гарантий (аналог группы D в «Оранжевой книге»).

Уровень Название Суть проверки
E0 Недостаточное доверие Требованиям ни одного уровня не соответствует
E1 Минимальное доверие Наличие цели безопасности и неформальное описание архитектуры; базовое функциональное тестирование
E2 Низкое доверие Неформальное описание детального проекта; тестирование с анализом результатов; конфигурационный контроль и дистрибуция
E3 Среднее доверие Исходный код или схемотехника проверяются оценщиком; тестирование охватывает интерфейсы механизмов безопасности
E4 Высокое доверие Формальная модель политики безопасности; полуформальные функциональные спецификации и описание архитектуры
E5 Очень высокое доверие Тесная связь между детальным проектом и исходным кодом; исчерпывающий анализ скрытых каналов
E6 Максимальное доверие Формальные спецификации функций безопасности и архитектуры; формальное доказательство их соответствия

Функциональные классы ITSEC

Для функциональной части ITSEC вводит десять стандартных классов — F1–F10. Первые пять (F1–F5) соответствуют классам «Оранжевой книги» для облегчения совместимости.

Класс Аналог TCSEC Описание
F1 C1 Дискреционный контроль доступа
F2 C2 Дискреционный контроль доступа + аудит
F3 B1 Мандатный контроль доступа с метками
F4 B2 Структурированная мандатная защита
F5 B3+A1 Высокоструктурированная защита с верификацией
F6 — Высокие требования к целостности данных (для СУБД)
F7 — Высокие требования к доступности (для систем реального времени)
F8 — Целостность при передаче данных (для коммуникационных систем)
F9 — Требования к конфиденциальности при передаче данных
F10 — Сети с требованиями к конфиденциальности и целостности

Классы F6–F10 — принципиальное новшество ITSEC: они закрывают пробел «Оранжевой книги», охватывая системы реального времени, коммуникационные системы и СУБД.

Схема обозначения уровня сертификации по ITSEC

В сертификате по ITSEC уровень записывается как сочетание функционального класса и уровня доверия, например: F3/E3 означает функциональность мандатной защиты (класс F3, аналог B1) с уровнем доверия E3.

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

Применение ITSEC и его судьба

ITSEC применялся в европейских странах с 1991 по конец 2000-х годов. В частности, по ITSEC сертифицировались продукты для государственных нужд в Великобритании, Германии и Франции.

В 1999 году с выходом ISO/IEC 15408 («Общих критериев») ITSEC фактически утратил актуальность — «Общие критерии» вобрали в себя лучшие идеи ITSEC, расширили их и получили статус международного стандарта. Сегодня ITSEC представляет исторический интерес как связующее звено между «Оранжевой книгой» и современными «Общими критериями».

ISO/IEC 15408: «Общие критерии» (1999)

Стандарт ISO/IEC 15408 разрабатывался с 1990 по 1999 год совместными усилиями специалистов Канады, США, Великобритании, Германии, Нидерландов и Франции. Он получил неофициальное название «Общие критерии» (Common Criteria, CC).

В России стандарт принят как ГОСТ Р ИСО/МЭК 15408 и действует с 1 января 2004 года.

«Общие критерии» синтезировали лучшее из TCSEC и ITSEC: от «Оранжевой книги» — строгость требований и иерархию уровней доверия, от ITSEC — разделение функциональности и доверия, охват всей триады КДЦ и применимость к любым типам ИТ-продуктов.

Три части стандарта

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

Часть 2 — Функциональные требования безопасности. Универсальный каталог требований к функциям безопасности: идентификация, аутентификация, управление доступом, аудит, криптографические функции и т.д.

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

Объект оценки и его среда

Объект оценки (ОО) — любой ИТ-продукт или система вместе с руководствами администратора и пользователя. Стандарт применим для трёх категорий пользователей.

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

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

Иерархия требований

Все требования организованы в единую иерархию: класс → семейство → компонент → элемент. Класс — наиболее общая группировка, элемент — неделимая единица
требования.

Два ключевых документа оценки

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

Задание по безопасности (ЗБ, Security Target) — документ производителя, описывающий конкретный продукт и заявленные функции безопасности. Может декларировать соответствие одному или нескольким профилям защиты. ЗБ — фактически техническое задание на подсистему обеспечения ИБ для конкретного объекта оценки.

Оценочные уровни доверия (ОУД)

ОУД — шкала глубины и строгости проверки в ходе сертификации. Семь уровней.

ОУД Название Суть проверки Типичное применение
ОУД 1 Функционально протестированный Базовое тестирование функций безопасности Минимальная уверенность
ОУД 2 Структурно протестированный Тестирование + базовый анализ проекта Коммерческие продукты без исходного кода
ОУД 3 Методично протестированный и проверенный Тестирование + анализ проекта + поиск уязвимостей Широко применяемые коммерческие продукты
ОУД 4 Методично спроектированный, протестированный и проверенный Полный анализ проекта, независимое тестирование, анализ уязвимостей, проверка исходного кода критических функций Практический максимум для коммерческих продуктов
ОУД 5 Полуформально спроектированный и протестированный Полуформальные методы описания проекта Высокозащищённые системы
ОУД 6 Полуформально верифицированный проект и протестированный Полуформальная верификация всего проекта Системы обработки государственной тайны
ОУД 7 Формально верифицированный проект и протестированный Полная математическая формальная верификация Военные и разведывательные системы

Сертификат ОУД 4 означает не «продукт абсолютно безопасен», а «процесс разработки и тестирования соответствует строгим требованиям стандарта, а заявленные функции безопасности независимо проверены». Новые уязвимости появляются постоянно — сертификат фиксирует состояние на момент оценки.

Требования ОУД 4 в части анализа уязвимостей и тестового покрытия напрямую соответствуют практикам безопасной разработки, описанным в теме 12. Безопасность в разработке.

Эволюция оценочных стандартов: от TCSEC к Common Criteria

Каждый стандарт устранял слабости предыдущего:

  • TCSEC (1983) — первый систематический подход, но жёсткий, привязан кконфиденциальности, не учитывает сети.
  • ITSEC (1991) — разделил функциональность и доверие, охватил всю триаду КДЦ, учёл сетевые системы.
  • Common Criteria (1999) — синтез всего лучшего, международный стандарт, гибкие профили защиты, применим к любым ИТ-продуктам.

Сравнение трёх стандартов

Параметр TCSEC «Оранжевая книга» ITSEC ISO/IEC 15408 «Общие критерии»
Год 1983 1991 1999 (актуальная ред. 2022)
Охват угроз Преимущественно конфиденциальность КДЦ полностью КДЦ полностью
Функции и доверие Связаны в один класс Разделены Разделены (ПЗ + ЗБ + ОУД)
Гибкость Фиксированные классы D/C/B/A 10 функциональных классов + 6 уровней доверия Настраиваемые профили для каждого класса продуктов
Распределённые системы Не учтены Учтены Учтены
Правовой статус Военный стандарт DoD (США) Межправительственный (4 страны ЕС) Международный стандарт ISO
В России Не применяется Не применяется ГОСТ Р ИСО/МЭК 15408, используется ФСТЭК
Применение сегодня Только исторический интерес Только исторический интерес Действующий международный стандарт

Что дальше

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

Список литературы и стандартов

Обновлено С. Антошкин 16 дня назад · 9 изменени(я, ий)