脆弱性评估文档 0002

产品脆弱性评估文档

脆弱性检测是信息安全风险评估的重点。脆弱性检测一般以信息系统脆弱性的分类为切入点，以脆弱性特征库的建立为工作的重点，以确定脆弱性采集方案为最终目标。脆弱性的分类方法为特征库中的脆弱性提供了组织形式，特征库中包含的脆弱性的粒度将决定脆弱性的采集方案[1]。在国际标准化组织(ISO)所制定的第13335 号信息安全管理指南中，将脆弱性检测从资产的角度进行分类，提出了物理层面、人员、管理等重要概念。在国家标准《信息安全风险评估指南》中，明确将脆弱性分成物理、网络、系统、应用与管理五大方面，并提出从这五个方面来识别脆弱性。本文对信息系统的应用脆弱性检测的方法进行研究，提出了应用脆弱性检测的一些指导方法。

1.隐蔽信道技术分析

隐蔽信道是资源配置策略和资源管理执行结果的信道。利用正常情况下不认为是数据客体的实体，从一个主体到另一个主体进行信息传输的信道，称为隐蔽信道。因此，TCSEC定义隐蔽信道是一个通信信道，它允许进程以一种违反系统安全策略的方式传递信息:隐蔽信道只和非自主访问安全策略有关，与自主访问安全模型无关。隐蔽信道是一种可用于在用户之间传递信息的机制，而这种机制是系统不允许的。

隐蔽信道又分为隐蔽存储信道和时间隐蔽信道。

隐蔽存储信道:如果一个进程直接或间接地写一个数据变量，另外一个进程直接或间接地读这个数据变量，这样形成的隐蔽信道就称为隐蔽存储信道。

时间隐蔽信道:如果一个进程通过调整它自己使用的系统资源(例如:CPU时间)的方法，从而影响到实际的响应时间，另一个进程通过观察这个响应时间，获取相应的信息。这样形成的隐蔽信道就称为时间隐蔽信道。

不管是隐蔽存储信道还是时间隐蔽信道，发送者和接收者之间的信息必须有同步关系。

2.隐蔽信道标识

隐蔽信道标识就是搜索系统中可能存在的隐蔽信道，并进行标识。一个隐蔽信道可以用一个三元组表示:，V 表示共享变量；PA表示对共享变量V进行写操作的TCB原语；PV表示对共享变量V 进行读操作的TCB 原语。常用的隐蔽信道标识s方法主要有文法信息流分析和共享资源矩阵方法两种。这两种方法各有优缺点，目前共享资源矩阵方法应用更为普遍。

2.1文法信息流分析 文法信息流分析(SyntacticInformation-Flow Analysis )，是将信息流文法同每一 条实现语言的语句相联系。只要证明在完整的程序和TCB原语设计或源代码中，所有的信息流形式都符合信息流策略，那么就不存在隐蔽信道。否则，这个信息流可能是导致隐蔽信道的信息流，对于这些信息流必须借助语义分析确定:这个信息流是真实的还是虚假的非法信息流；这个信息流是否具有导致真实隐蔽信道的使用场景；文法信息流分析具有以下优点:能够以简单清楚的方法自动实现；可以应用于顶级形式化设计和源代码；能够应用于增量的独立功能和TCB 原语；在详细设计和源代码中，不会错过任何导致隐蔽信道的信息流。 但是，它也有以下缺点:发现的非法信息流可能是虚假的(将增加通过手动文法分析方法，消除这些信息流的工作量)；不适用于非形式化设计；不能帮助开发者确定，放置隐蔽信道处理代码的TCB位置；

2.2共享资源矩阵方法 共享资源矩阵方法(Shared ResourceMatrix Method，SRM)，要求进行以下五个步骤:分析所有形式化或非形式化，或者源代码中指定的TCB 原语操作；建立一个共享资源矩阵，行是用户可见的TCB 原语，列是被查看或修改的TCB变量；根据这些变量是读还是修改，用R或是M 标记共享资源矩阵的每一个项；对共享资源矩阵的条目进行传递闭环操作。这个步骤能鉴别所有变量的间接读，并且将相应的结果添加到共享资源矩阵中。例如:TCB原语1根据变量Y的值，决定是否对变量X 进行修改，另一个TCB 原语2 能够通过读取变量X 的值，从而间接的获取到变量Y 的值。所以TCB 原语2 能够间接的读变量Y。必须将

这个条目添加到共享资源矩阵中。对行是R 或M的每一个矩阵列进行分析，每当这些列的变量由一个进程读，而

由另一进程写，并且前一进程的优先级不支配后一进程的优先级时，这些列的变量 可能支持隐蔽信道。

3 隐蔽信道带宽估算

对于搜索到的隐蔽信道，应该估算它们的带宽。系统的硬件配置，如:CPU速度、内存大小和速度、缓存大小、硬盘速度等，对隐蔽信道带宽都有很大的影响；TCB 原语的选择、噪声等因素也对隐蔽信道的带宽有很大影响。为了估计隐蔽信道的最大带宽，假设隐蔽信道是没有噪声的，系统中只有收/发进程，收/ 发进程之间的同步时间可以忽略，这些假设对计算隐蔽信道的最大带宽是合适的，但实际上是很难达到的。

3.1隐蔽信道处理 对隐蔽信道的处理，一般采取以下三种方法:消除隐蔽信道、带宽限制、审计隐蔽信道的使用。

3.2消除隐蔽信道 为了消除系统中的隐蔽信道，必须对系统的设计和实现进行修改。这些修改包括:通过为每一个共享者预先分配所需要的最大资源，或者为每一个安全级别划分出相应的资源，从而消除可能造成隐蔽信道的资源共享。消除引起隐蔽信道的接口、功能和机制。

3.3带宽限制 带宽限制就是要降低隐蔽信道的最大值，或者平均值，以使得任何一个隐蔽信道的带宽限制在一个预先定义的可接受的范围内。限制隐蔽信道带宽的方法主要有:故意在信道中引入噪声。(例如:对共享变量使用随机分配算法，共享变量一般包括:共享表的索引，磁盘区域，进程标识等；或者以随机方式引入无关的进程修改隐蔽信道的变量。)；在每一个真实隐蔽信道的TCB 原语中，故意引入延时；

3.4审计隐蔽信道的使用 通过审计，能够对隐蔽信道的使用者起到威慑的作用。对隐蔽信道的审计，要求记录足够多的数据，以能够:标识个别隐蔽信道的使用，或者某一类型隐蔽信道的使用；标识个别

隐蔽信道或者某一类型隐蔽信道的发送者和接收者。此外还要求，必须发现所有对隐蔽信道的使用；应该避免虚假的隐蔽信道使用记录。一旦审计跟踪分析确定了一个隐蔽信道的使用，那么对于这个隐蔽信道进行真实的带宽估算是可能的，也是需要的。

通常情况下，不可能根据审计跟踪发现通过隐蔽信道泄漏的实际信息，因为用户能够对数据进行加密。同时，仅仅通过检查审计跟踪，没有办法区别泄漏的是真实信息还是噪声信息。审计隐蔽信道的使用，将遇到以下问题:无法区别是隐蔽信道的使用，还是没有危害的TCB 原语使用；在隐蔽信道使用者中，不能将发送者明确地从接收者中区

分出来。之所以会出现这些问题，是因为:单个TCB 原语，根据不同的参数值和系统状态，能够改变和查看一个变量或属性；不同的TCB 原语，能够被不同的隐蔽信道共享。这样的TCB 原语允许用户伪装隐蔽信道的使用以旁路审计，并且将引起隐蔽信道的虚假检测。隐蔽信道审计的关键设计，是决定哪些事件需要记录，哪些数据需要使用审计工具进行保存，以确保能发现所有的隐蔽

信道使用。如前所述，隐蔽信道的标识能 够简写为，因此隐蔽信道 审计应该记录所有的和 第四级只对隐蔽存储信道提出了要求，而 没有要求进行时间隐蔽信道分析。

隐蔽存储信道标识 开发者应确定用于标识隐蔽存储信道的信息来源，这些信息来源应该包括描述性高层设计和系统参考手册，还应该包括源代码和处理器设计(如果涉及到硬件分析)。开发者应保证所使用的标识方法是彻底地和可靠地，应可重复。这就意味着，其它独立测试者，使用同样的标识方法和信息来源，能够得到同样的结果。否则，标识证据将缺乏可信度。开发者所标识的隐蔽存储信道，应包括共享变量和读写变量的TCB 原语。开发者还应该将潜在的隐蔽信道和实际的隐蔽信道区分开。对于实际的隐蔽信道，开发者还应提 供实际的隐蔽信道使用场景。

隐蔽存储信道处理 开发者应根据实际情况，确定隐蔽信道的两个带宽常数:Bmin和Bmax。如果隐蔽信道的带宽小于Bmin，那么这个隐蔽信道可以被接受，不必采取什么措施；如果一个隐蔽信道的带宽大于Bmax，那么这个隐蔽信道比较严重，如果能够消除，最好消除，如果不能够消除，那

么应该采取措施将带宽降低到Bmax；如果一个隐蔽信道的带宽在Bmin和Bmax之间，那么必须对这个隐蔽信道进行审计。(通常建议Bmin=1bits/sec，Bmax=100bits/sec。)开发者应该说明:隐蔽信道是如何消除的；隐蔽信道的带宽是如何限制在一个可

接受的范围内；开发者应提供证据，证明所采取的隐蔽信道处理方法是有效的。

信息系统安全脆弱性分析技术

当前安全脆弱性时刻威胁着网络信息系统的安全。要保障网络信息安全，关键问题之一是解决安全脆弱性问题，包括安全脆弱性扫描、安全脆弱性修补、安全脆弱性预防等。

网络系统的可靠性、健壮性、抗攻击性强弱也取决于所使用的信息产品本身是否存在安全隐患。围绕安全脆弱性分析的研究工作分为以下几个方面：

第一类，基于已知脆弱性检测及局部分析方法

Satan是最早的网络脆弱性分析工具，也是该类研究的代表，由网络安全专家Dan farmer和Wietse venema研制，其基本的设计思路是模拟攻击者来尝试进入自己防守的系统，Satan具有一种扩充性好的框架，只要掌握了扩充规则，就可以把自己的检测程序和检测规则加入到这个框架中去，使它成为Satan的一个有机成分。

正因为如此，当Satan的作者放弃继续开发新版本之后，它能被别的程序员接手过去，从魔鬼（Satan）一跃变成了圣者（Saint）。Saint与Satan相比，增加了许多新的检测方法，但丝毫没有改变Satan的体系结构。Satan 系统只能运行在Unix系统上，远程用户无法使用Satan检测。Saint解决了Satan远程用户问题，但是Satan和Saint都无法对一些远程主机的本地脆弱性进行采集，而且两者的脆弱信息分析方法停留在低级别上，只能处理原始的脆弱信息。

Nessus是一款免费、开放源代码和最新的网络脆弱性分析工具，可运行在Linux、Bsd、Solaris和其他平台上，实现多线程和插件功能，提供gtk界面，目前可检查多种远程安全漏洞。但是，Nessus只能从远程进行扫描获取脆弱性。许多脆弱性是本地的，不能通过网络检测到或被利用，例如收集主机配置信息，信任关系和组的信息难以远程获取。

第二类，基于安全属性形式规范脆弱性检测方法

自动和系统地进行脆弱性分析是目前的研究重点，C.R.Ramakri-shnan和R.Sekar提出了一种基于模型的配置脆弱性分析方法，其基本原理是：首先以形式来规范目标的安全属性，例如，普通用户不能够重写系统日志子文件；其次建立系统抽象模型描述安全相关行为，抽象模型由系统的组件模型来组成，例如，文件系统、特权进程等； 最后检查抽象模型是否满足安全属性，如果不满足，则生成一个脆弱性挖掘过程操作序列，用以说明导致这些安全属性冲突的实现过程。

该方法的优点在于检测已知和新的脆弱点，而Cops和Satan主要解决已知脆弱性的检查。但是运用该方法需要占用大量计算资源，目前还无法做到实际可用，另外，方法的可扩展性仍然是一个难题，实际模型要比实验大得多。模型的开发过程依赖于手工建立，模型自动生成技术尚需要解决。

第三类，基于关联的脆弱性分析与检测

这类研究工作利用了第一、第二类研究成果，侧重脆弱性的关联分析，即从攻击者的角度描述脆弱点的挖掘过程。一款基于网络拓扑结构的脆弱分析工具Tva(Topological Vulnerability Analysis)能够模拟渗透安全专家自动地进行高强度脆弱性分析，给出脆弱点挖掘过程，生成攻击图。tva将攻击步骤及条件建立为状态迁移图，这种表示使得脆弱性分析具有好的扩充性，使得输入指定的计算资源算出安全的网络配置。

然而Tva模型化脆弱性挖掘过程依赖尚需要手工输入，该问题的解决需要一种标准的、机器能理解的语言自动获取领域知识。另外，若一个大型网络存在多个脆弱点，则Tva将产生巨大图形，因而图形的管理将成为难题。最后，tva用到的信息要准确可靠，以便确定脆弱点是否可用，但是Tva的脆弱信息只是依靠Nessus。

Laura P.Swiler等人也研制了计算机攻击图形生成工具，将网络配置、攻击者能力、攻击模板、攻击者轮廓输入到攻击图生成器就可以输出攻击图，图中最短路径集表示系统最有可能受到攻击途径。Oleg Sheyner和Joshua Haines用模型检查方法来研究攻击图的自动生成和分析，其基本的思路是将网络抽象成一个有限状态机，状态的迁移表示原子攻击，并且赋予特定安全属性要求。然后用模型检查器Nusmv自动生成攻击图，并以网络攻击领域知识来解释图中状态变量意义和分析图中的状态变迁关系。但是该方法所要处理问题是模型的可扩展性，计算开销大，建模所使用到的数据依赖于手工来实现。

第四类，脆弱性检测基础性工作，主要指脆弱信息的发现、收集、分类、标准化等研究

安全脆弱性检测依赖于安全脆弱性发现，因此脆弱性原创性发现成为最具挑战性的研究工作。当前，从事安全脆弱性挖掘的研究部门主要来自大学、安全公司、黑客团体等。在脆弱性信息发布方面，Cert最具有代表性，它是最早向Internet网络发布脆弱性信息的研究机构。而在脆弱性信息标准化工作上，Mitre开发“通用漏洞列表(Common Vulnerabilities and Exposures，CVE)”来规范脆弱性命名，同时mitre还研制出开放的脆弱性评估语言OVAL（Open Vulnerability Assessment Language），用于脆弱性检测基准测试，目前该语言正在逐步完善之中。

同国外比较，我国脆弱性信息的实时性和完整性尚欠缺，主要原因在于脆弱性新发现滞后于国外。而安全脆弱性检测、消除、防范等都受制于安全脆弱性的发现。因而，安全脆弱性分析成为最具挑战性的研究热点。

入侵检测与预警技术

网络信息系统安全保障涉及到多种安全系统，包括防护、检测、反应和恢复4个层面。入侵检测系统是其中一个重要的组成部分，扮演着数字空间“预警机”的角色。入侵检测技术大致分为五个阶段：第一阶段是基于简单攻击特征模式匹配检测；第二阶段，基于异常行为模型检测；第三阶段，基于入侵报警的关联分析检测；第四阶段，基于攻击意图检测；第五阶段，基于安全态势检测。归纳起来，入侵检测与预警发展动向表现为以下几方面。

入侵安全技术集成

由于网络技术的发展和攻击技术的变化，入侵检测系统难以解决所有的问题，例如检测、预防、响应、评估等。入侵检测系统正在发生演变：入侵检测系统、弱点检查系统、防火墙系统 、应急响应系统等，将逐步集成在一起，形成一个综合的信息安全保障系统。例如，Securedecisions公司研究开发了一个安全决策系统产品，集成IDS、Scanner、Firewall等功能，并将报警数据可视化处理。入侵阻断系统（Intrusion Prevention System）成为IDS的未来发展方向。

高性能网络入侵检测

现代网络技术的发展带来的新问题是，IDS需要进行海量计算，因而高性能检测算法及新的入侵检测体系成为研究热点。高性能并行计算技术将用于入侵检测领域，高速模式匹配算法及基于纯硬件的NIDS都是目前国外研究的内容。

入侵检测系统标准化

标准化有利于不同类型IDS之间的数据融合及IDS与其他安全产品之间的互动。IETF（Internet Engineering Task Force）的入侵检测工作组（Intrusion Detection Working Group，简称 IDWG）制定了入侵检测消息交换格式(IDMEF)、入侵检测交换协议(IDXP)、入侵报警(IAP)等标准，以适应入侵检测系统之间安全数据交换的需要。同时，这些标准协议得到了Silicon Defense、Defcom、UCSB等不同组织的支持，而且按照标准的规定进行实现。目前，开放源代码的网络入侵检测系统Snort已经支持Idmef的插件。因此，具有标准化接口的功能将是下一代IDS的发展方向。

嵌入式入侵检测

互联网的应用，使计算模式继主机计算和桌面计算之后，将进入一种全新的计算模式，这就是普适计算模式。普适计算模式强调把计算机嵌入到人们日常生活和工作环境中，使用户能方便地访问信息和得到计算的服务。随着大量移动计算设备的使用，嵌入式入侵检测技术得到了重视。

入侵检测与预警体系化

入侵检测系统由集中向分布式发展，通过探测器分布式部署，实现对入侵行为的分级监控，将报警事件汇总到入侵管理平台，然后集中关联分析，以掌握安全态势的全局监控，从而支持应急响应。目前技术正向“检测-响应”到“预警-准备”方向发展。

网络蠕虫防范技术

与传统的主机病毒相比，网络蠕虫具有更强的繁殖能力和破坏能力。传统的基于单机的病毒预防技术、基于单机联动的局域网病毒防范技术、病毒防火墙技术等都不能很好地适应开放式网络对网络蠕虫的预警要求。例如，传统的单机病毒检测技术依赖于一定的检测规则，不适应网络蠕虫的检测。因为网络中恶意代码种类繁多，形态千变万化，其入侵、感染、发作机制也千差万别。近年来的研究热点主要是：计算机蠕虫的分类、蠕虫流量的仿真及蠕虫预警系统设计与测试、蠕虫的传播仿真实验、蠕虫剖析模型及隔离技术研究。在网络蠕虫的产品市场方面，国外Silicon Defense公司发布围堵蠕虫产品Countermalice，Lancope公司的Stealthwatch产品，该产品是基于行为入侵检测系统，具有威胁管理功能。

总之，就网络蠕虫发展状况来看，网络蠕虫的攻防技术正处于发展期间，其主要技术走向包括：网络蠕虫的快速传播机制及隐蔽机制；网络蠕虫的早期预警技术和仿真测试；网络蠕虫应急响应技术，主要是阻断技术；网络蠕虫理论模型，如基于应用系统的蠕虫、数据库蠕虫、移动环境网络蠕虫。抗网络蠕虫攻击机制，如代码随机化、软件多样性、蠕虫攻击特征自动识别。

信息系统攻击容忍技术

据有关资料统计，通信中断1小时可以使保险公司损失2万美元，使航空公司损失250万美元，使投资银行损失600万美元。如果通信中断2天则足以使银行倒闭。攻击容忍技术解决的安全问题是在面临攻击、失效和偶发事件的情况下，信息网络系统仍能按用户要求完成任务，信息网络系统能够支持用户必要的业务运行。目前，国际上关于信息网络系统生存的研究处于发展阶段，其主要研究领域包括生存性概念及其特性、生存性模型和仿真、生存性工程、系统的生存性分析与评估、网络容错、数据库入侵容忍等。

TCB 及防御作用

5.1.5 TCB 访问控制

应提供控制用户与 TCB 建立会话的功能。用户会话的建立包括创建一个或多个主体（如进程），

这些主体在TCB 中代表用户执行操作，并具有相应用户的敏感标记。TCB 访问控制包括： a) TCB 会话建立：根据相关的会话安全属性，TSF 应允许或拒绝用户与TCB 建立会话。这些属性包括：访问地址或端口，用户安全属性（如用户身份、许可证等级、角色中的成员资格），时间范围（如一天中的某些时间、一周的某些天、某些特定日期），或上述属性的组合。 b) 可选属性范围限定：在与TCB 建立会话时，应限制用户可选择的会话安全属性的范围，包括访问方法、访问的地址或端口及访问时间（如一日的某些时间、一周的某些天等），以及用户可能绑定到的主体（如进程）。

c) 多重并发会话限定：应对用户在一个时间段内可能的并发会话数进行限制，包括多重并发会

话的基本限定和每位用户多重并发会话的限定。前者是对TCB 内所有用户并发会话数的限 制，后者是对每一个用户并发会话数的限制。

d) TCB 访问历史：在一次会话成功建立的基础上，应显示该账户上一次会话成功建立的日期、时间、方法和位置等信息，或显示该账户上一次会话建立不成功的日期、时间、方法和位置等信息，以及从最后一次成功的会话建立以来不成功的尝试次数。用户应能够复查这些信息，也可以放弃这些信息，并且在没有给用户提供访问历史信息的机会的情况下，不能从用户界面上抹去该信息的。

e) 会话锁定：应提供交互式会话的TSF 原发的和用户原发的锁定和解锁能力及TSF 原发终止能

力，以便在会话进入非活动周期后对末端进行锁定或结束会话。在用户的静止期超过规定的 值时，通过以下方式锁定该用户的交互式会话： ——在显示设备上清除或涂抹，使当前的内容不可读；

——取消会话解锁之外的所有用户数据的存取/显示的任何活动； ——在会话解锁之前再次鉴别。 5.2 TCB 设计和实现

5.2.1 配置管理 5.2.1.1 配置管理自动化

应通过配置管理（CM）自动化增加CM 系统的有效性，使所设计的TCB 不易受人为错误或疏忽

的影响。这里的TCB 是就纯软件而言的，通过引进自动化的CM 来协助TCB 配置项的正确生成，并确

定TCB 与其以前版本之间的变化及将来版本的改变。 CM 自动化分为：

a） 部分 CM 自动化：应确保TCB 的实现表示是通过自动方式控制的，从而解决复杂实现或众多

合作者合作开发，以及在开发过程中多种变化情况所出现的人工难以解决的问题，并确保这 些变化是已授权的行为所产生的。部分CM 自动化要求：

——TCB 的开发者所使用的CM 系统应通过所提供的自动方式来确保TCB 的实现表示只能 进行已授权的变化，并能提供自动方式来支持TCB 的生成；

——开发者所提供的 CM 计划应描述CM 系统中所使用的自动工具，并说明如何使用这些工 具。

b） 完全 CM 自动化：除了与上述部分CM 自动化有相同的内容外，还能自动确定TCB 版本间的变化，并标识出哪个配置项会因其余配置项的修改而受到影响。

5.2.1.2 配置管理能力

应确保 TCB 在提交用户运行之前是正确和完备的，所有配置项不会缺少，并能防止对TCB 配置项进行未授权的增加、删除或修改。 配置管理能力的设计应满足以下要求：

a） 版本号：要求开发者所使用的版本号与所应表示的 TCB 样本应完全对应，没有歧义。 b） 配置项：要求配置项应有唯一的标识，从而对 TCB 的组成有更清楚的描述。这些描述与部

分CM 自动化的要求相同。

c） 授权控制：要求开发者用对TCB 的唯一引用作为其标签，从而使TCB 的使用者明确自己使

用的是哪一个样本；控制机制使TCB 不会受到未经授权的修改，从而确保TCB 的完整性。 为此，授权控制要求：

——CM 计划应描述系统是如何使用的，并说明运行中的CM 系统与CM 计划的一致性； ——CM 文档应足以说明在CM 系统下有效地维护了所有的配置项； ——CM 系统应确保对配置项只进行授权修改。

d） 生成支持和验收过程：要求在上述版本号、配置项、授权控制的基础上确认对配置项的任何

生成和修改都是由授权者进行的。为此，CM 系统应支持TCB 的生成，验收计划应描述用来 验收修改过的或新建的配置项的过程，并作为TCB 的一部分。

e） 进一步的支持：要求集成过程有助于确保由一组被管理的配置项生成TCB 的过程是以授权的

方式正确进行的，并要求CM 系统有能力标识用于生成TCB 的主拷贝的材料，这有助于通过 适当的技术，以及物理的和过程的安全措施来保持这些材料的完整性。为此，CM 的进一步支 持要求：

——CM 文档除应包括配置清单、CM 计划外，还应包括一个验收计划和集成过程，集成过程应

描述在TCB 制作过程中如何使用CM 系统；

——CM 系统应要求将一个配置项接收到CM 中的不是该配置项的开发者； ——CM 系统应明确标识组成TSF 的配置项；

——CM 系统应支持所有对TCB 修改的审计，至少应包括操纵者、日期、时间等信息； ——CM 系统应有能力标明用于生成TCB 主拷贝的所有材料；

——CM 文档应阐明CM 系统与开发安全方法相联系的使用，并只允许对TCB 作授权的修改； ——CM 文档应阐明集成过程的使用能够确保TCB 的生成是以授权的方式正确进行的

本文来源：https://www.bwwdw.com/article/cry2.html