Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 27034-3 — 应用安全 第3部分：应用安全管理流程
规范、实施、验证和维护应用安全控制的逐步流程
ISO/IEC 27034-3 定义了应用安全管理流程，提供了一种详细的、逐步的方法，用于在整个应用生命周期中管理应用安全。第一部分建立了概念框架，第二部分定义了组织基础设施，而第三部分则提供了驱动应用安全活动的程序引擎。该标准是 27034 系列的操作核心，明确规定了如何在整个应用组合中定义、选择、实施、验证和维护 ASC。
ISO/IEC 27034-3 是 27034 系列中最注重操作的部分。它提供了安全团队可直接实施的详细流程工作流，包括 ASC 规范模板、验证检查表和流程流程图。
应用安全管理流程概述
ISO/IEC 27034-3 中定义的流程包括覆盖整个应用生命周期的六项主要活动：（1）规范应用安全上下文；（2）识别和规范 ASC 需求；（3）选择和定制 ASC；（4）实施 ASC；（5）验证 ASC；（6）维护 ASC。这些活动在严格的瀑布式意义上不一定是顺序的；标准明确承认，根据开发方法的不同，它们可以迭代、并发或增量地执行。例如，对于敏捷项目，ASC 规范和实施会跨多个冲刺增量发生，而对于瀑布项目，它们可能在设计阶段前置加载。
27034-3 流程的一个显著特点是其对可追溯性的强调。每个 ASC 必须可从其在安全上下文和风险评估中的起源追溯到其规范和实施再到其验证证据。这个可追溯性链为审计证据、法规合规证明和事后分析提供了基础。标准建议使用追溯矩阵或集成的需求管理工具来维护这些链接。对工程团队而言，这种可追溯性不仅仅是文档负担，而且是安全需求变更时进行影响分析的强大工具。
| 流程活动 | 输入 | 输出 | 典型周期 | 验证工件 |
|---|---|---|---|---|
| 1. 规范上下文 | 应用描述、业务案例、监管环境 | 应用安全上下文文档 | 1-2周 | 已评审的上下文文档 |
| 2. 识别和规范ASC | 安全上下文、O-ASC库、风险评估结果 | ASC草案及理由 | 1-3周 | 已批准的ASC规范 |
| 3. 选择和定制ASC | ASC草案、O-ASC库 | 应用特定的A-ASC | 1-2周 | 已定制的A-ASC文档 |
| 4. 实施ASC | A-ASC、开发资源 | 带有控制的安全应用 | 视范围而定 | 代码评审和构建工件 |
| 5. 验证ASC | 已实施的应用、测试资源 | 验证证据和报告 | 2-4周 | 已签署的验证报告 |
| 6. 维护ASC | 变更请求、事件报告、审计发现 | 更新的A-ASC和验证证据 | 持续进行 | 更新的ASC文档 |
详细流程活动与工作流
第一个活动——规范应用安全上下文——可以说是最重要的，因为所有后续活动都依赖于其准确性。上下文规范捕获了应用的业务价值、数据敏感性、监管义务、技术架构、威胁环境和适用的组织安全策略。ISO/IEC 27034-3 为这一规范提供了结构化模板，确保考虑了所有相关因素。在进入 ASC 识别之前，上下文必须经过应用安全官和项目利益相关方的评审和批准。
ASC 识别和规范涉及基于应用安全上下文从 O-ASC 库中选择候选 ASC。如果没有合适的 O-ASC，则必须通过第二部分中定义的组织 ASC 管理流程创建新的 O-ASC。然后，选定的 ASC 根据特定应用进行定制，形成 A-ASC。定制可能涉及调整参数值、选择控制的子集、添加应用特定细节或修改验证标准。定制过程必须记录在案，任何偏离 O-ASC 基线的情况都必须经过应用安全经理的批准。
ISO/IEC 27034-3 中的可追溯性要求具有超越合规性的实际益处。当在生产中发现漏洞时，可追溯性链能够实现快速影响分析：哪个 ASC 本应阻止它、验证是否充分、哪些其他应用共享相同的 ASC、以及整个组合需要什么修复。
27034-3 流程中的一个常见陷阱是将 ASC 验证视为开发末尾的单次关卡。这种方法会造成瓶颈和延迟。标准建议分层验证：开发人员的单元级验证（级别 1）、测试人员的集成级验证（级别 2）和安全专家的独立评估（级别 3）。尽可能将验证左移。
持续改进与测量
ISO/IEC 27034-3 包括了一项维护活动，确保 ASC 在应用的整个运营生命周期中保持有效。维护触发因素包括对应用的变更（新功能、技术升级）、运营环境的变更（云迁移、新法规）、揭示 ASC 弱点的安全事件以及定期审计的发现。标准建议生产中的每个应用都应具有当前的 A-ASC 规范，并且验证证据至少每年或在发生重大变更时进行评审。
标准还涉及流程有效性的测量。它定义了一组组织应收集的流程指标，用于评估和改进其应用安全流程。这些指标包括 ASC 覆盖率（具有当前 A-ASC 的应用百分比）、ASC 验证通过率（首次验证即通过的 ASC 百分比）、验证失败修复时间以及可归因于 ASC 差距的安全事件数量。通过分析这些指标随时间的变化，组织可以识别其流程中的系统性弱点，并将改进工作针对影响最大的领域。
不要混淆 ASC 实施与 ASC 验证。在代码中”实施”但未经验证的 ASC 不提供任何保证。ISO/IEC 27034-3 要求每个 ASC 在应用发布之前具有正确实施的可验证证据。将验证视为强制性的发布关卡，而非可选活动。未完成完整 ASC 验证的应用需要治理委员会在部署前进行正式的风险接受。
问1：27034-3 流程可以用于第三方应用吗？
答：可以，但需要调整。对于采购或第三方应用，流程活动侧重于验证而非实施。规范安全上下文，从 O-ASC 库中识别 ASC，然后根据这些 ASC 验证第三方应用。差距通过合同要求、补偿控制或风险接受来解决。
答：可以，但需要调整。对于采购或第三方应用，流程活动侧重于验证而非实施。规范安全上下文，从 O-ASC 库中识别 ASC，然后根据这些 ASC 验证第三方应用。差距通过合同要求、补偿控制或风险接受来解决。
问2：27034-3 如何处理遗留应用？
答：标准建议对遗留应用采用基于风险的方法。不追求完全 ASC 覆盖，而是根据应用的安全上下文（业务影响、数据敏感性、威胁暴露）确定优先级。对于高优先级遗留应用，进行现有安全控制与适用 ASC 之间的差距分析，然后实施补偿控制或接受已识别的风险。
答：标准建议对遗留应用采用基于风险的方法。不追求完全 ASC 覆盖，而是根据应用的安全上下文（业务影响、数据敏感性、威胁暴露）确定优先级。对于高优先级遗留应用，进行现有安全控制与适用 ASC 之间的差距分析，然后实施补偿控制或接受已识别的风险。
问3：ASC 验证与渗透测试之间是什么关系？
答：它们是互补的。ASC 验证确认特定控制被正确实施（例如”对所有用户提供的数据执行输入验证”）。渗透测试尝试绕过这些控制（例如”尝试通过用户输入字段注入 SQL 命令”）。两者对于全面的应用安全保证都是必要的。
答：它们是互补的。ASC 验证确认特定控制被正确实施（例如”对所有用户提供的数据执行输入验证”）。渗透测试尝试绕过这些控制（例如”尝试通过用户输入字段注入 SQL 命令”）。两者对于全面的应用安全保证都是必要的。
