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

Из Википедии, бесплатной энциклопедии

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

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

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

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

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

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

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

До сих пор большинство ПЗ и наиболее оцененных ЗБ/сертифицированных продуктов относились к ИТ-компонентам (например, межсетевым экранам, операционным системам , смарт-картам).

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

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

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

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

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

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

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

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

Тестирующие организации [ править ]

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

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

Характеристики этих организаций были рассмотрены и представлены на 10-й сессии ICCC.

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

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

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

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

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

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

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

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

Стоимость сертификации [ править ]

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

Различные версии Microsoft Windows, включая Windows Server 2003 и Windows XP , были сертифицированы. Архивировано 30 сентября 2017 г. на Wayback Machine , но исправления безопасности для устранения уязвимостей безопасности все еще публикуются Microsoft для этих систем Windows. Это возможно, поскольку процесс получения сертификации Common Criteria позволяет поставщику ограничить анализ определенными функциями безопасности и сделать определенные предположения относительно операционной среды и силы угроз, с которыми сталкивается продукт в этой среде. Кроме того, CC признает необходимость ограничить объем оценки, чтобы обеспечить экономически эффективные и полезные сертификаты безопасности, например, чтобы оцениваемые продукты проверялись на уровне детализации, определенном уровнем доверия или PP. Таким образом, деятельность по оценке выполняется только с определенной глубиной, использованием времени и ресурсов и обеспечивает разумную гарантию для предполагаемой среды.

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

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

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

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

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

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

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

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

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

В 2017 году уязвимость ROCA была обнаружена в списке продуктов смарт-карт, сертифицированных по общим критериям. Уязвимость выявила несколько недостатков схемы сертификации Common Criteria: [12]

  • Уязвимость заключалась в собственном алгоритме генерации ключей RSA, который не был опубликован и не проанализирован сообществом криптоанализа. Однако испытательная лаборатория TÜV Informationstechnik GmbH (TÜViT) в Германии одобрила его использование, а орган по сертификации BSI в Германии выдал сертификаты Common Criteria для уязвимых продуктов. Security Target оцениваемого продукта утверждал, что ключи RSA генерируются в соответствии со стандартным алгоритмом. В ответ на эту уязвимость BSI теперь планирует повысить прозрачность, потребовав, чтобы в отчете о сертификации как минимум указывалось, не соответствует ли реализованная проприетарная криптография в полной мере рекомендуемому стандарту. BSI не планирует каким-либо образом требовать публикации запатентованного алгоритма.
  • Несмотря на то, что органы по сертификации теперь знают, что требования безопасности, указанные в сертификатах Common Criteria, больше не действительны, ни ANSSI , ни BSI не отозвали соответствующие сертификаты. По мнению BSI , сертификат может быть отозван только в том случае, если он был выдан по ошибке, например, когда выяснится, что были представлены неверные доказательства. После выдачи сертификата следует предположить, что срок действия сертификата со временем уменьшается из-за улучшения и обнаружения новых атак. Органы по сертификации могут выдавать отчеты о техническом обслуживании и даже проводить повторную сертификацию продукта. Однако эти действия должны быть инициированы и спонсированы поставщиком.
  • Хотя дефект ROCA затронул несколько продуктов, сертифицированных по общим критериям, реакция поставщиков в контексте сертификации была разной. Для некоторых продуктов был выпущен отчет о сопровождении, в котором указано, что только ключи RSA длиной 3072 и 3584 бита имеют уровень безопасности не менее 100 бит, при этом для некоторых продуктов в отчете о сопровождении не упоминается, что изменение ОО влияет сертифицированные функции криптографической безопасности, но приходит к выводу, что изменение находится на уровне руководящей документации и не влияет на гарантии.
  • По мнению BSI , пользователи сертифицированных конечных продуктов должны были быть проинформированы об уязвимости ROCA поставщиками . Однако эта информация не дошла своевременно до эстонских властей, которые использовали уязвимый продукт на более чем 750 000 эстонских удостоверениях личности .

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

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

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

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

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

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

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

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

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

  1. ^ «Публикации: Портал ЦК» . Проверено 6 января 2024 г.
  2. ^ «Общие критерии – обеспечение безопасности связи» . Архивировано из оригинала 01 февраля 2021 г. Проверено 2 марта 2015 г.
  3. ^ «Продукция, сертифицированная по общим критериям» . Проверено 30 декабря 2023 г.
  4. ^ «Обзор Индийской схемы сертификации по общим критериям (IC3S)» . Проверено 30 декабря 2023 г.
  5. ^ «Соглашение о признании сертификатов общих критериев в области безопасности информационных технологий» (PDF) . 02 июля 2014 г. Проверено 30 декабря 2023 г.
  6. ^ «Заявление о видении Комитета по управлению общими критериями» (PDF) . 01.09.2012 . Проверено 30 декабря 2023 г.
  7. ↑ Под атакой: Common Criteria имеет множество критиков, но вызывает ли она негативную реакцию. Архивировано 23 апреля 2021 г. в Wayback Machine Government Computer News, получено 14 декабря 2007 г.
  8. ^ Уиллер, Дэвид (11 декабря 2006 г.). «Бесплатное/открытое программное обеспечение (FLOSS) и гарантия программного обеспечения/безопасность программного обеспечения» (PDF) . Проверено 30 декабря 2023 г.
  9. ^ Вайринен, Дж.; Боден, М.; Бострем, Г. «Инженерия безопасности и экстремальное программирование: невозможный брак?». Конспекты лекций по информатике . дои : 10.1007/978-3-540-27777-4_12 .
  10. ^ Безносов Константин; Крухтен, Филипп (16 октября 2005 г.). «На пути к гибкому обеспечению безопасности» . Проверено 30 декабря 2023 г.
  11. ^ Каллберг, Ян (01 августа 2012 г.). «Общие критерии соответствуют реальной политике: доверие, союзы и потенциальное предательство» (PDF) . Проверено 30 декабря 2023 г.
  12. ^ Парсовс, Арнис (03 марта 2021 г.). Эстонское электронное удостоверение личности и проблемы его безопасности (доктор философии) (на эстонском языке). Тартуский университет. стр. 141–143 . Проверено 30 декабря 2023 г.
  13. ^ «CAPS: Схема вспомогательных продуктов CESG» . Архивировано из оригинала 1 августа 2008 г.
  14. ^ Службы обеспечения и сертификации Infosec (IACS). Архивировано 20 февраля 2008 г., в Wayback Machine.
  15. ^ Солтер, Крис (10 января 2011 г.). «Реформы общих критериев: улучшение продуктов безопасности за счет расширения сотрудничества с промышленностью» (PDF) . Архивировано из оригинала (PDF) 17 апреля 2012 г.
  16. ^ Брикман, Джошуа (11 марта 2011 г.). «Общие критерии «реформ» — тонуть или плыть. Как промышленности справиться с назревающей революцией, основанной на общих критериях?» . Архивировано из оригинала 29 мая 2012 г.
  17. ^ «Заявление управляющего комитета CCRA о будущем направлении применения CC и CCRA» (DOCX) . 18 сентября 2012 г. Проверено 30 декабря 2023 г.

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

Retrieved from "https://en.wikipedia.org/w/index.php?title=Common_Criteria&oldid=1205382049"