2.3　基本评估模型

通俗地说，CC/CEM可用来给IT产品开发者和消费者表达IT产品的安全控制措施，并给评估者提供测试和评估的模型。具体来说，按照CC的要求，评估发起者启动TOE的安全评估，提供包括作为TOE评估基础的ST、需要评估的TOE样品及其附属证据；然后评估者依据一定的评估准则、评估方法和评估体制产生对TOE满足其在ST中所规定安全要求的确认，并以安全评估技术报告的形式记录评估者的各种评估过程和结果。注意IT产品评估是以待评估TOE对应的ST为基础，而ST往往依赖于相应的PP。PP/ST编制的基础是TOE保护的资产，因此理解CC安全评估概念，特别是PP/ST中资产安全、保护对策、评估类型等是理解CC评估模型的基础。

2.3.1　资产及其安全

资产在TOE中一般以数据、信息、规则等形式由IT产品存储、处理和传输，以满足资产所有者的管理要求。资产所有者为了保证信息系统中数据资产的保密性、完整性和可用性，会严格控制这些资产的授权访问、传输和修改，以抵御可能的潜在安全威胁。

保护资产是那些对资产赋予价值的所有者的责任。实际或假定的威胁主体试图以违背所有者初衷的方式滥用这些资产。安全评估需要对资产所有者的安全对策进行风险分析。资产所有者应该意识到可能致使资产受损的各种潜在威胁，这些威胁对资产所有者而言会降低或破坏资产的价值。安全性破坏一般包括但又不仅包括以下几项：资产暴露给未授权的接收者（丧失保密性），资产由未授权用户的修改而损坏（丧失完整性），或资产的访问权被未授权地剥夺（丧失可用性）。因此，需要在资产、威胁和风险之间建立各种应对对策。图2.6说明了CC中资产安全相关概念和关系。

从图2.6可以看出，应用CC对保护资产安全的IT产品安全功能进行评估，资产所有者应分析他们使用的IT产品可能的威胁（识别威胁）及其相应的组织安全策略，并确定哪些应通过运行环境或通过行政措施加以控制，其结果就是识别出IT产品的各种安全风险。

威胁用于描述攻击者利用IT产品的某个脆弱性以达到特定破坏目的的状况。在信息安全中定义威胁时常涉及脆弱性、威胁和漏洞利用，这些概念之间相关关系概述如下。

（1）脆弱性（vulnerability）：又称弱点或漏洞，是指计算机或网络系统在硬件、软件、协议设计和实现、系统管理策略等方面存在的可能被威胁主体利用从而造成损害的薄弱点。脆弱性可能存在于IT产品的物理环境、业务过程、授权人员、系统配置、硬件、软件等各个方面，它们一旦被威胁主体成功利用就可能对IT产品保护的数据资产或IT产品本身造成损害。IT产品在上市之前或实施之后一般需要借助脆弱性分析或安全测试来消除这些弱点或漏洞。

（2）威胁（threat）：是导致发生损害IT产品的不期望事件的潜在原因。IT产品一般需要进行威胁识别和评估，以确保TOE应对某一特定威胁的安全处理的最佳方法。例如广泛采用的穿透性测试（penetration testing）就是侧重于评估威胁，以帮助制订有效的对策来防范特定威胁所代表的各类攻击。威胁描述一般要包括特定类型攻击的来源（主体）、技术手段及涉及的资产。

（3）漏洞利用（exploit）：IT产品的脆弱性可能会被威胁主体利用。漏洞利用过程也可以理解为威胁主体利用脆弱性对最终的资产造成实质性的威胁。人们一般借助漏洞利用测试暴露IT产品的脆弱性，以有助于向需要解决IT产品安全问题的各方提供用于识别意外风险的数据。

某种特定的威胁可以利用IT产品的一个或一组脆弱性，对资产造成损害。资产所有者应分析可能的安全威胁并确定哪些脆弱性存在于IT产品内或IT产品运行所处的环境中，以防范和控制潜在的安全风险。因此，在讨论漏洞利用中人们也常提到信息安全风险的概念。所谓安全风险，是指人为或自然的威胁利用IT产品及其管控体系中存在的脆弱性导致安全事件的发生及其对组织造成的影响（GB/T 20984《信息安全技术　信息安全风险评估规范》）。风险评估是为了确定威胁并尽快解决最重要的潜在脆弱性，列举最关键和最有可能的信息安全危险，并评估漏洞修复费用和可能性的过程。换句话说，风险评估要评估资产面临的威胁以及威胁利用脆弱性导致安全事件的可能性，并结合安全事件所涉及的资产价值来判断安全事件一旦发生将对组织造成的影响。这种评估会有助于资产所有者选择合适的安全保护对策，以应对各种风险并将其降低到一个可接受的水平。

在资产所有者将其资产泄露于特定威胁之前，所有者需要确信其对策足以应付面临的威胁。资产的所有者自己可能没有能力对安全保护对策的所有方面加以判断，但可以寻求第三方机构对其管理资产的IT产品或IT系统进行安全评估。评估结果是对安全保障能力可达程度（保障级）的描述，即信任对策能用于降低所保护资产的风险。该描述还将对策的保障能力进行分级。CC中定义的保障级别是对策的特性，这种特性是信任IT产品安全功能正确操作的基础。资产所有者可以根据此描述决定是否接受将资产泄露给威胁者所冒的风险。更多关于安全对策（控制）和如何实现及管理这些对策的讨论见GB/T 22080—2016《信息技术　安全技术　信息安全管理体系　要求》、GB/T 22081—2016《信息技术　安全技术　信息安全控制实践指南》等信息安全管理体系相关标准与指南。

资产所有者可能要对IT产品管理的资产安全负保护责任。因此，IT产品应提供足够的安全控制措施以支持资产所有者对安全策略的实施做出决定，以接受由IT产品/系统导致的资产泄露所带来的风险。

为了支持此项决定，IT产品的资产所有者应能够证实以下两个方面。

（1）对策是充分的：如果IT产品对策做了声称要做的事情，就能够对抗对资产的威胁。

（2）对策是正确的：IT产品对策确实做了资产所有者声称要做的事情。

许多资产所有者缺乏必要的知识、专业技术和各种资源来判断他们采用的IT产品保护资产对策的充分性和正确性，他们并不希望仅仅依赖对策开发者的各种声明与主张，而是希望借助第三方安全评估机构对他们使用的IT产品安全对策进行评估，以增加对所有或部分对策的充分性和正确性的信心（如图2.7所示）。

在CC中，资产保护对策的充分性是通过PP或ST文档结构中的安全目的原理来分析的。PP/ST从描述IT产品管理的资产和对这些资产的安全问题（假设、威胁或组织安全策略）开始，然后它们以安全目的形式描述IT产品给出的对策，并证实这些对策对于对抗这些威胁或组织安全策略是充分的：如果对策做了声称要做的事情，那么对策应足以对抗威胁，并满足相关组织安全策略的要求。更详细和完整的PP/ST编制描述参见本书第4章和第5章。

在PP/ST中将资产安全对策划分为两组。

（1）TOE的安全目的：描述了IT产品安全评估中需要确定其本身安全功能行为及其正确性的对策。

（2）运行环境安全目的：描述了不需要在IT产品评估中确定其正确性的对策。

这样划分安全对策的理由如下。

（1）CC仅仅适合于评估IT产品本身安全对策的正确性，因此，非技术对策（安保人员、管理规范）总是放在TOE运行环境的假设中考虑。

（2）对策的正确性评估耗费时间和金钱，因此，评估TOE可采用的所有安全对策的正确性也许不可行。

（3）某些信息技术对策的正确性可能已经在其他评估中评估了，因此，再次评估其正确性在成本效益上并不合算。

总而言之，PP/ST证实了以下几点。

（1）TOE安全目的和运行环境安全目的足以满足组织安全策略和对抗潜在威胁。

（2）TOE安全功能和安全保障要求满足TOE安全目的。

（3）TOE安全功能规范足以证实TOE安全要求得到了实现。

从这些方面看，基于CC描述的对策遵循了正确的TOE（满足SFR），与正确的运行环境（满足运行环境安全目的）结合来对抗资产面临的各种潜在安全问题。

2.3.2　TOE评估

保护资产的IT产品在设计和实现过程中可能存在不正确性。因此，IT产品运行过程中可能包含着导致本身失效的脆弱性。攻击者（威胁主体）通过利用这些脆弱性，仍可能破坏和（或）滥用IT产品管理的资产。在GB/T 20984《信息安全技术　信息安全风险评估规范》标准中，对IT产品脆弱性提出了两个属性。

（1）脆弱性的严重程度：基于“如果脆弱性被威胁者利用，将对资产造成损害”的程度。

（2）脆弱性的可利用程度：基于“利用技术实现的难易程度、脆弱性的流行程度”。

在GB/T 20984的“风险要素关系”描述中给出了IT产品“脆弱性”概念与资产安全保护对策相关的关系（见图2.8）。风险评估围绕着资产、威胁、风险、脆弱性和安全控制措施这些基本要素（图2.8中方框部分）展开，在对基本要素的评估过程中，需要充分考虑业务战略、资产价值、安全需求、安全事件、残余风险等与这些基本要素相关的各类属性（图2.8中椭圆部分）。图2.8中描述了风险要素及脆弱性属性之间存在的以下关系。

（1）业务战略的实现对资产具有依赖性，依赖程度越高，要求其风险越小。

（2）资产是有价值的，业务战略对资产的依赖程度越高，资产价值就越大。

（3）风险是由威胁引发的，资产面临的威胁越多则风险越大，并可能演变成为安全事件。

（4）脆弱性可能影响资产的价值，弱点越多则风险越大。

（5）脆弱性是未被满足的安全需求，威胁利用脆弱性危害资产。

（6）风险的存在及对风险的认识可导出安全需求。

（7）安全需求可通过安全控制措施得以满足，需要结合资产价值考虑实施成本。

（8）安全控制措施可抵御威胁，降低风险。

（9）残余风险有些是安全控制措施不当或无效，需要加强才可控制的风险；而有些则是在综合考虑了安全成本与效益后不去控制的风险。

（10）残余风险应受到密切监管，它可能会在将来诱发新的安全事件。

TOE脆弱性可能由IT产品研发期间的意外错误、糟糕的设计、故意添加的恶意代码、糟糕的测试、不合规的安全配置等多种因素引发。TOE的正确性评估一方面是对TOE的安全功能进行验证测试（独立性测试），同时也需要对这些脆弱性的“可利用程度”和“严重程度”进行测试（穿透性测试）。第三方测评机构一般需要基于某种评估准则对TOE安全功能的正确性和安全实现的可信性进行评估。

前面讲过，为保证评估结果的一致性、可重现性和IT产品的合格评定，CC提供了标准化的信息技术安全评估方法——CEM。CC建议TOE消费者、开发者和评估者在使用标准化CC安全组件表达TOE安全要求、描述TOE开发者安全方案和通过评估确认用户需求解决方案之前，首先要对TOE进行定义，明确IT产品保护的资产及其相关对策，之后才能对TOE实现的正确性进行安全评估。图2.9描述了CEM采用的TOE评估过程，安全评估活动的主要输入有以下三种。

（1）TOE开发者提供的一系列TOE评估证据。

（2）需要评估的TOE样品，包括作为TOE评估基础的评估过的安全技术要求（即PP/ST）。

（3）CC及其评估方法（CC/CEM）、国家评估体制等。

从图2.9所示的IT产品安全评估过程看出，TOE安全评估涉及下列术语。

（1）安全要求：用CC安全组件及标准化结构陈述的安全技术要求，旨在达到TOE的安全问题、安全目的和安全要求的一致性，一般体现为PP/ST。

（2）开发过程文档：与TOE实现表示有关的IT产品生命周期阶段中相关技术文档及其开发过程控制文件等。

（3）安全评估对象：按照TOE消费者需求表达、TOE开发者安全方案和供货商提供的IT产品，安全评估对象分为4类，PP、ST、TOE以及组合TOE。

（4）安全评估证据：TOE开发者提供的待PP、ST、TOE以及组合TOE的TOE样品及各种评估交付件。

（5）评估交付件：TOE评估者或监管者为执行一个或多个评估或评估监督活动所必需的，由TOE评估发起者或开发者提交的所有资源，包括安全要求、TOE开发过程文档、评估TOE样品、TOE评估证据等。

（6）检查（Examine）评估活动：评估者通过采用专业技能分析形成裁决。使用此动词的语句表明哪些是分析对象以及对象的哪些属性。

（7）裁决（Verdict）评估活动：评估者发布的关于评估者行为元素、保障组件或类是“通过”“不通过”，还是“待定”的一项决定。

（8）评估体制（Scheme）：评估管理机构制定的一套规则，这套规则定义了TOE评估环境，包括IT安全评估所需的通用评估准则和评估方法。

另外，在PP/ST的说明性材料（例如CC和安全评估方法及其安全组件应用注释）和安全评估人员及安全评估机构的IT基础设施、安全评估技术与工具等安全专业知识也常用来作为TOE评估过程的输入。

IT产品评估过程的预期结果是对TOE满足ST中安全要求的确认，其形式是评估者依据CEM对TOE得出的一个或多个记载测试或调查结果的报告。这些报告对IT产品的实际用户和潜在用户非常有用，对TOE开发者也同样具有指导作用。

通过评估获得的信任度依赖于TOE所达到的安全保障要求。评估通过以下两种途径促成TOE开发者产生安全的IT产品。

（1）评估意在发现TOE错误或脆弱性，以便TOE开发者纠正，从而减少在IT产品未来的操作中安全失效发生的可能性。

（2）或为了迎接严格的评估，TOE开发者在TOE设计和开发时会更加细心。因此，评估过程对最初需求、开发过程、最终产品以及运行环境产生强烈的，虽然是间接的但又是积极的影响。

为确定TOE安全功能实现的正确性，可以执行的评估活动如下。

（1）抽样测试TOE和通过自主设计的测试用例独立测试TOE。

（2）检查TOE的安全架构、各种设计和实现表示文档及其证据。

（3）检查TOE开发环境的物理安全、过程安全和管理规程等。

PP/ST以安全保障要求的形式提供了TOE生命周期过程中这些安全保障活动的结构化描述，以确定TOE在设计和开发过程中安全功能实现正确性的可信度。这些安全保障要求用CC标准化安全保障组件方式来表示，以保证TOE安全实现的正确性和可比性。

如果TOE满足了PP/ST中的安全要求，那么CC就假设TOE安全行为的正确性是可信的。换句话说，TOE安全功能正确性的可信度由其保障级别确定：“弱”的安全保障级别所能提供安全保障组件较少，而许多“强”的安全保障级别可提供更大的TOE安全可信保障。CC第3部分按照TOE提供的保障强弱，将TOE的安全保障程度分为7个级别：EAL 1～EAL 7。TOE评估保障级别越高，其安全保障能力或安全功能实现正确性的可信度就越高，TOE就可对抗来自越高程度的安全威胁，同时也适用更高安全风险环境的应用。

基于CEM的TOE安全行为正确性评估输出主要有以下几种。

（1）记录：评估者记载程序、事件、观察结果、所了解事项和结果的书面描述。该描述需足够详细，以便评估过程中执行的工作能够重现。

（2）裁决：评估者发布的关于CC中一个评估者行为元素、保障组件或类是“通过”“不通过”，还是“待定”的一项决定。

（3）报告：将评估结果和支持性材料纳入评估技术报告或观察报告。

（4）观察报告：在评估过程中评估者编写的要求澄清或标识一个问题的报告。

（5）评估技术报告：由评估者编写并呈交给监管者，以文档形式记录评估总体裁决及其理由的报告。

TOE评估目的是确定TOE安全功能实现正确性和TOE安全功能实现的可信度，包括两个方面。

（1）TOE安全功能实现是否与ST中的安全功能规范要求一致：依据TOE开发者提供的一系列评估证据（如分析、设计与测试文档），由评估者一方按照ST功能要求对TOE的安全功能进行抽样测试或通过自主设计测试用例进行安全功能的验证，在仿真环境下完成TOE安全功能的符合性测试。所以TOE安全功能实现正确性评估一般也叫独立性测试评估和（或）安全功能要求的符合性测试评估。

（2）TOE安全功能实现正确的可信性是否与ST中的安全保障要求一致：为了发现TOE在设计与实现中的缺陷或脆弱性，纠正TOE开发者相应的错误，减少TOE操作中安全失效发生的可能性，需要采用穿透性测试等脆弱性评定方法来评估TOE的安全性。所以CEM要求评估人员在仿真环境中模拟真实应用需求，测试TOE是否能抵御与安全保障级别相当的安全攻击，以确定该产品是否存在潜在的脆弱性。

TOE安全评估应由国家评估体制认可的CC测试实验室负责完成，但评估结果的文档化，测评技术报告的编写及其细节把握应当由CEM及评估所遵循的国家评估体制共同确定。

TOE评估过程产生的结果为下列两种情况之一。

（1）并未满足所有安全保障要求（SAR），因此，评估结果未达到ST中所述的TOE满足安全功能要求（SFR）的特定保障级别。

（2）满足所有安全保障要求（SAR），因此，评估结果达到了ST中所述的TOE满足安全功能要求（SFR）的特定保障级别。

注意TOE安全问题定义应详细描述安全要求的所有假设、预期的使用范围、要保护资产所面临的已知威胁及其TOE必须遵循的组织安全策略（OSP），但需要注意的是TOE运行环境的设计和实现也可能不正确，因此可能包含导致脆弱性的错误，攻击者通过利用这些脆弱性，仍然可以破坏和（或）滥用TOE保护的资产。

TOE运行环境的正确性评估就是TOE在未来运行过程中所处的IT环境满足TOE预期的安全要求，包括预期被使用的环境范围和特征，以及预期的使用方式等各种安全假设。然而，基于CC的IT产品安全评估是在CC测试实验室环境中完成的，无法保障TOE未来可获得有关运行环境的正确性假设。换句话说，在CEM中不包括TOE运行环境的评估内容，运行环境被假设为可以100%地实现运行环境安全目的。就像前面说的，CC所说的TOE评估一般不评估TOE运行环境的正确性。

这不排除TOE的消费者使用其他方法确定其运行环境的正确性，例如：

（1）对于一个操作系统，运行环境安全目的声明“运行环境将确保来自不可信网络（如，Internet）的实体只能通过文件传输协议（FTP）访问TOE”，消费者可以选择一个经过评估的防火墙，配置它为仅允许通过FTP对TOE进行访问；

（2）如果运行环境安全目的声明“运行环境将确保所有管理人员没有恶意行为”，TOE消费者可以调整其与管理人员的合同使其包括对恶意行为的惩罚性制裁，但这个不是CC规定的评估内容（评估范围）。

TOE评估可以在TOE开发完成之后进行，或者与TOE开发并行完成。

2.3.3　PP/ST/ACO评估

除了上面描述的面向IT产品的TOE评估，CC/CEM还规范了PP、ST和ACO评估方法。CC第3部分描述了PP、ST和ACO的具体评估要求。图2.10示意了CEM中给出的PP/ST文档的评估流程，ST比PP多一个TOE概要规范评估步骤。注意CEM中的PP评估与其所声明的EAL（或保障要求的其他集合）没有关系，CEM中对PP评估和ACO评估的要求和方法对每个EAL级别都是相同的，但ST/TOE评估与其所声明的EAL级别有关。因此，在许多地方，CC“评估”（不限定）一般是指ST和TOE评估。

GB/Z 30286—2013《信息安全技术　信息系统保护轮廓和信息系统安全目标产生指南》给出了PP/ST文档生成过程，分为如下几个步骤。

（1）确定TOE涉及的关键资产、TOE所处的运行环境和TOE的用途；关键资产就是要保护的内容，TOE运行环境指与TOE安全性相关的IT运行环境的所有方面，包括己知的物理和人员的安全假设，TOE用途说明产品类型和预期的TOE用法。

（2）根据前述三者确定TOE安全问题，包括关键资产所面临的威胁、安全假设和需要遵从的组织安全策略，其中威胁是指TOE所受的潜在攻击，假设是指TOE职责不需要考虑的安全要求，组织安全策略是指一些约定好的安全规章制度和安全控制措施。

（3）对确定的安全问题进行风险分析，确定哪些安全隐患比较严重，哪些安全问题不需要考虑，由此确定TOE需要解决的TOE安全目的及相关的环境安全目的。

（4）由TOE安全目的导出CC中相应的标准化安全组件，即确定TOE所需要的安全功能组件和安全保障组件。

（5）将安全功能组件和安全保障组件结合TOE实现的具体情况描述ST中的TOE概要规范（TSS），由此完成PP/ST文档的编制。

CC第3部分定义了PP/ST文档生成相关的保障要求（APE/ASE），CEM给出了这两类文档生成保障要求相应的评估活动（详见第6章）。