网络安全领域20年，我对审计的几点体会

我在网络安全领域工作了二十年，其中相当大一部分时间都花在审计上：准备审计、接受审计、与审计发现争论，以及修复审计揭示的问题。框架已经变过很多次，而这些经验从未改变。

1. 证据胜过叙述

最常见的审计发现往往不是控制措施缺失，而是控制措施已执行，却无法证明。访问权限审查确实做了，但没有人留存名单。变更确实经过批准，但审批记录在聊天群里，而该群聊后来已被删除。审计师只能依据其能看到的内容做判断。应设计能在执行过程中自然留下证据的控制措施，大多数发现便会随之消失。

2. 范围决定一切

大多数审计难题都可追溯到范围问题：范围划得过宽，每个系统都必须满足每项控制；范围划得过窄，认证结果无法回答客户的问题；或范围含糊不清，没人知道哪些系统算在内。应审慎确定范围，书面记录并为之辩护。我们关于首次 SOC 2 报告范围界定的文章几乎适用于任何审计。

3. 失效的控制措施，往往是无人负责的那些

当某项控制有明确的负责人，并将其作为日常工作的一部分来执行时，它就能发挥作用。若它只归属于“IT部门”或笼统的“安全团队”，它就会逐渐失控，直到审计前一周才被想起。明确责任归属，是成本最低的控制改进手段。

4. 文件必须反映实际情况

那些描述的是你并不存在的公司的模板化政策，比描述你真实公司的简短政策更糟糕。审计师检验的是你所写的内容。文件与实际操作之间的每一处差距都会成为一项发现，而且往往会连带动摇审计师对你所展示的其他一切内容的信任。

5. 审计师作为盟友比作为对手更有价值

进展最顺利的审计，通常是团队把审计师视为多一双眼睛，而非对手的审计。尽早询问审计师将如何测试某项控制。对已知弱点连同整改计划一并披露。由自己主动提出、且修复正在进行中的问题，与被审计师挖出来的问题，给人的观感截然不同。

6. 第二个框架的成本应该很低

若一个组织为每个框架分别运行一套项目，那么每次审计都要全额付费。若其建立一套统一的控制措施，并将其映射到所应对的每一个框架，则大部分成本只需支付一次。映射工作枯燥，但收益会不断累积。这也是我创建ControlMapping的主要原因之一。

7. 框架不同，问题相同

经历足够多的审计后，各个框架会逐渐变得相似。ISO 审计师、SOC 2 审计师、PCI 评估人员和监管机构用词各异，但他们问的往往是同样几个问题：范围包括什么，谁负责，如何证明其有效，以及失效时会发生什么。能够清楚地以证据回答这四个问题的组织，在几乎任何审计中都能表现良好。覆盖矩阵便是一个很好的说明：横跨十一个框架，同样的核心主题反复出现。

关键要点

• 设计能在执行过程中自然留下证据的控制措施。
• 审慎确定范围，并为每项控制指定明确的负责人。
• 将审计视为把安全工作做好的副产品。

8. 通过审计并非目标

审计通过仅说明，被测样本中的范围内控制措施运行有效。它并不代表组织是安全的；合规不等于安全。我见过的最好的团队，都把审计视为把安全工作做好的副产品，而不是安全工作的目的。

如果你只能记住一件事：明确你要做什么，始终如一地去做，让证据自然积累。差距分析是查看你当前控制措施覆盖范围的一个好去处。

常见问题

审计发现最常见的原因是什么？

根据我的经验，主要是控制措施确已执行，但证据缺失或不完整：审查已做却未记录，变更口头批准，样本总体与记录不符。

应如何准备安全审计？

持续运行控制措施并同步留存证据，检查文件是否与实际操作一致，并在审计师之前自行抽查样本走查一遍。

我们是否应该向审计师披露已知的弱点？

通常应该。对于已识别、并附有责任人和整改计划的弱点，审计师会认为这是一个运行正常的控制环境；而如果由审计师自行发现，则会被视为监督存在缺口。