浅谈安全团队渗透测试质量评价

浅谈安全团队渗透测试质量评价

2022年本人经历了一次工作变动，在深信服的一次面试中考官提问“如何评价渗透测试的质量？”当时回答并不理想但回头思量确实是个好问题，在此进行一个简单梳理希望对大家有帮助。

0x0 为什么要评价渗透测试:

渗透测试可能存在于不同的上下文环境，也给了测试人员极大的自由度。开展渗透测试可以是独立的个人、可以是乙方安服团队、也可以是甲方公司内部安全团队/安全部门。

作为渗透测试个人，提交一个漏洞就是一个漏洞的收益(如SRC)，不需要考虑单个被测系统测试质量的问题，甚至是写好脚本在互联网中海淘。但作为乙方安服团队或甲方内部的安全团队是需要对服务对象负责，需要将工作内容、价值、局限性说清楚，最终才能体现才能体现到KPI和收益上。

安全漏洞挖掘的多寡，只能作为渗透测试质量评价的一个维度（有机会再展开分析），我们需要更充分的评价方式。下文将以甲方安全团队为上下文视角，浅析我的一些评价思路。

0x1 渗透测试与软件测试的关系：

首先，在早些年没有渗透测试这个概念时，软件八大质量属性（功能性、性能、可用性、可靠性、健壮性、安全性、易用性、互操作性）一直都是渗透测试所关注的范畴，只不过很多团队将精力重点押宝在功能性上，而安全性等非功能属性关注相对较弱。那个时候安全性的测试质量又是如何评估的呢？

在软件测试领域，对于测试质量的评估一定程度上是对于既定测试策略的遵循程度。我们通过可以通过测试的广度和深度来定义测试策略（见：《MFQ&PPDCS》学习心得–TE—测试广度和深度）。

对于功能性测试，我们考虑的是需求/功能覆盖的广度和深度。而对于安全性测试我们通常是RBT：基于风险的测试，它评价的产品安全风险覆盖的广度和深度。

在甲方安全团队这样的渗透测试上下文环境中，我们可以认为渗透测试是软件测试中安全性这个非功能性测试的延伸和发展,依然可以通过风险的覆盖的广度和深度来评估它质量。

0x2 通过广度和深度来评价渗透工作质量：

渗透测试的广度：
即渗透测试应该覆盖的安全威胁/风险的范围。然而每个人的知识背景是有差异的，识别的出的威胁/风险也是不尽相同的。那么有效的风险识别依赖于项目上下文干系人的协作和威胁建模技术实践（如：微软STRIDE、ITU X.805）的切实落地。识别出项目中最迫切关注的安全风险点。

渗透测试的深度：
如同软件测试，渗透测试质量高低也极度依赖测试人员的能力和经验。同样一个风险点，探索能力强的人可以挖掘出N多漏洞，而新手可能毫无所获。然而他们都可以称之为完成了测试任务，但是探索的深度可能是截然不同的。那么如何去量化这种能力和探索的深度呢？我们需要有可以量化的模型和标准。
MITRE的ATT&CK 给我们提供了常见渗透攻击的战术和技术。同一安全风险点我们可以尝试使用不同的战术和技术，但它们需要的技能高低不一，对于风险挖掘的深度也是不一的。我们可以通过对标 ATT&CK模型来评价渗透测试探索的深度。即能够使用渗透战术、技术我们使用了多少？

0x3 其他间接评估方式：

横向对比
评估团队在渗透类似技术栈的项目的漏洞发现率来间接评估当前渗透测试工作质量。

若存在多个渗透测试组，横向比较其他组对类似技术栈项目的漏洞发现率来间接评估当前渗透测试工作质量。

纵向对比
软件、系统会迭代，对于甲方公司内部的安全团队针对同一被渗透对象可能会涉及多次评估的可能；借鉴软件测试可以建立度量，长期监控漏洞发现率指标。通过不同迭代评估的结果，间接评估当前渗透测试工作质量。

0x4 结尾：

有因才有果，渗透测试如同软件测试，它的体系化建设并非一朝一夕。需要一些耐心和投入。本文是结合自己软件测试和渗透测试工作经验的一些并不成熟的思考，欢迎留言讨论，谢谢！