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

В Общие критерии безопасности информационных технологий оценки (обозначаемые как Common Criteria или CC ) является международным стандартом ( ISO / IEC 15408) для компьютерной безопасности сертификации. В настоящее время он находится в версии 3.1, редакция 5. ^[1]

Общие критерии - это структура, в которой пользователи компьютерных систем могут указать свои функциональные требования и требования к обеспечению безопасности (SFR и SAR соответственно) в цели безопасности (ST) и могут быть взяты из профилей защиты (PP). Затем поставщики могут реализовать или заявить об атрибутах безопасности своих продуктов, а испытательные лаборатории могут оценитьпродукты, чтобы определить, действительно ли они соответствуют заявленным требованиям. Другими словами, Common Criteria обеспечивает уверенность в том, что процесс спецификации, реализации и оценки продукта компьютерной безопасности был проведен строгим, стандартным и повторяемым образом на уровне, который соизмерим с целевой средой для использования. ^[2] Common Criteria поддерживает список сертифицированных продуктов, включая операционные системы, системы контроля доступа, базы данных и системы управления ключами. ^[3]

Ключевые понятия [ править ]

Оценка общих критериев выполняется для продуктов и систем компьютерной безопасности.

• Цель оценки (ОО)  - продукт или система, которые являются предметом оценки. Оценка служит для подтверждения заявлений о цели. Для практического использования оценка должна проверять функции безопасности цели. Это делается следующим образом:
  • Профиль защиты (PP)  - документ, обычно создаваемый пользователем или сообществом пользователей, который определяет требования безопасности для класса устройств безопасности (например, смарт-карты, используемые для предоставления цифровых подписей , или сетевые брандмауэры).), относящиеся к этому пользователю для конкретной цели. Поставщики продуктов могут выбрать реализацию продуктов, соответствующих одному или нескольким PP, и провести оценку своих продуктов по этим PP. В таком случае ПЗ может служить шаблоном для ЗБ продукта (цель безопасности, как определено ниже), или авторы ЗБ, по крайней мере, обеспечат, чтобы все требования соответствующих ПЗ также присутствовали в ЗБ целевого документа. Клиенты, которые ищут определенные типы продуктов, могут сосредоточиться на тех, которые сертифицированы по ПЗ, которые соответствуют их требованиям.
  • Security Target (ST)  - документ, определяющий свойства безопасностиобъекта оценки. ЗБ может заявлять о соответствии одному или нескольким ПЗ. ОО оценивается по SFR (функциональные требования безопасности. Опять же, см. Ниже), установленным в его ЗБ, не больше и не меньше. Это позволяет поставщикам адаптировать оценку для точного соответствия предполагаемым возможностям их продукта. Это означает, что сетевой брандмауэр не должен отвечать тем же функциональным требованиям, что и база данных.система управления, и что разные брандмауэры на самом деле можно оценивать по совершенно разным спискам требований. ЗБ обычно публикуется, чтобы потенциальные клиенты могли определить конкретные функции безопасности, которые были сертифицированы в ходе оценки.
  • Функциональные требования безопасности (SFR)  - определяют отдельные функции безопасности, которые могут быть обеспечены продуктом. Common Criteria представляет собой стандартный каталог таких функций. Например, SFR может указывать, как пользователь, выполняющий определенную роль, может быть аутентифицирован . Список SFR может варьироваться от одной оценки к другой, даже если две цели относятся к одному и тому же типу продукта. Хотя Common Criteria не предписывает включать какие-либо SFR в ЗБ, он определяет зависимости, в которых правильная работа одной функции (например, возможность ограничивать доступ в соответствии с ролями) зависит от другой (например, способность идентифицировать отдельные роли). ).

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

• Требования обеспечения безопасности (SAR)  - описание мер, принятых во время разработки и оценки продукта для обеспечения соответствия заявленным функциям безопасности. Например, оценка может потребовать, чтобы весь исходный код хранился в системе управления изменениями или выполнялось полное функциональное тестирование. Общие критерии предоставляют их каталог, и требования могут варьироваться от одной оценки к другой. Требования к конкретным целям или типам продукции задокументированы в ЗБ и ПЗ соответственно.
• Уровень гарантии оценки (EAL)  - числовой рейтинг, описывающий глубину и строгость оценки. Каждый EAL соответствует пакету требований обеспечения безопасности (SAR, см. Выше), который охватывает полную разработку продукта с заданным уровнем строгости. В Common Criteria перечислено семь уровней, из которых EAL 1 является самым базовым (и, следовательно, самым дешевым для реализации и оценки), а EAL 7 - самым строгим (и самым дорогим). Обычно автор ЗБ или ПЗ не выбирает требования доверия индивидуально, а выбирает один из этих пакетов, возможно, «дополняя» требования в некоторых областях требованиями более высокого уровня. Более высокие EAL необязательно подразумевают «лучшую безопасность», они означают только то, что заявленная гарантия безопасности ОО была более тщательно проверена .

До сих пор большинство ПЗ и наиболее оцениваемые ЗБ / сертифицированные продукты относились к компонентам ИТ (например, межсетевым экранам, операционным системам , смарт-картам). Сертификация Common Criteria иногда указывается для закупок ИТ. Другие стандарты, содержащие, например, взаимодействие, управление системой, обучение пользователей, дополнительные стандарты CC и другие стандарты на продукцию. Примеры включают ISO / IEC 27002 ) и немецкую базовую защиту ИТ .

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

В последнее время авторы PP включают криптографические требования для оценок CC, которые обычно охватываются оценками FIPS 140-2, расширяя границы CC за счет интерпретаций, специфичных для схемы.

Некоторые национальные схемы оценки постепенно отказываются от оценок на основе ОУД и принимают для оценки только те продукты, которые заявляют о строгом соответствии с утвержденным ПЗ. В настоящее время в США разрешены только оценки на основе PP. Канада находится в процессе постепенного отказа от оценок на основе EAL.

История [ править ]

CC возник на основе трех стандартов:

• ITSEC  - Европейский стандарт, разработанный в начале 1990-х годов во Франции, Германии, Нидерландах и Великобритании. Это также было объединение более ранних работ, таких как два британских подхода ( Схема оценки CESG UK Evaluation Scheme, нацеленная на рынок обороны / разведки, и Зеленая книга DTI, нацеленная на коммерческое использование), и была принята некоторыми другими странами, например Австралией.
• CTCPEC  - Канадский стандарт последовал за стандартом Министерства обороны США, но позволил избежать ряда проблем и использовался совместно экспертами из США и Канады. Стандарт CTCPEC был впервые опубликован в мае 1993 года.
• TCSEC  - Министерство обороны США DoD 5200.28 Std, называемое « Оранжевой книгой» и частью серии « Радуга» . Оранжевая книга возникла в результате работы по компьютерной безопасности, включая отчет Андерсона, выполненной Агентством национальной безопасности и Национальным бюро стандартов (NBS в конечном итоге стало NIST ) в конце 1970-х - начале 1980-х годов. Центральный тезис Оранжевой книги вытекает из работы, проделанной Дэйвом Беллом и Леном Лападулой для набора механизмов защиты.

CC был создан путем унификации этих ранее существовавших стандартов, главным образом для того, чтобы компании, продающие компьютерные продукты для государственного рынка (в основном для использования в оборонных или разведывательных целях), нуждались только в их оценке по одному набору стандартов. CC был разработан правительствами Канады, Франции, Германии, Нидерландов, Великобритании и США.

Испытательные организации [ править ]

Все испытательные лаборатории должны соответствовать ISO / IEC 17025 , а органы по сертификации обычно утверждаются в соответствии с ISO / IEC 17065.

Соответствие ISO / IEC 17025 обычно демонстрируется национальным уполномоченным органом:

• В Канаде Совет по стандартам Канады (SCC) в рамках Программы аккредитации лабораторий (PALCAN) аккредитует службы оценки общих критериев (CCEF).
• Во Франции Французский комитет по аккредитации  [ fr ] (COFRAC) аккредитует центры оценки Common Criteria, обычно называемые Centre d'évaluation de la sécurité des Technologies de l'information  [ fr ] (CESTI). Оценка проводится в соответствии с нормами и стандартами, установленными Национальным агентством безопасности информационных систем (ANSSI).
• В Италии OCSI (Organismo di Certificazione della Sicurezza Informatica) аккредитует лаборатории оценки Common Criteria
• В Великобритании Служба аккредитации Соединенного Королевства (UKAS) использовалась для аккредитации коммерческих оценочных центров (CLEF) ; Великобритания с 2019 года является единственным потребителем в экосистеме CC
• В США Национальная программа добровольной аккредитации лабораторий (NVLAP) Национального института стандартов и технологий (NIST ) аккредитует испытательные лаборатории по общим критериям (CCTL).
• В Германии Bundesamt für Sicherheit in der Informationstechnik (BSI)
• В Испании Национальный криптологический центр (CCN) аккредитует испытательные лаборатории по общим критериям, работающие по испанской схеме.
• В Нидерландах нидерландская схема сертификации в области ИТ-безопасности (NSCIB) аккредитует центры оценки ИТ-безопасности (ITSEF).
• В Швеции Шведский орган по сертификации ИТ-безопасности (CSEC) лицензирует службы оценки ИТ-безопасности (ITSEF).

Характеристики этих организаций были изучены и представлены на ICCC 10. ^[4]

Договоренность о взаимном признании [ править ]

Помимо стандарта Common Criteria, существует также соглашение Common Criteria MRA (Соглашение о взаимном признании) на уровне субдоговора, в соответствии с которым каждая сторона признает оценки по стандарту Common Criteria, выполненные другими сторонами. Первоначально подписанный в 1998 году Канадой, Францией, Германией, Соединенным Королевством и США, Австралия и Новая Зеландия присоединились к 1999 году, а в 2000 году - Финляндией, Грецией, Израилем, Италией, Нидерландами, Норвегией и Испанией. переименовано в Common Criteria Recognition Arrangement ( CCRA ), и количество участников продолжает расширяться. В рамках CCRA взаимно признаются только оценки до EAL 2 (включая расширение с исправлением недостатков). Европейские страны в рамках бывшего соглашения ITSEC обычно также признают более высокие EAL. Оценки на уровне EAL5 и выше, как правило, связаны с требованиями безопасности правительства принимающей страны.

В сентябре 2012 года большинство членов CCRA подготовили заявление о видении, согласно которому взаимное признание продуктов, прошедших оценку CC, будет снижено до EAL 2 (включая расширение с исправлением недостатков). Кроме того, это видение указывает на полный отход от уровней доверия, и оценки будут ограничиваться соответствием профилям защиты, которые не имеют заявленного уровня доверия. Это будет достигнуто с помощью технических рабочих групп, разрабатывающих ПУ по всему миру, и пока еще полностью не определен переходный период.

2 июля 2014 года был ратифицирован новый CCRA в соответствии с целями, изложенными в заявлении о видении на 2012 год . Основные изменения в договоренности включают:

• Признание оценок только по совместному профилю защиты (cPP) или уровням гарантии оценки с 1 по 2 и ALC_FLR.
• Появление международных технических сообществ (iTC), групп технических экспертов, отвечающих за создание cPP.
• План перехода от предыдущего CCRA, включая признание сертификатов, выданных в соответствии с предыдущей версией Соглашения.

Проблемы [ править ]

Требования [ править ]

Общие критерии очень общие; он не предоставляет напрямую список требований безопасности продукта или функций для конкретных (классов) продуктов: это следует подходу, принятому ITSEC , но является источником дебатов для тех, кто использовал более предписывающий подход других более ранних стандартов, таких как TCSEC и FIPS 140-2.

Значение сертификации [ править ]

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

Различные версии Microsoft Windows, включая Windows Server 2003 и Windows XP , прошли сертификацию., но исправления безопасности для устранения уязвимостей безопасности все еще публикуются Microsoft для этих систем Windows. Это возможно, потому что процесс получения сертификата Common Criteria позволяет поставщику ограничить анализ определенными функциями безопасности и сделать определенные предположения об операционной среде и силе угроз, с которыми сталкивается продукт в этой среде. Кроме того, ОК признает необходимость ограничить объем оценки, чтобы предоставить рентабельные и полезные сертификаты безопасности, чтобы оцениваемые продукты проверялись до уровня детализации, определенного уровнем доверия или ПЗ. Поэтому деятельность по оценке выполняется только до определенной глубины, с использованием времени и ресурсов и обеспечивает разумную уверенность в предполагаемой среде.

В случае Microsoft предположения включают A.PEER:

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

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

Независимо от того, запускаете ли вы Microsoft Windows в точно оцененной конфигурации или нет, вам следует применять исправления безопасности Microsoft для устранения уязвимостей в Windows по мере их появления. Если любая из этих уязвимостей безопасности может быть использована в оцененной конфигурации продукта, поставщик должен добровольно отозвать сертификат Common Criteria продукта. В качестве альтернативы поставщику следует повторно оценить продукт, чтобы включить в него применение исправлений для исправления уязвимостей безопасности в оцениваемой конфигурации. Неспособность поставщика предпринять любой из этих шагов приведет к принудительному отзыву сертификации продукта органом по сертификации страны, в которой продукт был оценен.

Сертифицированные версии Microsoft Windows остаются на уровне EAL4 + без включения каких-либо исправлений уязвимостей безопасности Microsoft в их оцененную конфигурацию. Это показывает как ограничения, так и силу оцениваемой конфигурации.

Критика [ править ]

В августе 2007 года обозреватель Government Computing News (GCN) Уильям Джексон критически проанализировал методологию Common Criteria и ее реализацию в США посредством Common Criteria Evaluation and Validation Scheme (CCEVS). ^[5] В колонке были опрошены руководители отрасли безопасности, исследователи и представители Национального партнерства по обеспечению информационной безопасности (NIAP). Возражения, изложенные в статье, включают:

• Оценка - дорогостоящий процесс (часто измеряемый сотнями тысяч долларов США), и возврат этих инвестиций поставщиком не обязательно является более безопасным продуктом.
• Оценка фокусируется в первую очередь на оценке оценочной документации, а не на фактической безопасности, технической корректности или достоинствах самого продукта. Для оценок США в анализе участвуют только специалисты Агентства национальной безопасности с уровнем EAL5 и выше; и только на EAL7 требуется полный анализ исходного кода.
• Усилия и время, необходимые для подготовки свидетельств оценки и другой документации, связанной с оценкой, настолько обременительны, что к моменту завершения работы оцениваемый продукт, как правило, устаревает.
• Вклад отрасли, в том числе таких организаций, как Форум поставщиков общих критериев , обычно мало влияет на процесс в целом.

В исследовательской работе 2006 года компьютерный специалист Дэвид А. Уиллер предположил, что процесс Common Criteria дискриминирует организации и модели разработки, ориентированные на бесплатное и открытое программное обеспечение (FOSS). ^[6] Требования обеспечения Common Criteria обычно основываются на традиционной методологии разработки программного обеспечения « водопад» . Напротив, большая часть программного обеспечения FOSS создается с использованием современных гибких парадигм. Хотя некоторые утверждали, что обе парадигмы плохо согласуются ^[7], другие пытались примирить обе парадигмы. ^[8] Политолог Ян Каллберг.выразили обеспокоенность по поводу отсутствия контроля над фактическим производством продуктов после их сертификации, отсутствия постоянно укомплектованного персонала организационного органа, который следит за соблюдением нормативных требований, а также по поводу того, что доверие к сертификатам безопасности ИТ по общим критериям будет поддерживаться во всех геополитических регионах. границы. ^[9]

Альтернативные подходы [ править ]

На протяжении всего периода существования CC он не был повсеместно принят даже странами-создателями, в частности, криптографические утверждения обрабатывались отдельно, например, в рамках реализации стандарта FIPS-140 в Канаде / США и схемы CESG Assisted Products Scheme (CAPS ) ^[10] в Великобритании.

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

• CESG система оценки (SYSn) и Fast Track подход (FTA) схемы для обеспечения государственных систем , а не генерических продуктов и услуг, которые в настоящее время объединены в Службу CESG заказуНаша Assurance (CTAS) ^[11]
• Знак CESG Claims Tested Mark (CCT Mark) направлен на удовлетворение менее исчерпывающих требований гарантии для продуктов и услуг экономичным и эффективным способом с точки зрения затрат и времени.

В начале 2011 года NSA / CSS опубликовало документ Криса Солтера, в котором был предложен подход к оценке, ориентированный на профиль защиты . При таком подходе сообщества по интересам формируются вокруг типов технологий, которые, в свою очередь, разрабатывают профили защиты, которые определяют методологию оценки для типа технологии. ^[12] Цель - более надежная оценка. Есть некоторые опасения, что это может негативно повлиять на взаимное признание . ^[13]

В сентябре 2012 года Common Criteria опубликовала Заявление о видении, в значительной степени воплощающее мысли Криса Солтера за предыдущий год. Ключевые элементы Видения включали:

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

См. Также [ править ]

• Модель Bell-LaPadula
• Обязательный сертификат Китая
• Уровень гарантии оценки
• FIPS 140-2
• Информационное обеспечение
• ISO 9241
• ISO / IEC 27001
• Юзабилити-тестирование
• Верификация и валидация

Ссылки [ править ]

Внешние ссылки [ править ]

• Официальный сайт Common Criteria Project
• Стандартные документы Common Criteria
• Список продуктов, оцениваемых по Common Criteria
• Список лицензированных лабораторий Common Criteria
• На пути к гибкому обеспечению безопасности
• Важные сокращения общих критериев
• Форум пользователей Common Criteria
• Дополнительная информация об общих критериях в Google Knol
• OpenCC Project - бесплатная лицензия Apache CC, документы, шаблоны и инструменты
• Краткая справочная карта Common Criteria
• Шпаргалка по процессу Common Criteria