Введение
Международный стандарт сертификации компьютерной безопасности.
Общие критерии оценки безопасности информационных технологий (далее – Общие критерии или CC) – это международный стандарт (ISO/IEC 15408) для сертификации компьютерной безопасности. В настоящее время действует версия 3.1, редакция 5. Общие критерии представляют собой основу, в рамках которой пользователи компьютерных систем могут определить свои функциональные и требования к уровню доверия (SFR и SAR соответственно) в документе «Цель безопасности» (ST), которые могут быть взяты из профилей защиты (PP). Поставщики могут затем реализовывать или заявлять об атрибутах безопасности своих продуктов, а испытательные лаборатории могут оценить эти продукты, чтобы определить, соответствуют ли они заявленным характеристикам. Иными словами, Общие критерии обеспечивают уверенность в том, что процесс определения требований, реализации и оценки продукта компьютерной безопасности был проведен последовательно, в соответствии со стандартом и может быть повторен на уровне, соответствующем целевой среде использования. Общие критерии поддерживают список сертифицированных продуктов, включая операционные системы, системы контроля доступа, базы данных и системы управления ключами.
The Common Criteria for Information Technology Security Evaluation (referred to as Common Criteria or CC) is an international standard (ISO/IEC 15408) for computer security certification. It is currently in version 3.1 revision 5. Common Criteria is a framework in which computer system users can specify their security functional and assurance requirements (SFRs and SARs, respectively) in a Security Target (ST), and may be taken from Protection Profiles (PPs). Vendors can then implement or make claims about the security attributes of their products, and testing laboratories can evaluate the products to determine if they actually meet the claims. In other words, Common Criteria provides assurance that the process of specification, implementation and evaluation of a computer security product has been conducted in a rigorous and standard and repeatable manner at a level that is commensurate with the target environment for use. Common Criteria maintains a list of certified products, including operating systems, access control systems, databases, and key management systems.
Соглашение о взаимном признании
Помимо стандарта "Общие критерии", существует также соглашение о взаимном признании (MRA) на уровне подсоглашения "Общие критерии", в рамках которого каждая сторона признает оценки, проведенные другими сторонами в соответствии со стандартом "Общие критерии". Первоначально подписанное в 1998 году Канадой, Францией, Германией, Соединенным Королевством и Соединенными Штатами, к нему присоединились Австралия и Новая Зеландия в 1999 году, а затем в 2000 году – Финляндия, Греция, Израиль, Италия, Нидерланды, Норвегия и Испания. Соглашение впоследствии было переименовано в Соглашение о признании "Общих критериев" (CCRA), и число участников продолжает расти. В рамках CCRA взаимно признаются только оценки до уровня EAL 2 (включая дополнения по устранению уязвимостей). Европейские страны, участвующие в SOGIS MRA, как правило, признают и более высокие уровни EAL. Оценки уровня EAL5 и выше обычно включают требования безопасности правительства страны, в которой проводится оценка. В сентябре 2012 года большинство членов CCRA приняли декларацию о видении, согласно которой взаимное признание продуктов, оцененных по "Общим критериям", будет снижено до уровня EAL 2 (включая дополнения по устранению уязвимостей). Кроме того, в этой декларации указывается отход от уровней заверения в целом, и оценки будут ограничиваться соответствием профилям защиты, не имеющим установленного уровня заверения. Это будет достигнуто посредством технических рабочих групп, разрабатывающих профили защиты (ПП) международного уровня, и переходный период пока не определен. 2 июля 2014 года была ратифицирована новая CCRA в соответствии с целями, изложенными в декларации о видении 2012 года. Основные изменения в Соглашении включают: признание оценок, проведенных только в соответствии с совместным профилем защиты (cPP) или уровнями заверения 1–2 и ALC FLR. Формирование международных технических сообществ (iTC) – групп технических экспертов, ответственных за создание cPP. План перехода от предыдущей CCRA, включая признание сертификатов, выданных в соответствии с предыдущей версией Соглашения.
Recognition of evaluations against only a collaborative Protection Profile (cPP) or Evaluation Assurance Levels 1 through 2 and ALC FLR. The emergence of international Technical Communities (iTC), groups of technical experts charged with the creation of cPPs. A transition plan from the previous CCRA, including recognition of certificates issued under the previous version of the Arrangement.
Требования
Общие критерии носят очень общий характер; они не предоставляют непосредственного списка требований к безопасности продукта или функций для конкретных (классов) продуктов. Это соответствует подходу, принятому в ITSEC, но вызвало споры у тех, кто привык к более директивному подходу других, более ранних стандартов, таких как TCSEC и FIPS 140-2.
Значение сертификации
Сертификация по Общим критериям не может гарантировать безопасность, но обеспечивает независимую проверку заявлений о защитных атрибутах оцениваемого продукта. Иными словами, продукты, прошедшие оценку в соответствии со стандартом Общих критериев, демонстрируют четкую цепочку доказательств того, что процессы спецификации, реализации и оценки были выполнены тщательно и в соответствии со стандартами. Различные версии Microsoft Windows, включая Windows Server 2003 и Windows XP, были сертифицированы, однако Microsoft продолжает выпускать обновления безопасности для устранения уязвимостей в этих системах Windows. Это возможно, поскольку процесс получения сертификации по Общим критериям позволяет поставщику ограничить анализ определенными функциями безопасности и делать определенные предположения об операционной среде и уровне угроз, с которыми сталкивается продукт в этой среде. Кроме того, Общие критерии признают необходимость ограничения области оценки для обеспечения экономически эффективных и полезных сертификатов безопасности, в соответствии с которыми оцениваемые продукты проверяются с уровнем детализации, определяемым уровнем гарантии или ПП. Таким образом, оценка проводится на определенную глубину, с использованием определенного количества времени и ресурсов, и обеспечивает разумную уверенность в предполагаемой среде. В случае с Microsoft, предположения включают A. ПЕР: "Любые другие системы, с которыми взаимодействует оцениваемый продукт (TOE), предположительно находятся под тем же управлением и работают в соответствии с теми же ограничениями политики безопасности. Оцениваемый продукт применим к сетевым или распределенным средам только в том случае, если вся сеть работает в соответствии с одними и теми же ограничениями и находится в пределах единого домена управления. Нет требований безопасности, касающихся необходимости доверять внешним системам или каналам связи с ними". Это предположение содержится в Профиле защиты с контролируемым доступом (CAPP), которому соответствуют их продукты. На основе этого и других предположений, которые могут быть нереалистичными для типичного использования операционных систем общего назначения, оцениваются заявленные функции безопасности продуктов Windows. Следовательно, их следует считать безопасными только в предполагаемых, определенных обстоятельствах, также известных как оцениваемая конфигурация. Независимо от того, используете ли вы Microsoft Windows в точности в оцениваемой конфигурации или нет, необходимо применять обновления безопасности Microsoft для устранения уязвимостей в Windows по мере их появления. Если любая из этих уязвимостей может быть использована в оцениваемой конфигурации продукта, поставщик должен добровольно отозвать сертификацию продукта по Общим критериям. В качестве альтернативы, поставщик должен повторно оценить продукт, включив в оценку применение обновлений для устранения уязвимостей безопасности в рамках оцениваемой конфигурации. В случае невыполнения поставщиком ни одного из этих действий, орган по сертификации страны, в которой был оценен продукт, принудительно отозовет сертификацию продукта. Сертифицированные версии Microsoft Windows остаются на уровне EAL4+ без применения каких-либо исправлений уязвимостей безопасности Microsoft в их оцениваемой конфигурации. Это демонстрирует как ограничения, так и преимущества оцениваемой конфигурации.
"Any other systems with which the TOE communicates are assumed to be under the same management control and operate under the same security policy constraints. The TOE is applicable to networked or distributed environments only if the entire network operates under the same constraints and resides within a single management domain. There are no security requirements that address the need to trust external systems or the communications links to such systems." This assumption is contained in the Controlled Access Protection Profile (CAPP) to which their products adhere. Based on this and other assumptions, which may not be realistic for the common use of general purpose operating systems, the claimed security functions of the Windows products are evaluated. Thus they should only be considered secure in the assumed, specified circumstances, also known as the evaluated configuration. Whether you run Microsoft Windows in the precise evaluated configuration or not, you should apply Microsoft's security patches for the vulnerabilities in Windows as they continue to appear. If any of these security vulnerabilities are exploitable in the product's evaluated configuration, the product's Common Criteria certification should be voluntarily withdrawn by the vendor. Alternatively, the vendor should re evaluate the product to include the application of patches to fix the security vulnerabilities within the evaluated configuration. Failure by the vendor to take either of these steps would result in involuntary withdrawal of the product's certification by the certification body of the country in which the product was evaluated. The certified Microsoft Windows versions remain at EAL4+ without including the application of any Microsoft security vulnerability patches in their evaluated configuration. This shows both the limitation and strength of an evaluated configuration.
Критика
В августе 2007 года обозреватель Government Computing News (GCN) Уильям Джексон подверг критическому анализу методологию Common Criteria и ее реализацию в США посредством Схемы оценки и валидации общих критериев (CCEVS). В статье были опрошены руководители из индустрии безопасности, исследователи и представители Национального партнерства по информационной безопасности (NIAP). В статье были изложены следующие возражения:
Evaluation is a costly process (often measured in hundreds of thousands of US dollars) – and the vendor's return on that investment is not necessarily a more secure product. Evaluation focuses primarily on assessing the evaluation documentation, not on the actual security, technical correctness or merits of the product itself. For U. S. evaluations, only at EAL5 and higher do experts from the National Security Agency participate in the analysis; and only at EAL7 is full source code analysis required. The effort and time necessary to prepare evaluation evidence and other evaluation related documentation is so cumbersome that by the time the work is completed, the product in evaluation is generally obsolete. Industry input, including that from organizations such as the Common Criteria Vendor's Forum, generally has little impact on the process as a whole. In a 2006 research paper, computer specialist David A. Wheeler suggested that the Common Criteria process discriminates against free and open source software (FOSS) centric organizations and development models. Common Criteria assurance requirements tend to be inspired by the traditional waterfall software development methodology. In contrast, much FOSS software is produced using modern agile paradigms. Although some have argued that both paradigms do not align well, others have attempted to reconcile both paradigms. Political scientist Jan Kallberg raised concerns over the lack of control over the actual production of the products once they are certified, the absence of a permanently staffed organizational body that monitors compliance, and the idea that the trust in the Common Criteria IT security certifications will be maintained across geopolitical boundaries. In 2017, the ROCA vulnerability was found in a list of Common Criteria certified smart card products. The vulnerability highlighted several shortcomings of Common Criteria certification scheme:
The vulnerability resided in a homegrown RSA key generation algorithm that has not been published and analyzed by the cryptanalysis community. However, the testing laboratory TÜV Informationstechnik GmbH (TÜViT) in Germany approved its use and the certification body BSI in Germany issued Common Criteria certificates for the vulnerable products. The Security Target of the evaluated product claimed that RSA keys are generated according to the standard algorithm. In response to this vulnerability, BSI now plans to improve transparency by requiring that the certification report at least specifies if the implemented proprietary cryptography is not exactly conformant to a recommended standard. BSI does not plan on requiring the proprietary algorithm to be published in any way. Even though the certification bodies are now aware that the security claims specified in the Common Criteria certificates do not hold anymore, neither ANSSI nor BSI have revoked the corresponding certificates. According to BSI, a certificate can only be withdrawn when it was issued under misconception, e. g., when it turns out that wrong evidence was submitted. After a certificate is issued, it must be presumed that the validity of the certificate decreases over time by improved and new attacks being discovered. Certification bodies can issue maintenance reports and even perform a re certification of the product. These activities, however, have to be initiated and sponsored by the vendor. While several Common Criteria certified products have been affected by the ROCA flaw, vendors' responses in the context of certification have been different. For some products a maintenance report was issued, which states that only RSA keys with a length of 3072 and 3584 bits have a security level of at least 100 bits, while for some products the maintenance report does not mention that the change to the TOE affects certified cryptographic security functionality, but concludes that the change is at the level of guidance documentation and has no effect on assurance. According BSI, the users of the certified end products should have been informed of the ROCA vulnerability by the vendors. This information, however, did not reach in a timely manner the Estonian authorities who had deployed the vulnerable product on more than 750,000 Estonian identity cards.
Оценка – дорогостоящий процесс (часто оцениваемый в сотни тысяч долларов США), и возврат инвестиций для поставщика не обязательно приводит к созданию более защищенного продукта. Оценка в основном сосредоточена на проверке оценочной документации, а не на реальной безопасности, технической корректности или достоинствах самого продукта. Для оценок в США эксперты из Агентства национальной безопасности участвуют в анализе только на уровне EAL5 и выше; и только на уровне EAL7 требуется полный анализ исходного кода. Объем усилий и времени, необходимых для подготовки доказательств оценки и другой сопутствующей документации, настолько велик, что к моменту завершения работы оцениваемый продукт, как правило, устаревает. Мнение индустрии, включая вклад таких организаций, как Форум поставщиков Common Criteria, обычно оказывает незначительное влияние на процесс в целом. В исследовательской работе 2006 года специалист по компьютерам Дэвид А. Уилер предположил, что процесс Common Criteria дискриминирует организации и модели разработки, ориентированные на свободное и открытое программное обеспечение (FOSS). Требования Common Criteria к обеспечению надежности, как правило, основаны на традиционной каскадной методологии разработки программного обеспечения. В то же время, большая часть программного обеспечения FOSS создается с использованием современных гибких методологий. Хотя некоторые утверждают, что эти две методологии плохо сочетаются, другие пытаются их согласовать. Политолог Ян Каллберг выразил обеспокоенность по поводу отсутствия контроля над фактическим производством продуктов после их сертификации, отсутствия постоянно действующего организационного органа, осуществляющего мониторинг соответствия, и опасения, что доверие к сертификатам безопасности ИТ Common Criteria сохранится в условиях геополитических границ. В 2017 году уязвимость ROCA была обнаружена в списке сертифицированных по Common Criteria продуктов смарт-карт. Эта уязвимость выявила несколько недостатков схемы сертификации Common Criteria:
Evaluation is a costly process (often measured in hundreds of thousands of US dollars) – and the vendor's return on that investment is not necessarily a more secure product. Evaluation focuses primarily on assessing the evaluation documentation, not on the actual security, technical correctness or merits of the product itself. For U. S. evaluations, only at EAL5 and higher do experts from the National Security Agency participate in the analysis; and only at EAL7 is full source code analysis required. The effort and time necessary to prepare evaluation evidence and other evaluation related documentation is so cumbersome that by the time the work is completed, the product in evaluation is generally obsolete. Industry input, including that from organizations such as the Common Criteria Vendor's Forum, generally has little impact on the process as a whole. In a 2006 research paper, computer specialist David A. Wheeler suggested that the Common Criteria process discriminates against free and open source software (FOSS) centric organizations and development models. Common Criteria assurance requirements tend to be inspired by the traditional waterfall software development methodology. In contrast, much FOSS software is produced using modern agile paradigms. Although some have argued that both paradigms do not align well, others have attempted to reconcile both paradigms. Political scientist Jan Kallberg raised concerns over the lack of control over the actual production of the products once they are certified, the absence of a permanently staffed organizational body that monitors compliance, and the idea that the trust in the Common Criteria IT security certifications will be maintained across geopolitical boundaries. In 2017, the ROCA vulnerability was found in a list of Common Criteria certified smart card products. The vulnerability highlighted several shortcomings of Common Criteria certification scheme:
The vulnerability resided in a homegrown RSA key generation algorithm that has not been published and analyzed by the cryptanalysis community. However, the testing laboratory TÜV Informationstechnik GmbH (TÜViT) in Germany approved its use and the certification body BSI in Germany issued Common Criteria certificates for the vulnerable products. The Security Target of the evaluated product claimed that RSA keys are generated according to the standard algorithm. In response to this vulnerability, BSI now plans to improve transparency by requiring that the certification report at least specifies if the implemented proprietary cryptography is not exactly conformant to a recommended standard. BSI does not plan on requiring the proprietary algorithm to be published in any way. Even though the certification bodies are now aware that the security claims specified in the Common Criteria certificates do not hold anymore, neither ANSSI nor BSI have revoked the corresponding certificates. According to BSI, a certificate can only be withdrawn when it was issued under misconception, e. g., when it turns out that wrong evidence was submitted. After a certificate is issued, it must be presumed that the validity of the certificate decreases over time by improved and new attacks being discovered. Certification bodies can issue maintenance reports and even perform a re certification of the product. These activities, however, have to be initiated and sponsored by the vendor. While several Common Criteria certified products have been affected by the ROCA flaw, vendors' responses in the context of certification have been different. For some products a maintenance report was issued, which states that only RSA keys with a length of 3072 and 3584 bits have a security level of at least 100 bits, while for some products the maintenance report does not mention that the change to the TOE affects certified cryptographic security functionality, but concludes that the change is at the level of guidance documentation and has no effect on assurance. According BSI, the users of the certified end products should have been informed of the ROCA vulnerability by the vendors. This information, however, did not reach in a timely manner the Estonian authorities who had deployed the vulnerable product on more than 750,000 Estonian identity cards.
Уязвимость заключалась в самостоятельно разработанном алгоритме генерации ключей RSA, который не был опубликован и проанализирован криптографическим сообществом. Однако испытательная лаборатория TÜV Informationstechnik GmbH (TÜViT) в Германии одобрила его использование, а орган по сертификации BSI в Германии выдал сертификаты Common Criteria для уязвимых продуктов. В документе о целях безопасности оцениваемого продукта утверждалось, что ключи RSA генерируются в соответствии со стандартным алгоритмом. В ответ на эту уязвимость BSI планирует повысить прозрачность, требуя, чтобы в отчете о сертификации указывалось, не соответствует ли реализованная проприетарная криптография рекомендованному стандарту. BSI не планирует требовать публикации проприетарного алгоритма. Несмотря на то, что органы по сертификации теперь знают, что требования безопасности, указанные в сертификатах Common Criteria, больше недействительны, ни ANSSI, ни BSI не отозвали соответствующие сертификаты. По словам BSI, сертификат может быть отозван только в том случае, если он был выдан на основании ошибочных предположений, например, если выяснится, что были представлены неверные доказательства. После выдачи сертификата предполагается, что его действительность со временем снижается из-за обнаружения новых и улучшенных атак. Органы по сертификации могут выпускать отчеты о техническом обслуживании и даже проводить повторную сертификацию продукта. Однако эти действия должны быть инициированы и профинансированы поставщиком. Хотя несколько продуктов, сертифицированных по Common Criteria, пострадали от уязвимости ROCA, реакция поставщиков в контексте сертификации была различной. Для некоторых продуктов был выпущен отчет о техническом обслуживании, в котором указывалось, что только ключи RSA длиной 3072 и 3584 бита имеют уровень безопасности не менее 100 бит, в то время как для других продуктов в отчете о техническом обслуживании не упоминалось, что изменение TOE влияет на сертифицированную криптографическую функциональность, но заключалось, что изменение относится к руководящей документации и не влияет на уровень гарантий. По словам BSI, пользователи сертифицированных конечных продуктов должны были быть проинформированы поставщиками об уязвимости ROCA. Однако эта информация не дошла своевременно до властей Эстонии, которые развернули уязвимый продукт на более чем 750 000 эстонских удостоверениях личности.
Evaluation is a costly process (often measured in hundreds of thousands of US dollars) – and the vendor's return on that investment is not necessarily a more secure product. Evaluation focuses primarily on assessing the evaluation documentation, not on the actual security, technical correctness or merits of the product itself. For U. S. evaluations, only at EAL5 and higher do experts from the National Security Agency participate in the analysis; and only at EAL7 is full source code analysis required. The effort and time necessary to prepare evaluation evidence and other evaluation related documentation is so cumbersome that by the time the work is completed, the product in evaluation is generally obsolete. Industry input, including that from organizations such as the Common Criteria Vendor's Forum, generally has little impact on the process as a whole. In a 2006 research paper, computer specialist David A. Wheeler suggested that the Common Criteria process discriminates against free and open source software (FOSS) centric organizations and development models. Common Criteria assurance requirements tend to be inspired by the traditional waterfall software development methodology. In contrast, much FOSS software is produced using modern agile paradigms. Although some have argued that both paradigms do not align well, others have attempted to reconcile both paradigms. Political scientist Jan Kallberg raised concerns over the lack of control over the actual production of the products once they are certified, the absence of a permanently staffed organizational body that monitors compliance, and the idea that the trust in the Common Criteria IT security certifications will be maintained across geopolitical boundaries. In 2017, the ROCA vulnerability was found in a list of Common Criteria certified smart card products. The vulnerability highlighted several shortcomings of Common Criteria certification scheme:
The vulnerability resided in a homegrown RSA key generation algorithm that has not been published and analyzed by the cryptanalysis community. However, the testing laboratory TÜV Informationstechnik GmbH (TÜViT) in Germany approved its use and the certification body BSI in Germany issued Common Criteria certificates for the vulnerable products. The Security Target of the evaluated product claimed that RSA keys are generated according to the standard algorithm. In response to this vulnerability, BSI now plans to improve transparency by requiring that the certification report at least specifies if the implemented proprietary cryptography is not exactly conformant to a recommended standard. BSI does not plan on requiring the proprietary algorithm to be published in any way. Even though the certification bodies are now aware that the security claims specified in the Common Criteria certificates do not hold anymore, neither ANSSI nor BSI have revoked the corresponding certificates. According to BSI, a certificate can only be withdrawn when it was issued under misconception, e. g., when it turns out that wrong evidence was submitted. After a certificate is issued, it must be presumed that the validity of the certificate decreases over time by improved and new attacks being discovered. Certification bodies can issue maintenance reports and even perform a re certification of the product. These activities, however, have to be initiated and sponsored by the vendor. While several Common Criteria certified products have been affected by the ROCA flaw, vendors' responses in the context of certification have been different. For some products a maintenance report was issued, which states that only RSA keys with a length of 3072 and 3584 bits have a security level of at least 100 bits, while for some products the maintenance report does not mention that the change to the TOE affects certified cryptographic security functionality, but concludes that the change is at the level of guidance documentation and has no effect on assurance. According BSI, the users of the certified end products should have been informed of the ROCA vulnerability by the vendors. This information, however, did not reach in a timely manner the Estonian authorities who had deployed the vulnerable product on more than 750,000 Estonian identity cards.