34、应用安全实践与风险应对指南

应用安全实践与风险应对指南

1. 应用安全基础操作与案例分析

1.1 OpenAPI JSON 文件安全审计

使用 APIsecurity.io（https://apisecurity.io/tools/audit/）对 OpenAPI JSON 文件进行安全审计。此工具能识别 JSON 文件中与代码质量和安全相关的信息。借助 Microsoft 的 Visual Code（https://code.visualstudio.com/）插件，可在 OpenAPI 部分的左侧栏找到 JSON 文件中存在的安全问题。具体操作步骤如下：
1. 访问 APIsecurity.io 工具链接。
2. 上传 OpenAPI JSON 文件进行审计。
3. 打开 Visual Code 并安装相关插件。
4. 在 OpenAPI 部分查看识别出的安全项目。
可参考 http://mng.bz/WMO4 的说明来识别 OpenAPI JSON 文件中可能存在的安全问题。

1.2 安全接触点选项

在安全接触点方面有三个选项：
1. 架构分析 ：在设计阶段融入安全专业知识，以识别风险并提供补救措施。
2. 代码审查 ：安全团队需识别并指导解决发现的不安全代码。
3. 安全测试 ：多数组织可利用扫描工具测试应用程序，并将报告反馈给开发团队以解决问题。有许多免费工具可用于识别安全问题，如 OWASP 提供的开源动态安全测试工具 ZAP 和源代码分析工具 Dependency Track，Defect Dojo 可用于协调这些工具的检测结果。对于不太成熟的组织，安全测试接触点最为合适。

1.3 勒索软件攻击案例

以 Zegna 为例，2021 年 8 月该品牌遭受 RansomExx 勒索软件攻击。Zegna 通过备份和云服务提供商恢复了系统，并拒绝支付赎金。发现攻击后，Zegna 借助外部第三方进行取证，清除勒索软件，防止攻击者再次入侵并恢复系统。组织应具备识别、响应攻击的能力，必要时引入第三方协助恢复，且绝不要支付赎金。

2. 数据收集与风险评估

2.1 敏感数据收集考量

收集终端用户数据时，若涉及敏感信息（如社会安全号码等个人身份信息），会给组织和用户带来不必要风险。组织收集此类信息可能成为攻击目标，数据泄露时还需承担额外成本。因此，应思考是否有必要收集这些信息以及对业务或应用是否有价值。若无即时需求，可不收集，未来潜在用途并非当下收集的充分理由。

2.2 OWASP 风险评级方法

OWASP 风险评级方法可用于评估特定风险。可通过在线工具（www.owasp - risk - rating.com/）快速计算基本风险，考虑风险的可能性和影响。以医院临床应用的远程代码执行风险为例：
1. 可能性因素
- 威胁主体 ：假设攻击者需较高技能水平来编写利用程序，且无公开可用的利用程序。攻击者可能是网络犯罪分子，规模较小但有经济动机。机会取决于利用程序和补偿控制措施。
- 漏洞因素 ：假设存在公开和自动化工具可发现此漏洞，但组织有良好的安全工具可添加检测签名。综合来看，可能性为中等。
2. 影响因素
- 技术影响 ：涉及系统和数据的机密性、完整性、可用性和问责性。远程代码执行会危及数据机密性，可能导致系统停机以迫使医院支付恢复服务费用。
- 业务影响 ：包括财务损失、法律诉讼和声誉损害，如医院需考虑 HIPAA 违规和收入损失等问题。综合评估，此风险为中等影响。

3. 威胁建模与漏洞处理

3.1 威胁建模工具使用

下载并安装 Microsoft Threat Model（http://mng.bz/82zZ）或 OWASP 的 Threat Dragon（https://owasp.org/www - project - threat - dragon/）后，创建一个描绘浏览器与 Web 服务器交互的基本流程图。工具会识别出一些可能的威胁，如浏览器或用户访问 Web 服务器时可能被仿冒。为防止仿冒，需建立强大的身份验证机制，根据应用程序的重要性，可添加多因素身份验证以保护敏感工作流程。操作步骤如下：
1. 下载并安装所选工具。
2. 创建包含浏览器和 Web 服务器交互的流程图。
3. 查看工具识别的威胁。
4. 根据需要添加身份验证机制。

3.2 CVE 漏洞分析

从 NVD（https://nvd.nist.gov/vuln/full - listing）选取一个 CVE 进行分析，如 https://nvd.nist.gov/vuln/detail/CVE - 2022 - 0939。CVSS 分数通常仅作为严重程度的参考，组织内部审查后分数可能会改变，因为 CVSS 分数未考虑组织的补偿控制措施。例如，若组织刚开始使用 GitHub 且未托管代码仓库，则该漏洞对其代码无威胁；而其他组织可能受影响较大，需保留 9.9 的 CVSS 分数以采取缓解措施。具体步骤如下：
1. 从 NVD 选择一个 CVE。
2. 了解其详细信息和 CVSS 分数。
3. 根据组织的补偿控制措施，使用 CVSS 计算器（www.first.org/cvss/calculator/3.0）调整分数。

3.3 渗透测试与漏洞披露

• 渗透测试岗位 ：可参考 http://mng.bz/E01o 获取渗透测试人员的示例职位描述。
• 漏洞赏金计划 ：漏洞赏金计划可吸引更多测试人员进行安全测试，但组织需明确参与规则。可从 http://mng.bz/N5eN 获取网络安全和基础设施安全局的漏洞披露计划模板。

4. 应用安全团队与标准制定

4.1 应用安全团队组织

应用安全团队的组织形式多样，规模可大可小，目标因组织和行业而异。构建安全成熟度模型（BSIMM）可作为参考，若组织内部无安全团队，可查看 BSIMM 了解软件安全组（SSG）的职责范围。

4.2 标准制定示例

以加密标准为例，组织可参考 NIST 的示例加密标准和指南（http://mng.bz/lRo6）来制定可接受的加密级别标准。

4.3 应用访问要求

通过 API 网关访问应用程序时，一个简单的要求是在应用登录时实施多因素身份验证，即用户登录应用程序时必须完成多因素身份验证挑战。

5. 风险定义与服务自动化

5.1 风险定义与赋值

使用风险定义模板，可选择其他风险进行突出显示并赋值。

5.2 安全服务自动化

思考可提供的安全服务时，可考虑自动化典型安全服务，如 API URL 测试服务，该服务可识别安全问题并返回检测结果和补救报告。

6. 应用安全路线图与指标

6.1 路线图对齐

应用安全路线图应与组织的整体路线图保持一致。例如，若组织转向多云部署应用程序，应用安全路线图需确保具备支持多云战略所需的工具、培训和专业知识，可在各云环境中对云原生工具进行概念验证，以确保安全服务满足安全控制要求。

6.2 关键绩效指标（KPI）

可测量组织应用程序的总安全测试覆盖率，类似于代码单元测试的覆盖率概念，应将安全测试覆盖到代码行、项目和应用程序部署栈。组织应争取实现 100% 覆盖，首先需了解当前的测试覆盖情况，这需要审查应用安全工具集并确定其对每个应用程序的覆盖范围。

6.3 安全计分卡

不同行业的安全计分卡不同。以医疗组织跟踪患者用药剂量的应用程序为例，确保数据完整性的安全指标是关键焦点，如数据库数据完整性检查和数据访问控制应作为最高优先级标准。

6.4 TLS 版本与密码套件

组织可设定标准的 TLS 版本以确保数据传输安全，并遵循行业最佳实践。还可深入研究使用的密码套件，参考 Mozilla 的相关信息（http://mng.bz/BZ20），将现代和中级兼容密码套件作为计分卡目标，并为每个符合情况赋值。

6.5 应用安全相关概念总结

概念	描述
应用安全	涵盖多个方面，包括团队组织、工具使用、风险评估等，旨在保障软件安全
威胁建模	通过工具识别潜在威胁，采取相应防护措施
漏洞处理	利用各种工具和方法识别、分析和解决漏洞
数据安全	谨慎收集敏感数据，评估数据收集的必要性和风险
风险评估	使用 OWASP 等方法评估风险的可能性和影响
安全路线图	与组织整体战略对齐，确保具备支持业务发展的安全能力
指标与计分卡	通过 KPI 和安全计分卡衡量应用安全水平

6.6 应用安全流程 mermaid 流程图

graph LR
    A[应用开发] --> B[威胁建模]
    B --> C[安全测试]
    C --> D[漏洞修复]
    D --> E[持续监控]
    E --> F[风险评估]
    F --> G[调整策略]
    G --> A

此流程图展示了应用安全的循环流程，从应用开发开始，经过威胁建模、安全测试、漏洞修复等环节，持续监控并进行风险评估，根据评估结果调整策略，形成一个不断优化的闭环。

7. 应用安全的关键要素与应对策略

7.1 应用安全的核心概念

应用安全涉及多个关键概念，这些概念相互关联，共同构成了应用安全的整体框架。
- 资产 ：明确资产的定义有助于确定需要保护的对象。资产可以是数据、系统、应用程序等，对资产的清晰界定是实施安全措施的基础。
- 攻击者 ：了解攻击者的类型和动机是制定防御策略的关键。攻击者可能包括脚本小子、网络犯罪分子、黑客活动分子和恐怖分子等，不同类型的攻击者具有不同的技能水平和攻击目的。
- 认证与授权 ：认证用于验证用户的身份，确保只有合法用户能够访问系统；授权则决定了用户在系统中的操作权限，防止越权访问。

7.2 应对不同类型的攻击

针对不同类型的攻击，需要采取相应的应对策略。
|攻击类型|特点|应对策略|
| ---- | ---- | ---- |
|勒索软件攻击|加密关键数据，要求支付赎金恢复|定期备份数据，增强系统的恢复能力；不支付赎金，寻求专业的安全团队协助清除勒索软件|
|分布式拒绝服务（DDoS）攻击|通过大量请求使系统瘫痪|使用 DDoS 防护服务，如内容分发网络（CDN）和 DDoS 清洗中心；优化系统架构，提高系统的抗攻击能力|
|代码注入攻击|攻击者通过注入恶意代码来执行非法操作|对输入数据进行严格的验证和过滤，防止恶意代码注入；使用安全的编程实践，避免代码漏洞|

7.3 安全工具的使用

安全工具是保障应用安全的重要手段，不同的工具具有不同的功能和适用场景。
- 动态应用安全测试（DAST） ：在应用程序运行时进行测试，发现潜在的安全漏洞。操作步骤如下：
1. 选择合适的 DAST 工具，如 OWASP ZAP 等。
2. 配置测试环境，包括目标应用程序的 URL、认证信息等。
3. 启动测试，工具会自动发送请求并分析响应，发现潜在的漏洞。
4. 查看测试报告，对发现的漏洞进行修复。
- 静态应用安全测试（SAST） ：在代码开发阶段进行测试，分析代码中的安全漏洞。操作步骤如下：
1. 选择合适的 SAST 工具，如 SonarQube 等。
2. 将工具集成到开发环境中，如 IDE 或 CI/CD 管道。
3. 对代码进行扫描，工具会分析代码的语法和逻辑，发现潜在的漏洞。
4. 开发人员根据扫描结果修复代码中的漏洞。

8. 应用安全的持续改进

8.1 持续改进的重要性

应用安全是一个持续的过程，需要不断地进行改进和优化。随着技术的发展和攻击者手段的不断变化，应用程序面临的安全威胁也在不断增加。因此，持续改进应用安全措施是保障系统安全的关键。

8.2 持续改进的方法

• 引入新工具 ：关注安全技术的发展，及时引入新的安全工具和技术，提高安全防护能力。例如，使用人工智能和机器学习技术来分析安全数据，发现潜在的威胁。
• 建立威胁目录 ：收集和整理常见的安全威胁，建立威胁目录。通过对威胁目录的分析，制定相应的防御策略，提高应对威胁的能力。
• 与工程团队合作 ：加强与工程团队的沟通和合作，了解业务需求和技术架构的变化，及时调整安全策略。例如，在新的技术架构引入时，提前进行安全评估和规划。

8.3 持续改进的流程 mermaid 流程图

graph LR
    A[安全评估] --> B[发现漏洞]
    B --> C[制定修复计划]
    C --> D[修复漏洞]
    D --> E[重新评估]
    E --> F[更新安全策略]
    F --> A

此流程图展示了应用安全持续改进的循环流程，通过定期的安全评估发现漏洞，制定修复计划并进行修复，然后重新评估系统的安全性，根据评估结果更新安全策略，形成一个不断优化的闭环。

9. 应用安全的未来发展趋势

9.1 自动化与智能化

随着人工智能和机器学习技术的发展，应用安全将越来越多地采用自动化和智能化的方法。自动化工具可以快速地发现和修复安全漏洞，提高安全响应速度；智能化技术可以分析大量的安全数据，预测潜在的威胁，提前采取防御措施。

9.2 云安全

随着越来越多的应用程序迁移到云端，云安全将成为应用安全的重要组成部分。云服务提供商需要提供强大的安全防护能力，保障用户数据的安全；企业需要加强对云环境的安全管理，确保云应用的安全运行。

9.3 零信任架构

零信任架构将成为未来应用安全的主流趋势。零信任架构基于“默认不信任，始终验证”的原则，对任何试图访问系统的用户、设备和应用程序都进行严格的验证和授权，即使在内部网络中也不例外。

9.4 应用安全的未来发展趋势 mermaid 流程图

graph LR
    A[自动化与智能化] --> B[云安全]
    B --> C[零信任架构]
    C --> D[更高级的安全防护]

此流程图展示了应用安全未来发展的趋势，从自动化与智能化到云安全，再到零信任架构，最终实现更高级的安全防护。

总之，应用安全是一个复杂而重要的领域，需要综合考虑多个方面的因素。通过采取有效的安全措施，如威胁建模、漏洞处理、安全测试等，以及持续改进安全策略，可以提高应用程序的安全性，保护用户数据和业务的安全。同时，关注应用安全的未来发展趋势，提前布局，将有助于企业在未来的竞争中占据优势。