渗透测试

渗透测试实践涉及安全专业人员执行的一类标准的由外向内测试。渗透测试着重研究最终配置中的漏洞,并为缺陷管理和削减团队提供直接反馈信息。

1 级渗透测试

[PT1.1: 109] 聘用外部渗透测试人员查找问题。

借助外部渗透测试人员证明组织的代码需要保障。通过破解知名度高的应用,提供确凿的证据证明组织无法抵御某些问题,通常能够获得充分关注。随着时间的推移,渗透测试的重点从尝试确定某些区域的代码是否遭到破坏,进而转向在交付之前完成健全性检查。外部渗透测试人员针对问题带来了全新的经验和技能,给予了最有用的帮助。

[PT1.2: 94] 向缺陷管理和削减系统反馈结果。

渗透测试结果通过建立的缺陷管理或削减渠道反馈给开发部门,此后开发部门会通过缺陷管理和发布流程进行响应。通过邮件将测试结果发送给众多人员并不能起到有用的效果。正确地完成这项工作,证明了该组织改善安全状态的能力,而且许多公司强调不仅是识别而且切实地修复安全问题都至关重要。确保引起的注意的一种方法是在缺陷追踪和缺陷管理系统中添加安全信标。组织可以利用开发人员工作流或社交工具(例如,Slack、JIRA)来传达变更请求,但这些请求仍然作为漏洞管理过程的一部分予以明确跟踪。 

[PT1.3: 82] 在内部使用渗透测试工具。

该组织创建了采用工具的内部渗透测试职能。可将这一职能纳入 SSG,也可以纳入组织中其他部门的专业团队,利用这些工具提高测试过程的效率和可重复性。使用的工具可能包括专为应用程序渗透测试而构建的现成产品,专门了解应用程序层的网络渗透工具以及自定义脚本。非工作时间或危机驱动的工作不同于内部职能。

2 级渗透测试

[PT2.2: 25] 渗透测试人员利用一切可用信息。

内部或外部渗透测试人员利用源代码、设计文档、架构分析结果、滥用和误用案例,以及代码评审结果,进行更深入的分析并发现更多有趣的问题。为了有效地完成工作,渗透测试人员通常需要在整个 SSDL 中创建的所有内容,因此如果创建的 SSDL 没有有用的代码工件,将会加剧这项工作的难度。拥有这些工件的权限并不等于可以进行使用。

[PT2.3: 22] 制定定期渗透测试时间表覆盖所有应用。

SSG 根据既定的时间表定期测试其权限范围内的所有应用程序,该时间表可以和日历或发布周期相关联。突出的应用程序应当每年至少接受一次渗透测试。这项测试可作为健全性检查,并有助于确保昨天的软件不易受到今天的攻击;这也能够帮助维护软件配置和环境的安全性,特别是在云端的容器和组件。定期测试的一个重要方面是确保发现的问题切实得到解决,并且不会潜回构建中。为 CI/CD 创建的新型自动化也有必要接受渗透测试。

3 级渗透测试

[PT3.1: 11] 使用外部渗透测试人员执行深入分析。

该组织使用外部渗透测试人员进行关键项目的深入分析,并在 SSG 中引入全新的思路。这些测试人员都应是专家和专业人士,他们使组织能够从攻击者的视角来加快创建最新版本,并且拥有破坏受测软件类型的跟踪记录。技术精湛的渗透测试人员总能突破系统,但问题在于他们是否展现了新思路,发出了对在设计、实现和强化新系统时可能有用的攻击。根据威胁情报和滥用案例创建新的攻击类型,可以防止产生检查表驱动的方案,只查找已知类型的问题,这在涉及到新技术时至关重要。

[PT3.2: 5] 让 SSG 定制渗透测试工具和脚本。

SSG 要么创建渗透测试工具,要么采用公开可获得的工具更加高效且全面地攻击组织的软件。工具会提高渗透测试流程的效率,而不牺牲 SSG 能够确定的问题的深度。自动化在使用敏捷方法的组织中特别有价值,因为它能够帮助团队加快速度。能够定制的工具始终比通用工具更受欢迎。此时成功与否通常取决于测试的深度及广度。