渗透测试

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

1 级渗透测试

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

许多组织不愿意解决软件安全问题,除非有明确的证据表明组织会不可避免地遭受此种问题的影响。如果不优先考虑安全,外部渗透测试人员也可以证明组织的代码需要保障。可以引入渗透测试人员来破坏一个突出的应用程序,从而证明这一点。久而久之,渗透测试的重点就会从“我说过我们的东西被破坏了”,转变为发货前的冒烟测试和健全性检查。外部渗透测试人员带来全新的眼光看问题。

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

渗透测试结果通过建立的缺陷管理或削减渠道反馈给开发部门,开发部门通过缺陷管理和发布流程进行响应。向他们发送邮件不计算在内。正确地完成这项工作,证明了该组织改善安全状态的能力,而且许多公司开始强调不仅是识别而且切实地修复安全问题都至关重要。确保引起的注意的一种方法是在缺陷追踪和缺陷管理系统中添加安全信标。不断演变的 DevOps 和集成化团队结构没有消除对于有效缺陷管理系统的需求。

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

该组织创建了采用工具的内部渗透测试职能。可将这一职能纳入 SSG ,也可以纳入组织中其他部门的专业团队,利用这些工具提高测试过程(以及 CI/CD 环境中经常需要的部分)的效率和可重复性。工具可能包括现货产品、了解应用层面的标准常规网络渗透工具,以及手写脚本。非工作时间或危机驱动的工作不构成内部职能。  

2 级渗透测试

[PT2.2: 26] 为渗透测试人员提供一切可用信息。

内部或外部渗透测试人员获得源代码、设计文档、架构分析结果和代码评审结果之后,可以进行更深入的分析并发现更多有趣的问题。渗透测试人员需要在整个 SSDL 中创建的所有成果。如果渗透测试人员没有索要代码,您就需要寻找新的渗透测试人员。

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

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

3 级渗透测试

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

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

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

SSG 要么创建渗透测试工具,要么采用公开可获得的工具更加高效且全面地攻击组织的系统,工具提高了渗透测试流程的效率,而不牺牲 SSG 能够确定的问题的深度。在敏捷方法中使用自动化能够帮助团队加快速度,因而特别有价值。能够定制的工具始终比通用工具更受欢迎。这项活动对于测试深度和范围均有考量。