防守者最重要的问题，为什么红队无法回答

1931 年，科学家、哲学家阿尔弗雷德•科尔兹布斯基 (Alfred Korzybski)写道：“地图并不代表领土。” 他的意思是，所有模型，比如地图，与现实相比都会遗漏一些信息。在网络安全行业，用于威胁检测的模型也具有类似的局限性，因此防御者应该经常扪心自问：“我的威胁检测模型是否检测到了它本应检测到的所有内容？” 或者，换个问法：他们的威胁“地图”与威胁“现实”有多接近？渗透测试和红蓝演习一直在尝试回答这个问题。

不幸的是，它们并不能很好地回答这个问题。对其他许多事情来说，红队也许很有用，但对于防护的有效性这个问题，红队其实是一个错误的方案。其结果是，防守者并不能真实地了解他们的防守强度如何。

01 红队评估本质的局限性

红队评估并不能很好地验证正在运行的防御措施是否有效。就其本质而言，他们只测试对手可能使用的几种攻击技术的一些特定变体。正因为他们试图模仿现实世界的真实攻击：先侦察，再入侵，然后横向移动等等。但所有防守者从中学到的只是针对自身防御措施的特定攻击技术和变体。同样的攻击技术所衍生出的其他技术或变体，这些防守者是无从得知的。

换句话说，如果防守者没有发现红队，是因为他们防护手段不足吗？还是因为红队选择了一个他们没有准备到的攻击技术？另一方面，如果他们确实发现了红队，就能证明他们的威胁检测很全面吗？可能只是恰好“攻击者”选择了一个防守者提前准备好的技术？我们无从得知。

这一问题的根源是，红队没有使用足够多的变体攻击来判断防护的整体强度（当然从另一个角度来看，红队确实提供了一些价值）。攻击者虽然有比你想象得多的更多选择，例如我研究过的一项技术有 39,000 种变化，还有一项有240万！但把全部或大部分这些变体用来测试是不可能的。因此有限的测试就会给人一种错误的安全感。

02 甲方对厂商的态度：信任，但有待验证

为什么对威胁检测有效性的验证如此重要？简而言之，这是因为甲方的安全负责人想要验证厂商是否确实对他们声称要阻止的行为进行了全面的检测。甲方的安全态势很大程度上仍然依赖于供应商。

甲方安全团队选择并部署入侵防御系统 (IPS)、端点检测和响应 (EDR)、用户实体行为分析 (UEBA) 或其他类似工具，也相信所选供应商的软件能够检测到其声称会检测到的行为。但甲方安全负责人越来越希望能够验证厂商们的这些“声称”。

笔者已经记不清听过多少次这样的对话了：红队报告了他们入侵成功，蓝队说不可能，红队耸耸肩说“好吧，我们是这样这样这样做的……”安全团队都想要探究这其中的不一致性到底在哪里。

03 对数以万计的变体进行测试

尽管测试攻击技术的所有变体并不实际，但我相信测试其中的代表性样本是可行的。为此，安全团队可以使用诸如 Red Canary 的开源项目 Atomic Testing （为下文表述方便，暂译为“原子化测试”）这样的方法，即对每个技术使用多个测试用例进行单独测试（而不是作为总体攻击链的一部分）。

如果把红队演习比作一场足球训练赛，那么原子化测试就像球员的单项训练——并非所有对抗都会在一场完整的训练赛中发生，但为了应对可能的对抗，针对性的单项训练仍很重要。两者都应该是全面训练计划的一部分，回到本文来，就是全面安全计划的一部分。

他们所要做的，是使用一组测试用例涵盖相关技术的所有可能变体。构建这些测试用例对防守者来说是一项至关重要的任务；它将直接关系到对威胁检测手段的验证效果。就像笔者开篇提到的类比，这些测试用例构成了威胁的“地图”。一张好地图，会省略不重要的细节并突出显示重要的细节，从而建立一张分辨率稍低但全面准确的威胁全景图。如何构建这些测试用例是我仍在努力解决的一个问题（到目前为止我已经梳理出了一些工作）。

另一个验证当前威胁检测有效性的解决方案是使用紫队——让红队和蓝队一起工作，而不是将彼此视为对手。红蓝之间的合作好处多多，因此紫队服务逐渐兴起。但目前大多数这些服务仍不能解决根本问题。即使已经有更多的合作，但仅关注少数攻击技术和变体仍是其最大的局限性。紫队服务仍需要发展。

04 构建更好的测试用例

构建良好测试用例的挑战（以及红蓝队合作本身还不够的原因）部分在于我们对攻击进行分类的方式掩盖了很多细节。网络安全通过三层视角看待攻击：战术、技术和程序 (TTP)。像凭证窃取这样的攻击可以通过许多不同的程序来完成，例如 Mimikatz 或 Dumpert，并且每个程序可以有许多不同的函数调用序列。快速定义一个“程序”是什么很困难，但通过正确的方法是可能的。安全行业尚未发展出一个良好的系统来命名和分类所有这些细节。

如果你正寻求对威胁检测的有效性进行验证，笔者的建议是，构建能够测试更广泛可能性的代表性用例 —— 这是一个事半功倍的方法，能够帮助防守者最终回答红队苦苦挣扎的问题。

—【 THE END 】—