解读CC认证ST文档

笔者因为有一段时间接触过CC认证，所以想把一些经验记录下来。本文主要是解读CC认证中ST文档的结构和内容。

CC认证是一个国际安全认证，全称叫Common Criterial，该认证分为ASE，ADV，AGD，ATE, ALC, AVA等几个部分。

首先，先初步介绍一下文中涉及到的缩略语

• CC -Common Criteria 通用标准认证
• TOE -Target Of Evaluation 认证的目标产品
• ASE -Security Target Evaluation 对ST文档评估的保障
• ST -Security Target ST文档，用于ASE评估
• ADV -Development 和设计开发相关的文档评估
• AGD -Guidance Documents 操作指南文档评估
• ALC -Life-Cycle Support 生命周期文档评估，包括配置管理，缺陷管理，生命周期管理等等
• ATE -Tests 测试文档评估，包括测试计划，测试用例执行结果等
• AVA -Vulnerability Assessment 脆弱点评估
• EAL -Evaluation Assurance Level 认证等级，分为1-7 这7个等级
• PP -Protection Profile 保护轮廓，可以简单理解为一类产品的通用ST模板
• SFR -Security Functional Requirements
• SAR -Security Assurance Requirements

接下来讲CC认证的核心逻辑，包括安全概念及关系，认证概念及关系。

CC认证核心逻辑

安全概念及关系

下面是我对这张图的理解。

所有的安全活动都是以资产为锚点，每个资产都是对应的所有者。

威胁主体会对资产造成威胁，以致增加了资产面临的风险。

所有者的目标是通过一些对策去消除/减小/转移风险。

认证概念及关系

下面是我对这张图的理解。 基于前面提到的“安全概念及关系”，所有者需要资产的风险是可接受的信心。而这个信心可以通过CC认证评估通过后得到增强。

换句话说，所有者因为资产通过了CC认证，所以增强了对资产安全的信心，资产的安全通过资产面临的风险去衡量及评估。

那么CC认证怎么去提供信心呢？通过两个方面：

• 通过证明对策最小化风险的充分性，也就是说对策是充分的，所以风险能最小化
• 通过证明对策实现的正确性，也就是说对策是被正确实现的，所以风险做到了最小化

如果对策是充分的，那么只要正确的实现对策，就能提供给所有者以资产安全的信心。

ST文档解读

ST文档就是证明充分性的描述文档。

CC中ASE就是对ST文档进行评估。而本文的主要目标就是解读ST的逻辑框架。

ST是一类叫做安全目标的文档。大多数的CC认证的第一个步骤就是编写ST文档（有部分认证是从PP开始，这个不在本文讨论范围），在完成ASE评估后，才会进行下一步如ADV，AGD等模块。之所以ST是认证第一步要做的事，是因为后续的ADV，AGD都依赖ST的描述进行评估，如果ST的范围不断变化，后续的评估也要不断变化。所以最重要的是先把安全目标及范围定义清楚。

CC的认证顺序结构大体如下图所示

ST文档的结构在CCPART1的附录A中定义的非常清楚，每个章节应该写什么内容都明确了，开发者（开发TOE的角色）只需要按照既定结构把ST内容补充完整即可。

以”[ST] 20180627 - FFHDD-ASE v3.04”[5]为例，我们来解读一下这个ST文档。

EAL等级解释

评估等级是通过广度，深度，细化三个方面衡量的，高等级相比低等级，这三个方向的要求会逐渐加强。

EAL共分为7个等级，这些等级分别对应的要求，在CCPART3V3.1R5的第8章节有进行介绍。如果有符号+号表示认证的范围比相应等级要求的更高。比如所有的认证等级都不包含FLR模块（FLR是Flaw remediation的简写），这意味着如果做某个等级的认证比如EAL7，附带还做了FLR.2的认证，那么最终呈现的是EAL7+的等级。

对比下方两张图片，可以看到，ST认证的等级为EAL 7+，比EAL7在广度上多了ALC_FLR.3，在深度上由ASE_TSS.1变为ASE_TSS.2，所以认证等级带有+号。

EAL7标准定义的要求如下图

实际产品进行EAL7认证时，符合如下要求

不能单一的认为安全等级越高就越安全，要横向比对同类产品的安全等级，比如数据二极管这类产品，相对来说EAL等级都比较高。而其他如防火墙类产品，相比而言都比较低。同类产品里，安全功能越多，认证就越复杂，相比而言也就越安全。

第1章 Security Target Introduction

读完第一章，可以了解到TOE及TOE的使用，TOE的安全功能等。

Security Target Reference and TOE Reference

这个章节主要是确定ST和TOE的唯一性（通过名称，版本，作者，时间，开发者等等字段信息）

TOE Overview

TOE overview主要从三个方面进行描述

• TOE type
• Usage and major security features of a TOE
• Required non-TOE hardware/software/firmware

TOE type主要介绍TOE是什么东西，有什么用。

TOE的使用及主要安全功能 以本次分析的数据二极管为例，使用很简单，就是入口和出口接光纤，主要安全功能是让数据只能从上游发到下游，保护下游的机密性，保护上游完整性。

本产品的使用不需要其他硬件，软件，固件等，所以没有写。

TOE Description

TOE Description包括TOE物理范围和逻辑范围，物理范围包括硬件，软件，固件，文档等组成TOE的所有部分。逻辑范围主要是TOE提供的逻辑安全功能，这里描述的安全功能要相比于TOE Overview的描述要更细致一些。

物理范围

逻辑范围

第2章 Conformance Claim

兼容性申明，包括了使用哪个版本的CC标准，认证EAL哪个等级，有没有其他扩展的认证模块等。

第3章 Security Problem Definition

引用CCPART1V3.1R5 373段，这段话说明了分析安全问题的重要性。

However, it should be noted that the usefulness of the results of an evaluation strongly depends on the ST, and the usefulness of the ST strongly depends on the quality of the security problem definition. It is therefore often worthwhile to spend significant resources and use well-defined processes and analyses to derive a good security problem definition.

安全问题定义包括三类

• Threats
• Organisational security policies (OSPs)
• Assumptions

首先是TOE面临哪些威胁，其次运行TOE的环境的组织需要有哪些安全策略，比如运行TOE的组织，需要有7×24h的CCTV监控等等。最后是假设，假设是对TOE运行环境的假设，比如TOE运行在一个安全的环境，不会被未授权的人员物理接触等。

OSPs和Assumptions不是必须的。

这里提到的威胁只有一个，就是用户/进程故意或意外的把数据从下游通过TOE传输到上游。并对物理/电源/网络环境进行假设。换句话说，TOE在符合这几个假设的前提下，只有一个威胁。

第4章 Security Objectives

有了安全问题之后，就需要定义安全目标，这些安全目标能解决这些威胁。

针对威胁和OSPs有TOE安全目标，针对OSPs和假设有操作环境安全目标，如下图所示。

在TOE符合OE操作环境安全目标的前提下，只要达成保护下游机密性和保护上游完整性这两个目标，就可以消除威胁。接下来要做的就是定义安全功能，以实现这些安全目标。

引用CCPART1V3.1R5 407段，这段话说明了安全目标和安全问题的关系。

Based on the security objectives and the security objectives rationale, the following conclusion can be drawn: if all security objectives are achieved then the security problem as defined in Security problem definition (ASE_SPD) is solved: all threats are countered, all OSPs are enforced, and all assumptions are upheld.

最后，需要提供安全目标和安全问题的映射关系，并陈述为什么这些安全目标能解决这些安全问题。

第5章 Extended Components Definition

CCPART2V3.1R5定义了非常多的安全功能，但也总会出现覆盖不到的情况，本章节就是用于PART2没有覆盖到的安全功能的补充。

针对本次分析的ST文档，并没有补充扩展组件。

第6章 Security Requirements

安全需求分为安全功能需求(SFR)和安全保障需求(SAR)，前面第4章定义了安全目标，要实现这些目标就需要细化到需求层面，也就是说只要实现这些需求，也就达成对应的安全目标。这类需求就是安全功能需求。

在定义了一些了安全功能需求之后，要保障这些安全功能需求得到正确的实现，就需要配套的保障体系，比如良好的开发环境，良好的配置管理体系，良好的组织管理/人员管理等体系。举个例子，开发者定义了30个安全功能需求，解决了20个威胁，但是安全保障需求定义为EAL1等级，那就意味着这个保障等级大概率无法保障安全功能需求的正确实现。也就破坏了安全需求的充分性。这类需求就是安全保障需求。

安全功能需求

可以看到案例只定义了两个安全功能需求。只要正确实现了这两个安全功能，就能达成安全目标。

安全保障需求

可以看到，案例选择做EAL7+的安全保障需求

最后，引用CCPART1V3.1R5 430段，这段话说明了安全需求（包括功能需求和保障需求）和安全问题的关系。

All of the above can be combined into the statement: If all SFRs and SARs are satisfied and all security objectives for the operational environment are achieved, then there exists assurance that the security problem as defined in ASE_SPD is solved: all threats are countered, all OSPs are enforced, and all assumptions are upheld. This is illustrated in Figure 7.

最后，需要提供安全需求和安全目标的映射关系，并陈述为什么这些安全需求能实现这些安全目标。

第7章 TOE Summary Specification

该章节内容是概要陈述TOE是怎么实现第6章描述的安全需求。这一章节是对第一章TOE逻辑范围的补充。逻辑范围描述了TOE有哪些安全功能，而本章主要是概要描述TOE是如何实现这些安全功能的。

思考与总结

CC认证逻辑性较强，标准比较难读懂，需要花很多时间理解。但是这些时间投入是值得的，CC认证搭建了一个完整的安全系统框架，实际上在工作中，时时都可以参考CC的思路去执行安全活动。

通过下面的活动，一方面从理论上证明安全的充分性，另一方面从执行上保障了实现的正确性，从这两方面支撑起产品的安全性以及人们对产品的信心。

ASE充分性证明(资产 –> 威胁 –> 安全目标 –> 安全功能需求) –> ADV设计开发安全功能 –> AGD如何安全的配置和使用TOE –> ATE对安全功能进行测试 –> AVA脆弱点评估，对ATE的补充测试 –> ALC对生命周期各活动的管控和保障

我现在对安全的认识，把安全分为三个等级，安全功能等级，安全管理等级，安全信心等级。

安全功能等级，是指产品有xxx安全功能，能实现帐户防暴破，支持TLS1.2等等。

安全管理等级，是指产品不仅拥有xxx安全功能，公司层面包括供应链，所有环节的都有良好的流程及制度保障产品的安全性。

安全信心等级，是指公司及公司的产品在用户心中的安全信心程度较高。你对当今哪家公司的安全信心程度较高呢？

参考资料

[1] https://www.commoncriteriaportal.org/cc/
[2] CCPART1V3.1R5.pdf
[3] CCPART2V3.1R5.pdf
[4] CCPART3V3.1R5.pdf
[5] [ST] 20180627 - FFHDD-ASE v3.04.pdf