Контрольные вопросы

1. Что такое «Оранжевая книга»?

2. В чем заключаются отличия класса А от класса В стандарта "Оранжевая книга"?

3. Какие руководящие документы по вопросу информационной безопасности действуют в РФ?

4. Какие существуют категории информации согласно руководящим документам РФ?

5. На основании каких признаков выделяется группа АС?

Лекция 3. Единые критерии безопасности информационных технологий (гост р исо 15408)

Наиболее актуальный стандарт — ГОСТ Р ИСО 15408.

Разработкой данного стандарта занималась международная организация по стандартизации ISO. Стандарт разрабатывался в 1993-1999 годах, первая версия появилась в 1996 году. В данном документе рассматривается не только IT-продукт, но и процесс разработки. Пользователями данного документа являются три группы специалистов: потребители, верификаторы (evaluators) и разработчики.

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

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

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

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

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

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

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

Введение содержит идентификатор профиля и обзор содержания.

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

Раздел описание среды эксплуатации содержит описание среды функционирования с точки зрения безопасности. Он состоит из следующих подразделов:

• условия безопасности;

• угрозы безопасности – описание внешних угроз;

• политика безопасности – описание правил политики безопасности реализованных в ИТ-продукте.

Раздел «Задачи защиты» отражает потребности потребителей в противодействии угрозам и защите IT-продукта. Он состоит из следующих подразделов:

• защита IT-продукта;

• задачи, которые могут быть решены с помощью IT-продукта;

Раздел требования безопасности содержит список требований, которым должен удовлетворять ИТ-продукт. Он содержит два подраздела:

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

• подраздел требований адекватности, содержащий ссылки на требования адекватности стандарта;

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

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

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

Раздел «Обоснования» состоит из следующих подразделов:

- обоснования задач защиты;

- обоснование требований безопасности. Данный подраздел показывает, что требования безопасности позволяют эффективно решить задачи защиты поскольку:

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

б) требования безопасности являются согласованными (не противоречащими);

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

г) выбранный набор требований и уровень адекватности соответствует задачам защиты.

Взаимосвязь всех вышеуказанных компонентов приведена на Рис. .

Задание по безопасности(Security Task)

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

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

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

На Рис. приведена схема взаимосвязи между компонентами, дополненная с учетом задания по безопасности.

Рис. 3.1. Взаимосвязь компонентов профиля защиты

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

Единые критерии. Функциональные требования.

Функциональные требования задаются следующим образом:

Классы (11 шт.) → Разделы → Требования

Классы требований:

1. Аудит;

2. Подтверждение приема/передачи информации;

3. Криптография;

4. Защита информации;

5. Идентификация/Аутентификация;

6. Управление безопасностью;

7. Конфиденциальность работы в системе;

8. Надежность средств защиты;

9. Контроль за использованием ресурсов;

10. Контроль доступа к системе;

11. Прямое взаимодействие (Trusted Path).

Требования в одном разделе упорядочены → при задании профиля защиты указывается само требование → может быть более или менее жесткое требование. Требования упорядочены частично.

Рассмотрим эти классы подробнее:

1. Аудит

Автоматическое реагирование на попытки нарушения безопасности;

Регистрация и учет событий.

Анализ протокола аудита.

Доступ к протоколу аудита.

Отбор событий для регистрации и учета.

Протокол аудита.

2. Подтверждение приема и передачи информации

Предотвращение отречения от факта передачи информации:

1. подтверждение факта передачи информации по требованию;

2. автоматическое подтверждение факта передачи информации;

Предотвращение отречения от факта получения информации:

1. подтверждение факта получения информации по требованию;

2. автоматическое подтверждение факта получения информации.

3. Криптография

Управление ключами:

1. генерация ключей заданного размера;

2. распределение ключей;

3. осуществление доступа к ключам;

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

Криптографические средства.

4. Защита информации:

Политики управления доступом;

Средства управления доступом;

Аутентификация информации:

1. Подтверждение аутентификации информации, содержащейся в объекте доступа (нет подлога и искажения);

2. Аутентификация информации с идентификацией субъектов и осуществлением проверки подлинности;

Экспорт информации из системы:

1. Без атрибутов безопасности;

2. Вместе с атрибутами безопасности;

Политики управления информационными потоками:

1. Для частичного;

2. Для всего;

Средства управления информационными потоками:

1. Управление на основании атрибутов субъектов и объектов;

2. На основании иерархии атрибутов безопасности (модели Белла-ЛаПаудуллы);

3. Контроль скрытых информационных потоков;

4. Частичный запрет скрытых информационных потоков;

5. Полный запрет скрытых информационных потоков;

6. Мониторинг скрытых информационных потоков и ограничение их информационной способности;

Импорт информации.

Защита информации при передаче по внутренним каналам.

1. Базовая защита;

2. Передача данных с различными атрибутами безопасности;

3. Контроль целостности;

4. Контроль целостности с различными атрибутами;

Уничтожение остаточной информации:

1. Для определенного множества объектов при их создании и удалении;

2. Для всех объектов при их создании и удалении;

Откат (RollBack):

3. По отношению к ограниченному количеству информации;

4. По отношению ко всему количеству информации;

Контроль целостности информации в процессе хранения:

1. Обнаружение нарушений целостности;

2. Обнаружение нарушений и определение реакции на ошибки;

Защита внутрисистемной передачи информации при использовании внешних каналов.

Целостность внутрисистемной передачи информации при использовании внешних каналов:

1. Повторная передача;

2. Определение каналов информации.

5. Идентификация/Аутентификация:

Реакция на неудачные попытки аутентификации:

Средства идентификации и аутентификации должны перестать воспринимать попытки аутентификации после заданного количества неудач.

Атрибуты безопасности пользователей.

Аутентификационные параметры.

Аутентификация пользователей:

1. Обязательная аутентификация;

2. Распознание поддельных аутентификационных параметров;

3. Использование одноразовых аутентификационных параметров;

4. Использование множества параметров;

5. Повторная аутентификация;

Идентификация пользователей:

1. Обязательная идентификация;

2. Невозможность осуществления действий без идентификации;

Соответствие пользователей и субъектов доступа.

6. Управление безопасностью:

Управление средствами защиты.

Управление атрибутами безопасности.

Управление параметрами и конфигурацией средств защиты.

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

Ограничение времени действия атрибутов безопасности.

Требования к административным ролям:

1. Использование ролей;

2. Упорядочение ролей;

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

7. Конфиденциальность работы в системе:

Анонимность пользователей:

1. Анонимность субъектов;

2. Анонимность идентификаторов пользователей для средств защиты;

Использование псевдонимов (Alias):

1. Контроль действий анонимных пользователей с помощью псевдонимов (Гость, Администратор);

2. Установление личности пользователя по псевдониму;

3. Назначение псевдонимов в соответствии с правилами;

Анонимность сеанса работы в системе.

Защита от мониторинга сеансов работы в системе:

1. Защита от мониторинга;

2. Рассосредоточение критической информации между компонентами СЗ;

3. Запрет СЗ на запрос конфиденциальной информации у пользователя;

4. Мониторинг использования ресурсов системы только при наличии полномочий.

8. Надежность средств защиты:

Тестирование аппаратно-программной платформы.

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

Защита от сбоев.

Готовность средств защиты к обслуживанию удаленных клиентов.

Готовность к обслуживанию удаленных клиентов с заданной вероятностью (коэффициент готовности).

Конфиденциальность передаваемой информации при работе с удаленными клиентами.

Целостность передаваемой информации при работе с удаленными клиентами:

1. Обнаружение искажений;

2. Обнаружение и исправление искажений;

Защита внутренних каналов информационного обмена между средствами защиты:

1. Наличие средств безопасности;

2. Разделение трафика средств защиты и трафика приложений;

3. Контроль целостности информации при взаимодействии средств защиты;

Физическая защита:

1. Обнаружение физических атак;

2. Уведомление администратора;

3. Активное противодействие атакам;

Безопасное восстановление после сбоев:

1. Ручное;

2. Автоматическое;

3. Автоматическое с уменьшением потерь;

4. Автоматическое путем осуществления отката в безопасное состояние;

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

Контроль взаимодействий.

Разделение доменов:

1. Выделение отдельных доменов для СЗ;

2. Выделение отдельных доменов для функций СЗ;

3. Выделение отдельных доменов для всех функций СЗ;

Синхронизация:

1. Подтверждение приема информации;

2. Синхронизация состояний у участников в ходе осуществления обмена информацией;

Время;

Использование средств защиты надежного таймера.

Согласованность обмена информацией между средствами защиты.

Корректное преобразование информации при передаче.

Репликация информации, используемой СЗ.

Самотестирование средств защиты.

9. Контроль за использованием ресурсов:

Отказоустойчивость:

1. Обеспечение работоспособности на заданном уровне при возникновении сбоев;

2. Обеспечение нормальной работы в случае возникновения указанных сбоев;

Распределение ресурсов на уровне приоритетов (CPU time, memory, и т.д.):

1. Распределение не всех ресурсов;

2. Распределение всех ресурсов;

Квотирование ресурсов

10. Контроль доступа к системе:

Ограничение на использование атрибутов безопасности:

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

2. В зависимости от атрибутов безопасности пользователя;

Ограничение числа одновременных сеансов.

Блокировка сеанса работа с системой:

1. Вручную;

2. Автоматическое завершение сеанса;

Объявления, предупреждения, приглашения и подсказки.

Протокол сеансов работы пользователей.

Управление сеансами работы с системой.

11. Прямое взаимодействие (Trusted path):

Между средствами защиты.

Доверенное взаимодействие системы с пользователем.

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

Требования адекватности позволяют определить, насколько выполняются требования функциональности.

Мы заменяем характеристику продукта характеристикой технологии его создания.

Классы адекватности:

1. Управление проектом;

2. Дистрибуция (распределение);

3. Разработка;

4. Документация;

5. Ход проекта разработки;

6. Тестирование;

7. Анализ защиты.

Шкала: EAL - evaluated assurance scheme.

Существует семь уровней доверия:

Функциональное тестирование;

Структурное тестирование;

Методическое тестирование;

Методическое тестирование, разработка и анализ;

Полуформальные методы тестирования;

Полуформальные методы верификации разработки и тестирования;

Формальные методы верификации разработки и тестирования.

Классы адекватности:

1. Управление проектом.

Средства управления проектом:

1. Применение автоматизированных средств;

2. Полная автоматизация управления проектом и контроля версий;

Управление версиями:

1. Нумерация версий;

2. Идентификация компонентов;

3. Контроль целостности версий;

4. Авторизация разработчиков при обновлении версий;

5. Контроль целостности и подлинности дистрибутива;

Конфигурация проекта:

1. Основные компоненты проекта;

2. Обнаруженные ошибки и уязвимости;

3. Инструментальные средства разработки.

2. Дистрибуция – распространение:

Поставка:

1. Регламентация поставки;

2. Обнаружение искажений;

3. Защита от искажений во время поставки;

Установка, настройка, запуск:

1. Регламентация установки, настройки, запуска;

2. Протоколирование установки, настройки, запуска.

3. Разработка:

Общие функциональные спецификации:

1. Неформальные спецификации для СЗ;

2. Неформальные спецификации для всех интерфейсов СЗ;

3. Полуформальные спецификации для СЗ;

4. Формальные спецификации для СЗ;

Архитектура защиты:

1. Описание архитектуры;

2. Соответствие архитектуры ПБ;

3. Полуформальное описание архитектуры;

4. Соответствие полуформального описания архитектуры и ПБ;

5. Формальное описание и его соответствие ПБ;

Форма представления продукта на сертификацию:

1. Описание реализации ограниченного подмножества средств защиты;

2. Полное описание всех СЗ;

3. Структурированное описание всех СЗ;

Структура СЗ:

1. Использование модульного подхода;

2. Использование иерархии модулей;

3. Минимизация сложности структуры СЗ;

Частные спецификации средств защиты:

1. Неформальные частные спецификации СЗ;

2. Полуформальные частные спецификации СЗ;

3. Формальные частные спецификации СЗ;

Соответствие описаний различного уровня:

1. Неформальное подтверждение соответствия;

2. Полуформальное подтверждение;

3. Формальное доказательство;

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

1. Неформальное описание ПБ;

2. Полуформальное описание ПБ;

3. Формальная модель ПБ.

4. Документация:

Руководство администратора (описывает администрирование СЗ).

Руководство пользователя (описывает использование СЗ).

5. Процесс разработки:

Безопасность среды разработки:

1. Применение мер безопасности при разработке;

2. Подтверждение достаточности мер безопасности;

Исправление ошибок и устранение уязвимостей:

1. Исправление ошибок и устранение уязвимостей;

2. Регулярное исправление ошибок и устранение уязвимостей;

3. Гарантированное исправление ошибок и устранение уязвимостей в течение заданного времени;

Технология разработки:

1. Определенная разработчиком технология разработки;

2. Использование стандартизированной технологии;

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

Средства разработки (СР):

1. Использование ограниченного набора СР;

2. Использование ограниченного набора СР, отвечающего стандарту;

3. Использование СР, отвечающего стандарту.

6. Тестирование:

Полнота тестирования (множество входных компонентов):

1. Обоснование полноты;

2. Анализ полноты (объяснить);

3. Строгий анализ (доказательство);

Глубина тестирования:

1. Тестирование на уровне архитектуры;

2. Функциональные спецификации;

3. Реализация;

Методика тестирования:

1. Функциональное тестирование и протоколирование результатов тестов;

2. Тестирование в соответствии с определенной методикой;

Независимое тестирование (проводимое независимой стороной):

1. Готовность продукта к независимому тестированию;

2. Избирательное независимое тестирование;

3. Полное независимое тестирование.

7. Анализ защиты:

Анализ скрытых каналов:

1. Поиск и документирование СКУИ;

2. Поиск СКУИ на основе определенных методов;

3. Полный поиск СКУИ;

Анализ возможностей неправильного использования СЗ:

1. Анализ руководств администратора;

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

3. Независимый анализ возможностей неправильного использования СЗ;

Анализ стойкости СЗ.

Анализ продукта на наличие уязвимостей:

1. Выявление уязвимостей разработчиком;

2. Независимый анализ;

3. Систематический анализ уязвимостей;

4. Исчерпывающий анализ уязвимостей.

Единые критерии. Уровни адекватности

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

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

2. Структурное тестирование дополняет первый уровень:

• появляются требование №2 в группе управления версиями;

• появляется требование по поставке;

• архитектура защиты (требование №1);

• полнота и методика тестирования (требование №1);

• анализ стойкости и поиск уязвимостей (требование №1).

3. Методическое тестирование. Дополняет второй уровень:

• появляется требование №3 к управлению версиями;

• конфигурация проекта (требование №1);

• архитектура защиты, полнота тестирования, независимое тестирование (требование №2);

• безопасность среды разработки, глубина тестирования, анализ возможностей неправильного использования (требование №1).

4. Методическое тестирование, разработка и анализ дополняет третий уровень:

• средства управления проектом, форма представления продукта, частные спецификации, ПБ, технология и средства разработки (требование №1);

• управление версиями (требование №4);

• конфигурация проекта, поставка, общие функциональные спецификации, анализ возможностей неправильного использования, анализ на наличие уязвимостей (требование №2).

5. Полуформальные методы тестирования дополняет четвертый уровень:

• структура средств защиты, анализ СКУИ (требование №1);

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

• форма представления продукта, соответствие описаний различного уровня, ПБ, технология и средства разработки, глубина тестирования (требование №2).

6. Полуформальные методы верификации разработки и тестирования. Дополняет пятый уровень:

• средства управления проектом, структура средств защиты, частные спецификации средств защиты, безопасность среды разработки, методика тестирования, анализ СКУИ (требование №2);

• управление версиями (требование №5)

• архитектура защиты, анализ на наличие уязвимостей (требование №4);

• форма представления продукта, средства разработки, полнота тестирования, анализ возможностей неправильного использования (требование №3).

7. Формальные методы верификации разработки и тестирования. Дополняет шестой уровень до максимума:

• поставка, структура средств защиты, соответствие описаний различного уровня, ПБ, технология разработки, глубина тестирования, независимое тестирование (требование №3);

• общие функциональные спецификации (требование №4);

• архитектура защиты (требование №5).

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

Сертификация средств защиты в Российской Федерации

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

Система сертификации в РФ приведена на Рис. , где НСД – несанкционированный доступ к информации, НДВ – недокументированные возможности, РДВ – реальные декларированные возможности.

Рис. 3.3. Система сертификации в РФ

При подаче заявки на сертификацию ИТ-продукта во ФСТЭК продукт сначала передается органам сертификации, а затем тестируется в испытательных лабораториях. Результаты тестирования передаются органам сертификации, которые подтверждают соответствие ИТ-продукта профилю защиты (см. рис. 3.4).

Рис. 3.4. Схема сертификации ИТ-продукта

Анализ стандартов информационной безопасности.

Параметры для сравнения:

1. Универсальность определяется множеством ИТ-продуктов, к которым применимы стандарты.

2. То, каким образом требования стандарта инвариантно сформулированы по отношению к средствам защиты.

Информационные технологии эволюционируют → СЗ эволюционируют → Должны изменяться требования!

Эту характеристику называют гибкостью.

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

4. Реализуемость требований стандарта на практике.

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