信息技术保障组件开发（ADV）、组合（ACO）、保障组件依赖关系的交叉引用.docx

《信息技术保障组件开发（ADV）、组合（ACO）、保障组件依赖关系的交叉引用.docx》由会员分享，可在线阅读，更多相关《信息技术保障组件开发（ADV）、组合（ACO）、保障组件依赖关系的交叉引用.docx（26页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、附录A（资料性）开发（ADV）A. 1 ADV.ARC：安全架构的补充材料A. 1. 1概述本附录包含辅助材料，为ADV：开发类的族中提出的话题做进一步解释和提供额外的例子。安全架构是TSF所展示的一组属性；这些属性包括自保护、域分离和不可旁路。拥有这些属性为TSP 正在提供安全服务提供了信心。本附录提供了关于这些属性的附加材料，以及对安全架构描述内容的讨 论。本节首先解释了这些属性，然后讨论了描述TSF如何展示这此属性所需的信息。A. 1.2安全架构属性“自叔,指的是TSF保护自己不受外部实体操纵的能力，这些操纵可能导致TSF的改变。如果 没有这些属性，TSF可能无法执行其安全服务。通常情况

2、下，TOE基F其他IT实体提供的服务或资源来执行其功能（例如，依赖其底层操作系统 的应用程序）。在这些情况下，TSF不能完全凭借自身保护自己，因为它依赖其他IT实体来保护其使 用的服务。彼分密是这样一种属性，TSF为每个操作其资源的不可信活跃实体创建各自的交金域以对其资源 进行操作，并使这些域彼此分离，以便任何实体都不能在其他域中运行。例如，操作系统TOE为与不 可信实体相关的每个进程提供一个单独的域（地址空间、进程环境变量）。对于某些TOE来说这样的域是不存在的，因为所有不可信实体的操作都是由TSF代理的。包过滤防 火墙就是这种TOE的一个例子，它没有不可信实体域；只有TSF维护的数据结构。

3、因此，域的存在取 决于1） TOE的类型和2） TOE的安全功能要求。若TOE确实为不可信实体提供单独的安全域，本族 要求这些域彼此隔离以防止一个域中的不可信实体篡改另一个不可信实体的域（不受TSF代理的影 响）。不可旁路性是TSF （用SFR指定）安全功能经常调用的一个属性，并且对于特定机制它不会被旁路。 例如，如果对文件的访问控制被指定为TSF的一种能力，那么在调用TSF的访问控制机制（通过原始磁 盘访问可能是这样一个接口的例子）之前必须不能存在直接访问此文件的接口。拿自保护做例子，有些TOE可能很自然地依赖它们所处的环境，在TSF的不可旁路性中发挥作用。例 如，某安全应用TOE要求它可由

4、底层操作系统调用。类似的，防火墙依赖于这样一个事实，即不存在内 部和外部网络的直接连接通路，所以它们之间的通讯必须通过防火墙。A. 1.3安全架构描述安全架构的描述解释了 TSF如何展示.上述属性。它描述了域是如何定义的，以及TSF如何将它们 分离。它描述了如何防止不可信进程接触到TSF并对其进行修改。它描述了怎么确保TSF控制下的所有 资源得到充分保护，以及确保TSF所要满足的SFR相关的所有行为。它解释了所有情况下环境扮演的角色 （例如，假设它被其底层环境正确地调用，它们的安全功能是如何被调用的？）。耦合是软件模块之间相互依赖的方式和程度；耦合类型包括调用耦合、公共耦合和内容耦合。卜.面

5、描述了这些模块耦合类型的特征，以其可取性递减的顺序列出。a）调用耦合：如果两个模块严格通过调用其文档说明的函数进行通信，则这两个模块就是调用耦 合；调用耦合的实例是数据、戳和控制，定义如下。1）数据：如果两个模块严格通过使用表示单个数据项的调用参数进行通信，则它们是数据耦 合的。2）戳：如果两个模块严格通过使用包含多个字段或具有有意义的内部结构的调用参数进行通 信，则它们是戳耦合的。3）控制：如果一个模块传递旨在影响另一个模块内部逻辑的信息，则它们是控制耦合的。b）公共耦合:如果两个模块共享公共数据区或公共系统资源，则它们是公共耦合的。全局变量标 明使用这些全局变量的模块是公共耦合的。通过全局

6、变量的公共耦合通常是被允许的，但只是 在有限的程度上。例如，只被一个模块使用的变量放在全局区域是不合适的，应删除。在评估 全局变显的适用性时需要考虑的其他因素是：1）修改全局变量的模块数量:一般情况下，应该只分配一个模块来负责控制全局变量的内容， 但可以由第二个模块共同承担该职责，在这种情况下，必须提供充分的论证。由两个以上 的模块分担此责任是不可接受的。（在进行此评估时，应注意确定实际负责变量内容的模 块；例如，如果使用单个例行程序来修改变量，但该例行程序只是执行其调用者请求的修 改，则是调用模块负责，并且可能有多个这样的模块）。此外，作为复杂度确定的一部分， 如果两个模块负责一个全局变量的

7、内容，则应该清楚地说明它们之间如何协调修改。2）引用全局变量的模块的数最：虽然通常对引用全局变量的模块数最没有限制，但应该检查 多个模块进行引用的情况的有效性和必要性。c）内容耦合:如果一个模块可以直接引用另一个模块的内部结构（例如，修改另一个模块的代码 或引用另一个模块的内部标签），则两个模块是内容耦合的。内容耦合的结果是一个模块的部 分或全部内容将有效地包含在另个模块中。内容耦合可以被认为是使用未公开的模块接口； 这与调用耦合相反，后者只使用公开的模块接口。A. 3.3程序软件的复杂度复杂性是对代码执行的决策点和逻辑路径的度量。软件工程学将复杂度作为软件的一个负面特征， 因为它阻碍了对代码

8、逻辑和流程的理解。另一个阻碍理解代码的因素是存在不必要的代码，即它是未使 用的或冗余的。使用分层来分离抽象级别并最小化循环依赖以便更好地理解TSF,从而更加保障TOE的SFR在实现 中被准确和完整地实例化。降低复杂度还包括减少或消除相互依赖性，这既适用于单个层中的模块，也适用于不同层中的模块。 相互依赖的模块可能互相依赖，以得到某单一的结果，这可能导致进入死锁状态，或者更糟糕的紊乱状 态（例如检查时间vs使用时间问题），其最终的结论可能是不确定的，并且受特定时刻的计算环境的影 响。设计复杂度最小化是参考验证机制的一个关键特征，其目的是得出一个容易理解的TSF,从而可以 对其进行完整地分析。（参

9、考验证机制还有其他重要特征，如TSF自保护和不可旁路性；这些其他特征 被ADV_ARC族的要求所覆盖）。A.4 ADV_TDS：子系统和模块A. 4.1概述本节提供了关于TDS族的附加指南，以及其对术语“子系统”和“模块”的使用的额外指导。随 后讨论了随着有更多细节的要求的出现，如何减少有较少细节的要求。A. 4. 2子系统如图A.3所示，根据TSF的复杂度，设计可以从子系统抽模块维度来描述（子系统比模块的抽象级 别更高）；或者也可仅从一个抽象级别进行描述（例如，较低保障级别中的子系统，较高保障级别中的 德决）。如果从低抽象级别（模块）进行描述，那么也默认满足了对高抽象级别（子系统）的要求。这

10、 个概念在下面关于子系统和模块的讨论中得到进一步的阐述。图A.3子系统和模块开发者应使用子系统来描述TOE的灵讨。术语“子系统”用起来比较模糊，它可以用来指代适用 于TOE的单元（例如，子系统、模块）。子系统甚至可以在范围上是不均匀的，只要满足子系统描述的 要求即可。子系统的第一个用途是区分TSF的边界；即，包含TSF的TOE部分。一般而言，如果某个子系统具有 影响任何TSF正确操作的能力（无论是通过设计还是实现），那么它就是TSF的一部分。例如，对于依 赖不同硬件执行模式来提供域隔离（见A.1）的软件，其中SFR-执行代码在一个域中执行，那么在该域 中执行的所有子系统都将被视为TSF的部分。

11、同样，如果该域外的台服务器实现了SFR （例如，对 其管理的对象实现访问控制策略），那么它也将被视为TSF的一部分。子系统的第二个用途是提供一种描述TSF的结构，在描述TSF如何工作时，不一定包含模块描 述中的低层实现细节（稍后讨论）。可对子系统进行高级别描述（缺乏丰富的实现细节）或细节层面描 述（提供对实现的更多洞察）。为子系统提供的描述级别取决于该子系统对某SFR的实现程度。S/7?-热分子系统是提供执行任何SFR元素的机制的子系统，或直接支撑实现某个SFR的子系统。如 果一个子系统提供（实现）一个SFR-执行TSF1,那么这个子系统就是SFR-执行的。子系统也可以被识别为S/W-支撑和无

12、关子系统。SFR-支撑子系统受SFR-执行子系统依赖以实 现SFR,但它不像SFR-执行子系统那样直接发挥作用。SFR-无关子系统是不依赖于支撑或执行作用而实 现SFR的子系统。A. 4.3模块模块通常是一个相对较小的架构单元，可以根据TSF内部结构（ADV_INT）中讨论的属性进行表征。 当PP或ST中同时存在ADV_TDS.3基础模块设计（或以上）要求和TSF内部（ADVJNT）要求时.， TOE设计（ADV_TDS）要求中的“模块”与TSF内部（ADVJNT）要求中的“模块”是同一实体。与子系 统不同，模块很详细地描述了实现，可以指导对实现表示的评估。需要注意的是，基于TOE产品形态，模

13、块和子系统可能为同一抽象层。对于ADV TDS. 1基础设计和 ADV_TDS. 2结构化设计（不需要在模块级别进行描述），子系统描述提供了关于TSF的最低级别细节。 对于ADV_TDS. 3基础模块化设计（需要模块描述），这些描述提供最低级别细节，而子系统描述的详 细程度应考虑（如果它们作为单独的实体存在）上下文中的模块描述。也就是说，如果存在模块描述， 则无需提供详细的子系统描述。在足够简单的TOE中，不需要单独的“子系统描述”；可以通过模块 提供的文档来满足要求。对于复杂的TOE,子系统描述（关于TSF的）的目的是为读者提供上下文，以 便他们可以适当地聚焦他们的分析。这种差异如图A3所示

14、。SFR-执行模块是实现ST中完全或部分实现一个SFR的模块。此类模块可能会实现SFR-执行TSFI,但 SFR中陈述的某些功能（例如，审计和客体重用功能）可能不会直接绑定到这一单个TSFI。与子系统的 情况一样，SFR-支撑模块是SFR-执行模块所依赖的模块，但不直接负责实现SFR。SFR-无关模块是不直接 或间接地处理SFR实现的那些模块。需要注意的是，对“直接实现的含义的确定有一定的主观性。从狭义上来讲，“直接实现”可以解 释为通过执行类似“比较”、“归零操作”等的一两行代码以实现某安全要求。从广义上来讲，它包括 响应SFR-执行类TSFI所调用的模块，以及该模块可能依次调用的其他模块（

15、依此类推，直到调用完成）。 这两种解释都不是特别令人满意，因为第一种解释的狭隘性可能导致重要的模块被错误地归类为SFR- 支撑模块，而第二种解释则可能导致实际上并非SFR-执行的模块被归类为SFR-执行。模块的描述应该可以根据模块描述创建其实现，且产生的实现将：1）在呈现的接口方面与实际的 TSF实现相同，2）接口的使用与设计中提及的相同，3）功能与TSF模块目的所描述的信息保持一致。例 如，RFC793提供TCP协议的高层次描述。它必须是独立实现的。虽然它提供大量细节，但它不是一个 合适的设计描述，因为它在实现方面不是具体的。在实际实现中，可以向RFC中规定的协议中添加内 容，且实现中的选择

16、（例如，在实现的各个部分中使用全局数据与本地数据）可能对执行的分析产生影 响。TCP模块的设计描述会列出实现相关的接口（而不仅是RFC793中定义的接口），以及处理与实现 TCP模块相关的算法描述（假设它是TSF的一部分）。在设计中，模块的详细描述包括：提供的功能（目的）、呈现的接口（当标准要求时）、接口的返 回值、调用的其他模块接II （以及其他模块调用的本模块的接I I）,以及描述它们如何使用适合于实现 模块的技术方法来提供其功能。模块的目的宜说明该模块提供什么功能。描述宜足以让读者大致了解模块在架构中的功能。模块提供的接口是其他模块用来调用所提供的功能的那些接口。接口包括显镰口（例如其他

17、模块 调用的调用序列）和嬷式接口（例如模块操作的全局数据）。接口通过其调用方式和返回值来进行描述。 接口描述应包括参数列表及对这些参数的描述。如果一个参数被要求从一组值中取值（例如，“flag”参 数），则要描述该参数会影响模块处理的取值的全集。同样，描述数据结构的参数，要标识和描述数据 结构的每个字段。对全局数据的描述信息要确保可理解其目的。全局数据结构所需的描述等级需要与模 块接口的描述水平相同，其中输入参数和返归I值对应于数据结构中的各个字段及其可能的值。全局数据 结构可与操作或读取它们的模块分开描述，只要模块的设计中包含关于全局数据结构更新的足够信息 或从全局数据结构中提取的信息即可。

18、请注意，不同的编程语言可有额外不明显的“接口”：例如C+中的重载运算符/函数，这种“隐式 接口”也将作为模块设计的一部分描述。请注意，尽管一个模块可仅呈现一个接口，但更常见的情况是 一个模块呈现一小组相关接口。当需要描述一个模块所使用的接I I时，必须在模块的设计描述或被调用模块的目的中明确此类接 口，以及期望从被调用模块中得到什么服务。例如，如果模块A被描述，并且它使用模块B的冒泡排 序程序，那么模块之间交互的描述必须说明为什么调用模块B的冒泡排序程序以及这个调用对SFR的 实现有什么贡献。模块B的冒泡排序程序接口和目的必须作为模块B接口的一部分进行描述（提供 ADV_TDS的级别和模块B的

19、分类需要一个对它的接口的描述），基于此，模块A只需要识别需要使用此 程序进行排序的数据。一个适当的描述是：“模块A调用模块B的接口而漏/。_加历左。按字母顺序 对用户名进行排序”。请注意，如果用户名的这种排序对于执行任何SFR并不重要（例如，它只是为了提升性能，并且 模块A的算法实现也可以避免对用户名进行排序），使用模块B的冒泡排序程序不是SFR-执行，在模 块A的描述中充分解释用户名按字母顺序排序是为了提升性能即可。模块B可仅被归类为“SFR-支 撑”，选择的ADV_TDS级别会明确是否需要描述SFR-支撑模块的接口，或仅描述模块B的目的即可。如前所述，模块的算法描述应该以算法的方式描述模块

20、的实现。这可以在伪代码中完成，通过流程 图，或（在ADVJDS.3基础模块设计）非正式文本。它讨论了如何使用模块的输入和调用的函数来完成模 块的功能。它记录了模块产生的全局数据、系统状态以及返回值的变化。基于这些细节层面的描述，可 以得出一个与TOE实际实现非常相似的实现。需要注意的是，源代码不符合模块文档要求。虽然模块设计描述了实现，但它分不走其ZT的实现。 如果源代码中的注释对源代码含义进行了解释，那么这些注释可能是足够的文档说明。仅仅说明每行代 码是做什么的行内注糅是无用的，因为它们没有解释该模块旨在完成什么。在下面的元素中，为子系统和模块讨论的标签（SFR-执行、SFR-支撑和SFR-

21、无关）用于描述开发者 需要提供的信息的数量和类型。这些元素已被结构化了，因此不要期望开发者仅提供特定的信息，也就 是说，如果开发者的TSF文档提供了以下要求中的信息，则开发者不会更新他们的文档并将子系统和 模块标记为SFR-执行、SFR-支撑、SFR-无关。这种标记的主要目的是允许使用不太成熟开发方法（以 及相关构件如详细的接口和设计文档）的开发者在不产生不必要成本的情况下提供必要的证据 飞A. 4. 4分级方法由于确定什么是SFR-执行与SFR-支撑（以及在某些情况下，甚至确定什么是SFR-无关）带有主观性， 在本族中采用下面的范例。在本族的早期组件中，开发者提供适当的信息以说明子系统分类为

22、SFR-执行 等，并且很少有额外的证据提供给评估者用于检查这种分类的正确性。随着所需保障级别的增加，在开 发者确定分类的同时，评估者也获得了越来越多的证据用于确认开发者的分类。为了将评估者的分析集中在TOE中与SFR相关的部分，尤其是在较低保障级别中，对族的组件进行 了分级，以便最初只需要对SFR-执行架构实体进行最详细的描述。随着保障级别增加，SFR-支撑和（最 终）SFR-无关的实体也需要提供更多的信息。应该注意的是，即使需要完整的信息，也不要求对所有这 些信息进行相同程度的详细分析。在所有情况下，重点应放在是否已提供和分析了必要的信息。表A.1总结了本族每个组件所需的用于描述结构实体的信

23、息。表A. 1分级详细描述TSF子系统TSF模块SFR-执行SFR -支撑SFR -无关SFR -执行SFR -支撑SFR -无关ADV_TDS. 1基础设 计（非形式化陈 述）结构、SFR-执行 行为概述、交 互指定支撑指定支撑ADV_TDS. 2结构化 设计（非形式化陈 述）结构、SFR-执行 行为详细描 述、。行为、其 他行为的概述、 交互结构、其他行 为的概述、交 互指定支撑、 交互ADV_TDS. 3基础模 块设计（非形式化 陈述）描述、交互描述、交互描述、交互目的、SFR接CIb交互、目的交互、目的ADV_TDS. 4半形式 化模块设计（半形 式化陈述）描述、交互描述、交互描述、交

24、互目的、SFR 接口目的、SFR 接口交互、目的ADV_TDS. 5完全半 形式化模块设计 （半形式化陈述）描述、交互描述、交互描述、交互目的、所有 接口，目的、所有 接口目的、所有 接口ADV_TDS. 6带形式 化高层设计表示的 完全半形式化模块 设计（半形式化陈 述、附加的形式化 陈述）描述、交互描述、交互描述、交互目的、所有 接口目的、所有 接口目的、所有 接口“指定支凝;味着只需要提供足以支持子系统/模块分类的文档。、SFR接意味着模块描述包含每个SFR-相关接口的返回值和调用的其他模块的接口。所有度Z7意味着模块描述包含每个接口的返回值和调用的其他模块的接口。A. 4.5安全相关性

25、GB/T 18336系列将描述、证据和分析集中在TOE的安全功能上。这需要对TOE的功能和物理部分 的安全相关性进行表征。接口、子系统和模块可（隐式或显式）分类为“SFR-执行、“SFR-支撑”或 “SFR-无关”。开发者的证据和评估分析均与TOE相关，并侧重于TSF及其SFR-执行和SFR-支撑的实现。安 全架构描述应证实已识别的TOE的非-TSF子系统无法旁路TSF,并且TSF自保护机制可免受非-TSF 代码或实体的破坏。开发者应在TOE设计中描述SFR-无关的接口、子系统和模块，并证实它们不会因 为其目的、交互或资源分离而干扰TSF。接口、子系统或模块可划分为 SFR-执行，如果它直接实

26、现某个SFR。 SFR-支撑，如果SER的正常功能实现依赖于它的功能的正确运行。 SFR-无关，如果它与SFR的实现无关。对安全执行和安全支撑功能的关注点是需要证明其他功能为SFR-无关的。即使是正确实现的安全 执行功能和安全机制也可能被旁路、规避、停用、破坏或直接攻击。无干扰意味着TSF不能被滥用，并 且阻止其（或不可能）对TSF实现的资源进行未授权访问。因此，如果对安全相关的接口、子系统和模 块进行了分类，并且此分类用于脆弱性分析中时，那么TOE的安全架构具备不可旁路和自保护机制是至 关重要的。TSF自保护是安全架构属性，由此TSF不会被非TSF代码或实体破坏。这包括TOE的非-TSF子系

27、统和IT 产品的非TOE部分。它类似于SFR-无关子系统/模块的证据。安全域是由TSF提供的，供不可信实体使用的环境，其实现方式是将这些环境相互隔离并相互保护。因此，评估期间对无关的分析需要检查TOE （ADV ARC）的安全架构，并且可能需要更多关于非TSF子 系统的信息，而不仅仅是停留在为ADV_TDS.x. 1所提供的TOE子系统层面的信息。开发者应提供逻辑依据 以说明TSF的定义是正确的，并从SFR-无关模块的目的和与其他模块的交互方面进行分析。目的：模块如何提供其功能，不需要进一步的设计决策。交互：子系统或模块进行通信的原因，并表征所传递的信息（无需描述到接口层面）。在评估期间，应将

28、无关类的分析作为功能规范和TOE设计检查以及脆弱性分析的一部分。将接口、 子系统和模块分类为SFR-执行、SFR-支撑、SFR-无关意味着需要对功能规范、设计和测试进行具体检查。 将TSFI解释为所有可访问TSF的外部接口将有助于此分析。所有TSF子系统（从ATE_DPT. 1开始）和所 有TSF模块（ATE_DPT. 3及更高级别）的功能测试宜为其分类的正确性提供证据。A.5形式化方法补充材料形式化方法提供了 TSF及其行为的数学表示，并且是ADVJPM. 1 （形式化TOE安全策略模型）、 ADV_FSP. 6 （附加形式化描述的完备的半形式化功能规范）和ADV_TDS. 6 （带形式化高

29、层设计表示的完 全半形式化模块设计）组件中所要求的。在GB/T 30270:20XX,附录C评估技术和工具中，提供了关于 形式化方法的补充材料。图A.4说明了 ADV_SPM. 1中规定的SPM与ST及功能规范中提供的TSF表示之间的关系。图A.4 ADV_SPM与其他族和结构的关系ASE类定义了 SFR与TOE安全目的之间的对应要求，以及SPD元素与TOE安全目的及TOE运行环 境安全目的之间的对应关系的要求.与TSF表示相关的每个保障族（即功能规范（ADV_FSP）、TOE设计（ADV TDS）和TSF实现表示 （ADVMP）定义了与某具体的TSF表示及其上层对应关系相关的开发者行为，以及

30、此TSF表示与SFR 的对应关系的评估要求。ADV_SPM族聚焦形式化安全模型，该模型是TSF及其与TOE行为的关系的形式化表示。具体而 言，形式化TSF模型是对被评估系统的形式化描述，此系统由ST中描述的所有SFR定义。为这个形 式化模型定义的TOE形式化属性集覆盖了全部的TOE安全目的。为此，ADV_SPM族定义了：建立TSF形式化模型相关的开发者行为要求（A【）V_SPM. 1.1D）和TOE形式化属性集 （ADV_SPM. 1. 2D）；关于内容和表述对应性的要求： 形式化的TSF模型和完备的SFR （ADV_SPM. 1. 30 : TOE形式化属性和TOE安全目的（ADV_SPM.

31、 1. 4C） .通过形式化地证明TSF形式化模型满足TOE形式化属性来提供安全保障。为此，ADV_SPM族定义了 此形式化证明的要求（ADV_SPM. 1.3D与ADV_SPM. 1. 5C）O通过形式化证明形式化模型的属性所获得的 信心与通过定义形式化模型与TSF功能规范（AI）V_SPM. 1. 4D）之间对应逻辑关系而获得的信心是相伴而 生的。当映射到TSF功能规范（ADV SPM. L6D）的形式化部分时，对应逻辑关系应包括形式化证明。当 使用半形式化方式（AIW_SPM. 1. 5D）描述功能规范时，那么此逻辑关系应包括半形式化论证。AI）V_SPM族 定义了关于通过TSF功能规范

32、(ADV_SPM. 1. 6c/7C/8C)保留TOE形式化属性的对应逻辑依据的内容要 求。ADV_SPM族包括有关基础数学理论(ADV_SPM. 1. 1C)、用于形式化建模和证明的工具(ADV_SPM. 1. 7D 和ADV_SPM. 1. 90以及对支持和记录每个元素的说明性文字的要求(ADV_SPM. L2C)。ADY_FSP要求开发者建立TSF功能规范和SFR之间的对应关系。尽管此要求与SPM无关，但当将 ADV_SPM. 1用于此对应关系中时，那么，SPM的要求就是SFR与TSF形式化模型对应关系以及模型与功 能规范对应关系的副产物。图A. 4展示了形式化TSF模型在功能规范和ST

33、 (SFR和TOE属性)之间的关系中的作用，然后通 过ADV_TDS和ADV_IMP要求族在设计和实现表示中传递。附录B（资料性）组合（ACO）8. 1概述本附录的目的是解释组合评估和ACO标准的一些概念。本附录没有定义ASE标准；可以在第9章 中找到有关定义。8.2 组合TOE评估的必要性整个IT市场是由许许多多特定种类的产品/技术提供商组成的。尽管有些交叉，PC硬件供应商也可 能提供应用软件和/或操作系统，或者芯片制造商也可能为自己的芯片组开发专用的操作系统，但通常 的情况是，一个IT解决方案是由各种不同类型的供应商实施的。有时除了提供对单个部件的保障之外，还需要对组合部件进行保障。虽然这

34、些供应商之间有合作， 但在部件的技术整合所需的特定材料的分发，协议则很少涉及提供的设计信息和开发过程/程序证据的 详细程度。从被另一个部件依赖的部件开发者得到的信息不足，意味着依赖部件的开发者不能访问对依 赖部件和基础部件执行EAL2或更高级别的评估所需的信息。因此，虽然仍能执行依赖部件的任何保障 级别的评估，但对组合部件执行EAL2保障级或更高级的评估，需要重用对部件开发者执行各种评估的 评估证据和评估结果。ACO标准的目的是用于一个IT实体依赖另一个实体提供安全服务的情况。提供服务的实体称为 “基础部件”，接收服务的实体称为“依赖部件”。这种关系在很多种情况下存在。例如，一个应用程 序（依

35、赖部件）可能使用个操作系统（基础部件）提供的服务。可选的，两个关联的应用程序的情形, 要么在通用操作系统环境下，要么运行在单独的硬件平台上，这种关系可能是对等的。如果存在一个占 支配地位的实体向辅助实体提供服务，那么这个占支配地位的实体被认为是基本部件而辅助实体认为是 依赖部件。如果对等体以相互的方式为彼此提供服务，那么，每个实体被认为既是提供服务的基本部件， 也是得到服务的依赖部件。这将要求对每种部件实体重复运用SCO组件的所有要求。另一个目标是更加 广泛的适用性，逐步地（组合TOE由一个依赖部件和一个基本部件组成，而这个基本部件又是另一个组 合TOE的依赖部件）适用于更加复杂的关系，但这或

36、许需要进一步的阐述。组合TOE评估仍然要求各个组件进行了独立的评估，因为组合评估建立在各个组件独立评估的结 果之上。或许当组合TOE开始评估时，依赖部件的评估仍在进行中。但是，依赖部件的评估必须在组合 TOE评估完成之前完成。组合评估活动可以与依赖部件评估同时进行。这是由于两个因素：a）经济/业务驱动-依赖部件开发者要么是组合评估活动的发起者，要么支持这些活动，因为从依 赖部件评估得到的可交付的评估证据或结果是组合评估活动必需的。b）技术驱动-随着逐步理解依赖部件最近经历（正在经历）部件评估，并且所有评估有关的可交 付的评估证据或结果都是可用的，组件要考虑所必需的保障级是否由基本部件提供（例如

37、，考 虑基本部件评估完成以来的变化）。因此，没有要求组合期间重新验证依赖部件的评估活动。 同时，基本部件组成的（其中一个）用作依赖部件评估期间的依赖部件测试的测试配置项，由 ACO_CTT去考虑这个配置项中的基本部件。要求依赖部件评估得到的评估证据作为组合TOE评估活动的输入。要求基本部件评估得到的唯一的 评估资料作为TOE评估活动的输入，该资料是：基础部件评估期间报告的基本部件的残余脆弱点。这是ACO_VUL活动的要求。组合TOE评估不需要来自基础部件活动的其他评估证据，因为基础部件的组件评估的评估结果会 被重用。如果组合TOE TSF包含的要比基本部件的部件评估期间TSF要多，那么可能要求

38、基本部件的其 他信息。基本部件和依赖部件的部件评估假定在为ACO组件确定最终结论的时候已经完成了。ACO.VUL组件仅考虑抵御具有增强型基本攻击潜力的攻击者。这将根据提供的关于基本部件是如 何提供依赖部件依赖的服务的设计信息的级别，运用ACO_DEV活动。因此，尽管构成组合TOE的部件的保 降级可能高于EAL4级，但采用CAP对组合TOE进行评估所能获得的信心与对部件TOE进行EAL4评估所能获 得的信心相当。8.3 执行组合TOE的安全目标评估开发者将会提供一份ST文档，用于组合TOE （基础部件+依赖部件）的评估。ST会标识用于组合TOE 的保障包，该保障包利用部件评估获得的保障为复合实体

39、提供保障。在ST中考虑部件组合的目的是从环境和需求的角度验证部件间的兼容性，并评估组合TOE ST与 组件ST及其中描述的安全策略一致。这包括确定部件ST和其描述的安全策略是兼容的。组合TOE ST可能涉及部件ST的内容，或者ST作者在组合TOE ST内重述组件ST的材料，并提 供如何在组合TOE ST中描述部件ST的基本原理。在为组合TOE ST进行ASE_CCL评估活动期间，评估者要确定在组合TOE ST中部件ST的描述是准 确的。这将通过确定组合TOE ST与部件TOE ST的一致性得到了论证获得。同时，评估者也需要确定依赖 部件运行环境中的依赖条件在组合TOE中得到了充分满足。组合TO

40、E描述将描述组合方案。描述组合方案逻辑上和物理上的范围和边界，还会识别部件间的逻 辑边界。该描述会标识每个部件提供的安全功能。组合TOE安全功能要求的陈述会标识满足每个安全功能要求的部件。如果某个安全功能要求是由两 个部件满足的，那么陈述会标识各个部件满足安全功能要求的不同方面。同样的，组合TOE概要规范会 标识各个部件提供的上述安全功能。应用于组合TOE ST的安全目标评估要求（AST包）应于部件评估中使用的安全目标评估要求（ASE包） 一致。部件ST评估的评估结果重用的一个例子是组合TOE ST直接引用部件ST。例如，如果组合TOE ST引用 部件ST,作用其安全功能要求陈述的一部分，评估

41、者能理解完全所有赋值和选择的操作（ASE_REQ中陈 述的）在部件评估中已经满足了。8.4 组合IT实体间的相互作用基本部件的TSF经常在缺少对潜在应用的依赖性的知识的情况下被定义，有了这些知识基本部件才 能被组合。基本部件的TSF被定义成包括执行基本部件安全功能要求依赖的所有部分，这也将包括实现 基本部件安全功能要求必需的所有部分。基本部件的TSFI表示TSF为安全功能要求陈述中定义的外部实体提供调用TSF服务的接口。包括用 尸接口和外部IT实体的接口。但是，TSFI仅包括TSF的接口，因此，不需要外部实体和基本部件之间所 有可用接口的详尽说明。基本部件可能提供被认为是与安全无关的服务接口，

42、或者因为这种服务的固有 用途（如，调整字体），再或者因为与GB/T18336相关的安全功能要求在基本部件的ST中没有声明（如， 在第二部分的FIA：标识和鉴别安全功能要求中没有声明登录接口时）。基础部件提供的功能接口是除安全接口（TSFI）之外的接口，在基础部件评估期间不需要考虑。通 常包括依赖部件调用基本组件提供的服务用到的接口。基础部件可包括一些间接调用TSFI的接口，例如, 可以用来调用TSF服务的API,在评估基础部件时没有考虑。IT实体TSF接口基础部件功能通讯人类用户TSF接口TSFTOE的非TSF部分TOE （基础部件）边界图B.1基础部件概要依赖于基础部件的依赖部件类似于以下定

43、义：部件ST的SFR中定义的外部实体的接口被划分为 TSFI,并在ADV_FSP中进行检查。在图B. 1中进行了说明）。任何从依赖TSF要求环境对某一安全功能要求提供支持，应表明为了确保所陈述的依赖部件安全 功能要求的执行，依赖TSF服务从环境获得某种服务。这种服务在依赖部件边界之外，基本部件也不可 能在依赖部件ST中作为外部实体被定义。因此，依赖TSF调用底层平台（基本部件）的服务，不会作为 功能规范（ADV_FSP）评估活动的一部分被分析。这种对基本部件的依赖将作为环境安全目的在依赖部 件ST中描述。依赖部件和接口的抽象如下图B.2所示。图B. 2依赖部件抽象在考虑基础部件和依赖部件的组合

44、时，如果依赖部件的TSF需要来自基本部件获得服务来支持 SFR的实现，则需要定义服务的接口。如果该服务由基础部件TSF提供，则该接口应该是基础部件的 TSFI,因此会在基本部件的功能规范中定义。但是，如果依赖部件TSF调用的服务不是由基本部件的 TSF提供的（即它是在基本部件的非TSF部分中实现的，或者甚至是基本部件的非TOE部分（未在图安全架构描述以分解描述的方式呈现了 TSF的自保护、域分离和不可旁路属性。此描述的级别与 ADV_FSP、ADV_TDS和ADV_IMP要求的TSF描述相当。例如，如果仅在ADV_FSP中描述了TSF,那么, 因无法从中获取到TSF内部工作的细节，也就很难提供

45、任何有意义的安全架构描述。然而，如果可获得TOE设计，即使是最基础的级别（ADV_TDS. 1）,也会有一些构成TSF子系统的相 关信息，并且会描述它们如何工作以实现自保护、域分离和不可旁路。例如，也许所有用户与TOE的 交互都是通过一个代表该用户的进程来约束的，该进程采用了用户的所有安全属性；安全架构设计应描 述这样的进程是如何产生的，进程的行为是如何被TSF约束的（所以它不会破坏TSF）,进程的所有 行为是如何被TSF调控的（从而解释为什么TSF不可被旁路），等等。如果可获得的TOE设计更详细（例如在模块级），或实现表示也可获得，那么相应的安全架构设 计的描述应更详细，解释用户如何与TSF

46、进行交互的过程，TSF如何处理不同的请求，传递了哪些参数, 采用了哪些程序保护措施（防止缓冲区溢出、参数边界检查、核查时间/使用核查的时间等）。类似地， 若在TOE的ST中声明了ADV_IMP组件，则应加入实现表示相关的细节。安全架构描述中提供的解释应足够详细，以便测试其准确性。也就是说，简单的声明（例如TSF实 现域分离”）没有提供有用的信息让读者确信TSF的确创建并分离了域。A. 1.3. 1域分离如果TOE展现出的域分离完全由其本身实现，应就如何实现有一个明确描述。安全架构描述应解释 由TSF定义的不同种类的域，它们是如何被定义的（即哪些资源被分配到每个域），所有资源是如何 被保护的，以

47、及如何保持域的分离，以便一个域的活动实体不可以篡改另一个域的资源。对于TOE依赖其他IT实体实现域分离的情况，公用的角色必须明确说明。例如，某款应用软件 TOE依赖于底层操作系统来正确实例化TOE定义的域.：如果TOE为每个域定义了单独的进程空间、 内存空间等，那么它依赖于底层操作系统去正确和良好地执行（例如，仅允许在TOE软件申请的执行 空间中执行进程）。例如，实现域分离的机制（如内存管理、硬件提供的受保护的处理模式等）将被识别和描述。要 么,TSF可以执行软件保护结构或编码习惯以有助于执行软件域分离,也可能通过将用户地址空间从系统 地址空间勾画出来去实现域分离。脆弱性分析和测试（参见AVA

48、_VAN）活动可能包括尝试通过使用监控或直接攻击TSF的方式来破 坏所描述的TSF域分离。A. 1.3. 2 TSF 自保护如果TOE的自保护完全由其自身实现，那么应就如何实现自保护有一个明确的描述。应识别并描述 域分离机制，此机制应识别并描述如何从其他（用户）域中分离一个受TSF保护的域。对于TOE依赖其 他IT实体来实现自保护的情况，公用的角色必须要明确说明。例如，某应用软件TOE,依赖于底层操 作系统才能正确、良性地运行；应用程序无法保护自身以免受恶意操作系统的破坏（例如，覆写其可执 行代码或TSF数据）。安全架构描述还包括TSF如何处理用户输入，以使TSF不会受到用户输入的破坏。例如，TSF可 执行权限识别，并通过使用特权模式程序处理用户数据以实现自保护。TSF可以利用基于处理器的分离 机制（例如特权级别或环）将TSF代码和数据与用户代码和数据进行隔离。TSF可以执行软件保护结构 或编码习惯有助手执行软件隔离，也可以通过划分用户地址空间和系统地址空间来实现。有些TOE以消减功能模式（例如，单用户模式仅易于安装者或者管理