4.10 渗透测试与红队演练

概述与动机

你可以构建威胁模型所要求的每一项控制措施，却依然不知道它们是否真正有效。文档说防火墙会阻断那个端口，代码评审说输入已经过验证，策略说最小权限原则已被落实。进攻性安全（offensive security）正是在一个有动机的攻击者真正施压时，检验这一切是否属实的方式。本章讨论的是在获得授权的前提下，有意识地攻击你自己的系统，从而在真正的对手之前发现这些弱点。

这门学科横跨一个光谱。轻量的一端是漏洞扫描：使用自动化工具探测已知缺陷和错误配置。中间是渗透测试：由一名技艺娴熟的人员将多个弱点串联起来，针对一个明确的目标证明其可被利用。远端是红队演练：一场目标导向的行动，在人员、流程和技术层面模拟真实的对手，检验的是你的检测和响应能力，而不仅仅是预防能力。三者各自回答不同的问题，混淆它们是组织浪费金钱、并用虚假的安心自我安慰的最常见方式。

本章有意与相邻章节区分开来。第 4.4 章讲的是安全运营：防御性的、监控性的一面，负责监视威胁并作出响应。本章则是与之相对的进攻方，检验那种防御是否真正有效。第 4.9 章讲的是安全软件开发生命周期，安全性被内建到代码的设计和交付方式之中；而进攻性测试则是从外部验证该生命周期产出的成果。本章还建立在第 4.1 章的基础与文化以及第 4.2 章的应用安全实践之上。

对大型企业而言，进攻性测试既是一种降低风险的工具，也是一项监管义务。支付处理机构、银行和医疗服务提供商都面临明确的测试要求。对政府而言，利害关系触及国家安全和公众信任：这里的对手是资源充足的民族国家，其攻击目标运行着选举、福利和关键基础设施系统。在这两种情境下，价值都不在于报告本身，而在于你修复了什么、以及你学会多快地检测到下一次入侵。

关键原则

让测试活动匹配你要回答的问题：扫描、渗透测试和红队演练回答的是不同的事情。
在任何人触碰系统之前，先取得书面授权和明确的交战规则。
发现的问题在被修复和复测之前毫无价值；要像对待其他工作一样跟踪它们。
红队存在的意义是让蓝队变得更强，而不是为了取胜。
要模拟真实对手及其技术手段，而不是套用通用检查清单。
要衡量检测和响应能力，而不仅仅是发现漏洞的数量。
要警惕表演式测试：一场刻意设定为能够通过的测试看起来很亮眼，却什么也证明不了。

建议

理解进攻性安全的光谱

首先要弄清楚你购买的到底是什么。漏洞扫描覆盖面广、全自动、成本低；应对你的资产持续运行，以捕获已知的常见漏洞和暴露（CVE）和错误配置。它会产生大量结果和误报，也无法告诉你某个缺陷在具体环境中是否真的可被利用。渗透测试则是让一名技艺娴熟的测试人员在固定的时间窗口内针对一个明确的目标展开工作，将多个弱点串联起来以证明真实的影响：这个扫描器发现的问题，加上那个薄弱的权限设置，最终导致获得域管理员权限。它回答的是”这个具体的东西能否被攻破，破坏程度有多严重”。

红队演练回答的是一个更大的问题：“如果一个坚定的对手针对我们发起攻击，我们能否察觉，能否将其阻止。“它是目标导向的（例如窃取这份数据集、抵达这套控制系统），覆盖包括人员和物理访问在内的完整攻击面，而且通常在不预先通知防御方的情况下进行。紫队演练则打破了这堵墙：红队和蓝队在同一个房间里协同工作，攻击方执行一项技术手段，防御方则观察自己的工具是否能够捕捉到它，并实时调优检测规则。紫队演练往往能以更低的成本带来更大的防御改进，因为每一个动作都成为一次教学时刻。

刻意地选择黑盒、灰盒还是白盒

你向测试人员透露多少信息，决定了你能学到什么。黑盒测试除了目标之外什么都不提供，模拟的是一个没有任何内部信息的外部攻击者；它更贴近现实，但速度较慢，测试人员可能把整个预算都花在侦察上，而真正的对手可能要用数月时间来做这件事。白盒测试则交出源代码、架构图和凭据，让测试人员能够深入挖掘，在有限的时间内覆盖更多范围。灰盒介于两者之间：掌握一些信息、一些凭据，模拟的是一个已经做过功课的攻击者，或是一名心怀恶意的内部人员。

对于大多数应用程序测试而言，灰盒或白盒能带来更高的回报，因为你付费购买的是分析的深度，而不是让测试人员重新摸索一遍你的子网布局。把黑盒测试留给那些”发现阶段本身的真实性”正是你想要测试的场景，例如衡量一个外部人员能从你公开的信息足迹中获取多少信息。要明确说明你委托的是哪一种，因为一份收获寥寥的黑盒报告，既可能意味着你确实安全，也可能意味着测试人员的时间全都耗在了外围侦察上。

仔细界定范围，并写明交战规则

范围界定是测试成败的关键所在。一份交战规则文档界定哪些在范围之内、哪些不在，允许使用哪些技术手段，测试窗口期，所覆盖的系统和网络，数据处理要求，以及双方的应急联系人。它要指明哪些生产系统是禁区或需要格外小心，规定测试人员一旦发现真正危险的情况就必须停止的规则，并说明如果他们意外撞见真实的攻击者活动或真正敏感的数据该如何处理。

要写明升级路径，以及一封”免罪声明”：万一在测试过程中安全人员或执法部门对测试人员提出质疑，他们可以出示的授权证明。要事先约定发现结果如何存储和传输，因为一份渗透测试报告本质上就是一张如何攻破你的地图，必须得到相应的保护。范围窄，会在小范围内产生深入的发现；范围广，则会在大范围内产生浅层的覆盖。要有意识地做出选择，并且绝不允许范围在测试过程中未经重新授权就悄悄扩大。

把授权当作测试与犯罪之间的分界线

将渗透测试人员与犯罪分子区分开来的唯一一件事，就是授权。访问未经授权允许你访问的系统，在美国的《计算机欺诈与滥用法》以及其他地区的类似法律下都构成犯罪，良好的动机并不能作为辩护理由。授权必须以书面形式，由真正拥有授予权限的人出具，必须准确覆盖范围内的系统和技术手段，并且必须在工作开始之前签署完毕。

第三方系统会让这件事变得复杂。你的云服务商、软件即服务（SaaS）供应商，以及任何共享基础设施，都可能有自己的测试政策，而你无法对自己并不拥有的资产授权发起攻击。要核查供应商的规则，在需要时申请许可，并将测试限定在你自己的租户范围之内。针对员工的社会工程学测试，会引发关于同意和心理伤害的伦理与法律问题，你必须提前想清楚。如有疑问，就请法律顾问介入；一次沟通的成本，与一起未经授权访问事件的成本相比微不足道。

权衡内部团队与第三方测试人员

内部红队熟悉你的环境，与防御方建立起关系，并且能够持续进行测试，而不是每年一次集中突击。但这种熟悉本身也是一种局限：他们和你共享同样的盲点与组织内的既定假设，而当他们向与被测系统相同的领导层汇报时，其独立性也可能受到质疑。第三方公司则带来新鲜的视角、专业化的技能，以及审计方和监管机构往往要求的独立性，但他们的上手速度较慢，单次测试的成本更高，而且报告一交付就会离开。

大多数成熟的项目会两者并用。内部团队负责持续的对手模拟、检测调优，以及让紫队演练富有成效所需的深层环境知识。外部公司则提供周期性的独立验证，满足 PCI DSS 等标准对独立性的要求，并探查你自己人已经习以为常、不再留意的领域。无论你使用哪一种，都要坚持测试人员必须具备相应资质：像 OSCP（Offensive Security Certified Professional，攻防安全认证专家）这样的认证以及经过验证的实践经验，比一份精美的销售演示文稿重要得多。

开展漏洞赏金计划与协同披露

一项漏洞赏金计划邀请外部研究人员发现并报告漏洞，以换取认可和报酬。它为你提供了一种持续的、众包式的测试，涵盖了你不可能一次性全部聘用的各种技能，而且你只需为真实的发现付费。它不能替代结构化的渗透测试，因为研究人员会追逐有报酬的目标，可能会忽略整整一类问题，但它是发掘创造性攻击手法的强大补充。

在开展付费赏金计划之前，你需要一份协同漏洞披露政策：一个已公开发布、容易找到的渠道，让任何人都能安全地报告安全问题；一项不会对出于善意的研究人员追究法律责任的承诺；明确的响应时限；以及一套用于对收到的问题进行分诊和修复的内部流程。一份 security.txt 文件和一个清晰的报告地址是最低限度的要求。政府机构越来越多地要求面向公众的系统必须制定漏洞披露政策，而没有报告渠道并不会阻止研究人员发现漏洞，它只会阻止他们安全地告诉你。

使用假设已被入侵的方法与对手模拟

仅针对边界展开的测试，假设攻击者是从外部开始的，但真实的入侵事件往往始于一个被钓鱼获取的凭据，或者一台已经身处内部的失陷笔记本电脑。假设已被入侵演练让测试人员一开始就带着一个立足点，比如以普通员工的身份获得访问权限，然后考察他们从这里能走多远。这直接测试了你的内部分段、检测能力和爆炸半径控制措施，而不是把一切都押在一道终将被突破的边界之上。相比看着红队人员苦苦啃一道被加固过的边缘，这通常能更好地利用红队的时间。

要借助 MITRE ATT&CK 将演练建立在真实的对手行为之上，这是一个公开的知识库，记录了攻击者实际使用的战术和技术手段，按照从初始访问到数据渗出的顺序组织。对手模拟会选定一个已知会针对你所在行业的威胁行为体，重现其有文档记录的技术手段，并测试你是否能够检测并阻止每一个步骤。这远比一次泛泛的攻击更有用，因为它将你的防御能力与你实际面对的特定对手进行了映射，产出的发现也能供你的威胁情报团队排定优先级。

将发现反馈给蓝队和检测工程

进攻的意义在于成就更好的防御。红队的每一个动作都是一次提问的机会：我们的工具产生信号了吗，有人看到了吗，他们的响应是否正确。开展测试时，要让每一项技术手段都对应到一项你已经具备、需要构建、或需要调优的检测能力。这就是检测工程：把攻击者的行为转化为可靠的告警，也正是红队价值不断累积的地方。“横向移动过程中我们没有被检测到”这样的发现，应当转化为一条新的检测规则，并通过重新运行该技术手段来验证。

桌面推演将这一做法延伸到决策层面。召集那些真正会响应实际事件的人员，在纸面上完整走一遍一个贴近现实的场景：谁来宣布事件，谁去联系法务，谁来决定让某个系统下线。桌面推演成本低廉，能够暴露出技术测试所遗漏的角色和沟通方面的缺口，并为第 9.3 章的事件管理真正启动时最关键的人员做好准备。要把技术性的红队演练与定期的桌面推演结合起来，让你的工具和你的人员都得到锻炼。

跟踪修复情况并进行复测

一份没有人采取行动的漏洞报告本身就是一种负债，因为这意味着你如今是在明知故犯地运行一个审计人员可以援引的缺陷。要把每一个发现都纳入你日常的工作跟踪系统，指定负责人、严重程度，以及与风险挂钩的截止日期。严重的发现要按紧急情况处理；较低级别的发现则以诚实的优先级进入待办事项列表。真正重要的指标是修复所需的时间，而不是报告所需的时间。

复测让整个闭环得以完成。修复上线之后，测试人员（或一项自动化检查）要确认漏洞确实已经消失，并且这次修复没有打开新的漏洞。如果没有复测，“已修复”就只是一种期望，而不是事实，许多发现之所以反复出现，正是因为修复不完整，或是某次回归重新引入了它们。像 PCI DSS 这样的标准明确要求这一闭环。要把复测写进测试合同，使其不至于被遗忘。

权衡：优点与缺点

方法	最适合的场景	优点	缺点
漏洞扫描	对已知缺陷的持续覆盖	成本低、覆盖广、自动化、频率高	噪声多；无法证明可利用性
渗透测试	证明对明确目标的影响	具备深入的人工洞察；真实的利用链	只是某一时间点的快照；范围较窄；成本高
红队演练	测试检测和响应能力	贴近现实；锻炼人员和流程	成本高；耗时长；需要成熟的蓝队
紫队演练	快速改进检测能力	每单位成本的学习收益高；协作性强	现实性较弱；需要两支团队同时到位
漏洞赏金	持续的众包式发现	按发现付费；技能来源多样	覆盖不均；分诊负担重；需要配套流程

核心的张力在于真实性与学习速度之间。一支隐蔽的红队是你能开展的最贴近现实的测试，但它带来的经验教训来得很慢，而且只有在整个行动结束之后才会出现，一支尚不成熟的蓝队从被悄无声息地击败中学不到什么东西。紫队演练则牺牲了突然性，以最大化防御方进步的速度。第二重张力是广度与深度之间的取舍：扫描能浅层地覆盖一切，而渗透测试能深入地覆盖一小片区域。成熟的项目会将这些方法分层组合，而不是只选择其中一种，在持续扫描之上叠加周期性的深度测试，以及偶尔开展的全范围红队行动。错误的做法是每年只购买一次渗透测试，把报告归档，然后就认为问题已经解决。

与团队讨论的问题

当我们委托进攻性测试时，我们是否清楚自己实际想问的是哪个问题，测试活动是否与之匹配？ 许多组织购买了一次”渗透测试”，得到的却是一份带人工撰写摘要的漏洞扫描结果，随后便以为自己已经测试过防御能力，而实际上只是检查了已知缺陷。另一些组织在检测能力还很不成熟时就委托红队演练，结果这次演练只证明了大家早已知道的事情。请带上你们过去三次测试活动的范围界定和最终报告，逐一追问它们是否回答了你们真正需要回答的问题：对已知漏洞的覆盖情况、特定目标的可利用性，还是检测和响应入侵的能力。这个答案应当塑造出一种与你们成熟度相匹配的、经过深思熟虑的扫描、渗透测试与红队或紫队演练的组合。
报告交付之后，某个发现会经历什么，我们又该如何证明它已经被修复？ 进攻性安全的价值完全体现在修复之中，然而许多项目却以报告的篇幅厚度、而不是风险的缩减程度来衡量成功与否。请追溯上一次测试活动中的一个真实发现：谁负责它、它在与功能开发工作的比较中是如何被排定优先级的、它是何时被修复的，以及是否有人确认过修复确实有效。如果你拿不出这样一条追溯链条，那么你的测试正在产生一些你并未据此采取行动的知识，这比不知道还要糟糕，因为现在你是在明知故犯的情况下暴露在风险之中。这场讨论的产出，应当是一套带有负责人、基于风险的截止日期、并将强制复测写入每一份合同的、可被跟踪的修复工作流。
我们的红队是在让蓝队变得更强，还是仅仅在记比分？ 一支为未被检测到的胜利而庆祝、并把自己的技术手段藏着掖着的红队，看着热闹却毫无用处。在对抗的表象之下，这种关系应当是协作性的：每一项未被检测到的技术手段都应转化为一条新的检测规则，每一条成功的攻击路径都应为分段策略提供依据，两支团队应当共同进行复盘。问问你的防御人员，他们从上一次红队演练中学到了什么，是否有任何具体的检测能力或控制措施因此发生了改变。如果老实的答案是”什么都没有”，那你花的钱只是买了一场表演，应当转向紫队演练，以及与检测工程明确挂钩的对手模拟。
在下一次测试活动开始之前，我们是否已就范围内的每一项资产、包括我们并不拥有的那些资产，取得了书面授权？ 授权是渗透测试与计算机犯罪事件之间的分界线，而在一个大型组织里，测试人员将会触碰到的系统很少局限在单一的所有权边界之内：它们跨越云租户、软件即服务平台、托管网络，以及由合作伙伴或供应商掌控的共享基础设施。与之相抗衡的压力是速度，因为追要签署的许可和供应商的测试政策是一件缓慢的事情，在截止日期临近时很容易让人想要跳过。请带上交战规则草案、标明每个系统负责人的资产清单、相关的云服务商和供应商测试政策，以及一旦在测试过程中受到质疑、测试人员可以出示的已签署授权函。对企业和政府工作而言，暴露的风险尤为尖锐：针对一个共享平台的未经授权探测，可能违反合同、触发监管报告，对一个公共机构而言，还可能成为”政府攻击了自己无权触碰的系统”这样的头条新闻，因此在任何人开始工作之前，都应先取得法律顾问的签字确认。
我们是在投资内部红队、外部公司，还是两者兼有，这种配置是否与我们实际的需求相匹配？ 这是一项自建还是外购的决策，涉及真金白银，也会带来持续多年的后果：内部团队需要支付薪资和工具成本，能提供持续的对手模拟和深厚的环境知识；外部公司单次测试的成本更高，但能带来新鲜的视角、专业化的技能，以及审计方和监管机构所要求的独立性。这里的张力在于，两者各自弥补对方的盲点，所以把它们当作彼此的替代品、而不是互补品，往往会留下缺口。请带上你们目前在这两方面各自的投入、从事这项工作的人员所拥有的资质认证和已被证明的过往业绩、测试活动的节奏，以及你们所遵循的标准所强加的独立性要求。在受监管的企业中，PCI DSS 及类似的制度可能会强制要求外部独立测试，无论你的内部团队有多优秀；在政府部门，采购规则以及在获得运营授权之前需要展示一种”保持距离”的独立评估的要求，往往使经过认可的第三方成为强制性的选择，而非可选项。
我们是否为外部研究人员提供了一个安全的漏洞报告渠道，我们是否准备好处理收到的报告？ 一个面向公众的大型组织，无论是否主动邀请，都已经在被研究人员探测，唯一的问题在于他们能否安全地告诉你，还是被迫将发现公开或出售。与之相抗衡的考量是准备程度：开放一项协同披露政策或一个付费漏洞赏金计划，会带来大量报告和分诊负担，而一个为从未修复的发现付费的项目，比什么都不做还要糟糕。请带上你们目前的 security.txt 文件和报告地址（如果有的话）、你们的接收与分诊流程、你们能够诚实承诺的响应时限，以及修复收到问题所需的待办容量。对政府机构而言，公共系统上的漏洞披露政策正日益成为一项强制指令，而不是一种礼节性的姿态；对企业而言，一个运营良好的赏金计划，既是创造性发现的来源，也是客户尽职调查过程中成熟度的证明，因此真正的决策问题，与其说是要不要建立这样一个渠道，不如说是你是否配备了足够的人手去兑现它。

行业视角

初创企业。 你负担不起一支内部红队，因此要转而分层构建成本低廉的覆盖能力。把漏洞扫描接入你的部署流水线，在每次构建时捕获已知的依赖缺陷；发布一份 security.txt 文件和一份简单的协同披露政策，让研究人员能够联系到你；并在达成第一笔企业客户交易之前，向一家信誉良好的公司委托一次灰盒渗透测试，将每一个发现追踪到确认修复为止。速度比全面的项目更重要：挑选那一次能够解锁一笔交易或消除你最大风险的测试，其余的先放一放，等公司成长起来再说。

小型企业。 由于没有专职的安全人员，预算也紧张，应当选择购买而不是自建。使用一项托管扫描服务，并以适度的节奏聘请外部渗透测试公司，而不是搭建任何内部能力，同时确保合同中包含复测条款，使”已修复”成为被证明的事实，而不是想当然的假设。对你而言，价值最高、成本最低的举措，是提供一个公开的漏洞报告渠道，再加上快速打补丁的纪律，因为像你这样规模的企业，在现实世界中遭遇的大多数入侵，都是通过已知的、未打补丁的弱点发生的。

企业。 在规模化的场景下，挑战在于跨众多团队的治理。要在满足 PCI DSS 等标准要求的周期性独立外部渗透测试之下，持续运行漏洞扫描；维持一支内部红队，负责持续的对手模拟和紫队演练；并将修复工作作为一个被跟踪的组合来管理，配备负责人、基于风险的截止日期和强制复测。要把每一项未被检测到的技术手段都反馈进检测工程之中，并产出合规团队和董事会所期望的审计证据、覆盖率、时间线和结案率。

政府。 采购规则、透明度和公共问责制塑造了整个项目。要按照日益增多的强制指令，为面向公众的系统维持一项漏洞披露政策；对于作为系统运营授权前置条件的渗透测试，使用经过认可的独立评估机构；并以情报合作伙伴所标记的特定民族国家行为体为原型来构建对手模拟。要以额外的严谨态度对待授权、范围界定和数据处理，因为这些系统运行着选举、福利和关键基础设施，并将复测作为任何系统能够继续在线运行的前提条件。

示例

初创企业。 一家二十人规模的金融科技初创企业负担不起内部红队，于是它尽力分层构建能力。自动化漏洞扫描通过其流水线在每次部署时运行，及早捕获已知的依赖缺陷。它发布了一份 security.txt 文件和一份简单的协同披露政策，等产品趋于稳定之后，又在一个公开平台上开放了一个规模适中的漏洞赏金计划，为真实的漏洞向真实的研究人员付费。在签下第一个企业客户之前，它向一家信誉良好的公司委托了一次针对应用程序的灰盒渗透测试，在日常的工单跟踪系统中将每一个发现跟踪到结案，并额外付费进行复测以确认修复效果。这种分层的方法，以初创企业能够承受的成本，提供了可信的安全覆盖，而渗透测试报告也成为它在客户尽职调查过程中可以出示的证据。

企业。 一家处理银行卡支付的跨国零售商必须满足 PCI DSS 的要求，该标准要求至少每年一次、并在发生重大变更之后开展内部和外部渗透测试，还要求进行分段测试以证明持卡人数据环境已被隔离。该企业在数千项资产上持续运行扫描，委托独立的外部渗透测试以满足标准要求，并维持一支内部红队，针对已知会盯上零售行业的威胁行为体，开展以 MITRE ATT&CK 为基础的假设已被入侵演练。该红队与第 4.4 章所述的安全运营职能紧密协作：每一项未被检测到的技术手段都会转化为一张检测工程的工单，每季度的紫队会议则用于调优告警规则。修复工作按基于风险的截止日期进行跟踪，整个项目产出第 4.6 章合规要求所需的审计证据。

政府。 一家负责运行公民福利系统的国家机构面临着民族国家级别的对手，同时也肩负着保护敏感个人数据的公共使命。按照日益增多的政府指令要求，它在所有面向公众的系统上维持一项漏洞披露政策，为研究人员提供一个安全的报告渠道。在任何系统上线之前，独立的第三方评估机构会作为授权流程的一部分开展渗透测试，持续监控也包括不间断的扫描。该机构以情报合作伙伴所标记的特定威胁团伙为原型开展对手模拟，并定期开展桌面推演，演练一次真实入侵所需要的事件响应和法律协调工作。发现结果被纳入一套具有强制时限的正式修复项目，而复测则是任何系统保持运营授权的前提条件。

商业论证：动机、投资回报率与总拥有成本

进攻性安全的回报，就是那场你没有遭受的入侵事件。一次严重的数据泄露，在直接响应、监管罚款、法律责任、客户流失和声誉损害方面会耗费数以百万计的资金，而其中最昂贵的单一因素，是一次入侵未被察觉所持续的时间。红队演练和紫队演练正是通过缩小”失陷”与”检测”之间的差距，直接攻击这个数字。一次渗透测试发现了一条通往你客户数据库的可利用路径，并在攻击者发现它之前得到修复，仅凭这一次避免的事件，就能让整个项目的投入获得数倍的回报。

也存在一些硬性驱动因素。PCI DSS 强制要求任何处理银行卡数据的机构进行渗透测试。各类框架和政府的运营授权制度要求在运营之前及运营期间进行独立评估。企业客户则把近期的渗透测试报告作为签约条件加以要求。在这些情况下，测试并非可选项，唯一的问题在于，你是否从这笔无论如何都必须花出去的钱里，真正提取出了安全价值。

总拥有成本所包含的，远不止测试委托本身的费用。如果你自建内部团队，就要为其工具和人员做预算；漏洞赏金计划会带来分诊方面的负担；而最重要的是，各项发现所催生的修复工作，才是真正花钱的地方。一个只委托测试、却在修复上投入不足的项目，是两头都不讨好的最坏结果：它先为坏消息付了钱，等到被忽视的发现被人利用时，还要再付一次代价。要向领导层证明这件事的合理性，就要把测试与他们所关注的指标挂钩：平均检测时间、平均修复时间、已结案的审计发现，以及你最关键资产上的风险降低程度。

反模式与陷阱

改头换面的扫描： 把一次漏洞扫描包装成渗透测试出售，交付的只是工具的输出结果，没有经过人工验证或利用链的串联。
报告即弃： 把交付物本身当作目标，把发现的问题归档了事，从不跟踪修复或复测。
划定范围以求通过： 刻意缩小测试范围，把最可能出问题的系统巧妙地排除在外，从而得到一份干净却毫无意义的报告。
把红队当记分牌： 一支囤积技术手段、只顾庆祝胜利的对抗性团队，而不是致力于让防御方变得更强。
对尚不成熟的蓝队进行隐蔽测试： 在你还不具备任何检测能力之前就秘密运行红队，导致这次演练只证明了你早已知道的事情。
没有授权或范围模糊： 在没有书面许可的情况下开始工作，或者让范围蔓延到你并不拥有的系统，招致法律灾难。
执迷于边界： 只测试外部边缘，而忽视了攻击者是从内部开始这一”假设已被入侵”的现实。
忽视披露渠道： 没有为外部研究人员提供安全的报告方式，导致他们转而公开发布或出售发现。
表演式指标： 只统计发现的漏洞数量，而不是风险降低程度、检测能力改进程度和修复时间缩短程度。

成熟度模型

第 1 级，启动： 测试是偶发的、被动式的，通常只是每年一次为了走个流程而做的渗透测试，或仅在发生事件之后才被触发。报告归档后很少有后续跟进，修复工作未被跟踪，不存在披露渠道，对真实入侵的检测能力未经测试，很可能也并不存在。
第 2 级，发展： 漏洞扫描和渗透测试已经存在，但在各团队之间并不一致，有些团队持续扫描，有些则完全没有。发现结果会被记录在某个地方，但负责人和截止日期时有缺失，复测是临时性的，协同披露渠道可能覆盖了部分系统，却没有覆盖整个资产范围。
第 3 级，标准化： 进攻性测试是一套有文档记录、在全组织范围内强制执行的项目，而不是一次孤立的活动。扫描持续运行，其上是按照既定节奏、并在重大变更之后委托的计划性渗透测试；交战规则和授权已成为标准做法；每一个发现都由负责人和基于风险的截止日期跟踪至结案；复测是强制性的；协同披露政策覆盖所有面向公众的系统。
第 4 级，管理： 项目会被对照基线进行度量和控制。你会跟踪平均检测时间和平均修复时间、产生信号的红队技术手段所占的比例、针对与你所在行业相关的 MITRE ATT&CK 技术手段的检测覆盖率、发现问题的复发率，以及披露响应时间，并将每一项指标对照目标进行考核，一旦出现偏离就采取行动。假设已被入侵演练和对手模拟已成为常规做法，红队持续运作，发现结果反馈进检测工程，是否放行的决策依据的是证据而不是主观看法。
第 5 级，协同： 红队和紫队演练在整个组织范围内实现了整合，并具备自适应能力。每一项技术手段都对应着一项经过测试的检测能力，对手模拟会随着情报的变化，持续跟踪当前正针对你所在行业的特定威胁行为体，整个项目也会在学习的过程中不断优化自己的范围、技术手段和衡量指标。进攻性测试、安全运营、检测工程和事件响应作为一个统一的闭环运作，能够随着时间的推移，可衡量地缩小”失陷”与”检测”之间的差距。

讨论思路

如果今天真的有攻击者以普通员工的身份获得了立足点，在被人发现之前，他们能走多远，你又是如何知道的？
你们最近的测试活动中，哪些是真正贴近现实的，哪些又被刻意设定了范围，使可能出现的失败被巧妙地排除在外？
上一次测试中的多少发现至今仍未关闭，这说明你们真正的瓶颈是测试本身，还是修复环节？
外部研究人员是否有一个安全、显而易见的渠道向你们报告漏洞，报告到达之后又会发生什么？
你们的事件响应人员上一次在纸面上演练一场入侵是什么时候，那次桌面推演有没有暴露出技术测试遗漏的缺口？
你们衡量的是发现的漏洞数量，还是检测能力的改进程度和风险的降低程度？

关键要点

进攻性安全是一个光谱：扫描发现已知缺陷，渗透测试证明可利用性，红队演练测试检测和响应能力。要让测试活动匹配你要回答的问题。
书面授权和明确的交战规则，是安全测试与犯罪之间的分界线；绝不能跳过这一步，尤其是在你并不完全拥有的系统上。
价值体现在修复和复测之中，而不是报告本身。要用负责人、基于风险的截止日期和确认过的修复，来跟踪每一个发现。
红队存在的意义是让蓝队变得更强。要把发现反馈进检测工程，优先选择紫队演练和假设已被入侵演练，并通过 MITRE ATT&CK 将演练建立在真实的对手技术手段之上。
要衡量检测和响应能力，而不仅仅是漏洞数量，并警惕那些被设定为能够通过的测试活动，它们只会带来安心的错觉，而不是真正的安全。

参考文献与延伸阅读

Georgia Weidman, Penetration Testing: A Hands-On Introduction to Hacking
Peter Kim, The Hacker Playbook 3: Practical Guide to Penetration Testing
Jim O’Gorman, Devon Kearns, and Mati Aharoni, Metasploit: The Penetration Tester’s Guide
Joe Vest and James Tubberville, Red Team Development and Operations: A Practical Guide
MITRE, MITRE ATT&CK framework and knowledge base
Payment Card Industry Security Standards Council, PCI DSS Requirements and Testing Procedures and Penetration Testing Guidance
National Institute of Standards and Technology, NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
Dafydd Stuttard and Marcus Pinto, The Web Application Hacker’s Handbook