信息技术安全评估共同准则
 |
信息技术安全评估共同准则（Common Criteria for Information Technology Security Evaluation），简称共同准则（Common Criteria）或CC，是计算机安全认证的国际标准（ISO/IEC 15408）。目前的版本是3.1版，第5次修订[1]。
共同准则是信息安全性的架构，电脑系统的用户可以在安全目标（Security Target，ST）文件当中，标示安全机能需求（Security Functional Requirements，SFR）及安全保障需求（Security Assurance Requirement，SAR），也可以从系统的保护轮廓（Protection Profile，PP）中获取这些资料。供应商可以实现或是声明其产品的安全属性，测试实验室可以评估这些产品，确认其是否符合声明的属性。换句话说，共同准则提供了保证，电脑安全产品的规格、实现以及评估可以用一个严谨、标准化且可重复的方式进行，而且可以与目标使用环境相称[2]。共同准则会维护一份已认证产品的清单，其中包括操作系统、访问控制系统、数据库及密钥管理系统[3]。
相关概念
[编辑]共同准则评估是实施在电脑安全产品上的，以下是一些相关的概念：
- 评估目标（Target of Evaluation，TOE）：是指要评估的系统或是产品，评估可以验证目标性能相关的声明。为了要符合实务情形，评估需要确认目标的安全特性：可以用以下方式来进行：
- 保护轮廓（Protection Profile，PP）：识别某一类安全设备（例如用来进行数字签名的智能卡，或是网络防火墙）安全需求的文件，多半是用户或用户组体所产出，而且其安全设备是和用户的特定用途有关。产品的供应商可以让其产品满足一个或是多个保护轮廓，并且让其产品在这些保护轮廓下进行评估。这种情形下，保护轮廓可以是产品安全目标（ST）模版，或是安全目标作者至少会确保，所有相关保护轮廓的需求都会在产品的安全目标的文件中。寻求这类特定产品的顾客可以将重心放在符合其需求的保护轮廓，再找有相关认证的产品。
- 安全目标（Security Target，ST）：识别要评估的产品或系统安全性质的文件。安全目标中可能会声明此产品符合一个或是多个保护轮廓（PP）。评估会针对安全目标里面的安全机能需求（SFR）来评估，不多不少。因此供应商可以调整其评估方式，精准的符合产品预期要有的性能。像网络防火墙不需要符合数据库管理系统的所有安全需求，不同的防火墙也可能是用完全不同的需求清单来进行评估。一般来说会将安全目标对外发行，因此潜在客户才可以依评估认证的安全特性来查找产品。
- 安全机能需求（Security Functional Requirements，SFR）：说明产品的安全机能。共同准则会列出这些机能的标准目录。例如：安全机能需求可能会说明针对以角色为基础的访问控制的用户，需以什么方式进行身份验证。安全机能需求的列表可能会依不同评估而不同，就算是二个相同种类的产品也可能会有不同的列表。虽然共同准则没有规定在安全目标中一定要有安全机能需求，不过会列出各个机能（例如依角色限制访问能力的机能）若要正常运作，会和哪些其他机能（例如识别不同角色的能力）有相依性。
评估过程也会透过质量保证的流程，设法建立有关产品安全特性的可信度信息：
- 安全保障需求（Security Assurance Requirement，SAR）：叙述在产品开发及评估过程中，为了确认符合安全性功能所进行的措施。例如评估会要求所有的程序源代码都要放在变更管理系统中，或是要进行全功能测试。共同准则也会提供相关措施的目录，需求可能会随评估而不同。特定的产品的需求会列在其保护轮廓（PP）及安全目标（ST）文件中。
- 评估保障等级（Evaluation Assurance Level，EAL）：以数值方式来针对评估的深度以及严谨性进行评比。每一个EAL会对应一组安全保障需求（SAR），这些安全保障需求包括了产品完全开发的过程，有一定的严谨性。共同准则中列有七个等级，其中的EAL 1是最基础的（不论实施或是评估都最便宜），EAL 7最严格（也最贵）。一般而言，不会针对个别的保护轮廓（PP）或安全目标（ST）去指定评估保障等级，会针对一组的保护轮廓及安全目标来定义，也有可能针对一些领域再扩展更高等级的安全需求。高评估保障等级不一定表示“安全性较高”，只表示的评估目标（TOE）所声明的安全保障已用更深入的方式进行验证及确认。
目前，大部分的保护轮廓，大部分评估的安全目标及认证的产品都是IT产品（例如防火墙、操作系统、智能卡等）。 有时在IT流程中会列出共同准则认证。其他标准也可能会包括，例如互操作性、系统管理、用户训练、供应商的CC评估以及其他产品标准。例子包括有ISO/IEC 27002及德国的IT基准保护。
评估目标中密码学实现的细节不在CC的范围内。不过像是FIPS 140-2等国际标准会列出密码模块的规格，也有许多的标准要求加密使用的算法。
最近保护轮廓（PP）中也会加入CC评估的加解密要求，一般会包括在FIPS 140-2评估内，透过对方案的特定解释来加大CC的应用范围。
有些国际评估方案已不考虑以EAL为基础（EAL-based）的评估，只考虑已核可的保护轮廓，接受和这些保护轮廓严谨兼容的评估。美国目前只接受以保护轮廓为基础（PP-based）的评估，加拿大也开始要排除以EAL为基础的评估。
测试组织
[编辑]测试实验室需符合ISO/IEC 17025，认证体也要是ISO/IEC 17065核可的组织。
ISO/IEC 17025的合规性一般是由国家级的认证单位来进行：
- 加拿大的加拿大标准委员会（SCC）依实验室认可计划（PALCAN）会针对共同准则评估机构（Common Criteria Evaluation Facilities，CCEF）进行认证。
- 法国的法国认证委员会（COFRA）会针对共同准则的评估机构进行认证，评估机构一般会称为信息技术安全评估中心（CESTI）。评估是依国家信息系统安全局（ANSSI）的规范及标准进行。
- 意大利的IT安全认证机构（Organismo di Certificazione della Sicurezza Informatica，OCSI）会针对共同准则的评估机构进行认证。
- 英国的英国认证服务（UKAS）会认证商业评估机构(Commercial Evaluation Facilities，CLEF），英国自2019年起只是CC生态系中的消费者，不提供认证。
- 美国的国家标准技术研究所（NIST）的国家自愿实验室认可计划（NVLAP）会认证通用准则测试实验室（Common Criteria Testing Laboratories，CCTL）
- 德国的国家级认证单位是联邦信息安全办公室（BSI）
- 西班牙的国家密码学中心（CCN）会认证西班牙架构下的通用准则测试实验室。
- 荷兰的IT安全领域的认证计划（Netherlands scheme for Certification in the Area of IT Security，NSCIB）会认证IT安全评估机构（IT Security Evaluation Facilities，ITSEF）。
- 瑞典的IT安全认证机构（Swedish Certification Body for IT Security，CSEC）会认证IT安全评估机构（IT Security Evaluation Facilities，ITSEF）。
这些组织的特性会在ICCC 10中进行检验及说明[4]。
相互认可协议
[编辑]除了信息技术安全评估共同准则以外，也有子条约等级的共同准则相互认可协议（MRA，Mutual Recognition Arrangement），其中的各国家认可其他国家所进行的共同准则评估。相互认可协议最早是由加拿大、法国、德国、英国、美国、澳洲及新西兰在1998年签署，之后芬兰、希腊、以色列、意大利、荷兰、挪威和西班牙在2000年加入。协议后来更名为“通用标准识别协议”（Common Criteria Recognition Arrangement，CCRA），成员也继续扩展中[5]。CCRA相互认可的评估最多只到EAL 2（包括缺陷修复的增强版本）。在以前ITSEC范围内的欧盟国家也认可更高等级的EAL。EAL5或更高等级的评估一般会涉及目的国家的安全要求。
问题
[编辑]需求
[编辑]信息技术安全评估共同准则是通用性的准则，没有特定产品（产品类别）安全机能需求的列表，这是依ITSEC的作法，但以往有其他规范性更强的标准，例如TCSEC或FIPS 140-2。
认证的价值
[编辑]信息技术安全评估共同准则本身无法保证安全性，只能确认待评估产品声称的安全属性已经过独立验证。经过此方式评估的产品有明确的验证，在规格、实现、评估的各过程都有严谨且标准化的做法。
许多的微软视窗系统（包括Windows Server 2003及Windows XP）都已通过认证[6]，但微软仍然会针对安全漏洞发行安全补丁。其可能原因是因为获取此认证的过程允许供应商限制安全机能分析时的分析范围，并且针对产品的应用环境以及威胁强度进行假设。而且，为了成本效益以及有用的安全认证，此认证认为有必要限制评估范围，因此受验证产品是以依保证程度或保护轮廓的指定的细节来进行测试。因此，评估活动不论其深度、使用时间、资源都有一定限度，在预期的环境下可以提供合理的保证。
受验证的微软Windows操作系统在没有安装安全漏洞补丁的情形下，评估保障等级可以到EAL4+。这可以看出评估配置的限制以及强度。
批评
[编辑]2007年8月时，Government Computing News（GCN）中的专栏作家William Jackson针对共同准则的方法论以及美国的通用标准评估与验证计划（Common Criteria Evaluation and Validation Scheme，CCEVS）进行了严格的检验[7]。同时也访问了安全产业的的主管，研究者，以及美国国家信息保障合作组织（National Information Assurance Partnership，NIAP）的代表。文章中提出来，反对共同准则的意见如下：
- 评估很花钱（会耗费数十万美元），而供应商投资所得到的不一定是更安全的产品。
- 评估主要是确认评估文件，不是针对实际的安全性、技术正确性或产品的优点。只有EAL5或更高等级的评估才会有美国国家安全局的专家参与评估，只有EAL7及以上的评估才会进行完全代码的分析。
- 要准备评估证据以及评估相关文件花的心力以及时间都非常的烦琐，因此当评估完成时，评估的产品往往已经过气，没有竞争力了。
- 产业界的意见，包括像是通用标准供应商（Common Criteria Vendor's Forum）等组织的意见，在整个过程中没有什么影响力。
相关条目
[编辑]- Bell–LaPadula模型
- 中国强制性产品认证
- 评估保障等级
- FIPS 140-2
- 信息保障
- ISO 9241
- ISO/IEC 27001
- 可用性测试
- 验证及确认
- 可控式访问保护配置文件（CAPP）
参考资料
[编辑]- ^ The Common Criteria. [2021-01-25]. （原始内容存档于2006-07-18）.
- ^ Common Criteria - Communication Security Establishment. [2021-01-25]. （原始内容存档于2021-02-01）.
- ^ Common Criteria Certified Products. [2021-01-25]. （原始内容存档于2021-05-13）.
- ^ Common Criteria Schemes Around the World (PDF). [2021-01-27]. （原始内容存档 (PDF)于2020-09-27）.
- ^ membership continues to expand. [2008-08-22]. （原始内容存档于2008-08-22）.
- ^ , have been certified （页面存档备份，存于互联网档案馆）
- ^ Under Attack: Common Criteria has loads of critics, but is it getting a bum rap （页面存档备份，存于互联网档案馆） Government Computer News, retrieved 2007-12-14
外部链接
[编辑]- The official website of the Common Criteria Project （页面存档备份，存于互联网档案馆）
- The Common Criteria standard documents （页面存档备份，存于互联网档案馆）
- List of Common Criteria evaluated products （页面存档备份，存于互联网档案馆）
- List of Licensed Common Criteria Laboratories （页面存档备份，存于互联网档案馆）
- Towards Agile Security Assurance
- Important Common Criteria Acronyms （页面存档备份，存于互联网档案馆）
- Common Criteria Users Forum （页面存档备份，存于互联网档案馆）
- Additional Common Criteria Information on Google Knol
- OpenCC Project – free Apache license CC docs, templates and tools （页面存档备份，存于互联网档案馆）
- Common Criteria Quick Reference Card （页面存档备份，存于互联网档案馆）
- Common Criteria process cheatsheet （页面存档备份，存于互联网档案馆）
