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

Pause

О́бщие крите́рии (англ. Common Criteria, CC; полное название — Common Criteria for Information Technology Security Evaluation, «Критерии оценки безопасности информационных технологий») — набор международно признанных стандартов, предназначенных для объективной оценки безопасности информационных систем и программного обеспечения. Стандарты выпускаются как серия ISO/IEC 15408 (Международная организация по стандартизации и Международная электротехническая комиссия) и как комплект документов CC:2022, издаваемый правительственными организациями ряда стран[1][2].

Оценка ведётся по единым каталогам требований: функциональные требования описывают, что должна делать защита, а требования доверия — насколько обоснованно доверять её реализации. Разработчик декларирует свойства продукта в документе, который называется заявкой безопасности, либо ориентируется на типовой профиль защиты; аккредитованная лаборатория проверяет соответствие и присваивает один из семи уровней доверия, от EAL1 до EAL7[2][3].

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

Результаты оценки признаются участниками соглашения о взаимном признании CCRA без повторной проверки. Общие критерии легли в основу национальных схем сертификации средств защиты в десятках государств, а с 2024 года — и единой схемы Европейского союза EUCC[4][5].

Общие сведения
Что важно знать
Общие критерии
Область использования информационная безопасность, компьютерная безопасность, сертификация
Дата появления 1996
Место появления Канада, Франция, Германия, Нидерланды, США
Автор понятия редакционная комиссия CCEB, образованная организациями — спонсорами четырёх национальных критериев
Ключевые слова стандарт, оценка соответствия, тестирование программного обеспечения, формальная верификация
Базовые понятия объект оценки, профиль защиты, заявка безопасности, уровень доверия

История

Предшественники

Первой системой критериев оценки защищённых компьютерных систем стали «Критерии определения безопасности компьютерных систем» министерства обороны США. Раннюю редакцию опубликовали 15 августа 1983 года под индексом CSC-STD-001-83, а в декабре 1985 года вышла заменившая её редакция DoD 5200.28-STD[6]. Критерии делили продукты на четыре дивизиона — минимальную защиту (D), дискреционную защиту (C), мандатную защиту (B) и верифицированную защиту (A) — с классами от C1 до A1[6]. Требования наращивались постепенно: для класса B2 требовалась документированная формальная модель политики безопасности, а для высшего класса A1 — формальная спецификация верхнего уровня, проверяемая доказательно[6]. В документах Национального центра компьютерной безопасности США критерии фигурировали под бытовым названием «Оранжевая книга»: например, требования классов именовались там «требованиями дивизионов и классов Оранжевой книги»[7].

undefined

Позднее собственные критерии появились у других государств. Канада в 1989 году выпустила первую версию Canadian Trusted Computer Product Evaluation Criteria, доработанную к январю 1993 года до редакции 3.0e, в которой канадцы попытались совместить американский и европейский подходы[8]. Франция, Германия, Нидерланды и Великобритания совместно подготовили европейские критерии ITSEC, версия 1.2 которых была опубликована Комиссией европейских сообществ 28 июня 1991 года; к ним примыкала методология оценки ITSEM, первая редакция которой датирована сентябрём 1993 года[9][8]. В декабре 1992 года НИСТ и АНБ США выпустили в двух томах проект Federal Criteria; именно этот документ ввёл понятие профиля защиты — набора требований, обращённого не к отдельному продукту, а к классу задач[8].

Тем временем работа над международными критериями началась и в ИСО: с 1990 года её вела рабочая группа WG 3 подкомитета SC 27 объединённого технического комитета JTC 1. Национальные критерии к началу 1990-х годов настолько разошлись, что сосуществование четырёх систем оценки осложняло и разработчикам, и потребителям, поэтому идеи взаимного сближения обсуждались параллельно в нескольких организациях[10].

Создание общих критериев

В июне 1993 года организации — спонсоры канадских, европейских, американских военных и американских гражданских критериев объединили усилия в едином проекте. Представители спонсоров образовали редакционную комиссию CCEB, которая свела четыре национальных документа в один. Между комиссией и рабочей группой WG 3 была установлена постоянная связь: CCEB передавала в ИСО ранние редакции как вклад в разрабатываемый международный стандарт[10]. Всего в проекте участвовали семь правительственных организаций Европы и Северной Америки; в приложении к первому изданию стандарта названы организации Канады (CSE), Франции (SCSSI), Германии (BSI и GISA), Нидерландов (NLNCSA) и США (НИСТ и АНБ)[10].

Первая редакция общих критериев CC v1.0 была завершена в январе 1996 года, и в апреле того же года ИСО одобрила её как проект комитета. В октябре 1997 года вышла редакция CC v2.0, обозначенная как бета-версия; работы с этого момента вела комиссия CCIB, сменившая CCEB[10][8]. 1 декабря 1999 года серию ISO/IEC 15408 утвердили в качестве международного стандарта в трёх частях. Официальное название серии — «Evaluation criteria for IT security»; термин Common Criteria закрепился по традиции, и изданный спонсорами национальный комплект повторял текст стандарта дословно[10].

Развитие стандарта

Серия стандарта пересматривалась по мере накопления опыта оценок. Редакция CC v3.1 выдержала пять исправленных переизданий; последнее, Rev 5, датировано апрелем 2017 года[11]. В августе 2022 года ИСО опубликовала четвёртое издание серии ISO/IEC 15408 (первая часть — 142 страницы), а в ноябре 2022 года организации-спонсоры выпустили синхронизированный с ним комплект CC:2022 — уже в пяти частях с новым номером редакции Rev 1. Одна только часть 1 заняла 167 страниц[12][2]. 19 мая 2026 года издание 2022 года было отозвано и заменено пятым изданием первой части стандарта — ISO/IEC 15408-1:2026 объёмом 138 страниц[1][12].

Вместе со стандартом развивается и общая методика оценки — CEM, документ, задающий методы и активности оценщика. Редакция CEM:2022 выпущена в ноябре 2022 года и издана ИСО как ISO/IEC 18045:2022; её объём составил 471 страницу[13].

Соглашение о взаимном признании

Чтобы сертификаты, выданные в одной стране, принимались в других, участники проекта заключили соглашение о взаимном признании CCRA. Действующая редакция датирована 2 июля 2014 года и ратифицирована 8 сентября 2014 года; она заменила прежнюю редакцию соглашения. Сторонами выступают государства и назначенные ими национальные схемы сертификации; сертификаты и отчёты о валидации признаются без повторной оценки, а понятия сертификации и валидации в соглашении объявлены синонимами. Координацией занимается постоянный комитет управления — Management Committee[4].

Европейский союз пошёл дальше взаимного признания и встроил общие критерии в собственную правовую систему. Регламент (ЕС) 2019/881, известный как акт о кибербезопасности и подписанный 17 апреля 2019 года, создал рамку европейской сертификации продуктов в области кибербезопасности[14]. Исполнительным регламентом (ЕС) 2024/482 от 31 января 2024 года в этой рамке учреждена схема сертификации EUCC, построенная на общих критериях[5].

Структура стандарта

Части стандарта

Комплект CC:2022 состоит из пяти частей. Часть 1 вводит общую модель: понятия объекта оценки, профиля защиты, заявки безопасности и типы соответствия. Часть 2 содержит каталог функциональных требований, часть 3 — каталог требований доверия. Часть 4, появившаяся только в редакции 2022 года, задаёт структуру описания методов и активностей оценки, а часть 5 собирает готовые пакеты требований, включая уровни доверия[2][15][3]. Шестым документом комплекта идёт общая методика оценки CEM:2022[13]. Каждой части присвоен номер серии CCMB-2022-11 с порядковым суффиксом, например CCMB-2022-11-001 у первой части[2].

undefined

Публикуют комплект двенадцать правительственных организаций. Среди них — ASD (Австралия), CSE (Канада), ANSSI (Франция), BSI (Германия), IPA (Япония), NLNCSA (Нидерланды), GCSB (Новая Зеландия), NSRI (Республика Корея), MAECD и CCN (Испания), FMV (Швеция), NCSC (Великобритания), а также АНБ и НИСТ (США)[2]. Документы распространяются свободно на сайте портала общих критериев[2].

Объект оценки и требования

Предметом оценки выступает объект оценки — продукт или система вместе с сопроводительной документацией; он может быть реализован аппаратно, в микропрограммах или программно[2]. В качестве примеров часть 1 называет сетевые устройства, программные приложения, операционные системы, системы виртуализации, интегральные схемы и их криптографические сопроцессоры, приложения для мобильных устройств и базы данных[2]. Разработчик описывает объект в заявке безопасности, где фиксирует проблему безопасности, цели защиты и выбранные из каталогов требования; если заявка опирается на заранее утверждённый профиль защиты, оценка упрощается и для разработчика, и для заказчика[2]. Профили защиты адресованы классу задач, а не конкретному продукту; редакция 2022 года добавила вспомогательные конструкции — PP-модуль и PP-конфигурацию, позволяющие собирать сложные профили из готовых фрагментов[2].

Отдельно стандарт нормирует типы соответствия. Точное соответствие запрещает отклоняться от требований профиля, строгое разрешает лишь усиление, а доказуемое допускает обоснованные замены; дополнительные требования для каждого типа вынесены в отдельные разделы части 1[2].

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

Часть 2 стандарта — каталог функциональных требований к защите, организованный в три уровня: классы, семейства и компоненты. Класс объединяет семейства с общей темой, семейство — компоненты с общим назначением, а компонент задаёт конкретное требование, которое допускает зависимости от других компонентов[16].

undefined

В редакции 2022 года каталог насчитывает десять классов: FAU (аудит безопасности), FCS (поддержка криптографии), FDP (защита данных пользователя), FIA (идентификация и аутентификация) и FMT (управление безопасностью)[16]. Ещё пять классов — FPR (приватность), FPT (защита механизмов самого объекта оценки), FRU (использование ресурсов), FTA (доступ к объекту оценки) и FTP (доверенный маршрут и доверенные каналы)[16]. Семейства и компоненты снабжены примечаниями по применению, которые поясняют, как формулировать и проверять требования в конкретных случаях[16]. Каждому классу присвоен латинский код из трёх букв: например, семейство FIA_UAU относится к аутентификации пользователей, а FMT_MTD — к управлению данными безопасности[16].

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

Требования доверия

Часть 3 зеркально описывает требования доверия — доказательства того, что заявленные функции действительно реализованы и корректны. Классов здесь девять: ASE (оценка заявки безопасности), APE (разработка профиля защиты), ACE (оценка профиля защиты), ADV (разработка), AGD (эксплуатационная документация), ALC (поддержка жизненного цикла), ATE (тестирование), AVA (анализ уязвимостей) и ACO (сборка составных объектов)[17].

undefined

Внутри классов требования сгруппированы в семейства: например, ALC объединяет девять семейств, от управления конфигурацией ALC_CMC до обращения с уязвимостями ALC_FLR, а класс ADV — от описания архитектуры ADV_ARC до моделирования функций защиты[17]. Компоненты нумеруются кодом семейства с порядковым номером: AVA_VAN.1 и AVA_VAN.2 различаются глубиной анализа уязвимостей, ALC_CMC.1 требует лишь маркировки образцов, а ALC_CMC.5 — развитой системы управления конфигурацией[17]. Как и в части 2, требования сопровождаются примечаниями по применению, ориентированными на автора документации и оценщика[17].

Пакеты доверия

Чтобы не собирать требования доверия каждый раз заново, часть 5 стандарта задаёт готовые пакеты. Основной линейкой служат семь уровней доверия EAL[3]. Первые четыре ступени — EAL1 (функционально протестировано), EAL2 (структурно протестировано), EAL3 (методично протестировано и проверено) и EAL4 (методично спроектировано, протестировано и пересмотрено)[3]. Высшие уровни опираются на формальные и полуформальные методы: EAL5 — полуформально верифицированное проектирование и тестирование, EAL6 — полуформально верифицированные проектирование и тестирование, EAL7 — формально верифицированные проектирование и тестирование[3].

undefined

Каждый следующий уровень включает требования предыдущего и добавляет новые, поэтому от EAL1 к EAL7 растут и объём доказательств, и стоимость оценки. Низшие уровни опираются на документацию и независимое тестирование, тогда как высшие требуют формальной верификации проектных решений[3]. Наряду с EAL стандарт определяет пакеты CAP для составных объектов оценки, собранных из зависимых компонентов, и допускает наращивание уровней дополнительными семействами, чаще всего ALC_FLR — планомерным устранением дефектов после выпуска[3][17].

Процесс оценки

Оценку проводят аккредитованные лаборатории под надзором национальных схем сертификации; методы и активности оценщика заданы общей методикой CEM. В редакции 2022 года методика структурно согласована с частью 4 стандарта: каждый метод описывается в терминах действий с входными и выходными артефактами[13][15].

undefined

Типичная оценка начинается с проверки заявки безопасности: оценщик убеждается, что проблема безопасности, цели и выбранные требования согласованы. Затем оцениваются разработки — проектная документация, руководство по эксплуатации, конфигурационное управление; выполняется независимое тестирование функций и анализ уязвимостей с учётом потенциальных возможностей злоумышленника[13][17]. По результатам национальная схема выдаёт сертификат с указанием достигнутого уровня доверия и версии стандарта; отчёт об оценке публикуется вместе с сертификатом[4].

Стандарт подчёркивает, что оценка устанавливает уровень доверия, а не гарантирует безопасность: результаты оценки «могут помочь потребителям определить, удовлетворяет ли продукт их потребностям в безопасности», но решение о применимости остаётся за потребителем[2]. Именно поэтому сертификат принято рассматривать вместе с условиями эксплуатации, а не вместо них[18].

Использование

В России

Российская практика опирается на национальную версию стандарта. ГОСТ Р ИСО/МЭК 15408-2002, повторивший общие критерии редакции 1999 года, действовал в России с 1 января 2004 года и применялся при сертификации средств защиты информации[19].

Действующие требования к оценке сформулированы Федеральной службой по техническому и экспортному контролю (ФСТЭК России). Приказом от 2 июня 2020 года № 76 установлены шесть уровней доверия к средствам технической защиты информации: шестой — низший, первый — высший; для средств защиты с классами защиты 6, 5 и 4 закреплены соответствующие им уровни доверия 6, 5 и 4[20]. Уровни доверия задают глубину оценки — от анализа документации до формальной проверки, в соответствии с которой выбирается схема испытаний[21].

Российские исследования отмечают, что высшие уровни доверия требуют формального или полуформального стилей проектирования, поэтому переход на них затруднён для большинства разработчиков: методика оценки соответствия общим критериям должна учитывать и полноту доказательств, и реальную зрелость процессов[21][19].

В Европейском союзе

Акт о кибербезопасности закрепил в Союзе общие рамки сертификации продуктов и услуг в области кибербезопасности, а координацию поручил агентству ENISA — Европейскому агентству Союза по кибербезопасности. Схемы сертификации утверждаются исполнительными регламентами и действуют во всех государствах-членах[14].

Первой такой схемой стала EUCC — преемница национальных схем общих критериев стран ЕС. Регламент 2024/482 определяет правила её применения для продуктов информационно-коммуникационных технологий, включая категории продукции, роль органов оценки и процедуру выдачи сертификатов; схема построена на требованиях общих критериев и общей методики оценки[5]. Для производителей это означает единую процедуру вместо отдельных национальных сертификаций, а для заказчиков — сопоставимость результатов оценки по всему Союзу[14].

Ограничения метода

Общие критерии оценивают не продукт как таковой, а доказательства его разработки и тестирования. Уровень доверия характеризует строгость проверки, пройденной объектом оценки в конкретной конфигурации, и не переносится автоматически на другие версии и режимы работы[2]. Авторы учебников по компьютерной безопасности поэтому советуют читать сертификат вместе с отчётом об оценке: в нём перечислены допущения, ограничения и выявленные остаточные риски[22].

В инженерии безопасности подчёркивается и другое: сертификат подтверждает добросовестность разработки, но не заменяет эксплуатационный контроль — настройку, обновления и мониторинг уже развёрнутой системы[18][23]. Затраты на высшие уровни доверия оправданы не для всякого продукта, поэтому большинство оценок в мире выполняется на средних уровнях, а формальные методы остаются уделом систем с жёсткими требованиями к доказательности[24][25]. Выбор уровня, таким образом, становится компромиссом между стоимостью доказательств и потребностью заказчика в обоснованном доверии[25].

Примечания

  1. ↑ 1 2 ISO/IEC 15408-1:2026 (англ.). www.iso.org. International Organization for Standardization (май 2026). Дата обращения: 4 октября 2026.
  2. ↑ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Common Criteria for Information Technology Security Evaluation. Part 1: Introduction and general model (англ.). www.commoncriteriaportal.org. Common Criteria (ноябрь 2022). Дата обращения: 4 октября 2026.
  3. ↑ 1 2 3 4 5 6 7 Common Criteria for Information Technology Security Evaluation. Part 5: Pre-defined packages of security requirements (англ.). www.commoncriteriaportal.org. Common Criteria (ноябрь 2022). Дата обращения: 4 октября 2026.
  4. ↑ 1 2 3 Common Criteria Recognition Arrangement (англ.). www.commoncriteriaportal.org. Common Criteria (июль 2014). Дата обращения: 4 октября 2026.
  5. ↑ 1 2 3 Commission Implementing Regulation (EU) 2024/482 of 31 January 2024 laying down rules for the application of Regulation (EU) 2019/881 as regards the adoption of the EUCC scheme on the cybersecurity of ICT products (англ.). eur-lex.europa.eu. Publications Office of the European Union (январь 2024). Дата обращения: 4 октября 2026.
  6. ↑ 1 2 3 Department of Defense Trusted Computer System Evaluation Criteria. DoD 5200.28-STD (англ.). seclab.cs.ucdavis.edu. Department of Defense (декабрь 1985). Дата обращения: 4 октября 2026.
  7. ↑ Use of the Trusted Computer System Evaluation Criteria (TCSEC) for Complex, Evolving, Multipolicy Systems. NCSC-TR-002 (англ.). www.csirt.org. National Computer Security Center (июль 1994). Дата обращения: 4 октября 2026.
  8. ↑ 1 2 3 4 ETSI ETR 367: Security Techniques Advisory Group (STAG); Security requirements capture (англ.). www.etsi.org. ETSI (февраль 1997). Дата обращения: 4 октября 2026.
  9. ↑ Information Technology Security Evaluation Criteria (ITSEC): Provisional Harmonised Criteria. Version 1.2 (англ.). www.sogis.eu. Commission of the European Communities (июнь 1991). Дата обращения: 4 октября 2026.
  10. ↑ 1 2 3 4 5 Information technology — Security techniques — Evaluation criteria for IT security — Part 1: Introduction and general model (ISO/IEC 15408-1:1999) (англ.). learn.ztu.edu.ua. ISO/IEC (декабрь 1999). Дата обращения: 4 октября 2026.
  11. ↑ Common Criteria for Information Technology Security Evaluation. Part 1: Introduction and general model. CC v3.1 Rev 5 (англ.). www.commoncriteriaportal.org. Common Criteria (апрель 2017). Дата обращения: 4 октября 2026.
  12. ↑ 1 2 ISO/IEC 15408-1:2022 (англ.). www.iso.org. International Organization for Standardization (август 2022). Дата обращения: 4 октября 2026.
  13. ↑ 1 2 3 4 Common Evaluation Methodology for Information Technology Security Evaluation. CEM:2022 (англ.). www.commoncriteriaportal.org. Common Criteria (ноябрь 2022). Дата обращения: 4 октября 2026.
  14. ↑ 1 2 3 Regulation (EU) 2019/881 of the European Parliament and of the Council of 17 April 2019 on ENISA (the European Union Agency for Cybersecurity) and on information and communications technology cybersecurity certification (Cybersecurity Act) (англ.). eur-lex.europa.eu. Publications Office of the European Union (апрель 2019). Дата обращения: 4 октября 2026.
  15. ↑ 1 2 Common Criteria for Information Technology Security Evaluation. Part 4: Framework for the specification of evaluation methods and activities (англ.). www.commoncriteriaportal.org. Common Criteria (ноябрь 2022). Дата обращения: 4 октября 2026.
  16. ↑ 1 2 3 4 5 6 Common Criteria for Information Technology Security Evaluation. Part 2: Security functional components (англ.). www.commoncriteriaportal.org. Common Criteria (ноябрь 2022). Дата обращения: 4 октября 2026.
  17. ↑ 1 2 3 4 5 6 Common Criteria for Information Technology Security Evaluation. Part 3: Security assurance components (англ.). www.commoncriteriaportal.org. Common Criteria (ноябрь 2022). Дата обращения: 4 октября 2026.
  18. ↑ 1 2 Anderson R. Security Engineering: A Guide to Building Dependable Distributed Systems (англ.). — 2nd ed.. — Indianapolis: Wiley, 2008. — 840 p. — ISBN 978-0-470-06852-6.
  19. ↑ 1 2 Зайцев О. Е. Базовые параметры формальных моделей оценки защищённости ИТ по общим критериям // Научно-технический вестник информационных технологий, механики и оптики. — 2007. — № 39.
  20. ↑ Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и требования по безопасности информации к их функциональным компонентам. web.archive.org. ФСТЭК России (июнь 2020). Дата обращения: 4 октября 2026.
  21. ↑ 1 2 Барабанов А. В., Марков А. С., Найханова Л. В. Методика оценки соответствия средств защиты информации общим критериям // Вестник МГТУ. Приборостроение. — 2013. — № 2 (91).
  22. ↑ Bishop M. Computer Security: Art and Science (англ.). — Boston: Addison-Wesley, 2003. — 1084 p. — ISBN 978-0-201-44099-7.
  23. ↑ Schneier B. Secrets and Lies: Digital Security in a Networked World (англ.). — Indianapolis: Wiley, 2004. — 448 p. — ISBN 978-0-471-45380-2.
  24. ↑ Gollmann D. Computer Security (англ.). — 3rd ed.. — Chichester: Wiley, 2011. — 456 p. — ISBN 978-1-119-95875-8.
  25. ↑ 1 2 Stallings W., Brown L. Computer Security: Principles and Practice (англ.). — Upper Saddle River: Prentice Hall, 2008. — 798 p. — ISBN 978-0-13-600424-0.

Литература

  • Барабанов А. В., Марков А. С., Найханова Л. В. Методика оценки соответствия средств защиты информации общим критериям // Вестник МГТУ. Приборостроение. — 2013. — № 2 (91).
  • Зайцев О. Е. Базовые параметры формальных моделей оценки защищённости ИТ по общим критериям // Научно-технический вестник информационных технологий, механики и оптики. — 2007. — № 39.
  • Anderson R. Security Engineering: A Guide to Building Dependable Distributed Systems (англ.). — 2nd ed.. — Indianapolis: Wiley, 2008. — 840 p. — ISBN 978-0-470-06852-6.
  • Bishop M. Computer Security: Art and Science (англ.). — Boston: Addison-Wesley, 2003. — 1084 p. — ISBN 978-0-201-44099-7.
  • Commission of the European Communities. Information Technology Security Evaluation Criteria (ITSEC): Provisional Harmonised Criteria (англ.). — Version 1.2. — Luxembourg: Commission of the European Communities, 1991.
  • Department of Defense. Department of Defense Trusted Computer System Evaluation Criteria (англ.). — DoD 5200.28-STD. — Washington, D.C.: Department of Defense, 1985.
  • Gollmann D. Computer Security (англ.). — 3rd ed.. — Chichester: Wiley, 2011. — 456 p. — ISBN 978-1-119-95875-8.
  • ISO/IEC. Information technology — Security techniques — Evaluation criteria for IT security (англ.). — ISO/IEC 15408:1999. — Geneva: ISO/IEC, 1999.
  • Schneier B. Secrets and Lies: Digital Security in a Networked World (англ.). — Indianapolis: Wiley, 2004. — 448 p. — ISBN 978-0-471-45380-2.
  • Stallings W., Brown L. Computer Security: Principles and Practice (англ.). — Upper Saddle River: Prentice Hall, 2008. — 798 p. — ISBN 978-0-13-600424-0.


Дополнительно по теме

Pause