ISO/IEC 15408系列标准(Common Criteria, CC)是信息技术安全评估的权威国际基准。其中第2部分——ISO/IEC 15408-2:2009(2014确认版)——专门定义了安全功能组件(Security Functional Components),为描述和评估IT产品的安全功能提供了结构化的需求目录。本文章将全面解析该标准的核心内容、应用要点及其在CC评估体系中的关键作用。
1. 标准概况与适用范围
ISO/IEC 15408-2:2009(2014确认版)是Common Criteria系列标准的有机组成部分。该系列由以下部分构成:
- 第1部分(ISO/IEC 15408-1):简介和通用模型
- 第2部分(ISO/IEC 15408-2):安全功能组件
- 第3部分(ISO/IEC 15408-3):安全保障组件
第2部分的主要作用是为评估对象(TOE, Target of Evaluation)的安全功能需求提供标准化构件。这些构件以类(Class)、族(Family)、组件(Component)的分层结构组织,每个组件对应一个具体的安全功能需求项。
适用范围:
- 适用于定义保护轮廓(Protection Profile, PP)和安全目标(Security Target, ST)中的安全功能需求。
- 适用于IT产品或系统的开发者、评估者、用户以及监管机构,用于描述、分析和评估产品的安全功能。
- 所有类型的IT产品(如操作系统、防火墙、智能卡、数据库等)均可使用该标准的功能组件来表述其安全功能。
技术要点: 在实际使用中,安全功能组件允许迭代(iteration)、赋值(assignment)、选择(selection)和细化(refinement),以适应不同产品的具体实现。这一机制大大增强了标准组件的灵活性,同时又保持了需求的标准化表达。
2. 主要技术内容与要求
ISO/IEC 15408-2:2009(2014确认版)将安全功能需求划分为11个类(Class),每个类下设若干族(Family),族内再包含一个或多个组件(Component)。每个组件由明确的组件层次(如“FAU_GEN.1 审计数据产生”)、依赖关系以及管理需求组成。
2.1 安全功能需求分类概览
| 类编号 | 类名称 | 说明 | 族数量(示例) |
| FAU | 安全审计 | 审计记录的产生、存储、保护与分析 | 6 |
| FCO | 通信 | 原发抗抵赖与接收抗抵赖 | 4 |
| FCS | 密码支持 | 密钥管理、密码运算等 | 5 |
| FDP | 用户数据保护 | 访问控制策略、信息流控制、存储完整性等 | 15 |
| FIA | 标识与鉴别 | 用户标识、鉴别机制、失败处理等 | 8 |
| FMT | 安全管理 | 安全属性的管理、数据管理功能、角色定义等 | 11 |
| FPR | 隐私 | 匿名、假名、不可关联性等 | 6 |
| FPT | TOE保护 | TSF自检、域隔离、时间戳、可信恢复等 | 12 |
| FRU | 资源利用 | 容错、服务优先级、资源分配 | 3 |
| FTA | TOE访问 | 会话锁定、访问历史、限制登录等 | 6 |
| FTP | 可信路径/信道 | TSF与用户间的可信路径,TSF与其他IT实体间的可信信道 | 4 |
标准实施的益处: 使用标准化的功能组件能够减少需求描述的歧义,提高PP/ST之间的可比性,并且使得不同评估机构或不同产品之间的安全等级(EAL)评价更加一致。
2.2 组件结构与依赖关系
每个安全功能组件都包含以下要素:
- 组件标识与层次:例如“FIA_UAU.1 鉴别时机(Timing of authentication)”。
- 依赖关系(Dependencies):列出使用该组件前必须满足的其他组件(如FIA_UAU.1依赖FIA_UID.1 用户标识)。
- 管理需求(Management):提示安全管理功能中需考虑的操作。
- 可操作项:赋值、选择、细化、迭代的具体说明。
这种结构化的依赖关系使得需求集合的完整性验证成为可能,避免遗漏关键功能。
3. 实施与应用要点
在编写保护轮廓(PP)或安全目标(ST)时,选择适当的功能组件并正确应用它们的机制是确保评估顺利进行的关键。
3.1 选择组件的流程
- 根据产品的安全环境(资产、威胁、假设)确定安全功能需求。
- 从15408-2的分类中选择匹配的类、族和组件。
- 对每个所选组件,检查并满足其依赖关系,必要时补充额外组件。
- 对组件中的赋值、选择等操作进行具体化(如“对审计事件列表进行赋值”)。
- 将定制后的组件整合进PP/ST的功能需求部分。
重要注意事项: 常见错误包括遗漏依赖关系导致功能需求集不完整,或过度使用细化改变了组件原本的安全含义。根据CC评估方法(ISO/IEC 18045),对组件的任何细化必须严格限制且不改变其预期安全属性,否则可能导致评估失败。
3.2 与其他标准的关系
ISO/IEC 15408-2与以下标准紧密关联:
- ISO/IEC 15408-1:2009:提供PP、ST的编写指南和评估模型,第2部分的组件必须依据第1部分定义的结构进行使用。
- ISO/IEC 15408-3:2009:定义评估保障等级(EAL 1-7)所需的安全保障组件,安全功能组件与保障组件共同构成TOE的评估依据。
- ISO/IEC 18045:2008(2014确认版):CC评估方法(CEM),规定了如何验证PP/ST中的功能组件与保障组件是否得到正确实施。
- 国家级互认协议(如CCRA):各国政府基于CC标准制定认证方案,15408-2的功能组件是其中唯一的标准化功能需求目录。
安全关键要求: 在涉及国家安全或关键基础设施的信息系统认证中,PP的创建必须严格遵循15408-2组件并使用正确的依赖关系。任何对组件的非法定制(如删除关键依赖性)将直接导致安全目标失效,产品无法获得有效的CC证书。
4. 常见问题(FAQ)
问: ISO/IEC 15408-2:2009与2014年确认版有何不同?
答: 2014年确认版(Confirmed)是指ISO机构审核后确认该标准内容仍然有效,未进行实质技术修订。因此技术内容与2009第一版完全一致,仅更新了封面、确认年份并修正了少量编辑性错误。使用时应引用为“ISO/IEC 15408-2:2009(确认2014)”。
问: 能否直接使用第2部分中的组件而不作任何修改?
答: 可以。但是标准的组件通常包含需要赋值的“占位符”(如“< TSF >”或“< 操作 >”),用户必须根据TOE的具体情况填充这些值。此外,也可能需要进行选择(如从列表中选择支持的密码算法)或细化(如增加更具体的描述),只要不违反组件的原有意图。
问: 如果找不到恰好满足需求的功能组件,是否可以创造自定义组件?
答: CC标准允许在PP/ST中定义“扩展组件(Extended Components)”,但它们必须明确标识为非标准组件,并且不能与原标准中的已有组件冲突。但强烈建议优先从15408-2中获取最大程度的需求覆盖,扩展组件仅在功能独特且无法用标准组件表达时使用,并且需要提供充分的证明。
问: 第2部分与第3部分在评估中如何协同?
答: 一个完整的CC评估同时涉及功能需求和保障需求。产品选择的安全功能组件(第2部分)决定了“需要实现什么功能”,而保障组件(第3部分)决定了“对这些功能的实现需要提供多少信任证据”,二者组合形成具体的评估保障等级(EAL)。例如,EAL4等级要求采用第2部分中若干功能组件,同时满足第3部分中EAL4对应的保障组件。
© 2026 技术解析·基于ISO/IEC 15408-2:2009(确认2014)标准编写。