认监委 发布《抗拒绝服务系统安全评价规范》（征求意见稿）
《抗拒绝服务系统安全评价规范》（征求意见稿）
前言
本标准按照GB/T 1.1-2009的规则起草。
本标准由国家认证认可监督管理委员会提出并归口；
本标准起草单位：中国信息安全认证中心，XXX，XXX 等；
本标准主要起草人：。
1. 范围
本评价规范是国家实施信息技术产品信息安全认证的指导性技术规范之一，
本评价规范所指的抗拒绝服务系统产品是指对抗拒绝服务攻击的硬件设备或软硬件组合，通过监测和控制进出的数据流，及时发现背景流量中各种类型的拒绝服务攻击行为，对攻击流量进行过滤或旁路，保证正常流量的通过，实现对拒绝服务攻击的防护作用。
本评价规范适用于抗拒绝服务系统产品。
2. 规范性引用文件
下列标准所包含的条文，通过在本评价规范中引用而成为本评价规范的条款。凡是注明日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本评价规范。
3. 术语和定义
标准《GB/T 18336-2008信息技术 安全技术 信息技术安全性评估准则》中确立的术语和定义适用于本规范。
3.1.1. 授权管理员
具有抗拒绝服务系统管理权限的用户，负责对抗拒绝服务系统的系统配置、安全策略、审计日志等进行管理。
3.1.2. 安全策略
有关管理、保护和发布敏感信息的法律、规定和实施细则。
3.1.3. 拒绝服务
通过发送大量垃圾信息或干扰信息的方式，导致无法向正常用户提供服务的现象。
3.1.4. 拒绝服务攻击
拒绝服务攻击，即DoS攻击。造成拒绝服务的攻击行为被称为拒绝服务攻击。
3.1.5. 抗拒绝服务系统
对抗拒绝服务攻击的硬件设备或软硬件组合，其通过监测和控制进出的数据流，及时发现背景流量中各种类型的拒绝服务攻击行为，对攻击流量进行过滤或旁路，保证正常流量的通过，实现对拒绝服务攻击的防护作用。
3.1.6. 吞吐量
抗拒绝服务系统在不丢包情况下转发数据的能力，一般以所能达到线速的百分比（或称通过速率）来表示。
3.1.7. 流量牵引
流量牵引就是通过旁路部署模式情况下，将攻击流量和正常流量进行分离，由抗拒绝服务系统来专门抵抗拒绝服务攻击，保证正常流量尽可能的不受到攻击的干扰。
3.1.8. Bypass功能
Bypass功能既是旁路功能，通过特定的触发状态（断电或死机）让两个网络不通过网络安全设备的系统，直接物理上导通。
4. 符号和缩略语
DOS 拒绝服务 Denial of Service
FTP 文件传输协议 File Transfer Protocol
HTTP 超文本传输协议 HyperText Transfer Protocol
IP 网络互连的协议 Internet Protocol
POP3 邮局协议的第3个版本 Post Office Protocol 3
PING 因特网包探索器 PING Packet Internet Grope
SSL 安全的数据加密传输 Secure Socket Layer
SSH 建立在应用层和传输层基础上的安全协议 Secure Shell
SYN 建立连接时使用的握手信号 synchronize TCP/IP
SNMP 简单网络管理协议 Simple Network Management Protocol
SMTP 简单邮件传输协议 Simple Mail Transfer Protocol
TCP 传输控制协议 Transmission Control Protocol
UDP 用户数据包协议 User Datagram Protocol
5. 技术要求
5.1. 总体说明
5.1.1. 技术要求分类
本评价规范包括对产品的功能要求、性能要求、安全要求和安全保证要求。
5.1.2. 安全等级
本技术要求不对产品进行安全等级划分。产品的安全保证要求采用GB/T18336.3-2008中有关EAL2级的要求。
5.2. 功能要求
5.2.1. 部署方式
a) 应支持串联接入模式；
b) 应支持旁路接入用户网络，当检测有攻击时，牵引受攻击IP流量至抗拒绝服务系统，经过滤后，将正常流量发至用户网络。
5.2.2. 系统监控告警
a) 应具备网络流量监控功能，对网络接口的流量实时显示；
b) 应具备网络连接监控功能，对访问连接数和网络中受保护的主机的连接情况实时显示；
c) 应具备系统负载监控功能，包括实时显示系统的CPU、内存的占用情况、报文收发数据；
d) 应支持SNMP协议方式的设备监控；
e) 应对异常网络流量、连接、攻击及系统负载设置告警功能，并将报警信息以消息或邮件等形式提交给管理员。报警信息至少应包括以下内容：
1） 事件标识；
2） 事件主体；
3） 事件客体；
4） 事件发生时间。
5.2.3. 攻击类型防护
1） 应能防护各类基于流量型、连接耗尽型等网络层拒绝服务攻击，如SYN Flood、UDP Flood、ICMP Flood等；
2） 应能针对应用层拒绝服务攻击进行有效防护，如CC攻击；
3） 应能防护 典型的拒绝服务攻击，如Smurf、Teardrop、Ping Sweep、IP Spoof、IP Fragmentation Overlap、Ping of Death等。
5.2.4. 流量限制防护
a) 应提供流量限制特性，用于应对突发的流量异常变化；
b) 应具备全局、单主机流量限制。
5.2.5. 高级防护功能(如适用)
a) 应实现对应用层协议高级防护（如：FTP,SMTP,POP3,HTTP等)，系统应具有应用层协议防护模块；
b) 产品应具备灵活的对自定义端口的防护设置功能；
c) 产品应具备对数据包进行深层次的过滤功能，应允许管理员根据数据包的源、目的IP，源、目的协议端口，协议类型及TCP Flag/ICMP Type/ICMP Code等特征字节定义过滤规则。
5.2.6. 系统管理
应具备灵活的配置管理功能，支持本地管理和远程管理，系统应具备同步网络时间的功能。
5.2.7. 产品升级
应支持手动或者自动的方式进行产品升级，对规则库、策略文件以及服务程序等进行更新。
5.2.8. 高可用性
在串接方式下应具备硬件或者软件Bypass功能，能够在断电、硬件故障等异常情况下保持网络连通。
抗拒绝服务系统产品可支持双机热备、负载均衡等高可用性功能。
5.3. 性能要求
5.3.1. 吞吐量
测试设备或系统在没有丢包情形下的最大传送数据的速率。
5.4. 安全要求
5.4.1. 安全审计
5.4.1.1. 审计数据产生（FAU_GEN.1）
a) 抗拒绝服务系统应对以下事件生成审计记录：
1） 攻击事件、攻击类型、攻击特征、攻击来源等信息；
2） 用户的创建、修改、删除、权限分配等管理行为；
3） 任何使用鉴别机制的行为；
4） 鉴别失败的次数超过给定门限导致会话终止；
5） 企图修改待测目标安全功能配置参数的行为（无论成功与否）。
b) 抗拒绝服务系统每个审计记录中应记录下列信息：
（1） 事件发生的日期、时间；
（2） 事件的类型；
（3） 主体身份；
（4） 客体身份；
（5） 事件的结果（包括成功或失败）。
5.4.1.2. 审计查阅（FAU_SAR.1）
a) 抗拒绝服务系统应为授权管理员提供从审计记录中读取全部审计信息的功能；
b) 抗拒绝服务系统应以便于用户理解的方式提供审计记录。
5.4.1.3. 可选审计查阅（FAU_SAR.3）
抗拒绝服务系统应根据主体ID（标识符）、客体ID、日期、时间以及这些参数的逻辑组合等参数提供对审计数据进行搜索、分类或排序的能力。
5.4.1.4. 防止审计数据丢失（FAU_STG.4）
a) 抗拒绝服务系统的安全功能应把生成的审计记录存储于一个永久性的记录中或导出到审计日志服务器；
b) 对因故障或存储耗竭而导致审计数据丢失的最大审计存储容量，抗拒绝服务系统的开发者应提供相应的分析结果；
c) 一旦审计存储容量达到事先规定的警戒值，应能发送警告信息，并保证在授权管理员所采取的审计行为以外，防止其他可审计行为的出现。
5.4.2. 标识和鉴别
5.4.2.1. 鉴别的时机（FIA_UAU.1）
a) 在用户被鉴别前，TSF应只允许用户执行输入登录信息、查看登录帮助等操作；
b) 在允许执行代表该用户的任何其它TSF的动作前，TSF应要求每个用户都已被成功鉴别。
5.4.2.2. 用户属性定义（FIA_ATD.1）
抗拒绝服务系统应为每一个用户保存安全属性表，属性应包括：用户标识、鉴别数据、授权信息或用户组信息、其他安全属性等。
5.4.2.3. 鉴别失败处理（FIA_AFL.1）
在经过一定次数的鉴别失败后，抗拒绝服务系统安全功能应能终止进行登录尝试主机建立会话的过程。最多失败次数仅由授权管理员设定。
5.4.3. 安全管理
5.4.3.1. 安全功能行为的管理（FMT_MOF.1）
抗拒绝服务系统应仅限于已识别了的指定的授权角色对产品功能具有启用、禁止、修改的能力。
5.4.3.2. 安全属性管理（FMT_MSA.1）
抗拒绝服务系统应执行访问控制策略或信息流控制策略，以限制已识别了的授权角色查询、修改和删除安全属性的能力。
5.4.3.3. 安全角色（FMT_SMR.1）
a) 抗拒绝服务系统应维护已标识的授权角色；
b) 抗拒绝服务系统应能够将用户与角色关联起来。
5.4.3.4. TSF数据的管理（FMT_MTD.1）
抗拒绝服务系统应仅允许授权管理员控制TSF数据的管理。
5.4.4. TSF保护
5.4.4.1. 传送过程中TSF间的保密性（FPT_ITC.1）
TSF应保护所有从抗拒绝服务系统传送到远程管理主机的TSF数据在传送过程中不会被未授权泄漏。
5.4.4.2. 可信恢复（FPT_RCV.2.2）
当抗拒绝服务系统的发生服务中断后在人工干预的情况下或者无人工干预自动恢复到安全状态。
5.4.5. 用户数据保护
5.4.5.1. 基于安全属性的访问控制（FDP_ACF.1）
a) 产品安全功能应基于安全属性和确定的安全属性组，对已明确的客体执行产品访问控制策略；
b) 产品安全功能应执行产品访问控制策略，决定受控的主体与客体间的操作是否被允许。
5.5. 保证要求
5.5.1. 配置管理
5.5.1.1. 配置项
开发者应执行以下内容：
a) 开发者应为抗拒绝服务系统产品提供一个参照号；
b) 开发者应使用一个配置管理系统；
c) 开发者应提供配置管理文档。
开发者执行的内容应满足以下要求：
a) 抗拒绝服务系统产品参照号对抗拒绝服务系统产品的每一个版本应是唯一的；
b) 应该给抗拒绝服务系统产品标记上参照号；
c) 配置管理文档应包括一个配置清单；
d) 配置清单应唯一标识组成抗拒绝服务系统产品的所有配置项；
e) 配置清单应描述组成抗拒绝服务系统产品的配置项；
f) 配置管理文档应描述用于唯一标识抗拒绝服务系统产品所包含配置项的方法；
g) 配置管理系统应唯一标识抗拒绝服务系统产品所包含的所有的配置项。
评估者应执行以下内容：
评估者应确认开发者所提供的信息应满足对开发者的要求。
5.5.2. 交付与运行
5.5.2.1. 交付程序
开发者应执行以下内容：
a) 开发者应将把TOE及其部分交付给用户的程序文档化；
b) 开发者应使用交付程序。
开发者执行的内容应满足以下要求：
交付文档应描述，在向用户方分发抗拒绝服务系统产品版本时，用以维护其安全性所必需的所有程序。
评估者应执行以下内容：
评估者应确认开发者所提供的信息应满足对开发者的要求。
5.5.2.2. 安装、生成和启动程序
开发者应执行以下内容：
开发者应将TOE安全地安装、生成和启动必需的程序文档化。
开发者执行的内容应满足以下要求：
安装、生成和启动文档应描述抗拒绝服务系统产品安全地安装、生成和启动所必需的所有步骤。
评估者应执行以下内容：
评估者应确认开发者所提供的信息应满足对开发者的要求。
5.5.3. 开发
5.5.3.1. 非形式化功能规范
开发者应提供以下文档：
开发者应提供一个功能规范。
开发者提供的文档应满足以下要求：
a) 功能规范应使用非形式化风格来描述抗拒绝服务系统产品安全功能与其外部接口；
b) 功能规范应当是内在一致的；
c) 功能规范应描述所有外部抗拒绝服务系统产品安全功能接口的用途与使用方法，适当时应提供效果、例外情况和错误消息的细节；
d) 功能规范应完备地表示抗拒绝服务系统产品安全功能。
评估者应执行以下内容：
评估者应确认开发者所提供的信息应满足对开发者的要求。
5.5.3.2. 描述性高层设计
开发者应提供以下文档：
开发者应提供抗拒绝服务系统产品安全功能的高层设计。
开发者提供的文档应满足以下要求：
a) 高层设计的表示应是非形式化的；
b) 高层设计应是内在一致的；
c) 高层设计应按子系统描述抗拒绝服务系统产品安全功能的结构；
d) 高层设计应描述每个抗拒绝服务系统产品安全功能子系统所提供的安全功能性；
e) 高层设计应当标识抗拒绝服务系统产品安全功能要求的任何基础性的硬件、固件或软件，以及在这些硬件、固件或软件中实现的支持性保护机制所提供功能的一个表示；
f) 高层设计应标识抗拒绝服务系统产品安全功能子系统的所有接口；
g) 高层设计应标识抗拒绝服务系统产品安全功能子系统的哪些接口是外部可见的。
评估者应执行以下内容：
评估者应确认开发者所提供的信息应满足对开发者的要求。
5.5.3.3. 非形式化对应性证实
开发者应提供以下文档：
开发者应提供一个所提供抗拒绝服务系统产品安全功能表示的所有相邻对之间对应性的分析。
开发者提供的文档应满足以下要求：
对于所提供的抗拒绝服务系统产品安全功能表示（如抗拒绝服务系统产品功能规范、高层设计等）的每个相邻对，分析应证实，较为抽象的抗拒绝服务系统产品安全功能表示的所有相关安全功能都在较不抽象的安全功能表示中得到正确且完备地细化。
评估者应执行以下内容：
评估者应确认开发者所提供的信息应满足对开发者的要求。
5.5.4. 指导性文档
5.5.4.1. 管理员指南
开发者应提供以下文档：
开发者应提供针对系统管理员的管理员指南。
开发者提供的文档应满足以下要求：
a) 管理员指南应描述抗拒绝服务系统产品管理员可使用的管理功能和接口；
b) 管理员指南应描述如何以安全的方式管理抗拒绝服务系统产品；
c) 管理员指南应包含一些关于安全处理环境中应被控制的功能和特权的警示信息；
d) 管理员指南应描述所有关于与抗拒绝服务系统产品运行有关的用户行为的假设；
e) 管理员指南应描述所有受管理员控制的安全参数，适当时应指明安全值；
f) 管理员指南应描述每一种与需要执行的管理功能有关的安全相关事件，包括改变抗拒绝服务系统产品安全功能所控制实体的安全特性；
g) 管理员指南应与供评估的所有其他文档一致；
h) 管理员指南应描述所有与管理员有关的IT环境安全要求。
评估者应执行以下内容：
评估者应确认开发者所提供的信息应满足对开发者的要求。
5.5.4.2. 用户指南
开发者应提供以下文档：
开发者应提供用户指南。
开发者提供的文档应满足以下要求：
a) 用户指南应描述抗拒绝服务系统产品的非管理用户可使用的功能和接口；
b) 用户指南应描述抗拒绝服务系统产品所提供的用户可访问安全功能的使用；
c) 用户指南应包含一些关于安全处理环境中应被控制的用户可访问功能和特权的警示信息；
d) 用户指南应清晰地阐述抗拒绝服务系统产品安全运行所必需的所有用户职责，包括与抗拒绝服务系统产品安全环境陈述中可找到的与关于用户行为的假设有关的那些职责；
e) 用户指南应与供评估的所有其他文档保持一致；
f) 用户指南应描述所有与用户有关的IT环境安全要求。
评估者应执行以下内容：
评估者应确认开发者所提供的信息应满足对开发者的要求。
5.5.5. 测试
5.5.5.1. 覆盖证据
开发者应提供以下文档：
开发者应提供测试覆盖的证据。
开发者提供的文档应满足以下要求：
测试覆盖的证据中应说明测试文档中所标识的测试与功能规范中所描述的抗拒绝服务系统产品安全功能之间的对应性。
评估者应执行以下内容：
评估者应确认开发者所提供的信息应满足对开发者的要求。
5.5.5.2. 功能测试
开发者应执行以下内容：
a) 开发者应测试抗拒绝服务系统产品安全功能，并文档化测试结果；
b) 开发者应提供测试文档。
开发者执行的内容应满足以下要求：
a) 测试文档应包括测试计划、测试程序描述、预期的测试结果和实际的测试结果；
b) 测试计划应标识要测试的安全功能，并描述要执行的测试的目标；
c) 测试程序描述应标识要执行的测试，应描述每个安全功能的测试脚本，这些脚本应包括对于其他测试结果的任何顺序依赖性；
d) 预期的测试结果应指出测试成功执行后的预期输出；
e) 开发者执行测试所得到的测试结果应证实每个被测试的安全性功能都按照规定运转。
评估者应执行以下内容：
评估者应确认开发者所提供的信息应满足对开发者的要求。
5.5.5.3. 独立测试——抽样
开发者应执行以下内容：
开发者应提供用于测试的抗拒绝服务系统产品。
开发者执行的内容应满足以下要求：
a) 开发者提供的抗拒绝服务系统产品应适合测试；
b) 开发者应提供一组相当的资源，用于开发者的抗拒绝服务系统产品安全功能的功能测试。
评估者应执行以下内容：
a) 评估者应确认开发者所提供的信息应满足对开发者的要求；
b) 评估者应适当地测试抗拒绝服务系统产品安全功能的一个子集，以确认抗拒绝服务系统产品按照规定运行；
c) 评估者应执行测试文档中的一个测试样本，以验证开发者的测试结果。
5.5.6. 脆弱性评定
5.5.6.1. TOE安全功能强度评估
开发者应执行以下内容：
开发者应对ST中所标识的每个具有抗拒绝服务系统产品安全功能强度声明的安全机制进行抗拒绝服务系统产品安全功能强度分析。
开发者执行的内容应满足以下要求：
a) 对于每个具有抗拒绝服务系统产品安全功能强度声明的安全机制，抗拒绝服务系统产品安全功能强度分析应说明该机制达到或超过PP/ST中定义的最低强度级别；
b) 对于每个具有抗拒绝服务系统产品安全功能强度声明的安全机制，抗拒绝服务系统产品安全功能强度分析应说明该机制达到或超过PP/ST中定义的特定功能强度度量。
评估者应执行以下内容：
评估者应确认开发者所提供的信息应满足对开发者的要求。
5.5.6.2. 开发者脆弱性分析
开发者应执行以下内容：
a) 开发者应执行脆弱性分析；
b) 开发者应提供脆弱性分析文档。
开发者执行的内容应满足以下要求：
a) 脆弱性分析文档应描述为搜索用户能违反抗拒绝服务系统产品安全策略的明显方法而执行的抗拒绝服务系统产品可交付材料分析；
b) 脆弱性分析文档应描述对明显的脆弱性的处置；
c) 脆弱性分析文档应针对所有已标识的脆弱性，说明脆弱性不能在抗拒绝服务系统产品的预期使用环境中被利用。
评估者应执行以下内容：
a) 评估者应确认开发者所提供的信息应满足对开发者的要求；
b) 评估者应在开发者脆弱性分析的基础上实施穿透性测试，以确保明显的脆弱性都已被处理。
6. 测评方法
6.1. 总体说明
测评方法与技术要求一一对应，它给出具体的测评方法来验证抗拒绝服务系统是否满足技术要求。它由测试环境、测试工具、检测要求、检测方法和判定结果五个部分组成。
6.2. 功能测试
6.2.1. 测试环境与工具
a) 测试环境图
图1 功能测试环境图
b) 测试工具：
应用层渗透性测试工具
拒绝服务测试工具
网络协议分析工具
6.2.2. 部署方式
a) 检测要求
1） 应支持串联接入模式；
2） 应支持旁路接入用户网络，当检测有攻击时，牵引受攻击IP流量至抗拒绝服务系统，经过滤后，将正常流量发至用户网络。
b) 检测方法
1） 产品以串联模式（网桥或路由模式）接入到网络中，验证该接入模式是否有效；
2） 产品以旁路监听的模式接入到网络中，验证当检测有攻击时，能否牵引受攻击IP流量至抗拒绝服务系统，经过滤后，将正常流量发至用户网络。
c) 结果判定
1） 产品支持串联接入模式；
2） 产品支持旁路接入用户网络中，当检测有攻击时，能够牵引受攻击IP流量至抗拒绝服务系统，经过滤后，将干净流量转发至用户网络；
1)或2）项符合为“符合”，1)和2）项都不符合为“不符合”。
6.2.3. 系统监控告警
a) 检测要求
1） 应具备网络流量监控功能，对网络接口的流量实时显示；
2） 应具备网络连接监控功能，对访问连接数和网络中受保护的主机的连接情况实时显示；
3） 应具备系统负载监控功能，包括实时显示系统的CPU、内存的占用情况、报文收发数据；
4） 应支持SNMP协议方式的设备监控；
5） 应对异常网络流量、连接、攻击及系统负载设置告警功能，并将报警信息以消息或邮件等形式提交给管理员。报警信息至少应包括以下内容：
a) 事件标识；
b) 事件主体；
c) 事件客体；
d) 事件发生时间。
b) 检测方法
1） 查看产品相应功能模块，验证产品是否提供了网络流量监控功能，对网络中受保护的所有网络和主机流量实时显示；
2） 查看产品相应功能模块，验证产品是否提供网络连接监控，是否对网络的所有连接数和网络中受保护的所有的主机的连接情况实时显示；
3） 查看产品相应功能模块，验证产品是否提供了系统负载监控功能，是否包括实时显示系统的CPU、内存、报文收发数据等；
4） 查看产品相应功能模块，验证产品是否支持SNMP设备监控方式；
5） 查看产品相应功能模块，验证产品是否对异常网络流量、连接、攻击及系统负载设置告警功能，并将报警信息以消息或邮件等形式提交给管理员；报警信息至少应包括以下内容：
a) 事件标识；
b) 事件主体；
c) 事件客体；
d) 事件发生时间。
c) 结果判定
1） 产品提供了网络流量监控功能，能够对网络中受保护的所有网络和主机流量提供实时显示；
2） 产品提供了网络连接监控功能，能够对网络的所有连接数和网络中受保护的所有的主机的连接情况实时显示；
3） 产品提供了系统负载监控功能，包括实时显示系统的CPU、内存、报文收发数据等；
4） 产品提供了SNMP设备监控方式；
5） 产品提供了对异常网络流量、连接、攻击及系统负载设置告警功能，并将报警信息以消息或邮件等形式提交给管理员；报警信息至少应包括以下内容：
a) 事件标识；
b) 事件主体；
c) 事件客体；
d) 事件发生时间。
1)、2）、3)、4）、5）项均满足为“符合”，1)、2）、3)、4）、5）项中有一项不满足为“不符合”。
6.2.4. 攻击类型防护
a) 检测要求
1） 应能防护各类基于流量型、连接耗尽型等网络层拒绝服务攻击，如SYN Flood、UDP Flood、ICMP Flood等；
2） 应能针对应用层拒绝服务攻击进行有效防护，如CC攻击；
3） 应能防护 典型的拒绝服务攻击，如Smurf、Teardrop、Ping Sweep、IP Spoof、IP Fragmentation Overlap、Ping of Death等。
b) 检测方法
1） 通过测试工具实施模拟拒绝服务攻击，验证产品是否能防护SYN Flood、UDP Flood、ICMP Flood等基于流量型、连接耗尽型等网络层拒绝服务攻击；
2） 通过测试工具实施应用层拒绝服务攻击，验证产品是否对应用层拒绝服务攻击进行有效防护；
3） 通过测试工具实施一些典型拒绝服务攻击，如 Smurf、Teardrop、Ping Sweep、IP Spoof、IP Fragmentation Overlap、Ping of Death，验证产品是否对典型的拒绝服务攻击行为进行有效防护。
c) 结果判定
1） 产品能防护SYN Flood、UDP Flood、ICMP Flood等各类基于流量型、连接耗尽型等网络层拒绝服务攻击；
2） 产品能防护应用层拒绝服务攻击；
3） 产品能防护等一些典型的拒绝服务攻击，如 Smurf、Teardrop、Ping Sweep、IP Spoof、IP Fragmentation Overlap、Ping of Death等。
1)、2）、3)项中有二项或全部满足为“符合”，1)、2）、3)项中有两项或全部不满足为“不符合”。
6.2.5. 流量限制防护
a) 检测要求
1） 应提供流量限制特性，用于应对突发的流量异常变化；
2） 应具备全局、单主机流量限制。
b) 检测方法
1） 通过测试工具实施异常流量攻击，验证产品是否提供流量限制特性，用于应对突发的流量异常变化；
2） 查看并验证产品是否提供了对全局、单主机流量限制的功能。
c) 结果判定
1） 产品能够对异常流量攻击进行检测并限制，能自定义流量限制阈值；
2） 产品提供了对全局、单主机流量限制的功能。
1)、2）项均满足为“符合”，1)、2）项中有一项不满足为“不符合”。
6.2.6. 高级防护功能(如适用)
a) 检测要求
1） 应实现对应用层协议高级防护（如：FTP,SMTP,POP3,HTTP等)，系统应具有应用层协议防护模块；
2） 产品应具备灵活的对自定义端口的防护设置功能；
3） 产品应具备对数据包进行深层次的过滤功能，应允许管理员根据数据包的源、目的IP，源、目的协议端口，协议类型及TCP Flag/ICMP Type/ICMP Code等特征字节定义过滤规则。
b) 检测方法
1） 通过工具实施应用层协议（如：FTP,SMTP,POP3,HTTP等)的仿真攻击测试，验证产品是否提供了应用层协议模块防护功能；
2） 查看产品功能模块并验证是否提供了对自定义端口的防护设置功能；
3） 查看并验证产品是否提供对数据包进行深层次的过滤功能模块，是否允许管理员根据数据包的源、目的IP，源、目的协议端口，协议类型或Tcp flag/ICMP Type/ICMP Code等特征字节定义过滤规则。
c) 结果判定
1） 产品提供了应用层协议模块防护功能，能够对应用层协议（如：FTP,SMTP,POP3,HTTP等) 攻击提供防护；
2） 产品提供了对自定义端口的防护设置功能；
3） 产品提供了对数据包进行深层次的过滤功能，能够允许管理员根据数据包的源、目的IP，源、目的协议端口，协议类型及TCP Flag/ICMP Type/ICMP Code等特征字节定义过滤规则。
1） 或2)项有一项符合或者两项都符合并且3)项符合为“符合”，其余情况为“不符合”。
6.2.7. 系统管理
a) 检测要求
抗拒绝服务系统应具备灵活的配置管理功能，支持本地管理和远程管理，系统应具备同步网络时间的功能。
b) 检测方法
1） 查看抗拒绝服务系统的管理方式（如：Console口、Telnet、SSH、HTTP、HTTPS、SNMP、产品专用的管理程序），是否支持本地管理和远程管理方式，并进行验证；
2） 查看抗拒绝服务系统本地和远程管理是否必须通过口令认证；
3） 查看抗拒绝服务系统是否提供了时间同步功能。
c) 结果判定
1） 抗拒绝服务系统支持本地的管理方式；
2） 抗拒绝服务系统支持远程管理方式；
3） 以上两种管理方式，管理员都需通过口令验证等身份鉴别措施；
4） 抗拒绝服务系统应提供时间同步功能。
1) 或2)项有一项符合或者两项都符合并且3)、4）项符合为“符合”，其余情况为“不符合”。
6.2.8. 产品升级
a) 检测要求
抗拒绝服务系统应支持手动或者自动的方式进行产品升级，对规则库、策略文件以及服务程序等进行更新。
b) 检测方法
1） 审查产品说明书描述是否支持产品升级；
2） 按照产品说明书，测试产品是否可实施手动或自动升级。
c) 结果判定
产品提供手动或者自动升级功能，按照说明可以完成产品升级，结果为“符合”，否则为“不符合”。
6.2.9. 高可用性
a) 检测要求
1） 在串接方式下应具备硬件或者软件Bypass功能，能够在断电、硬件故障等异常情况下保持网络连通。
2） 抗拒绝服务系统产品可支持双机热备、负载均衡等高可用性功能。
b) 检测方法
1） 审查产品说明书描述是否具备硬件Bypass或者软件Bypass功能；在抗拒绝服务系统运行过程中，切断产品电源，模拟断电等硬件故障，测试抗拒绝服务系统在断电状态下是否能够保持网络连通。
2） 抗拒绝服务系统产品如支持双机热备、负载均衡，可配置双机热备、负载均衡模式，并验证其功能实现。
c) 结果判定
1)项符合为“符合”，1)项不符合为“不符合”。
6.3. 性能测试
6.3.1. 测试环境与工具
a) 测试环境图
图2 吞吐量性能检测环境图
b) 测试工具：?
网络层性能测试设备
6.3.2. 吞吐量
a) 检测要求
测试设备或系统在没有丢包情形下的最大传送数据的速率。
b) 检测方法
1） 在不开启防护策略的情况下，使用网络层测试设备，测试进行UDP双向吞吐量测试；
2） 在开启缺省防护策略的情况下，使用网络层测试设备，进行UDP双向吞吐量测试；
3） 测试参数配置：
（1） 帧长：64、512、1518字节；
（2） 方向：双向；
（3） 性能测试仪端口状态：100M或者1000M、全双工、协商状态。
（4） 其它参数：试验持续时间：60秒，试验次数：3次，初始负载：100％，最大负载：100％。
c) 结果判定
记录检测结果。
6.4. 安全性测试
6.4.1. 测试环境与工具
a) 测试环境图
图3 安全性检测环境图
b) 测试工具：
? 应用层渗透性测试工具
? 拒绝服务测试工具
? 网络协议分析工具
6.4.2. 安全审计
6.4.2.1. 审计数据产生（FAU_GEN.1）
a) 检测要求
1） 抗拒绝服务系统应对以下事件生成审计记录：
（1） 攻击事件、攻击类型、攻击特征、攻击来源等信息；
（2） 用户的创建、修改、删除、权限分配等管理行为；
（3） 任何使用鉴别机制的行为；
（4） 鉴别失败的次数超过给定门限导致会话终止；
（5） 企图修改待测目标安全功能配置参数的行为（无论成功与否）。
2） 抗拒绝服务系统每个审计记录中应记录下列信息：
（1） 事件发生的日期、时间；
（2） 事件的类型；
（3） 主体身份；
（4） 客体身份；
（5） 事件的结果（包括成功或失败）。
b) 检测方法
1） 系统管理员实施对用户的管理操作，并设置相应的角色和权限；
2） 使用不同角色用户模拟对产品不同模块进行访问、运行、修改、关闭以及重复失败尝试等相关操作。审查审计记录的正确性；
3） 审查审计记录的对象是否全面，是否满足检测要求1）中的对象事件；
4） 审查审计记录是否全面，是否满足检测要求2）中的要素。
c) 结果判定
审计内容和审计记录信息完全符合1)、2)项要求为“符合”；无审计为“不符合”。
6.4.2.2. 审计查阅（FAU_SAR.1）
a) 检测要求
1） 抗拒绝服务系统应为授权管理员提供从审计记录中读取全部审计信息的功能；
2） 抗拒绝服务系统应以便于用户理解的方式提供审计记录。
b) 检测方法
1） 审查产品功能是否为授权管理员提供从审计记录中读取全部审计信息的功能；
2） 查看抗拒绝服务系统审计信息的提供方式和格式。
c) 结果判定
1） 抗拒绝服务系统应为授权管理员提供从审计记录中读取全部审计信息的功能；
2） 审计查阅以用户易理解的方式和格式提供。
1)、2)项符合为“符合”；否则为“不符合”。
6.4.2.3. 可选审计查阅（FAU_SAR.3）
a) 检测要求
抗拒绝服务系统应根据主体ID（标识符）、客体ID、日期、时间以及这些参数的逻辑组合等参数提供对审计数据进行搜索、分类或排序的能力。
b) 检测方法
1） 测试抗拒绝服务系统安全功能是否自身提供了审计查阅工具，能够按照主体ID（标识符）、客体ID、日期、时间对审计数据进行单一条件查找和排序；
2） 测试是否能够按照主体ID（标识符）、客体ID、日期、时间对审计数据进行组合条件查找和排序；
3） 检查选择查阅的结果是否完全正确。
c) 结果判定
1） 自身提供了审计查阅工具，能够按照主体ID（标识符）、客体ID、日期、时间对审计数据进行单一条件查找和排序；
2） 能够按照主体ID（标识符）、客体ID、日期、时间进行对审计数据进行组合条件查找和排序；
3） 选择查阅的结果完全正确。
1)、3)项均满足为“符合”，1)、3)项中有一项不满足为“不符合”。
6.4.2.4. 防止审计数据丢失（FAU_STG.4）
a) 检测要求
1） 抗拒绝服务系统的安全功能应把生成的审计记录存储于一个永久性的记录中或导出到审计日志服务器；
2） 对因故障或存储耗竭而导致审计数据丢失的最大审计存储容量，抗拒绝服务系统的开发者应提供相应的分析结果；
3） 一旦审计存储容量达到事先规定的警戒值，应能发送警告信息，并保证在授权管理员所采取的审计行为以外，防止其他可审计行为的出现。
b) 检测方法
1） 测试抗拒绝服务系统的安全功能是否将生成的审计记录存储于一个永久性的记录中，或支持将审计日志导出到日志服务器；
2） 对因故障或存储耗竭而导致审计数据丢失的最大审计存储容量，验证抗拒绝服务系统的开发者是否提供相应的分析结果；
3） 模拟审计容量大量消耗相关的操作，测试抗拒绝服务系统是否在审计存储容量达到事先规定的警戒值时发出警告信息，并保证在授权管理员所采取的审计行为以外，防止其他可审计行为的出现。
c) 结果判定
1） 审计记录存储于一个永久性的记录中，或支持将审计日志导出到日志服务器；
2） 产品应支持自动存档机制或支持授权管理员的导出备份功能，从而能够防止由于故障和攻击可能造成的意外丢失；
3） 审计容量达到警戒值时发出警告信息，能够保证在授权管理员所采取的审计行为以外，防止其他可审计行为的出现。
1)、2)、3)项均满足为“符合”；1)、2)、3)中有一项不满足为“不符合”。
6.4.3. 标识和鉴别
6.4.3.1. 鉴别的时机（FIA_UAU.1）
a) 检测要求
1） 在用户被鉴别前，TSF应只允许用户执行输入登录信息、查看登录帮助等操作；
2） 在允许执行代表该用户的任何其它TSF的动作前，TSF应要求每个用户都已被成功鉴别。
b) 检测方法
1） 设置多个授权管理员，分别以所有这些授权管理员的身份登录；
2） 测试是否在所有授权管理员（应包括所有角色）请求执行的任何操作之前，抗拒绝服务系统的安全功能确保对每个授权管理员都进行了鉴别。
c) 结果判定
1） 在用户执行任何与安全功能相关的操作之前应对用户进行鉴别；
2） 登录之前允许做的操作，应仅限于输入登录信息、查看登录帮助等操作。
1)、2)项均符合为“符合”；1)、2)项有一项不符合为“不符合”。
6.4.3.2. 用户属性定义（FIA_ATD.1）
a) 检测要求
抗拒绝服务系统应为每一个用户保存安全属性表，属性应包括：用户标识、鉴别数据（如口令）、授权信息或用户组信息、其他安全属性等。
b) 检测方法
1） 抗拒绝服务系统应当维护授权角色的安全属性列表。
2） 对用户安全属性进行修改，验证有效性。
c) 结果判定
1） 制定的授权管理员能够维护授权角色的安全属性列表（包括创建、修改和删除等）；
2） 用户安全属性值的修改能够正确、有效。所有用户能够依据其安全属性进行相应的操作。
1)、2)均满足为“符合”；否则为“不符合”。
6.4.3.3. 鉴别失败处理（FIA_AFL.1）
a) 检测要求
在经过一定次数的鉴别失败后，抗拒绝服务系统安全功能应能终止进行登录尝试主机建立会话的过程。最多失败次数仅由授权管理员设定。
b) 检测方法
1） 以错误的用户名－口令登录，在一定次数的鉴别失败后，测试抗拒绝服务系统是否终止了进行登录尝试主机建立会话的过程（例如：关闭身份鉴别的对话界面、锁定帐户等）；
2） 检测该产品是否提供最多失败次数的设定功能，并分别使用授权管理员和普通用户的身份登录尝试，验证所设定的次数是否有效；
3） 检测该产品“最多失败登录次数”是否仅由授权管理员设定。
c) 结果判定
1） 鉴别失败后，抗拒绝服务系统能够终止登录尝试主机建立会话的过程；该“最多失败次数”可以是产品在设计时默认的，也可以是由授权管理员设置的，此两种情况均可评定为本条满足。
1)满足为“符合”；1)项不满足为“不符合”。
6.4.4. 安全管理
6.4.4.1. 安全功能行为的管理（FMT_MOF.1）
a) 检测要求
抗拒绝服务系统应仅限于已识别了的指定的授权角色对产品功能具有启用、禁止、修改的能力。
b) 检测方法
1） 检查抗拒绝服务系统的安全功能是否明确规定仅限于指定的授权角色对系统的功能具有启用、禁止、修改的能力；
2） 检查指定的授权角色对系统的功能进行启用、禁止、修改等操作前，是否先登录才能操作。
c) 结果判定
1） 抗拒绝服务系统应仅限于识别了的指定的授权角色对系统的功能进行启用、禁止、修改；
2） 指定的授权角色对抗拒绝服务系统的功能进行启用、禁止、修改等操作前，应先登录才能操作。
1)、2)项均符合为“符合”；否则为“不符合”。
6.4.4.2. 安全属性管理（FMT_MSA.1）
a) 检测要求
抗拒绝服务系统应执行访问控制策略或信息流控制策略，以限制已识别了的授权角色查询、修改和删除安全属性的能力。
b) 检测方法
1） 查看产品所设定的安全属性组（如：用户名、口令、帐户有效性、帐户过期时间和口令过期时间等）；
2） 对用户的安全属性进行查询、创建、修改和删除，并作相应验证；
3） 验证是否仅指定的授权管理员（如：系统管理员）对安全属性具有管理能力。
c) 结果判定
1） 产品能够提供对安全属性进行查询、创建、修改和删除的功能；
2） 产品仅允许指定的授权管理员对安全属性具有管理能力。
1)、2)均满足为“符合”；否则为“不符合”。
6.4.4.3. 安全角色（FMT_SMR.1）
a) 检测要求
1） 抗拒绝服务系统应维护已标识的授权角色；
2） 抗拒绝服务系统应能够将用户与角色关联起来。
b) 检测方法
1） 查看产品说明文档中关于安全管理角色的划分和描述；
2） 查验是否允许定义多个角色或对角色进行分级，使不同级别的管理角色具有不同的管理权限；
3） 将用户与角色关联起来，并进行验证；
4） 检测未授予安全管理角色的普通用户是否能够执行安全管理功能相关操作。
c) 结果判定
1） 产品支持定义多个角色或对角色进行分级，使不同级别的管理角色具有不同的管理权限；
2） 用户能够与角色进行关联，从而实施相应的管理功能；
3） 未授予安全管理角色的普通用户不能执行安全管理功能相关操作。
1)、2)、3)均满足为“符合”；否则为“不符合”。
6.4.4.4. TSF数据的管理（FMT_MTD.1）
a) 检测要求
抗拒绝服务系统应仅允许授权管理员控制TSF数据的管理。
b) 检测方法
1） 验证授权管理员用户对TSF数据的管理能力（TSF数据包括审计报警信息、时钟、系统配置、重鉴别的阈值、告警参数和其它TSF配置参数等）；
2） 验证仅允许指定的授权管理员实施TSF数据的管理。
c) 结果判定
1） 产品能够提供对TSF数据（包括审计报警信息、时钟、系统配置、重鉴别的阈值、告警参数和其它TSF配置参数等）的管理能力；
2） 仅允许指定的授权管理员（如：安全策略管理员）实施TSF数据的管理。
1)、2)均满足为“符合”；否则为“不符合”。
6.4.5. TSF保护
6.4.5.1. 传送过程中TSF间的保密性（FPT_ITC.1）
a) 检测要求
TSF应保护所有从抗拒绝服务系统传送到远程管理主机的TSF数据在传送过程中不会被未授权泄漏。
b) 检测方法
1） 审查产品说明手册，当产品需要通过网络进行管理时，是否能提供对管理信息进行保密传输的功能；
2） 使用网络协议分析工具，对网络传输的管理信息进行截包分析并加以验证。
c) 结果判定
产品能够对管理信息进行保密传输即1），2）均符合为“符合”，否则为“不符合”。
6.4.5.2. 可信恢复（FPT_RCV.2.2）
a) 检测要求
当抗拒绝服务系统的发生服务中断，后在人工干预的情况下或者无人工干预自动恢复到安全状态。
b) 检测方法
1） 人为造成系统关键功能失效（包括抗拒绝服务系统与相连的网络设备之间网络通信断开；抗拒绝服务系统电源关闭等）；
2） 验证系统是否提供系统关键功能的自动恢复或者人工干预恢复功能。
c) 结果判定
当发生抗拒绝服务系统与相连的网络设备之间网络通信断开、抗拒绝服务系统电源关闭等意外故障，故障排除后，抗拒绝服务系统能够自动或者在人工干预的情况下恢复到未发生故障之前的状态的为“符合”，否则为“不符合”。
6.5. 保证要求测试
6.5.1. 配置管理
6.5.1.1. 配置项
a) 检测要求
开发者应执行以下内容：
1） 开发者应为抗拒绝服务系统产品提供一个参照号；
2） 开发者应使用一个配置管理系统；
3） 开发者应提供配置管理文档。
开发者执行的内容应满足以下要求：
1） 抗拒绝服务系统产品参照号对抗拒绝服务系统产品的每一个版本应是唯一的；
2） 应该给抗拒绝服务系统产品标记上参照号；
3） 配置管理文档应包括一个配置清单；
4） 配置清单应唯一标识组成抗拒绝服务系统产品的所有配置项；
5） 配置清单应描述组成抗拒绝服务系统产品的配置项；
6） 配置管理文档应描述用于唯一标识抗拒绝服务系统产品所包含配置项的方法；
7） 配置管理系统应唯一标识抗拒绝服务系统产品所包含的所有的配置项。
评估者应执行以下内容：
评估者应确认开发者所提供的信息应满足对开发者的要求。
b) 检测方法
1） 检查抗拒绝服务系统产品参照号对抗拒绝服务系统产品的每一个版本是否是唯一的；
2） 检查抗拒绝服务系统产品上是否标记了参照号；
3） 检查开发者提供的配置管理文档是否包括配置清单；
4） 检查配置清单中是否唯一标识组成抗拒绝服务系统产品的所有配置项；
5） 检查配置清单中是否描述组成抗拒绝服务系统产品的配置项；
6） 检查配置管理文档是否包含对配置项给出唯一标识的方法的描述；
7） 检查产品是否使用了配置管理系统，并且检查配置管理系统是否对所有的配置项做出唯一的标识。
c) 结果判定
1） 开发者为抗拒绝服务系统产品提供了参照号，且参照号满足要求；
2） 开发者提供了配置管理文档，且文档满足要求；
3） 开发者使用了配置管理系统，且现场检查的配置项在配置管理系统中均做出唯一的标识。
1）-3）项均满足的为“符合”，其他情况为“不符合”。
6.5.2. 交付与运行
6.5.2.1. 交付程序
a) 检测要求
开发者应执行以下内容：
1） 开发者应将把TOE及其部分交付给用户的程序文档化；
2） 开发者应使用交付程序。
开发者执行的内容应满足以下要求：
交付文档应描述，在向用户方分发抗拒绝服务系统产品版本时，用以维护其安全性所必需的所有程序。
评估者应执行以下内容：
评估者应确认开发者所提供的信息应满足对开发者的要求。
b) 检测方法
1） 检查抗拒绝服务系统产品交付文档中是否包含了产品分发程序描述，分发程序是否提供了维护安全性所必需的程序；
2） 检查开发者是否提供了使用交付程序的证据。
c) 结果判定
1） 抗拒绝服务系统产品交付文档中包含了产品分发程序描述，分发程序提供了维护安全性所必需的程序；
2） 开发者提供了使用交付程序的证据。
1）-2）项满足的为“符合”；其他情况为“不符合”。
6.5.2.2. 安装、生成和启动程序
a) 检测要求
开发者应执行以下内容：
开发者应将TOE安全地安装、生成和启动必需的程序文档化。
开发者执行的内容应满足以下要求：
安装、生成和启动文档应描述抗拒绝服务系统产品安全地安装、生成和启动所必需的所有步骤。
评估者应执行以下内容：
评估者应确认开发者所提供的信息应满足对开发者的要求。
b) 检测方法
1） 检查开发者是否提供了安装、生成和启动产品所必需的程序文档；
2） 使用安装、生成和启动程序文档执行程序中规定的操作，检查操作能否正确完成。
c) 结果判定
1） 开发者提供了安装、生成和启动产品所必需的程序文档；；
2） 按照安装、生成和启动相关程序文档能够正确完成相关操作。
1）-2）项满足的为“符合”；其他情况为“不符合”。
6.5.3. 开发
6.5.3.1. 非形式化功能规范
a) 检测要求
开发者应提供以下文档：
开发者应提供一个功能规范。
开发者提供的文档应满足以下要求：
1） 功能规范应使用非形式化风格来描述抗拒绝服务系统产品安全功能与其外部接口；
2） 功能规范应当是内在一致的；
3） 功能规范应描述所有外部抗拒绝服务系统产品安全功能接口的用途与使用方法，适当时应提供效果、例外情况和错误消息的细节；
4） 功能规范应完备地表示抗拒绝服务系统产品安全功能。
评估者应执行以下内容：
评估者应确认开发者所提供的信息应满足对开发者的要求。
b) 检测方法
1） 检查功能规范是否以非形式化形式对抗拒绝服务系统产品的安全功能和外部接口进行描述；
2） 检查功能规范是否内在一致；
3） 检查功能规范是否对外部抗拒绝服务系统产品安全功能接口的用途与使用方法进行了描述，是否适当描述了效果、例外情况和错误消息的细节；
4） 检查功能规范是否完备地表示了抗拒绝服务系统产品的安全功能。
c) 结果判定
1） 开发者提供了功能规范文档；
2） 功能规范文档的内容满足要求。
1）-2）项满足的为“符合”；其他情况为“不符合”。
6.5.3.2. 描述性高层设计
a) 检测要求
开发者应提供以下文档：
开发者应提供抗拒绝服务系统产品安全功能的高层设计。
开发者提供的文档应满足以下要求：
1） 高层设计的表示应是非形式化的；
2） 高层设计应是内在一致的；
3） 高层设计应按子系统描述抗拒绝服务系统产品安全功能的结构；
4） 高层设计应描述每个抗拒绝服务系统产品安全功能子系统所提供的安全功能性；
5） 高层设计应当标识抗拒绝服务系统产品安全功能要求的任何基础性的硬件、固件或软件，以及在这些硬件、固件或软件中实现的支持性保护机制所提供功能的一个表示；
6） 高层设计应标识抗拒绝服务系统产品安全功能子系统的所有接口；
7） 高层设计应标识抗拒绝服务系统产品安全功能子系统的哪些接口是外部可见的。
评估者应执行以下内容：
评估者应确认开发者所提供的信息应满足对开发者的要求。
b) 检测方法
1） 检查高层设计是否以非形式化的风格表示；
2） 检查高层设计是否内在一致的；
3） 检查高层设计是否按子系统描述抗拒绝服务系统产品安全功能的结构；
4） 检查高层设计是否描述了每个抗拒绝服务系统产品安全功能子系统所提供的安全功能性；
5） 检查高层设计是否标识了抗拒绝服务系统产品安全功能要求的任何基础性的硬件、固件或软件，以及在这些硬件、固件或软件中实现的支持性保护机制所提供功能的一个表示；
6） 检查高层设计是否标识了抗拒绝服务系统产品安全功能子系统的所有接口；
7） 检查高层设计是否标识了抗拒绝服务系统产品安全功能子系统的哪些接口是外部可见的。
c) 结果判定
1） 开发者提供了高层设计文档；
2） 高层设计文档的内容满足要求。
1）-2）项满足的为“符合”；其他情况为“不符合”。
6.5.3.3. 非形式化对应性证实
a) 检测要求
开发者应提供以下文档：
开发者应提供一个所提供抗拒绝服务系统产品安全功能表示的所有相邻对之间对应性的分析。
开发者提供的文档应满足以下要求：
对于所提供的抗拒绝服务系统产品安全功能表示（如抗拒绝服务系统产品功能规范、高层设计等）的每个相邻对，分析应证实，较为抽象的抗拒绝服务系统产品安全功能表示的所有相关安全功能都在较不抽象的安全功能表示中得到正确且完备地细化。
评估者应执行以下内容：
评估者应确认开发者所提供的信息应满足对开发者的要求。
b) 检测方法
1） 检查对应性分析文档，检查抗拒绝服务系统产品的功能规范是否正确完备的表示了安全目标的概要规范中的安全功能；
2） 检查对应性分析文档，检查产品的高层设计是否正确完备的表示了功能规范。
c) 结果判定
1） 开发者提供了相关的对应性分析文档；
2） 对应性分析文档的内容满足要求。
1）-2）项满足的为“符合”；其他情况为“不符合”。
6.5.4. 指导性文档
6.5.4.1. 管理员指南
a) 检测要求
开发者应提供以下文档：
开发者应提供针对系统管理员的管理员指南。
开发者提供的文档应满足以下要求：
1） 管理员指南应描述抗拒绝服务系统产品管理员可使用的管理功能和接口；
2） 管理员指南应描述如何以安全的方式管理抗拒绝服务系统产品；
3） 管理员指南应包含一些关于安全处理环境中应被控制的功能和特权的警示信息；
4） 管理员指南应描述所有关于与抗拒绝服务系统产品运行有关的用户行为的假设；
5） 管理员指南应描述所有受管理员控制的安全参数，适当时应指明安全值；
6） 管理员指南应描述每一种与需要执行的管理功能有关的安全相关事件，包括改变抗拒绝服务系统产品安全功能所控制实体的安全特性；
7） 管理员指南应与供评估的所有其他文档一致；
8） 管理员指南应描述所有与管理员有关的IT环境安全要求。
评估者应执行以下内容：
评估者应确认开发者所提供的信息应满足对开发者的要求。
b) 检测方法
1） 检查管理员指南是否描述了抗拒绝服务系统产品管理员可使用的管理功能和接口；
2） 检查管理员指南是否描述了如何以安全的方式管理抗拒绝服务系统产品；
3） 检查管理员指南是否包含了一些关于安全处理环境中应被控制的功能和特权的警示信息；
4） 检查管理员指南是否描述了所有关于与抗拒绝服务系统产品运行有关的用户行为的假设；
5） 检查管理员指南是否描述了所有受管理员控制的安全参数，适当时应指明安全值；
6） 检查管理员指南是否描述了每一种与需要执行的管理功能有关的安全相关事件，包括改变抗拒绝服务系统产品安全功能所控制实体的安全特性；
7） 检查管理员指南是否与供评估的所有其他文档一致；
8） 检查管理员指南是否描述了所有与管理员有关的IT环境安全要求。
c) 结果判定
1） 开发者提供了管理员指南文档；
2） 管理员指南文档的内容满足要求。
1）-2）项满足的为“符合”；其他情况为“不符合”。
6.5.4.2. 用户指南
a) 检测要求
开发者应提供以下文档：
开发者应提供用户指南。
开发者提供的文档应满足以下要求：
1） 用户指南应描述抗拒绝服务系统产品的非管理用户可使用的功能和接口；
2） 用户指南应描述抗拒绝服务系统产品所提供的用户可访问安全功能的使用；
3） 用户指南应包含一些关于安全处理环境中应被控制的用户可访问功能和特权的警示信息；
4） 用户指南应清晰地阐述抗拒绝服务系统产品安全运行所必需的所有用户职责，包括与抗拒绝服务系统产品安全环境陈述中可找到的与关于用户行为的假设有关的那些职责；
5） 用户指南应与供评估的所有其他文档保持一致；
6） 用户指南应描述所有与用户有关的IT环境安全要求。
评估者应执行以下内容：
评估者应确认开发者所提供的信息应满足对开发者的要求。
b) 检测方法
1） 检查用户指南是否描述了抗拒绝服务系统产品的非管理用户可使用的功能和接口；
2） 用户指南是否描述了抗拒绝服务系统产品所提供的用户可访问安全功能的使用；
3） 用户指南是否包含一些关于安全处理环境中应被控制的用户可访问功能和特权的警示信息；
4） 用户指南是否清晰地阐述了抗拒绝服务系统产品安全运行所必需的所有用户职责，包括与抗拒绝服务系统产品安全环境陈述中可找到的与关于用户行为的假设有关的那些职责；
5） 用户指南是否与供评估的所有其他文档保持一致；
6） 用户指南是否描述了所有与用户有关的IT环境安全要求。
c) 结果判定
1） 开发者提供了用户指南文档；
2） 用户指南文档的内容满足要求。
1）-2）项满足的为“符合”；其他情况为“不符合”。
6.5.5. 测试
6.5.5.1. 覆盖证据
a) 检测要求
开发者应提供以下文档：
开发者应提供测试覆盖的证据。
开发者提供的文档应满足以下要求：
测试覆盖的证据中应说明测试文档中所标识的测试与功能规范中所描述的抗拒绝服务系统产品安全功能之间的对应性。
评估者应执行以下内容：
评估者应确认开发者所提供的信息应满足对开发者的要求。
b) 检测方法
检查相关测试覆盖的证据文档、测试文档和功能规范文档，确认测试覆盖的证据文档对测试文档中所标识的测试与功能规范中所描述的抗拒绝服务系统产品安全功能之间的对应性进行了描述，且描述内容准确。
c) 结果判定
1） 开发者提供了测试覆盖的相关证据；
2） 测试覆盖的相关证据的内容满足要求。
1）-2）项满足的为“符合”；其他情况为“不符合”。
6.5.5.2. 功能测试
a) 检测要求
开发者应执行以下内容：
1） 开发者应测试抗拒绝服务系统产品安全功能，并文档化测试结果；
2） 开发者应提供测试文档。
开发者执行的内容应满足以下要求：
1） 测试文档应包括测试计划、测试程序描述、预期的测试结果和实际的测试结果；
2） 测试计划应标识要测试的安全功能，并描述要执行的测试的目标；
3） 测试程序描述应标识要执行的测试，应描述每个安全功能的测试脚本，这些脚本应包括对于其他测试结果的任何顺序依赖性；
4） 预期的测试结果应指出测试成功执行后的预期输出；
5） 开发者执行测试所得到的测试结果应证实每个被测试的安全性功能都按照规定运转。
评估者应执行以下内容：
评估者应确认开发者所提供的信息应满足对开发者的要求。
b) 检测方法
1） 检查开发者提供的测试文档是否包括测试计划、测试程序描述、预期的测试结果和实际的测试结果；
2） 检查测试计划是否标识了要测试的安全功能，并描述了要执行的测试的目标；
3） 检查测试程序描述是否标识了要执行的测试，是否描述了每个安全功能的测试脚本，这些脚本是否包括了对于其他测试结果的任何顺序依赖性；
4） 检查预期的测试结果是否指出了测试成功执行后的预期输出；
5） 检查开发者执行测试所得到的测试结果是否证实了每个被测试的安全性功能都按照规定运转。
c) 结果判定
1） 开发者提供了测试文档；
2） 测试文档的内容满足要求。
1）-2）项满足的为“符合”；其他情况为“不符合”。
6.5.5.3. 独立测试——抽样
a) 检测要求
开发者应执行以下内容：
开发者应提供用于测试的抗拒绝服务系统产品。
开发者执行的内容应满足以下要求：
1） 开发者提供的抗拒绝服务系统产品应适合测试；
2） 开发者应提供一组相当的资源，用于开发者的抗拒绝服务系统产品安全功能的功能测试。
评估者应执行以下内容：
1） 评估者应确认开发者所提供的信息应满足对开发者的要求；
2） 评估者应适当地测试抗拒绝服务系统产品安全功能的一个子集，以确认抗拒绝服务系统产品按照规定运行；
3） 评估者应执行测试文档中的一个测试样本，以验证开发者的测试结果。
b) 检测方法
1） 检查开发者提供的抗拒绝服务系统产品是否适合测试；
2） 检查开发者是否为抗拒绝服务系统产品测试提供了必要的资源；
3） 适当地测试抗拒绝服务系统产品安全功能的一个子集，以确认抗拒绝服务系统产品按照规定运行；
4） 执行测试文档中的一个测试样本，检查测试结果是否与开发者的测试结果一致。
c) 结果判定
1） 开发者提供的抗拒绝服务系统产品适合测试；
2） 开发者为抗拒绝服务系统产品测试提供了必要的资源；
3） 通过对抗拒绝服务系统产品的测试，抗拒绝服务系统产品能够按照规定运行，测试结果与开发者的测试结果一致。
1）-3）项满足的为“符合”；其他情况为“不符合”。
6.5.6. 脆弱性评定
6.5.6.1. TOE安全功能强度评估
a) 检测要求
开发者应执行以下内容：
开发者应对ST中所标识的每个具有抗拒绝服务系统产品安全功能强度声明的安全机制进行抗拒绝服务系统产品安全功能强度分析。
开发者执行的内容应满足以下要求：
1） 对于每个具有抗拒绝服务系统产品安全功能强度声明的安全机制，抗拒绝服务系统产品安全功能强度分析应说明该机制达到或超过PP/ST中定义的最低强度级别；
2） 对于每个具有抗拒绝服务系统产品安全功能强度声明的安全机制，抗拒绝服务系统产品安全功能强度分析应说明该机制达到或超过PP/ST中定义的特定功能强度度量。
评估者应执行以下内容：
评估者应确认开发者所提供的信息应满足对开发者的要求。
b) 检测方法
1） 检查开发者提供的抗拒绝服务系统产品安全功能强度分析文档，查看对于每个具有抗拒绝服务系统产品安全功能强度声明的安全机制，是否说明了该机制达到或超过PP/ST中定义的最低强度级别；
2） 查看对于每个具有抗拒绝服务系统产品安全功能强度声明的安全机制，抗拒绝服务系统产品安全功能强度分析文档是否说明了该机制达到或超过PP/ST中定义的特定功能强度度量。
c) 结果判定
1） 开发者提供了功能强度分析文档；
2） 功能强度分析文档的内容满足要求。
1）-2）项满足的为“符合”；其他情况为“不符合”。
6.5.6.2. 开发者脆弱性分析
a) 检测要求
开发者应执行以下内容：
1） 开发者应执行脆弱性分析；
2） 开发者应提供脆弱性分析文档。
开发者执行的内容应满足以下要求：
1） 脆弱性分析文档应描述为搜索用户能违反抗拒绝服务系统产品安全策略的明显方法而执行的抗拒绝服务系统产品可交付材料分析；
2） 脆弱性分析文档应描述对明显的脆弱性的处置；
3） 脆弱性分析文档应针对所有已标识的脆弱性，说明脆弱性不能在抗拒绝服务系统产品的预期使用环境中被利用。
评估者应执行以下内容：
1） 评估者应确认开发者所提供的信息应满足对开发者的要求；
2） 评估者应在开发者脆弱性分析的基础上实施穿透性测试，以确保明显的脆弱性都已被处理。
b) 检测方法
1） 检查脆弱性分析文档是否描述了为搜索用户能违反抗拒绝服务系统产品安全策略的明显方法而执行的抗拒绝服务系统产品可交付材料分析；
2） 检查脆弱性分析文档是否描述了对明显的脆弱性的处置；
3） 检查脆弱性分析文档是否针对所有已标识的脆弱性，说明脆弱性不能在抗拒绝服务系统产品的预期使用环境中被利用；
4） 在开发者脆弱性分析的基础上实施穿透性测试，以确保是否明显的脆弱性都已被处理。
c) 结果判定
1） 开发者提供了脆弱性分析文档；
2） 脆弱性分析文档的内容满足要求；
3） 通过实施的穿透性测试确认明显的脆弱性都已被处理。
1）-3）项满足的为“符合”；其他情况为“不符合”。
