应用安全的策略与实践
1. 紧跟工程步伐
在应用安全领域,组织常常面临技能差距的挑战。预算限制使得组织难以简单地招聘具备合适技能的员工或送现有员工去培训。为应对应用安全与工程组织之间的技术差距,应用安全团队可采取以下策略。
1.1 建立与工程组织的合作关系
- 参与技术交流 :应用安全团队应参与技术对话、规划会议和路线图制定。这样不仅能代表组织的安全利益,还能了解工程组织的技术决策和未来规划,有助于将安全融入开发过程。
-
维护人际关系
:与工程组织的对应人员和决策者建立并维护良好关系。例如,与CTO或业务领导者分享应用安全路线图,促进思想交流,获取反馈,并请求对方提供技术和业务路线图。关注路线图中的关键信息,如:
- 新的需要SDLC安全集成的产品。
- 改变软件开发或部署方式的新方法或技术。
- 业务产品整合,可能带来效率提升,但也可能遗留技术债务和遗留代码。
- 产品停用及退役时间表,可能导致产品被忽视,安全漏洞得不到解决。
1.2 使用可互换工具
- 工具的可替代性 :确保工具、流程和技术具有可替代性,即与组织的流程和技术松散耦合。这样可以避免供应商锁定,在初始供应商不符合期望时更换供应商。例如,运行WAF等运行时保护工具时,云部署模式使组织更易更换供应商或采用多供应商策略。
- 成本考量 :更换供应商会产生成本,且可能失去单一供应商的批量折扣。因此,需要在总体战略、工具多样性需求、扩展能力和利用不同技术之间进行平衡。
- 结对学习 :应用安全工程师可以与使用新的、团队需要提升技能的技术的开发人员结对学习,类似于软件开发中的结对编程,通过实践学习新技术。
2. 停止追逐新工具
市场上有很多优秀的安全工具,但有些团队倾向于为每个问题寻找新工具,而忽略了现有工具或简单解决方案,这可能导致功能重叠和资源浪费。
2.1 使用能力矩阵
- 创建矩阵 :构建简单的能力矩阵,以了解团队现有工具的能力。首先列出团队的工具清单,然后确定工具的能力。能力矩阵可以根据团队需求简单或复杂,其主要目的是在评估新工具时提供现有工具能力的信息。
-
示例矩阵
:以下是一个简单的应用安全能力矩阵示例:
| 工具 | 运行时保护 | 发现OWASP Top Ten风险 | Jira票务集成 | 需要代理安装 | 源代码管理集成 | OSS扫描 | SaaS/On - prem |
| — | — | — | — | — | — | — | — |
| 静态应用安全测试 | X | X | X | | | | On - prem |
| 动态应用安全测试 | X | X | X | | | | On - prem |
| 软件成分分析 | X | X | X | X | | | SaaS |
| 交互式应用安全测试 | X | X | X | | | | On - prem |
当比较特定类型的工具时,如SAST工具,需要创建更详细的能力矩阵:
| 工具 | 与Visual Studio集成 | 与Eclipse集成 | 与Jira集成 | 与GitHub集成 | 自定义规则创建 | 支持内部语言 |
| — | — | — | — | — | — | — |
| SAST - Tool1 | X | X | X | X | X | |
| SAST - Tool2 | X | X | X | X | | |
| SAST - Tool3 | X | X | X | | | |
| SAST - Tool4 | X | X | X | X | X | |
2.2 管理工具和供应商
- 持续评估 :决策购买工具后,或组织已有工具时,要持续评估工具和供应商的有效性。定期与供应商沟通,了解工具的功能变化和更新。
- 查看路线图 :向供应商索要工具路线图,这有助于更新能力矩阵。例如,SAST工具可能会根据客户需求增加对新语言的支持。
- 监控工具效果 :持续监控工具的有效性,并向供应商提供反馈。供应商希望工具在组织中成功使用,会根据反馈进行改进。
2.3 购买新工具
在经过充分评估,使用能力矩阵,与供应商沟通获取路线图和功能信息后,如果仍发现组织在软件保护方面存在差距,可以考虑购买新工具。例如,很多组织的软件运行时安全是较新的领域,WAF和RASP等运行时工具正逐渐受到关注。但购买新工具时,要确保其能满足组织的能力需求,通过能力矩阵、概念验证和价值验证,并成功集成工具。同时,要注意安全工具的集成难度,不同团队的流程和技术差异可能导致集成复杂。
以下是应用安全工具在安全事件中的使用流程 mermaid 图:
graph LR
A[CVE] --> B[软件成分分析]
B --> C{组织的暴露情况?}
C -->|是| D[动态扫描或渗透测试工具]
C -->|否| E[无暴露]
D --> F{是否可利用?}
F -->|是| G[动态扫描或渗透测试工具]
F -->|否| H[不可利用]
G --> I{修复是否有效?}
I -->|是| J[修复成功]
I -->|否| K[继续修复]
L[应用安全提供的缓解或修复措施] --> M[将缓解或修复措施纳入代码]
应用安全的策略与实践
3. 为最坏情况做准备
尽管组织会尽力保障安全,但仍可能遭遇安全漏洞。应用安全团队在应对攻击或漏洞事件时通常需要发挥作用,因为应用运行依赖于硬件、软件、第三方工具和网络等多个组件,攻击者可能会破坏应用及其运行环境。
3.1 资产与版本管理
组织需要识别应用开发和运营中使用的资产、工具、技术和服务。资产包括硬件、软件、数据和人员等,通常存储在数据库中进行管理。在潜在网络攻击发生时,组织首先要了解自身的暴露情况,这就需要有完善的资产管理策略。不仅要知道拥有哪些资产,还要清楚其使用版本和资产归属。
例如,在2021年末至2022年初的Log4j漏洞事件中,多个版本受到影响,不同版本有不同的缓解和修复建议:
| 版本 | 缓解/修复措施 |
| — | — |
| Log4j版本2.12.1和2.13.0至2.15.0 | 升级到版本2.16.0 |
| Java 8或更高版本 | 升级到版本2.17.0 |
| Java 7 | 升级到版本2.12.3 |
| Log4j版本2.17.0及以下 | 移除jdnilookup.class |
由于许多组织使用多个版本的Log4j,在技术或客户限制下,简单升级到最新版本可能不可行,这就导致在修复漏洞时容易产生困惑。因此,强大的资产管理对于跟踪问题并解决至关重要。
3.2 建立沟通渠道
在应对生产中断或安全事件等时间敏感的情况时,建立有效的沟通渠道非常关键。知道在问题发生时联系谁,能够快速召集多学科和多团队的人员共同解决问题,这可能是控制安全事件和避免漏洞扩大的关键。
3.3 利用安全工具应对事件
应用安全工具不仅可以发现安全漏洞,还能在安全事件中发挥重要作用。当资产工具不可用时,应用安全工具可用于检测暴露情况。例如,当新的CVE显示组织使用的流行库存在关键漏洞时,应用安全团队可以使用现有工具识别暴露情况和库的使用情况,然后使用测试工具(自动化或渗透测试工具)确定漏洞是否可被利用。如果可以利用,还可以使用这些工具验证应用的补丁是否有效。此外,如果应用安全团队运行WAF或RASP等运行时保护工具,可以创建规则来阻止利用漏洞的攻击。
4. 总结
- 攻击洞察 :使用如MITRE ATT&CK和Cyber Kill Chain等矩阵,可以了解攻击者如何利用系统或软件中的简单漏洞来破坏组织并导致漏洞发生。
- 工具评估 :威胁目录是衡量工具有效性的主要方法,也是在软件已知弱点和漏洞方面建立共同语言的方式。它可以为质量保证测试人员和渗透测试人员提供审查软件安全性的步骤指导。
- 紧跟工程 :工程团队发展迅速,应用安全团队需要通过培训提升技能,并与工程团队密切合作,以跟上其步伐。
- 工具管理 :应用安全团队在组织中广泛使用工具,但要确保工具提供预期的价值,避免工具集的冗余。
- 应急响应 :所有组织都可能在某个时候遭遇漏洞,因此需要从“阻止攻击者”的理念转向“检测和响应”的概念,建立相应的工具、流程和人员体系,以便在攻击发生时做出有效响应。
以下是一个总结应用安全关键要点的列表:
1. 与工程组织建立紧密合作,参与技术交流和规划。
2. 合理使用可互换工具,平衡成本和多样性。
3. 运用能力矩阵评估和管理工具及供应商。
4. 谨慎购买新工具,确保满足组织需求。
5. 建立完善的资产和版本管理策略,应对安全事件。
6. 建立有效的沟通渠道,快速响应安全事件。
7. 充分利用安全工具检测和解决安全问题。
通过以上策略和实践,组织可以更好地应对软件安全挑战,提高自身的安全防护能力。
graph LR
A[应用安全策略] --> B[紧跟工程步伐]
A --> C[合理管理工具]
A --> D[应对最坏情况]
B --> B1[建立合作关系]
B --> B2[使用可互换工具]
C --> C1[使用能力矩阵]
C --> C2[管理工具和供应商]
C --> C3[购买新工具]
D --> D1[资产与版本管理]
D --> D2[建立沟通渠道]
D --> D3[利用安全工具应对事件]
超级会员免费看

被折叠的 条评论
为什么被折叠?



