以合规为驱动的渗透测试
多数渗透测试之所以被采购，是因为某项法规要求。法规决定范围、频率，以及最常被低估的部分——事后你必须能拿得出的证据。本页对比我所对应的各类监管制度，帮助你判断真正适用于自己的是哪一项。
各项法规对比
以下每一项制度都强制要求或实质上需要独立的安全测试。真正重要的差别是：约束谁、频率多高、事后需要拿出什么。
沙特阿拉伯
- NCA Essential Cybersecurity Controls（英文）——适用于政府机构、其承包商及关键基础设施的国家基线。控制项 2-11 覆盖渗透测试：须定义、记录、批准并落实，范围至少涵盖对互联网开放的服务及其背后的技术基础设施。按周期执行。
- NCA Critical Systems Cybersecurity Controls——系统一旦被归类为关键，频率提升至至少每六个月一次。打乱预算假设的通常正是这一频率变化。
- SAMA Cyber Security Framework（英文）——受沙特中央银行监管的银行、保险公司、金融公司与支付机构。至少每年一次的独立外部测试，覆盖对互联网开放的系统、Web 应用与网络基础设施。
阿拉伯联合酋长国
- NESA / UAE Information Assurance Standards（英文）——联邦机构及被认定为关键的信息基础设施。须开展并跟踪漏洞评估与渗透测试，实务上为每年一次，高危与严重发现须在规定期限内形成整改记录与复测证据。审计方会审查执行者的资质。
- Dubai ISR（DESC）——迪拜政府机构及其供应商。与 NESA 并行适用；一次项目可同时作为两者的证据。
- CBUAE、DFSA 与 ADGM（英文）——境内银行与金融公司、DIFC 企业、ADGM 企业。三者均期待定期的独立测试。
- VARA——迪拜虚拟资产服务提供商。依据 Technology and Information Rulebook，至少每年一次独立渗透测试；在 VARA 认为相称时，还需情报驱动测试。
- ADHICS（英文）——阿布扎比医疗机构及其技术供应商。
国际标准
- PCI DSS——面向任何存储、处理或传输持卡人数据的主体。要求 11.4 规定至少每年一次以及重大变更后的内外部渗透测试，若使用分段来缩小范围，还须进行分段测试。
- SOC 2——并非逐条强制，但渗透测试是多数审计方针对 CC4.1 与 CC7.1 所期待的证据，企业客户也越来越多地要求在报告中体现。
- ISO 27001——附录 A 的技术漏洞管理，测试是证明该控制项确实在运行的实际方式。
审计方实际要求什么
报告是必要的，但不充分。一份完整的证据包由四份材料构成，而多数机构只带来第二份：
- 范围说明书——测试了什么、未测试什么，以及该范围为何与控制项相符。把控制项真正关心的系统排除在外的测试，做得再好也通不过。
- 报告——发现、严重级别、复现细节，以及与相关控制项的对应关系。
- 整改记录——修复了什么、何时修复，以及以何理由接受了哪些风险。接受风险是允许的；不记录决策则不允许。
- 复测证据——确认高危与严重发现确已关闭，且在法规规定的期限内。NESA 的 90 天期望最容易让人栽跟头：在第十一个月做测试，周期结束前就没有复测的余地了。
载明由谁、按何范围、在何日期执行的确认函把整包材料串起来，通常也正是归档或转交客户的那一份。这里的每个项目都包含确认函。
最常被误读的要求：独立性
其中数项法规使用了独立一词，含义很具体：测试不能由构建或运维被测系统的人来做。内部安全团队测试本机构基础设施，能满足部分法规而非全部；编写该应用的团队再去测试它，则一项都不满足。
这在很大程度上解释了外部顾问在这一市场存在的原因，也值得在认定内部能力足够之前，先对照你们的具体义务核对一遍。在这一点上判断失误代价很高，因为它是在审计时暴露，而不是在界定范围时。
我如何界定合规类项目的范围
第一次沟通谈的是义务而非技术：哪项法规、哪个控制项、期限何时、自上次测试以来是否有实质性变化。据此我通常能在一次通话内告诉你，一个项目是否覆盖你们适用的全部要求，以及范围必须包含什么才能产出经得起审计的证据。
你会得到：开工前的固定报价；由与你沟通的本人执行测试；任何严重发现即时通报，而不是在最终文件里给你意外；一份同时写给管理层与工程师的报告；整改期间的支持；一次复测；以及确认函。如果想先看格式，有样例报告（英文）；价格量级见价格页。
按地区
如果你在海湾地区，地区页面更深入地说明适用制度及其相互关系：沙特阿拉伯渗透测试与阿联酋渗透测试。其他情况下，服务页面介绍测试本身，而直接联系是获得明确答复的最快途径。
关于合规测试的问题
通常可以，而且比分开做便宜得多。技术范围高度重叠——外部暴露面、Web 应用与 API、内部网络、Active Directory、云——不同的是与控制项的对应关系和报告形式，而不是测试本身。前提只有一个：从一开始就按这个思路界定范围。只按 PCI 界定范围的测试，即便底层工作几乎相同，也产生不了 NESA 所要求的证据。界定范围时把适用于你们的所有制度都告诉我，报告会把每一项发现对应到各自的法规上。
不够，而且这是证据被驳回的最常见原因。扫描把已知特征与已知版本做比对并输出一张清单；渗透测试则把各项发现串联起来，展示攻击者实际能做到什么。各项法规对此的表述越来越明确，审计方也已能辨认套着渗透测试封面的扫描报告——识别特征是：每条发现都是一个 CVE，且彼此之间毫无关联。差别详解（英文）。
四样，而多数机构只保留了第二样。说明测试了什么、以及为何该范围恰当的范围说明书。包含发现、严重级别与复现细节的报告本身。针对高危与严重发现的整改记录。以及确认修复有效的复测证据，且需在法规规定的期限内完成——90 天很常见。一封载明由谁、按何范围、在何日期执行的确认函把这些串在一起，通常归档留存的也正是这一页。
一年一次是常见基线：SAMA、NESA、VARA 与 PCI DSS 都落在这里。两件事会缩短这一周期：在沙特 CSCC 下被归类为关键系统，须至少每六个月测试一次；以及重大变更。几乎所有法规都要求在环境发生实质性变更后重新测试，与上一次年度测试的时间无关——大型迁移或新上线的对外应用，实际上会把计时清零。
通常可以，原因也很好预判：范围相对控制项要求过窄；由构建该系统的团队执行，因而不具独立性；没有形成复测证据；或者把扫描当作渗透测试提交。四种情形都可纠正，解决方案通常是一次范围界定正确的项目，而不是一套体系工程。把审计方的意见和上一份报告发给我，在你花钱之前我会告诉你属于哪一种。
不确定哪项法规适用于你们？
一次简短沟通通常就能确定，并告诉你一次测试能否覆盖全部。