网络安全威胁-恶意软件趋势和策略-二-

网络安全威胁、恶意软件趋势和策略（二）

原文：Cybersecurity Threats, Malware Trends, and Strategies

协议：CC BY-NC-SA 4.0

六、策略实现

在前一章中，我讨论了许多网络安全策略。在这一章中，我将采用其中的一种策略，并说明如何在真实的 it 环境中实现它。我们的目标是把理论化，让它对你来说更真实一点。我将提供一些我在职业生涯中学到的技巧和诀窍。

在本章中，我们将介绍以下内容:

• 什么是入侵杀伤链？
• 传统压井链模型现代化的一些方法
• 规划和实现此模型时要考虑的因素
• 设计支持该模型的安全控制集

让我们首先决定我们之前讨论的哪些策略将在本章中实现。

介绍

以攻击为中心的策略拥有最高的网络安全基础评分系统 ( CFSS )估计的总分。在满分为 100 分的测试中，它获得了 95 分的满分。它赢得了如此高的分数，因为它几乎完全解决了所有网络安全的基本问题，只有社会工程除外，它实际上无法完全缓解。

业内安全专业人士使用的以攻击为中心的框架的两个流行例子包括入侵杀伤链(埃里克·m·哈钦斯、迈克尔·j·克洛普特、罗汉·m·阿明博士)和米特里·ATT&CK模型(米特里)。

在本章中，我将提供一个例子来说明如何实现以攻击为中心的策略。我将重点介绍的模型是由洛克希德·马丁公司首创的入侵杀伤链框架 first 。我发现安全专业人士要么喜欢要么讨厌这种模式。对这个模型似乎有很多误解；我希望这一章将有助于澄清这些问题。实际上，我有机会做一个大的预算实现，所以我有一些第一手的经验。当我构思这个实现时，我意识到入侵杀伤链可能有几种不同的实现方式。我将描述实现这个框架的一种方法，充分认识到还有其他方法可以实现它，而我的方法可能不是最好的方法。

入侵杀伤链框架基于洛克希德·马丁公司的论文情报驱动的计算机网络防御，通过对手战役和入侵杀伤链的分析获得信息。在我看来，这篇论文是所有网络安全专业人士的必读之作。这篇论文中的一些概念现在可能看起来是主流，但当它首次发表时，它引入了改变网络安全行业的概念和想法。有些人可能会认为这种模式已经过了它的全盛时期，现在有更好的方法可用，比如米特 ATT & CK 模式。这并不完全正确，因为 ATT & CK 是入侵杀伤链方法的补充。按照的说法:

“ATT&CK 和网络杀伤链是互补的。与网络杀伤链相比，ATT 和 CK 站在一个更低的定义层面来描述对手的行为。ATT 和 CK 的战术是无序的，不可能在一次入侵中全部出现，因为敌方的战术目标在整个作战过程中不断变化，而网络杀伤链使用有序的阶段来描述高级别的敌方目标。”

——米特里，常开触点

此外，请记住，CFSS 分数表明，入侵杀伤链方法几乎可以完全缓解网络安全常见问题。不管这种方法的拥护者或反对者怎么说，第五章，网络安全策略给了你 CFSS 方法来决定它对你自己的潜在功效。当面对关于网络安全策略的不同意见时，我建议使用这个工具。此外，请记住，这种方法可以用在内部 IT 环境、云环境和混合环境中。这种方法的另一个优点是它是技术中立的，这意味着它不局限于特定的技术或供应商。这意味着现在和将来，随着 it 策略的发展，大多数组织都可以使用它。

什么是入侵杀伤链？

入侵杀伤链是攻击者可以在攻击中使用的阶段。洛克希德·马丁公司论文中提供的阶段包括:

• 侦察
• 武器化
• 交货
• 探索
• 装置
• 指挥和控制(C2)
• 目标行动

虽然您可能从每个阶段的名称就能知道它们包含的内容，但是让我快速地为您总结一下。注意，这是基于我自己对洛克希德·马丁公司论文的解读，其他解读也是可能的。

攻击者在侦察阶段选择他们的目标(Eric M. Hutchins，Michael J. Cloppert，Rohan M. Amin，哲学博士)。当然，许多攻击者选择目标是机会主义的，很多时候是巧合，互联网上出现的所有商品恶意软件就证明了这一点。

其他攻击者可能会花费时间和精力，根据他们的攻击动机来研究他们应该以谁为目标。在这一阶段，他们可能会花时间发现他们的目标使用的 IP 地址空间、他们使用的硬件和软件、他们拥有的系统类型、企业或组织如何运作、他们的供应链中有哪些供应商以及谁在那里工作。他们可以使用一系列工具来进行这项研究，包括进行 DNS 名称查找的技术工具、IP 地址范围扫描、组织发布职位空缺广告的网站，这些网站通常包括基于他们使用的硬件和软件的技术资格，等等。在大规模恶意软件攻击的情况下，攻击者已经决定攻击每个人。但是，他们仍然需要做出决定，而且是在攻击的这个阶段。

一旦攻击者选择了他们的目标，并对他们在互联网上的位置和他们使用的技术有了一些了解，那么他们就知道如何攻击受害者。这个阶段被称为武器化 (Eric M. Hutchins，Michael J. Cloppert，Rohan M. Amin，博士)。例如，基于他们对目标的研究，他们看到他们使用 Adobe 产品。因此，他们计划首先尝试通过利用 Acrobat Reader 的潜在未修补漏洞来破坏环境。为此，他们构建了一个畸形的。当受害者打开 pdf 文件时，该文件能够利用特定的漏洞(CVE ID)。当然，这种攻击只有在他们使用的漏洞没有在目标环境中打补丁的情况下才会起作用。

现在，攻击者已经决定了他们将如何尝试首先破坏目标的环境，并且他们已经建立了一种武器来完成这一任务。接下来，他们必须决定如何向目标投放武器。在交付阶段，他们决定是否要发送畸形的。pdf 文件作为电子邮件附件，将其用作水坑攻击的一部分，将其放在 USB 驱动器上并扔进组织的停车场，等等。

一旦武器被交付给潜在的受害者，攻击者需要一种方法来激活武器。在我们的恶意中。例如，攻击者希望受害者尝试打开格式错误的文件，以便他们的漏洞在受害者的系统上运行。这个阶段被恰当地称为开发阶段(埃里克·m·哈钦斯、迈克尔·j·克洛普特、罗汉·m·阿明博士)。如果受害者的系统没有针对漏洞利用的特定漏洞进行修补，那么攻击者的漏洞利用将成功执行。

当攻击者利用漏洞执行时，它可能会将更多的恶意软件下载到受害者的系统中，或者从内部对其进行解压缩。通常，这将使攻击者远程访问受害者的系统。这个阶段叫做安装(埃里克·m·哈钦斯，迈克尔·j·克洛普特，罗汉·m·阿明博士)。

一旦攻击者成功地在受害者的系统上安装了他们的工具，他们就可以向他们的工具或系统本身发送命令。攻击者现在可以完全或部分控制系统，他们可以在受害者的系统上运行任意代码。攻击的这个阶段是指挥控制 ( C2 )阶段(埃里克·m·哈钦斯、迈克尔·j·克洛普特、罗汉·m·阿明博士)。他们可能会通过尝试危害更多系统来进一步渗透到环境中。

对目标的行动是入侵杀伤链的最后一个阶段。既然攻击者控制了一个或多个被入侵的系统，他们就会追求他们的目标。正如我在第一章、中讨论的，成功的网络安全策略的要素，他们的动机可能包括利润、经济间谍、军事间谍、恶名、报复和许多其他因素。现在，他们能够实现特定的目标来满足他们的动机。他们可能会窃取知识产权，坚持不懈地收集信息，试图通过动能攻击来物理破坏受害者的操作，破坏系统，等等。

请注意，我已经写了攻击者可以在攻击中使用的攻击阶段。我没有写每个阶段都是总是用于攻击。这是这个框架的一些批评者通常忽略的细微差别。他们经常争辩说，攻击者不必使用洛克希德·马丁公司论文中列出的所有七个阶段。他们只使用他们必须使用的相位。因此，模型是有缺陷的。我会承认我从来没有理解过这个论点，但是在讨论这个框架的时候经常听到。这个论点有一些缺陷。记住这个框架的预期目的是有帮助的——让攻击者更难成功。此外，还记得我在第三章*、威胁格局的演变——恶意软件中给你的关于全知的提示吗？这个论点依赖于全知。我们永远不会知道所有的攻击者都做了什么。这就引出了这个论点的第二个缺陷。因为我们不知道攻击者现在或将来会做什么，所以我们必须准备好保护、检测和响应他们选择做的任何事情。也就是说，我们需要基于这样的现实，攻击者可以使用这些阶段中的任何一个。*

例如，一些环境已经被破坏，使得现在和将来潜在的攻击者更容易渗透受害者的环境，而无需经过前三或四个阶段。这并不意味着攻击者在之前的攻击中没有成功通过这些阶段，也不意味着攻击者在未来不会使用它们。我们不知道未来会怎样，我们也无法控制攻击者。我们不是全知全能的。我们知道攻击者总是会使用这些阶段中的至少一个——他们必须这样做。随后，无论攻击者使用哪个阶段，防御者都必须做好准备。

了解攻击者的入侵杀伤链看起来像什么，可以帮助防御方使攻击者更难成功。通过显著增加攻击者成功所需的努力，我们降低了他们的投资回报，并可能降低他们的决心。为了做到这一点，入侵杀伤链论文的作者建议防御者使用行动过程矩阵 (Eric M. Hutchins，Michael J. Cloppert，Rohan M. Amin，博士)。这个矩阵允许防御者绘制出他们计划如何在入侵杀伤链的七个阶段中的每一个阶段检测、否认、扰乱、降级、欺骗和摧毁攻击者的努力。在表 6.1 中举例说明了这一点:

表 6.1:行动方案矩阵(Eric M. Hutchins、Michael J. Cloppert、Rohan M. Amin 博士)

通过将控制分层到这个矩阵中，目标是使攻击者更难或不可能通过他们的入侵杀伤链。矩阵中的每个单元可以包括多个互补能力。在入侵杀伤链中尽早阻止攻击者可以减少潜在的损害以及相关的恢复时间和成本。攻击者在击败防火墙或一组控制措施后并不成功，他们必须在攻击的每一步都克服行动过程矩阵中的多层防御。

使杀伤链现代化

在实现这个框架之前需要考虑的一个问题是，防御者是应该使用原来的入侵杀伤链框架，还是更新它。有几种方法可以使这个框架现代化。在这一部分，我会给你一些如何做到这一点的想法。然而，不要害怕接受迭代改进的概念，这是基于您的组织对这个框架或其他框架的经验。

绘制网络安全常见疑点地图

在第一章、成功网络安全策略的要素中，我介绍了网络安全的常见嫌疑人，并在本书中提到了他们。我希望我已经传授了减轻组织最初被损害的五种方式的重要性。入侵杀伤链框架可以围绕网络安全常见的可疑因素进行修改或重组，以确保它们得到缓解，并更容易识别组织安全态势中的差距。这可以通过几种不同的方式来实现。首先，它们可以集成到传统的杀伤链框架中。也就是说，用于缓解网络安全常见问题的控制措施像所有其他控制措施一样分布在行动过程矩阵中。这种方法的挑战在于，它会使识别那些特定领域中的过度投资、投资不足和差距变得困难，特别是如果您的矩阵很大的话。为了弥补这一点，可以在矩阵中添加一列，在该列中，可以跟踪网络安全通常怀疑的每种控制所减轻的程度。一些行在此列中没有条目，因为许多控制将是高级网络安全功能，不一定集中于网络安全常见的可疑情况。

另一种更容易确保完全缓解网络安全常见问题的方法是使用两个单独的列表。在一个列表中列出缓解网络安全常见问题的控制措施，在一个单独的行动方案矩阵中列出所有其他措施。通过这种方式，您可以全面、清晰地了解为缓解网络安全常见问题而实现的控制措施，以及所有其他控制措施。这可能意味着这些列表中有一些重复的控件，使得跟踪随时间的变化变得更加复杂。

我更喜欢第二种方法，即使用两个单独的列表。我喜欢清晰可见的控制，以减轻网络安全通常的嫌疑。这种方法使得跟踪代表策略基础的控制变得更加容易。但是，您可以随意使用这两种方法中的任何一种，或者最适合您的组织的另一种方法。这是我将在本章提供的例子中使用的方法。我已经在其他章节中广泛讨论了网络安全的常见疑点和网络安全的基础知识。我在这里提供的例子将集中在该策略的高级网络安全能力部分。

更新矩阵

此方法的另一个值得考虑的修改是是否更新行动过程矩阵中的阶段和行动。例如，入侵杀伤链的侦察阶段可以分为两个独立的阶段。这种区分认识到，在入侵尝试中，攻击者通常会在两个不同的时间执行侦察。在攻击之前，攻击者可能会花时间选择他们的目标，并研究他们可能受到攻击的方式。在网络安全的一个通常的嫌疑人被用来初步危及受害者之后，攻击者可能会再次执行一些侦察，以绘制出受害者的网络以及高价值资产 ( HVAs )在哪里。将这两个阶段分开会有所帮助的原因是，攻击者使用的工具、技术、战术和程序在最初的攻击前后可能会有所不同。通过用侦察 I 和侦察 II 阶段替换侦察阶段来更新矩阵，将使安全团队能够映射不同的控制以在这些阶段中的每个阶段阻止攻击者。请记住，在这两种情况下，攻击者可能会使用非侵入式侦察策略，或者选择使用侵入式侦察策略。

阶段的另一个潜在更新是取消武器化阶段。这似乎是对原始框架的重大改变，但以我的经验来看，它并没有改变防御者通常使用的控制手段。在攻击的这一阶段，已经决定如何攻击受害者的攻击者计划重新使用旧武器或制造和/或购买新武器用于攻击。

这种活动大多发生在维权者的视野之外。随后，攻击者在此阶段的活动很少会受到防御者可用的控制措施的影响。如果攻击者对他们获得武器的来源漫不经心，威胁情报供应商或执法机构可能会得到他们活动的通风报信，也许还有他们的意图。如果该武器是零日漏洞，目标受害者可以部署变通办法来缓解，这可能是有帮助的，但坦率地说，专注于其他攻击阶段可能会为防御者带来更高的投资回报，因为他们可能有更多的可见性和控制力。对于大多数组织来说，武器化阶段太不透明了，无法真正影响。换句话说，CISOs 通常在交付阶段之前没有非常有效的保护和检测控制；对具有明确、可衡量价值的缓解措施进行优先投资非常重要。

行动方案矩阵可以更新，以包括一些不同的行动。例如，摧毁可以是被丢弃，以利于一些更现实的动作，比如限制和恢复。使用限制作为一个动作表明防御者想让攻击者在攻击过程中很难或不可能自由移动。例如，限制攻击者可用的交付选项，限制攻击者可以控制的基础设施的范围，这两者都使攻击者更难成功。如果模型中分层的所有其他缓解措施未能按预期执行，使用恢复操作有助于组织规划其恢复。对于限制和恢复，并不是矩阵中的每个单元都必须有控件。例如，在侦察 I 阶段，可能没有有助于恢复的控制，因为环境尚未受到攻击。矩阵中可能会有几个单元格没有条目，这是意料之中的。表 6.2 中举例说明了更新后的行动方案矩阵:

表 6.2:更新的行动方案矩阵示例(Eric M. Hutchins、Michael J. Cloppert、Rohan M. Amin 博士)

当然，这些更新是完全可选的。对于许多组织来说，实现原始入侵杀伤链模型是提高其安全状况的有效方法。我建议 CISOs 们在认真实现这种模式之前，花些时间思考一下对原始模式的任何修改是否有利。然后，他们应该在继续使用该模型之前更新行动方案矩阵，因为这将节省时间、费用和潜在的令人沮丧的返工。

入门指南

现有的 IT 环境，尤其是那些已经由 CISO 管理的环境，可能已经部署了一些网络安全控制措施。如果以攻击为中心的策略和入侵杀伤链方法对一个组织来说是新的，那么现有控制的部署方式很可能不一定符合行动方案矩阵。将目前部署的网络安全控制措施映射到行动方案矩阵，将有助于确定目前部署的网络安全能力与全面实现的行动方案矩阵之间存在的潜在差距。它还可以帮助识别过度投资和投资不足的领域。例如，在将他们当前的网络安全能力映射到这个矩阵后，安全团队意识到他们已经在否认攻击者的武器交付的能力上投入了大量资金，但是没有投入任何有助于检测交付企图的东西；事实上，他们现在意识到他们在整个捕杀链的探测能力上投资不足。这种映射练习有助于揭示关于组织安全能力的乐观假设。一些安全专业人士称这种类型的练习为“制图 T2”。

这个练习可能很有启发性，但也很难执行，尤其是在大型复杂环境中。我所建议的大多数组织都没有一个完整的、最新的产品、服务和配置列表，这些列表在像这样的练习中是有用的。即使拥有变更控制管理系统的组织也经常发现他们的数据是不完整的、过时的和不准确的。我看到的行业估计表明，平均内部 IT 环境有 20%的未记录资产和服务，在某些行业，如医疗保健行业，估计值甚至更高。

一些组织试图使用采购工件来确定他们的 IT 部门购买了什么，但是这通常与实际部署的不同。面对获得其环境中运行的网络安全功能的准确、最新清单的挑战，大多数组织从他们拥有的数据开始，并手动验证已经实现的内容。这不一定是一件坏事，因为它可以提供一个准确和最新的视图，而且还包括无法从库存数据库中呈现的定性洞察。

当前网络安全能力的成熟度

我有机会在一些大型、复杂的 IT 环境中做这个映射练习。让我分享一些我学到的东西，如果你面临同样的挑战，可以节省你一些时间。当您将当前的网络安全能力映射到行动方案矩阵时，需要注意的一个因素是每个控制或能力的实现成熟度。也就是说，软件清单上的项目可能不会提供任何关于控制是完全实现还是部分实现的线索。了解每项控制措施实现的成熟度是真正了解哪里存在差距以及哪里出现投资不足和过度投资的关键。

例如，一个组织从顶级行业供应商那里采购了一套网络安全功能。该套件能够为台式机和服务器提供多种重要功能，包括文件完整性监控、防恶意软件扫描和数据丢失防护。当将能力映射到行动过程矩阵时，很容易看到套件可以提供的能力，并且将它们全部包含在组织的当前能力清单中。然而，问题是，实际上已经部署了多少套件的功能？一个相关的问题是，谁负责操作和维护这些控制？在大型复杂的 IT 环境中，这些问题可能很难回答。然而，如果不揭示当前实现成熟度的真相，映射的可信度和策略的潜在功效就会被破坏。还记得我在本书中使用的潜艇比喻吗？如果你真的不知道所有的关键系统是否都完全运行，你真的会热衷于在潜艇中出航吗？可能不会。

许多组织渴望拥有世界级的网络安全团队。为了支持这一愿望，他们中的一些人在评估和采购网络安全能力时使用的原则是，他们只想要同类最佳的技术。也就是说，他们只想要最好的产品，不会满足于低于这个价格。对于大多数组织来说，这是非常雄心勃勃的，因为吸引和留住网络安全人才是整个行业面临的挑战。采用“同类最佳”的采购理念使得这一严峻的人才挑战变得更加困难。这是因为它可能会减少对这些昂贵且相对罕见的“同类最佳”实现有经验的人数。这种方法对于现金充裕的组织来说也是危险的，这些组织认为他们可以简单地购买有效的网络安全，而不是发展一种人人参与的文化。我见过的大多数持这种理念的组织最终都买了一辆法拉利并使用了它的烟灰缸。他们根本没有必要的资金来设计、部署、操作和维护同类最佳产品，因此他们只使用了可用功能的一小部分。在某些情况下，发现自己处于这种场景中的组织通过购买相同或相似的功能在某个领域过度投资，但是他们通过购买他们可以成功部署和操作的产品来做到这一点。在发现自己处于这种情况的组织中执行这种映射练习可能特别困难。这是因为它揭示了关于过于乐观的雄心和假设的严酷事实，以及边际回报的网络安全投资。然而，对于有勇气照镜子并愿意对其当前的安全状况做出积极的、渐进的改变的组织来说，这一过程可能是不可避免的。如果组织实际上可以实现这些雄心壮志，那么雄心勃勃、志存高远并没有错。

量化一个网络安全套件或一组功能有多少已经成功部署是一项挑战。我尝试过的一种方法有不同的结果，那就是将功能集的功能分解成不同的类别，并使用成熟度指数来量化部署的成熟度，等级在 1 到 5 之间，其中 5 是最成熟的。这有助于确定某个特定领域是否需要更多投资。在大型、复杂的环境中，这说起来容易做起来难，有些人可能会怀疑是否值得花时间和精力去完成它。然而，安全团队对其事务的当前状态了解得越详细，他们就越有信心推进这一策略。

谁消费数据？

在将 IT 环境的当前安全功能映射到行动方案矩阵时，我发现有一个原则很有帮助，即每个控制集生成的数据都需要有人或某物来使用。例如，执行此映射的安全团队发现网络管理团队实现了潜在的强大 IDS/IPS 功能，这些功能包含在他们上一财年购买的网络设备中。尽管启用了这些功能，但他们发现网络管理团队中没有人主动监控或审查来自该系统的警报，并且该组织的安全运营中心 ( SOC )甚至不知道它们的存在。这些功能的最终结果相当于根本没有它们，因为没有人消费它们生成的数据。人类不一定要消耗这些数据；编排和自动化系统也可以基于这些数据采取行动。然而，如果无论是人还是系统都不使用这些数据，那么安全团队就不能真正地将这些功能包括在他们当前实现的控制措施的映射中，除非这些缺陷得到解决。

当安全团队执行这种映射时，对于他们识别的每个控件，他们还应该记录谁或什么使用了它生成的数据。记录作为使用这些数据的联系人的姓名将会给安全团队带来好处。联系人可能是 SOC 或网络运行中心 ( NOC )的经理、事件响应团队成员或供应商。这些信息对于建立对本组织真正网络安全能力的信心非常有价值。然而，它对于衡量你的策略的有效性也是非常有价值的，我将在第七章、衡量表现和有效性中详细讨论:

表 6.3:部分行动方案矩阵示例(Eric M. Hutchins、Michael J. Cloppert、Rohan M. Amin 博士)，包括成熟度指数、谁或什么将使用来自每个控制的数据，以及联系点(PoC)

如表 6.3 所示，随着行动过程矩阵的更新，它会快速扩展。我过去曾用电子表格做过这种映射。我承认这不是执行这种映射的最优雅的方式。我做的一个映射是一个电子表格中超过 120 页的控件；浏览电子表格并不有趣。此外，使用电子表格并不是最具可扩展性的工具，并且报告功能有限。如果你有更好的工具，就用它吧！如果您没有更好的工具，请放心，映射练习可以使用电子表格或文档来完成。然而，环境越大越复杂，使用这些工具就变得越困难。

网络安全许可证续订

从供应商处购买的大多数软件和硬件都有许可条款，其中包括许可证到期的日期。当许可证到期时，必须进行续订，否则产品必须停止使用。要考虑的行动方案矩阵的另一个更新非常有用，那就是添加一个列来跟踪列出的每项功能的合同续订日期。如果您要花时间清点用于网络安全的软件和硬件，也要记录每个项目的到期/续订日期。这将使您了解列表中的每个项目在许可证到期并需要续订之前的时间。将此信息嵌入到控制映射本身将使您了解每项功能的潜在剩余寿命，并有助于提醒安全团队何时开始重新评估每项产品的有效性，以及是否更新或替换现有功能。

另一个有助于跟踪的类似日期是产品的寿命终止/支持日期；通常，在此日期之后，制造商会弃用产品，不再为其提供安全更新。随着时间的推移，这些产品增加了 IT 环境中的攻击面，因为它们中的漏洞不断被公开披露，甚至在它们的支持日期结束后也是如此。跟踪这些日期可以帮助我们避免意外。作为修改后的行动方案矩阵的一部分，跟踪这些日期是可选的。

CISOs 和安全团队不应依赖他们的采购部门为他们标记续约日期；它应该反过来工作。与我交谈过的许多 CISOs 都希望了解这个“展望列表”，它如何影响他们的预算，以及需要做出决策的关键里程碑日期。什么样的 CISO 人不希望得到一些提前通知，他们的网络 id/IPS 将被关闭，因为他们的许可证即将失效？这些决策的准备时间越长，安全团队在最后一刻遇到的意外就越少。此外，当我在下一章讨论衡量这种策略的有效性时，您将会看到让这些信息唾手可得会很有帮助。

当然，对矩阵的更新是可选的。续期日期可在单独的文件或数据库中跟踪。然而，能够在您的地图中交叉引用更新日期和网络安全能力应该是 CISOs 可以轻松做到的事情。他们需要有足够的准备时间来决定是继续生产现有的产品和服务，还是进行替换:

表 6.4:部分行动方案矩阵的示例(Eric M. Hutchins、Michael J. Cloppert、Rohan M. Amin 博士)，包括成熟度指数、谁或什么将使用数据、联系点(PoC)以及每个控制的更新日期

实现这一策略

在规划过程结束时，CISOs 和安全团队应该对已部署的网络安全功能和控制措施以及组织如何使用这些功能和控制措施中的数据有一个更好的了解。这是实现入侵杀伤链框架的一个很好的起点。但是，不要低估拥有大型复杂 it 环境的组织实现这一目标的挑战性。

对于一些组织来说，将映射工作划分为更小的、更容易实现的项目，专注于其环境的一部分，比尝试映射其整个环境更容易。在没有准确的当前规划的情况下推进这一策略很容易导致过度投资、投资不足以及安全能力方面的差距。虽然这些问题可以随着时间的推移得到纠正，但它可能会使成本更高、更耗时。

表 6.5:更新的行动方案矩阵(Eric M. Hutchins、Michael J. Cloppert、Rohan M. Amin 博士)的一部分示例，其中包含组织当前网络安全能力的映射

我在表 6.5 中提供了一个例子，展示了一组更新的阶段中的前两个动作。一个大型组织的实际映射可能要大得多，但是我想让您对映射有一个概念。在实际映射中， control_name 将是针对攻击的每个阶段检测、拒绝、破坏等的特定产品、服务、特性或功能的名称。描述字段是对每个控件功能的简短描述。我建议在这个领域提供比我这里更多的细节，这样每个控件的功能和作用范围就很清楚了。

每个控件都有一个成熟度指数，范围从 1 到 5，5 表示实现尽可能完整和有效。一到二的成熟度指数表明，虽然产品或功能有很多功能，但相对来说，只有很少的功能被部署或运行。该指数将有助于我们了解每项控制措施目前的有效性及其潜力。这有助于避免假设控制以最高效率运行的陷阱，而实际上它并没有完全部署，或者没有被积极地运行或监控。对该字段或基于该字段的整个行项目进行颜色编码，可以更容易地理解每个控制的成熟度。

每个动作的数据消费者是组织中使用来自控制的数据来检测、拒绝、破坏、降级等的特定组或部门。消费者概念验证列包含消费每个控制数据的小组或部门中每个联系人的姓名。这使得定期验证来自每个控件的数据是否仍在按计划使用变得更加容易。毕竟，如果没有人真正关注它们，部署缓解措施就没有意义。花在这些控制上的时间、精力和预算可能会在组织的其他地方得到更有效的利用。

最后，每个操作的更新日期列提供了每个控制的潜在到期日期的可见性。这样做有助于最大限度地减少每个控制操作状态中潜在的意外失误。这有助于避免您认为完全有效的缓解措施实际上由于许可失效或产品停止支持而被部分或完全禁用的情况；这些意外会让 CISOs 和安全团队焦头烂额。

合理化矩阵——差距、投资不足和过度投资

如果没有当前网络安全能力与行动方案矩阵的对应关系，很容易在网络安全产品上过度投资或投资不足，并在保护、检测和响应能力上存在差距。我所说的过度投资、投资不足和缺口到底是什么意思？将现有的网络安全能力和控制措施映射到入侵杀伤链框架可能需要大量的工作。然而，对于一些首席信息安全官来说，这可能会导致顿悟。如果执行正确，这种映射可以揭示出组织根本没有投资的关键领域——差距。例如在表 6.5 中，侦察 I 行没有任何条目；这可以清楚地表明组织的控制集合中存在缺口，这可能会使攻击者的入侵杀伤链的这一阶段变得更容易。组织在这方面投资失败并不罕见。像这样的差距是一个明显的改进机会。

在行动方案矩阵中，某个领域的投资不足可能更加微妙。投资不足可能表现为矩阵中某项活动或阶段的相对较少的条目。这就是成熟度指数和描述可以帮助的地方。

矩阵中成熟度指数为 5 的单个条目可能就是该操作所需的全部投资。成熟度指数和描述的结合应该有助于做出这个决定。然而，条目的描述应该足够详细，以便我们理解该功能的功能和范围是否真的会打破攻击者的杀伤链，或者是否在矩阵的该区域需要更多的投资。可能会部署正确的控件；但如果它只是部分实现或部分运作，它可能不足以打破杀伤链或在所有情况下都有效。进一步投资于成熟的控制可能是这个问题的解决方案。另一个可能的解决方案是投资于不同的控制，以补充当前的缓解措施。从这个角度来看，行动方案矩阵成为在事故期间提供帮助的重要文档，并且是与非技术主管就预算和资源进行协商的中心。

在某些领域过度投资是一个常见的问题，我见过公共和私营部门组织都深受其害。它可以随着时间的推移缓慢发生，也可以在数据泄露后迅速发生。在行动方案矩阵中，它可以表现为一个或两个领域中执行相同或相似功能的许多条目。例如，我见过一些组织购买了多种身份和访问管理产品，但没有一个完全部署。这可能是由一系列原因造成的。例如，他们可能对自己吸引和留住部署这些产品所需的人才的能力不切实际。另一个例子是，在入侵成功后，受害组织通常会决定是时候对网络安全进行大量投资了。带着新发现的紧迫感和旺盛的精力，他们不会花时间在疯狂购物之前获得当前功能及其成熟度的清单。合并和收购也会使组织在矩阵的某些领域过度投资。最后，简单来说，有些销售人员真的很擅长他们的工作。我看到在整个行业和地理区域，每个人都在相同的 1 或 2 个财年内采购了相同的 SIEM 或端点解决方案。这没有什么错，但他们不太可能都是从相同的环境、可比的网络安全人才以及当前产品的相同许可续订日期开始的。当一个优秀的销售人员非常成功时，这有时会导致在某些领域的过度投资。

规划您的实现

确定差距、投资不足的领域和过度投资的领域非常重要，因为这些将为实现计划提供信息。希望组织已经投资的许多领域不需要改变。这将使他们能够专注于解决其当前安全态势中的差距和不足。当他们有了当前的规划并确定了差距、投资不足的领域和过度投资的领域时，他们就可以开始规划其余的实现了。

安全团队应该首先处理行动方案矩阵的哪个部分？对于一些组织来说，专注于解决现有差距将提供最高的潜在投资回报率。然而，有一些因素需要考虑，包括预算和网络安全人才的可用性。首要目标是打破攻击者的杀戮链。但是，请记住，在杀伤链中尽可能早地这样做是有效率的。在利用和安装之前阻止攻击有助于最大限度地降低成本和损失。但是，正如我在讨论保护和恢复策略时所讨论的，假设安全团队能够在 100%的时间内做到这一点是过于乐观的，很可能会让组织面临失败。随后，我与之讨论过这个问题的一些首席信息官决定在矩阵的每一部分都投资一点。然而，充足的预算和资源可用性可能是这种方法的限制因素。

我接触过的大多数首席信息安全官预算有限。对于那些没有这样做的人，他们通常仍然受到快速设计、部署和操作新功能的能力的限制；网络安全人才短缺是全行业性的。矩阵中每个项目的续订日期有助于为用于解决差距和投资问题的时间表提供信息。选择不为过度投资领域的低效产品续订许可证可能有助于释放一些预算，这些预算可用于解决缺口和投资不足的领域。并非每个组织都有过度投资，许多组织在整个矩阵中都长期投资不足。对于这类组织来说，尽可能多地利用操作系统和集成开发环境中的“免费”控件可能会有所帮助。

例如，地址空间布局随机化 ( ASLR )和数据执行阻止 ( DEP )有助于使攻击的利用阶段更难完成且不一致。这些特性已经内置到当今主流厂商的大多数现代操作系统中。然而，并不是所有的应用程序都利用了它们。深思熟虑地使用这种免费或低成本的控件可以帮助预算有限的组织实现这一策略。

我见过的 CISOs 计划实现的另一种方式是使用红队和蓝队练习和渗透测试的结果。渗透测试通常侧重于确认已经实现的安全控制的有效性，而红队的练习侧重于超越和智胜防御者。这是测试作为您当前实现的一部分的人员、流程和技术的有效性的直接方法。与确定差距同样重要的是，这些练习可以确定未按预期执行的控制和缓解措施。这些练习还有助于在您的规划中提供成熟度指数，并以一种实用的、较少理论性的方式帮助您确定实现计划中项目的优先级。

最后，我看到 CISOs 决定实现像这样的框架的另一种方式是首先投资于高 ROI 领域。他们通过确定从哪里获得最大的投资回报来做到这一点。这是通过在矩阵的多个部分识别提供缓解的控制来完成的。例如，如果相同的控制可能有助于打破攻击者在交付、利用、指挥和控制阶段的杀伤链，他们会优先考虑那个控制，而不是可能只打破攻击的一个阶段的控制(Eric M. Hutchins，Michael J. Cloppert，Rohan M. Amin，博士)。换句话说，他们寻找可以用一个价格使用两个或三个缓解措施的领域。他们的矩阵越详细，他们能够识别的机会就越多。

我将在第七章、评估表现和有效性的部分重新讨论我在本节中讨论的许多因素。

设计控制集

有了当前的控制集映射、已确定的差距、投资不足的区域、过度投资的区域，以及将解决这些区域的计划，安全团队可以开始设计控制集。过程的这一部分可能很有挑战性，但也很有趣。

毕竟，设计控件使攻击者尽可能难以得逞是一件有趣的事情！对一些人来说，花钱也是一种乐趣，在这个练习中有机会为这样做打下基础。

可能的控制集的组合和排列比我在这本书里所能涵盖的还要多。这一部分旨在为您提供我概述的更新的行动方案矩阵的每一部分的更多细节，并引发一些关于安全团队可以为其组织设计控制集的方式的思考。这不是一个应该遵循的蓝图；真的只是一个高层次的例子。我没有收到我在本节中提到的任何产品或公司的任何促销付款，我不认可它们，也不对它们或它们的产品做出任何声明或担保。请使用符合您要求的任何公司、产品、服务和功能。如果你想要专业的建议，我建议你去消费行业分析公司的报告和服务，比如 Forrester 和 Gartner 等。这就是 CISO 议会、专业协会和封闭社交网络非常有用的地方。直接从其他 CISOs 那里获得策略、产品和服务的第一手资料会非常有帮助。分析公司不能过于公开地批评一家公司或其产品，但我没见过多少首席信息安全官不愿意在私下私下交谈时坦诚相待。

攻击阶段——侦察 I

在攻击的这一阶段，攻击者选择他们的目标，进行研究，绘制和探测他们的目标的在线存在，并对他们的目标受害者的供应链中的组织做同样的事情。攻击者正在寻找关于什么、为什么、何时和如何的基本问题的答案。他们的研究不仅限于 IP 地址和开放的 TCP/UDP 端口；人员、流程和技术都是他们攻击的潜在棋子。

在攻击的这个阶段，防御者面临的挑战是，这些类型的侦察活动会混入合法的网络流量、电子邮件、电话、员工等等。当攻击者的侦察活动不异常时，很难识别它们。尽管如此，在这个阶段投资网络安全能力还是值得的，因为正如我前面提到的，尽早打破攻击者的杀伤链通常会带来最高的投资回报。

将侦察活动分为被动和主动两类(H. P. Sanghvi，2013)有助于安全团队决定在哪些领域进行投资是可行的。例如，试图通过阅读一个组织的招聘网站来识别进行被动研究的攻击者，仅仅是为了识别该组织使用的硬件和软件的类型，这可能是非常昂贵的。但是，检测和阻止主动扫描公司防火墙漏洞的系统的 IP 地址可能是可行的。许多被动侦察活动可以在防御者的视线之外进行，因此不会生成防御者可以使用的日志条目或警报。然而，许多威胁情报供应商向他们的客户提供服务，这些服务搜集社交媒体网站和非法市场，都是为了在黑暗的网络中寻找关于他们的 IP 地址范围、域、已知漏洞、待售凭证和即将发生的攻击的聊天记录。主动侦察活动倾向于直接与受害者及其供应链互动，这有可能让防御者更直接地看到他们。

图 6.1:侦察活动类别

在攻击的这个阶段，一些网络安全能力可以有所帮助包括:

• 威胁情报服务可以帮助检测被动侦察活动，潜在地通知防御者他们防御态势中的已知漏洞和即将到来的攻击。理想情况下，这可以给他们一些时间来解决这些已知的漏洞，并更好地为攻击做准备。目前提供此类服务的威胁情报供应商包括:
  • 数字阴影
  • 火眼儿
  • [姓氏]克罗尔
  • MarkMonitor
  • 校对点
  • 许多许多其他公司，包括较小的精品公司
• Web 应用防火墙 ( WAF )可以检测应用层攻击，比如 SQL 注入、跨站脚本等等。WAF 可以帮助检测、拒绝、破坏和降低应用层攻击。WAFs 的一些示例包括:
  • 亚马逊网络服务
  • 梭鱼
  • 云 flare
  • F5
  • Imperva
  • 微软
  • 神谕
  • 很多很多其他人
• 至少有几种不同风格的防火墙。防火墙可以检测、拒绝、破坏和降低一些主动网络侦察活动。供应商提供防火墙产品的例子不胜枚举，但其中一些例子包括:
  • 梭鱼
  • 加拿大白鲑
  • 检查点软件技术
  • 瞻博网络公司
  • 帕洛阿尔托网络公司
  • 音墙网络
  • 很多很多其他人
• 欺骗技术可以用来欺骗攻击者进行主动侦察。欺骗技术系统将系统呈现为其供应链中预期目标或供应商的合法基础设施。攻击者花费时间和资源在这些系统上执行侦察，而不是生产基础设施和系统。欺骗技术供应商的例子包括:
  • 主动网络
  • 虚幻网络
  • 包装工
  • TrapX 安全性
  • 很多很多其他人
• 自动化可以与威胁情报和检测功能相结合，使能够对侦察活动做出动态响应。例如，如果 WAF 或防火墙检测到来自已知恶意 IP 地址的探测，则可以触发自动化来动态调整一段时间内被阻止的 IP 地址列表，或者自动化可以允许来自恶意 IP 地址的 ICMP 网络流量，阻止流向端口 80、443 和其他开放端口的 TCP 流量，从而尝试降低侦测能力并浪费攻击者的时间。这将允许攻击者看到系统在线，但无法连接到其上运行的服务。这种类型的自动化在传统的内部环境中可能更难实现，但它默认情况下被嵌入到云中，并且相对容易配置。我将在第八章、云——安全和合规性的现代方法中更详细地讨论云功能。

这是基于我在本节中讨论的能力的侦察 I 阶段的行动方案矩阵的样子。当然，这只是触及了这个阶段可能发生的事情的表面，但是它为您提供了一些关于攻击的第一阶段的一些操作的想法。您会注意到，我没有为恢复操作添加任何条目。

由于侦察通常不会造成损害或危害，所以在攻击的这个阶段没有什么可以恢复的。

正如我提到的，使用 Excel 创建一个行动过程矩阵并不理想，但它是可行的。然而，这个练习创建的表格太大了，不能打印在书里，而且仍然可读。随后，我将为示例矩阵的每个部分提供控件列表。我没有包括对阶段的控制，例如恢复，除非其中有项目。为了进一步简化，我不包括我前面讨论的任何修改，因为它们对于每个组织都是独特的。这个列表并不是详尽无遗的；它提供了一些基本控件的示例，您可以将其作为开发自己的行动方案矩阵的起点。有些项目在行动方案矩阵中重复多次，因为这些控制在矩阵中可以扮演多重角色。

以下控件是示例控件，可用于在攻击的侦察 I 阶段检测攻击者的活动:

• 欺骗技术:可以帮助检测攻击者的侦察活动。
• Web 应用防火墙(WAF) :可以检测应用层攻击，如 SQL 注入、跨站脚本等。
• 防火墙:可以检测网络探测器和一些侦察活动。
• 威胁情报侦察服务:可以帮助检测被动侦察活动，让防御方注意到他们防御态势中的已知漏洞和即将到来的攻击。

以下控件是示例控件，可用于在攻击的侦察 I 阶段拒绝攻击者的活动:

• 自动化:当侦测到侦测活动时，使用自动化来调整防火墙规则和其他控制，以拒绝、破坏、降级或限制其活动。
• Web 应用防火墙(WAF) :可以拦截 SQL 注入、跨站脚本等应用层攻击。
• 防火墙:可以阻止网络探测和一些侦察活动。

以下控件是示例控件，可用于在攻击的侦察 I 阶段扰乱攻击者的活动:

• 自动化:当侦测到侦测活动时，使用自动化来调整防火墙规则和其他控制，以拒绝、破坏、降级或限制其活动。
• Web 应用防火墙(WAF) :可以阻断应用层攻击，如 SQL 注入、跨站点脚本等。
• 防火墙:可以中断网络探测和一些侦察活动。

以下控件是示例控件，可以在攻击的侦察 I 阶段使用来降级攻击者活动:

• 自动化:当侦测到侦测活动时，使用自动化来调整防火墙规则和其他控制，以拒绝、破坏、降级或限制其活动。
• Web 应用防火墙(WAF) :可以降低应用层攻击，如 SQL 注入、跨站点脚本等。
• 防火墙:可以降低网络探测器和一些侦察活动的性能。

以下控件是示例控件，可用于在攻击的侦察 I 阶段欺骗攻击者:

• 欺骗技术:欺骗技术可以欺骗攻击者花时间侦察假资产而不是真资产。

以下控制示例可用于在攻击的侦察 I 阶段限制攻击者的活动:

• 自动化:当侦测到侦察活动时，使用自动化来调整防火墙规则和其他控制，以拒绝、破坏、降级或限制其活动。

为侦察 I 阶段的投资决策提供信息的最有效方法之一是让安全团队在自己的网络上执行侦察。

攻击阶段–交付

在攻击的这一点上，攻击者已经决定以哪个组织为目标，做了一些研究来帮助他们执行攻击，并可能做了一些主动侦察扫描，并探测了预期受害者的互联网存在。根据这些信息，他们也经历了一些武器化阶段或过程，他们采购和/或制造武器，这将帮助他们最初危及他们的目标，并使他们能够事后活动。这一武器化过程通常发生在防御者的视线之外。然而，正如我在侦察 I 阶段提到的，一些威胁情报供应商的服务有时可以洞察这些活动。

攻击者的武器可能包括人员、流程和技术。有了这些，攻击者必须把这些武器送到他们的目标；这是交付阶段的目标。攻击者有一系列选择来将他们的武器交付给他们的目标和供应链中的供应商。传送机制的一些示例包括恶意电子邮件附件、电子邮件中的恶意 URL、吸引受害者注意力的恶意网站、恶意内部人员、蠕虫等自传播恶意软件、将恶意 USB 驱动器留在受害者家中等等。

在攻击的这一阶段，一些有帮助的投资包括:

• Education/training: Recall the research I provided in Chapter 3, The Evolution of the Threat Landscape – Malware. It's clear that different types of malware go in and out of vogue with attackers, but their mainstay approach has always been social engineering. Therefore, educating information workers and training them to spot common social engineering attacks can be very helpful in detecting the delivery of the attacker's weapons. The challenge is that social engineering training isn't a one-time activity, it's an ongoing investment. When training stops, current employees start to forget these lessons and new employees don't get trained. Note that the training itself needs to be kept up to date in order to continue being effective.

  一些组织根本没有支持社会工程培训的文化，包括实际的网络钓鱼活动和其他针对员工的社会工程攻击。然而，不进行这种培训的组织错过了让他们的员工从经验和失败中学习的机会。每个人都试图帮助 CISO 的文化比安全团队总是对未经培训的信息工作者每天做出的不知情、缺乏信任的决定做出反应的文化更有力量。

• 微软 Office 365 高级威胁防护(APT) :电子邮件是社交工程攻击的主要载体。在任何时期，基于电子邮件的攻击的量都相对巨大。为信息工作者提供没有有效保护的电子邮件收件箱会让组织走向失败。微软 Office 365 APT 等基于云的服务通过阻止任何用户面临的威胁来帮助所有用户接种疫苗。如此大规模的服务可以轻松识别僵尸网络和攻击者用于垃圾邮件、网络钓鱼和其他基于电子邮件的攻击的 IP 地址，并为其所有用户阻止这些地址。

• 欺骗技术:我是欺骗技术的超级粉丝。这项技术超越了蜜罐和蜜网，提供了成熟的环境来吸引攻击者，发出他们存在的信号，并浪费他们的时间，降低他们的投资回报。使用欺骗技术向攻击者展示易受攻击的系统、关键基础设施系统或存储或访问潜在有价值数据的系统，可能会转移他们对合法系统的注意力。

• 反恶意软件套件:反恶意软件软件可以检测并阻止不同类型武器的交付企图。正如我在第三章、威胁格局的演变——恶意软件中所讨论的，在一个恶意文件的数量轻易超过合法文件的世界里，反恶意软件不是可选的。一些提供产品的反恶意软件供应商包括:

  • 黑莓 Cylance
  • CrowdStrike
  • 炭黑
  • 火眼儿
  • f-安全
  • 卡巴斯基
  • 迈克菲
  • 微软
  • 趋势科技
  • 许多其他人

• 网络浏览器保护技术:阻止对已知不良网站和不安全内容的访问，以及在浏览器下载内容之前对其进行扫描，有助于防止遭受偷渡式下载攻击、网络钓鱼攻击、恶意软件托管站点和其他基于网络的恶意攻击。

• 文件完整性监控(FIM) : FIM 可以通过维护操作系统和应用程序文件的完整性来帮助检测、阻止、破坏和降级交付阶段。

• IDS/IPS :一些供应商提供 IDS/IPS 系统，包括思科、火眼等等。

• 操作系统强制访问控制:可以帮助中断和降低交付。

• 短命环境:系统只存活几个小时就能破坏和降低攻击者投放其武器的能力，尤其是更复杂的多级投放场景。云可以使利用短期环境变得相对容易；我将在第八章、云——实现安全性和合规性的现代方法中详细讨论这个概念。

• 恢复:这些年来，我见过许多组织，他们依靠反恶意软件等阻止机制来检测和阻止交付，但如果有任何机会系统遭到破坏，他们会重建系统。如果交付成功，即使利用和安装被阻止，一些组织也希望整合和重建系统或从备份中恢复数据，以确保一切都处于已知的良好状态。

接下来，我们将基于我在本节中讨论的能力，来看看交付阶段的行动过程矩阵是什么样子的。

以下控件是示例控件，可用于在攻击的交付阶段检测攻击者的活动:

• 教育/培训:信息工作者教育和培训，以发现社会工程攻击。
• Microsoft Office 365 高级威胁防护:检测并阻止恶意电子邮件和文件的发送。
• 欺骗技术:欺骗技术可以吸引攻击者，并探测到对欺骗资产的武器投放。
• 防恶意软件套件:防恶意软件可以检测并阻止来自存储介质、网络以及通过网络浏览器的恶意内容。
• 文件完整性监控(FIM) : FIM 可以检测并阻止系统文件替换尝试。
• IDS/IPS :可以检测并有可能破坏或停止交付。

以下控件是示例控件，可用于在攻击的交付阶段拒绝攻击者的活动:

• USB 驱动器禁止策略:阻止安装 USB 和可移动介质可以阻止交付。
• Microsoft Office 365 高级威胁防护:检测并阻止恶意电子邮件和文件的发送。
• 网络浏览器保护技术:一些浏览器会阻止用户访问已知的恶意网站。
• 防恶意软件套件:防恶意软件可以检测并阻止来自存储介质、网络以及通过网络浏览器的恶意内容。
• 文件完整性监控(FIM) : FIM 可以检测并阻止系统文件替换尝试。
• IDS/IPS :可以检测并有可能破坏或停止交付。

以下控件是示例控件，可用于在攻击的交付阶段扰乱攻击者的活动:

• 操作系统强制访问控制:以能够中断或降低交付的方式控制对文件和设备的访问。
• 短命的环境:每隔几个小时就更换的系统会增加交付的难度。
• 防恶意软件套件:防恶意软件可以检测并阻止来自存储介质、网络以及通过网络浏览器的恶意内容。
• 文件完整性监控(FIM) : FIM 可以检测并阻止系统文件替换尝试。
• IDS/IPS :可以检测并有可能破坏或停止交付。

以下控件是示例控件，可用于在攻击的交付阶段降级攻击者活动:

• 操作系统强制访问控制:控制对文件和设备的访问，以免中断或降低交付。
• 短命的环境:每隔几个小时就更换的系统会增加交付的难度。
• 防恶意软件套件:防恶意软件可以检测并阻止来自存储介质、网络以及通过网络浏览器的恶意内容。
• 文件完整性监控(FIM) : FIM 可以检测并阻止系统文件替换尝试。
• IDS/IPS :可以检测并有可能破坏或停止交付。

以下控件是示例控件，可用于在攻击的交付阶段欺骗攻击者:

• 欺骗技术:欺骗技术可以吸引攻击者，并探测到对欺骗资产的武器投放。

以下控件是示例控件，可用于在攻击的交付阶段限制攻击者的活动:

• 身份和访问管理技术:实现最小特权原则和有意义的职责分离有助于限制 it 环境中的交付。

以下控件是示例控件，可用于在攻击的交付阶段恢复:

• 备份:根据需要从备份中恢复。
• 图像和容器:根据需要重建基础设施。

我在这里提供的例子很简单，但我希望它们能给安全团队一些思路。不管交付媒介是什么，将打破交付阶段的功能分层是关键。

攻击阶段——剥削

在攻击者成功地将他们的武器送到他们的目标后，武器必须被激活。有时，交付和利用阶段会紧接着发生，例如驾车下载攻击。在这种情况下，用户通常会被诱骗通过电子邮件或在线内容中的 URL 访问恶意网站。当他们点击链接，他们的 web 浏览器执行名称解析并加载页面时，恶意页面上的脚本将检测操作系统和浏览器，然后尝试利用该软件。如果软件没有针对这些漏洞的漏洞进行修补，那么攻击者通常会将更多的恶意软件下载到系统中，安装工具，并继续他们的杀伤链。在这种类型的攻击中，交付和利用阶段几乎同时发生。在其他攻击中，如基于电子邮件的攻击，在用户打开电子邮件并点击恶意附件或恶意网站的 URL 之前的几分钟、几小时、几天、几周甚至几个月，就可能发生传送。在这种情况下，交付和开发阶段是截然不同的(Eric M. Hutchins、Michael J. Cloppert、Rohan M. Amin 博士)。有些攻击者追求即时的满足，而有些人更喜欢“低慢”的方法。

防御者必须为这一系列攻击做好准备。他们不能假设交付和开发阶段总是几乎同时发生，但是他们必须为这样的场景做好准备。打破攻击者杀伤链的利用阶段是至关重要的，因为如果他们成功地完成了这一阶段的攻击，他们就有可能在环境中找到立足点，从而进一步渗透。在攻击的这个阶段之后，防御者管理防御会变得更加困难。因为许多攻击是自动进行的，所以利用后阶段的活动可能会很快发生。正如俗话所说，打破攻击者的杀伤链是安全团队的谨慎目标。

防止利用未打补丁的漏洞和安全错误配置(网络安全的两个常见嫌疑)的最佳方式是每天扫描和修补所有东西。每天扫描所有 IT 资产可以最大限度地减少环境中存在未打补丁的漏洞和安全错误配置的次数，从而暴露残余风险，以便有意识地减轻、转移或接受风险。

除了每天修补一切之外，下面的列表为您提供了一些示例控制，可用于在攻击的利用阶段检测攻击者的活动。希望这能给你一些想法，如何让利用阶段对攻击者更具挑战性:

• 反恶意软件套件:反恶意软件可以检测和阻止漏洞利用。
• 容器化和支持安全工具:容器可以减少攻击面，工具可以帮助检测和防止攻击。
• 文件完整性监控(FIM) : FIM 可以检测某些利用漏洞的企图。
• 日志审查:审查各种系统日志可以发现漏洞利用的迹象。

以下控制示例可用于在攻击的利用阶段拒绝攻击者的活动:

• 反恶意软件套件:反恶意软件可以检测和阻止漏洞利用。
• 容器化和支持安全工具:容器可以减少攻击面，工具可以帮助检测和防止攻击。
• 地址空间布局随机化(ASLR) :操作系统的“ASLR”会导致利用不一致或不可能。
• 数据执行保护(DEP) :操作系统的 DEP 可以使利用不一致或不可能。
• 身份和访问管理控制:严格遵循最小特权原则可以在某些场景下拒绝利用。

以下控件是示例控件，可用于在攻击的利用阶段扰乱攻击者的活动:

• 反恶意软件套件:反恶意软件可以阻断对漏洞的利用。
• 容器化和支持安全工具:容器可以减少攻击面，工具可以帮助检测和防止攻击。
• 地址空间布局随机化(ASLR) :操作系统的“ASLR”会导致利用不一致或不可能。
• 数据执行保护(DEP) :操作系统的 DEP 可以使利用不一致或不可能。

以下控件是示例控件，可用于在攻击的利用阶段降级攻击者活动:

• 反恶意软件套件:反恶意软件可以降低漏洞的利用程度
• 容器化和支持安全工具:容器可以减少攻击面，工具可以帮助检测和防止攻击。
• 地址空间布局随机化(ASLR) :操作系统的“ASLR”会导致利用不一致或不可能。
• 数据执行保护(DEP) :操作系统的 DEP 可以使利用不一致或不可能。
• 短暂的环境:每隔几个小时就被更换的系统会增加利用的难度。

以下控件示例可用于在攻击的利用阶段欺骗攻击者:

• 欺骗技术:欺骗技术可以吸引攻击者，欺骗他们攻击假环境。
• 蜜罐:吸引攻击者并暴露他们使用的漏洞。

以下控件是示例控件，可用于在攻击的利用阶段限制攻击者的活动:

• 地址空间布局随机化(ASLR) :操作系统的“ASLR”会导致利用不一致或不可能。
• 数据执行保护(DEP) :操作系统的 DEP 可以使利用不一致或不可能。

以下控件是可用于在攻击的利用阶段恢复的示例控件:

• 备份:根据需要从备份中恢复。
• 图像和容器:根据需要重建基础设施。

上面列表中讨论的一些功能在攻击的这个阶段会有所帮助，包括:

• 地址空间布局随机化(ASLR) :这种内存安全特性可以通过随机化地址空间位置，使攻击者更难利用漏洞。这使得攻击者更难持续预测他们想要利用的漏洞的内存位置。ASLR 应该与数据执行保护结合使用(Matt Miller，2010)。
• 数据执行保护(DEP) :另一个内存安全特性，阻止攻击者使用数据内存页面来执行他们的代码。DEP 应与 ASLR 联合使用(Matt Miller，2010)。
• 容器化和支持安全工具:使用 Docker 和 Kubernetes 等容器技术有很多优势，尤其是有助于减少系统和应用程序的攻击面。当然，容器也是软件，因此也有自己的弱点。有些供应商提供工具来帮助检测和防止利用容器的环境中的漏洞。一些例子包括:
  • 水上安全
  • 云通道
  • 伊卢米奥
  • 站得住脚的
  • 扭锁
  • 其他人
• 身份和访问管理控制:严格遵循最小特权原则可以增加漏洞利用的难度。有时，攻击者的代码在执行它的用户的帐户上下文下运行，而不是在提升的权限下运行。限制用户权限会使攻击更难成功或达到预期效果。
• 短寿命环境:系统寿命只有几个小时，并被完全修补的系统所取代，这使得攻击更加难以成功。

花时间仔细分层控制以打破攻击者杀伤链的利用阶段是值得的(Eric M. Hutchins，Michael J. Cloppert，Rohan M. Amin，博士)。这本书有整整一章可以专门讨论剥削；我在这里仅仅触及了表面，但是我鼓励 CISOs 和安全团队花更多的时间研究和考虑如何在他们的环境中实现这个框架的这个特定阶段。

攻击阶段–安装

像 2003 年一样，简单地成功利用一个漏洞并不是大多数现代攻击者的目标。恶名已经被更加严重和邪恶的动机所取代。一旦攻击者成功地交付了他们的武器并且利用成功，他们通常会寻求扩大他们在受害者环境中的控制范围。

要做到这一点，他们有一系列的选择，例如从漏洞本身内部解包恶意软件或远程控制工具，或者从他们控制的另一个系统下载它们。

最近,攻击者试图使用操作系统和应用程序的本地和预装工具、脚本、库和二进制文件,“远离土地生活”重新流行起来。这种策略使他们能够进一步渗透受损环境，同时避开专注于检测与恶意软件和利用相关的特定文件的防御者。要知道“陆地生存”战术可以用在攻击者杀伤链的几个阶段，而不仅仅是在安装阶段。此外，请注意，虽然它已经有所现代化，这种战术是像我一样古老，并依赖于过去的防御者在时间中丢失的部落知识。

2003 年，当我在微软的事件响应团队工作时，每个攻击者都“生活在陆地上”。在那些日子里，我们看到攻击者使用了许多的创造性战术。我学到的一个教训是，删除操作系统自带的所有内置支持工具，如ping.exe、tracert.exe以及攻击者依赖的许多其他工具，迫使攻击者带来更多自己的工具。在受支持的 IT 环境中的系统上找到任何这些工具都是妥协的标志。同时，桌面和服务器支持人员可以从网络共享下载他们自己的工具，用于故障排除，并在完成后删除它们。如今，攻击者变得更加老练，他们使用的系统二进制文件和库在不破坏操作系统的情况下是无法真正删除的。然而，让他们尽可能少地生活可以帮助防御者在攻击的多个阶段。

攻击者还依靠许多技巧隐藏在系统中。例如，他们会在受害者的系统上运行远程控制或监视软件的组件，方法是将其命名为与管理员期望在系统上运行的系统文件相同的名称，但从稍微不同的目录运行。文件和进程看起来很正常，大多数管理员不会注意到它是从system目录而不是system32目录运行的。这种策略如此普遍，以至于我开发了一些流行的 Windows 支持工具，可以帮助检测这种恶作剧，包括 Port Reporter、Port Reporter Parser 和 Portqry(微软公司，n.d .)。

这些工具仍然可以在微软下载中心免费下载，尽管我怀疑它们能否在今天基于 Windows 10 的系统上正常运行，因为自从我开发这些工具以来，许多 Windows APIs 都发生了变化。当然，当我开发这些工具时，我不得不找点乐子；我的名字出现在端口报告器日志文件中，当隐藏的/dev开关与 Portqry 一起运行时:

图 6.2:用 Portqry 版玩复活节彩蛋

有助于打破攻击安装阶段的一些功能包括:

• 反恶意软件套件:反恶意软件软件可以检测并阻止不同类型武器的安装企图。保持反恶意软件套件最新；否则，他们可以自己增加攻击面。
• 文件完整性监控(FIM) :我是 FIM 的粉丝。当它正常工作时，它可以帮助检测安装企图，并在理想情况下，阻止他们。它还有助于满足许多组织的法规遵从性义务。FIM 功能内置于许多终端保护套件中，可以与 SIEMs 集成。我见过的一些正在使用的 FIM 供应商/产品包括:
  • 迈克菲
  • 哪一个
  • 绊网
  • 许多其他人
• 身份和访问管理控制:遵循最小特权原则会使安装更难成功。
• Windows Device Guard :这可以锁定 Windows 10 系统，防止未经授权的程序运行(微软公司，2017)。这有助于防止攻击过程中的漏洞利用和安装。
• 强制访问控制，Linux 系统上基于角色的访问控制:这些控制有助于实现最小特权原则，并控制对文件和进程的访问，这会使安装变得更加困难或不可能。

以下控件是示例控件，可用于在攻击的安装阶段检测攻击者的活动:

• 反恶意软件套件:反恶意软件可以检测和阻止安装。
• 文件完整性监控(FIM) : FIM 可以检测并阻止对系统和应用程序文件的更改。
• 日志审查:审查各种系统日志可以揭示安装的指标。

以下控件是示例控件，可用于在攻击的安装阶段拒绝攻击者的活动:

• 反恶意软件套件:反恶意软件可以检测和阻止安装。
• 文件完整性监控(FIM) : FIM 可以检测并阻止对系统和应用程序文件的更改。
• 短寿命环境:每几个小时更换一次的系统会增加安装难度。
• Windows Device Guard :可以让未经授权的程序更难运行。
• 强制访问控制，Linux 系统上基于角色的访问控制:可以使未经授权的程序更难运行。
• 身份和访问管理控制:严格遵循最小特权原则会使安装变得更加困难或不可能。

以下控件是示例控件，可用于在攻击的安装阶段扰乱攻击者的活动:

• 反恶意软件套件:反恶意软件可以检测和阻止安装。
• 文件完整性监控(FIM) : FIM 可以检测并阻止对系统和应用程序文件的更改。
• 短寿命环境:每几个小时更换一次的系统会增加安装难度。
• Windows Device Guard :可以让未经授权的程序更难运行。
• 强制访问控制，Linux 系统上基于角色的访问控制:可以使未经授权的程序更难运行。

以下控件是示例控件，在攻击的安装阶段，可用于降级攻击者活动:

• 反恶意软件套件:反恶意软件可以检测和阻止安装。
• FIM : FIM 可以检测并阻止对系统和应用程序文件的更改。
• 短寿命环境:每几个小时更换一次的系统会增加安装难度。
• Windows Device Guard :可以让未经授权的程序更难运行。
• 强制访问控制，Linux 系统上基于角色的访问控制:可以使未经授权的程序更难运行。

以下控件是示例控件，可用于在攻击的安装阶段欺骗攻击者:

• 欺骗技术:欺骗技术可以吸引攻击者，欺骗他们攻击假环境。

以下控制示例可用于在攻击的安装阶段限制攻击者的活动:

• 文件完整性监控(FIM) : FIM 可以检测并阻止对系统和应用程序文件的更改。
• Windows Device Guard :可以让未经授权的程序更难运行。
• 身份和访问管理控制:严格遵循最小特权原则可以限制安装。

以下控件是示例控件，在攻击的安装阶段，可用于恢复:

• 备份:根据需要从备份中恢复。
• 图像和容器:根据需要重建基础设施。

在攻击者攻击的安装阶段，还有许多其他控制措施可以帮助检测、拒绝、破坏、削弱、欺骗和限制攻击者。如果攻击者在此阶段成功，大多数组织将不会依赖反恶意软件或基于主机的恢复点来恢复；他们将格式化系统，并使用映像或备份从头开始重建。正如我前面所讨论的，云通过短暂的环境、自动伸缩和其他功能使这变得更加容易。

攻击阶段——指挥和控制(C2)

如果攻击者在他们攻击的安装阶段成功，通常他们会寻求与被入侵的系统建立通信通道。这些通信信道使攻击者能够向他们入侵的系统发送命令，使他们能够在攻击的下一阶段采取一系列行动。僵尸网络就是一个很好的例子。一旦攻击者入侵了系统并在其上安装了 C2 软件，他们现在就可以将这些“僵尸”系统用于各种非法目的，包括身份盗窃、知识产权盗窃、DDoS 攻击等等。

攻击者可以采用多种技术进行 C2 通信。有些比其他的更有创新性和趣味性。通过网络进行通信是最直接的方法，攻击者已经开发了许多不同的方法和协议来促进 C2 通信；这些方法从简单地监听预定义的 TCP 或 UDP 端口号来获取命令，到使用更复杂的协议，如 RPC 和 DNS、定制协议，以及使用代理来进一步混淆它们的通信。

所有这些技术都有可能帮助攻击者远程控制受损环境，同时逃避检测。他们希望自己的网络流量与其他合法的网络流量融合在一起。一些攻击者开发了令人印象深刻的域生成算法，允许攻击者动态更改用于 C2 通信的 IP 地址。十多年前，Conficker 是第一个使用这种方法的大型蠕虫攻击。一些攻击者开发了混淆和加密协议，使防御者更难检测和阻止攻击者的命令。米特 ATT 和 CK 框架提供了攻击者用于 C2 通信的大量技术(米特，2019)。这是一个很好的例子，说明了 ATT&CK 框架(MITRE)和入侵杀伤链框架是如何相互补充的。

通过检测、否认、破坏、降低、欺骗和限制 C2 通信，防御者可以最大限度地降低组织的损失和费用，并加快恢复速度，同时增加攻击者的费用。在这一领域，拥有丰富网络专业知识和能力的供应商，结合威胁情报，可以真正增加价值。维权者可以采取的一些方式包括:

• IDS/IPS :这些系统可以在网络的几个地方检测和拦截 C2 通信。许多组织在其非军事区和企业网络内部运行 IDS/IPS。许多供应商都提供 IDS/IPS 系统，包括:
  • 加拿大白鲑
  • 火眼儿
  • 大功率(High Power)ˌ高压(High Pressure)ˌ高性能(High Performance)ˌ高聚物(High Polymer)
  • 国际商用机器公司
  • 杜松
  • 迈克菲
  • 其他人
• 网络微分段:这可以通过支持组织将策略应用到单个工作负载来提供精细控制。这使得攻击者更难使用受损系统进行 C2 通信。
• 日志审查:分析环境中的日志、网络流量数据和 DNS 查询有助于检测 C2 通信。由于数据太多，人类无法手动完成这项工作，许多组织现在采用人工智能和/或机器学习来为他们完成这项工作。当然，云使这比尝试在内部完成要容易得多。

以下控件示例可用于在攻击的 C2 阶段检测攻击者的活动:

• IDS/IPS :可以检测和停止通信。
• 防火墙和代理服务器:防火墙和代理服务器可以检测和阻止与远程网络的通信。
• 日志审查:审查各种系统日志，包括 DNS 查询，可以揭示 C2 通信的迹象。

以下控件是示例控件，可用于在攻击的 C2 阶段拒绝攻击者的活动:

• IDS/IPS :可以检测和停止通信。
• 防火墙和代理服务器:防火墙和代理服务器可以检测和阻止与远程网络的通信。
• 短暂的环境:每几个小时更换一次的系统会使 C2 通信变得更加困难和不稳定。
• 身份和访问管理控制:严格遵循最小特权原则会使一些 C2 通信技术变得更加困难。
• 网络微分段:执行限制通信的规则会使 C2 通信更加困难。

以下控制示例可用于在攻击的 C2 阶段扰乱攻击者的活动:

• IDS/IPS :可以检测和停止通信。
• 防火墙和代理服务器:防火墙和代理服务器可以检测和阻止与远程网络的通信。
• 短暂的环境:每几个小时更换一次的系统会使 C2 通信变得更加困难和不稳定。
• 身份和访问管理控制:严格遵循最小特权原则会使一些 C2 通信技术变得更加困难。
• 网络微分段:执行限制通信的规则会使 C2 通信更加困难。

以下控件是示例控件，可用于在攻击的 C2 阶段降低攻击者的活动:

• IDS/IPS :可以检测和停止通信。
• 防火墙和代理服务器:防火墙和代理服务器可以检测和阻止与远程网络的通信。
• 短暂的环境:每几个小时更换一次的系统会使 C2 通信变得更加困难和不稳定。
• 身份和访问管理控制:严格遵循最小特权原则可以让一些 C2 通信技术发挥更大的作用。
• 网络微分段:执行限制通信的规则会使 C2 通信更加困难。

以下控件示例可用于在攻击的 C2 阶段欺骗攻击者:

• 欺骗技术:攻击者与假环境通信浪费时间和精力。

以下控件是示例控件，可用于在攻击的 C2 阶段限制攻击者的活动:

• IDS/IPS :可以检测和停止通信。
• 防火墙和代理服务器:防火墙和代理服务器可以检测和阻止与远程网络的通信。
• 短暂的环境:每几个小时更换一次的系统会使 C2 通信变得更加困难和不稳定。
• 身份和访问管理控制:严格遵循最小特权原则会使一些 C2 通信技术变得更加困难。
• 网络微分段:强制执行限制通信的规则会使 C2 通信更加困难。

检测和防止 C2 通信的一个重要方面是威胁情报。在评估供应商时，请记住我在第三章、中提供的关于威胁情报供应商的提示，以便在框架的这一阶段提供帮助。提供旧情报、商品情报和误报很少有帮助，但似乎是许多供应商面临的共同挑战。我还发现，除非 C2 通信或其他恶意网络流量可以追溯到受损环境中的特定身份上下文，否则不太容易被起诉。随后，与身份识别系统集成的 C2 检测和预防系统似乎比没有这种集成的系统更有优势。这些系统的价值似乎是对它们进行微调所花费的时间和精力的函数，尤其是为了最大限度地减少误报。

攻击阶段——侦察 II

攻击者经常命令他们控制的被入侵系统做的事情之一是帮助他们绘制受害者的网络。攻击者通常希望探索受害者的网络，寻找有价值的数据、有价值的知识产权和高价值的资产，以便窃取、破坏或索要赎金。他们还寻找信息、账户、基础设施和其他任何可能帮助他们获得上述贵重物品清单的东西。同样，他们试图将他们的侦察活动融入普通、合法的网络流量、身份验证和授权过程中，这些过程发生在受害者的网络上。这有助于他们逃避检测，并在网络上停留更长时间。

检测侦察活动有助于防御方发现其环境中的受损系统。此外，使攻击者难以或不可能执行这种类型的侦察可能有助于限制与危害相关的损失和费用。这说起来容易做起来难，尤其是在有大量自主开发的应用程序和旧应用程序的遗留环境中，这些应用程序的行为在许多情况下可能令人惊讶和不可预测。许多 SOC 分析师发现了他们网络上的顺序端口扫描，结果却发现一些本土应用使用最嘈杂的方式在网络上通信。这种行为通常可以追溯到开发人员试图在解决问题的同时让他们的生活变得更轻松。世界上充满了这样的应用，这使得检测真正的异常更加困难。

这是另一个阶段,攻击者通常“靠土地生活”无论是运行脚本来执行侦察还是手动执行侦察，当防御者将攻击者需要的大多数工具(默认安装在系统上)留在系统中时，攻击者的工作会变得更容易，而不是更难。在任何可能给攻击者带来不便的地方删除或限制这些常用工具的使用，将使检测这些工具或类似工具在环境中的使用变得更加容易。然而，安全团队不太可能从他们的环境中删除攻击者可以使用的所有二进制文件和库。

这是 MITRE ATT&CK 框架(MITRE)和入侵杀伤链框架之间集成点的另一个很好的例子。ATT&CK 框架提供了攻击者通常试图发现的资产列表和攻击者用来逃避检测的技术列表(MITRE，2019)。这些可用于设计检测、否认、破坏、降级、欺骗和限制侦察的控制集。

以下控件示例可用于在攻击的侦察 II 阶段检测攻击者的活动:

• 欺骗技术:欺骗技术可以帮助检测攻击者的侦察活动。
• 日志审查:审查各种系统日志，包括 DNS 查询，可以发现危害迹象。
• 用户行为分析:可以检测异常行为。
• SAW/PAW :受监控和审计的 SAW/PAW 有助于检测特权凭证的异常使用。

以下控件是示例控件，可用于在攻击的侦察 II 阶段拒绝攻击者的活动:

• 网络微分段:强制执行限制网络流量的规则会增加侦察的难度。
• 身份和访问管理控制:严格遵循最小特权原则会增加侦察的难度。
• 随处加密:对传输中的数据和静态数据进行加密，可以保护数据免受攻击者的攻击。
• SAW/PAW :可以让攻击者更加难以窃取和使用管理员帐户和其他具有提升权限的帐户的凭证。
• 活动目录加固:使攻击者更难访问和窃取凭证。

以下控件是示例控件，可用于在攻击的侦察 II 阶段扰乱攻击者的活动:

• 网络微分段:强制执行限制网络流量的规则会增加侦察的难度。
• 身份和访问管理控制:严格遵循最小特权原则会增加侦察的难度。
• 随处加密:对传输中的数据和静态数据进行加密，可以保护数据免受攻击者的攻击。
• SAW/PAW :可以让攻击者更加难以窃取和使用管理员帐户和其他具有提升权限的帐户的凭证。
• 活动目录加固:使攻击者更难访问和窃取凭证。

以下控件是示例控件，可在攻击的侦察 II 阶段中用于降级攻击者活动:

• 网络微分段:强制执行限制网络流量的规则会增加侦察的难度。
• 身份和访问管理控制:严格遵循最小特权原则会增加侦察的难度。
• 随处加密:对传输中的数据和静态数据进行加密，可以保护数据免受攻击者的攻击。
• SAW/PAW :可以让攻击者更加难以窃取和使用管理员帐户和其他具有提升权限的帐户的凭证。
• 活动目录加固:使攻击者更难访问和窃取凭证。

以下控件是示例控件，可以在攻击的侦察 II 阶段使用来欺骗攻击者:

• 欺骗技术:欺骗技术可以欺骗攻击者花费时间在虚假的环境而不是真实的环境中进行侦察。

以下控件是示例控件，可用于在攻击的侦察 II 阶段限制攻击者的活动:

• 网络微分段:强制执行限制网络流量的规则会增加侦察的难度。
• 身份和访问管理控制:严格遵循最小特权原则会增加侦察的难度。
• 随处加密:对传输中的数据和静态数据进行加密，可以保护数据免受攻击者的攻击。
• SAW/PAW :可以让攻击者更加难以窃取和使用管理员帐户和其他具有提升权限的帐户的凭证。
• 活动目录加固:使攻击者更难访问和窃取凭证。

上述列表中包含的一些功能包括:

• 欺骗技术:无论网络内部执行侦察的一方是攻击者还是内部人员，欺骗技术都有助于检测他们的存在。当有人开始刺探组织中无人合法接触的资产时，这可能是一个危险信号。此外，如果攻击者接受了欺骗技术提供的诱饵，例如窃取凭据，并在环境中的其他地方使用这些凭据，这是一个很好的侦察活动迹象。
• 用户行为分析(UBA) : UBA，或实体行为分析，可以帮助识别用户和其他实体何时以非正常方式访问资源。这可能表明攻击者正在使用内部威胁或被盗凭证，并发现侦察活动。许多供应商都提供这种类型的检测产品，包括:
  • 阿鲁巴岛
  • Exabeam
  • ForcePoint(力点)
  • 记录节奏
  • 微软
  • 南非共和国(Republic of South Africa)
  • 软体
  • 许多其他人
• SAW/PAW :安全管理员工作站(SAW)或特权访问工作站(PAW)将使攻击者更难窃取和使用管理员帐户和其他特权提升的帐户的凭证。受监控和审计的 saw/paw 有助于检测特权凭证的异常使用。
• 活动目录加固:使攻击者更难访问和窃取凭证。
• 无处不在的加密:在数据通过网络传输时保护数据，无论数据存放在何处，都是防止有效侦察的有力控制手段。当然，这依赖于有效的密钥管理。

有更多的方法来检测和使攻击者更难侦察。虽然似乎只有在成功的妥协之后，在响应期间，才发现侦察的泄露秘密的迹象，但是在框架的这个阶段的投资可以为安全团队带来巨大的回报。这种云还可以使探测和防止侦察变得更加容易。

攻击阶段——针对目标的行动

请记住，攻击有许多可能的动机，包括恶名、利润、军事间谍、经济间谍、报复、无政府状态等等。一旦攻击者在攻击中达到这一阶段，他们的目标就可能触手可及。在此阶段，他们可能会将管理员锁定在系统之外，泄漏数据，损害数据的完整性，加密数据和基础架构，使系统无法启动，或者只是持续观察受害者并收集数据。对目标的行动取决于他们的动机。

在某些情况下，这是防御方在恢复变得更加昂贵和可能令人向往之前检测和阻止攻击者的最后机会。然而，攻击者在他们的杀伤链中达到这一阶段的事实并不自动意味着他们可以访问所有资源并完全控制 it 环境；他们的目标范围可能会更小，或者为阻止他们的进展而部署的安全控制可能已经达到了预期的效果。这可能意味着许多用于中断杀伤链其他阶段的控制在这个阶段仍然有用。如果攻击者能够在攻击的早期阶段击败或绕过控制，这并不意味着他们可以随时随地在 IT 环境中这样做。检测和拒绝攻击者是理想的，但是破坏、降低、欺骗和限制他们的攻击比从他们那里恢复更可取。

针对目标的行动是入侵杀伤链模型和 MITRE ATT 和 ACK 框架之间存在巨大潜在集成的另一个阶段。MITRE 公布了攻击者常用的影响技术列表(MITRE，2019)。这个列表可以告知在这个阶段用来打破攻击者杀伤链的控制。

缓解这一阶段攻击时要考虑的一些控制措施包括:

• 数据备份:如果攻击者选择通过损坏存储介质或固件、擦除存储介质、加密数据或篡改数据完整性来销毁数据，备份会非常有帮助。强烈建议离线备份，因为如果攻击者能够使用勒索软件或加密软件，他们会很乐意加密在线备份。
• SAW/PAW : SAW 或 PAW 使攻击者更难使用特权帐户将管理员锁定在他们管理的系统之外。
• 加密无处不在:记住加密不仅提供保密性，还可以维护数据的完整性；加密有助于检测已被更改的数据。
• 身份和访问管理控制:身份是安全的核心。如果攻击者已经拥有环境中的活动目录，那么将很难或者不可能驱逐他们。但是，如果他们只能访问某些帐户，身份和访问管理控制仍然有助于限制他们的攻击范围。

以下控制示例可用于在攻击的目标阶段的行动中检测攻击者的活动:

• 反恶意软件套件:反恶意软件可以检测和阻止恶意软件。
• 文件完整性监控(FIM) : FIM 可以检测并阻止对系统和应用程序文件的更改。
• 日志审查:审查各种系统日志可以揭示危害的迹象。
• 用户行为分析:可以检测异常行为。
• 欺骗技术:欺骗技术可以检测攻击者对资产的操作以及对欺骗资产的使用。
• SAW/PAW :受监控和审计的 SAW/PAW 有助于检测特权凭证的异常使用。

以下控件是可用于在攻击的目标阶段的动作中拒绝攻击者活动的控件的示例:

• 反恶意软件套件:反恶意软件可以检测和阻止恶意软件。
• 文件完整性监控(FIM) : FIM 可以检测并阻止对系统和应用程序文件的更改。
• 短寿命环境:每几个小时更换一次的系统会增加安装难度。
• Windows Device Guard :可以让未经授权的程序更难运行。
• 强制访问控制，Linux 系统上基于角色的访问控制:可以使未经授权的程序更难运行。
• 身份和访问管理控制:严格遵循最小特权原则可以使攻击者对目标的行动更加困难。
• SAW/PAW :可以让攻击者更加难以窃取和使用管理员帐户和其他具有提升权限的帐户的凭证。
• 随处加密:对传输中的数据和静态数据进行加密，可以保护数据免受攻击者的攻击。

以下控制示例可用于在攻击的目标阶段的行动中扰乱攻击者的活动:

• 反恶意软件套件:反恶意软件可以检测和阻止恶意软件。
• 文件完整性监控(FIM) : FIM 可以检测并阻止对系统和应用程序文件的更改。
• 短寿命环境:每几个小时更换一次的系统会增加安装难度。
• Windows Device Guard :可以让未经授权的程序更难运行。
• 强制访问控制，Linux 系统上基于角色的访问控制:可以使未经授权的程序更难运行。
• 身份和访问管理控制:严格遵循最小特权原则可以使攻击者对目标的行动更加困难。
• SAW/PAW :可以让攻击者更加难以窃取和使用管理员帐户和其他具有提升权限的帐户的凭证。
• 随处加密:对传输中的数据和静态数据进行加密，可以保护数据免受攻击者的攻击。

以下控件是可以在攻击的目标阶段的动作中用于降低攻击者活动的控件示例:

• 反恶意软件套件:反恶意软件可以检测和阻止恶意软件。
• 文件完整性监控(FIM) : FIM 可以检测并阻止对系统和应用程序文件的更改。
• 短寿命环境:每几个小时更换一次的系统会增加安装难度。
• Windows Device Guard :可以让未经授权的程序更难运行。
• 强制访问控制，Linux 系统上基于角色的访问控制:可以使未经授权的程序更难运行。
• 身份和访问管理控制:严格遵循最小特权原则可以使攻击者对目标的行动更加困难。
• SAW/PAW :可以让攻击者更加难以窃取和使用管理员帐户和其他具有提升权限的帐户的凭证。
• 随处加密:对传输中的数据和静态数据进行加密，可以保护数据免受攻击者的攻击。

以下控件是控件的示例，可用于在攻击的目标阶段的欺骗攻击者:

• 欺骗技术:欺骗技术可以吸引攻击者，欺骗他们攻击假环境。

以下控制示例中的可用于限制攻击者在攻击目标阶段的活动:

• 反恶意软件套件:反恶意软件可以检测和阻止恶意软件。
• 文件完整性监控(FIM) : FIM 可以检测并阻止对系统和应用程序文件的更改。
• Windows Device Guard :可以让未经授权的程序更难运行。
• 身份和访问管理控制:严格遵循最小特权原则可以使攻击者对目标的行动更加困难。
• SAW/PAW :可以让攻击者更加难以窃取和使用管理员帐户和其他具有提升权限的帐户的凭证。
• 随处加密:对传输中的数据和静态数据进行加密，可以保护数据免受攻击者的攻击。

以下控件是在攻击的目标阶段的动作中可用于恢复的控件示例:

• 备份:根据需要从备份中恢复。
• 图像和容器:根据需要重建基础设施。
• 灾难恢复流程和技术

结论

这是实现入侵杀伤链框架的一种方式。显然，有其他可能的解释和方法来实现这个模型。我已经在会议上看到了一些针对该框架的经过深思熟虑的复杂方法，并在互联网上进行了记录，但是最好的方法是解决您的组织所关注的特定 hva 和风险的方法。

请记住，“最佳实践”是基于其他人心中的威胁和资产，而不一定是您的。

这可能是显而易见的，但是入侵杀伤链框架可以帮助 CISOs 和安全团队采取结构化的方法来管理入侵。可以说，入侵是大多数组织面临的最严重的威胁，因为它们具有潜在的影响，但是 CISOs 还需要应对其他威胁。例如，DDoS 攻击通常不涉及入侵尝试，也不需要 Kill Chain 框架来解决。

此外，这种方法已经变得有点过时，因为在这个世界上，云已经破坏并改进了传统的 IT 和网络安全方法。虽然这种方法仍然有可能在内部和混合环境中非常有效，但一个旨在打破入侵杀伤链和阻止所谓的高级持续威胁 ( APT )参与者的框架在云中并不相关。如果使用有效，CI/CD 管道、短暂的环境、自动扩展和云提供的其他功能就不会给 APT 参与者或其他攻击者留下立足之地，以便横向移动并保持持久性。简而言之，云给了 CISOs 戏剧性地改变竞争环境的机会。我将在第八章、云——安全和合规的现代方法中更详细地讨论云提供的网络安全好处。

鉴于该行业将在未来十年继续从老式的内部 IT 世界过渡到云，入侵杀伤链框架似乎仍然可以作为一种过渡性的网络安全策略来帮助组织。它可以帮助内部和云中的组织实现劳动力现代化，以利用 DevOps 以及即将实现的零信任方法。至关重要的是，采用这种策略仍然比没有网络安全策略或使用我在第五章、网络安全策略中研究的许多其他策略具有潜在的优势。如果您的组织没有网络安全策略，或者有，但没有人能清楚地表达出来，那么您可能比采用入侵杀伤链策略更糟糕。

要做到这一点，在许多情况下，您必须获得比我在这里提供的高级示例更详细、更具体的信息。但是，我想我已经为您提供了一个我们已经研究过的最佳评分网络安全策略的开端。这不是一件坏事。

章节摘要

CISOs 和安全团队在开发保护、检测和响应现代威胁的方法时，有许多网络安全策略、模型、框架和标准可供选择。我们在第五章、网络安全策略中研究的一个以攻击为中心的策略，入侵杀伤链，值得认真考虑，因为它获得了 CFSS 估计的最高总分。在满分为 100 分的测试中，它获得了 95 分的满分。本章试图为您提供一个实现该模型的示例。

入侵杀伤链模型由洛克希德·马丁公司首创；洛克希德·马丁公司的论文中提供的杀伤链阶段包括侦察、武器化、投放、开发、安装、指挥和控制(C2)以及对目标的行动(埃里克·m·哈钦斯、迈克尔·j·克洛普特、罗汉·m·阿明博士)。在实现这个框架之前需要考虑的一个问题是，防御者是应该使用原来的入侵杀伤链框架，还是对其进行更新。

有几种方法可以使这个框架现代化。它可以围绕网络安全常见的可疑因素进行修改或重组，以确保它们得到缓解，并使识别组织安全态势中的差距变得更加容易。将侦察阶段分成两个阶段，而不是一个阶段；一个是攻击者在初次攻击前使用的，另一个是在攻击后使用的。武器化阶段可以放弃，因为 CISOs 在交付阶段之前通常没有非常有效的保护和检测控制。销毁阶段可以替换为更实用的阶段，如限制和恢复。添加一个成熟度指数，以获取和传达每种网络安全能力减轻威胁的程度或效果，可以帮助确定投资不足的领域和防御中的潜在差距。为每个缓解措施添加一个联系点，以明确谁在使用网络安全功能生成的数据，这将有助于确保环境中没有不受管理的缓解措施。跟踪网络安全许可证更新和支持截止日期将有助于防止能力下降。

合理化缓解措施有助于确定投资不足和过度投资的差距和领域。从哪里开始实现取决于许多因素，包括预算、资源、差距以及投资不足和投资过度的领域。在多个地方实现有助于打破杀伤链的控制措施，可能会给安全团队带来更高的 ROI。

我关于如何实现网络安全策略的例子到此结束。希望我提供的小技巧和窍门对你有帮助。在下一章，我将研究 CISOs 和安全团队如何衡量他们的策略实现是否有效。对于安全团队来说，这可能是一个重要但难以实现的目标..

参考

1. Eric M. Hutchins，Michael J. Cloppert，Rohan M. Amin，博士(未注明)。情报驱动的计算机网络防御，通过对手活动和入侵杀伤链分析提供信息。检索自洛克希德·马丁:T3【https://Lockheed Martin . com/content/dam/Lockheed-Martin/rms/documents/cyber/LM-White-Paper-Intel-Driven-defense . pdfT5】
2. H.P. Sanghvi，硕士(2013 年)。网络侦察:网络攻击前的警报。《国际计算机应用杂志》(0975–8887)，第 63 卷第 6 期，第 2-3 页。从 citeseerx.ist.psu.edu/viewdoc/dow… doi = 10 . 1 . 1 . 278 . 5965&rep = re P1&type = pdfT5】](citeseerx.ist.psu.edu/viewdoc/dow…)
3. 马特·米勒，男(2010 年 12 月 8 日)。关于 DEP 和 ASLR 的效力。从微软安全响应中心检索:msrc-blog . Microsoft . com/2010/12/08/on-the-effectiveness-of-dep-and-aslr/
4. 微软公司。(2017 年 10 月 13 日)。控制基于 Windows 10 的设备的健康状况。检索自微软文档:Docs . Microsoft . com/en-us/windows/security/threat-protection/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices
5. 微软公司。(未注明日期)。 PortQry 命令行端口扫描器版本 2.0 。从微软下载中心检索:【www.microsoft.com/en-us/downl… = 17148T5】](www.microsoft.com/en-us/downl…)
6. 米特雷。(2019 年 7 月)。命令和控制。从米特里取回 ATT&CK:T3】https://attack.mitre.org/tactics/TA0011/T5】
7. 米特雷。(2019 年 7 月)。防御闪避。从米特里取回 ATT&CK:T3】https://attack.mitre.org/tactics/TA0005/T5】
8. 米特雷。(2019 年 7 月)。发现。从米特里取回 ATT&CK:T3】https://attack.mitre.org/tactics/TA0007/T5】
9. 米特雷。(2019 年 7 月 25 日)。影响。从米特里取回 ATT&CK:T3】https://attack.mitre.org/tactics/TA0040/T5】
10. 米特雷。(未注明日期)。ATT&CK**T3】。从米特里取回 ATT&CK:T5】https://attack.mitre.org/T7】
11. 米特雷。(未注明日期)。ATT&CK**常见问题*。从 attack.mitre.org/resources/f… ATT&CK:T7】*

七、衡量表现和有效性

我们如何知道我们采用的网络安全策略是否按计划运行？我们如何知道 CISO 和安全团队是否有效？本章将着重于衡量网络安全策略的有效性。

在本章中，我们将讨论以下主题:

• 使用漏洞管理数据
• 衡量网络安全策略的表现和效力
• 以攻击为中心的网络安全策略为例
• 使用入侵重建结果

让我们以一个问题开始这一章。为什么 CISOs 需要测量任何东西？

介绍

网络安全团队需要度量事物的原因有很多。遵从法规标准、行业标准和他们自己的内部安全标准通常是其中的首要因素。

有数百个与治理、风险和法规遵从性相关的指标可供组织选择来衡量自己。学过认证信息系统安全专业人员()认证的人都知道，安全领域数不胜数，包括安全与风险管理、资产安全、安全架构与工程、通信与网络安全、身份与访问管理 ( IAM ，等等。(ISC2，2020)这些领域中的人员、流程和技术的性能和功效可以通过多种方式来衡量。事实上，度量标准的数量和度量方法令人眼花缭乱。如果您有兴趣了解可用指标的范围，我推荐您阅读 Debra S. Herrmann 关于该主题的 848 页的《利维坦》,安全和隐私指标完整指南:衡量法规遵从性、运营弹性和 ROI (Herrmann，2007)。

**除了出于合规性原因衡量事物，网络安全团队还试图找到有意义的指标来帮助证明他们正在为他们支持的业务增加价值。这对 CISOs 来说可能很有挑战性，也有点不公平。关键表现指标(KPI)通常根据目标或目的衡量表现。对于安全团队来说，未能实现目标往往会造成损害。很难找到有意义的数据来证明 CISO 和网络安全团队的投资和努力是组织没有受到威胁或数据泄露的原因。是他们的工作阻止了攻击者成功吗？或者，正如我听到许多非安全管理人员所说的那样，该组织只是“在攻击者的雷达下飞行”吗？这就是我在前言中介绍的潜艇类比有所帮助的地方。在涉及网络安全的互联网上不存在雷达下的飞行；只有来自各个方向的持续压力。此外，希望不是策略，而是放弃责任。

然而，首席信息安全官需要能够向他们的同行、他们支持的企业或公民，以及股东证明，他们创造的成果不是运气或希望实现的副产品。他们需要证明他们的成果是成功执行网络安全策略的产物。我见过很多 CISOs 试图通过观点和轶事证据来做到这一点。

但是，如果没有数据来支持观点和轶事，这些首席信息安全官往往很难捍卫他们的策略和网络安全计划的成功。审计员或顾问提出不同意见，挑战 CISO 对当前事态的描述，这只是时间问题。

数据是衡量网络安全策略的表现和功效的关键。数据帮助 CISOs 管理他们的网络安全计划和投资，并帮助他们证明他们的网络安全计划是有效的，并在不断改进。在这一章中，我将向 CISOs 和安全团队提供如何衡量其网络安全策略有效性的建议。为此，我将使用我在第五章、网络安全策略和第六章、策略实现中研究过的最佳评分策略，即以攻击为中心的策略，作为一个例子。我还将利用我在本书前几章中提供的概念和见解。我不会在这里讨论度量合规性或其他目的，因为有许多书籍、论文和标准已经在做这件事了。让我们先来看看漏洞管理数据的潜在价值。

使用漏洞管理数据

对于刚刚开始实现网络安全计划的组织，或者已经承担了一项计划领导责任的 CISOs 来说，漏洞管理数据可能是一个强大的工具。即使对于成熟的网络安全计划，漏洞管理数据也有助于说明安全团队如何有效地管理其组织的风险，并随着时间的推移不断改进。尽管如此，令人惊讶的是，我遇到过一些大型成熟企业的首席信息安全官，他们不汇总和分析，或者使用他们漏洞管理计划中的数据。当我遇到它时，我感到惊讶。这是因为这些数据是 CISOs 传达其网络安全计划有效性的最直接、最简单的方式之一。

CISOs 和 IT 管理人员面临的一个挑战是根据与业务管理人员衡量和沟通表现的方式相一致的数据制定表现概述。此类数据对 CISOs 的影响也可能完全不同。

例如，当一个生产站点落后于目标时，将会有额外的资源和行动计划来帮助弥补。但是对于 CISOs 来说，额外的资源很少是落后于目标的结果；在很大程度上，安全程序应该是“拨号音”

正如我在前面的章节中详细讨论的，未打补丁的漏洞和安全错误配置是通过漏洞管理程序管理的五个网络安全常见疑点中的两个。随后，一个运行良好的漏洞管理程序不是可选的。正如我在第一章、成功的网络安全策略的要素中所讨论的，完整且最新的资产清单对于漏洞管理计划和整体网络安全计划的成功至关重要。毕竟，安全团队很难管理他们不知道存在的资产。

漏洞管理团队应该每天扫描库存中的所有东西，寻找漏洞和错误配置。这将有助于最大限度地减少未缓解的漏洞和错误配置在其环境中出现和被利用的时间。请记住，漏洞和错误配置可以通过多种方式引入 IT 环境；新披露的漏洞平均每天 33 到 45 个(在过去 3 年中)，从旧映像构建或从备份恢复的软件和系统，失去支持的传统软件和系统，随着时间的推移变得不受管理的孤立资产，等等。

漏洞管理团队每天扫描他们的所有资产，他们将获得环境当前状态的新快照，他们可以将这些快照与以前的所有快照拼接在一起。随着时间的推移，网络安全团队可以通过多种方式使用这些数据。让我举几个例子来说明如何使用这些数据。

管理资产与总资产之比

受漏洞管理团队管理的资产数量与组织拥有和运营的资产总数之比，可能是一些组织感兴趣的数据点。这两个数字之间的差异可能代表风险，特别是如果存在没有被任何人针对漏洞和错误配置积极管理的资产。我在一些组织中看到了这两个数字之间的巨大差异，在这些组织中，IT 人员长期以来一直不足，并且没有足够的文档或部落知识来提供准确的资产清单。随后，可能会有 IT 资产的子网没有被清点，也没有作为漏洞管理计划的一部分进行主动管理。

我还发现，当首席信息官与 IT 领导层关系不佳时，这些数字会有很大差异；在这种情况下，不准确的 IT 清单似乎很常见，并给组织带来真正的风险。在我见过的一些案例中，IT 知道所有或大部分资产的位置，但不会主动与 CISO 合作，以确保它们都被清点和修补。正如我在第一章、成功网络安全策略的要素中所写的，首席信息安全官必须努力与他们的利益相关者社区保持良好的关系，尤其是与他们的 IT 组织。首席信息官和首席技术官还需要认识到，他们的角色越来越多地与 CISO 有着共同的命运；当漏洞管理程序失败时，他们都失败了，应该分享“荣耀”CISO 成为 IT 安全失败的唯一替罪羊的日子已经成为过去。处于这种情况下的 CISOs 应该努力改善与 IT 合作伙伴的关系。在某些情况下，这说起来容易做起来难。

在图 7.1 所示的示例场景中，漏洞管理计划全年持续管理相同数量 IT 资产的漏洞和错误配置。幸运的是，他们没有意识到有一些子网的 IT 资产不是他们管理的。他们也没有积极管理这一年中引入环境的新 IT 资产。图中两条线之间的空间代表组织面临的风险:

图 7.1:趋势数据示例，说明库存中的 IT 资产总数与漏洞管理计划中注册的资产数量之间的差异

为了最大限度地降低风险，IT 资产的总数和每天主动管理漏洞和错误配置的资产的总数应该相同。然而，在大型复杂的环境中，可能有很好的理由让这条规则有例外。但是负责管理漏洞的团队仍然需要知道、理解和跟踪异常；否则，组织面临的风险不会暴露给组织中正确的管理层。换句话说，如果组织将拥有未打补丁的系统，那么这样做的决定以及持续多长时间的决定需要由最高的适当管理层接受，并定期重新检查。

对于这样的决策，合适的管理层可能根本不在 IT 部门——这取决于他们所采用的组织和治理模型。请记住，允许未打补丁的系统在环境中运行的决定是代表整个组织接受风险的决定，而不仅仅是该资产的所有者或管理者。我见过项目经理为了满足他们项目的进度、预算和质量目标，而过于热情地代表他们的整个组织接受各种各样的风险。尽管事实上他们的角色范围仅限于他们所从事的项目。如果风险从未升级到适当的管理级别，它可能会永远处于未知和潜在的不受管理状态。应采用风险登记来跟踪风险，并定期重新评估风险接受和转移决策。

在 IT 资产总数和针对漏洞进行主动管理的资产总数存在显著差异的环境中，这是 CISOs 和漏洞项目经理展示他们如何努力缩小这一差距从而降低组织风险的机会。他们可以利用这些数据向 IT 领导和董事会说明组织面临的风险。要做到这一点，他们可以使用不完整和不准确的资产清单，并谈论不受管理的资产的存在。CISOs 可以定期向利益相关方提供最新信息，说明漏洞管理团队管理的资产数量与组织拥有和运营的资产总数之间的差异如何随着时间的推移而变化，以及 IT 部门和他们的网络安全团队如何共同努力减少和最大限度地降低这种差异。该数据点代表了组织面临的真实风险，趋势数据说明了 CISO 及其漏洞管理团队是如何管理风险的。如果这一数字朝着错误的方向发展，高级领导层和管理委员会有责任认识到这一点，并帮助解决这一问题。

图 7.2 显示了 CISO 和漏洞管理团队一直在与他们的 IT 合作伙伴合作，以降低未加入漏洞管理计划的系统带来的风险。

这是一个积极的趋势，CISO 可以借此传达网络安全计划的价值:

图 7.2:趋势数据示例，说明库存中的 IT 资产总数与漏洞管理计划中注册的资产数量之间的差异在不断改善

已知未打补丁的漏洞

漏洞管理计划的另一个关键数据点是环境中存在的已知未修补漏洞的数量。请记住，一些组织的 IT 资产清单中存在未打补丁的系统有很多原因。坦率地说，我听到的最常见的原因是缺乏对漏洞管理项目的投资；人手不足和资源不足的计划根本无法管理其环境中的大量新漏洞。除了时间之外，测试和部署安全更新还需要训练有素的人员、有效的流程和支持技术。

不管原因是什么，了解哪些系统未打补丁、未打补丁的漏洞的严重性以及针对它们的缓解计划仍然很重要。定期分享未修补漏洞的数量是如何减少的，有助于传达 CISO 和网络安全团队是如何为企业的成功做出贡献的。对于快速变化的环境，需要考虑的一个细微差别是，尽管基础架构发生了重大变化或 IT 资产数量增加，漏洞的数量如何减少。为了有效地传达这一点，CISOs 可能需要就漏洞管理指标的基础和细微差别，以及它们对组织整体风险的重要性，对他们的一些利益相关者进行培训。董事会中通常只有一两个成员有网络安全经验，而在典型的高管层中有这种经验的高管就更少了。根据我的经验，教育这些利益相关者是值得花时间的，并且将帮助每个人理解网络安全团队提供的价值。在漏洞管理团队资源不足的情况下，这些数据可以帮助以易于理解的方式构建增加投资的业务案例。

图 7.3 展示了一个场景，漏洞管理团队成功地最小化了其环境中未修补漏洞的增加，尽管在其计划中注册的 IT 资产数量略有增加。但是，收购一家 10 月份关闭的小型公司引入了大量新的 IT 资产，漏洞管理团队需要管理这些资产。这导致未打补丁的漏洞数量急剧增加，到本季度末，该团队能够将其减少到更典型的水平:

图 7.3:趋势数据示例，说明已修补漏洞的数量、未修补漏洞的数量以及组织漏洞管理计划中注册的系统数量

有了这样的数据，CISO 和网络安全团队就像英雄一样。如果没有这样的数据，就很难描述收购给漏洞管理团队带来的挑战、随之增加的工作量以及积极的结果。不过，这也不全是好消息，因为该组织的环境中存在大量且不断增加的未修补漏洞。CISO 应该能够阐明将未修补漏洞的数量尽可能减少到零的计划，使用相同的数据来请求更多的资源来加速这一努力。注意，我在这个例子中使用的数字完全是虚构的；实际数据可能会有很大差异，这取决于资产、硬件、软件、应用程序、修补策略、治理实践等的数量。

但是对于一些组织来说，减少未打补丁的漏洞数量说起来容易做起来难。一些已知的漏洞根本无法修补。这有许多原因。例如，许多供应商不会为不再受支持的软件提供安全更新。一些供应商停业，随后，他们的客户已经部署的产品的安全更新将永远不会提供。另一个常见的例子是遗留应用程序，它们与操作系统或 web 浏览器的特定安全更新存在兼容性问题。在这种情况下，通常会有一些变通办法，即使没有安装修复这些漏洞的安全更新，也可以实现这些办法，使利用特定漏洞变得不可能或不可能。通常，在可以部署修复漏洞的安全更新之前，变通办法是短期解决方案。然而，在许多环境中，工作区变成了永久租户。报告如何使用变通办法而不是安全更新来缓解已知的未打补丁的漏洞，有助于传达风险及其管理方式。提供诸如正在进行的解决方案、已部署的和没有可用的解决方案之类的类别，可以帮助业务发起人了解哪里需要做出决策。部署了变通办法的系统的数量，以及它们缓解的底层漏洞的严重性，提供了环境中风险的细微视图。将这些数据与针对潜在漏洞的长期缓解计划结合起来，CISOs 就有了一个可以与利益相关者分享的风险管理故事。

按严重性划分的未修补漏洞

另一个潜在的强大数据点是环境中未打补丁的漏洞数量，按严重性分类。正如我在第二章、使用漏洞趋势降低风险和成本中详细讨论的那样，由于被利用的可能性和影响，关键和高严重性漏洞代表着最高的风险。了解环境中在任何时候都存在多少这样的漏洞、它们存在了多长时间以及补救时间都是重要的数据点，有助于阐明它们带来的风险。从长远来看，这些数据可以帮助 CISOs 了解这些风险缓解的速度，并发现导致其环境中相对较长生命周期的因素。这些数据可以帮助漏洞管理项目经理和 CISOs 为更多资源和更好的流程和技术建立业务案例。这些数据也可以是网络安全团队的价值以及他们为组织管理风险的有效性的最有力的指标之一，因为这些漏洞带来的风险是最严重的，并且很容易向高管和董事会表达。

不要低估 IT 环境中中等严重性漏洞对攻击者的价值。由于严重和高评级漏洞的货币价值，攻击者一直在寻找方法使用中等严重性漏洞的组合来危害系统。CISOs 和漏洞管理团队需要积极管理这些漏洞，以最大限度地降低环境风险。这是向他们支持的企业展示价值和交流不断修补这些漏洞的进展的又一次机会。

按产品类型划分的漏洞

另一个潜在的有用的数据集是按产品类型分类的漏洞。让我们面对它；大多数操作发生在用户桌面上，因为它们会通过外围防御将威胁带入 IT 环境。正如眼睛是心灵的窗户，浏览器对于操作系统也是如此。攻击者不断试图找到并利用 web 浏览器和操作系统中的漏洞。

图 7.4 中探究的数据在第二章、中也有涉及，利用漏洞趋势降低风险和成本:

图 7.4:按产品类型分类的 CVE 最多的 25 种产品中的漏洞(1999-2019)(CVE 细节，2019)

漏洞管理团队可以为他们的环境开发类似的视图，以说明他们所面临的挑战以及他们管理挑战的能力和进度。像这样的数据，结合我之前讨论的数据点，可以帮助说明组织的风险所在，并帮助优化其处理。环境中操作系统、web 浏览器和应用程序中未修补、严重、高和中等严重性漏洞的数量，以及不受漏洞管理计划管理的系统的数量，有助于 CISOs 及其利益相关方了解其 IT 环境中的风险。当然，根据环境的不同，包括与基于云的资产、移动设备、硬件、固件、设备、路由和交换设备以及每个 IT 环境中使用的其他技术相关的数据将提供更完整的视图。这些技术的组合及其潜在的漏洞对于每个组织来说都是独特的。

向执行管理团队和董事会成员提供这样的量化数据有助于他们理解现实和观点。没有这种类型的数据，就很难做出令人信服的商业案例，也很难根据网络安全项目的目标交流进展。这些数据还将使随机的高管和其他利益相关方(如过于激进的供应商)更容易向网络安全计划的利益相关方询问成为新闻头条的“当前漏洞”。如果高级利益相关者知道他们的 CISO 和漏洞管理团队正在称职且勤奋地管理其环境中的漏洞和错误配置，那么大量可能分散 ciso 注意力的干扰就可以被过滤掉。

这种报道对一些人来说可能听起来复杂和吓人。好消息是已经有漏洞管理产品可以提供丰富的分析和报告功能。CISOs 并不局限于我在本章中提供的想法，因为漏洞管理供应商有很多很好的方法来帮助衡量和交流进展。关键是使用分析和报告机制来有效地向风险承担者展示您的漏洞管理计划如何降低组织的风险，并在需要时请求资源。

尽管来自漏洞管理程序的数据对 CISOs 非常有帮助，但它只能帮助他们管理五个网络安全常见嫌疑人中的两个。可能有更多的数据可以帮助 CISOs 了解和管理其网络安全策略的性能和效力。接下来让我们使用我在第六章、策略实现中详细讨论的例子来探讨这个问题，这是一个以攻击为中心的策略，入侵杀伤链框架(Eric M. Hutchins，Michael J. Cloppert，Rohan M. Amin，博士)。

衡量以攻击为中心的策略的性能和功效

正如我在第五章、网络安全策略和第六章、策略实现中提到的，入侵杀伤链框架具有许多属性，使其成为一种有吸引力的网络安全策略。首先，它在第五章中获得了最高的网络安全基础评分系统 ( CFSS )估计总分。

这意味着它有最大的潜力来充分减轻网络安全通常的嫌疑。此外，这种方法可用于内部环境以及混合环境和云环境。也许我最喜欢这个框架的一点是，它的性能和功效可以用一种相对简单的方式来衡量。让我们详细检查一下。

执行入侵重建

当你阅读它时，这可能看起来很奇怪，但是当涉及到衡量网络安全策略的性能和效力时，入侵企图是攻击者给防御者的礼物。它们是礼物，因为它们测试防御者的网络安全策略的执行和操作。但是为了从入侵尝试中获取价值，必须分解和研究每一个成功的、部分成功的和失败的入侵尝试。在这样做的时候，有两个关键问题需要回答。首先，在攻击者被检测到并最终被阻止之前，他们的入侵杀伤链(Eric M. Hutchins，Michael J. Cloppert，Rohan M. Amin，博士)进展到什么程度了？第二，攻击者如何击败或绕过网络安全团队为打破他们的入侵杀伤链而部署的所有缓解控制层？换句话说，如果攻击者进入了入侵杀伤链的第四阶段，他们如何通过第一、第二和第三阶段的所有缓解措施呢？

这些是入侵重建(Eric M. Hutchins，Michael J. Cloppert，Rohan M. Amin 博士)应该帮助回答的核心问题。在寻找这两个问题的答案时，入侵重建还应该回答许多其他问题，这些问题将有助于衡量这种方法的每个实现的性能和功效。正如您将在我描述这个过程时看到的，这些问题的潜在主题是，正在努力打破攻击者入侵杀伤链的人员、过程和技术是否有效。我们希望发现在我们以攻击为中心的策略的每个阶段是否需要任何改变。我们开始吧。

洛克希德·马丁公司关于入侵杀伤链的论文讨论了入侵重建的概念。我再次推荐阅读这篇论文。我将在本章描述的方法与洛克希德·马丁公司论文中描述的方法略有不同。至少有几种方法可以完成入侵重建；我将描述一种我曾经成功使用过的方法。

这种方法假设防御者无法自信地进行归因，因此它不像其他方法那样依赖于归因。我认为这是一个优势，因为随着攻击者变得越来越老练，错误归属的可能性也会增加。我的入侵重建方法的目标是确定入侵杀伤链框架的实现可以改进的地方，而不是确定攻击者并对他们采取军事或法律行动。

让我就何时进行入侵重建提供一些建议。事故响应活动正在进行时，请勿执行重建。在活动事件期间，使用在您组织的事件响应流程中发挥作用的宝贵资源和专业知识是不必要的干扰。重建可以等到危机时期过去之后。理想情况下，重建可以在事件过去几天或几周后参与者对细节记忆犹新的时候进行。然而，如果你的组织总是处于危机状态，那么就忽略这个建议，尽可能地接触他人和信息。也许你可以通过找出导致危机的缺陷来帮助打破危机循环。

为了执行入侵重建，我强烈建议您从负责网络安全策略、架构、保护、检测、响应和恢复的所有团队中至少挑选一名代表。在非常大的环境中，这可以限制在负责入侵尝试所涉及区域的相关团队的范围内。一旦组织变得擅长重建，参与者的数量可能会减少更多。但是您需要专业知识和可见性，每个团队都必须重现每个失败、部分成功和完全成功的入侵尝试中发生的事情。请记住，我在第六章、策略实现中对行动方案矩阵(Eric M. Hutchins、Michael J. Cloppert、Rohan M. Amin 博士)所做的修改之一是为每个缓解措施添加一个“数据消费者联系点”。这些信息有助于从不同的团队中找到合适的人来参与重建。

应该决定是否邀请供应商参加这些会议。我通常发现让我们曾经使用的一些网络安全供应商的可信代表参与入侵重建是有帮助的。

这种方法至少有几个好处。首先，供应商应该能够围绕他们的产品和服务带来专业知识，并提供否则可能会被忽略的见解。其次，与您选择的帮助您抵御攻击者的供应商分享攻击者给您的“礼物”非常重要。这些练习可以让你的供应商做出更好的产品，你的组织和其他人都可以从中受益。但是这也给了你一个机会来看看你的供应商到底有多愿意帮忙，以及他们是否愿意为他们的缺点负责。我发现，我使用的一些供应商，我以为他们会在安全事件中支持我，但当我真正需要他们时，他们却像马戏团帐篷一样折叠起来，离开了城镇。在入侵重建过程中，这些供应商有勇气参与，但通常会将他们产品的失败归咎于他们的客户。如果您对供应商做了足够多的重构练习，您将有可能确定他们是否真的有愿望和能力以您认为他们会的方式帮助您的组织。当他们的产品许可更新日期临近时，这些知识会派上用场。我将在本章后面详细讨论这一点。

尽管如此，邀请供应商参与重建也有相关的风险。简单来说，有些厂商在保密信息保密方面真的很差。我的建议是，根据具体情况，与参与重建工作的利益相关方讨论让供应商参加这些会议。如果供应商增加了足够的价值并且值得信赖，那么就有理由让他们参与这些练习。在最终决定让供应商参与这些活动之前，与高层领导讨论这一想法并征求他们的意见也是一个谨慎的步骤。

如果您的组织有一个取证团队或使用一个供应商进行取证，这些专家对入侵重建工作会有极大的帮助。他们拥有的工具和技能有助于确定重建中的系统是否、何时以及可能如何遭到破坏。根据我的经验，我遇到过两种类型的取证团队。第一个是传统的法医团队，他们有经过认证的法医检查员，他们遵循严格的程序来保持他们收集的证据的完整性。

根据我在拥有这种取证团队的组织中的经验，他们需要一个全职的专家团队来保存证据，维护监管链，并可能在他们帮助调查的刑事案件中出庭作证。更常见的情况是，组织将这类工作外包出去。

我更经常看到的另一种类型的取证团队，履行不同的职能，有时被简单地称为事故响应者。他们也试图确定系统是否被入侵。但这些团队通常没有经过认证的法医专业人员，不保持证据的完整性，也不打算在法庭上作证。事实上，很多时候，他们努力确定系统是否已经被破坏，结果是破坏了在刑事诉讼中被认为是证据的东西。在这里，我遇到了一些有资质的法医专家的有趣的、有时是偏狭的态度，因为他们中的许多人根本不会把这些努力称为法医，因为他们销毁证据，而不是妥善保存证据。但是这些人需要记住，许多戴着粉红色戒指的工程师讨厌 IT 工程师在他们的头衔中使用“工程师”;设计建筑的建筑师也不喜欢 IT 建筑师用自己的头衔，“安全研究员”这个头衔让很多学术研究者望而却步。但是我跑题了。现实是，并不是每个组织都想花时间和精力追踪攻击者，并试图在法庭上起诉他们。组织需要决定他们需要哪种类型的取证专业人员，以及他们是否负担得起。当这两种取证专家帮助确定系统是否已经被入侵并参与入侵重建演习时，他们都是物有所值的。

谁应该领导重建工作？我建议由负责网络安全策略的个人或团体来领导这些练习。该个人或团队最终负责整体策略的表现和功效。他们还可能负责根据需要进行调整，以确保策略的成功。策略小组的替代方案是事件响应 ( IR )团队。IR 团队应该掌握领导入侵重建所需的大部分(如果不是全部)细节(Eric M. Hutchins、Michael J. Cloppert、Rohan M. Amin 博士)。如果他们没有，你就已经确定了第一个需要改进的地方。

IR 团队负责管理事件，因此他们应该能够轻松获得与部分和完全成功的入侵尝试相关的大部分信息。但他们可能不会参与不符合事故条件的失败尝试。在这些情况下，SOC 人员、运营人员和建筑师可能拥有重建的关键信息。

请记住，我们的目标不是对组织面向互联网的防火墙上发生的每个端口扫描进行分类。我建议在参与重建工作的小组之间就一个原则达成一致，该原则用于确定应该执行重建的入侵类型。也就是说，定义确定是否执行正式重建的入侵尝试的特征。如表 7.1 所示，使用我们从第六章、策略实现中更新的行动过程矩阵，一个有效的原则可以是，在交付阶段中，任何使其比拒绝行动更进一步的入侵都应该被重建。一个不那么激进的原则是，任何导致恢复操作的入侵尝试都应该被重建。在这两个例子之间还有许多其他选择。

这一原则的目标是实现一致性，有助于适当平衡风险和重建参与者的宝贵时间。这个原则不需要被刻在石头上，它可以随着时间的推移而改变。当一个组织第一次开始执行重建时，他们可以有一个相对积极的原则，使他们能够快速学习。然后，一旦来自重建的经验已经“正常化”了，就可以采用一个不那么激进的原则。但在这些重建活动中，利益相关方就启动这些活动的原则达成一致，对于这些活动的长期成功以及网络安全策略的成功至关重要。相对于入侵尝试而言，太少的重建可能意味着组织没有对攻击者给予的礼物给予足够的重视，并且可能对攻击调整得太慢。太多的重建会带来破坏性和反效果。随着时间的推移，达成一致的原则应该为利益相关方群体找到正确的平衡。

表 7.1:第六章“策略实现”中更新的行动方案矩阵示例(Eric M. Hutchins、Michael J. Cloppert、Rohan M. Amin 博士)

一旦确定了合适的参与者或其代表，并且入侵重建负责人准备好进行协调，就可以安排重建会议。为参与者提供足够的准备时间和指导来为重建收集适当的数据将有助于节省时间和减少挫折。根据我的经验，一些重建工作很简单，因为入侵企图在早期就被检测到并阻止了。在这些情况下，参与者的数量和他们重建入侵企图所需的数据量可能相对较少。随后，这个练习通常需要的时间相对较短，例如 45 分钟或一个小时。如果您刚刚开始在您的组织中进行重建，您自然需要比习惯之后多一点的时间。对于更复杂的入侵尝试，尤其是当攻击者进入其杀伤链的后期阶段时，可能需要拥有更多数据的更多参与者，从而增加了重建练习所需的时间。

我工作过的许多组织都用代号来标记安全事件。所有关于事故的后续通信都使用其代号。这样，如果一封电子邮件或其他通信被某个没有被读到事件的人看到，其背景和意义就不明显了。当组织用事件代码名称标记事件时，关于入侵重建的通信和邀请应使用事件代码名称。如果您决定使用事故代码名称，请仔细考虑您使用的名称，避免使用可能具有攻击性的标签。这包括英语以外的其他语言的名称。

如果该代码名称成为公共知识，请考虑对组织声誉的潜在影响。远离那些与公司品牌或公司希望在顾客心目中建立的品牌不一致的主题。除了良性代号之外，确实没有令人信服的商业理由来使用任何东西。这些很无聊，但在多个层面上有效。

现在，我们的重建工作有了一个代号，参与者将带来相关数据，一些值得信赖的潜在供应商将参与其中，还有一个领导者来促进这项工作。这个练习的目的是重建攻击者在他们的杀戮链的每个阶段所采取的步骤。要做到这一点可能没有完全的把握，对他们的战术和技术的一些假设可能是必要的。但是，重构包含的细节越多，就越容易识别人员、流程和技术表现符合预期或表现不佳的领域。在这些练习中，准备好做详细的笔记。入侵重建演习的产品应该是一份报告，其中包含入侵企图的详细信息，以及网络安全团队已实现的防御措施的性能。这些工件将潜在地具有多年的价值，因为它们将提供关于过去攻击的知识的有用的连续性，即使当关键员工离开组织时。换句话说，当从这些入侵尝试中吸取的经验教训被记录下来时，它们可供当前的和将来的人员借鉴。这是我将入侵尝试称为“礼物”的另一个原因。

我们更新的杀伤链框架有七个阶段。重建工作应该从哪里开始？在第一阶段，或者可能是最后阶段？这个问题的答案是，看情况。有时，入侵很简单，可以按顺序从头到尾绘制出来。然而，对于复杂的入侵或几个月或几年前开始的入侵，以这种方式进行重建可能是不谨慎或不可能的。从你最了解和最有把握的阶段开始。这可能是杀人链的最后一环。从你的起点出发，利用重建参与者提供的数据和见解，在两个方向上建立一个时间表。由于缺乏数据或不确定性，可能无法建立完整的时间表。

重建揭示的细节越多越好，因为这将有助于识别改进的机会、差距和防御中的失败。在我的例子中，我将简单地从第一阶段开始，通过杀伤链向前推进。但是要注意的是，这不可能对每一次入侵都这样做。先说侦察 I 阶段。

在攻击前的侦察 I 阶段，可能无法确定任何特定威胁参与者的活动。由于如此多的网络流量不断轰击所有连接互联网的设备，挑选出特定攻击者进行的特定探测和侦察活动通常具有挑战性。但也不是不可能。这是一个结合了人工智能 ( AI )、机器学习 ( ML )、良好威胁情报和粒度日志的领域，非常有前途。使用 AI/ML 系统在海量日志数据中搅动，如网络流量数据、DNS 日志、认证和授权日志、API 活动日志等，以接近实时的方式找到特定攻击者的活动，这不再是科幻小说。如今，云服务可以大规模做到这一点。锦上添花的是，你可以通过亚马逊 Alexa (Worrell，2018)将安全调查结果读给你的 SOC 分析师听！这些能力直到最近还只能在科幻小说中实现。但是现在，只要有信用卡和一点时间，任何人都可以通过云计算提供的功能实现这一点。真的很神奇！我将在下一章详细讨论云计算。

从攻击的交付阶段收集数据和见解显然是非常重要的。关键问题是，攻击者如何击败或绕过网络安全团队为打破这一阶段的杀伤链而部署的层层缓解措施？他们是如何成功交付武器的，涉及到哪些人员、流程和技术？

为了回答这些问题，我发现在参与者的帮助下，在白板上画出系统流程图是很有用的。首先，尽可能详细地绘制基础架构，包括外围防御、服务器、客户端、应用程序、系统名称、IP 地址等。绘制相关基础架构的地图，并绘制数据在该基础架构中应该如何流动、使用的协议、身份验证和授权界限、涉及的身份、存储等图表。然后，画出攻击者在入侵尝试期间是如何交付武器的，以及交付期间发生了什么。

攻击者在这一阶段成功的原因是什么？这个问题的答案包括询问和回答许多其他问题。让我给你举几个例子。入侵重建中一个有用的数据点是检测到攻击需要多长时间。建立攻击时间表是帮助确定攻击执行方式的有用工具。在交付阶段(Eric M. Hutchins、Michael J. Cloppert、Rohan M. Amin 博士)，是否检测到了武器的交付，是通过何种控制手段检测到的？如果没有检测到交付，记录哪些控制应该检测到它。如果您的 Kill Chain 框架实现中存在明显差距，请记录。当您在策略实现中补救缺陷时，这些信息将非常有用。

是否有任何控制措施本应检测到交付，但却未能做到？为什么这些控制没有按预期运行？他们失败是因为他们没有做供应商承诺的事情吗？他们失败的原因是控制之间的集成或自动化，还是系统没有按预期工作？这就是重建流程图中系统的日志数据和其他数据源非常有用的地方。通过流程图中各系统日志中的数据，尝试一步步拼凑出武器是如何交付的。所有这些系统看起来都像预期的那样运行吗？如果没有，找出异常和薄弱环节。在某些情况下，日志数据可能不可用，因为日志记录没有打开，或者激进的数据保留控制删除了日志数据。是否有充分的理由不在这些系统上启用日志记录并存储日志以备将来使用？

有足够的数据来确定武器是如何投放的吗？有时，根据现有的数据，根本不可能确定武器是如何交付的。一些 IR 团队将第一个被入侵的系统称为“零号病人”。在一些入侵中，攻击者的进入点非常明显，可以追踪到电子邮件、访问恶意网站、USB 驱动器、恶意软件等等。在其他情况下，如果最初的攻击是在几周、几个月或几年前完成的，并且攻击者擅长掩盖他们的踪迹，找到零号病人是一种渴望，而根本不可能。想想在这种情况下什么会对你有帮助。增加日志记录的详细程度会有帮助吗？将日志存档更长时间或将日志运送到异地会有帮助吗？有没有一些你目前不具备的能力可以帮助填补这个空白？

交付阶段缓解措施的数据消费者是否获得了检测和打破该阶段所需的数据？例如，SOC 是否获得了检测入侵所需的数据？在更新的行动方案矩阵中确定的数据消费者是否按预期接收或访问了数据？如果不是，是哪里出了问题？是数据交付机制失败了，还是因为某种原因，需要的数据在目的地被过滤掉了？在数据的收集、传递和分析中可能有多次失败。深入了解这一点，找出那些没有按计划进行的事情，并记录下来。

控制、自动化和集成是否按预期工作，但人员或流程是失败的根源？这种情况比你想象的要多。架构是健全的，系统按预期工作，技术按预期执行，武器被检测到，但没有人注意，或者警报被注意到但被解除。不幸的是，人员和流程故障与技术控制故障一样常见，如果不是更常见的话。SOC 流程中的失败、糟糕的决策、犯错误的供应商，有时仅仅是关键人员的懒惰，都会导致无法检测和阻止攻击。

在攻击的这一阶段，攻击者和/或防御者运气好吗？我遇到的一些安全专家告诉我，他们不相信运气。但我把这种信念归结为幼稚。我见过攻击成功是因为喜剧般的错误，这些错误可能无法重复或复制。人员、流程、技术和环境的组合可能导致攻击场景，就像中了彩票一样。不要低估运气的作用。请记住，并非所有的风险都能真正被识别；“黑天鹅”事件可能发生(Taleb，2007)。

一旦重建团队了解了攻击的交付阶段是如何完成的，并且已经记录下来，我们就可以进入攻击的下一个阶段，即开发阶段(Eric M. Hutchins，Michael J. Cloppert，Rohan M. Amin，博士)。在这里，重建团队将重复该过程，使用数据来尝试确定是否尝试、检测和停止了利用。我们在交付阶段问的问题同样适用于这个阶段。哪些控制措施未能防止和发现剥削？在攻击的这个阶段，保护和检测控制方面的差距在哪里促成了攻击者的成功？

供应商的网络安全缓解措施像宣传的那样有效吗？数据消费者是否获得了检测和打破这一阶段所需的数据？IR 流程是否按计划开始并运行？我们可以从攻击者在这一阶段的成功中学到什么，以使这种成功在未来变得更加困难或不可能？记录你的发现。

继续对压井链的所有阶段进行调查。可能有些阶段什么也没发生，因为攻击者在这些阶段之前就被阻止了。请注意何时何地成功检测到攻击并成功破解。如果攻击没有在当前阶段被破坏，后续阶段中的缓解措施会成功检测并阻止攻击吗？在评估中尽可能坦诚地对待自己；陈词滥调、乐观主义和未定义未来的计划可能不足以打破下一个攻击者的入侵杀伤链。然而，清醒地下定决心让攻击者尽可能地难以下手可能会有所帮助。记得记录这些想法。

现在重建已经完成，您已经根据需要询问和回答了尽可能多的问题，以发现发生了什么，最好是在攻击的每一步。接下来，让我提供一些例子，说明在失败、部分成功和完全成功的攻击之后，重建应该确定的具体可操作的事情。

使用入侵重建结果

首先，回忆一下第六章、策略实现中关于识别差距和过度投资及投资不足领域的讨论。入侵重建可以确认在计划实现该策略时所做的一些差距和投资不足的分析。例如，如果在规划期间发现交付阶段的检测差距，并且后来的入侵重建数据也说明了同样的差距，这是一个奇怪的令人安心的消息。现在，CISO 有了更多的数据来帮助构建投资商业案例，以缩小这一差距。CISO 说他们需要投资探测能力是一回事，否则会发生不好的事情。但是，当 CISOs 能够向高级管理人员和董事会证明攻击者一直在积极利用已知漏洞时，这样的请求就更加有力了。

当 CISOs 能够提供风险真实存在的证据时，它反驳了风险是理论上的任何概念。这也有助于建立一种以前没有的紧迫感。如果入侵尝试导致与响应和恢复活动相关的计划外费用，这将有助于说明与差距相关的当前和潜在未来成本。这些数据可以为风险等式的概率和影响面提供信息，从而更容易与其他风险进行比较。使用这样的数据，CISOs 可以在每次网络安全计划审查会议上向其管理委员会提供差距和投资不足领域的更新，直到它们得到缓解。

当重建工作发现以前未知的差距或投资不足的领域时，这确实是攻击者的礼物。通过这样做，攻击者为 CISOs 提供了对其策略实现中的缺陷的宝贵见解，以及实现新的缓解措施或改进现有措施的明确行动号召。入侵重建数据也有助于为网络安全投资路线图提供信息。请记住，在入侵杀伤链中尽可能早地阻止攻击者比在后期阻止他们更可取。重建数据可以帮助网络安全团队确定和优先考虑缓解措施，这将有助于攻击者更难或不可能进入攻击的后期阶段。帮助网络安全团队了解在交付和利用阶段的不足和需要改进的地方是入侵重建工作的一个重要成果。然后，这些数据可用于规划投资路线图，该路线图绘制了组织计划部署的人员、流程和技术以及部署时间。由于大多数组织都有资源限制，重建数据和他们提供的投资路线图可能会成为网络安全团队规划流程的核心。

还记得我在第一章、中讨论的那些网络安全的当务之急及其支持项目吗？成功的网络安全策略的要素？当务之急是一个大胆的多年目标，最好与组织的业务目标一致。升级到急需的现代身份系统，或者最终放弃 VPN，为成千上万的信息工作者提供现代远程访问解决方案，就是两个例子。重建数据有助于为网络安全需求提供支持数据，并为处理这些数据的工作人员提供共同的目标感。相反，重建数据可能并不总是支持这样的观念，即计划的必要措施是组织的正确方向。

没有人期望这些一定会协调一致，尤其是在具有复杂环境和多项要务的大型组织中。但是，当雷击和重建数据表明一个命令对组织来说是至关重要的，它可以增压正在工作的项目团队。这种积极的势头有助于维持项目时间表，并使项目跨越终点线。

识别蹩脚的控制

源自入侵重建的另一个潜在行动领域是纠正未能按预期执行的缓解措施。这些控制措施已经部署并得到积极管理，但没有按照设计保护、检测或帮助响应入侵企图。显而易见，首席信息安全官和安全团队不能依赖不按他们应该的方式工作的控制措施。失败的控制有一系列可能的根本原因。

失败的一个常见根本原因是控件实际上没有执行安全团队认为它执行的功能。不幸的是，安全控制的功能和安全团队的期望之间的不匹配非常普遍。一些控制措施旨在缓解特定环境下非常特定的威胁。但是这种细微差别可能会在供应商的营销材料和销售活动中丢失。这是架构师在许多网络安全团队中扮演的一个关键角色:真正理解每种控制所减轻的威胁，以及需要如何协调控制来保护、检测和响应组织面临的威胁。他们应该深思熟虑地执行我在第六章、策略实现中讨论的网络安全能力清单，并对这些清单进行修改，以最大限度地减少差距和投资不足的领域。但是，正如我在第六章中提到的，控制实现的成熟度是一个重要因素，控制生成的数据的消耗也是如此。这是架构师可以参与的事情，即清点和规划，但数据消费者、运营人员和 SOC 工程师等需要帮助完成这一画面。否则，控制功能和期望之间的不匹配会让网络安全团队焦头烂额。

缓解措施未能按预期执行的另一个常见原因是它们根本没有按照供应商所说的方式工作。我知道这对于少数人来说是一个令人震惊的发现，而对于安全团队来说，这是一个非常普遍的挑战。如果供应商遵守他们所有的承诺，那么就不会有全球性的网络安全挑战，也不会有价值数十亿美元的网络安全产业。这是拥有多层防御的一个原因，这样当一个控制失败时，其他控制可以帮助减轻威胁。这是一个 ciso 可以与其他 ciso 分享和学习的领域。特定供应商和特定产品的专业经验通常是最好的参考。

缓解措施未能保护、检测或响应的另一个常见原因是它们所依赖的可信计算基础已经被破坏。也就是说，攻击者通过损害他们赖以运行的硬件和/或软件来破坏缓解措施。例如，一旦许多攻击者使用一个或多个网络安全常见嫌疑人来危害系统，他们首先要做的事情之一就是禁用系统上运行的反恶意软件软件。一个不太明显的策略是将目录添加到反恶意软件引擎的例外列表中，这样攻击者的工具就不会被扫描或检测到。一旦攻击者或恶意软件开始危害系统，他们通常会破坏为保护系统和检测攻击者而部署的控制措施。因此，精通网络安全基础知识是部署高级网络安全能力的先决条件。不要费心部署昂贵的攻击者检测系统，该系统使用人工智能来执行行为分析，除非你也致力于管理该系统的网络安全基础。如果未打补丁的漏洞、安全错误配置以及脆弱、泄露或被盗的密码使攻击者能够访问他们运行的系统，攻击者将破坏这些高级网络安全功能。我在前面的章节中详细讨论了这一点，但我将在这里再次重申。如果网络安全基础得不到有效管理，任何网络安全策略，即使是入侵杀伤链框架这样的高分策略，都不会有效。

此外，牢记网络安全基础知识，有效管理网络安全产品本身也很重要。反恶意软件引擎和其他常见缓解措施在过去一直是可利用漏洞和安全错误配置的来源。它们也必须得到有效的管理，这样它们就不会增加而不是减少攻击面。

与失败的控制相关的另一个行动项目是解决失败的控制集成。例如，在攻击者的杀伤链中，直到相对较晚的时候才检测到入侵企图，因为尽管控制器在早期阶段成功地检测到了入侵企图，但该数据从未到达 SIEM。像本例这样的中断和降级的集成在大型复杂的 IT 环境中很常见，很难检测到。如果网络安全团队可以简单地依靠数据消费者来识别网络安全控制的数据报告中的异常，那将是理想的，但在许多情况下，缺少数据并不是异常。许多组织中的技术债务会使识别和补救不良集成变得非常困难。很多时候，这种集成是由供应商或专业服务组织执行的，他们对客户的 IT 环境了解有限。这就是 SOC 工程师的价值所在；他们可以帮助确保集成按预期工作，并随着时间的推移不断改进。

从失败中学习

除了识别差距和次优控制和集成，入侵重建还可以帮助 CISOs 和网络安全团队确认他们拥有正确的投资优先级。来自重建的数据可以帮助重新确定投资的优先级，以便首先解决最关键的领域。这些数据不仅可以帮助投资决策合理化，还可以帮助首席信息官证明他们的投资决策是正确的，尤其是在面对首席信息官和首席技术官的批评时，他们有着不同的观点和可能不同的议程。投资于破坏攻击者努力的领域，而不是 IT 依赖的新功能，可能不是 IT 领导层的普遍选择。但是用重建数据来为这样的决定辩护会让其他人更难反对。

除了识别未按预期工作的技术之外，重建还可以提供一个机会来改进表现低于预期的人员和流程。例如，在治理失误导致不良安全结果的情况下，这可能是有助于推动治理流程和相关培训的积极变化的良好数据。如果遵守内部标准或行业标准无助于保护、检测或响应攻击，那么重建可能是变革的动力。

允许组织中的人从失败中学习是很重要的。在花费时间和精力了解失败并从中恢复后，组织可以通过将失败的教训传播给组织中受益最大的人来增加这些投资的回报。例如，重建数据可以帮助为高管或整个组织的社会工程培训建立一个案例。

识别有帮助的供应商

供应商是组织的重要合作伙伴，因为他们通常提供客户所依赖的技术、服务、人员和流程。入侵重建数据有助于识别表现达到或超过预期的供应商。它还可以帮助识别未能按预期表现的供应商。这包括供应商如何自己参与入侵重建演习。重建工作有助于发现那些倾向于将产品和服务性能的失败归咎于客户的供应商，这很少有帮助。这一点，以及有关供应商产品和服务表现的数据，有助于为供应商产品许可证续订谈判提供信息。一旦安全团队尝到了供应商产品的真正性能，以及他们在入侵期间愿意提供多大帮助，他们可能愿意在未来为它们支付更少的费用，或者根本不愿意使用它们。如果您的组织还没有这样做，我建议您维护一个许可证续订和生命周期终止“展望列表”,向您显示与续订和产品生命周期终止相关的关键日期何时临近。

确保组织给予自己足够的提前通知，以便他们可以花费合理的时间来重新评估现在是否存在更好的缓解措施。在部署和运行供应商的产品后，组织可能拥有比最初采购时更多、更好的关于其当前供应商表现的数据，以便为产品评估提供信息。

奖励那些乐于助人的供应商，并考虑替换那些不理解其核心价值应该是客户服务的供应商。纵观我在第六章、策略实现中提到的所有厂商，除了我没有提到的所有厂商，也不乏竞争你组织业务的公司。不要满足于那些将失败归咎于你的组织的供应商。即使这是真的，他们应该帮助你克服这些挑战，而不是玩指责游戏。入侵重建练习是他们证明投资于您的成功的机会，而不是作为一个不感兴趣的第三方旁观，等待下一个许可证更新日期。如果他们一直试图帮助你的组织从他们的产品中获得更多的价值，但是你的组织没有接受，那么在做出轻率的决定之前，这应该被调和。替换那些一直在逆流而上帮助您的组织的优秀供应商对您没有任何帮助，可能会使您的网络安全计划倒退几个月，甚至几年。但是他们的产品要么像宣传的那样工作，并且他们愿意帮助你在合理的时间内让他们进入那种状态，要么他们应该被替换。否则，他们只是增加了攻击面，同时使用了可以在其他地方更好地保护、检测和响应威胁的资源。

重建数据可能是你真正衡量网络安全供应商表现的最佳数据。在许可证续签谈判中使用它来反驳营销废话和销售主管的承诺，即最新版本或下一个版本解决了您的所有挑战，包括他们无法提供基本水平的客户服务。有时，绝望的供应商意识到他们将失去业务，决定通过直接向其他高管或董事会申诉来“终结”CISO 和网络安全团队。对于背负着对他们没有帮助的产品的 CISOs 来说，这可能是次优的。

但是，当 CISO 一直在向高管和董事会通报入侵重建的结果，并向他们展示他们的一些供应商是如何帮助或不帮助他们时，他们很难给这些供应商更多的业务。如果高管们仍然决定将更多的业务授予那些表现不尽如人意的供应商，数据显示，他们已经决定代表整个组织接受风险。首席信息安全官一直在管理这种类型的风险。但是随着数据的持续增长，每个人都很难简单地接受现状。数据而非意见本身应该有助于组织对其投资的网络安全能力做出更好的决策。

通知内部评估

我将讨论的入侵重建结果的最后一个潜在行动项目领域是渗透测试和红/蓝/紫团队练习。许多组织投资于渗透测试和红/蓝/紫团队，以便他们能够以更加结构化和可控的方式模拟攻击。从入侵重建演习中获得的经验教训可以为渗透测试和红队/紫队演习提供参考。如果重建工作发现了攻击者在实现网络安全策略时可以利用的弱点或漏洞，则应进一步测试这些弱点或漏洞，直到它们得到充分解决。当专业渗透测试人员和 Red 团队获得入侵重建结果时，它可以帮助他们设计测试，确保这些弱点得到适当的缓解。理想情况下，渗透测试人员和红/蓝/紫团队在攻击者有机会之前发现实现缺陷。

章节总结

网络安全团队需要衡量各种不同的东西，包括遵守监管、行业和内部标准。但是，本章重点介绍了 CISOs 和网络安全团队如何衡量其网络安全策略实现的表现和功效，并以以攻击为中心的策略为例。

数据帮助 CISOs 管理他们的网络安全计划和投资，并帮助他们证明他们的网络安全计划是有效的，并在不断改进；它还有助于说明检测到问题后纠正措施的有效性。运行良好的漏洞管理程序不是可有可无的；利用来自 it 部门的数据是 CISOs 传达效率和进度的最简单方式之一。漏洞管理团队应该每天扫描其清单中的所有内容，查找漏洞和错误配置。这有助于最大限度地减少未缓解的漏洞和错误配置出现和被利用的时间。随着时间的推移，漏洞管理扫描数据会产生有价值的趋势数据。一些有价值的数据包括:

• 漏洞管理小组管理的资产数量与组织拥有和运营的资产总数之比。
• 按漏洞严重性划分的环境中未修补的漏洞数量。
• 按产品类型划分的漏洞有助于说明环境中风险最大的地方；环境中操作系统、web 浏览器和应用程序中未修补、严重、高和中等严重性漏洞的数量，以及未受管理系统的数量，有助于 CISOs 及其利益相关方了解其 IT 环境中的风险。

以攻击为中心的策略，如入侵杀伤链，使衡量性能和功效变得相对容易；为此，使用了入侵重建。入侵重建结果可以在许多不同方面帮助 CISOs，尤其是通过识别未能按预期执行的缓解措施。为了从入侵尝试中获取价值，必须对每个成功、部分成功和失败的入侵尝试进行分解和研究，以回答两个关键问题:

1. 在被检测到并最终被阻止之前，攻击者的入侵杀伤链进展到了什么程度？
2. 在被阻止之前，攻击者是如何击败或绕过网络安全团队为打破其入侵杀伤链而部署的所有缓解控制层的？

在本书的下一章，我们将探讨云如何为安全性和合规性提供一种现代方法，以及它如何进一步帮助组织实现网络安全策略。

参考

1. 工程师的命令(未注明)。从工程师的命令中检索:
2. CVE 细节(2019)。按“独特”漏洞总数排名前 50 的产品。从 www.cvedetails.com/top-50-prod… 检索到的详细信息:T3T5】
3. Eric M. Hutchins，Michael J. Cloppert，Rohan M. Amin，博士(未注明)。情报驱动的计算机网络防御，通过对手活动和入侵杀伤链分析提供信息。检索自洛克希德·马丁:T3【https://Lockheed Martin . com/content/dam/Lockheed-Martin/rms/documents/cyber/LM-White-Paper-Intel-Driven-defense . pdfT5】
4. 赫尔曼博士(2007 年)。安全和隐私指标完整指南:衡量法规遵从性、运营弹性和投资回报率。奥尔巴赫出版公司。
5. ISC2 (2020 年)。 CISSP 域名更新常见问题解答。检索自 ISC2 认证:www . is C2 . org/certificates/CISSP/Domain-Refresh-FAQ #
6. 新泽西州塔勒布(2007 年)。黑天鹅:极不可能事件的影响。企鹅图书。
7. 沃雷尔，c .(2018 年 4 月 3 日)。如何使用亚马逊 Alexa 获取亚马逊 GuardDuty 统计数据和调查结果。检索自 AWS 安全博客:AWS . Amazon . com/blogs/Security/how-to-use-Amazon-Alexa-to-get-Amazon-guard duty-statistics-and-findings/**

八、云——实现安全性和合规性的现代方法

云提供了一种现代化的安全性和合规性方法。本章将介绍一些概念，这些概念将有助于尚未完全接受云计算的 CISOs 以及安全和合规专业人员了解云计算的背景。

在本章中，我们将讨论以下主题:

• 应用程序接口的力量
• 自动化的优势有助于缓解网络安全常见的疑点
• 云中的网络安全策略
• 加密和密钥管理

让我们先来看看云与我们一直在内部进行的工作有何不同。

介绍

2006 年商业云计算的出现在一些组织中引发了大量关于云是否可信以及它是否与内部 it 环境一样安全的辩论。然而，对于许多组织来说，云代表的不仅仅是新技术。简单来说，云代表着变化。让我们面对现实吧，对于一些组织来说，变革很容易，比如初创公司，而对于大型、成熟和高度监管的组织来说，变革可能更困难，比如金融服务机构或公共部门中的一些垂直行业。

通常，这些组织中的 CISO 是变革的反对者，在 ciso 对变革有一定控制权的 it 环境中，他们的运作方式就好像理想的结果是与攻击者僵持不下。只要没什么变化，他们就能保持这种相对成功的状态，继续提高。然而，当然，事物是不断变化的；只是我们这些忙碌的人需要时间才能注意到。跟不上技术进步步伐的企业会落后于竞争对手，并成为试图扰乱其行业的初创公司的牺牲品——狼总是在门口。然而，CISOs 希望在获得成功后维持现状，这无可厚非。然而，不花时间假装自己是首席技术官的首席信息官们会给他们的组织带来伤害，因为他们拖了太多的后腿，阻碍了创新。

这并不意味着 CISOs 可以或者应该提倡采用每一种即将出现的新技术。然而，经过十多年的争论，结论是明确的-云是安全和合规专业人士的游戏规则改变者。本章将概述云如何成为伟大的网络安全人才放大器，帮助组织执行其当前的网络安全策略，甚至采用更现代的方法来实现安全性和合规性。让我们先快速介绍一下云计算。

云计算有什么不同？

在 IBM、甲骨文、阿里巴巴等云服务提供商(CSP)中，全球最受欢迎的三大 CSP 是亚马逊网络服务 ( AWS )、微软和谷歌。这些 CSP 通常被称为超大规模 CSP，因为它们的云产品遍布全球。

当组织第一次考虑利用 CSP 提供的服务时，他们中的一些人首先想探讨的话题是安全性和法规遵从性。他们需要了解通信服务提供商如何提供所需的 IT 能力，同时满足或超过行业安全标准、监管标准和他们自己的内部安全标准。我听过很多关于云计算的神话，我也看到云帮助组织实现了他们在自己的内部 IT 环境中不可能实现的事情。在这一章中，我将分享一些我所了解到的关于云的事情，但请注意，这一章以及本书的其余部分所写的所有观点和意见都是我自己的个人观点，而不是我过去或现在的任何雇主的观点。我们开始吧。

尽管云计算正在被世界各地的行业所采用，但这种情况并不均衡，在世界上的一些地区更为缓慢。随着云计算开始受到企业的青睐，服务模型描述使得教育人们云是什么和不是什么变得很容易。三种云计算服务模式成为的热门，包括基础设施即服务(IaaS)平台即服务 ( PaaS )和软件即服务 ( SaaS )。这些服务模型描述使每个人都更容易理解可用的云服务类型以及它们在每个组织的 it 组合中的位置。例如，组织可以在 CSP 的 IaaS 产品中运行自己的虚拟服务器，如亚马逊弹性计算云 ( 亚马逊 EC2 )、微软 Azure 虚拟机或谷歌计算引擎。

通信服务提供商基于他们在世界各地建立的大规模物理 IT 基础设施提供服务。随着时间的推移，电信运营商大致围绕的物理基础设施模型是基于 AWS 开创的模型；区域和可用性区域的概念。按照 AWS 的说法，可用性区域是一个数据中心集群，区域是一个可用性区域集群。在电信运营商基础设施的规模和范围以及他们如何利用该模型的组件方面，存在有意义的差异。您可以在每个电信运营商的网站上了解他们的基础设施:

• AWS:T3】https://aws.amazon.com/about-aws/global-infrastructure/T5】
• 谷歌:T3】https://cloud.google.com/compute/docs/regions-zones/T5】
• 微软:T3】https://azure . Microsoft . com/en-us/global-infra structure/regions/

尽管 IaaS、PaaS 和 SaaS 这些术语今天仍被广泛使用，但它们正慢慢变得过时。当它们第一次被创造出来时，CSP 只有少量的服务，这些服务模型有助于描述每个服务是如何部署的。然而，这种情况正在迅速改变。在撰写本文时，上述三家超大规模通信服务提供商提供了数百种云服务。随后，像容器即服务 ( CaaS )、身份即服务 ( IDaaS )和功能即服务 ( FaaS )这样的新的缩写出现了。这种服务的激增一直在加速，因为新服务的开发者可以使用现有的服务作为构建模块。例如，如果一个电信运营商正在开发一项新的云服务，并且他们需要存储，而不是从头开始构建一个新的存储基础架构，他们可以简单地使用一个满足其要求的现有云存储服务。这种方法不仅有助于加速新云服务的开发，还意味着服务可以包含 IaaS、PaaS 和/或 SaaS 组件，模糊了这些旧服务模型描述之间的界限。换句话说，特定问题的解决方案变得比维护服务模型定义更加重要。随着云服务的持续增长，企业将能够为他们想要解决的特定问题购买解决方案，旧的服务模式将变得越来越不重要。

谈到服务模式，一个重要的区别是超大规模 CSP 提供的服务与传统的托管服务提供商(MSP)提供的服务之间的差异。几十年来，世界各地的许多组织都在利用 MSP。例如，政府倾向于与 MSP 签订长期协议来管理他们的数据中心并为他们提供 IT 服务。至少出于几个原因，MSP 在这样的组织中扮演了重要的角色。首先，MSP 成功地保持了大量的 IT 人才，否则企业很难吸引和留住他们。第二，MSP 变得非常熟悉他们客户的 IT 环境，因为他们管理这些环境；这种部落知识提供了企业所需的连续性，以便在关键员工离职时最大限度地减少潜在的中断。当然，MSP 也为他们的客户提供其他好处。

越来越多的组织希望从资本支出模式转移到 OPEX 模式，在这种模式下，他们不必预先进行大量投资，并希望他们的容量和利用率估计是正确的；只为他们使用的特定资源付费更有效率。MSP 和 CSP 可以帮助他们的客户实现这一转变。然而，MSP 往往有一个基于外包的业务模型，其中 CSP 提供一个用于转型的自助服务模型，而不是复制现有流程。

第一次考虑使用云的企业容易犯的一个错误是，认为 CSP 只是 MSP 的另一种形式。他们不是。超大规模通信服务提供商提供了一种极具可扩展性和灵活性的自助服务 IT 模式，其客户只需为他们使用的服务付费，以计算秒和他们存储或通过网络传输的数据量来衡量。任何持有信用卡的人都可以开立一个账户，并访问数百项服务，而在内部部署或 MSP IT 环境中构建这些服务的成本极其高昂。当客户使用完电信服务提供商的服务后，他们通常可以不带任何义务地离开。

相反，MSP 代表他们的客户管理数据中心和系统。由于物理构建数据中心和在其中运行的系统需要前期投资，MSP 模型通常需要长期合同来确保 MSP 可以从其投资中获得适当的回报。这种模式使中小企业及其客户处于不利地位。电信运营商将费用分摊给全球数百万客户，而移动运营商需要服务的客户数量要少得多，他们必须自己支付所有费用。一些 MSP 为他们的客户构建了自己的私有云，试图模仿云计算的弹性和其他特征。然而，根据我的经验，术语私有云是对有限规模、有限服务和缓慢变化的委婉说法。在某些情况下，私有云只是一个外包的数据中心。将这些与超大规模通信服务提供商提供的一系列服务进行比较，并不是真正的点对点比较。随后，许多 MSP 发展了他们的产品和服务，在 CSP 的服务之上运行。这很有意义，因为它们也可以从超大规模 CSP 提供的经济规模中受益。

他们通过大幅降低资本支出、获得几乎无限的产品规模，以及让自己能够以难以置信的速度创新来实现这一目标，而这可能是他们自己无法实现的。对于 MSP 来说，为客户设计、构建和管理系统是一个巨大的机会。但是，他们可以将更多精力放在创新上，而不是关注 IT 基础架构管理。他们还可以为客户提供更好的安全性。在本章中，我将讨论云可以提供更好的安全性和合规性的一些方法。

未能理解 CSP 和 MSP 之间的区别会让组织在评估云的安全性和合规性时慢下来。许多组织花费大量时间试图了解如果他们选择利用云，他们将如何维持现状。然而，正如我前面提到的，云代表变化；当组织第一次考虑使用云时，协调这两件事是他们面临的首要问题之一。这种调和可以以几种不同的方式表现出来。让我给你举几个例子。

正如我前面提到的，作为一个群体，超大规模通信服务提供商为他们的客户提供数百种服务。尽管如此，许多企业仍然选择将应用程序提升并转移到云中。这通常意味着他们将一直在本地 IT 环境中的服务器上运行的应用程序放到云中托管的服务器上运行。这种向云的过渡使他们能够维持他们多年来一直使用的人员、流程和技术，同时从资本支出转向 OPEX。对于许多组织来说，这是完全自然的，因为他们拥有在内部 IT 环境中构建和管理这些系统的深厚专业知识，并且当他们将这些相同的系统迁移到云中时，他们可以继续利用这些专业知识。在云中，他们可以利用他们一直在内部使用的相同或相似的硬件和软件。随后，这种类型的转换可以相对容易和快速。

提升和转移应用程序的挑战在于，复杂性、低效率和技术债务也会随着应用程序转移到云中。尽管如此，对于一些组织来说，这种类型的过渡可能是未来更大更好的事情的起点。

通常，一旦组织开始使用云，开发一些专业知识并探索其更广泛的功能，他们在未来会更广泛地使用它。他们不是提升和转移更多的应用程序，而是重新平台化应用程序，重新购买应用程序，或者使用云原生功能重构应用程序。随着时间的推移，他们不再像管理内部 IT 那样管理云，真正的创新开始蓬勃发展。然而，对于一些组织来说，这种转变和发展需要时间。

为了加快速度，一些组织决定采取大胆的大动作。他们决定将任务关键型应用程序迁移到云中，而不是将遗留应用程序提升和迁移到云中。他们的逻辑是，因为应用程序对业务至关重要，所以第一次就能做好，他们在这个过程中学到的东西可以应用于所有其他不太重要的应用程序，这些应用程序会跟随 it 走向云；这种方法将加速他们的数字化转型，并帮助他们有可能超越他们的弱小竞争对手。

一些 CISOs 努力应对云所代表的变化，并试图维持现状。这是因为他们已经在其组织的当前 IT 环境中成功地管理了他们的网络安全计划。对于一些组织来说，变更可能会带来风险。我最常看到的例子是企业安全团队用来确定新解决方案是否满足其安全标准和要求的安全评估。此类评估旨在确定在通过新解决方案处理、存储和传输组织的数据时，是否有一套最低限度的控制措施来保护这些数据。例如，一个评估问题可以确定新解决方案是否使用最新版本的传输层安全 ( TLS )协议来保护传输中的数据。另一个评估问题可以确定解决方案中的静态数据是否使用特定算法加密。另一个评估问题可能是供应商是否有特定的第三方安全证明或认证，例如 ISO 27001。

在一些组织中，当新的基于云的解决方案提交给安全团队进行安全评估时，他们会应用他们一直用于评估其内部 IT 环境中的新解决方案的相同评估流程。这似乎是合理的；毕竟，评估检查解决方案是否符合组织的安全标准。

这些年来，我看到的一些安全评估问卷非常详细，包括数百个问题。这些调查问卷中有许多是经过多年开发的，并且已经过定制，以反映使用它们的组织的特定 IT 环境和法规遵从性要求。

然而，这种评估问卷中的许多问题是基于一些关键的基本假设；例如，假设评估员将物理访问硬件以回答他们的问题。另一个类似的例子是，评估者将评估组织自己管理的系统。我看到的另一个流行的假设是，一个解决方案所使用的技术永远不会偏离当前商业上可用的技术。例如，解决方案的虚拟化工作负载所运行的虚拟机管理程序，其运行方式与在本地 IT 环境中运行的虚拟机管理程序完全相同。最后一个例子是假设提供解决方案的供应商只有一个解决方案，而没有一个庞大的技术套件或堆栈，可以通过不同的方式组合来解决问题。当这些假设和其他假设中的任何一个不成立时，基于它们的评估就不能完全完成。当这种情况发生时，一些安全团队简单地拒绝一个解决方案，因为他们无法使用他们的可靠的安全评估问卷来确定它是否符合他们的标准。然而，他们评估过程中的明显缺陷是，它不检查解决方案是否符合组织的安全标准，它检查他们的问卷中的问题是否可以按书面形式回答；这是一个微妙但重要的区别。

让我用一个夸张的比喻来说明我的意思。在过去的几十年里，车主可以将他们的汽车带到专业管理的车库进行多点检查。在某些情况下，这些检查是法律规定的，例如排放检查。然而，当第一辆全电动汽车的车主带着他们的汽车进行法律强制排放检查时，他们发生了什么？车库能够处理法律要求的评估吗？那辆车有没有排气管或者催化转换器让修车厂测试？毕竟每辆车都必须有这些技术吧？

鉴于汽车修理厂不能像他们几十年来测试汽车一样测试这辆车，他们应该不认证这辆车吗，尽管它超过了汽车排放标准，而这是传统内燃机无法达到的？一些安全团队拒绝基于云的解决方案，因为他们无法像以前那样评估解决方案。

很少有安全团队会自发地质疑他们多年来的评估流程所基于的假设。他们的安全需求不一定要改变。但是，他们需要发展和更新他们的评估流程，以确定新技术是否能够满足或超过这些要求。安全评估的目标是确保新的解决方案满足组织的安全要求，而不是确保他们的安全评估问题永远不会改变。企业需要偶尔质疑他们的假设，以检查它们是否仍然准确和相关。

让我们直接开始吧！接下来，我将分享为什么我认为云是安全和法规遵从性专业人员的游戏规则改变者。

安全性和合规性改变游戏规则

云可以通过多种方式让游戏场向有利于防御者的方向倾斜。在这一部分，我将介绍两个安全性和法规遵从性游戏规则改变者。

API 的力量

应用程序接口(API)为系统与人类和其他系统的交互提供了的强大机制。有不同种类的 API，但一般来说，API 定义了系统愿意接受的特定输入和它将提供的输出。系统如何处理输入和提供输出的细节可以从视图中抽象出来，从而为想要使用它的人和其他系统简化了系统。换句话说，我不需要为了使用它而知道系统内部是如何工作的。我只需要知道它的 API。我可以调用一个 API，向它传递它需要的信息，然后等待输出，这时软件的魔力就出现了。

魔术在这里是对所有聪明的工程师和开发人员在硬件、固件、操作系统和软件上的工作的委婉说法，这些硬件、固件、操作系统和软件构成了 API 及其系统所依赖的技术堆栈。

API 可以是特定于编程语言的，因此包含在软件开发包(SDK中。这使得了解 C++、Java 或其他流行编程语言的开发人员能够轻松利用 API。虽然 API 曾经主要由开发人员用来帮助他们开发应用程序，但是操作角色现在也利用 API 来部署和操作 IT 基础架构，从而有助于预示 DevOps 时代的到来。

在云计算环境中，可以从应用程序内部、命令行或 CSP 提供的 web 控制台调用 API。让我给你举几个例子。

假设我们想在 Amazon EC2 中调配和启动五台虚拟机，该虚拟机位于伦敦地区目前可用的三个区域之一。我们可以使用 RunInstances API (AWS，2020):

https://ec2.amazonaws.com/?Action=RunInstances
&ImageId=i-030322d35173f3725
&InstanceType=t2.micro
&MaxCount=5
&MinCount=1
&KeyName=my-key-pair
&Placement.AvailabilityZone=eu-west-2a
&AUTHPARAMS 

如果我们使用 AWS 控制台做同样的事情，启动实例向导将收集虚拟机的所有配置信息，并代表我们进行相同类型的 API 调用。我们还可以使用 AWS 命令行界面 ( CLI )来启动这些虚拟机，指定相同的参数，CLI 将为我们发出相同类型的 API 调用:

aws ec2 run-instances --image-id i-030322d35173f3725 --count 5 --instance-type t2.micro --key-name my-key-pair --placement "AvailabilityZone= eu-west-2a" 

在运行这个 AWS CLI 命令的系统的掩护下，它将使用 TCP 端口 443 (AWS，2020)上的 HTTPS 协议向 Amazon EC2 发送这种类型的请求。

需要记住的一件重要事情是，API 调用需要认证、授权、完整性和机密性机制。这里就不细说了。

当然，和 AWS 一样，Google Cloud 和微软 Azure 也有类似的 API，并支持一系列编程和脚本语言，以及命令行界面。这是来自 Google 的命令行界面 SDK 的一个例子，首先创建一个虚拟机，然后启动它(Google，n.d .):

gcloud compute instances create example-instance --image-family=rhel-8 --image-project=rhel-cloud --zone=us-central1-a
gcloud compute instances start example-instance --zone=us-central1-a 

这里可以看到一个类似的例子，关于在微软 Azure 中使用表述性状态转移(REST)API 创建虚拟机(微软公司，2020)。一旦创建了虚拟机，另一个 API 调用将启动它。这也可以使用 Azure CLI、Azure PowerShell 和 Azure Portal 来完成:

{
  "location": "westus",
  "properties": {
    "hardwareProfile": {
      "vmSize": "Standard_D1_v2"
    },
    "storageProfile": {
      "osDisk": {
        "name": "myVMosdisk",
        "image": {
          "uri": "http://{existing-storage-account-name}.blob.core.windows.net/{existing-container-name}/{existing-generalized-os-image-blob-name}.vhd"
        },
        "osType": "Windows",
        "createOption": "FromImage",
        "caching": "ReadWrite",
        "vhd": {
          "uri": "http://{existing-storage-account-name}.blob.core.windows.net/{existing-container-name}/myDisk.vhd"
        }
      }
    },
    "osProfile": {
      "adminUsername": "{your-username}",
      "computerName": "myVM",
      "adminPassword": "{your-password}"
    },
    "networkProfile": {
      "networkInterfaces": [
        {
          "id": "/subscriptions/{subscription-id}/resourceGroups/myResourceGroup/providers/Microsoft.Network/networkInterfaces/{existing-nic-name}",
          "properties": {
            "primary": true
          }
        }
      ]
    }
  }
} 

如您所见，使用 API 使这些服务的用户能够部署基础设施，如服务器、防火墙、网络负载平衡器和第三方设备。但是，它也允许我们按照我们希望的方式配置基础架构。例如，在部署服务器时，我们可以指定操作系统、IP 地址、网络安全配置、路由表等等，这是非常强大的。只需一条命令，我们就可以启动一台或十万台虚拟机，所有虚拟机都按照我们希望的方式进行配置。因为我们确切地知道我们的系统应该如何配置，所以我们可以将生产中运行的系统的当前配置与我们的标准配置进行比较，并确定是否有任何差异。我们可以不断地这样做，以便发现可能是妥协迹象的变化。

在内部 IT 环境中，这通常涉及在服务器上部署代理或管理软件来监控配置更改。

许多组织面临的一个挑战是部署和管理来自不同供应商的多个代理和管理套件。每个代理都需要某种程度的管理和安全更新，以确保它不会增加攻击面。通常，首席信息官和首席信息官会想方设法减少系统上运行的代理数量，抵制在其环境中部署更多代理的想法。与此同时，系统配置更改的来源可能包括各种各样的东西—管理员、管理软件、用户、恶意软件、从备份中恢复等等。这使得检测更改和确定系统更改是否是危害的标志变得非常困难。

在云中，由于一切都是通过 API 发生的，API 为可见性和控制提供了完美的瓶颈。如果组织能够监控他们的 API 调用，并根据发生的情况采取行动，他们将拥有更好的可见性和控制力。在这种环境中，将代理和管理软件部署到数百或数千个系统是可选的，因为 API 是嵌入到云中的。如果组织有规定特定控制配置的法规遵从性要求，他们可以监控这些控制以确保它们始终合规。

实际上，出于这个目的，API 调用被记录到 API 日志服务中。例如，AWS CloudTrail 是一个 API 日志服务，它在 AWS 帐户中记录 API 调用(AWS，2020)。早些时候，当我们在 AWS EC2 中运行启动五个虚拟机的命令时，如果启用了 AWS CloudTrail，它就会记录一个事件来捕获该 API 调用的详细信息。该事件包含大量的详细信息，包括使用了哪个帐户、发出调用的主体、一些身份验证和授权详细信息、时间、区域、调用来自的源 IP 地址、虚拟机的详细信息以及关于其配置的一些详细信息。这些日志可以与其他日志记录数据相结合，由人工和数据分析系统进行汇总和分析，导入云中的 SIEMS 和/或下载到内部 IT 环境中的系统。这些日志对于事件响应调查也是必不可少的。谷歌提供云审计日志(Google，2020)，而微软提供 Azure Monitor(微软公司，2019 年 10 月 7 日)，此外还有其他日志记录机制，目的类似。

以下是 AWS CloudTrail 记录的一个事件的截断示例:

{
    "eventVersion": "1.05",
    "userIdentity": {
        "type": "AssumedRole",
        "principalId": "Example:user123",
        "arn": "arn:aws:sts::Example:assumed-role/Admin/user123",
        "accountId": "Example-ID",
        "accessKeyId": "Example-access-key",
        "sessionContext": {
            "sessionIssuer": {
                "type": "Role",
                "principalId": "Example-principle",
                "arn": "arn:aws:iam::Example:role/Admin",
                "accountId": "Example-ID",
                "userName": "Admin"
            },
            "webIdFederationData": {},
            "attributes": {
                "mfaAuthenticated": "false",
                "creationDate": "2020-04-01T05:09:15Z"
            }
        }
    },
    "eventTime": "2020-04-01T05:09:26Z",
    "eventSource": "ec2.amazonaws.com",
    "eventName": "RunInstances",
    "awsRegion": "eu-west-2",
    "sourceIPAddress": "169.254.35.31",
    "userAgent": "aws-cli/1.3.23 Python/2.7.6 Linux/2.6.18-164.el5 ",
    "requestParameters": {
        "instancesSet": {
            "items": [
                {
                    "imageId": " i-030322d35173f3725",
                    "minCount": 1,
                    "maxCount": 5,
                    "keyName": "my-key-pair"
                }
            ]
        },
        "instanceType": "t2.micro" 

概括地说，与云的每一次交互都是通过 API 调用进行的。这种模式有许多好处，包括安全性和合规性好处。因此，云提供的可见性和控制优于大多数内部 IT 环境，更不用说这种方法的简单性和成本优势了。此外，它还支持新的 it 和安全运营方法。例如，我们知道我们部署的每个系统都配置为符合我们的安全性和合规性标准，因为这是我们用来部署它们的代码中的定义。由于存储和网络与计算服务分离，没有什么可以阻止我们每隔几小时就简单地关闭系统并部署新系统来替换它们。正如我们前面看到的，只需要脚本或应用程序中的几行代码就可以做到这一点。如果系统的寿命很短，管理员和管理软件就更难随着时间的推移引入安全错误配置，攻击者可以利用这些配置在环境中获得立足之地。

API 是强大的，但是它们也必须被正确地实现，这样它们才不会产生漏洞百出的攻击面。当然，通信服务提供商知道这一点，并在他们的 API 开发中使用专业知识、流程和技术来最小化风险。认证和授权机制、保护、监控、检测、响应和审计功能层；APIs 摇滚！

我在这里讨论了一个场景，即使用 API 来配置和启动虚拟机。现在，想象一下，如果你可以使用 API 来控制数百个执行各种功能的云服务，如计算、存储、网络、数据库、容器、无服务器计算、人工智能、机器学习、物联网和安全，仅举几例。想象一下，在世界上的任何地方，以几乎任何规模对所有这些进行编程控制，这真的很神奇。这就是 API 的力量！对于安全和法规遵从性专业人员来说，它们确实是游戏规则的改变者。API 的威力不仅适用于拥有大量 IT 预算的大型组织；任何有信用卡的人都可以用 CSP 开一个账户，并获得这些 API 的能力。接下来，让我们看看另一个改变游戏规则的因素，自动化。

自动化的优势

正如我们已经看到的，API 的力量使我们能够使用代码配置和控制云中的大多数东西，甚至是基础设施。为了充分利用 API 的能力，云提供了高度的自动化。除了运行 CLI 命令，您还可以使用脚本、模板、应用程序和云服务来自动化复杂的工作流。

CSP 提供丰富的自动化功能。这些功能分布在不同的云服务上，就像它们利用的 API 一样。一些有助于实现某些功能自动化的服务示例包括微软 Azure Automation(微软公司，2018 年 10 月 18 日)、谷歌云编辑器(谷歌，2020 年)和 AWS CloudFormation (AWS，2020 年)。还有第三方提供的自动化解决方案，如 Chef (Chef，2020)、Puppet (Puppet，2020)、Ansible (Ansible，2020)、Terraform (Hashicorp，2020)等。

对于安全和合规专业人员来说，所有这些自动化功能和工具都有助于供应、配置、管理、监控、重新配置和取消供应基础架构和其他云服务。此外，这些丰富的自动化功能有助于保护、检测、响应和恢复，同时符合监管标准、行业标准和内部安全标准。在许多情况下，所有这些都可以近乎实时地发生，因为是自动化而不是人类在执行这些操作。

事实上，减少这些操作中的人工参与有很多好处。回想一下我在第一章、成功的网络安全策略中详细讨论的网络安全常见疑点；让我们看一些自动化如何帮助我们减轻这些问题的例子。让我们先来看看内部威胁和社会工程。

减轻内部威胁和社会工程

请记住我之前定义的两种类型的内部威胁:恶意的内部人员滥用他们对资源的特权访问，以及非恶意的内部人员犯错误导致糟糕的安全结果。自动化有助于缓解这两种类型的威胁。例如，我们开发、测试和实现的自动化程度越高，管理员犯下具有安全后果的错误的机会就越少。

使用自动化来完成可重复的流程可以带来更一致、更快速的结果，更不容易出现人为错误。

自动化管理流程还会减少恶意内部人员采取行动的机会。这就是即时管理和刚好够用管理的概念可以发挥作用的地方。随着高度自动化的实现，管理员对系统的访问要求将会降低，从而减少了他们窃取数据或破坏基础架构的机会。高度自动化的环境也使得检测管理员何时访问系统变得更加容易，因为这种情况是规则的例外。当恶意内部人员知道当他们直接访问数据和系统时，他们的可见性和审查会增加，他们在没有合法理由的情况下尝试访问资源的频率就会降低。

自动化有助于最大限度地减少管理员的访问权限。例如，不允许管理员完全访问他们所连接的系统，而只允许他们在这些系统上运行预先测试和批准的脚本和自动化将减少他们运行任意命令的机会。有了足够的自动化，管理员只有在现有自动化无法解决问题的“破碎玻璃”场景下才有理由运行任意命令。可以对这些案例进行监控和审计，以减少恶意内部人员采取行动的机会。在这种情况下，对两个或更多参与者采用基于法定人数的管理程序也有助于减轻内部威胁。随着时间的推移，增加更多的自动化来覆盖更多的支持场景，可以大大减少管理员运行任意命令的机会。

使用自动化还有隐私方面的好处。如果人类无法访问敏感数据，那么他们就无法接触到个人身份信息 ( PII )或受保护的健康信息 ( PHI )，或者敏感的财务信息。使用自动化来代替人工与数据交互，有助于组织实现他们对客户或公民的隐私承诺。

听起来很棒，对吧？也许好得不像真的？难道我们不能通过使用堡垒主机和安全外壳(SSH)会话在内部 IT 环境中实现这一点吗？很棒的问题。让我们看一个真实世界的例子。

本例中安全团队的要求是管理员不能直接访问他们管理的系统。这意味着使用 SSH 直接访问系统不能满足需求。如果他们确实使用 SSH 来访问这些系统，那么他们可能能够在这些系统上运行任意命令，这是他们想要避免的。

在这个场景中，安全团队还希望限制堡垒主机在其环境中的使用。过去他们已经被堡垒主机烧毁了。堡垒主机通常跨越较高安全区域和较低安全区域，允许管理员从较低安全区域访问较高安全区域中的系统；随后，需要将堡垒主机作为更高安全性区域的一部分进行管理。事实证明，这可能比听起来更难，这个虚构组织的流程失误导致了其环境中的系统受损。经历过一次失败后，他们希望最大限度地减少环境中堡垒主机的数量。

例如，使用 AWS 满足这些需求的一种方法是使用 AWS 系统管理器服务在 Amazon EC2 服务中运行的虚拟机上运行命令。为此，将在这些虚拟机上安装 Systems Manager 代理。正确配置该代理后，管理员可以从 AWS Systems Manager 控制台运行经过测试和批准的脚本，这些脚本将通过 Systems Manager 代理(AWS，2020)在这些虚拟机上执行。

这种方法有几个很酷的优点。首先，管理员不需要拥有他们所管理的虚拟机的管理员凭据。因为他们正在云中运行 AWS Systems Manager 服务的脚本，所以他们不需要本地凭证来访问单个系统。如果管理员不知道这些系统的用户名和密码，他们就无法直接登录这些系统。他们仅限于从云中运行经过测试和批准的脚本。这有助于降低这些系统面临内部威胁的风险。

这种方法也减轻了与这些系统上的社会工程相关的一些风险。管理员不会因为不了解这些系统而被诱骗放弃这些系统的凭据。由于管理员与这些系统交互的唯一方式是在这些系统上远程运行预先批准的脚本，因此他们不会被诱骗运行任意命令或安装新软件，这可能会破坏这些系统的安全性并导致不良的安全后果。当然，考虑到社会工程是多么阴险，这种方法必须与其他一些缓解措施结合起来才能完全缓解它；比如针对 AWS 账号本身的多因素认证 ( MFA )。然而，我希望您能够看到这种方法在减轻针对管理员的典型社会工程攻击方面的潜在优势。当管理员只在需要时访问，并且访问受到严格的范围和控制时，典型的社会工程策略成功的机会就更少了。

请记住，使用云的一大优势是可伸缩性。如果我们使用自动化在部署的每台虚拟机上安装 Systems Manager 代理，我们将能够根据需要在任意多的系统上使用这种管理方法——规模实际上是无限的。使用自动化，我们可以使用相同的技术和工作量管理三个或三千个系统。随着我们管理的系统数量的增加或减少，管理员不需要额外的工作，因为他们运行相同的脚本，而不管他们管理的系统数量；管理更多的系统并不意味着管理员有更多的访问权限。

如果我们在 AWS CloudTrail 中记录由管理员与 AWS Systems Manager 服务的交互所生成的 API 调用，那么他们的活动可以被近乎实时地监控和审计(AWS，2020)。我们还可以监控和审核管理员与虚拟机本身的任何交互，以确保管理员仅在发生中断事件时访问这些系统。

当然，其他 CSP 也有丰富的自动化功能。例如，微软提供了一系列服务和功能来帮助，包括 Azure Automation、Azure PowerShell、Azure Monitor 等。谷歌还提供几项服务，包括云监控、云功能和云资产清单等。

自动化允许我们设计不经常需要直接人机交互的系统。这使得更容易检测这些事件何时发生，并更好地缓解内部威胁和社会工程。接下来，让我们看看在这种情况下，如何缓解网络安全的另一个常见问题，即未打补丁的漏洞。

缓解未打补丁的漏洞

让我们看看如何使用自动化来帮助管理我们使用的虚拟机上的漏洞。正如我们在第二章、利用漏洞趋势降低风险和成本中所看到的，漏洞管理团队每天都要面对多达 45 个新的漏洞披露，这些漏洞可能会影响他们的系统。云中的自动化有助于减少与清点系统、扫描系统和修补系统相关的工作量。

例如，回想一下我在第二章中写的，准确的清单对漏洞管理团队至关重要。在云中，因为不使用 API 就不会供应或取消供应，所以 API 和自动化有助于快速提供准确的清单。像这样清点环境不需要几个小时或几天，几乎可以瞬间完成。

有许多方法可以用来扫描和修补云中的虚拟机。在我们的 AWS 示例中，AWS 系统管理器可用于修补系统。此外，您的组织在内部 IT 环境中用于漏洞管理软件的供应商也有可能拥有为云构建的类似功能。这使您的组织能够利用其在内部 it 环境中管理漏洞所积累的专业知识，并继续在云中利用它。

您可能想知道，当系统的数量可以完全动态地扩展和缩减以满足负载和应用程序可用性目标时，漏洞管理流程对运行在云中的虚拟机有什么潜在影响。在这种情况下，例如，Amazon EC2 Auto Scaling 可以用来实现这一点(AWS，2016)。它还可以帮助系统保持最新。可以使用自动扩展来大幅减少这一工作，而不是扫描和修补一大群系统中的每个系统。为此，扫描用于构建虚拟机的 Amazon 机器映像以查找漏洞，并根据需要安装安全更新以确保映像是最新的，测试以确保它按预期工作。然后，关闭基于该映像旧版本的生产环境中运行的虚拟机。根据您为自动扩展设置的负载和可用性规则，当自动扩展决定启动新的虚拟机时，它会使用您刚刚修补和测试的映像来执行此操作。当新的虚拟机启动时，它是完全修补的。您可以使用自动化来有意识地关闭正在运行的虚拟机，这些虚拟机基于旧映像，自动扩展将重新启动新的、完全修补的虚拟机来替换它们。无需扫描，无需打补丁，减轻了重启带来的痛苦。对于大型企业来说，这是一种更简单的方式来做一些长期以来的棘手问题。

谷歌和微软也提供工具来有效地发现和减少漏洞。例如，谷歌提供操作系统库存管理、操作系统补丁管理(目前处于测试阶段)和云安全扫描器，而微软提供 Azure Automation 和 Azure Security Center 等工具。有许多第三方供应商为云环境提供漏洞管理解决方案，包括 Qualys、Tenable、IBM QRadar 等。

当然，这只是执行修补的一种方法——还有其他方法。通过使用 CSP 为您管理的服务，还有可能完全消除修补。正如我在本章前面提到的，IaaS 只是云中的一种服务；电信运营商提供了数百种服务，完全不需要您配置、管理和修补服务器。如果你不需要自己管理服务器，又何苦呢？

让 CSP 为您管理基础设施，您可以将通常用于此类任务的时间用于减少其他领域的技术债务、似乎永远无法完成的项目工作或创新——想象一下。想象一下，花时间弄清楚如何使用无服务器计算、AI、ML 和 IoT 来更好地保护、检测和应对威胁，而不是测试补丁和重启服务器。

云肯定有助于减少未打补丁的漏洞，并使这比在大多数内部环境中容易得多；困扰企业几十年的事情。现在，让我们看看云中的自动化如何帮助减轻另一个常见的网络安全嫌疑，即安全错误配置。

减少安全错误配置

正如我在第一章、成功网络安全策略的要素中所写的那样，安全错误配置可能是硬件、操作系统和应用程序中糟糕的默认设置，也可能随着时间的推移而发生，因为系统根据管理员或软件更新引入的调整“偏离”了其组织的标准。此外，在大型 IT 环境中，废弃的技术可能会很快成为被遗忘的风险，得不到积极的管理。由于大型企业一直在努力保持事物按照他们需要的方式配置，变更管理成为一门成熟的 IT 学科，受到整个行业供应商的支持。这一点很重要，不仅是出于安全目的，也是出于合规目的。确保系统符合监管标准、行业标准和内部 IT 标准非常重要，在许多情况下也是必需的。

在我们的示例场景中，组织可以选择在他们部署在云中的服务器上安装管理软件。他们可以像在本地 IT 环境中一样，继续测量和修复配置更改。

他们还可以利用 API 的强大功能和内置于云中的自动化功能。例如，AWS Config 是一个云服务，它监视资源的配置更改，并使您能够基于这些更改采取一系列的操作。

在我们的示例场景中，安全团队可能决定应该自动修复一种类型的变更；当检测到更改时，自动化会将配置更改回其标准设置。或者，为了安全起见，可以使用自动化来关闭配置错误的系统，如果启用了自动扩展，将启动一个符合组织所有标准的新系统来替换它。

安全团队可能会认为另一种类型的变更是需要由他们的事件响应团队进行调查的妥协迹象。在这种情况下，自动化可以拍摄虚拟机的快照，创建一个新的虚拟私有云(VPC)—姑且称之为 IR 洁净室—将快照复制到隔离的 IR 洁净室，将 IR 团队的取证软件连接到映像，向 IR 团队发送消息对其进行调查，并关闭原始虚拟机。如果进行了配置，自动扩展将启动一个符合所有批准标准的全新虚拟机来取代它的位置。这一切几乎都是实时完成的。请注意，在这些示例中，虚拟机上没有管理软件或代理，也没有 SOC 分析师执行手动查询来寻找危害迹象。由于基础设施是代码，我们可以自动化任意数量的操作来满足组织的需求。

在法规遵从性环境中，该功能非常强大，因为它可以帮助保持配置符合标准。当我们使用自动化来检测变更并采取适当的行动时，我们也可以使用该自动化来生成法规遵循工件，这将帮助组织证明对适用于它们的特定标准的持续遵循。这有助于减少错误配置系统的手动审核和手动补救。

微软 Azure Automation 和谷歌云资产清单为各自的服务提供了类似的功能。也有第三方提供自动化解决方案，如 Ansible、Chef、Terraform 等。

接下来，让我们看看云中的自动化如何帮助缓解网络安全的最后一个常见问题:脆弱、泄露和被盗的密码。

减少弱密码、泄露密码和被盗密码

通信服务提供商和众多第三方供应商为云和混合环境提供身份和访问管理解决方案。例如，微软通过 Azure Active Directory 特权身份管理 ( PIM )(微软公司，2020 年)提供 Azure Active Directory 和支持服务，如即时特权访问能力。第三方，如 Aporeto、Centrify、CyberArk 和许多其他公司也提供服务，可以在不同的情况下帮助一些人。Google Cloud 提供云身份和访问管理，AWS 提供 AWS 身份和访问管理。

通信服务提供商提供 MFA，正如我在第一章、成功网络安全策略的要素中所讨论的，这是一种非常有效的控制，可以在很大程度上减少脆弱、泄露和被盗的密码。利用 MFA 并限制用户在两次身份认证请求之间访问资源的时间，可以使攻击者更难成功使用窃取和泄露的凭据。使用秘密管理器来管理访问密钥、证书和凭证以便定期自动改变和轮换它们也是有效的。为此，谷歌提供了谷歌云秘密管理器(Google，2020)，微软提供了 Azure Key Vault(微软公司，2020)，AWS 提供了 AWS 秘密管理器(AWS，2020)。同样，有许多第三方供应商也提供解决方案，包括 Docker Secrets、SecretHub、知己等。

事实上，在身份和访问服务和解决方案中有如此多的能力和功能，整本书都致力于这一主题领域。身份是安全的关键。我强烈建议花些时间了解 CSP 和其他供应商提供的强大的身份和访问功能。

安全性和法规遵从性游戏规则改变者—摘要

API 的强大功能和云中的自动化是安全和法规遵从性专业人员的两大改变因素。这并不是说本地 IT 环境中没有 API 和自动化。然而，投资和努力使这些功能等同于那些嵌入到云中的功能将会非常昂贵，并且难以实现；考虑到任何持有信用卡的人，只要花几分钟时间在 CSP 开户，就可以默认获得这些功能，因此很难证明实现内部版本是合理的。

我们现在已经看到，云可以提供一些有效和创新的方法来解决所有网络安全的常见问题。换句话说，云使解决网络安全基础问题比在内部 IT 环境中减轻它们更容易。我们在这里仅仅触及了皮毛，因为我在本节中使用的示例场景是一个 IaaS 示例。正如我提到的，通信服务提供商提供数百种服务，涵盖并融合了 IaaS、PaaS、SaaS、FaaS、IDaaS 等。更不用说，我没有深入研究这些电信运营商提供的任何安全服务。整本书都致力于云安全这一主题。

现在让我们看看云如何支持我们在第五章、网络安全策略中研究的网络安全策略。

在云中使用网络安全策略

在第五章、网络安全策略中，我们考察了过去二十年中我所见过的在行业中采用的几种网络安全策略。我们使用网络安全基础评分系统 ( CFSS )评估了这些策略。每个策略的 CFSS 分数估计值有助于我们了解它们在解决网络安全基础问题方面的表现。为了提醒您，在表 8.1 中提供了每个策略的 CFSS 得分汇总:

表 8.1: CFSS 评分评估汇总

几乎所有这些策略都可以在云中使用。现在让我们来看看在云环境中的一些策略。

在云中使用保护和恢复策略

通信服务提供商提供精细的防火墙和网络控制，可以帮助组织采用和实现保护和恢复策略。API 和云中自动化的强大功能使网络团队和安全团队能够供应和操作 Web 应用程序防火墙，以及位于云资产边缘的网络防火墙，并构建和操作 dmz。除了网络 ACL、路由表、子网规则、基于主机的防火墙等之外，它们还提供虚拟私有云或虚拟网络，为网络流量增加了另一层控制。通信服务提供商通常提供令人眼花缭乱的网络控制。

由于所有这些控制都可以通过代码和自动化来供应和监控，因此在云中执行这种策略比在内部执行要容易得多。在云中，不需要订购和接收硬件，不需要在数据中心进行机架安装和堆叠，也不需要更多机架空间、电力或冷却。你只需要运行代码，CSP 会做所有其他的事情。如果你需要扩大或缩小你的基础设施，只需要更多的代码和自动化。您只需为您所使用的内容付费，并且可以在您的组织决定关闭时随时关闭它。正如我们在第五章、网络安全策略中所讨论的，保护和恢复策略是一种糟糕的评分策略。它可以与其他策略结合使用，以更全面地解决网络安全的基本问题。在云中扩展这种策略也更容易，因为一切都是代码。现在让我们来看看更好的得分策略。

合规性是云中的一种网络安全策略

让我们看看第五章、网络安全策略中的另一个策略，合规作为一种网络安全策略。在本章的前面，我们看到了云中的 API 和自动化如何帮助减少安全错误配置。这些相同的功能可以帮助组织持续遵守安全标准，无论是监管标准、行业标准还是内部标准。我已经讨论了 API 和自动化如何确保系统得到正确配置，并持续监控配置变化。然而，在执行这一策略时，需要注意一个重要的细微差别。

许多第一次考虑使用云的安全团队和合规团队想知道他们如何证明他们符合标准，也就是说，当他们不拥有运行基础架构的数据中心，并且随后无法让他们的审计员访问这些设施时。不管谁拥有数据中心，许多组织仍然必须向他们的审计员和监管者证明他们符合要求的标准。

在大多数情况下，这是利用超大规模 CSP 的另一个优势。AWS、谷歌和微软的云服务都有大量的认证和证明。例如，ISO27001 是当今所有 CSP 的竞争对手，他们都必须获得该认证，以满足其企业客户的要求。有两种认证对许多 CISOs 来说是最有价值的。

首先是美国协会 CPAs 的系统和组织控制 ( SOC )，特别是 SOC2 Type II 认证(AICPA，2020)。至少有几个因素使这一认证对 CISOs、安全团队和合规团队很有价值。首先，SOC2 Type II 中审计的控制范围通常回答了企业关于安全性的大多数问题。第二，这不是控制设置或架构设计的“时间点”快照；追求 SOC2 Type II 的组织需要 6 个月的持续审计才能实现。组织为准备这种类型的审计而采取的步骤可以极大地改善他们的安全状况。然后，要获得这种认证并长期保持下去，并不断证明服务是按照描述的方式运行的，这可能是一个巨大的挑战。许多企业甚至从未试图获得这一认证，因为这很难做到，而且可能很昂贵。然而，超大规模通信服务提供商在其许多服务中获得并保持这一认证，以保持其安全标准在行业中处于最高水平。

电信运营商通常会与客户分享 SOC2 Type II 审计报告。对于安全团队和合规团队来说，值得下载这些报告并进行审查，以确保他们评估的解决方案符合或超过他们的标准。SOC2 Type II 审计报告中没有回答的问题可以直接提交给 CSP，他们通常很乐意回答。

许多 CISOs 和安全团队认为很有价值的另一个证明是云计算合规控制目录 ( C5 )，由德国联邦政府办公室联邦信息安全办公室 ( BSI )设计(BSI，2020)。C5 是深度安全保证认证。它有许多领域的标准，包括策略、人员、物理安全、身份和访问管理、加密等。同样，这种证明的范围和复杂性可能会使其难以实现和维护。与 SOC2 Type II 一样，对于 CISOs 来说，该证明包含了他们对 CSP 安全控制集的许多疑问的答案。

SOC2 Type II 和 C5 就像是 CISOs、安全团队、合规团队和审计员的安全信息宝库。通信服务提供商通常将这些与许多其他认证和证明结合起来，以帮助他们的客户证明他们符合合规性要求。然而，通信服务提供商的客户也在其中扮演着重要角色。请记住，电信服务提供商不同于托管服务提供商(MSP)。电信运营商提供自助服务云。他们的客户和 ISV 可以基于这些云构建解决方案。但是，CSP 的“认证”和“证明”范围并不包括由客户设计和操作的解决方案部分；与 MSP 不同，CSP 通常没有这样做所需的可见性或访问权限。

这种安排意味着通信服务提供商和他们的客户都要对他们设计和运营的解决方案的各自部分负责。谷歌、微软和 AWS 都将这种安排称为共同责任。通信服务提供商和他们的客户都提供适当的认证和证明，以证明他们各自的解决方案部分满足他们必须遵守的标准的要求。这种安排通常可以为通信服务提供商的客户节省时间和金钱。这是因为在几乎所有情况下，他们必须证明的解决方案部分可以显著减少。例如，由于通信服务提供商的客户并不拥有运行其基础设施的数据中心，他们实际上已经将审核和认证这些数据中心的责任委托给了他们的通信服务提供商。换句话说，他们不再需要处理物理数据中心的复杂性和成本，因为通信服务提供商为他们做了这些。这对通信服务提供商的客户来说是一个胜利，因为他们可以达到或超过他们负责的安全标准，同时减少他们的工作量和成本。

关于 CSP 运作的合规项目的信息可以在他们各自的网站上找到，但是审计报告本身通常是为 CSP 的客户保留的；以下是包含 AWS、Google 和 Microsoft 合规计划信息的位置:

• AWS:T3】https://aws.amazon.com/compliance/programs/T5】
• 睁眼:cloud.google.com/security/co…](cloud.google.com/security/co…)
• 微软:T3】https://docs . Microsoft . com/en-us/Microsoft-365/compliance/offering-home？view = o365-全球

API、自动化和 CSP 提供的认证和证明的结合可以帮助希望将合规性作为网络安全策略的组织。对于希望扩展这一策略以全面解决网络安全基础问题的组织来说，云通常比内部 IT 环境更容易做到这一点。这是因为我们已经讨论过的 API 和自动化功能。一切都是代码。让我们再来看一个我们在第五章、网络安全策略中研究过的策略，以及如何在云中实现它。

在云中使用以攻击为中心的策略

在我们研究的所有策略中，得分最高的是以攻击为中心的策略。在第六章、策略实现中，我们深入探讨了这个策略，并举例说明了它的一种实现方式。在第七章、衡量表现和有效性中，我们研究了一种衡量该策略有效性的方法。然而，这种策略能在云中实现吗？

这个问题的简短答案是，是的，它可以在云中实现。在某些情况下，想要在云环境中实现这一策略的组织已经完成了一些工作。例如，MITRE 提供了“战术和技术[原文如此],代表了涵盖基于云技术的企业的 MITRE ATT 和 CK 矩阵。该矩阵包含以下平台的信息:AWS、GCP、Azure、Azure AD、Office 365、SaaS。”(MITRE，2019 年 10 月 9 日)。

我在第六章、策略实现中提到，米特 ATT & CK 框架可以补充我们深入研究过的入侵杀伤链模型(Eric M. Hutchins、Michael J. Cloppert、Rohan M. Amin 博士)。杀伤链方法也可以在云中实现。要做到这一点，您可能需要像我们在第六章中所做的那样，为您在云中实现的解决方案制定一个行动方案矩阵(Eric M. Hutchins、Michael J. Cloppert、Rohan M. Amin 博士)。换句话说，由于这可能是一项耗时的工作，正如您所看到的，您不需要为 CSP 提供的每个云服务构建一个行动方案矩阵，只需为您计划使用的云服务构建即可。

在某些方面，为针对 IaaS 环境开发的解决方案执行此操作类似于为内部 IT 环境执行此映射。这是因为许多硬件和软件可能是相同或相似的。例如，为运行在 Linux 或 Windows 上的解决方案确定的操作系统缓解措施将非常相似，无论该操作系统是运行在云中还是内部。然而，正如我们之前所讨论的，除了这些操作系统缓解措施之外，云原生控件和第三方解决方案也可以分层部署到环境中，以实现一组使攻击者更难得逞的控件。例如，帮助我们检测配置更改的相同服务将帮助我们近乎实时地检测云中的危害迹象。我们讨论的相同身份和访问能力将使攻击者更难使用窃取的凭据横向移动。我们谈到的帮助系统保持最新的技术将使攻击者更难找到和利用未打补丁的漏洞。

请注意，尽管 Kill Chain 方法非常适合构建在 IaaS 环境中的解决方案，但这种方法对于使用更高级别的云服务(如托管服务)构建的解决方案帮助不大。在这些情况下，CSP 负责保护底层 IT 环境，通常将底层 IT 基础架构的较少直接访问和较少直接控制留给组织的安全团队。这并不意味着安全团队没有他们需要的可见性和控制力，正如我们已经讨论过的，这恰恰相反。但是，缓解控制的类型可能会不同于为内部或 IaaS 环境开发的传统解决方案。

控制应该是不同的，因为某些威胁和风险肯定是不同的。随后，Kill Chain 可能不是云中组织的最佳评分方法，这取决于他们使用的服务类型。随着企业消费越来越多模糊 IaaS、PaaS、SaaS、FaaS、IDaaS 和其他模型之间界限的服务，杀伤链方法变得越来越不相关。

这不是一件坏事——这只是需要接受更多的改变。请记住，CISOs 和安全团队的角色不是确保现状，而是保护他们组织的数据，即使这些组织决定是时候发展他们使用的技术和流程，以保持竞争力和/或相关性。云不仅提供了技术和流程现代化的机会，也提供了可以采用的网络安全策略现代化的机会。让我们进一步探讨这个概念，看看我在第五章、网络安全策略中提到的一种更现代的网络安全方法，称为 DevOps 。

devo PS——实现云中安全性的现代方法

由于没有更好的名字，我们姑且称这种方法为 DevOps 。与我们研究过的其他网络安全策略相比，这种策略代表了一种更现代的方法。它认识到开发和 It 操作规程已经联合起来，部分原因是这些角色被恰当地定位为利用 API 和自动化的力量。因为一切都是云中的代码，包括基础设施，了解开发和 IT 基础设施运营的团队可以充分利用云所提供的一切。让我们看看开发运维驱动的安全策略如何帮助安全团队在基于云的环境中保护、检测和响应现代威胁。

回想一下第三章、中的，威胁格局的演变——恶意软件*，在那里我描述了为什么 Windows 生态系统比苹果 iOS 生态系统有更多的恶意软件。看起来，关键在于软件在这些生态系统中的传统分布方式。微软允许用户将任何人开发的软件轻松安装在他们基于 Windows 的系统上。*

另一方面，苹果为所有面向 iOS 设备的应用程序提供了单一来源，即他们的应用商店。虽然 Windows 用户可以自行决定他们想要运行的软件的可信度，但苹果公司规定了一个安全标准，所有独立软件开发商必须达到该标准，他们的应用程序才能分发到基于 iOS 的设备上。这种软件分发方式的差异，至少部分解释了为什么苹果 iOS 生态系统一直保持着如此低的恶意软件流行率。

让我们吸取这一教训，并将其应用到我们的云安全方法中。利用持续测试、持续集成 ( CI )和持续交付或持续部署 ( CD )可以帮助最大限度地减少有问题的软件进入电信运营商客户构建和运营的基于云的环境。在他们的 CI/CD 管道中，他们可以实现自动(和手动)安全和合规性检查。这确保了通过这些管道部署到生产环境中的任何软件或基础设施满足其组织的安全性和法规遵从性要求。

要做到这一点， CI/CD 管道的每一步都将自动进行适当的安全性和合规性检查。例如，一个 DevOps 团队可以开发或获得寻找 OWASP Top 10 (OWASP，2020)中包含的问题的自动化。另一个常见的例子是执行静态代码分析和/或一组特定的功能安全测试的需求。基础设施必须满足每个组织的合规团队定义的控制设置要求，并且这将在项目通过管道时得到验证。

实现这样的测试通常是在代码和自动化中完成的，所以可以进行的检查的数量和类型几乎是无限的。当然，因为这可能是有效和有趣的，一旦一些 DevOps 团队开始开发这些检查，他们将花费更多的时间在 CI/CD 管道的开发上，而不是在应用程序和基础设施上。

如果某个应用程序或基础结构项目没有通过这些检查中的一项，管道将会停止，相应的人员将会收到警报，该项目将不会继续进行，也不会按计划引入到生产环境中。必须解决应用程序或基础设施项目中的缺陷，以便通过失败的检查，然后再次检查整个管道。

这样，只有通过所有安全和合规性检查的产品才能进入生产。这意味着安全和法规遵从性团队可以对引入其生产环境的所有内容都满足其所有安全和法规遵从性要求，并且不会给该环境带来更多风险充满信心。要做到这一点，一切都必须通过 CI/CD 管道。换句话说，将应用程序或基础设施项目投入生产的唯一方法是通过 CI/CD 管道。为了获得最大的成功机会，组织需要有规程以及治理机制来强制执行这个需求。管理多个 CI/CD 管道是一种可预测的常见结果，尤其是对于大型分布式组织。一些组织面临的风险是，CI/CD 管道的数量激增，开始危及最初管道所要求的高安全性和合规性标准；太多的管道可能会变成一个治理问题。

另外，请注意，一些攻击者已经发现越来越多的组织正在使用 DevOps 和 CI/CD 管道。这使得 CI/CD 管道本身成为攻击者的潜在目标。了解您的组织用于管道的技术和自动化堆栈，并采取措施保护它们是非常重要的。对于一些组织来说，CI/CD 渠道可以成为高价值资产，值得特别关注，正如我在第一章、中讨论的成功网络安全策略的要素。

现在，安全和法规遵从性团队对他们的部署充满信心，他们如何长期保持这些环境的原始状态呢？他们可以使用我们在本章前面讨论的服务和自动化来监控配置更改。当配置发生变化时，他们可以使用自动化使其恢复合规性，或者对其变化的方式和原因进行更深入的调查。

正如我们前面所讨论的，云中的漏洞管理有一系列选项。继续使用您的组织在其内部环境中已经使用多年的技术和流程可能是一个可行的选择。

然而，使用自动化，比如我前面提供的自动伸缩示例，有可能简化和加速漏洞管理。另一种选择是组织从管理服务器和应用程序本身发展到使用更高层次的云服务，并将基础架构修补留给电信运营商。

以攻击为中心的策略在行业中如此受欢迎的原因之一是它们可以使“高级”威胁参与者难以成功——所谓的高级持续威胁 ( APT )。然而，这正是 API 的强大功能和高度自动化可以发挥作用的地方。例如，当组织每隔几个小时关闭运行在云中的服务器子集，并用满足所有要求的新服务器替换它们时，攻击者就更难在该环境中获得并保持立足点。短命的、相对不可变的系统留给攻击者的氧气非常少，不像那些运行数月或数年的系统。

云中的检测功能优于大多数内部环境中的检测功能。请记住，云中 API 和自动化的力量提供了很少内部环境能够实现的可见性和控制。云可以使记录 API 调用、网络流量、认证和授权操作、加密/解密密钥操作等变得容易。然而，无论是否使用云，大多数安全团队都面临一个挑战，即所有这些日志中的大量数据使得人类几乎不可能及时查看和使用这些数据。这也是云可以提供帮助的地方。AI 和 ML 服务可以用来代替安全团队成员审查所有这些日志和 API 活动，并确定真正值得他们注意的事情。这是可能的，因为 AI/ML 服务可以根据需要扩展到足够大，以比人类更快的速度处理大量日志数据集。当他们这样做时，这些服务在自动化的帮助下，可以检测和响应各种攻击，包括 DDoS、恶意软件、漏洞利用、内部威胁等等。

最后，如果所有这些功能都无法保护、检测和响应攻击者，DevOps 和云可以使恢复生产环境比在典型的内部环境中容易得多。因为一切都是代码，所以如果进行一些规划和周密的准备，在云中重建环境会相对容易。然而，业务连续性规划是另一本书的主题。

再说一次，我觉得我们甚至还没有触及表面。然而，我希望您有足够的信息来思考 DevOps 策略是否能帮助您的组织。从传统策略过渡到开发运维需要时间，在此期间，一些组织寻求开发运维与传统策略的巧妙结合。

本节关于云中的网络安全策略到此结束。然而，在我们结束本章和本书之前，我想强调云提供的另一组重要功能:加密和密钥管理。

加密和密钥管理

你可能想知道为什么我把这个话题留到了本书的最后一节。根据我的经验，大多数关于云中安全性的讨论都以加密和密钥管理结束。无论对话以什么话题开始，如漏洞、利用、恶意软件或基于互联网的威胁，他们都会以讨论加密和密钥管理而结束。这是因为加密是一种强大的数据保护控制，有助于提供数据的机密性和完整性。

无论组织追求哪种网络安全策略或策略组合，当橡胶上路时，保护数据是目标。这就是我们所研究的网络安全策略令人分心的地方，这些策略是数据保护的代理。安全团队过于关注保护终端或应用程序，以至于忽略了根本目标是保护数据。我提到的代理很重要，必须有效管理，但是不要忘记数据！

通信服务提供商都知道这一点，并为他们的客户提供丰富的加密和密钥管理功能。他们的目标是保护传输中的数据和静态数据。TLS(1.2 版)是保护传输中数据的事实上的互联网标准。随后，通信服务提供商支持 TLS，此外还提供其他机制来保护传输中的数据，例如 VPN 连接或直接连接到他们的云基础架构。

通信服务提供商通常提供一系列加密选项来保护静态数据，使其客户能够在将数据放入云中之前(在某些情况下)和/或之后对数据进行加密。CSP 为静态数据加密提供的当前加密标准是高级加密 标准 ( AES )，通常使用 128 位或 256 位密钥长度。

如果攻击者能够访问受 AES256 保护的数据(访问通常经过身份验证和授权),使用暴力破解技术和大量传统计算能力破解这种类型的加密可能会花费比数据的生命周期长得多的时间。

安全团队需要理解的一个重要的细微差别是，到底加密了什么，加密降低了哪些风险。例如，如果底层存储介质被加密，但是正在写入介质的数据在被写入之前没有被加密，则被减轻的风险是存储介质的丢失或被盗。加密存储介质有助于减轻攻击者物理访问存储介质的攻击。如果有人获得了加密存储介质的物理访问权，但没有安装和解密它的密钥，则写入其上的数据将受到保护，不会被未经授权的访问。但是，如果攻击者试图以逻辑方式而非物理方式访问数据，例如通过网络，那么存储级加密可能无法降低这种风险，因为数据在从网络访问时会被解密。

了解需要减轻的特定风险以及针对该特定风险的特定减轻措施非常重要，这样才能确信风险已经真正减轻。如果希望防止通过网络对静态数据进行未经授权的访问，那么加密数据本身(而不仅仅是存储介质)将是一种更有效的缓解措施。这听起来似乎是显而易见的，但这是安全团队在应用程序安全评估过程中经常犯的错误。

除了提供数据加密选项，通信服务提供商还真正提供经过认证和授权的数据加密。即每个加密操作 API 调用都是经过认证的，必须经过授权；在没有首先被认证和授权的情况下，加密和解密操作不会发生。以这种方式使用身份和访问服务为安全团队提供了很大的灵活性。例如，一个人或一组人可以被授权加密数据，但无权解密数据。另一个组可以被授予解密数据的权限，但不能同时进行加密和解密操作。经过身份验证和授权的加密实现了职责分离，这在许多情况下很有帮助。

对于许多组织来说，加密最具挑战性的部分之一可能是密钥管理。风险很高，因为如果组织的钥匙损坏、丢失或被盗，可能会对他们造成灾难性的影响。一般来说，通信服务提供商希望让他们的客户能够轻松安全地管理密钥。谷歌提供云密钥管理服务(Google，2020)，微软提供 Azure Key Vault(微软公司，2020)，AWS 提供 AWS 密钥管理服务(AWS，2020)。当然，也有第三方供应商提供加密和密钥管理服务，如 Thales、金雅拓、Equinix 等。

电信运营商的关键管理服务可以提供一个有趣的优势，因为它们可以集成到其他云服务中。这意味着一些云服务可以代表用户执行加密和解密。这里的数据保护优势是，数据可以通过 AES 加密来保护，直到它位于运行将要处理它的服务的服务器的物理内存中。一旦处理完成，服务可以再次重新加密数据，然后将数据移动到存储或其他服务进行进一步处理。用于加密和解密的密钥可以在密钥管理服务和使用它们的服务之间的传输中受到保护。这意味着未加密的数据只能在数据所有者授权的严格控制的环境中公开。这有助于最大限度地增加加密保护数据的位置和时间。CSP 的密钥管理服务倾向于为低延迟和高可用性而设计，以便潜在地处理数十亿个请求。

一些组织希望在他们用于计算和存储的供应商与提供关键管理服务的供应商之间划分职责。提供密钥管理服务的第三方供应商可以扮演这一角色，或者电信运营商的客户自己可以操作和维护他们自己的密钥管理基础设施。选择此选项的组织应该能够轻松管理他们自己的密钥管理基础架构，或者允许第三方为他们做这件事。然而，管理硬件安全模块 ( HSMs )和公钥基础设施(PKI)是出了名的困难。这使得使用 CSP 的密钥管理服务成为一种流行的选择。

对于需要在内部保存密钥但仍希望获得云优势的组织来说，客户端加密是一个潜在的解决方案。使用客户端加密意味着数据所有者在将数据放入云服务之前对其进行加密。例如，数据所有者拥有自己的内部密钥管理基础架构。在将数据放入云存储服务之前，他们会在本地生成一个密钥，然后使用一个也在本地运行的应用程序使用该密钥加密数据。然后，他们进行身份验证，并将加密的数据安全地传输到云存储服务。在这种情况下，他们的 CSP 无法访问未加密的数据或加密密钥，因为他们都没有离开自己的内部 IT 环境。要解密这些数据，数据所有者需要向云存储服务进行身份验证，安全地下载加密的数据，并使用他们的本地应用程序和本地密钥来解密数据。同样，无论是未加密的数据还是加密密钥都不会与 CSP 共享。

客户端加密并不局限于存储场景；它可以用于其他服务，例如数据库。在这种情况下，客户端加密用于在将记录或单个字段写入云中运行的数据库服务时对其进行加密。为此，从内部密钥管理系统中检索加密密钥，并由执行加密的应用程序临时用于加密操作。一旦记录在写入数据库时被加密，就可以从执行加密操作的应用程序的内存中删除加密密钥，从而减少密钥驻留在内部密钥管理系统之外的系统上的时间。对数据库记录执行加密和解密操作的应用程序可以在本地或云中运行。因为 CSP 的客户完全控制密钥，所以 CSP 不能访问密钥，除非客户授权他们访问。索引和数据库键保持不加密，以便仍然可以执行数据库的索引和搜索。因此，不要将敏感数据放入这些字段是很重要的。为了解密数据，在从内部密钥管理系统提供密钥之后，检索并解密适当的记录。在解密操作之后，可以再次从执行解密操作的应用程序的存储器中移除密钥。

有许多不同的方法来执行客户端加密和密钥管理。然而，与简单地使用 CSP 提供的集成加密和密钥管理服务相比，这种方法实现起来可能更加复杂和昂贵。随着时间的推移，一些开始使用客户端加密并将密钥保存在内部的组织得出结论，使用 CSP 的密钥管理服务可以降低他们最担心的风险，并简化他们的应用程序。毕竟，云中的加密和解密操作是使用 API 调用来执行的，这些 API 调用是使用自动化来进行身份验证、授权、监控和潜在控制的，正如我们前面所讨论的。

将正确实现的加密和有效的密钥管理与云中 API 和自动化的强大功能相结合，有助于以在内部 IT 环境中复制起来更加复杂的方式保护数据。加密和密钥管理有助于保护数据免受我们在本书中讨论的许多威胁；它们是强大的数据保护控件，应该成为您的组织所追求的任何网络安全策略的一部分。

结论

对于尚未采用云或者不喜欢其内部 IT 环境的组织，我想到了一句名言:

“未来已经到来——只是分布不均匀。”

——(吉布森，2003 年)

每个组织都有机会以前所未有的规模利用 API 和云自动化的力量。这些游戏规则改变者不仅使应用程序和 IT 基础架构的供应、配置、操作和取消供应变得更加容易，还为安全和合规专业人员提供了他们过去可能没有的可见性和控制力。我鼓励首席信息安全官和安全团队拥抱云，以此事半功倍，弥补行业长期的网络安全人才短缺。

章节摘要

本章介绍了云计算的一些安全性和合规性优势。我把我的讨论集中在世界上最受欢迎的通信服务提供商的基本能力上，也就是 Amazon Web Services、Google 和 Microsoft。

超大规模通信服务提供商大致围绕的物理基础设施模型基于区域和可用性区域的概念。这个概念是，可用性区域是一个数据中心集群，区域是一个可用性区域集群。在电信运营商基础设施的规模和范围以及他们如何利用该模型的组件方面，存在有意义的差异。尽管 IaaS、PaaS 和 SaaS 这些术语今天仍被广泛使用，但它们正慢慢变得过时。解决特定问题的新服务会模糊 IaaS、PaaS 和 SaaS 服务模型之间的界限，使它们变得不那么重要。

电信运营商在一些关键方面不同于传统的托管服务提供商(MSP)。重要的是，当高管们第一次考虑使用云时，要认识到这一点，以避免会让他们慢下来的困惑。建立在通信服务提供商产品之上的 MSP 将继续为其客户和行业发挥重要作用。

在本章中，我讨论了云提供的两个安全性和法规遵从性规则改变者:

• 应用程序接口(API的威力
• 自动化的优势

通过管理控制台、命令行界面和应用程序与云进行的每一次交互都使用 API。API 为可见性和控制提供了完美的瓶颈。如果组织能够监控他们的 API 调用，并根据发生的情况采取行动，他们将拥有更好的可见性和控制力。为了充分利用 API 的能力，云提供了高度的自动化。除了运行 CLI 命令，您还可以使用脚本、模板、应用程序和云服务来自动化复杂的工作流。云中的自动化可以帮助解决网络安全基础问题，其方式可能比传统 IT 环境更有效。

云足够灵活，可以支持我们在第五章、网络安全策略中讨论的几乎所有网络安全策略。与我们研究的其他网络安全策略相比，DevOps 提供了一种更现代的方法。因为一切都是云中的代码，包括基础设施，了解开发和 IT 基础设施运营的团队可以充分利用云所提供的一切。持续集成(CI)、持续交付和持续部署(CD)管道可以在其中自动进行适当的安全性和合规性检查；比如 OWASP Top 10 (OWASP，2020)。

我希望你发现这本书有时兼具教育性和娱乐性。我坚信，如果我们能够对我们所关心的风险足够具体，并且对我们所采用的缓解措施和策略的有效性足够诚实，网络安全将会成为人们更加关注的焦点。

旅途愉快！

参考

1. AICPA。(2020 年 4 月)。 SOC 2 -服务机构 SOC:信任服务标准。检索自 AICPA:www . AICPA . org/interest areas/frc/assuranceadvisoryservices/aicpaso C2 report . html
2. 亚马逊网络服务。(2020 年 3 月)。采用 AWS 的云计算。从自动气象站检索到:【aws.amazon.com/what-is-aws…
3. Ansible。(2020 年 4 月)。红帽 Ansible 。检索自红帽 Ansible:【www.ansible.com/】
4. AWS。(2016 年 10 月 20 日)。通过自动扩展简化车队管理。检索自 AWS 计算博客:AWS . Amazon . com/blogs/Compute/fleet-management-made-easy-with-auto-scaling/
5. AWS。(2020 年 4 月)。亚马逊弹性计算云 API 参考。从 AWS 检索:T3】https://docs . AWS . Amazon . com/AWS C2/latest/API reference/API _ run instances . htmlT5】
6. AWS。(2020 年 4 月)。自动气象站云形成。从自动气象站检索到:【aws.amazon.com/cloudformat…
7. AWS。(2020 年 4 月)。 AWS CloudTrail 。从自动气象站检索到:【aws.amazon.com/cloudtrail/…
8. AWS。(2020 年 4 月)。 AWS 密钥管理服务(KMS) 。从自动气象站检索到:【aws.amazon.com/kms/】
9. AWS。(2020 年 4 月)。 AWS 秘密管理器。从自动气象站检索到:【aws.amazon.com/secrets-man…
10. AWS。(2020 年 4 月)。用 AWS CloudTrail 记录 AWS 系统管理器 API 调用。从 AWS 检索:docs . AWS . Amazon . com/systems-manager/latest/user guide/monitoring-cloud trail-logs . htmlT5】
11. AWS。(2020 年 4 月)。在 EC2 实例上远程运行命令。从 AWS 检索:AWS . Amazon . com/getting-started/hands-on/remote-run-commands-ec2-instance-systems-manager/
12. AWS。(2020 年 4 月)。使用 AWS CLI 。从 AWS 检索:T3】https://docs . AWS . Amazon . com/CLI/latest/user guide/CLI-chap-using . htmlT5】
13. 主厨。(2020 年 4 月)。厨师。从厨师处取回:T3【https://www.chef.io/products/chef-infra/】T5
14. Eric M. Hutchins，Michael J. Cloppert，Rohan M. Amin，博士(未注明)。情报驱动的计算机网络防御，通过对手活动和入侵杀伤链分析提供信息。检索自洛克希德·马丁:T3【https://Lockheed Martin . com/content/dam/Lockheed-Martin/rms/documents/cyber/LM-White-Paper-Intel-Driven-defense . pdfT5】
15. 西吉布森(2003 年 12 月 4 日)。年度图书。经济学家。
16. 谷歌。(2020 年 4 月)。云审计日志。从谷歌云检索:【cloud.google.com/logging/doc…](cloud.google.com/logging/doc…)
17. 谷歌。(2020 年 4 月)。云密钥管理服务。从谷歌云检索:【cloud.google.com/kms/】[T3T5】](cloud.google.com/kms/)
18. 谷歌。(2020 年 4 月)。云作曲。从谷歌云检索:【cloud.google.com/composer】[T…](cloud.google.com/composer)
19. 谷歌。(2020 年 4 月)。介绍谷歌云的秘密管理器。检索自谷歌云博客:Cloud . Google . com/Blog/products/identity-security/introducing-Google-clouds-secret-manager
20. 谷歌。(未注明日期)。g 云计算实例创建。从谷歌检索:T3】https://cloud . Google . com/SDK/g cloud/reference/compute/instances/createT5】
21. 哈希公司。(2020 年 4 月)。地形。哈希公司从 Terraform 取回:T3【https://www.terraform.io/】T5
22. 微软公司。(2018 年 10 月 18 日)。Azure 自动化简介。从微软 Azure 检索:T3】https://docs . Microsoft . com/en-us/Azure/automation/automation-introT5】
23. 微软公司。(2019 年 10 月 7 日)。 Azure Monitor 概述。从微软 Azure 检索:docs . Microsoft . com/en-us/Azure/Azure-monitor/overview
24. 微软公司。(2020 年 3 月)。天蓝色产品。从微软 Azure 检索到:【azure.microsoft.com/en-us/servi…](azure.microsoft.com/en-us/servi…)
25. 微软公司。(2020 年 4 月)。密钥库。从微软 Azure 检索到:【azure.microsoft.com/en-us/servi…](azure.microsoft.com/en-us/servi… )
26. 微软公司。(2020 年 4 月)。使用 Azure Key Vault 管理服务器应用中的机密。从微软学习检索:docs . Microsoft . com/en-us/Learn/modules/manage-secrets-with-azure-key-vault/
27. 微软公司。(2020 年 4 月)。虚拟机-启动。检索自微软公司:docs . Microsoft . com/en-us/rest/API/compute/virtual machines/start
28. 微软公司。(2020 年 4 月)。*什么是 Azure AD 特权身份管理？*从微软 Azure 检索:docs . Microsoft . com/en-us/Azure/active-directory/privileged-identity-management/PIM-configure
29. 米特雷。(2019 年 10 月 9 日)。云矩阵。从米特里取回 ATT&CK:T3】https://attack.mitre.org/matrices/enterprise/cloud/T5】
30. OWASP。(2020 年 4 月)。十大 Web 应用安全风险。从 OWASP 检索到:T3【https://owasp.org/www-project-top-ten/】T5】
31. 木偶。(2020 年 4 月)。傀儡企业。从傀儡中取回:T3【https://puppet.com/products/puppet-enterprise/】T5
32. 英国标准协会。(2020 年 4 月)。标准目录 C5 。从联邦信息安全办公室检索:www . BSI . bund . de/EN/Topics/cloud computing/Compliance _ Criteria _ catalog/Compliance _ Criteria _ catalog _ node . html