Основы построения и эксплуатации защищенных телекоммуникационных систем

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

Структура функциональных требований

Класс

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

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

Семейство

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

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

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

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

В описаниях семейств сформулированы также требования аудита. Требования аудита содержат информацию для авторов  ПЗ/ЗБ, помогающую выбрать необходимые аудиторские функции. Эти требования включают функции безопасности различного уровня детализации, поддержанные компонентами аудита безопасности семейства FAU_GEN. Запись аудита может предусматривать действия, которые раскрываются в терминах: минимальный - успешное использование механизма безопасности; базовый - любое использование механизма безопасности, включая использование информации признаков безопасности; детализированный - контроль любых изменений конфигурации механизма безопасности, включая оценку фактической ценности конфигурации до и после изменения.

Компонент

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

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

Элемент

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

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

При использовании ПЗ/ЗБ не разрешается  выбирать только один или большее  количество элементов из компонента. Для включения в ПЗ/ЗБ должен быть отобран полный набор элементов компонента.

В ОК принята уникальная короткая форма названия (имени) функционального  элемента. Например, требование FDP_IFF. 4.2 читается следующим образом: F – функциональное требование, DP – класс «Защита Данных Пользователя», IFF – семейство «Функции Управления Информационным Потоком», 4 – 4-ый компонент, названный «Частичное Устранение Незаконных Информационных Потоков», 2 – 2-ой элемент компонента.

Классы и семейства функциональных требований сгруппированы на основе определенной функции или цели и представлены в ОК в алфавитном порядке. Всего в ОК 9 классов, 76 семейств, 184 компонента и 380 элементов.

Класс FAU (Аудит Безопасности) состоит из 12 семейств, содержащих требования по распознаванию, регистрации, хранению и анализу информации, связанной с действиями, относящимися к безопасности ОО.

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

Класс FDP (Защита Данных Пользователя) включает 15 семейств, определяющих требования для функций безопасности ОО и политики функции безопасности ОО, связанной с защитой данных пользователя. Класс FDP подразделен на пять групп семейств, которые адресованы защите данных пользователя в пределах ОО в процессе ввода, вывода и хранения информации.

Класс FIA (Идентификация и Аутентификация) включает девять семейств. Семейства в этом классе содержат требования для функций, предназначенных для установления и проверки требуемой идентичности пользователя. Эффективность других классов требований (например, Защита Данных Пользователя, Аудит Безопасности) зависит от правильной идентификации и аутентификации пользователей.

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

Класс FPT (Защита Функций Безопасности) включает 22 семейства функциональных требований, которые касаются целостности и контроля механизмов, обеспечивающих ФБ, и целостности и контроля данных ФБ. Может показаться, что семейства в этом классе дублируют компоненты в классе FDP (Защита Данных Пользователя); они могут даже быть реализованы, используя те же самые механизмы. Однако, класс FDP сосредотачивается на защите данных пользователя, в то время как класс FPT – на защите данных ФБ. Фактически, компоненты от класса FPT необходимы даже при отсутствии любой защиты данных пользователя, обеспечивая доверие осуществлению политики, определенной в ПЗ/ЗБ.

Класс FRU (Использование Ресурса) включает три семейства, которые определяют готовность требуемых ресурсов к обработке и/или хранению информации.

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

Класс FTP (Надежный Маршрут/Канал) включает два семейства, которые содержат требования по обеспечению надежного маршрута связи между пользователями и ФБ и надежного канала связи между ФБ, имеющих следующие общие характеристики:

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

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

В отличие от функциональных требований, семейства гарантии – все линейно  иерархические, то есть при наличии более чем одного компонента, компонент 2 требует больше, чем компонент 1, в терминах определенных действий, определенного доказательства или строгости действий или доказательств.

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

1. Элементы действия Разработчика. Этот набор действий обязательно включает поставку демонстрационного материала, упомянутого в следующем наборе элементов. Требования для действий разработчика идентифицированы путем добавления к номеру элемента в конце буквы «D».
2. Элементы представления и содержания свидетельства (требуемое свидетельство, что свидетельство должно демонстрировать, какую информацию свидетельство должно передать). Требования по содержанию и представлению свидетельств идентифицированы путем добавления к номеру элемента в конце буквы «C».
3. Элементы действия Оценщика. Этот набор действий обязательно включает подтверждение того, что свидетельство выполняет требования, предписанные в предыдущем наборе элементов, и может включать действия или анализ, которые должны быть выполнены в дополнение к тому, что уже сделано разработчиком. Требования для действий оценщика идентифицированы путем добавления к номеру элемента в конце буквы «E».

Всего в разделе «Требования  гарантии оценки ОО» 7 классов, 25 семейств, 72 компонента.

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

Класс ADO (Поставка и Действие) состоит из двух семейств и определяет требования для мер, процедур и стандартов, связанных с безопасной поставкой, установкой и эксплуатацией ОО, гарантируя, что безопасность ОО не будет поставлена под угрозу в процессе его передачи, установки, запуска и функционирования.

Класс ADV (Разработка) состоит из шести семейств и определяет требования для пошаговой отработки ФБ от краткой спецификации ОО в ЗБ до фактического выполнения. Каждое из заканчивающихся представлений ФБ обеспечивает информацию, помогающую оценщику определить, были ли функциональные требования к ОО выполнены.

Класс AGD (Документы Руководства) состоит из двух семейств и определяет требования, направленные на способность понимания, охват и законченность эксплуатационной документации, представленной разработчиком. Эта документация, которая содержит две категории информации, для конечных пользователей и для администраторов, является важным фактором безопасной эксплуатации ОО.

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

Класс ATE (Тестирование) состоит из четырех семейств и формулирует требования для объема, глубины и вида тестирования, которые демонстрируют, что ФБ удовлетворяет по крайней мере функциональным требованиям безопасности.

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

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

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

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