31、应用安全的衡量与持续改进

应用安全的衡量与持续改进

1. 应用安全评分卡的创建与应用

在评估应用的安全状况时，应用的关键性是确定实际评分卡的一个数学因素，这意味着它成为确定总体得分的一个额外标准。从简单的角度来看，组织可以使用基本的加权评分方法来确定产品的总体得分。由于并非每个标准在评分中所占的权重相同，因此按重要性对它们进行排名非常重要。

以下是某组织对评分卡标准进行排名后的列表：
| 标准 | 权重 |
| ---- | ---- |
| 应用关键性 | 20% |
| 支持的TLS版本 | 10% |
| 支持的TLS密码套件 | 10% |
| 关键数据库的校验和 | 5% |
| 关系数据库中的数据使用特定加密标准加密 | 15% |
| 包含敏感信息的NoSQL（非结构化数据）静态加密 | 15% |
| OWASP Top 10—A02加密失败 | 5% |
| OWASP Top 10—A03注入 | 5% |
| 可用性和DDoS相关漏洞 | 15% |

在分配权重后，就需要创建实际的评分卡。对于评分卡中的每个标准，都需要一种将其映射到加权分数的方法。因为并非每个标准都是相同的，有些是“开或关”的二元标准，如对特定TLS版本的支持；而另一些则有一系列可能的输入，如特定漏洞的数量。

以下是评分卡输入和权重的表格：
| 标准 | 权重 | 可能的输入 |
| ---- | ---- | ---- |
| 支持的TLS版本 | 10 | 二元 |
| 支持的TLS密码套件 | 10 | 二元 |
| 关键数据库的校验和 | 10 | 二元 |
| 关系数据库中的数据使用特定加密标准加密 | 20 | 二元 |
| 包含敏感信息的NoSQL（非结构化数据）静态加密 | 20 | 二元 |
| OWASP Top 10—A02加密失败 | 10 | 0->n |
| OWASP Top 10—A03注入 | 10 | 0->n |
| 可用性和DDoS相关漏洞 | 10 | 0->n |

对于二元标准，需要为标准是否实施分配一个值。例如，如果应用配置的TLS版本符合组织的标准（如TLS版本1.3），则认为该标准已完全实施，应用将获得1分；如果未实施，则获得0分。对于依赖于不断变化的漏洞组的0->n标准，应将其划分为可接受的漏洞组。例如，对于A02加密失败标准，组织可以根据风险进行分组，如0、1 - 5、6 - 10、11 - 15、>16。组织还可以考虑标准中漏洞的严重程度，以创建额外的分数级别。

为了使评分卡有效工作，每个标准都需要转换为与常见教育评分系统（A、B、C、D和F）一致的百分比或等级。这样可以计算出应用的总体得分。如果是二元项目，“开”为100分或A，“关”为50分或F；对于有多个可能得分的项目，组织应使用分组策略为每个组分配一个分数。

下面是一个示例安全评分卡：
| 标准 | 权重 | 得分 |
| ---- | ---- | ---- |
| 支持的TLS版本 | 10 | A |
| 支持的TLS密码套件 | 10 | F |
| 关键数据库的校验和 | 10 | A |
| 关系数据库中的数据使用特定加密标准加密 | 20 | A |
| 包含敏感信息的NoSQL（非结构化数据）静态加密 | 20 | A |
| OWASP Top 10—A02加密失败 | 10 | D |
| OWASP Top 10—A03注入 | 10 | C |
| 可用性和DDoS相关漏洞 | 10 | B |

创建安全评分卡的流程如下：
1. 确定评分标准并按重要性排名。
2. 为每个标准分配权重。
3. 确定每个标准的可能输入类型（二元或0->n）。
4. 为二元标准定义实施和未实施的得分，为0->n标准进行漏洞分组并分配分数。
5. 收集每个标准的信息。
6. 计算总体得分并以合适的方式呈现。

2. 持续改进应用安全计划

当应用安全计划顺利运行，漏洞减少，工程师能够提前解决影响应用的安全问题时，安全和攻击者的情况并非一成不变，安全问题的形势在不断演变，攻击手段也在不断升级。因此，组织需要持续改进应用安全计划。

2.1 领先于攻击者

在防御中，有一个常见的说法：“攻击者只需成功一次，而防御者必须每次都成功。”随着系统变得越来越复杂，暴露点增多，攻击者有了更多的目标。不同类型的攻击者对组织的威胁程度和组织防御的难度各不相同，常见的威胁行为者包括脚本小子、内部人员、黑客活动分子和恐怖分子、网络罪犯以及高级持续威胁。

为了应对不同类型的攻击者，组织可以采用分层防御策略。以下是攻击者可能采取的步骤以及相应的防御措施：
- 侦察（Reconnaissance） ：攻击者通过扫描和搜索公共信息来收集目标组织的信息。组织应减少应用和组织信息的暴露，如减少源代码和文档的公开，确保Web服务器的HTTP头不提供不必要的信息，并关闭未使用的端口。
- 资源获取、访问和执行（Resource, Access, and Execution） ：攻击者利用基础设施和主机的弱点，获取硬件和云资源，获得访问权限并执行脚本。组织应确保主机和服务器具有适当的安全控制，如最小权限访问、关闭端口、及时更新软件，并通过日志和监控来检测入侵迹象。
- 持久化、提权和规避（Persistence, Escalation, and Evasion） ：攻击者在获得主机访问权限后，会尝试持久化存在、提升权限并规避防御措施。组织应确保主机、服务器和网络设备的安全配置，使用日志和监控检测恶意活动，并利用哈希技术确保文件不被篡改。
- 凭证访问和发现（Credential Access and Discovery） ：攻击者试图获取凭证或账户访问权限，并在组织系统中发现服务和信息。组织应加强账户安全管理，防止凭证泄露。
- 横向移动和收集（Lateral Movement and Collection） ：攻击者通过网络横向移动，寻找更多的攻击目标，并收集数据。组织应加强网络安全防护，防止攻击者通过钓鱼等手段获取更多访问权限。
- 命令与控制和数据外泄（Command and Control and Exfiltration） ：攻击者需要将收集到的数据从网络中导出。他们会采用混淆和加密的方法，避免被网络工具检测到。组织应监控网络流量，设置合理的流量阈值，防止数据外泄。
- 破坏（Impact） ：攻击者可能会通过破坏性方法（如数据擦除、加密、删除账户访问权限等）破坏系统的可用性或完整性。组织应制定应急响应计划，以应对此类攻击。

2.2 MITRE ATT&CK框架

MITRE开发了ATT&CK框架（https://attack.mitre.org/），该框架涵盖了攻击者从侦察到数据外泄的各个步骤。虽然该框架不能涵盖所有攻击者的行为，但它有助于开发特定于攻击者行为的威胁模型和缓解技术。

以下是MITRE ATT&CK矩阵的主要阶段：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(侦察):::process --> B(资源开发):::process
    B --> C(初始访问):::process
    C --> D(执行):::process
    D --> E(持久化):::process
    E --> F(提权):::process
    F --> G(防御规避):::process
    G --> H(凭证访问):::process
    H --> I(发现):::process
    I --> J(横向移动):::process
    J --> K(收集):::process
    K --> L(命令与控制):::process
    L --> M(数据外泄):::process
    M --> N(影响):::process

2.3 Cyber Kill Chain框架

Cyber Kill Chain框架（http://mng.bz/aPdj）由洛克希德·马丁公司开发，用于快速了解攻击者的类型和攻击过程。该框架的第一步也是侦察，攻击者通常通过收集组织的公共信息来了解目标。侦察技术可以通过使用专门的工具（如Shodan）变得更加复杂。

通过了解这些攻击框架和步骤，组织可以制定更有效的防御策略，持续改进应用安全计划，以应对不断变化的安全威胁。

3. 两种攻击框架的对比与应用

虽然MITRE ATT&CK框架和Cyber Kill Chain框架都用于描述攻击者的行为过程，但它们在侧重点和应用场景上有所不同。

对比项	MITRE ATT&CK框架	Cyber Kill Chain框架
覆盖范围	涵盖了攻击者从侦察到数据外泄的各个详细步骤，包含众多具体的技术和策略，范围广泛且细致。	主要关注攻击的主要阶段，步骤相对简洁，更侧重于提供攻击过程的整体概览。
用途	有助于开发特定于攻击者行为的威胁模型和缓解技术，适用于深入分析攻击者的行为模式和制定针对性的防御措施。	可用于快速了解攻击者的类型和攻击过程，便于组织快速评估安全态势并做出响应。
详细程度	非常详细，对每个阶段的描述和可能使用的技术都有具体说明。	相对简略，主要突出攻击的关键步骤。

组织可以根据自身的需求和资源，结合使用这两个框架。例如，在进行全面的安全评估和威胁建模时，可以使用MITRE ATT&CK框架深入分析攻击者的可能行为；在快速响应安全事件时，Cyber Kill Chain框架可以帮助组织迅速定位攻击阶段并采取相应的措施。

4. 应用安全持续改进的实践建议

为了更好地持续改进应用安全计划，组织可以参考以下实践建议：

4.1 建立安全指标和监控体系

• 定义关键安全指标（KPIs） ：确定与组织目标相关的安全指标，如漏洞修复率、安全事件响应时间等。通过定期监控这些指标，了解应用安全计划的运行状况。
• 实时监控和预警 ：利用安全信息和事件管理（SIEM）系统等工具，实时监控应用系统的安全状况。当出现异常情况时，及时发出预警，以便组织能够迅速采取措施。

4.2 加强人员培训和安全意识教育

• 技术人员培训 ：为开发人员、运维人员等提供定期的安全培训，使他们了解最新的安全威胁和防御技术。例如，举办安全编码培训课程，提高开发人员编写安全代码的能力。
• 全员安全意识教育 ：通过安全宣传、培训和模拟攻击演练等方式，提高全体员工的安全意识。让员工了解常见的安全风险和防范措施，避免因人为疏忽导致安全漏洞。

4.3 定期进行安全评估和漏洞扫描

• 内部安全评估 ：定期组织内部安全评估，包括代码审查、漏洞扫描等。发现潜在的安全漏洞，并及时进行修复。
• 外部安全审计 ：邀请专业的安全机构进行外部安全审计，获取客观的安全评估报告。根据审计结果，改进应用安全计划。

4.4 建立应急响应机制

• 制定应急响应计划 ：明确在发生安全事件时的应急响应流程和责任分工。确保组织能够迅速、有效地应对安全事件，减少损失。
• 定期演练 ：定期进行应急响应演练，检验应急响应计划的可行性和有效性。通过演练，提高团队的应急响应能力和协同作战能力。

5. 应用安全持续改进的流程总结

为了更清晰地展示应用安全持续改进的过程，以下是一个mermaid格式的流程图：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(建立安全评分卡):::process --> B(监控安全指标):::process
    B --> C(分析安全态势):::process
    C --> D{是否存在安全风险?}:::process
    D -- 是 --> E(制定改进措施):::process
    E --> F(实施改进措施):::process
    F --> B
    D -- 否 --> B

这个流程包括以下几个关键步骤：
1. 建立安全评分卡 ：通过确定评分标准、分配权重和收集信息，创建应用安全评分卡，为评估应用安全状况提供基础。
2. 监控安全指标 ：定期监控关键安全指标，了解应用安全计划的运行状况。
3. 分析安全态势 ：根据监控数据，分析应用的安全态势，判断是否存在安全风险。
4. 制定改进措施 ：如果发现安全风险，制定相应的改进措施，如修复漏洞、加强安全控制等。
5. 实施改进措施 ：将改进措施付诸实践，并持续监控改进效果。

通过不断循环这个流程，组织可以持续改进应用安全计划，提高应用系统的安全性，应对不断变化的安全威胁。

总之，应用安全是一个持续的过程，需要组织不断地关注和改进。通过创建安全评分卡、了解攻击框架、采取有效的防御措施和持续改进实践，组织可以更好地保护应用系统免受攻击，确保业务的安全稳定运行。