Общие критерии

В 1983 и 1985 годах Национальный институт стандартов и технологий США (NIST) и Агентство национальной безопасности (NSA) опубликовали «Оранжевую книгу» (англ. Trusted Computer System Evaluation Criteria, TCSEC), — стандарт оценки способности компьютерных систем защищаться от атак^[5].

Европа в 1991 году на основе TCSEC разработала собственные критерии оценки — англ. Information Technology Security Evaluation Criteria (ITSEC), устранённые недостатки которых позволили повысить эффективность анализа рисков^[6].

В 1993 году Канада представила свой стандарт CTCPEC (англ. Canadian Trusted Computer Product Evaluation Criteria), а признание сертификатов оставалось в рамках соглашений между странами^[7].

В Европе действует соглашение SOG-IS, а с 1999 года Общие критерии закреплены в виде международного стандарта ISO 15408, охватывающего государства — участники соглашения CC-MRA (Common Criteria Mutual Recognition Arrangement). Помимо 17 подписантов, ещё 9 стран признают данные сертификаты^[8].

Общие критерии служат ориентиром для разработки и проверки продуктов и систем информационных технологий, обрабатывающих данные различного рода. Их цель — защита от несанкционированного раскрытия, изменения или потери доступности информации (конфиденциальность, целостность и доступность). Учитываются риски как от человеческих действий, так и не связанных с участием человека^[6].

Оцениваемыми могут быть компьютерные сети, операционные системы, распределённые системы, прикладные программные комплексы и др. Система оценивается в контексте предполагаемого использования по двум категориям требований: функциональные и требования гарантии^[6].

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

• Конечные пользователи — могут оценивать, удовлетворяет ли продукт их требованиям, по результатам сертификации.
• Разработчики — используют Общие критерии для формализации требований безопасности к продукту.
• Оценщики — могут использовать критерии для проверки соответствия продукта целям и формальному профилю. Стандарт определяет перечень действий, но не устанавливает обязательные процедуры^[6].

Общие критерии описаны в трёх взаимосвязанных документах:

Введение и общая модель

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

TI — информационные технологии.

TOE (англ. Target Of Evaluation) — объект оценки. Это продукт или система, прошедшие сертификацию, с сопутствующей документацией для администратора и пользователя.

TSF (англ. TOE Security Functions) — совокупность функций безопасности объекта оценки.

Функциональные требования безопасности

каталог компонентов безопасности, организованных по классам и семействам.

Требования по гарантии безопасности

перечень требований к разработчику и действиям оценщика.

Функциональные требования безопасности — это перечень спецификаций к функциям безопасности, объединённых в 11 классов, каждый из которых разбит на семейства и компоненты^[9].

• FAU — аудит безопасности: 6 семейств (распознавание, регистрация, хранение и анализ действий безопасности).
• FCO — коммуникации: контроль непризнания отправки и получения.
• FCS — криптографическая поддержка: высший уровень защиты на основе криптографии (2 семейства: управление ключами, генерация ключей).
• FDP — защита пользовательских данных: 8 семейств по работе с пользовательской информацией.
• FIA — идентификация и аутентификация: 6 семейств (идентификация, аутентификация, управление доступом).
• FMT — администрирование безопасности: 6 семейств по определению ролей и управляющих функций.
• FPR — защита персональных данных: предотвращение мошеннического раскрытия или использования личности.
• FPT — защита объекта оценки: требования к функционированию средств безопасности самой TOE.
• FRU — управление ресурсами: доступность через устойчивость, распределение и приоритет сервисов.
• FTA — контроль доступа: контроль установления соединения пользователя.
• FTP — доверенные пути и каналы: поддержка защищённых каналов связи.

Разработчик может выбирать необходимые компоненты в зависимости от функциональности продукта; возможно добавление новых при необходимости. Например, для сертификации биометрических решений добавляются специализированные семейства — как SPOD («обнаружение подделки биометрических данных»)^[10].

Эта категория охватывает меры проверки переданных материалов, документации и самого продукта. Для разработчика это перечень доказательств, которые он должен подготовить, а для оценщика — список действий для подтверждения соответствия^[11].

Список представлен классами, каждый отражает определённую область, разбитую на семейства и компоненты различной глубины (именуются Axx):

• ADV — с момента спецификации до реализации TOE.
• ACO — учёт взаимодействия с внешними сертифицированными компонентами.
• AGD — требования к пользовательской документации.
• ALC — процессы жизненного цикла, в том числе устранение выявленных дефектов.
• APE — полнота профиля защиты.
• ASE — техническая состоятельность оценки объекта.
• ATE — достаточность тестирования.
• AVA — идентификация уязвимостей на всех этапах работы.

По результатам оценки присваивается один из семи уровней гарантии (Evaluation Assurance Level — EAL1...EAL7), соответствующий минимальному набору требований ^[12]. Каждый следующий уровень включает требования предыдущего. Уровни отражают баланс между степенью доверия и затратами при реализации:

• EAL1 — минимальный (без участия разработчика, охватывает только явно известные угрозы).
• EAL2 — требует передачи информации о спецификациях и тестах.
• EAL3 — выявляются очевидные уязвимости.
• EAL4 — компромисс между безопасностью и затратами, не требует специальной экспертизы.
• EAL5 — включает анализ функций безопасности на основании всей документации.
• EAL6 — для решений с высокими рисками.
• EAL7 — максимальный, предполагает формальную спецификацию и высокий уровень требований.

Профиль защиты — это документ, определяющий требования безопасности для класса продуктов вне зависимости от их реализации, который можно использовать повторно в схожих проектах^[6]. Структура профиля включает:

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

Право выдачи сертификатов имеют только страны — участники соглашения CC-MRA, они же определяют приём новых членов^[13]. Так, Индия стала 17-м участником соглашения в 2013 году^[14].

Оценку производит независимая лаборатория, аккредитованная государственным органом страны-участника CC-MRA^[3].

США

программу координирует NSA в рамках NIAP —National Information Assurance Partnership.

Франция

по закону ответственна Агентство национальной безопасности информационных систем (ANSSI); она лицензирует Центры оценки (CESTI) и выдаёт итоговый сертификат.

Сертификация проходит в три этапа:

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

Вовлечение требований безопасности на ранних фазах разработки продукта позволяет снизить количество уязвимостей и повысить его надёжность. Эксперты отмечают, что внедрение практик по Общим критериям способствует экономии времени и ресурсов, снижая дублирующие процессы^[15].

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

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

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

На практике требования безопасности зачастую формулируются слишком поверхностно, а заказчики и разработчики не всегда могут однозначно определить эти требования. Сложности возникают и с управлением ими на протяжении жизненного цикла продукта^[17].

Общие критерии допускают неоднозначные трактовки, их реализация требует значительных ресурсов и подготовки. Многие отмечают высокую сложность стандарта, что увеличивает затраты на подготовку специалистов для его применения^[18].

Стандарт в целом недостаточно прозрачен для неспециалистов, многие элементы трудно документируются в рамках привычных процессов разработки^[19].

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

Уровни сертификации редко применяются в практике промышленности, поскольку методология стандарта часто не стыкуется с внутренними процессами разработки. Соответственно ценность сертификации может быть неочевидна ни для покупателей, ни для производителей ПО^[20].

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

Часть методик (например, по Taguchi) строится на диаграммах вариантов использования, отражающих требования безопасности на всех этапах проектирования продукта^[15]. Такой подход предполагает формализацию угроз, целей и требований безопасности через метамодель стандарта. Для визуализации и документирования используются специализированные графические инструменты (например, open-source UML-средства).

Методики (в частности, по Vetterling) предусматривают интеграцию требований ОК во все фазы жизненного цикла проекта, от планирования до внедрения, при этом основной упор делается на итеративную оценку каждого результата^[21]. Это позволяет своевременно доводить документацию до необходимого уровня детализации, соответствующей выбранному EAL, и избегать большой доли предписываемых несогласованностей.

Существуют подходы (например, Romero-Mariona), при которых требования безопасности ОК «проецируются» на архитектурные элементы программной системы. На их основе генерируются спецификации систем, тестовые наборы и итоговые отчёты^[22]. Иные методики предполагают расширение формата целей безопасности для учёта программных уязвимостей и связей между ними.