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

Common Criteria

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

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

Ключевые идеи

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

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

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

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

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

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

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

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

История

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

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

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

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

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

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

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

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

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

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

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

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

вопросы

Требования

Common Criteria очень общий; он не предоставляет напрямую список требований безопасности продукта или функций для конкретных (классов) продуктов: это следует подходу, принятому 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 г. Новости правительственной вычислительной техники (GCN) обозреватель Уильям Джексон критически проанализировал методологию Common Criteria и ее реализацию в США с помощью Common Criteria Evaluation and Validation Scheme (CCEVS).[5] В колонке были опрошены руководители индустрии безопасности, исследователи и представители Национального информационного партнерства (NIAP). Возражения, изложенные в статье, включают:

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

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

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

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

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

  • В CESG Схемы оценки системы (SYSn) и ускоренного подхода (FTA) для обеспечения безопасности государственных систем, а не общие продукты и услуги, которые теперь объединены в CESG Tailored Assurance Service (CTAS) [11]
  • В CESG утверждает, что знак протестирован (CCT Mark), который направлен на выполнение менее исчерпывающих требований к гарантии для продуктов и услуг экономичным и эффективным способом.

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

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

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

Смотрите также

использованная литература

  1. ^ «Общие критерии».
  2. ^ «Общие критерии - установление безопасности связи».
  3. ^ «Продукция, сертифицированная по общим критериям».
  4. ^ «Схемы общих критериев во всем мире» (PDF).
  5. ^ Under Attack: Common Criteria имеет множество критиков, но получает ли он бред? Government Computer News, получено 14 декабря 2007 г.
  6. ^ Бесплатное программное обеспечение с открытым исходным кодом (FLOSS) и Software Assurance
  7. ^ Wäyrynen, J., Bodén, M., and Boström, G., Инженерия безопасности и экстремальное программирование: невозможный брак?
  8. ^ Безносов, Константин; Крухтен, Филипп. «На пути к гибкому обеспечению безопасности». Архивировано из оригинал на 2011-08-19. Получено 2007-12-14.
  9. ^ Общие критерии соответствуют Realpolitik - доверие, союзы и возможное предательство
  10. ^ «CAPS: Схема продуктов, поддерживаемых CESG». Архивировано из оригинал 1 августа 2008 г.
  11. ^ Услуги по обеспечению и сертификации Infosec (IACS) В архиве 20 февраля 2008 г. Wayback Machine
  12. ^ «Реформы общих критериев: лучшие продукты безопасности за счет расширения сотрудничества с промышленностью» (PDF). Архивировано из оригинал (PDF) 17 апреля 2012 г.
  13. ^ Реформы «общих критериев» - тонуть или плыть - как промышленность должна справляться с революцией, созревающей с использованием общих критериев? ». Архивировано из оригинал на 2012-05-29.

внешние ссылки