导语：本文将延续上一篇文章的内容，继续探讨如何确认红队演练的评估范围，在下面的章节中，作者详细介绍了在确定评估范围得到过程中需要注意的几个问题，这些问题都是乙方在为客户服务以及甲方自建红队在执行演练活动时应该注意的事项，特别是在本文的最后，作者提到的混合网络环境中执行红队演练时应注意的法律问题。
前言
阅读这本独特的书籍，能够让你在进行进攻性安全交战时利用多种高阶技术。你将了解实际的谍报技术、操作指南和进攻性安全最佳实践，来开展专业的网络安全交战，而不仅仅是漏洞利用、执行脚本或使用工具。
本书将向你介绍基本的进攻性安全概念。重点说明了评估和道德黑客的重要性，并讨论了自动化评估技术。现代进攻性安全的现状以及面临的挑战。
这本书的作者是奥克利博士（Dr. Jacob G. Oakley），他曾在美国海军陆战队工作七年多，是美国国家安全局(NSA)下属的海军陆战队网络空间司令部作战兵种创始成员之一，之后担任海军陆战队的高级操作员和一个师的技术主管。入伍后，奥克利博士撰写并教授了一门高级计算机操作课程，最终回到米德堡的任务支持中心。后来，在解除政府合约后，他在一家私人公司为商业客户提供威胁仿真和红蓝对抗服务，并担任渗透测试的主要负责人以及渗透测试和网络运作的主管。他目前是一名政府客户的网络安全专家。奥克利博士在陶森大学(Towson University)完成了信息技术博士学位，主要研究和开发进攻性网络安全方法。他是迈克·奥利里(Mike O 'Leary)所著《网络行动，第二版》(Cyber Operations, second edition)一书的技术评论员。
系列文章目录：
开展专业的红蓝演练 Part.7：进攻性安全面临的挑战（上）
开展专业的红蓝演练 Part.8：进攻性安全面临的挑战（下）
本文将延续上一篇文章的内容，继续探讨如何确认红队演练的评估范围，在下面的章节中，作者详细介绍了在确定评估范围得到过程中需要注意的几个问题，这些问题都是乙方在为客户服务以及甲方自建红队在执行演练活动时应该注意的事项，特别是在本文的最后，作者提到的混合网络环境中执行红队演练时应注意的法律问题。
之前的测试
之前是否有红队或渗透测试人员进行过测试，这个问题可能是理解客户需求的死胡同，也可能是金矿。从问这个问题中获得的信息严格地取决于客户是否愿意提供有用的信息。以下几个问题获得更细粒度的答案是有帮助的，问题如下：
1.评估是多久以前的事？
2.谁做的评估？
3.评估报告的结果是什么？
4.评估报告中的问题是否得到了缓解？
这些额外的问题帮助红队了解之前进行的进攻性安全评估是否有价值。
如果评估是多年前开展的，那么这些结果充其量只能作为补充信息，不能依靠这些信息来取代枚举或评估活动。如果上一次安全评估是最近进行的并且由于时间约束的存在将会影响红队的能力来满足组织的评估需求，有时候集中精力在之前的评估中未发现漏洞的主机上，可能会更有帮助，这样可以在有限的时间内尽可能多的覆盖攻击面。同样，如果评估结果很不错并且包括了枚举活动和结果，并且评估是在几个月或几周内完成的，则该信息可以帮助加速后续团队的评估速度。
要想对先前的评估活动信息的可靠性或有用性做出明智的判断，就需要知道是谁做的。有些公司比其他公司提供更好的服务，正如我在前面章节提到的，有些公司将漏洞扫描服务“美化包装后”推销为渗透测试服务。知道是谁做了以前的评估可以让当前的红队评估人员知道之前的安全评估质量。从非商业的角度来看，这也意味着我们要知道哪些有机资产可以预先评估。如果是最近进行了安全评估，并且是在组织内部没有正式的内部红队（有机红队）之前进行的，则由于缺乏熟练掌握技能的进攻性安全从业人员，评估的可靠性可能会大大降低。
如果进攻性安全的从业人员可以管理整个工作范围的质量，那么他们产出的评估报告可以更加多样化。许多优秀的道德黑客在产出报告、简报以及在编撰文档方面都很糟糕，因此他们低估了自己伟大才能所带来的好处。这也意味着，如果之前的安全评估是由一个非常有才能的团队完成的，但评估报告的内容不够丰富，那么产出的评估报告的信息对后续团队来说几乎毫无用处。稍后，我将讨论红队应如何最好地展示他们在文档编写和产出报告方面的才能。
如果在之前的安全评估中发现了问题，那么最好知道组织是否已经补救或缓解了这些问题。如果这些问题还没有得到缓解，那么这些信息就很有用处，可以用于进一步的枚举，或者是后续的良好实践，并确保在脆弱的系统上没有发现其他问题，也没有被之前的安全评估捕获。如果之前的安全评估发现的漏洞已经确认得到了缓解，那么检查客户是否已经真正解决了问题也是有价值的，也可以相对快速的产出结果。有时，特别是由于糟糕的实现或配置而导致的漏洞——即使已经进行了修复——但修复的只是一个症状而不是原因，那么深层次的问题对组织来说，仍然是威胁。记住，错误的安全感可能是对组织最大的威胁。
现有的安全防护
在理解红队应该提供的评估需求时，还必须考虑组织中现有的安全防御系统的成熟度。在询问完安全防御方面的成熟度后，我还想问以下几个问题:
1.安全防御体系里是否已经实现漏洞扫描？
2.系统的完整性和更新是强制的吗？
3.具备哪些监控、响应和取证能力？
这些问题的答案使红队能够对评估进行调整，从而为组织提供最有效的安全性改进建议。有时，组织可能没有好的或完整的答案来回答这些问题。在这种情况下，团队必须在暗中围绕这些主题前进。
如果组织还没有实现漏洞扫描，无论是手动的还是通过自动化的过程，这对红队来说都是严重的问题。此时，红队应该提供此功能作为评估的一部分，并在评估结果中指出组织缺乏漏洞扫描过程。特别是在一个短的评估窗口期间，覆盖至少所有范围内系统的漏洞扫描，对于客户来说，可能比深入研究几个特定的系统更有价值。如果系统的完整性和更新尚未执行，红队应该在其调查结果中指明这一点，并且至少应将评估的最初重点转向从远程角度确定所有系统上存在哪些漏洞，然后再尝试获得远程执行，并进一步侵入组织。如果外围布满了漏洞，帮助组织确定这些漏洞的位置比告诉组织在网络深处有一些机器存在潜在的远程代码执行漏洞更为重要。
关于安全防御成熟度的最后一个问题直接影响到红队在评估期间应该如何行动，以及应该如何确定其评估范围。道德黑客和红队的一个巨大好处是能够测试一个组织对攻击的反应。这包括组织中的监控能力如何能够识别攻击者，安全程序和技术如何让组织响应红队的评估，以及取证能力如何能够跟踪红队活动。如果一个组织不具备这些能力中的一项或多项，那么实施极其隐秘的情报技术和谨慎的枚举活动可能是不明智的。在红队枚举期间，谨慎地判断安全监控是否对评估行为起作用，是很有价值的演练。如果没有监控能力，则应该将这种能力的缺失标记在评估报告中，但是红队应该利用能力缺失这一事实加速完成枚举，并关注评估执行的其他部分。红队在评估过程中也会使用情报技术。如果没有取证或其他安全响应能力来评估已识别事件的结果，那么使用多种持久访问方法和多种 C2 基础设施可能是一种浪费。当取证和安全响应能力就绪时，评估其有效性非常重要；当组织不具备这些能力时，红队应该将其作为一项评估发现，并在评估窗口期间使用这一事实提高评估效率。
范围的覆盖区域
从非常直接的意义上说，组织的网络子集或者称为覆盖区域是确定在评估范围内的，并且通常由客户决定。它还与可用的评估窗口是否足以满足建议的覆盖区域有关。在这一章中，我们已经提到了一些需要评估的覆盖区域，例如特定的应用程序、系统或整个组织。覆盖区域可能已经被作为范围的一部分所讨论的问题的答案和需求所决定，但是关于范围的覆盖区域还有其他直接的含义。
在提出适当的安全评估范围的同时，客户可能会说，他们只希望评估外网可见的目标。这里可能有两个问题。组织可能对“从外网可见”的含义有错误的理解，因为这里说的“从外网可见”的资产里可能包含客户认为本身只能在内部访问的资产，但实际上由于错误配置等原因在外网上也可以访问的资产。这可能导致红队评估了客户认为自己已经沟通过的资产，而这些资产实际上超出了客户所期望的范围。这就是为什么在范围语言中只针对外部主机的笼统声明是不合适的原因之一。如果客户需要，应该定义出特定的主机。此外，客户可能希望红队完成某些任务，如评估监控和响应，这在与外网上的大量活动主机竞争时完成这些任务可能很困难。此外，应该向客户提出的真正问题是评估范围是否包括内部主机，以及它们是否可以从外部范围的主机转移到内部范围的主机。我从一些客户那里得到的印象是，尽管他们希望评估整个安全防御系统，但他们对红队从最初的受损主机转移到内网感到不舒服。我觉得这相当讽刺，因为大多数公司被入侵都是由内部发生的，比如通过社会工程学或内部威胁，而不是基于互联网的攻击。无论怎么样，重要的是要了解评估范围的影响，以及客户是否不提供特定主机的详细列表，至少应该包括通过跳板机进一步执行内网渗透方面以及不通过跳板机渗透内网方面。允许渗透到组织的其他部分会显著地增加评估范围覆盖区域，并且评估范围覆盖区域的大小可以成为评估能力的一个约束，从而在满足客户需求的同时达到窗口范围。优秀的红色团队应准备好了解并更改范围中包含的已经与组织商定好的范围。有时需要这样做，以便更充分地适应可能阻碍评估成功的其他因素。
无机约束
尽管客户和供应商有能力就进攻性安全约定的适当范围达成一致，但外部因素也会限制客户给出的评估范围。我所见过的最常见的情况是强制把云提供商带入评估范围内进行讨论。如果执行得当，向云环境进行一般推送对组织运营和安全是一件好事。这种趋势的增长意味着客户组织在云部署上托管一些功能性资产越来越普遍。在这些情况下，一个经常被忽视的方面是需要通过批准来测试这些资产。在许多情况下，与云供应商的用户和业务协议都有条款规定，要对他们托管的系统进行任何测试，都需要通知和批准。在某些情况下，这是严格禁止的。因为未经批准的攻击性安全服务是一种非法活动，重要的是要意识到这样一个事实：客户组织在测试之前可能没有从他们的云供应商那里获得这种批准。
在评估前，除了使用云和物理设备的混合组织所需要的明显和特定的批准之外，还有其他限制因素。如果客户拥有云资产，评估人员还应该询问作为评估范围的一部分所给出的地址是否为静态地址。只有当红队攻击的地址属于该客户时，客户组织的“出狱卡”才适用。如果在演练评估过程中，非静态云地址被转移到另一个客户，而红队不知道这一点，那么该团队将对未知组织的资产进行非法攻击。作为评估范围的一部分所包含的信息需要尽可能地稳定。如果正在使用云托管服务，红队需要确保客户为这些云资产提供的目标信息是可靠的并且是静态的。
与那些将基础设施作为服务(如云提供商)的混合组织相比，使用连接协议和其他类似情况的组织不太常见。在这种情况下，一个组织出于不同的目的与另一个组织有物理或逻辑上的联系。与这种联系有关的规则通常在法律文件中列出，如果 A 组织因为 B 组织因疏忽而受到网络攻击成为受害者，那么 A 组织可以追究 B 组织的责任。这些法律文件中还概述了在跨越此类连接的过程中，某个组织的结束和另一个组织的开始之间的界限。
某些研究机构就是这种情况的典型例子。例如，一个政府研究实验室可能在全国有几所学院和大学，它们专门连接到该实验室的计算机网络，以促进实验、研究和知识共享。这里的风险是，当其中一个组织决定进行红队评估，而红队并不知道所有这些协议，或者这些协议在技术上是如何实现的。如果红队正在对实验室进行安全评估，然后不同的大学通过虚拟专用网络连接，则目标的枚举可能不表明某些主机属于另一个组织。如果允许红队跨越评估范围中指明的覆盖区域，则存在一种非常真实的危险，即外部实体被视为客户组织的另一个子网。
回答有关组织中第三方资产的安全评估的问题，对于确定评估范围的法律边界是很重要的。这些第三方资产可以作为组织基础设施的一部分，也可以作为外部通信的组织。研究实验室示例中给出的连接需要在安全评估的开始和范围讨论期间做出明确定论，以便红队资产对被评估组织的边界有一个坚如磐石的理解。除了防止红队方面的非法活动外，这也确保了被评估的资产会按照客户预期的那样得到利用。如果不是这样，红队就有可能破坏没有做好防护准备的外部或第三方系统。
总结
本章讨论了红队的形成阶段，以及通过理解成功的进攻性安全评估中的 Who（评估干系人）、What（评估什么）以及 When（何时评估）来确定合适的评估范围。
本文由作者“丝绸之路”整理发布，如若转载，请注明原文地址：
如有侵权请联系:admin#unsafe.sh