29、应用安全成效的衡量与优化

应用安全成效的衡量与优化

在当今数字化时代，应用安全至关重要。组织需要采取一系列措施来确保其应用程序的安全性，包括使用运行时保护工具、优化漏洞修复流程以及通过关键绩效指标（KPI）来衡量安全计划的有效性。

1. 运行时保护工具的部署与调整

运行时保护工具如Web应用防火墙（WAF）在应用安全中起着关键作用。在初始阶段，WAF通常在预生产环境中启用。以解决DNS问题为例，启用WAF后流量得到改善，应用安全团队能够开始监控潜在的恶意活动。由于预生产环境的域名未公开暴露，外部攻击的可能性极低，这使得团队可以利用动态应用安全测试（DAST）工具进行自动化安全测试，并运用渗透测试技能模拟针对WAF的攻击。经过两周的预生产环境测试，团队积累了经验并收集了数据，有信心将WAF集成到生产环境中，且影响最小。

然而，将WAF集成到生产环境并非终点，组织还需要持续调整这些运行时保护工具，以应对以下情况：
- 新发现的攻击 ：可能绕过运行时工具并对应用程序发动攻击。
- 运行时保护工具规则的更改 ：随着技术的发展，供应商会持续提供更新，这些更新通常会自动推送，但具体取决于供应商和产品。
- 环境变化 ：组织的技术环境变化会导致威胁格局和风险状况的改变。例如，Web服务器的技术从Java变为Rails，可能会消除几类漏洞，这就需要调整检测攻击的模式。

组织应建立一个监控和调整运行时工具的流程，根据变化和不同需求进行相应调整。通过监控、收集指标并将其反馈到运行时工具中，组织可以确保其安全运行，且不会对自身产生负面影响。

2. 衡量安全流程的有效性

组织的安全工作依赖于各种流程，应用安全团队主要关注与安全扫描工具、漏洞管理、渗透测试和安全教育相关的流程。衡量这些流程的有效性对于确保应用安全至关重要。

2.1 平均修复时间（MTTR）的衡量

调整安全工具可以确保获得高质量的结果，但衡量围绕工具的流程有效性同样关键。平均修复时间（MTTR）是衡量工具有效性的一个重要指标，它指的是从安全工具发现漏洞到漏洞修复并部署到生产环境所花费的时间，通常以天为单位。了解MTTR有助于评估漏洞管理流程的工作效果以及开发团队对修复要求的理解程度。

常见导致MTTR延迟的问题包括：
- 工程部门没有合适的联系人。
- 解决问题的信息不足。
- 对开放漏洞的优先级设置不当。
- 开发管道未经过良好调整，无法快速发布代码。
- 无法快速访问重测人员。

以下是一个衡量MTTR的流程：
1. 安全分析工具产生发现结果，由应用安全团队进行分类。如果是真正的漏洞，则将其放入跟踪队列，由开发团队解决。
2. 开发团队根据应用安全团队的反馈和协助，通过代码更改来修复漏洞。
3. 代码合并到分支，进行构建并部署到测试环境，最终部署到生产环境，此时漏洞被视为已修复。

每个问题都会降低组织及时修复漏洞的能力，使漏洞暴露时间过长。而且，根据安全工具的设置，组织通常每天都会引入新的漏洞。

2.2 优化平均修复时间

为了有效处理漏洞，组织需要考虑在遇到需要立即修复的关键漏洞时的应对措施。例如，Log4j漏洞就要求使用该日志记录工具的组织立即进行修复。

以Superior Products为例，处理新发现漏洞的流程如下：
1. 确定组织影响 ：识别受特定工具中发现的漏洞影响的应用程序。Superior Products维护了每个扫描工具中应用程序所有者的注册表，包括分发列表电子邮件地址和适用的票务跟踪系统。
2. 应用安全团队的处理 ：内部需要有服务水平协议（SLA），规定团队对扫描工具中发现的问题进行确认和分类的速度。团队将对问题进行分类，确定是否为真正的漏洞，然后将票务发送到跟踪系统或通过电子邮件发送到分发列表，并在票务中包含修复问题所需的所有相关信息，如更多信息或培训的链接。
3. 开发团队的修复 ：开发团队根据问题的严重性开始进行修复工作，他们也有与修复问题相关的SLA。组织会为每个发现的漏洞制定与严重性相符的修复时间。开发团队将制定修复方案，使修复时间与应用程序的发布计划相匹配。例如，对于需要在30天内解决的关键漏洞，修复代码应在该时间范围内发布的补丁中发布。
4. 应用安全团队的重测 ：在开发团队进行修复期间，应用安全团队将开发重测流程，包括手动步骤和潜在的自动化测试脚本，以测试修复代码部署后应用程序中是否仍存在漏洞。修复代码将按照开发团队遵循的标准管道实践进行构建和部署。

当处理多个漏洞时，这个工作流程会变得更加复杂。大多数组织需要同时处理多个不同严重性的漏洞，并将它们的修复时间与发布计划相匹配，这并非易事。组织可以通过收集每个漏洞的相关信息，计算不同严重性漏洞的MTTR，以了解其在关闭特定严重性漏洞方面的效率。

以下是一个不同严重性漏洞的MTTR示例：
| 漏洞 | 时间（天） | 严重性评级 | 已关闭漏洞数量 | 修复时间 | 最短时间 | 平均时间 | 最长时间 |
| — | — | — | — | — | — | — | — |
| 关键 | 5 | 30 | 2 | 20 | 38 | | |
| 高 | 12 | 60 | 17 | 37 | 56 | | |
| 中 | 23 | 90 | 24 | 50 | 75 | | |
| 低 | 40 | 365 | 63 | 169 | 275 | | |

通过收集和分析这些数据，组织可以更好地了解其漏洞修复能力，并采取相应措施进行改进。

3. 使用关键绩效指标（KPI）衡量成效

应用安全计划通常旨在推动新流程和产品，或解决组织的安全问题。组织希望通过一些关键绩效指标（KPI）来衡量应用安全计划的改进情况。

3.1 关键绩效指标的定义和关注重点

KPI是组织衡量长期目标有效性的一种方式。在应用安全领域，KPI主要关注以下方面：
- 业务风险的降低 ：在给定时间段（月、季度、年度）内，业务风险的降低情况。这依赖于业务部门识别开放漏洞、分配严重性并将其置于业务风险的背景下。
- 漏洞修复速度 ：组织从最初识别漏洞到在生产环境中修复漏洞的速度，即前面提到的MTTR。
- 漏洞的重新引入频率 ：应用程序中漏洞重新出现的频率。例如，如果一个项目中多次发现SQL注入漏洞，且根本原因未得到解决，这些漏洞可能会继续出现。
- 应用安全覆盖范围 ：应用安全计划所使用的安全工具（如静态应用安全测试（SAST）、DAST、交互式应用安全测试（IAST）、WAF等）的覆盖范围，即这些工具与已知开发管道和运行时环境的集成程度。

3.2 构建KPI

创建KPI测量过程的复杂程度取决于组织对数据的深入程度。为了衡量应用安全计划的成功，我们可以关注以下四个KPI：
- 开放漏洞
- MTTR
- 漏洞的重新引入
- 应用安全覆盖范围

对于每个KPI，应用安全团队应首先明确需要收集信息的标准，并使用简单的文档记录相关信息，如下表所示：
| 目标 | 结果 | 描述 | 类型 | 来源 | 频率 | 目标 |
| — | — | — | — | — | — | — |
| 减少开放漏洞数量以符合业务风险 | 定量 | 应用扫描工具和渗透测试 | 每周 | 低于可接受的业务风险 | | |

收集这些信息将指导未来的数据收集，并有助于报告目标的进展情况。理想情况下，组织应采用自动化方式收集信息，否则负责收集的团队或个人可能会不堪重负。

在这个例子中，组织的目标是减少整体漏洞数量，漏洞将通过组织现有的扫描工具进行识别，KPI数据每周更新一次，目标是将漏洞数量控制在预定义的业务风险阈值内。同时，需要确定KPI的负责人，负责收集和报告目标进展情况。例如，开放漏洞KPI的负责人通常是应用安全团队，因为他们对扫描工具具有广泛的了解，能够轻松在组织层面进行报告。

3.3 设置KPI目标

确定KPI后，组织需要为每个KPI设定期望的目标。这些目标可能受到外部压力的驱动，如法规、合同或其他要求。例如，对于开放漏洞KPI，目标是将开放漏洞数量控制在业务可接受的风险范围内，这需要业务和安全部门对可接受风险进行正确分类和达成共识。

以MTTR为例，组织首先需要收集当前的MTTR基线指标。假设组织设定关键漏洞的MTTR目标为14天，即从确定关键漏洞为真正的漏洞到修复代码在生产环境中运行的平均时间应在14天或更短。应用安全团队将使用组织中的缺陷跟踪工具来跟踪每个真正的关键漏洞的修复进度。

以下是一个跟踪关键漏洞的示例：
| 漏洞 | 开启日期 | 部署版本 | 部署日期 | 修复天数 |
| — | — | — | — | — |
| 项目1中的SQL注入 | 2022年12月7日 | 补丁4.1.8 | 2021年12月20日 | 13 |
| 项目4中的SQL注入 | 2022年12月2日 | 补丁4.1.8 | 2021年12月20日 | 16 |
| 项目3中的XSS | 2022年12月10日 | 补丁4.1.9 | 2021年12月27日 | 17 |
| 项目2中的路径遍历 | 2022年12月20日 | 补丁4.1.10 | 2022年1月3日 | 14 |

这四个漏洞的MTTR为15天，虽然比关键漏洞的SLA（30天）短很多，但未达到KPI设定的14天目标。组织可以根据这些指标进行改进。

3.4 基于KPI推动变革

组织设定了目标、收集了信息并明确了目标后，就需要采取行动使KPI符合目标。负责推动KPI的团队需要提供以下几个经常性的功能，以帮助降低KPI：
- 定期和自动化的指标收集 ：组织应确保能够快速、定期地收集指标，并确保数据的准确性。许多组织在开始收集指标时未能保证数据质量，因此需要找到所有数据来源，消除陈旧和重复的数据，并确定数据的所有者。
- 明确有能力影响KPI管理方式的利益相关者 ：例如，要实现应用安全覆盖范围的KPI，工程组织的领导者需要支持并参与其中，因为他们需要协助实施工具并承诺解决发现的漏洞。
- 将KPI设定为个人和领导者的目标 ：这是推动KPI时经常被忽视的部分。当个人对KPI有利益关联且能够对其产生影响时，组织更有可能实现目标。例如，将某些KPI纳入个人的年度绩效评估和目标设定中，但要确保个人有能力满足KPI的要求。
- 使KPI对所有利益相关者可见 ：KPI应处于突出位置，并由利益相关者定期审查。就像个人定期检查财务预算和目标一样，KPI也需要定期关注。

以Superior Products为例，应用安全团队负责降低已关闭漏洞的再次出现率这一KPI。由于衡量漏洞再次出现的指标需要比一般应用安全工具的指标更多的处理工作，团队需要查找相同项目中相同类型的开放漏洞，包括跨所有应用程序和项目中与之前关闭的漏洞相似的漏洞。这可能需要手动审查开放和关闭的漏洞来确定相似性。

Dashing Danielle负责制定解决漏洞再次出现KPI的计划。她首先从应用安全计划的可用工具中收集指标，重点关注SAST、DAST和渗透测试结果。为了测试她的流程，她决定先专注于一种类型的漏洞，即跨站脚本（XSS）漏洞，因为这些漏洞在应用安全计划的工具和流程中经常被发现。

她使用扫描工具中的标签并审查渗透测试报告，以定位Superior Products销售的三种产品在过去12个月内发现的所有已知XSS漏洞，如下表所示：
| 产品 | SAST | DAST | 渗透测试 |
| — | — | — | — |
| Stuff - For - You | 1 | 6 | 2 |
| Stuff - For - Me | 2 | 4 | 1 |
| Things - You - Need | 1 | 3 | 3 |

在过去12个月中，每个应用程序都发现了多个XSS漏洞，许多已经关闭，但随着时间的推移，同一应用程序中又出现了新的漏洞。Dashing Danielle首先去除每个应用程序中的重复发现，然后确定这些问题是否为真正的漏洞，因为许多工具可能会产生误报。

以Stuff - For - Me应用程序为例，在年度渗透测试中发现了一个XSS漏洞。Dashing Danielle回顾上一年的渗透测试，确定这是一个新发现。但在审查报告中的具体问题时，她发现DAST工具在渗透测试前几个月就已经发现了这个问题，开发团队进行了部分修复并通过了DAST扫描，但应用安全团队未能对关闭的漏洞进行重测，直到渗透测试才正式测试，这凸显了流程中的一个漏洞。

在Things - You - Need应用程序中，SAST工具发现了一个XSS问题。Dashing Danielle研究后发现，同一项目在全年中多次出现并关闭了XSS问题，这表明可能存在需要解决的根本原因。

通过以上方法和流程，组织可以更好地衡量和优化应用安全成效，降低安全风险，确保业务的稳定运行。

应用安全成效的衡量与优化（下半部分）

4. 深入分析 KPI 数据以持续改进

在收集和分析 KPI 数据的过程中，组织可以进一步深入挖掘数据背后的信息，以实现更有针对性的改进。

4.1 分析开放漏洞 KPI

开放漏洞 KPI 反映了组织当前面临的安全风险状况。对开放漏洞数据进行详细分析，可以帮助组织识别漏洞的高发区域和类型。例如，通过对扫描工具发现的漏洞进行分类统计，可以了解哪些应用程序或功能模块容易出现漏洞，以及哪些类型的漏洞最为常见。

假设组织发现某个特定应用程序的开放漏洞数量一直居高不下，进一步分析可能会发现该应用程序使用了一些过时的技术或库，导致安全漏洞频发。针对这种情况，组织可以考虑对该应用程序进行技术升级或更换相关库，以降低安全风险。

同时，分析开放漏洞的生命周期也很重要。了解漏洞从发现到修复的时间分布，可以评估漏洞管理流程的效率。如果发现某些漏洞长时间处于开放状态，可能需要检查漏洞分配和处理的流程，是否存在责任不明确或处理优先级不合理的问题。

4.2 优化 MTTR KPI

MTTR KPI 直接关系到组织对漏洞的响应速度和修复能力。为了进一步优化 MTTR，可以从以下几个方面入手：

• 加强沟通与协作 ：确保应用安全团队、开发团队和其他相关部门之间的沟通顺畅。建立有效的沟通机制，如定期的漏洞协调会议，及时解决漏洞处理过程中遇到的问题。
• 自动化漏洞处理流程 ：利用自动化工具实现漏洞的快速分配、修复和验证。例如，开发自动化脚本，当扫描工具发现漏洞时，自动将漏洞信息发送给相关的开发人员，并跟踪修复进度。
• 提高开发团队的安全意识 ：通过培训和教育，提高开发团队对安全漏洞的认识和处理能力。使开发人员能够更快地理解漏洞的影响和修复方法，减少修复时间。

4.3 降低漏洞重新引入频率 KPI

漏洞重新引入频率 KPI 反映了组织在修复漏洞后防止其再次出现的能力。为了降低这个 KPI，可以采取以下措施：

• 建立漏洞根因分析机制 ：当发现漏洞重新出现时，深入分析其根本原因。是由于代码逻辑问题、配置错误还是其他因素导致的。通过解决根本原因，避免类似漏洞的再次出现。
• 加强代码审查 ：在代码开发和部署过程中，加强代码审查环节。确保开发人员在修复漏洞时不会引入新的问题，同时检查代码是否符合安全规范。
• 完善测试流程 ：增加对修复代码的全面测试，包括功能测试、安全测试等。确保修复后的代码在各种情况下都能正常运行，并且不会再次出现漏洞。

4.4 扩大应用安全覆盖范围 KPI

扩大应用安全覆盖范围 KPI 有助于提高组织整体的安全防护能力。为了实现这个目标，可以按照以下步骤进行：

1. 评估现有安全工具的覆盖情况 ：了解当前使用的安全工具（如 SAST、DAST、IAST、WAF 等）在开发管道和运行时环境中的覆盖范围，找出存在的空白区域。
2. 选择合适的安全工具进行补充 ：根据评估结果，选择适合组织需求的安全工具进行补充。例如，如果发现某些应用程序在运行时缺乏有效的安全监测，可以考虑引入 IAST 工具。
3. 制定工具集成计划 ：将新的安全工具集成到现有的开发和运维流程中。确保工具之间能够协同工作，不会对现有流程造成过大的干扰。
4. 培训相关人员 ：对使用安全工具的人员进行培训，使其熟悉工具的使用方法和功能。提高人员的安全意识和操作技能，确保工具能够发挥最大的作用。

5. 建立反馈机制与持续优化循环

为了确保应用安全成效的持续提升，组织需要建立一个有效的反馈机制和持续优化循环。

5.1 反馈机制的建立

反馈机制可以收集来自不同层面的信息，包括应用安全团队、开发团队、运维团队以及业务部门的反馈。具体可以通过以下方式实现：

• 定期的安全会议 ：组织定期的安全会议，让各个部门分享在安全工作中遇到的问题、经验和建议。通过会议讨论，及时发现安全流程和工具中存在的不足。
• 安全调查问卷 ：设计安全调查问卷，向相关人员收集对安全工作的满意度、改进建议等信息。通过对调查问卷的分析，了解大家对安全工作的看法和期望。
• 事件报告与分析 ：当发生安全事件时，及时进行事件报告和分析。总结事件的原因、影响和处理过程，从中吸取教训，并将改进措施纳入到安全流程中。

5.2 持续优化循环的构建

基于反馈机制收集到的信息，组织可以构建一个持续优化循环，不断改进应用安全工作。具体流程如下：

graph LR
    A[收集反馈信息] --> B[分析反馈信息]
    B --> C[制定改进计划]
    C --> D[实施改进措施]
    D --> E[评估改进效果]
    E --> A

• 收集反馈信息 ：通过上述反馈机制，收集来自各个方面的信息。
• 分析反馈信息 ：对收集到的信息进行深入分析，找出存在的问题和潜在的改进点。
• 制定改进计划 ：根据分析结果，制定具体的改进计划，明确改进的目标、措施和责任人。
• 实施改进措施 ：按照改进计划，组织相关人员实施改进措施。确保改进措施能够得到有效执行。
• 评估改进效果 ：在改进措施实施一段时间后，评估改进效果。通过对比改进前后的 KPI 数据和其他安全指标，判断改进措施是否有效。如果效果不理想，回到收集反馈信息阶段，重新进行分析和改进。

6. 应用安全文化的建设

除了技术和流程方面的改进，建设良好的应用安全文化也是提升应用安全成效的重要因素。

6.1 安全意识培训

组织应定期开展安全意识培训，提高全体员工对应用安全的认识和重视程度。培训内容可以包括安全基础知识、常见的安全漏洞类型、安全操作规范等。

培训方式可以多样化，如线上课程、面对面培训、案例分析等。通过生动有趣的培训方式，使员工更容易接受和理解安全知识。

6.2 安全激励机制

建立安全激励机制，鼓励员工积极参与应用安全工作。例如，设立安全奖励制度，对在安全工作中表现突出的个人或团队进行表彰和奖励。

同时，将安全绩效纳入员工的绩效考核体系，使员工认识到安全工作与自身利益密切相关。通过激励机制，激发员工的安全积极性和主动性。

6.3 安全沟通与分享

营造良好的安全沟通氛围，鼓励员工之间分享安全经验和案例。可以组织安全分享会、论坛等活动，让大家在交流中学习和成长。

通过安全沟通与分享，促进不同部门之间的协作和理解，提高整个组织的安全水平。

7. 总结

应用安全成效的衡量与优化是一个持续的过程，需要组织从多个方面入手。通过合理部署和调整运行时保护工具，优化漏洞修复流程，建立有效的 KPI 体系，深入分析 KPI 数据，建立反馈机制和持续优化循环，以及建设良好的应用安全文化，组织可以不断提升应用安全水平，降低安全风险，保障业务的稳定运行。在日益复杂的网络安全环境中，只有不断学习和改进，才能适应新的安全挑战，确保组织的应用程序始终处于安全可靠的状态。

总之，应用安全是组织发展的重要保障，我们应高度重视并采取有效的措施来提升应用安全成效。