Международный стандарт сертификации компьютерной безопасности
Общие критерии оценки безопасности информационных технологий (именуемые Общими критериями или CC ) — это международный стандарт ( ISO / IEC 15408) для сертификации компьютерной безопасности . В настоящее время он находится в версии 3.1, редакция 5. [1]
Common Criteria — это структура, в которой пользователи компьютерных систем могут указывать свои функциональные требования безопасности и гарантии (SFR и SAR соответственно) в Security Target (ST) и могут быть взяты из Protection Profiles (PP). Затем поставщики могут внедрять или делать заявления об атрибутах безопасности своих продуктов, а испытательные лаборатории могут оценивать продукты, чтобы определить, действительно ли они соответствуют заявлениям. Другими словами, Common Criteria обеспечивает гарантию того, что процесс спецификации, внедрения и оценки продукта компьютерной безопасности был проведен строгим, стандартным и повторяемым образом на уровне, который соизмерим с целевой средой использования. [2] Common Criteria ведет список сертифицированных продуктов, включая операционные системы, системы контроля доступа, базы данных и системы управления ключами. [3]
Ключевые понятия
Оценки по Общим критериям проводятся для продуктов и систем компьютерной безопасности.
- Цель оценки (TOE) – продукт или система, являющиеся предметом оценки. Оценка служит для проверки заявлений, сделанных относительно цели. Чтобы иметь практическое применение, оценка должна проверить функции безопасности цели. Это делается следующим образом:
- Профиль защиты (PP) — документ, обычно создаваемый пользователем или сообществом пользователей, который определяет требования безопасности для класса устройств безопасности (например, смарт-карты, используемые для предоставления цифровых подписей , или сетевые брандмауэры ), имеющих отношение к этому пользователю для определенной цели. Поставщики продуктов могут выбрать реализацию продуктов, которые соответствуют одному или нескольким PP, и оценить свои продукты по этим PP. В таком случае PP может служить шаблоном для ST продукта (цель безопасности, как определено ниже), или авторы ST, по крайней мере, обеспечат, чтобы все требования в соответствующих PP также отображались в документе ST цели. Клиенты, ищущие определенные типы продуктов, могут сосредоточиться на тех, которые сертифицированы по PP, который соответствует их требованиям.
- Security Target (ST) – документ, который определяет свойства безопасности цели оценки. ST может заявлять о соответствии одному или нескольким PP. TOE оценивается по SFR (функциональным требованиям безопасности. Опять же, см. ниже), установленным в его ST, не больше и не меньше. Это позволяет поставщикам адаптировать оценку для точного соответствия предполагаемым возможностям своего продукта. Это означает, что сетевой брандмауэр не должен соответствовать тем же функциональным требованиям, что и система управления базами данных , и что различные брандмауэры могут фактически оцениваться по совершенно разным спискам требований. ST обычно публикуется, чтобы потенциальные клиенты могли определить конкретные функции безопасности, которые были сертифицированы оценкой.
- Функциональные требования безопасности (SFR) — определяют отдельные функции безопасности , которые могут быть предоставлены продуктом. Общие критерии представляют стандартный каталог таких функций. Например, SFR может указывать, как пользователь, действующий в определенной роли , может быть аутентифицирован . Список SFR может меняться от одной оценки к другой, даже если две цели представляют собой один и тот же тип продукта. Хотя Общие критерии не предписывают включение каких-либо SFR в ST, они определяют зависимости, где правильная работа одной функции (например, возможность ограничивать доступ в соответствии с ролями) зависит от другой (например, возможность идентифицировать отдельные роли).
Процесс оценки также пытается установить уровень доверия, который может быть проявлен к функциям безопасности продукта посредством процессов обеспечения качества :
- Требования к обеспечению безопасности (SAR) — описания мер, принятых во время разработки и оценки продукта для обеспечения соответствия заявленной функциональности безопасности. Например, оценка может потребовать, чтобы весь исходный код хранился в системе управления изменениями или чтобы было проведено полное функциональное тестирование. Общие критерии предоставляют каталог таких требований, и требования могут различаться от одной оценки к другой. Требования для конкретных целей или типов продуктов документируются в ST и PP соответственно.
- Уровень гарантии оценки (EAL) – числовой рейтинг, описывающий глубину и строгость оценки. Каждый EAL соответствует пакету требований гарантии безопасности (SAR, см. выше), который охватывает полную разработку продукта с заданным уровнем строгости. Общие критерии перечисляют семь уровней, при этом EAL 1 является самым базовым (и, следовательно, самым дешевым для внедрения и оценки), а EAL 7 – самым строгим (и самым дорогим). Обычно автор ST или PP не выбирает требования гарантии по отдельности, а выбирает один из этих пакетов, возможно, «дополняя» требования в нескольких областях требованиями с более высокого уровня. Более высокие EAL не обязательно подразумевают «лучшую безопасность», они лишь означают, что заявленная гарантия безопасности TOE была более тщательно проверена .
До сих пор большинство ПП и наиболее оцененных ST/сертифицированных продуктов были предназначены для ИТ-компонентов (например, межсетевых экранов, операционных систем , смарт-карт).
Сертификация Common Criteria иногда указывается для закупок ИТ. Другие стандарты, содержащие, например, взаимодействие, управление системой, обучение пользователей, дополнения CC и другие стандарты продуктов. Примерами являются ISO/IEC 27002 и немецкий стандарт защиты базовых ИТ .
Детали криптографической реализации в TOE выходят за рамки CC. Вместо этого национальные стандарты, такие как FIPS 140-2 , дают спецификации для криптографических модулей, а различные стандарты определяют используемые криптографические алгоритмы.
В последнее время авторы PP включают криптографические требования для оценок CC, которые обычно охватываются оценками FIPS 140-2, расширяя границы CC посредством интерпретаций, специфичных для конкретной схемы.
Некоторые национальные схемы оценки постепенно отказываются от оценок на основе EAL и принимают для оценки только те продукты, которые заявляют о строгом соответствии с утвержденным PP. В настоящее время Соединенные Штаты допускают только оценки на основе PP.
История
CC возник из трех стандартов:
- ITSEC – Европейский стандарт, разработанный в начале 1990-х годов Францией, Германией, Нидерландами и Великобританией. Он также был объединением более ранних работ, таких как два подхода Великобритании ( CESG UK Evaluation Scheme, нацеленная на рынок обороны/разведки, и DTI Green Book, нацеленная на коммерческое использование), и был принят некоторыми другими странами, например Австралией.
- CTCPEC – Канадский стандарт последовал за стандартом Министерства обороны США, но избежал нескольких проблем и использовался совместно оценщиками из США и Канады. Стандарт CTCPEC был впервые опубликован в мае 1993 года.
- TCSEC – Министерство обороны США DoD 5200.28 Std, называемое Orange Book и части Rainbow Series . Orange Book возникла из работы по компьютерной безопасности, включая отчет Anderson, выполненной Агентством национальной безопасности и Национальным бюро стандартов (NBS в конечном итоге стало NIST ) в конце 1970-х и начале 1980-х годов. Центральный тезис Orange Book вытекает из работы, проделанной Дейвом Беллом и Леном ЛаПадулой для набора механизмов защиты.
CC был создан путем объединения этих уже существующих стандартов, в основном для того, чтобы компании, продающие компьютерные продукты для государственного рынка (в основном для использования в целях обороны или разведки), могли оценивать их только по одному набору стандартов. CC был разработан правительствами Канады, Франции, Германии, Нидерландов, Великобритании и США
Тестирующие организации
Все испытательные лаборатории должны соответствовать стандарту ISO/IEC 17025 , а органы по сертификации обычно утверждаются на основании стандарта ISO/IEC 17065.
Соответствие стандарту ISO/IEC 17025 обычно подтверждается национальному органу по утверждению:
Характеристики этих организаций были рассмотрены и представлены на 10-й конференции ICCC.
Соглашение о взаимном признании
Помимо стандарта Common Criteria, существует также уровень поддоговора Common Criteria MRA (Соглашение о взаимном признании), в соответствии с которым каждая сторона признает оценки по стандарту Common Criteria, проведенные другими сторонами. Первоначально подписанное в 1998 году Канадой, Францией, Германией, Великобританией и Соединенными Штатами, Австралия и Новая Зеландия присоединились в 1999 году, за которыми в 2000 году последовали Финляндия, Греция, Израиль, Италия, Нидерланды, Норвегия и Испания. С тех пор Соглашение было переименовано в Соглашение о признании Common Criteria ( CCRA ), и членство продолжает расширяться. [5] В рамках CCRA взаимно признаются только оценки до EAL 2 (включая дополнение с устранением недостатков). Европейские страны в рамках SOGIS-MRA обычно признают и более высокие EAL. Оценки на уровне EAL5 и выше, как правило, включают требования безопасности правительства принимающей страны.
В сентябре 2012 года большинство членов CCRA представили заявление о видении, в соответствии с которым взаимное признание продуктов, оцененных по CC, будет снижено до EAL 2 (включая расширение с устранением недостатков). Кроме того, это видение указывает на отход от уровней гарантии в целом, и оценки будут ограничены соответствием Профилям защиты, которые не имеют заявленного уровня гарантии. Это будет достигнуто посредством технических рабочих групп, разрабатывающих всемирные PPs, и пока еще переходный период не был полностью определен.
2 июля 2014 года был ратифицирован новый CCRA [6] в соответствии с целями, изложенными в заявлении о видении 2012 года. [7] Основные изменения в Соглашении включают в себя:
- Признание оценок только по совместному профилю защиты (cPP) или уровням обеспечения оценки 1–2 и ALC_FLR.
- Появление международных технических сообществ (МТС) — групп технических экспертов, ответственных за создание КПТ.
- План перехода от предыдущего CCRA, включая признание сертификатов, выданных в соответствии с предыдущей версией Соглашения.
Проблемы
Требования
Общие критерии носят весьма общий характер; они не содержат напрямую список требований к безопасности продукта или функций для конкретных (классов) продуктов: это соответствует подходу, принятому ITSEC , но стало источником споров для тех, кто привык к более предписывающему подходу других более ранних стандартов, таких как TCSEC и FIPS 140-2 .
Ценность сертификации
Сертификация Common Criteria не может гарантировать безопасность, но она может гарантировать, что заявления о свойствах безопасности оцениваемого продукта были независимо проверены. Другими словами, продукты, оцененные по стандарту Common Criteria, демонстрируют четкую цепочку доказательств того, что процесс спецификации, внедрения и оценки был проведен строго и стандартно.
Различные версии Microsoft Windows, включая Windows Server 2003 и Windows XP , были сертифицированы [8], но исправления безопасности для устранения уязвимостей безопасности все еще публикуются Microsoft для этих систем Windows. Это возможно, поскольку процесс получения сертификации Common Criteria позволяет поставщику ограничить анализ определенными функциями безопасности и сделать определенные предположения об операционной среде и силе угроз, с которыми сталкивается продукт в этой среде. Кроме того, CC признает необходимость ограничения области оценки для предоставления экономически эффективных и полезных сертификатов безопасности, так что оцениваемые продукты проверяются на уровне детализации, указанном уровнем гарантии или PP. Таким образом, действия по оценке выполняются только на определенную глубину, с использованием времени и ресурсов и предлагают разумную гарантию для предполагаемой среды.
В случае Microsoft предположения включают A.PEER:
«Предполагается, что любые другие системы, с которыми взаимодействует TOE, находятся под тем же контролем управления и работают в рамках тех же ограничений политики безопасности. TOE применим к сетевым или распределенным средам только в том случае, если вся сеть работает в рамках тех же ограничений и находится в пределах одного домена управления. Не существует требований безопасности, которые учитывают необходимость доверять внешним системам или каналам связи с такими системами».
Это предположение содержится в профиле Controlled Access Protection Profile (CAPP), которому придерживаются их продукты. На основе этого и других предположений, которые могут быть нереалистичными для обычного использования операционных систем общего назначения, оцениваются заявленные функции безопасности продуктов Windows. Таким образом, их следует считать безопасными только в предполагаемых, указанных обстоятельствах, также известных как оцененная конфигурация .
Независимо от того, используете ли вы Microsoft Windows в точной оцененной конфигурации или нет, вам следует применять исправления безопасности Microsoft для уязвимостей в Windows, поскольку они продолжают появляться. Если какие-либо из этих уязвимостей безопасности могут быть использованы в оцененной конфигурации продукта, сертификация Common Criteria продукта должна быть добровольно отозвана поставщиком. В качестве альтернативы поставщик должен повторно оценить продукт, включив применение исправлений для устранения уязвимостей безопасности в оцененной конфигурации. Невыполнение поставщиком любого из этих шагов приведет к непреднамеренному отзыву сертификации продукта органом по сертификации страны, в которой продукт был оценен.
Сертифицированные версии Microsoft Windows остаются на уровне EAL4+ без включения в их оцененную конфигурацию каких-либо исправлений уязвимостей безопасности Microsoft. Это показывает как ограничение, так и силу оцененной конфигурации.
Критика
В августе 2007 года обозреватель Government Computing News (GCN) Уильям Джексон критически рассмотрел методологию Common Criteria и ее реализацию в США Схемой оценки и проверки Common Criteria (CCEVS). [9] В колонке были опрошены руководители из индустрии безопасности, исследователи и представители Национального партнерства по обеспечению безопасности информации (NIAP). Возражения, изложенные в статье, включают:
- Оценка — дорогостоящий процесс (часто измеряемый сотнями тысяч долларов США), и возврат инвестиций поставщика не обязательно заключается в более безопасном продукте.
- Оценка фокусируется в первую очередь на оценке оценочной документации, а не на фактической безопасности, технической корректности или достоинствах самого продукта. Для оценок в США только на уровне EAL5 и выше в анализе участвуют эксперты из Агентства национальной безопасности; и только на уровне EAL7 требуется полный анализ исходного кода.
- Усилия и время, необходимые для подготовки доказательств оценки и другой документации, связанной с оценкой, настолько обременительны, что к моменту завершения работы оцениваемый продукт, как правило, устаревает.
- Вклад отрасли, в том числе со стороны таких организаций, как Форум поставщиков общих критериев, обычно оказывает незначительное влияние на процесс в целом.
В исследовательской работе 2006 года компьютерный специалист Дэвид А. Уилер предположил, что процесс Common Criteria дискриминирует организации и модели разработки, ориентированные на свободное и открытое программное обеспечение (FOSS). [10] Требования к обеспечению Common Criteria, как правило, вдохновлены традиционной методологией каскадной разработки программного обеспечения. Напротив, большая часть программного обеспечения FOSS производится с использованием современных гибких парадигм. Хотя некоторые утверждают, что обе парадигмы не очень хорошо согласуются, [11] другие пытаются примирить обе парадигмы. [12] Политолог Ян Каллберг выразил обеспокоенность по поводу отсутствия контроля над фактическим производством продуктов после их сертификации, отсутствия постоянно укомплектованного организационного органа, который следит за соответствием, и идеи о том, что доверие к сертификациям Common Criteria по ИТ-безопасности будет поддерживаться вне зависимости от геополитических границ. [13]
В 2017 году уязвимость ROCA была обнаружена в списке продуктов смарт-карт, сертифицированных по Common Criteria. Уязвимость выявила несколько недостатков схемы сертификации Common Criteria: [14]
- Уязвимость заключалась в самодельном алгоритме генерации ключей RSA, который не был опубликован и проанализирован сообществом криптоанализа. Однако испытательная лаборатория TÜV Informationstechnik GmbH (TÜViT) в Германии одобрила его использование, а орган по сертификации BSI в Германии выдал сертификаты Common Criteria для уязвимых продуктов. Security Target оцениваемого продукта заявил, что ключи RSA генерируются в соответствии со стандартным алгоритмом. В ответ на эту уязвимость BSI теперь планирует повысить прозрачность, потребовав, чтобы в отчете о сертификации по крайней мере указывалось, соответствует ли реализованная фирменная криптография рекомендуемому стандарту. BSI не планирует требовать публикации фирменного алгоритма каким-либо образом.
- Несмотря на то, что органы по сертификации теперь знают, что требования безопасности, указанные в сертификатах Common Criteria, больше не действуют, ни ANSSI , ни BSI не отозвали соответствующие сертификаты. Согласно BSI , сертификат может быть отозван только в том случае, если он был выдан по недоразумению, например, когда выясняется, что были представлены неверные доказательства. После выдачи сертификата следует предположить, что его действительность со временем снижается из-за обнаружения улучшений и новых атак. Органы по сертификации могут выпускать отчеты о техническом обслуживании и даже проводить повторную сертификацию продукта. Однако эти действия должны инициироваться и спонсироваться поставщиком.
- Хотя несколько сертифицированных по Common Criteria продуктов были затронуты уязвимостью ROCA, ответы поставщиков в контексте сертификации были разными. Для некоторых продуктов был выпущен отчет о техническом обслуживании, в котором указано, что только ключи RSA длиной 3072 и 3584 бит имеют уровень безопасности не менее 100 бит, в то время как для некоторых продуктов отчет о техническом обслуживании не упоминает, что изменение TOE влияет на сертифицированную криптографическую функциональность безопасности, но делает вывод, что изменение находится на уровне руководящей документации и не влияет на обеспечение.
- По данным BSI , пользователи сертифицированных конечных продуктов должны были быть проинформированы об уязвимости ROCA поставщиками. Однако эта информация не была своевременно доведена до эстонских властей, которые развернули уязвимый продукт на более чем 750 000 эстонских удостоверениях личности .
Альтернативные подходы
За время существования CC он не был принят повсеместно даже странами-создателями, в частности, криптографические утверждения обрабатывались отдельно, например, канадско-американской реализацией FIPS-140 и Схемой вспомогательных продуктов CESG (CAPS) [15] в Великобритании.
В Великобритании также был разработан ряд альтернативных схем, когда было установлено, что сроки, затраты и накладные расходы на взаимное признание препятствуют работе рынка:
- Схемы оценки системы CESG (SYSn) и ускоренного подхода ( FTA ) для обеспечения государственных систем, а не общих продуктов и услуг, которые теперь объединены в индивидуальную службу обеспечения CESG (CTAS) [16]
- Знак соответствия требованиям CESG (знак CCT), который направлен на выполнение менее исчерпывающих требований к гарантиям для продуктов и услуг эффективным с точки зрения затрат и времени способом.
В начале 2011 года NSA/CSS опубликовали статью Криса Солтера, в которой предлагался подход, ориентированный на профиль защиты , к оценке. В этом подходе сообщества по интересам формируются вокруг типов технологий, которые в свою очередь разрабатывают профили защиты, определяющие методологию оценки для типа технологии. [17] Целью является более надежная оценка. Есть некоторые опасения, что это может оказать негативное влияние на взаимное признание. [18]
В сентябре 2012 года Common Criteria опубликовала Vision Statement [19], во многом реализующую мысли Криса Солтера из предыдущего года. Ключевые элементы Vision включали:
- Технические сообщества будут сосредоточены на разработке профилей защиты (PP), которые поддерживают их цель получения разумных, сопоставимых, воспроизводимых и экономически эффективных результатов оценки.
- Оценки следует проводить по этим ПП, если это возможно; в противном случае взаимное признание оценок целевых показателей безопасности будет ограничено уровнем EAL2.
Смотрите также
Ссылки
- ^ "Публикации: Портал CC" . Получено 2024-01-06 .
- ^ "Общие критерии - Установление безопасности связи". Архивировано из оригинала 2021-02-01 . Получено 2015-03-02 .
- ^ "Продукты, сертифицированные по общим критериям" . Получено 2023-12-30 .
- ^ "Обзор индийской схемы сертификации Common Criteria (IC3S)" . Получено 2023-12-30 .
- ^ "Члены CCRA". The Common Criteria Portal . Архивировано из оригинала 2008-08-22.
- ^ «Соглашение о признании сертификатов общих критериев в области безопасности информационных технологий» (PDF) . 2014-07-02 . Получено 2023-12-30 .
- ^ "Заявление о видении Комитета по управлению общими критериями" (PDF) . 2012-09-01 . Получено 2023-12-30 .
- ^ "Версии Windows получают Common Criteria EAL уровня 4+". Новости сетевой информационной безопасности и технологий . 2005-12-14. Архивировано из оригинала 2006-10-14.
- ^ Под атакой: Common Criteria имеет множество критиков, но получает ли он плохую репутацию Архивировано 2021-04-23 в Wayback Machine Government Computer News, извлечено 2007-12-14
- ^ Уилер, Дэвид (11.12.2006). "Free-Libre/Программное обеспечение с открытым исходным кодом (FLOSS) и Software Assurance/Безопасность программного обеспечения" (PDF) . Получено 30.12.2023 .
- ^ Вайринен, Дж.; Боден, М.; Бострём, Г. «Инженерия безопасности и экстремальное программирование: невозможный брак?». Конспект лекций по информатике . doi :10.1007/978-3-540-27777-4_12.
- ^ Безносов, Константин; Крухтен, Филипп (2005-10-16). "Towards Agile Security Assurance" . Получено 2023-12-30 .
- ^ Каллберг, Ян (01.08.2012). «Общие критерии встречают Realpolitik — доверие, альянсы и потенциальное предательство» (PDF) . Получено 30.12.2023 .
- ^ Парсовс, Арнис (2021-03-03). Эстонская электронная идентификационная карта и проблемы ее безопасности (PhD) (на эстонском языке). Тартуский университет. С. 141–143 . Получено 2023-12-30 .
- ^ "CAPS: CESG Assisted Products Scheme". Архивировано из оригинала 2008-08-01.
- ↑ Infosec Assurance and Certification Services (IACS) Архивировано 20 февраля 2008 г. на Wayback Machine
- ^ Salter, Chris (2011-01-10). "Общие критерии реформ: более качественные продукты безопасности за счет расширения сотрудничества с промышленностью" (PDF) . Архивировано из оригинала (PDF) 17 апреля 2012 г.
- ^ Брикман, Джошуа (11.03.2011). «Общие критерии «реформы» — пан или пропал — как промышленность должна справиться с назревающей революцией с общими критериями?». Архивировано из оригинала 29.05.2012.
- ^ "Заявление о видении Комитета по управлению CCRA относительно будущего направления применения CC и CCRA" (DOCX) . 2012-09-18 . Получено 2023-12-30 .
Внешние ссылки
- Официальный сайт проекта Common Criteria
- Стандартные документы Common Criteria
- Список продуктов, оцененных по общим критериям
- Список лицензированных лабораторий Common Criteria
- На пути к гибкому обеспечению безопасности
- Важные сокращения общих критериев
- Форум пользователей Common Criteria
- Дополнительная информация об общих критериях на Google Knol
- OpenCC Project – бесплатная лицензия Apache CC, документация, шаблоны и инструменты
- Краткая справочная карта по общим критериям
- Памятка по процессу Common Criteria
- Хронология процесса Common Criteria
