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

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

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

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

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

5、性。此描述的级别与ADV_FSP、ADV_TDS 和 ADV_IMP 要求的 TSF 描述相当。例如，如果仅在ADV_FSP中描述了TSF，那么，因无法从中获取到TSF内部工作的细节，也就很难提供任何有意义的安全架构描述。然而，如果可获得TOE设计，即使是最基础的级别 (ADV_TDS.1)，也会有一些构成 TSF 子系统的相关信息，并且会描述它们如何工作以实现自保护、域分离和不可旁路。例如，也许所有用户与 TOE 的交互都是通过一个代表该用户的进程来约束的，该进程采用了用户的所有安全属性；安全架构设计应描述这样的进程是如何产生的，进程的行为是如何被 TSF 约束的（所以它不会破坏 TSF），

6、进程的所有行为是如何被 TSF 调控的（从而解释为什么 TSF 不可被旁路），等等。如果可获得的 TOE 设计更详细（例如在模块级），或实现表示也可获得，那么相应的安全架构设计的描述应更详细，解释用户如何与TSF进行交互的过程，TSF如何处理不同的请求，传递了哪些参数，采用了哪些程序保护措施（防止缓冲区溢出、参数边界检查、核查时间/使用核查的时间等）。类似地，若在TOE的ST中声明了ADV_IMP 组件，则应加入实现表示相关的细节。安全架构描述中提供的解释应足够详细，以便测试其准确性。也就是说，简单的声明（例如TSF实现域分离”）没有提供有用的信息让读者确信TSF 的确创建并分离了域。域分离如

7、果TOE展现出的域分离完全由其本身实现，应就如何实现有一个明确描述。安全架构描述应解释由 TSF 定义的不同种类的域，它们是如何被定义的（即哪些资源被分配到每个域），所有资源是如何被保护的，以及如何保持域的分离，以便一个域的活动实体不可以篡改另一个域的资源。对于 TOE 依赖其他 IT 实体实现域分离的情况，公用的角色必须明确说明。例如，某款应用软件 TOE 依赖于底层操作系统来正确实例化 TOE 定义的域；如果 TOE 为每个域定义了单独的进程空间、内存空间等，那么它依赖于底层操作系统去正确和良好地执行（例如，仅允许在 TOE 软件申请的执行空间中执行进程）。例如，实现域分离的机制（如内存管

8、理、硬件提供的受保护的处理模式等）将被识别和描述。要么,TSF可以执行软件保护结构或编码习惯以有助于执行软件域分离,也可能通过将用户地址空间从系统地址空间勾画出来去实现域分离。脆弱性分析和测试（参见 AVA_VAN）活动可能包括尝试通过使用监控或直接攻击 TSF 的方式来破坏所描述的 TSF 域分离。TSF 自保护如果TOE的自保护完全由其自身实现，那么应就如何实现自保护有一个明确的描述。应识别并描述域分离机制，此机制应识别并描述如何从其他（用户）域中分离一个受TSF保护的域。对于 TOE 依赖其他 IT 实体来实现自保护的情况，公用的角色必须要明确说明。例如，某应用软件TOE，依赖于底层操作

9、系统才能正确、良性地运行；应用程序无法保护自身以免受恶意操作系统的破坏（例如，覆写其可执行代码或 TSF 数据）。安全架构描述还包括 TSF 如何处理用户输入，以使 TSF 不会受到用户输入的破坏。例如，TSF 可执行权限识别，并通过使用特权模式程序处理用户数据以实现自保护。TSF 可以利用基于处理器的分离机制（例如特权级别或环）将 TSF 代码和数据与用户代码和数据进行隔离。TSF可以执行软件保护结构或编码习惯有助于执行软件隔离，也可以通过划分用户地址空间和系统地址空间来实现。有些TOE以消减功能模式（例如，单用户模式仅易于安装者或者管理员进入），接着转变至经评估之后的安全配置（不可信用户能

10、够登录和使用TOE的服务和资源的模式），安全架构描述也应包括对TSF如何保护该初始化代码不在评估后的配置模式下运行的描述。对于这样的 TOE，安全架构描述应解释是什么防止了仅初始化过程中可使用的服务（例如，直接访问资源）被评估后的配置所访问。还应解释当TOE正处于评估后的配置时，是什么防止了初始化代码被运行。还必须解释可信初始化代码是如何维护 TSF（及其初始化过程）完整性的，以便初始化过程能够检测到任何会导致 TSF 被欺骗以相信它处于初始安全状态的所有的修改。脆弱性分析和测试（参见 AVA_VAN）活动可能包括通过使用篡改、直接攻击或监控 TSF 的方式来破坏所描述的 TSF 自保护机制。

11、TSF 不可旁路不可旁路性与那些允许旁路执行机制的接口有关。在大多数情况下与实现是有因果关系的，如果某程序员正在编写一个接口去访问或操作某对象时，针对这个对象的某些接口是安全功能要求机制的一部分,该程序员有责任使用这些接口，而不是试图绕过这些接口。由于描述的是不可旁路性，那么有两个方面是必须要覆盖到的。首先是 SFR-执行的接口。这些接口的属性是它们当中不能包含用于旁路 TSF 的操作或模式。 ADV_FSP 和 ADV_TDS 的证据可能在很大程度上可以用来做这个决定。因为不可旁路性关注的是，如果仅有可用在这些TSFI上的特定操作在文档（因为他们是SFR-执行）中作了声明，其他操作均不可用，

12、开发者应考虑是否额外的信息（在ADV_FSP和ADV_TDS中提出的信息）也有必要做出声明，即SFR-支撑以及SFR-无关的TSFI的操作不会提供给一个不可信实体去旁路正在执行的策略。如果此类信息是必要的，也应被包括在安全架构描述中。不可旁路性的第二个方面涉及那些与SFR-执行无关的接口。依赖于ADV_FSP 和 ADV_TDS 组件的声明，这些接口中的有些信息可能在功能规范和TOE设计文档中,也可能不在其中。这样的接口（或接口组）的描述信息应充分，使得读者能够确定执行机制不可被旁路（描述的详细程度与ADV：开发类中提供的其他证据相当）。安全功能不能被旁路的属性均应被应用于所有的安全功能。即设

13、计描述应覆盖安全功能要求保护下的目标（例如FDP_*组件）和TSF所提供的功能（例如,审计）。这些描述也应标识出那些与安全功能相关联的接口；也可以利用功能规范中使用的信息。该描述还应包括所有设计构件，例如目标管理器，以及它们的使用方法。例如,如果程序是被用作一个标准的宏来处理一个审计记录,该规定则是设计的一部分，促成了审计机制的不可旁路性。很重要的一个问题是，本文中不可旁路性不是尝试回答此问题“如果是恶意的话，TSF执行的某部分是否可旁路安全功能”，而是在文档中描述如何去执行不可旁路安全功能。脆弱性分析和测试（参见 AVA_VAN）活动可能包括试图通过旁路 TSF来破坏所描述的不可旁路性。AD

14、V_FSP：功能规范的补充材料概述定义TSFI的目的是为进行测试提供必要的信息；如果不知道与 TSF 交互的可能方式，就无法充分测试 TSF 的行为。要声明TSFI的两个方面：标识它们和描述它们。由于TOE可能的多样性，以及不同的TSF，没有组成“TSFI”标准的接口集合。本附录提供的指南是关于确定哪些接口是TSFI的要索。TSF接口的具体说明包括两个部分：接口标识和接口描述。由于 TOE 的多样性以及其中不同的 TSF，因此没有一套标准的接口构成“TSFI”。本附录提供关于确定TSF接口要素的指南。TOE 的非 TSF 部分TSF 包括用户为了信任安全功能而必须依赖的 TOE的所有部分。换句

15、话说，那些不属于 TSF 的 TOE 部分可以被攻击者修改，但不会对 TOE 的安全功能产生任何影响。如果不是这种情况，则必须将 TOE 的这些部分包含在 TSF 中。如果定义了 TSF 和 TSF 实现，那么就可以清楚判断TOE是否存在非 TSF 部分。尽管这些部分不是 TSF 的一部分，但它们仍是 TOE 的一部分。TOE 的 TSF 和非 TSF 部分之间的关系由它们的定义和 ARC 属性给出，如下所示：非 TSF 部分不可旁路 TSF TSF部分实现自保护以免受篡改。不属于 TSF 一部分的 TOE 子系统必须满足以下条件（作为经验法则描述）：即使该子系统被攻击者恶意替换，它也不会对

16、TOE 产生任何安全影响。因此，在非 TSF 部分和 TSF 部分之间，有某种“分离机制”似乎是可取的，因为这种“分离机制”可以为评估非 TSF 部分对 TSF 部分没有影响奠定基础。这种“分离机制”可以由安全架构实现，也可以由实现的显式实现部分实现（例如，TOE 的 TSF 和非 TSF 部分之间的防火墙）。“分离机制”的分析是脆弱性评估的对象，因为它必须根据评估的 VAN 级别承受相应强度的攻击者攻击。开发者应在其安全架构描述中提供不可旁路和自保护的证据，评估者应在 ADV_ARC.1 子活动中分析此证据，并评估脆弱性评定的有效性。TOE 设计文档的目标是提供足够的信息来确定 TSF 边界

17、，并描述 TSF 如何实现安全功能要求。需要进一步注意的是，ADV_TDS 族只需要标识 TOE 的非 TSF 子系统。ADV_FSP 或 ADV_TDS 中没有为这些子系统提供接口描述。这些子系统的SFR-无关是开发者假设的，但开发者没有相关证明，评估者也没有详细检查。然而，从 TOE 设计的角度来看，只要上述分离机制到位并且脆弱性评估确认其足够强大，这一问题并不那么重要。因此，这种“分离机制”实现了 TSF 或执行了ARC 属性作为其安全特性。但是不可旁路性也可通过“纯架构属性”来执行。归类为非 TSF 的 TOE 部分不得提供旁路 TSF 的方法（无论是使用TOE这部分的合法用户还是攻击

18、者）并且确保其不会构成TSF 。开发者提供明确的证据并证实如何满足此要求非常重要。因此，开发者应证实且评估者应检查标识为非TSF的TOE子系统（参见 ADV_TDS.x.1）是正确的，因此不需要对这些子系统进行详细描述。评估者应检查开发者提供的 ADV_ARC 文档中描述的不可旁路和自保护属性（请参阅上面的段落）。确定TSFI概述为了标识TSF 的接口，必须首先识别组成 TSF 的 TOE 部分。这种识别实际上是 TOE 设计 (ADV_TDS) 分析的一部分，但针对 TOE 设计 (ADV_TDS) 未被包含在保障包的情况，开发者也会隐式执行（通过TSFI的识别和描述）。在此分析中，如果 T

19、OE 的一部分有助于满足 ST 中的SFR（全部或部分），则必须将其视为TSF 的一部分。例如，这包括 TOE 中用于TSF 运行初始化的所有细节，比如SFR的执行没有开始（例如启动时）优先于TSF运行的软件应能够实现自保护。对于TSF 自保护、域分离和不可旁路的架构原则提供支持的TOE所有部分也包含在TSF中（请参阅安全架构(ADV_ARC)）。一旦定义了TSF，也就表明了TSFI。TSF接口由外部实体（或属于TOE但在 TSF 之外的主体）向 TSF 提供数据、从 TSF 接收数据和从 TSF 调用服务的所有方式组成。这些服务调用和响应是穿越TSF 边界的方法。虽然其中许多是显而易见的，但

20、其他的可能不那么明显。应带着以下问题来识别TSF 接口：“潜在攻击者如何与 TSF 交互以试图破坏SFR？”因此，从评估的角度来看，攻击者是否可以滥用接口来访问安全功能以破坏受 TSF 保护的资产也很重要。任何可能被攻击者使用的 TSF 相关接口都属于 TSF接口（无论进一步分类为 SFR-执行、SFR-支撑或SFR-无关）。是否会从外部访问 TSF 或 TSF 是否访问外部资源（例如 TSF 调用平台或用户）并不重要。唯一的衡量标准是，是否存在来自外部的对TSF的潜在干扰。以下讨论说明了TSFI定义在不同上下文中的应用。电气接口在诸如智能卡之类的 TOE 中，攻击者不仅对 TOE 具有逻辑访

21、问权限，而且对 TOE 具有完备的物理访问权限，TSF 边界就是物理边界。因此，暴露的电气接口被认为是 TSF 接口，因为它们的操作会影响 TSF 的行为。因此，需要描述所有此类接口（电气触点）：例如可以适用的各种电压等。网络协议栈TOE中执行协议处理的TSF接口将是潜在攻击者可直接访问的那些协议层。这些接口不一定是整个协议栈，但也可能是。例如，如果 TOE 是某种网络设备，潜在的攻击者可能会影响协议栈的每一层（即发送任意信号、任意电压、任意数据包、任意数据等），那么协议栈的每一层均为TSF 的边界。因此，功能规范必须覆盖堆栈的每一层中的每个协议。但是，如果 TOE 是保护内部网络免受互联网攻

22、击的防火墙，那么潜在的攻击者将无法直接操纵电压进入 TOE；任何极端电压都无法通过互联网传递，也就是说，攻击者只能访问Internet层或以上的那些协议。TSF 边界存在于堆栈的每一层。因此，功能规范应只描述Internet层或以上的那些协议：它应根据有可能出现在网路上的正常输入描述防火墙所暴露的每个不同通信协议层，以及正常和恶意输入所导致的后果。例如，Internet层协议将描述如何构成一个格式良好的 IP 数据包，以及在接收到格式正确和格式错误的数据包时会发生什么。同样，TCP层的描述应包括如何建立TCP连接以及在成功建立连接和无法建立连接或异常丢弃时会发生什么。假设防火墙的目的是为了过滤

23、应用层命令（如 FTP 或telnet），那么应用层的描述应包括防火墙能够识别和过滤的应用层命令，以及针对未知命令的处理结果。对这些层的描述可参考公开发布的正使用的通信标准（telnet、FTP、TCP 等），并注释出所选择的用户定义选项。包装器包装器“包装器”将一系列复杂的交互转化为简单的通用服务，例如操作系统创建 API 供应用程序使用（如图 A.1所示）。无论TSF接口是系统调用还是依赖于应用程序使用的API：如果应用程序可以直接使用系统调用,那么系统调用就是TSFI接口。但是，如果禁止直接调用它们并要求通过 API 进行所有通信，那么API将是TSFI。图形用户界面类接口也是类似的：它

24、在机器可理解的命令和用户友好图形界面之间进行转换。类似地，TSF接口可以是用户有权限访问的命令，也可以是用户被限制使用的图形界面（下拉菜单、复选框、文本字段）。值得注意的是，在这两个例子中，如果用户被禁止使用更原始的接口（即系统调用或命令），这种限制及其执行的描述将被包括在安全架构描述中（见A.1）。此外，包装器将是 TSF 的一部分。不可访问的接口对于给定的TOE，并非所有接口都可以访问。也就是说，运行环境（在ST中）的安全目的可能会阻止对这些接口的访问或以几乎不可访问的方式限制访问。此类接口不会被视为 TSF 接口。以下是一些例子：如果对于独立防火墙运行环境的安全目的规定陈述为：防火墙将在

25、只允许可信且经过培训的人员才能进入的机房环境中运行，机房将配备可中断的电源（防止断电），那么物理和电源接口将是不可访问的，因为可信且经过培训的人员将不会试图拆除防火墙和/或中断电力供应。如果对于软件防火墙（应用程序）运行环境的安全目的规定陈述为：操作系统和硬件将为应用程序提供一个安全域，防止其他程序的篡改，那么操作系统中可被其他应用程序访问防火墙的接口就应是不可访问接口（如删除或修改防火墙的可执行文件，直接读写防火墙的内存空间），因为运行环境的操作系统/硬件部分使得这种接口不可访问。如果软件防火墙运行环境的安全目的还规定了，操作系统和硬件会如实地执行 TOE 的命令，并且不会以任何方式篡改 T

26、OE，那么防火墙从操作系统和硬件获得原始功能的接口（执行机器代码指令、操作系统 API，如创建、读取、写入或删除文件、图形 API 等）将是不可访问的，因为操作系统/硬件是唯一能够访问该接口的实体，并且它们是完全可信的。对上述示例，这些不可访问的接口不是 TSF 接口。示例：复杂的 DBMS图 A.2举一个复杂 TOE的例子：一个依赖于 TOE边界之外的硬件和软件的数据库管理系统（在本讨论的其余部分被称为IT 环境）。为简化本示例，TOE 等同于 TSF 。阴影框代表 TSF，而无阴影框代表环境中的 IT 实体。TSF 包括数据库引擎和管理用户图形界面（由标记为DB的框表示）以及作为操作系统的

27、一部分运行的执行某些安全功能的内核模块（由标记为PLG的框表示）。TSF 内核模块具有操作系统规范定义的入口点，操作系统将通过这些入口点来调用某些功能（这可能是设备驱动或身份验证模块等）。关键在于这个可嵌入内核模块提供了 ST 中功能要求描述的安全服务。DBMS 系统的接口IT 环境由操作系统本身（由标记为OS的框表示）以及外部服务器（由标记为SRV的框表示）组成。这个外部服务器和操作系统一样，提供了 TSF 所依赖的服务，因此也要被列为 IT 环境。图中Ax 表示 TSF接口，Bx表示其他接口，这些接口将记录在 ACO：组合中。以下将分别描述这些接口。接口组 A1 代表最直观的TSF接口集。

28、这些是用户用来直接访问数据库及其安全功能和资源的接口。接口组 A2 代表操作系统调用以获得可嵌入模块所提供功能的 TSF 接口。这些接口与接口组 B3 形成对比，后者代表可嵌入模块为从 IT 环境中获取服务而进行的调用。接口组A3 代表通过 IT 环境的 TSF 接口。在这种情况下，DBMS 使用一个私有的应用层协议进行网络通信。虽然 IT 环境负责提供多种支持协议（例如以太网、IP 、TCP），但用于从 DBMS 获取服务的应用层协议是 TSF 接口，必须在文档中描述。虚线表示通过网络连接从 TSF 返回的值/服务。标记为Bx的接口代表 IT 环境中的功能接口。这些接口不是 TSF 接口，仅

29、当 TOE 作为与 ACO 类活动的一部分被用于组合评估时才需要讨论并分析。功能规范实例概述以用于内外网之间的防火墙为例，它验证接收到的数据的源地址（以确保外部数据没有试图伪装成来自内部的数据）；如果它检测到任何此类尝试，它会将违规尝试保存到审计日志中。通过建立一个从内部网络到防火墙的 telnet 连接，管理员可连接到防火墙。管理员行动包括鉴权、口令更改、审查审计日志、设置或更改内部和外部网络地址。例如，防火墙提供了以下内部网络接口：IP 数据报；管理员命令；为外部网络提供以下接口：IP 数据报。接口描述：IP 数据报数据报采用 RFC791 中规定的格式。目的：将数据块（数据报）从源主机传

30、输到由固定长度地址确定的目的主机；还提供了必要时对长数据报的分割和重新组合，以便通过小包网络传输。使用方法：它们来自底层（例如，数据链路）协议。参数：IP 数据报头的以下字段：源地址、目的地址、分片标志位。参数描述：如RFC791 中第 3.1 条（“Internet 报头格式”）的定义。行动：传输非伪造的数据报；必要时对大数据报进行分段；将分段数据重组形成数据报。错误消息：（无）。无法保证可靠性（由上层协议提供可靠性）丢弃无法传递的数据报（例如，必须对传输进行分片，但设置了不分片标志位）。接口描述：管理员命令管理员命令为管理员提供了一种与防火墙交互的方法。这些命令和响应运行在从内部网络上的任

31、何主机建立的 telnet (RFC854) 连接之上。可用的命令有：Passwd目的：设置管理员密码；使用方法：Passwd ；参数：密码；参数描述：新密码的值；行为：将密码更改为新提供的值。没有任何限制；错误消息：无。Readaudit目的：将审计日志呈现给管理员；使用方法：Readaudit；参数：无；参数描述：无；行为：提供审计日志文本；错误消息：无。Setintaddr目的：设置内部网络的地址。使用方法：Setintaddr参数：address参数描述：IP 地址的前三个字段（如 RFC791中所定义）。例如：123.123.123；行为：更改定义内部网络的变量内部值，该值用于判断伪

32、装尝试；错误消息：-“address in use”：表示所识别出的内部网络与外部网络地址相同。 Setextaddr目的：设置外部网络地址；使用方法：Setextaddr；参数：address；参数描述： - IP 地址的前三个字段（如 RFC791中所定义）。例如：123.123.123；行为：改变定义外部网络的变量的内部值。错误信息：“address in use”：表示所识别出的外部网络与内部网络地址相同。ADV_INT：TSF 内部的补充材料概述评估对象种类繁多，因此无法编纂出比“结构合理”或“最小复杂度”更具体的任何内容。对结构和复杂度的判断预计将从 TOE 使用的具体技术中得出。

33、例如，如果软件表现出软件工程学科中所提及的特征，就有可能被认为是结构合理。本附录提供了用于评估 TSF 面向过程的软件部分的结构和复杂度补充材料。本材料是基于软件工程文献中现有的信息。对于其他种类的内部结构（如硬件、非过程化软件如面向对象的代码等），应参考相应的最佳实践文献。程序软件的结构概述程序软件的结构传统上是根据其模块化程度来评估的。用模块化设计编写的软件，通过明确一个模块对其他模块的依赖性（耦合）以及在一个模块中只包括相互之间有强关联的任务（内聚）实现可理解性。模块化设计的使用减少了 TSF 元素之间的相互依赖性，从而降低了一个模块中的更改或错误对整个 TOE 产生影响的风险。模块化设

34、计的使用增强了设计的清晰度，并为不发生非预期影响提供更多保障。模块分解可取的附加属性是减少了冗余或非必要代码的数量。最小化 TSF 中的功能数量允许评估者和开发者只关注 SFR 实现所必需的功能，从而进一步提高可理解性并降低设计或实现错误的可能性。将模块化分解、分层和最小化合并到设计和实现过程必须伴随着合理的软件工程考虑。一个实用的、有用的软件系统通常会伴随着模块之间的一些不良耦合，一些模块包括松散相关的功能，以及模块设计中的一些微性或复杂之处。这些偏离模块化分解的理想通常被认为是实现某些目标或约束的必要条件，可能与性能、兼容性、未来计划的功能或其他一些因素有关，并且可能是可以接受的，这取决于

35、开发者对它们的解释。在应用本类的要求时，必须适当考虑合理的软件工程原则；但是，内部结构的易理解性是必须达成的整体目标。内聚内聚是指单个软件模块所执行的任务相互关联的方式和程度；内聚的类型包括偶然内聚、通信内聚、功能内聚、逻辑内聚、顺序内聚和时间内聚。下面描述了这些模块内聚类型的特征，以其可取性递减的顺序列出。功能内聚：具有功能内聚的模块执行与单一目的相关的活动。功能内聚模块将单一类型的输入转换为单一类型的输出，例如堆栈管理器或队列管理器。顺序内聚：具有顺序内聚的模块包含多个功能，其中每个功能的输出都是模块中后续功能的输入。顺序内聚模块的一个示例是包含写入审计记录功能和维护特定类型审计违规累积次

36、数的实时计数功能模块。通信内聚：具有通信内聚的模块包含为模块内的其他功能产生输出或使用来自模块内其他功能的输出的功能。通信内聚模块的一个例子是包括强制性、自主性和能力验证功能的访问验证模块。时间内聚：具有时间内聚的模块包含需要几乎同时执行的各类功能。时间内聚模块的示例包括初始化、恢复和关机模块。逻辑（或程序）内聚：具有逻辑内聚的模块在不同的数据结构上执行类似的活动。如果模块的功能对不同的输入执行相关但不同的操作，则该模块表现为逻辑内聚。偶然内聚：具有偶然内聚的模块执行不相关或松散相关的活动。耦合耦合是软件模块之间相互依赖的方式和程度；耦合类型包括调用耦合、公共耦合和内容耦合。下面描述了这些模块

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

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

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

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

41、要求所覆盖)。ADV_TDS：子系统和模块概述本节提供了关于 TDS 族的附加指南，以及其对术语“子系统”和“模块”的使用的额外指导。随后讨论了随着有更多细节的要求的出现，如何减少有较少细节的要求。子系统如图 A.3所示，根据TSF的复杂度，设计可以从子系统和模块维度来描述（子系统比模块的抽象级别更高）；或者也可仅从一个抽象级别进行描述（例如，较低保障级别中的子系统，较高保障级别中的模块）。如果从低抽象级别（模块）进行描述，那么也默认满足了对高抽象级别（子系统）的要求。这个概念在下面关于子系统和模块的讨论中得到进一步的阐述。子系统和模块开发者应使用子系统来描述 TOE 的设计。术语“子系统”用

42、起来比较模糊，它可以用来指代适用于TOE的单元（例如，子系统、模块）。子系统甚至可以在范围上是不均匀的，只要满足子系统描述的要求即可。子系统的第一个用途是区分TSF的边界；即，包含TSF的TOE部分。一般而言，如果某个子系统具有影响任何 TSF 正确操作的能力（无论是通过设计还是实现），那么它就是TSF的一部分。例如，对于依赖不同硬件执行模式来提供域隔离（见A.1）的软件，其中 SFR-执行代码在一个域中执行，那么在该域中执行的所有子系统都将被视为 TSF 的一部分。同样，如果该域外的一台服务器实现了SFR（例如，对其管理的对象实现访问控制策略），那么它也将被视为 TSF 的一部分。子系统的第

43、二个用途是提供一种描述 TSF 的结构，在描述 TSF 如何工作时，不一定包含模块描述中的低层实现细节（稍后讨论）。可对子系统进行高级别描述（缺乏丰富的实现细节）或细节层面描述（提供对实现的更多洞察）。为子系统提供的描述级别取决于该子系统对某SFR的实现程度。SFR-执行子系统是提供执行任何SFR元素的机制的子系统，或直接支撑实现某个SFR 的子系统。如果一个子系统提供（实现）一个 SFR-执行TSFI，那么这个子系统就是 SFR-执行的。子系统也可以被识别为SFR-支撑和SFR-无关子系统。SFR-支撑子系统受 SFR-执行子系统依赖以实现SFR，但它不像 SFR-执行子系统那样直接发挥作用

44、。SFR-无关子系统是不依赖于支撑或执行作用而实现 SFR 的子系统。模块模块通常是一个相对较小的架构单元，可以根据 TSF 内部结构 (ADV_INT) 中讨论的属性进行表征。当 PP 或 ST 中同时存在 ADV_TDS.3 基础模块设计（或以上）要求和 TSF 内部（ADV_INT）要求时，TOE 设计（ADV_TDS）要求中的“模块”与TSF 内部 (ADV_INT) 要求中的“模块”是同一实体。与子系统不同，模块很详细地描述了实现，可以指导对实现表示的评估。需要注意的是，基于TOE产品形态，模块和子系统可能为同一抽象层。对于 ADV_TDS.1 基础设计和 ADV_TDS.2 结构化

45、设计（不需要在模块级别进行描述），子系统描述提供了关于 TSF 的最低级别细节。对于 ADV_TDS.3 基础模块化设计（需要模块描述），这些描述提供最低级别细节，而子系统描述的详细程度应考虑（如果它们作为单独的实体存在）上下文中的模块描述。也就是说，如果存在模块描述，则无需提供详细的子系统描述。在足够简单的 TOE 中，不需要单独的“子系统描述”；可以通过模块提供的文档来满足要求。对于复杂的 TOE，子系统描述（关于TSF的）的目的是为读者提供上下文，以便他们可以适当地聚焦他们的分析。这种差异如图 A.3所示。SFR-执行模块是实现ST中完全或部分实现一个SFR的模块。此类模块可能会实现 S

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

47、重要的模块被错误地归类为SFR-支撑模块，而第二种解释则可能导致实际上并非SFR-执行的模块被归类为SFR-执行。模块的描述应该可以根据模块描述创建其实现，且产生的实现将：1）在呈现的接口方面与实际的TSF实现相同，2）接口的使用与设计中提及的相同，3）功能与TSF模块目的所描述的信息保持一致。例如，RFC793提供 TCP 协议的高层次描述。它必须是独立实现的。虽然它提供大量细节，但它不是一个合适的设计描述，因为它在实现方面不是具体的。在实际实现中，可以向 RFC 中规定的协议中添加内容，且实现中的选择（例如，在实现的各个部分中使用全局数据与本地数据）可能对执行的分析产生影响。TCP 模块的

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

49、。接口描述应包括参数列表及对这些参数的描述。如果一个参数被要求从一组值中取值（例如，“flag”参数），则要描述该参数会影响模块处理的取值的全集。同样，描述数据结构的参数，要标识和描述数据结构的每个字段。对全局数据的描述信息要确保可理解其目的。全局数据结构所需的描述等级需要与模块接口的描述水平相同，其中输入参数和返回值对应于数据结构中的各个字段及其可能的值。全局数据结构可与操作或读取它们的模块分开描述，只要模块的设计中包含关于全局数据结构更新的足够信息或从全局数据结构中提取的信息即可。请注意，不同的编程语言可有额外不明显的“接口”；例如 C+中的重载运算符/函数，这种“隐式接口”也将作为模块设

50、计的一部分描述。请注意，尽管一个模块可仅呈现一个接口，但更常见的情况是一个模块呈现一小组相关接口。当需要描述一个模块所使用的接口时，必须在模块的设计描述或被调用模块的目的中明确此类接口，以及期望从被调用模块中得到什么服务。例如，如果模块 A 被描述，并且它使用模块 B 的冒泡排序程序，那么模块之间交互的描述必须说明为什么调用模块 B 的冒泡排序程序以及这个调用对SFR的实现有什么贡献。模块B 的冒泡排序程序接口和目的必须作为模块 B接口的一部分进行描述（提供ADV_TDS的级别和模块B的分类需要一个对它的接口的描述），基于此，模块 A 只需要识别需要使用此程序进行排序的数据。一个适当的描述是：

51、“模块 A 调用模块 B 的接口double_bubble()按字母顺序对用户名进行排序”。请注意，如果用户名的这种排序对于执行任何 SFR 并不重要（例如，它只是为了提升性能，并且模块 A 的算法实现也可以避免对用户名进行排序），使用模块B 的冒泡排序程序不是SFR-执行，在模块 A 的描述中充分解释用户名按字母顺序排序是为了提升性能即可。模块 B 可仅被归类为“SFR-支撑”，选择的 ADV_TDS 级别会明确是否需要描述 SFR-支撑模块的接口，或仅描述模块 B 的目的即可。如前所述，模块的算法描述应该以算法的方式描述模块的实现。这可以在伪代码中完成，通过流程图，或(在ADV_TDS.3

52、基础模块设计)非正式文本。它讨论了如何使用模块的输入和调用的函数来完成模块的功能。它记录了模块产生的全局数据、系统状态以及返回值的变化。基于这些细节层面的描述，可以得出一个与TOE实际实现非常相似的实现。需要注意的是，源代码不符合模块文档要求。虽然模块设计描述了实现，但它并不是真正的实现。如果源代码中的注释对源代码含义进行了解释，那么这些注释可能是足够的文档说明。仅仅说明每行代码是做什么的行内注释是无用的，因为它们没有解释该模块旨在完成什么。在下面的元素中，为子系统和模块讨论的标签（SFR-执行、SFR-支撑和SFR-无关）用于描述开发者需要提供的信息的数量和类型。这些元素已被结构化了，因此不

53、要期望开发者仅提供特定的信息，也就是说，如果开发者的 TSF 文档提供了以下要求中的信息，则开发者不会更新他们的文档并将子系统和模块标记为 SFR-执行、SFR-支撑、SFR-无关。这种标记的主要目的是允许使用不太成熟开发方法（以及相关构件如详细的接口和设计文档）的开发者在不产生不必要成本的情况下提供必要的证据。分级方法由于确定什么是SFR-执行与SFR-支撑（以及在某些情况下，甚至确定什么是SFR-无关）带有主观性，在本族中采用下面的范例。在本族的早期组件中，开发者提供适当的信息以说明子系统分类为SFR-执行等，并且很少有额外的证据提供给评估者用于检查这种分类的正确性。随着所需保障级别的增加

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

55、 -支撑SFR 无关ADV_TDS.1 基础设计（非形式化陈述）结构、SFR-执行行为概述、交互指定支撑指定支撑ADV_TDS.2 结构化设计（非形式化陈述）结构、SFR-执行行为详细描述、。行为、其他行为的概述、交互结构、其他行为的概述、交互指定支撑、交互ADV_TDS.3 基础模块设计（非形式化陈述）描述、交互描述、交互描述、交互目的、SFR接口b交互、目的交互、目的ADV_TDS.4 半形式化模块设计（半形式化陈述）描述、交互描述、交互描述、交互目的、SFR 接口目的、SFR 接口交互、目的ADV_TDS.5 完全半形式化模块设计（半形式化陈述）描述、交互描述、交互描述、交互目的、所有接

56、口c目的、所有接口目的、所有接口ADV_TDS.6 带形式化高层设计表示的完全半形式化模块设计（半形式化陈述、附加的形式化陈述）描述、交互描述、交互描述、交互目的、所有接口目的、所有接口目的、所有接口a指定支撑意味着只需要提供足以支持子系统/模块分类的文档。b SFR 接口意味着模块描述包含每个SFR-相关接口的返回值和调用的其他模块的接口。c所有接口意味着模块描述包含每个接口的返回值和调用的其他模块的接口。安全相关性GB/T 18336系列将描述、证据和分析集中在TOE的安全功能上。这需要对 TOE 的功能和物理部分的安全相关性进行表征。接口、子系统和模块可（隐式或显式）分类为“SFR-执行

57、”、“SFR-支撑”或“SFR-无关”。开发者的证据和评估分析均与 TOE 相关，并侧重于 TSF 及其 SFR-执行和 SFR-支撑的实现。安全架构描述应证实已识别的 TOE 的非-TSF 子系统无法旁路 TSF，并且 TSF自保护机制可免受非-TSF 代码或实体的破坏。开发者应在 TOE 设计中描述SFR-无关的接口、子系统和模块，并证实它们不会因为其目的、交互或资源分离而干扰TSF。接口、子系统或模块可划分为SFR-执行，如果它直接实现某个SFR。SFR-支撑，如果SFR的正常功能实现依赖于它的功能的正确运行。SFR-无关，如果它与SFR的实现无关。对安全执行和安全支撑功能的关注点是需要

58、证明其他功能为SFR-无关的。即使是正确实现的安全执行功能和安全机制也可能被旁路、规避、停用、破坏或直接攻击。无干扰意味着TSF不能被滥用，并且阻止其（或不可能）对TSF实现的资源进行未授权访问。因此，如果对安全相关的接口、子系统和模块进行了分类，并且此分类用于脆弱性分析中时，那么TOE的安全架构具备不可旁路和自保护机制是至关重要的。TSF自保护是安全架构属性，由此TSF不会被非TSF代码或实体破坏。这包括TOE的非-TSF子系统和IT产品的非TOE部分。它类似于SFR-无关子系统/模块的证据。安全域是由TSF提供的，供不可信实体使用的环境，其实现方式是将这些环境相互隔离并相互保护。因此，评估

59、期间对无关的分析需要检查TOE (ADV_ARC)的安全架构，并且可能需要更多关于非TSF子系统的信息，而不仅仅是停留在为ADV_TDS.x.1所提供的TOE子系统层面的信息。开发者应提供逻辑依据以说明TSF的定义是正确的，并从SFR-无关模块的目的和与其他模块的交互方面进行分析。目的：模块如何提供其功能，不需要进一步的设计决策。交互：子系统或模块进行通信的原因，并表征所传递的信息（无需描述到接口层面）。在评估期间，应将无关类的分析作为功能规范和TOE设计检查以及脆弱性分析的一部分。将接口、子系统和模块分类为SFR-执行、SFR-支撑、SFR-无关意味着需要对功能规范、设计和测试进行具体检查。

60、将TSFI解释为所有可访问TSF的外部接口将有助于此分析。所有TSF子系统（从 ATE_DPT.1 开始）和所有TSF模块（ATE_DPT.3 及更高级别）的功能测试宜为其分类的正确性提供证据。形式化方法补充材料形式化方法提供了 TSF 及其行为的数学表示，并且是 ADV_SPM.1（形式化TOE安全策略模型）、ADV_FSP.6（附加形式化描述的完备的半形式化功能规范）和 ADV_TDS.6（带形式化高层设计表示的完全半形式化模块设计）组件中所要求的。在GB/T 30270:20XX，附录C评估技术和工具中，提供了关于形式化方法的补充材料。图 A.4说明了 ADV_SPM.1 中规定的 SP