标准规范下载简介
GBT18336.3-2015 信息技术 安全技术 信息技术安全评估准则 第3部分：安全保障组件.pdfACO"组合”类包括五个族。本族列出的保障要求，是为了提供确信一个组合TOE依靠过去 软件、固件或硬件等组成部分所提供的安全功能是能够安全运行的信心。 “组合”是针对成功通过ISO/IEC15408安全保障要求包（基本部件和依赖部件，参见附录B)的 两个或更多的IT实体结合起来的一个整体，不包括对其中的IT实体进行的下一步的开发。额
IT实体（以前未经组件评估的实体)的开发也不包括。组合T()E形成了一种新的产品，它能波安装并 集成进任何特定环境中以满足环境目的。 “组合”没有为组件的评估提供可选的方法。AC(）类的“组合”为组合TO)E整合者提供了一种方 法，作为可选的方法被用于IS()/IEC15408中指定的其他保障级，在由两个或更多的成功评估过的组 件合成的TOE评估过程中获得信心，而不需要重新评估合成的TSF。（在整个ACO类中用组合TOE 整合者指代“开发者”，任何与基本或依赖部件相关的开发者都这样阐述。） 第8章和6.3定义的组合保障包是衡量组合T)E的一种保障等级。这种保障等级是除了EAL之 外的要求，因为对于依据EAL评估过的组件，得到一个EAL保障的结果，组合T(E必须满足EAL中 所有的安全保障要求项。尽管重复使用能构成组合T()E的评估结果，但是经常会有组件的其他方面 必须放到组合TOE中考虑，如B.3中描述的那些。由于一个组合TE的评估活动涉及不同的部分， 解决评估组件的组合以及获得一个有意义结果相关的问题。这些在附录B中有进一步的探讨 相应服务的部件称为基本部件。这种相互 乍用和区别在附录B中有进 是正在以某种形式（作为开发者、发起者
安师大风雨操场施工组织设计图16ACO各族之间的关系和部件间的关系
附录B中提供了组合TOE内部定义和相互作用的进一步阐述。 图18给出了本类中的族及族中各组件之间的层次关系，
图17ACO各族之间的关系
16.1组合基本原理（ACO COR)
[16. 1.1 目的
6.1.3ACO.COR.1组合基本原理
16.1.3.1开发者行为元素
6.1.3.3评估者行为元
16.1.3 3.1ACO COR.1.1E
16.2开发证据（ACODEV
本族陈述随着细节的逐级增加，对基本部件的规范说明的相关要求。这些信息是确认 安全功能支持依赖部件的要求所必需的（依赖信息中表示的）
本族组件是基于提供的接口以及实现细节的数量逐渐增加而分级的
基本部件的TSF经常在缺少潜在组合应用的依赖知识的情况下定义。基本部件的TSF被定义成 包括执行基本部件安全功能要求依赖的所有部分，这也将包括实现基本部件安全功能要求必需的所有 部分。 基本部件的功能规范将根据基本部件提供的允许外部实体调用TSF操作的接口来描述TSFI。这 包括允许通过与TSF操作交互来调用安全功能要求的用户接口，也包括允许外部IT实体调用TSF的
ACODEV.1功能描述
衣赖关系：ACOREL.1基本的依赖信息
16.2.4. 1且的
依赖部件所依赖的基本部件接口的描捕述是必需的。这将被检查，以确定其是否与依赖部件依束 信息描述一致。
16.2.4.2开发者行为元素
6.2.4.2.1 ACO DEV.1
[16.2.5.1月的
16.2.5.3内容和形式元素
6.2.5.3内容和形式元
16.2.5.4评估者行为元素
16.2.5.4.1ACO DEV.2.1E
依赖部件所依赖的基本部件接口的描述是必需的。这将被检查，以确定其是否与依赖部件依 口信息描述一致， 提供基本部件的结构的接口描述，以使评估者能确定是否是该接口构成了基本部件的TSF
16.2.6.2开发者行为元素
开发者应提供基本部件的开发信息。
16.2.6.3内容和形式元素
2.6.3内容和形式元素
[6.2.6.4评估者行为元素
16.2.6.4.1ACODEV.3.1F
■依赖部件的依赖性（A
本族的目的是提供描述依赖部件依赖基本部件的依赖性证据。这些信息对于负责组合该部件和其 也已评估过的IT部件形成组合TOE，并负责解释组合之后的安全属性的人员是有用的。 提供组合TOE的依赖部件和基本部件之间的接口描述，这些接口或许在它们各自部件评估期间 没有得到分析，因为这些接口不是它们各自部件TOE的TSFI
本族组件是根据依赖部件依赖基本部件的依赖性的描述的细节数量分级的
16.3.5.3评估者行为元素
16.3.5.3.1ACO REL.2.1E
本族要求执行组合TOE测试以及组
本族组件是基于进行接口测试时不断增加的严 格性，以及分析证实组合TOE的运行是与依赖 组合TE安全功能要求符合性测试的充分性不断增加的严格性而分级的
16.4.4ACOCTT.1接口测试
开发者成提供组合TOE测试文档
[16.4.5. 1目的
16.4.5.1且的
本族的组件是基于审查的公共脆弱性信息和进行独立脆弱性分析不断增加的详细程度而分级的
16.5.4ACOVUL.1组合脆弱性审查
16.5.4.1开发者行为元素
16.5.4.3.3ACO VUL.1.3F
16.5.4.3.4ACO VUL.1.4E
评估者应根据已标识的脆弱点，实施穿透性测试，证实组合TOE能抵抗具有基本攻击潜力的攻击 者进行的攻击
ACOVUL.2组合脆
16.5.5.1开发者行为元素
16.5.6.3评估者行为元素
16.5.6.3.1 ACO VUL.3.1E
附录A 资料性附录 开发（ADV)
本附录包含辅助材料.为ADV(开发类）的族中提出的话题做更进一步的解释和提供额外的例于
A.1ADVARC.安全架构的补充材料
安全架构是TSF所展示的属性集合；这些属性包括自保护、域分离和不可旁路。拥有这些属性 TSF提供安全服务的信心基础。本附录给出了这些属性的附加材料，以及在安全架构描述内容 论。 A.1.1～A.1.2首先解释了这些属性，然后讨论描述TSF如何展示那些特性所需要的信息
A.1.1安全架构属性
有保护是TSF用于保护自身的能力，以抵御外部实体可能导致1SF改变的操作。没有这些属性 TSF可能无法执行它的安全服务。 常常有这种情况，T()E使用其他IT实体提供的服务或资源来执行它的功能（例如依赖它下层操作 系统的应用）。在这些情况中，TSF不完全凭借自身保护自已，因为它依赖于其他IT实体保护其使用 的服务。 域分离是这样一种属性，TSF为每个操作其资源的不可信激活实体创建各自的安全域，并维持那 些域彼此分离，这样没有实体能在其他实体域中运行。例如，操作系统TE为每个与不可信实体相关 的过程提供一个域（地址空间、进程环境变量）。 对有些TOE来说这样的域是不存在的，因为所有不可信实体的行为都由TSF来代理。包过滤防 火墙就是此类T()E的一个例子，它没有不可信实体域；只有由TSF所维护的数据结构。那么，域的存 在性依赖于1)TOE类型以及2)TE的安全功能要求。T()E若提供针对不可信实体的域，本族要求 拥有不可信实体的域要与其他域隔离，以免受其他不可信实体域的干扰（不受TSF控制的影响）。 不可旁路性是TSF（用安全功能要求说明）安全功能经常调用的一个属性.并且对于特定机制它不 能被绕过。例如，通过安全功能要求对文件的访问控制被说明为TSF的一种能力，那么在调用TSF的 访问控制机制（通过原始磁盘访问可能是这样一个接口的例子）之前必须不能存在直接访问此文件的 接口。 拿自保护做例子，有些T()E可能很自然地依赖它们所处的环境，在TSF的不可旁路性中发挥作 用。例如，某安全应用TE要求它被底层操作系统调用。类似的，防火墙依赖于这样一个事实，即不
A.1.2安全架构描述
A.1.2.2TSF自保护
如果T()E展现的自保护整个是由其自身实现，应就如何实现有一个明确的描述。提供域分离的 机制是为了定义TSF保护域，以阻止其他（用户）域，此机制应被识别并描述， 对于T()E依赖其他IT实体来实现保护自身的情况，公用的角色必须要明确说明。例如，某TOE 是一个独立应用软件，它依赖底层操作系统去正确、良好地执行；该应用软件无法保护自身以对抗恶意 操作系统对其破坏（例如，覆写其执行代码或TSF数据） 安全架构描述也包括TSF如何处理用户输人，从而使TSF不会被用户输入所破坏。例I，TSF可 执行权限识别，并通过使用特权模式程序来处理用户数据从而自我保护。TSF有可能使用基于处理器 的隔离机制（例如，权限级别或环级别》将TSF代码和数据与来自于用户的代码和数据进行隔离。TSF 可以执行软件保护结构或编码习惯以有助于执行软件隔离，也可能通过将用户地址空间从系统地址空 间勾画出来去实现。 有些T)E以消减功能模式（例如，单用户模式仅易于安装者或管理员进人)启动，接着转变至经评 估之后的安全配置（不可信用户可以登录并使用TE服务和资源的模式），安全架构描述也应包括对 TSF如何保护该初始化代码不在评估后的配置模式下运行的描述。对于这样的TOE，安全架构捕述应 解释是什么防止了仅初始化过程中可使用的服务（例如，直接访间资源）被评估后的配置所访问。还应 解释当T()E正处于评估后的配置时，是什么防止了初始化代码被运行。 必须还要解释，可信初始化代码是如何维护TSF（以及它的初始化进程）完整性的.这样初始化进
A.1.2.3TSF不可旁路性
A2ADVFSP.TSFI补充材料
制定TSFI的目的是为引导测试提供必须的信息；在不知道与TSF交互的各种可能途径的情况 下，不可能充分测试TSF的行为。 要声明TSFI的两个方面：标识它们和描述它们。由于TE可能的多样性，以及不同的TSF，没有 组成"TSFI"的标准接口集合。本附录提供的指南是关于确定哪些接口是TSFI的要素。
A.2.1确定TSFI
一且定义了TSF，也就表明了TSFI。TSFI是由用户调用TSF（通过提供经TSF处理过的数据 所有途径以及对这些服务的响应所构成。这些服务规定和响应是穿越TSF边界的方法。当然 务会很明显，有些则不那么明显。当确定TSFI的时候要问的间题是“个企图破坏安全功能事 在攻击者是如何与TSF进行交互的？”下面的讨论将展现TSFI定义在不同情境下的应用寺庄水库施工组织设计，
A.2.1.1电气接口
在智能卡这样的TOE中，攻击者不仅仅能够逻辑访问TOE，而且能够完全物理访问TOE:,TSH 是物理边界。因此，所暴露的电口应被纳为TSFI,因为对它们的操作有可能影响到TSF的行 ，所有此类接口（电气触点）均需描述：可适用的多种电压，等等，
A.2.1.2网络协议栈
“封装程序” 的共用服务，例如，当操作系统创建应程序所 使用（见图A.1)的API。无论TSFI是系统调用还是依赖于应用程序使用的API：如果应用程.予可以直 接使用系统调用，那么系统调用就是TSFI接口。不过，如果禁止它们直接调用并且要求所有交互信息 都通过API.那么API就应是TSFI
图形化的用户接口也类似：它在机 间转换。类似的，如果用户1 令则它们就是TSFI或者用户被强制使用图形则图形（按钮，检查框，文本域）就是TSFI。 在这两种例子中，若用户被禁止使用更原始的接口（例如系统调用或命令），值得注意的是对这利 强制的描述应被包含进安全架构描述（见图 同样，封装程序也是TSF的一部分
A.2.1.4不可访问接口
对于特定T()E，不是所有接口都是可访问的。即操作环境（安全目标中的）的安全目的有可能禁止访 问这些接口，或者以几乎不可访问的方式限制访问。这样的接口不应被列为TSFI。以下是一些例子： 如果对于单独防火墙操作环境的安全目的的陈述为"防火墙的操作将会在一间服务器房间环 境中，该房间只允许可信且经过培训的个人能访问，它还装配有不间断电源供应（应对电力故 障）”，物理以及电力接口将是不可访问的，因为可信且培训过的个人将不会试图拆除防火墙 并/或中断电力供应。 如果对于软件防火墙（应用程序）操作环境的安全目的陈述为“操作系统和硬件将为应用程序 提供安全域以防止其他程序的篡改”，那么在操作系统中可被其他程序（例如，删除或修改防火 墙可执行文件，直接读或写防火墙的内存空间）访间防火墙的接口就应是不可访问接口，因为 操作系统/硬件部分操作环境使得此接[I不可访问 C 如果对于软件防火墙操作环境的安全目的描述为操作系统和硬件会如实地执行T()E命令 并且不会以任何方式篡改T()E，那么防火墙用以从操作系统和硬件（执行机器代码指令，操作 系统API，例如创建、读、写或删除文件，图形API等）获取原始功能的接口应是不可访问的， 因为操作系统/硬件是能够访问此接口的仅有的实体，并且它们全都可信。 对上述所有例子，这些不可访问接口就不是TSFI
XXX小学工程施工组织设计A.2.2范例复杂的DBMS