Illumio零信任六部曲：微分段有效性实战评估

作者  柯善学

人们普通认同微分段是一种阻止攻击者横向移动的零信任措施，但是一直无法度量微分段的功效和价值，也没有数字可以证明这一点。

由红队组织Bishop Fox撰写的首份微分段量化评估报告，解答了上述问题，量化了微分段的功效。它基于MITRE ATT＆CK框架，提出了一种测试方法论，可以帮助组织在自己的环境中验证测试结果。

Bishop Fox针对不同粒度、逐步收紧的分段策略，进行了几轮对比测试，以度量微分段有效限制横向移动的能力。主要发现包括：对于100个工作负载的环境，即使是采用最简单的分段策略（即环境隔离），攻击者横向移动并实现目标的难度也增至3倍；如果采用应用程序微分段策略，难度增至4.5倍；而当环境扩展到1000个工作负载时，攻击者的难度增至22倍。

所以，如果您真地想有效增加对手的攻击难度，请实施微分段。

目录

1. 项目背景

2. 执行摘要

3. 测试总结

4. 测试环境

5. 测试策略

1）对照测试

2）用例1-环境分离

3）用例2-应用程序隔离

4）用例3-基于层的分段

6. 测试方法论

7. 测试结果

1）对照测试

2）用例1-环境分离

3）用例2-应用程序隔离

4）用例3-基于层的分段

5）用例2–500个工作负载

6）用例2–1000个工作负载

8. 评估结论

01 项目背景

Illumio聘请Bishop Fox，度量使用Illumio微分段能力来限制横向移动的有效性。

以下报告详细说明了开始于2020年3月16日的聘用过程中发现的调查结果。

测试目标：

• 创建可复用的测试方法论，该方法可由第三方在其自身环境中测试使用；

• 记录每个用例测试中得到奖杯（trophy）所需的时间；

• 审查由于增加微分段措施而产生的可检测的网络流量水平；

• 确定微分段的总体有效性，因为它与可检测事件的生成和攻击者穿越网络所需的时间投资有关。

日期：

• 2020年3月16日：启动

• 2020年3月23日–2020年4月8日：主动测试

• 2020年5月12日：报告交付

02 执行摘要

攻击者在入侵过程中会花费大量时间在横向移动上，因为他们要在网络中试图找到他们想要的“战利品”。而对这种横向移动没有有效控制的网络，为攻击者提供了一条通往其目标的简易通道。

横向移动也是恶意软件尤其是勒索软件对整个组织产生如此严重影响的原因。所有高调的勒索软件攻击，都利用网络周围相同的横向移动自由度，以便以毁灭性的速度传播并使网络瘫痪。

零信任，特别是作为零信任安全框架中关键能力之一的微分段，正致力于阻碍这种横向移动的自由。微分段迫使攻击者（和恶意软件）更加努力和聪明地工作。在最好的情况下，微分段可以消除威胁。在最坏的情况下，所有增加的活动都会增加防御者发现的机会。

人们普遍认为，微分段控制阻碍了横向运动，但影响程度有多大？各种类型的微分段策略在阻止攻击者方面有多有效，它们是否迫使行为改变？这正是本次评估所要衡量的。

这次测试的结果，突出了在现实世界环境中实施微分段的重要性。总体而言，研究小组发现，随着在测试环境中启用更严格的微分段控制，获得敏感信息（即获得“皇冠宝石”）所需的时间可被量化地增加。这也表明，攻击者被迫花费更多时间来访问敏感信息，从而产生更多可检测的事件，从而为蓝队提供了更好的检测攻击的机会，从而带来了可观的好处。

03 测试总结

评估团队对Illumio创建的网络环境进行了一系列攻击模拟，以度量产品的微分段控制针对一系列攻击的有效性。

为了进行度量，评估团队在测试过程中记录了以下指标：

• 攻击者获得“皇冠宝石”的时间（称为完成时间）

• 网络上识别的主机/工作负载数量

• 网络上识别的服务数量

评估团队在Illumio控制的环境中进行攻击模拟，该环境具有以下特性：

• 所有工作负载都安装了Illumio-VEN代理，并与管理平台（策略计算引擎PCE）配对

• 前四次测试的工作负载的规模相同

• 使用更高的工作负载集重复两次测试，以确定对完成时间（Time to Completion）指标的影响

为了获得有意义的度量，定义了四个测试用例：

• 对照测试（Control Test）：

  表示没有分段的扁平网络。

• 用例1–环境隔离：

  生产（Production）工作负载只能与其他生产工作负载通信，开发（Development）工作负载只能与其他开发工作负载通信。

• 用例2–应用程序隔离：

  与同一应用程序相关和在同一环境中的工作负载可以相互通信–例如，订购（Ordering）应用程序/生产工作负载只能与其他订购应用程序/生产工作负载通信。

• 用例3–分层分段（Tiered Segmentation）：

  与在特定应用程序和环境中的特定层相关联的工作负载可以相互通信–例如，Web层/订购应用程序/生产工作负载只能与其他Web层/订购应用程序/生产工作负载通信。

对于攻击模拟，评估团队基于MITRE ATT&CK框架的主要组成部分，开发了一种方法，试图将其活动与真实场景中使用的文档化的战术、技术和程序（TTP）进行映射。该方法的详情见本报告的方法部分。

图1-基于测试用例的结果和推断

图2-基于用例2结果的预测

表3-100个工作负载环境的结果

评估团队观察到，与对照环境（扁平网络场景）相比，对于100个工作负载环境，攻击者分别需要300%（用例1）、450%（用例2）和950%（用例3）的时间来获得皇冠宝石。

该团队发现，尽管网络上发现的主机数量在不同的测试用例之间有所不同，但他们能够成功地枚举所有这些主机。然而，在对照环境测试和用例3之间，发现的服务数量线性减少了44%（从293个已识别的服务减少到130个）。

对于工作负载数量变化的测试，仅适用于第二个用例微分段策略。测试显示：500个工作负载（即对照环境测试的8.5倍）获得皇冠宝石的时间增加了189%，1000个工作负载环境（即对照环境测试的22倍）获得皇冠宝石的时间增加了489%。 也就是说，攻击者达成目标的时间随着工作负载数量的增加，大致呈现线性增长趋势（如图2所示）。

简言之，微分段策略越紧（从对照测试，到用例1，再到用例2，再到用例3），当对手试图横向移动时，对他们造成的困难就越大。此外，只要在整个企业中一致地应用微分段策略，即便微分段的级别（策略的粒度）保持不变，也有显著的可度量的好处。

04 测试环境

从本节开始，将介绍测试方法。这是业界首创的测试方法，它是从零开始开发的，目的是促进可复用性。本节描述了测试环境的属性和测试活动期间使用的策略。

注：Illumio在任何时候都没有向评估团队透露关于以下测试环境的任何信息（包括工作负载的数量和类型）。

1）测试环境的组件

团队进行攻击模拟的测试环境，由以下组件组成：

• 管理平台：

  Illumio策略计算引擎（PCE）部署为AWS中的单节点群集（SNC）

• 数据中心工作负载（测试靶场）：

  部署了Illumio VEN代理的Linux Centos AWS EC2实例

测试靶场包括：

• 一个面向公众的跳转主机（跳转服务器或堡垒主机），可从互联网直接访问

• 部署在私有子网上的应用程序工作负载

Illumio VEN代理安装在测试靶场内的所有工作负载上，并与管理平台配对。

测试靶场在每一轮测试后都被摧毁并完全重建。测试靶场内的所有主机都被分配了动态IP地址，这使得团队无法在测试用例之间重用主机信息。

2）工作负载按应用程序分组

为了模拟真实的网络，工作负载按应用程序分组。每个应用程序都有以下类型的工作负载：

• 开发：运行Apache、Tomcat和Postgres的单个工作负载；

• 生产：Web（Apache）、处理（Tomcat）、数据库（Postgres）层的独立工作负载；Apache在80/tcp和443/tcp上监听，Tomcat在8080/tcp上监听，Postgres在5432/tcp上监听；

• 应用程序跳转主机；

• 所有工作负载都允许在22/tcp或1357/tcp上使用SSH；

测试环境中并不包括由工作负载提供服务的实际应用程序，而只包含暴露在网络中的未配置服务。因此，假设在测试环境中进行渗透转移的方法是使用SSH，因为所有主机共享相同的凭据。这些凭据还允许使用命令在每个主机上进行访问。

3）攻击成功的战利品

“皇冠宝石”（攻击者针对的数据）是使用Postgres服务器在测试环境中存储的伪造个人识别信息（PII）来实现的。由于环境中没有部署真正的应用程序，Illumio团队将每个测试用例的说明存储在一个文件中，其中包含了指示奖杯是什么的线索。该文件的内容如下：

图4-为攻击者留下线索的文件内容

该文件模拟了包含凭据的配置文件，是攻击场景中的第一个检查点。一旦攻击者获得它，他们的目标就是找到托管crown_jewels（皇冠宝石）数据库的Postgres服务器并提取其数据。

05 测试策略

本节描述应用于测试环境的不同策略。对于每个策略，所有网络流（允许和阻止）都会被记录并转发到PCE（策略计算引擎），然后转发到Illumio基础设施上的SIEM服务器。

1）对照测试（CONTROL TEST）

对于对照测试，所有工作负载都在“构建模式（Build Mode）”下配置了Illumio-VEN代理。

这是一种非阻塞模式，iptables允许所有入口和出口连接。现有的策略是“Allow All”（允许所有）策略。

这个策略是用来模拟一个扁平网络中攻击者的活动，并作为一个对照起点，来比较所获得的指标与逐步收紧的微分段策略。

2）用例1-环境分离

在本用例中，所有工作负载的Illumio-VEN代理都配置为“强制模式”。这是一种阻塞模式，其中iptables被编程为只允许PCE中定义的策略明确允许的进出流量，所有其他连接都被阻止。

此用例的策略定义如下：

• 从internet到公共跳转主机的SSH访问

• 从公共跳转主机到单个应用程序跳转主机的SSH访问

• 所有生产工作负载都可以相互通信

• 所有开发工作负载都可以相互通信

• 单个应用程序跳转主机可以通过SSH连接到同一应用程序中的任何其他工作负载

• 所有其他流量都被拒绝

3）用例2-应用程序隔离

在此用例中，所有工作负载的Illumio VEN代理均配置为“强制模式”。这是一种阻塞模式，其中iptables被编程为仅允许PCE定义的策略明确允许的入口和出口流量，而所有其他连接都被阻塞。

• 从internet到公共跳转主机的SSH访问

• 从公共跳转主机到单个应用程序跳转主机的SSH访问

• 单个应用程序跳转主机可以通过SSH连接到同一应用程序中的任何其他工作负载

• 特定应用程序中的所有开发工作负载，都可以与同一应用程序中的所有其他开发工作负载进行无限制对话

• 特定应用程序中的所有生产工作负载，都可以与同一应用程序中的所有其他生产工作负载进行无限制对话

• 所有其他流量都被拒绝

4）用例3-基于层的分段

在本用例中，所有工作负载的Illumio-VEN代理都配置为“强制模式”。这是一种阻塞模式，其中iptables被编程为只允许PCE中定义的策略明确允许的进出流量，所有其他连接都被阻止。

• 从internet到公共跳转主机的SSH访问

• 从公共跳转主机到单个应用程序跳转主机的SSH访问

• 特定应用程序中特定层（Web、处理、数据库）中的所有生产工作负载，都可以无限制地与该应用程序的同一层中的所有其他生产工作负载通信

• 特定应用程序中特定层（Web、处理、数据库）中的所有开发工作负载，都可以无限制地与该应用程序的同一层中的所有其他开发工作负载通信

• 允许从任何源到开发Web层中的端口80/tcp或443/tcp的流量

• 允许从任何源到生产Web层中的端口80/tcp或443/tcp的流量

• 端口8080/tcp上允许从生产Web层中的应用程序到生产处理层中的同一应用程序的流量

• 端口5432/tcp上允许从生产处理层的应用程序到生产数据库层中的同一应用程序的流量

• 应用程序跳转主机可以通过SSH连接到同一应用程序中的任何其他工作负载，除了五个生产应用程序的情况（其中的SSH路径描述如下图所示）

• 所有其他流量都被拒绝

图5-SSH访问特例

此图表示以下五个生产应用程序的SSH访问特例：

• PCI应用程序

• 订单（Order）应用程序

• 结算（Settle）应用程序

• 库存（Inventory）应用程序

• 资产管理（Asset Mgmt）应用程序

“数据库订单生产（DB Order Prod）”服务器包含了存储奖杯（包含一张模拟PII的表）的crown_jewels（皇冠宝石）数据库。

06 测试方法论

为了进行攻击模拟，评估团队根据测试环境预期和与Illumio环境相关的主要缓解措施，即网络分段和横向移动，从MITRE ATT&CK和Pre-ATT&CK框架中提取了相关的TTP，并将这些TTP分为以下部分：

根据上表所列的战术和技术，采用下面的方法来执行测试活动：

注：该图中间的3个战术（本地主机侦察、网络发现、横向移动），与上表中的3个战术对应，可采用每个战术中所列的技术。

这种方法适用于所有的测试用例，对于团队成功渗透的每个主机，他们通过网络扫描来记录邻居（当前主机的可访问主机）和可用服务的数量。

07 测试结果

评估团队共进行了6次不同的攻击模拟。如下所示：

1. 对照测试（100个工作负载）

2. 用例1-环境分离（100个工作负载）

3. 用例2-应用程序隔离（100个工作负载）

4. 用例3-基于层的分段（100个工作负载）

5. 用例2–500个工作负载（应用程序隔离）

6. 用例2–1000个工作负载（应用程序隔离）

可见，对照测试和前三个用例都在100个工作负载环境中运行。而为了度量环境变化的影响，评估团队还分别在500和1000个工作负载环境中，执行了用例2（应用程序隔离）场景，以更好地了解网络规模如何影响总体复杂性。

本节描述了这些测试的可观察结果，包括Bishop Fox观察到的时间、主机和服务的指标，以及由Illumio识别的流量事件（允许/拒绝的连接）。

1）对照试验

对照环境由99个工作负载组成。此环境为扁平网络，允许每个主机彼此通信。

评估团队遵循上一节所述的方法执行侦察、凭证收集、目标分析、渗透转移活动。

在本轮测试中，公共跳转主机为10.0.0.98。从那里，评估团队列出了正在运行的进程，并迅速确定Illumio-VEN代理正在运行（尽管处于“构建模式”）：

图6-在公共跳转主机上的运行进程

评估团队继续对本地主机进行侦察，发现以下情况：

• 一个已建立到PCE服务器的连接，托管在100.20.217.186:8444

• 有两个SSH密钥可以访问，在/home/centos/.ssh

• shell历史记录包含对子网10.0.1.0/24的引用

然后，评估团队对10.0.1.0/24子网进行了网络扫描，识别出99台主机，暴露了293个服务。在那里，评估团队重用了来自公共跳转主机的SSH密钥，来连接到所有主机，并再次启动本地侦察循环。

评估团队在10.0.1.42上发现了一个感兴趣的README.txt文件，如下所示：

图7-在10.0.1.42上检索到的第一条线索

有了这些信息，下一步就是在所有Postgres服务器上运行这些命令，以识别存放皇冠宝石的服务器并提取它们：

图8-在10.0.1.42上发现的皇冠宝石

下表总结了第一轮测试的量化结果：

获得皇冠宝石的时间似乎很长，因为这是评估团队第一次面对该环境。正如在“环境概述”一节中所解释的，评估团队事前并没有关于应该查找或提取什么内容的信息。正如预期的那样，阻塞的连接数为零，因为根据定义，对于这种扁平网络场景，没有适当的微分段措施。

由于所有的测试都是在同一个环境下进行的，为了避免在第一个对照测试中遇到的学习曲线，团队在重建的环境上重新进行了测试。下表说明了第二轮对照测试的结果：

正如预期的那样，在第二轮测试中，团队只花了30分钟就达到了目标（而第一轮测试花费了4小时）。

第二轮测试代表了对照测试用例。所有后续测试用例的时间度量，都将与第二轮测试进行比较，因为只有过滤策略发生了更改；而环境本质上是相同的。

2）用例1–环境分离

此测试场景发生在与对照测试环境具有相同属性的环境中，其中唯一的区别是启用了Illumio-VEN代理，进行了微分段。简言之，环境分离可以理解为：生产主机只能与生产主机对话，而开发只能与开发对话等。

这一轮测试的入口点系统是10.0.0.90。团队再次从公共跳转主机收集本地信息开始，这导致了类似的观察结果：

• 除了与PCE服务器的出口连接外，没有建立出口连接

• 一个SSH密钥位于/home/centos/.ssh/

• shell历史记录为空

然后，团队进入了网络发现阶段，很快发现了第一个区别：来自公共跳转主机的入站和出站ICMP流量都被iptables规则过滤，并由网络策略强制执行：

图9-由本地主机阻止的传出ICMP流量

该团队借助第四层扫描，来识别来自公共跳转主机的可访问工作负载。从这些扫描中，在10.0.1.0/24子网中发现了9个新主机：

• 10.0.1.10

• 10.0.1.100

• 10.0.1.124

• 10.0.1.151

• 10.0.1.156

• 10.0.1.174

• 10.0.1.177

• 10.0.1.195

• 10.0.1.250

下一步是连接到这些主机，然后再次启动循环，如方法论一节所述。团队在每个主机上运行本地发现，然后开始扫描每个主机的地址空间。

在分析第二个跳转主机上的循环迭代的结果之后，团队识别了托管在10.0.1.118上的感兴趣的README.txt文件：

图10-在10.0.1.118上检索到的第一条线索

从那里，团队返回到已经收集的结果，以枚举所有可用的Postgres服务器。最后，他们从第二个跳转列表中的每个主机运行以下命令以检索皇冠宝石：

图11-从10.0.1.252上检索到的皇冠宝石

如上图高亮所示，团队通过10.0.1.195访问了运行Postgres服务器的主机，该服务器包含皇冠宝石。最终的攻击路径如下：

10.0.0.90>10.0.1.195>10.0.1.252。

下表说明了与此轮测试相关的度量值：

这一轮测试的主要观察结果是，拿到皇冠宝石的时间增加了三倍（90分钟对30分钟）。这是由于相对于在扁平网络中提供的自由而言，横向移动明显减少了。识别的主机数量略有减少，这是因为一旦目标实现，评估小组就停止了测试。这也解释了为什么Illumio团队观察到的传出连接数与对照环境测试相比有所减少。

3）用例2–应用程序隔离

此测试场景发生在与对照环境具有相同属性的环境中，其中唯一的区别是启用了Illumio-VEN代理，并设置了附加的微分段。简言之，应用程序隔离是指同一应用程序和同一环境中的主机和工作负载之间可以进行通信，但不允许进行其他任何通信。

此轮测试的入口点系统为10.0.0.186。与用例1相比，来自公共跳转主机的本地主机侦察阶段给出了相同的结果。

在对公共跳转主机运行网络扫描后，该团队再次确定了9个新的跳转主机：

• 10.0.1.128

• 10.0.1.134

• 10.0.1.139

• 10.0.1.17

• 10.0.1.184

• 10.0.1.204

• 10.0.1.48

• 10.0.1.77

• 10.0.1.8

然后，团队从这些主机中依次重新启动攻击循环。通过查看网络扫描结果，团队注意到第二个跳转主机公开的服务与从公共跳转主机访问的服务有区别。

团队最终在10.0.1.204上找到了一个感兴趣的README.txt文件，可通过10.0.1.244访问：

图12-在10.0.1.244上检索到的第一条线索

从那里，团队构建了一个运行Postgres实例的所有已发现主机的列表，并尝试通过SSH运行突出显示的命令来检索皇冠宝石。最终在10.0.1.167服务器上找到了：

图13-从10.0.1.167中检索皇冠宝石

获得皇冠宝石的最终攻击路径如下：10.0.0.186>10.0.1.139>10.0.1.167。

下表说明了与此轮测试相关的度量值：

再一次，在这轮测试中发现的主机更少。这主要是由于在测试环境中实施了更严格的微观分段策略，这也减少了已识别服务的数量。评估团队还测试了更多的试验和错误尝试，更多的传出连接就说明了这一点。必须进行更多的扫描以确定存放皇冠宝石的服务器。

最终，与第一个用例相比，团队获得皇冠宝石的时间增加了1.5倍，与对照测试相比增加了3倍。这再次证明了微分段策略的有效性。

4）用例3–基于层的分段

此测试场景发生在与对照环境具有相同属性的环境中，其中唯一的区别是启用了Illumio-VEN代理，并且进行了微分段。基于层的分段是最细粒度的微分段形式之一，只有在相同的环境、相同的应用程序、相同的应用程序层中的工作负载，才能相互通信。对于一个敌手来说，这意味着为了横向移动，可利用的开放路径数量显著减少。

这一轮测试的入口点系统是10.0.0.146。与用例1和用例2相比，来自公共跳转主机的本地主机侦察阶段给出了相同的结果。

在对公共跳转主机运行网络扫描后，该团队再次确定了9个新的跳转主机：

• 10.0.1.18

• 10.0.1.22

• 10.0.1.38

• 10.0.1.57

• 10.0.1.67

• 10.0.1.73

• 10.0.1.138

• 10.0.1.208

• 10.0.1.250

然后，团队从这些发现的主机依次重新启动攻击循环，以收集本地主机信息，然后执行网络扫描。第二轮侦察发现README.txt文件存在于10.0.1.146上，可从10.0.1.18访问：

图14-在10.0.1.146检索到的第一条线索

从那里，团队分析了从上面第二个跳转列表中提取的所有主机的本地侦察结果，以识别正在运行的Postgres服务器实例。然后，他们依次尝试通过SSH连接到它们，以检索皇冠宝石。

这种方法不成功。结果，该团队从第二个跳转位置访问的主机，重新启动了攻击循环，但使用了更有针对性的扫描（重点放在SSH暴露的端口上）。通过分析结果，团队识别了一个服务器：10.0.1.137，它可以访问一组全新的目标，包括存储皇冠宝石的服务器：10.0.1.248。

图15-在10.0.1.248上检索到的皇冠宝石

下表说明了与此轮测试相关的度量值：

由于严格的基于层的微分段策略，团队必须枚举测试环境中可用的所有主机，以识别存储奖杯数据的主机。发现的端口数量减少的原因，既有更严格的网络过滤策略，也有该轮测试接近尾声时操作方法的改变。由于团队在测试的早期发现了第一条线索，扫描端口的数量减少了，这是因为扫描的目标更加明确。这也是Illumio团队观察到的传出连接数量较少的主要原因。

最终，与第二个用例相比，团队获得皇冠宝石的时间增加了2.11倍，与对照测试相比增加了9.5倍。

5）用例2–500个工作负载

这个场景是用例2的一个副本，但是工作负载的数量增加到500（而不是100），以了解工作负载总数如何影响枚举网络和捕获奖杯所需的时间。

评估团队所采用的方法和最初的观察结果与用例2的相同。唯一显著的区别是执行连续网络扫描活动所需的时间。

下表说明了与此轮测试相关的度量值：

将环境规模乘以5后，对评估团队取回皇冠宝石所需的时间的确有直接影响。与用例2相比，该场景中达到目标的时间增加了1.88倍，与对照环境相比增加了8.5倍。

传出连接的数量稍低，因为在测试的这个阶段，评估团队利用本地主机防火墙规则中的信息来识别下一个可访问的主机，而不是盲目地扫描网络来发现主机。这还允许评估团队识别环境中的所有主机。

6）用例2–1000个工作负载

这个场景是用例2的副本，但是工作负载的数量增加到1000（而不是100）。

评估团队所采用的方法和最初的观察结果与用例2的相同。唯一显著的区别是执行网络扫描活动所需的时间。

下表描述了与此轮测试相关的度量值：

由于环境的规模是对照测试环境的10倍，所以团队决定尽可能并行地运行网络发现阶段。在此之前，所有的网络扫描活动都是按顺序运行的，显然花费更长的时间。

采用这种方法，评估团队花了不到2小时（1小时51分钟）就获得了皇冠宝石。为了公平起见，为了得到可比较的结果，评估团队将每次网络扫描的时间累积起来，就好像它们一直在按顺序运行一样，得到了上表中的保留时间。

评估团队对远程主机的发现活动，使用了与500个工作负载用例相同的方法。通过这样做，该团队能够在不运行网络扫描的情况下快速识别新主机，这导致了有限数量的传出网络连接。

08 评估结论

总之，评估团队发现，正确应用微分段策略会增加横向移动和通过测试网络穿透的难度，从而导致总体上增加了失陷时间和产生的可检测事件的数量，以便攻击者获取目标敏感信息。明确地：

• 即使是保持应用程序环境分离的最基本的分段策略，攻击者也需要付出至少三倍的努力；

• 增加微分段能力的覆盖规模，同时保持相同的策略状态，可在延迟攻击者方面获得可观的收益；

• 使用微分段迫使攻击者改变技术，以便更有效地遍历网络；

综合起来，这些发现强调了将微分段作为组织企业安全态势的一部分的重要性，因为控制在阻止横向移动方面具有可度量的有效性。

声明：本文来自网络安全观，版权归作者所有。