零信任体系架构中的事件响应 理论与实践
2020-06-18 10:35:48 Author: xz.aliyun.com(查看原文) 阅读量:571 收藏

意义

  • 研究"零信任世界中的事件响应"的意义：
    • 1.有助于企业完善"零信任网络"下应急响应流程
    • 2.有助于企业建设"零信任网络"
    • 3.有助于安全研究人员继续探索
    • ...

意义较大，故逐字翻译，带上了注释，以供参考。

Paper: 《Incident Response in a Zero Trust World》
Author: heath.lawson
Advisor: Lenny Zeltser
Accepted: January 15th, 2020

摘要

"零信任网络"(Zero Trust Networks)，是一种新的安全模型，它使企业能够不断地提供对资产的"受验证访问"(verified access)，并且随着企业使用云资源，这种模型变得越来越普遍(Rose, S., Borchert, O., Mitchell, S., & Connelly, S., 2019)。
"零信任网络"模型使企业能够通过使用各种各样的"信号"(signals)来实现对资源访问的更严格控制，这些信号给"验证访问请求"(validate access requests)提供了很好的可见性。随着这种方法越来越多地被采用，"事件响应者"(incident responders)必须理解"零信任网络"如何增强其现有流程。本文会为使用这种新范式管理事件的事件响应人员提供指导。

  • 本文将比较2种场景的事件响应能力:
    • 零信任网络中的事件响应能力
    • 传统的"以边界为中心"(perimeter-centric)模型的事件响应能力

1. Introduction

  • 大量的条件正在为各个企业"采用新的模型来保护他们的资源"奠定基础：
    • 1.随着"云服务"(cloud services)变得越来越普遍，甚至最关键的业务功能也上了云，各企业意识到他们必须将"安全边界"(security boundaries)扩展到传统网络边界之外
    • 2."连通性的普及"(prevalence of connectivity)
    • 3.设备的多样化
    • 4.劳动力的激增
    • 5.为了实现"总是在线"(always-on), 不间断
    • 6.为了实现"资源总是可用"(always available resources)
    • 7.为了改变员工的工作方式、地点
    • ...

所有这些因素，都对"企业保护其资产的方式"提出了一套新的要求。这种新方法通常被称为"零信任网络"(Zero Trust Networking)，或"零信任体系结构"(Zero Trust Architectures,ZTA)。它侧重于保护资源，而不是像现在常见的那样保护"网段"(network segments)，(Rose, S., Borchert, O., Mitchell, S., & Connelly, S., 2019).

与此同时，"事件响应人员"和"企业防御人员"(enterprise defenders)面临着日益敌视的威胁、比以前任何时候都更加坚定和先进的对手。对传统网络中的事件防御与响应已经得到了充分的证明，但是当它与"零信任"模型相结合时，当今可用的许多事件响应指导细则都暴露出了不足。

因此，这些事实之间的联系，提出了一个重要的问题:
当与云服务结合使用时，"零信任网络的概念"能使事件响应人员(跟传统网络下)同样高效、甚至更加高效吗?

本研究旨在通过"分析常见的云安全事件"来回答这个问题，这些事件都是通过"网络边界安全"(network-perimeter security)和"零信任网络架构"来观察的。

2. Incident Response

事件响应。

  • 如何定义"计算机安全事件"(A computer security incident) ?
    • 定义1 - "计算机安全事件"是一系列可观察的事件共同构成的一项活动，对企业中系统或数据资产的保密性、完整性、可用性具有潜在的负面影响(SANS, 2019)。
    • 定义2 - "美国国家标准与技术研究所"(The National Institute of Standards and Technology)进一步将"计算机安全事件"定义为:“侵害违反，或即将侵害违反计算机安全策略、可接受的使用策略、标准安全实践的威胁”。原文是“a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices”.(Cichonski, P., Millar, T., Grance, T., & Scarfone, K., 2012)。

"事件响应"(incident response): 也称为"事件处理"(incident handling)，是使用已建立的模型管理"计算机安全事件"的过程(Cichonski, P., Millar, T., Grance, T., & Scarfone, K., 2012)。

"事件响应"与信息安全的许多"操作部分"(operational aspects)一样，这些模型通常遵循了一个生命周期，从"事件开始"到"事件修复"、"事件结束"。

  • "事件响应"生命周期
    • 1."准备阶段"(preparation phase) - 企业建立书面策略，获得所需的必要材料和资源，并准备响应事件。
    • 2."识别阶段"(identification phase) - 企业识别事件的范围和严重程度，并启动响应。
    • 3."遏制阶段"(containment phase) - 一旦企业识别了事件，就会进入"遏制阶段"，并采取措施防止攻击者的进一步移动或破坏。
    • 4."清除阶段"(eradication phase) - 一旦企业控制了该事件(防止了蔓延)，企业将开始"清除阶段"，从目标系统中清除攻击者的所有踪迹。
    • 5."恢复阶段"(recovery phase) - 对受影响的系统、数据进行验证，并恢复到正常服务。
    • 6."总结阶段"(lessons learned phase) - 企业得到了教训就总结经验，从事件中得到了见识和改进的机会，并将这些信息提供给"准备阶段"，以"完成闭环"(complete the cycle)。

3. Network-based security model

基于网络的安全模型。

(Scarfone, K., & Hoffman, P., 2009)

  • 企业通常采用通用安全体系结构的某个变体，至少关注3个"网络区域"(network zones)
    • Internet
    • DMZ
    • Intranet 或 Private networks

主机分组：主机按用途和敏感程度分组，并被分配到一个zone。每个zone承载了不同级别的信任。

受信任程度：Private zone> DMZ > hosts on the public network

为了应对当前的威胁发展，构建安全网络的最佳实践，许多安全防御措施通常在网络的每个choke point都找到了家，以确保足够的覆盖范围。
在"以网络为中心"(network-centric)的模型中，安全防御有：IDS，IPS，DLP(Data Loss Prevention tools)，在网络边界上运行的Web代理等。这意味着必须跨越这些网络边界的任何活动都必须被监控、检查、保护(见Figure 1)。

Figure 1. Common network layout with security defenses

  • "以网络为中心"(network-centric)的模型 有多个潜在的缺点:
    • 1.首先，存在一种隐式信任，即只要在"边界安全防御"(the perimeter security defenses)之后的任何设备的连接，就会被认为是“安全的”，且该连接的安全级别等同于那个zone的安全级别。
      • 实际场景:在传统的企业网络中，这意味着如果有了一个已被感染的终端(失陷)，那么就不需要大肆穿过这种网络防御("边界安全防御")，并且攻击者在"初始感染"(initial compromise)之后可以不被检测地移动。
    • 2.另一个根本限制是，流量必须始终通过这些"网络边界"(network perimeters)才能得到保护。
      • 实际场景:因为当今有大量"手机用户"(mobile users)和云服务，所以这样的要求可能给用户体验带来许多挑战。企业经常通过使用VPN等技术来减轻这种限制:将所有流量重新带回"安全网络"(the secured network)，然后通过"边界控制"(perimeter controls)将其路由出去。但是这种方法带来了其他挑战，包括额外的复杂性和潜在的更高延迟，并且可能在非企业拥有的设备上引入"隐私问题"(privacy concerns)，比如BYOD(Bring Your Own Device)等场景。

4. Zero Trust Networks

由于"现代计算环境"(modern computing environment)中的"传统的网络防御"带来的这些挑战，"零信任网络"在企业网络中日益普及。为了能够在各种条件下从任何位置的任何设备进行访问，这个新模型必须确保"只有经过授权的才能够访问资源"，但是我们必须更加细化。
当今这个时代，是容器、"基础设施即代码"(infrastructure-as-code)、数十亿设备的时代，我们不能再仅仅依赖"网络"来提供我们所需的管控能力。取而代之的是，需要一个新模型来解决这个问题：一种在所有用户、设备、应用程序、以及它们接触的数据上都能够使用相同一致的控制面板的模型。

"零信任网络"，也称为"零信任体系结构"，通过对资源访问进行更严格的控制，打破了上一节中强调的广泛的"隐式信任"(implicit trust)。"零信任"模型的核心是:确保每次访问尝试都是经过验证的，并使用所有可用数据来验证它是一个合法请求。

  • 为了更好地描述"事件响应"(incident response)中的零信任，可以将其归纳为以下4个原则:
    • 1.假设公司网络(边界防御和内部人员)不可信。 这一原则与"聚焦于边界"的方法背道而驰，"聚焦于边界"认为: "安全设备背后的任何东西本质上都是可信的、安全的"。而该原则把重点放在"突破事件遏制遏制"(breach containment)和"限制事件损害"(limiting damage)上。
    • 2.对身份(Identity), 设备(Device), 应用(Application), 数据(Data)需要有洞察力。从历史上看，这些资产中的许多资产在"基于网络的探测"(network-based detections)之后(译者注:可能是指无法洞察到这些资产)。在假定网络不可信的情况下，企业只剩下这4个通用的因素来审查"每一笔交易"的安全性。
    • 3.每次资源访问尝试都必须经过验证。与天生内在地信任用户和设备(因为它们处于'secure network')而应具有访问权限不同，而是使用上述所有可用"信号"(signals)来验证这是合法请求(Rose, S., Borchert, O., Mitchell, S., &Connelly, S., 2019).
    • 4."自动化的响应"(Automated response)至关重要。在当前的威胁形势下，"自动化的检测和修复补救"(automated detection and remediation)是我们分析足够的数据并足够迅速地做出响应的唯一方法，以便有机会及时捕获和阻止"高级对手"(advanced adversaries)。

随着零信任的这些原则(Rose, S., Borchert, O., Mitchell, S., & Connelly, S., 2019)的确定，逻辑组件可以解释(见Figure 2)。

Figure 2. Conceptual model of Zero Trust Access (NIST, 2019)

  • 译者注：美国"国家标准技术研究所"(NIST)的模型中，"策略决策点"(Policy Decision Point,PDP)的定义有2个：
    • PDP的定义1:一种系统实体，为自己或请求作出授权决定的其他系统实体做出"授权决定"(authorization decisions)的系统实体。
      • 原文:A system entity that makes authorization decisions for itself or for other system entities that request such decisions.
    • PDP的定义2:一种机制，该机制检查访问资源的请求，并将它们与(适用于访问该资源的所有请求的)策略进行比较，以确定是否应向(发出该请求的)这个具体的请求者,授予具体的访问权。
      • 原文:Mechanism that examines requests to access resources, and compares them to the policy that applies to all requests for accessing that resource to determine whether specific access should be granted to the particular requester who issued the request under consideration.

"策略决策点"(Policy Decision Point,PDP)是个连接点。这可能听起来像一个"边界"(perimeter)，但它与业界最熟悉的广泛边界有根本的不同。相反，把它看作是每个资源的"安全之地"：我们能控制以实现极其简明的需求。在这个"安全之地"之内，我们可以应用"细粒度策略"(granular policy)在资源之间强制执行"最小权限"(least privilege)。

在策略和后续的"决定需求"(decision requirements)方面，"零信任"的下一项优势是聚焦于最大程度地减少"未授权的访问"(unauthorized access)。

通过具有"最小信任区"(minimal trust zone)和健壮的"执行点"(即PDP)的强大控制面板，信号可被组合，以确保使用可用的、最佳的数据来做出访问请求决策。这意味着“零信任”系统本质上会将各种信息源整合在一起。以确保在正确的条件下，以正确的方式、正当的理由访问资源。(Rose, S., Borchert, O., Mitchell, S., & Connelly, S., 2019).

  • “零信任”系统通常汇集哪些"源"(sources)？
    • "基于风险的用户行为模型"(the risk-based models of user behavior)
    • 设备健康程度(device health)
    • 数据分类(data classifications)
    • 合规规范(compliance boundaries)
    • ...

在零信任的世界中，仍然会发生安全事件。可能没有什么技术可以神奇地消除威胁。
重要的是考虑到"零信任网络"的基石，即"缩小信任区域"(shrinking trust zones)的想法。

  • ZTA的基石是"缩小信任区域",它对事件响应的好处有:
    • 1.对任何单一的事件减少其他资源的介入。这意味着当事件发生时，较小的信任区域将减少对其他系统的广泛风险。
    • 2.我们还可以减少检测的延迟，并使每个人的事件响应更高效。

最后，有一个要点需要注意，直到最近才有像NIST这样的标准机构开始提供关于零信任网络的指南，例如在"NIST特别出版物草案"(the NIST draft Special Publication)800-207中写的那样。这很重要，因为它表明被普遍定义为"零信任"的内容仍然存在很大差异。此外，许多安全厂商已经锁定了"零信任"的标签，并用它来推销他们的产品。需要明确的是：零信任仍处于初级阶段，还有更多的工作要做，尽管现在每个人都可以采取一些有意义的步骤。

5. The Experiment

我们已经设计好了一个实验，从每个环境（"传统网络"和"零信任网络"）的典型的示例中捕获数据，并通过我们控制下的一系列事件以对它们进行定量比较。

  • 测试过程包括4个场景，用于模拟使用云服务时常见的真实的安全事件。
    • 场景1."使用未经认可的云服务"(Use of an unsanctioned cloud service) - 通过将包含Microsoft Word文档的测试文件夹上传到"消费者云服务"(consumer cloud service)，可以模拟一次"使用未经批准的云服务"。
    • 场景2."失陷的用户凭据"(Compromised user credentials) - 被危害的用户凭证占了安全事件的近29%(Verizon, 2019)，并通过使用合法的用户凭证进行模拟，这些用户凭证可以通过钓鱼或社会工程获得，从而访问公司服务。在此场景中，将在公司网络外部模拟对抗行为。
    • 场景3."邮件转发的可疑使用"(Suspicious use of mailbox forwarding) - 可疑地使用邮箱转发是一种常见的后渗透技术，被攻击者用于"数据取出"(data exfiltration)、收集信息等(Email Collection, Technique T1114 - Enterprise | MITRE ATT&CK®)。模拟这种场景:创建邮箱规则将邮件转发到外部域，并自动删除已发送的邮件。
    • 场景4."粗心导致的文件过度共享"(Inadvertent file oversharing) - 通过与外部接收者共享云存储服务中的敏感文件，可以模拟"粗心导致的文件过度共享"。这种情况有多种形式，但通常是用户产生的安全事件。

为了定量评估结果，我们使用了一个评分模型来评估环境对PICERL的"2.识别阶段"、"3.遏制阶段"的影响。

PICERL: preparation, identification, containment, eradication, recovery , lessons learned.
PICERL: 1.准备、2.识别、3.遏制、4.清除、5.恢复、6.吸取教训。

选择这2个阶段是为了简化测试，因为"检测威胁"、"初始响应"是事件响应的后续阶段的基础。（换句话说，如果其中某一个环境无法检测到事件、或无法采取任何行动来遏制事件，那么把后续那几个阶段作为一种衡量标准的话，效果较差。）

评分标准如下:

Score Outcome
0 不能完成目标
3 能够完成一部分目标。需要进一步的工作才能进入事件响应的下一个阶段
5 能够完成事件响应所有阶段

除了评分外，每种环境的利弊都在下面的表格中列出:

Phase Zero Trust Architecture Perimeter-based Architecture
2."识别阶段" - Identify Pros: 优点 Cons: 缺点 Score: 分数 Pros: 优点 Cons: 缺点 Score: 分数
3."遏制阶段" - Contain Pros: 优点 Cons: 缺点 Score: 分数 Pros: 优点 Cons: 缺点 Score: 分数

5.1. Network-based security environment

在基于网络的安全环境中，一个简单网络用作评估事件"识别"和"遏制"的测试环境(见Figure 3)。

Figure 3. Network diagram of perimeter-based security environment

  • 这个简单网络中有2个设备:
    • (1)一个Windows 10 client PC
      • 这个Windows 10 1909 client(hostnameWin10Trad)是运行在VMware Fusion上的一台虚拟机，并安装了Office 365 ProPlus，以及所有可用的更新。它充当模拟用户或攻击者执行操作的设备。
    • (2)一个pFSense firewall
      • 这个pFSense防火墙(hostname FW01)也运行在VMware Fusion Pro上。
      • 安装了Snort和OpenAppID规则以提供SaaS软件使用情况。Snort使用默认配置运行，此外还通过Security设置，启用了适当的OpenAppID规则类别、启用了IPS模式。
      • Squid也被安装在PFSense firewall虚拟机中，以充当"用户活动可见性"(visibility into user activities)的proxy，并且被配置为执行SSL审查(SSL inspection)。
      • SquidGuard也被安装在这台虚拟机中，以提供针对指定应用程序URLs的URL filtering(见Figure 4)

Figure 4 Packages installed on pFSense firewall.

5.2 Zero Trust Network environment

为了保持"基于网络的环境"(network-based environment)的简单性，一台PC和几个云组件可用于为"零信任网络"概念建模 (见Figure 5).

Figure 5. Zero Trust Network environment

这台运行在VMware Fusion的虚拟机Windows 10 1909(hostname Win10-ZTN), 被配置为"直接Internet访问"(direct internet access), 用作"客户端活动"(client activities)的测试平台。安装了Office 365 ProPlus以及所有可用的更新。

  • 其他安全工具也已启用，可为"身份"(identity), "设备"(device), "应用"(applications)提供信号:
    • Microsoft Azure Active Directory (AAD)提供了一个以身份为中心的用户身份验证信号，包括可疑的登录。Microsoft Defender ATP (MDATP)提供来自Client的信号，包括对所访问的URL的可见性，以及响应能力(通过"终端"block URLs)。
    • 配置Microsoft Cloud App Security(MCAS)以分析正在使用的云应用程序，并部署了"策略"(policies)来查找"异常或恶意活动"(anomalous or malicious activities)。

值得注意的是，"零信任网络"模型中的这些组件是由作者对工具的预先熟悉而选择的。其他厂商提供的其他组件应该也能提供类似的功能。

6. Findings

6.1. Use of unsanctioned cloud application

在这个场景中，作为一个免费套餐的DropBox账户，从每个终端上传一批文档到一个"文件存储应用程序"(file storage application)，总计30"兆字节"megabytes。

这个"基于网络的环境"提供了数据，这些数据对于识别发送到"未经批准的云服务"(unsanctioned cloud service)的信息非常有用。
LightSquid显示了许多与DropBox URL关联的transactions及其size(见Figure 6), 虽然这并不一定仅仅表示数据离开了网络，但值得进一步调查。
在"遏制"(containment)方面，一支有能力的团队可以迅速采取行动，在proxy中block对应的"违反规定的"(offending)应用程序，然后与用户合作以确保从云服务中删除数据。

Figure 6. LightSquid showing data egress to DropBox

"零信任网络"还提供了有用的数据:用于识别将数据发送到未经批准的云服务。
图7显示了为Dropbox生成的MCAS告警，并在红色框中显示了可以发起 遏制containment/根除eradication 活动(见Figure 7), 通过从终端block站点来实现。
对于事件响应人员和分析人员，这意味着通过在已检测到事件的CASB(cloud access security broker)中采取行动，它将在终端上强制采取行动，无论设备在何处被连接。

Figure 7. Microsoft Cloud App Security showing detection and options to block application

在这个测试中，2个环境都得到了很高的分数10分。分数相同但存在差异，这表明，零信任网络在"识别"(identification)、遏制(containment)事件方面具有明显的优势。

表格:

Phase Zero Trust Architecture Perimeter-based Architecture
2."识别阶段" - Identify 优点：来自"终端"的信号提供了数据，终端无须在公司网络中。告警不是实时的，而是迅速显示"未批准的应用程序"(the unsanctioned application). 缺点:必须配置策略来识别新的"大容量应用程序"(high-volume applications)，需要对端点进行管理/注册(可以自动强制执行). Score: 5 优点：LightSquid提供报告以突出显示数据流，显示完整的URL，并能够突出显示DropBox流量。 缺点:在业务繁忙的环境中，这样的报告很难解释。一些云服务提供商(Amazon, Microsoft等)的Raw URLs实际上可以被合法服务使用。此外，如果该终端不在网络边界之内，则这种可见性将不可用。 Score: 5
3."遏制阶段" - Contain 优点:能够快速block应用程序，无论网络位置如何，都能确保block正常工作。 缺点:在这种情况下，Blocking非常广泛。如果需要针对每个用户或每个组进行更细粒度的控制，则该应用程序将被批准，并加入更丰富的控制机制。 Score: 5 优点:可以将Snort配置为主动阻止已知的bad应用程序，并在允许特定业务部门访问应用程序时，可能提供更细的粒度。 缺点:只有在"受保护的网络"(the protected network)中、或者远程设备(一直开着VPN)连接到受保护的网络中，Block才有效! Score: 5
Total Score 10/10 10/10

原表格:

6.2. Compromised user credentials

"被窃取的用户凭据".

这个场景代表了云服务中最常见的事件之一，其中用户凭证被钓鱼或其他社会工程方法窃取。一旦攻击者获得了用户的凭据，攻击者将使用这些凭据，实现以员工身份访问资源并继续攻击。
通过"模拟攻击者"来测试这个场景：使用用户的凭据，并从Tor来远程访问资源。

在这个场景中，如果没有额外的管控措施，"基于边界的架构"(the perimeter-based architecture)是无效的。因为攻击者正在使用一个边界网络之外的终端的凭据，所以存在“缺乏可见性”的问题。在企业场景中，通常会有一些没有在"基于边界的架构"中表示的"管控措施"(controls)：这些"管控措施"可以借助数据(比如来自身份提供程序的"集中化的日志"、Office 365 activity logs)帮助识别恶意活动。

零信任网络将"登录"识别为异常，并从"身份"(identity)的丰富信号中受益，以带来可见性，并遏制、清除、恢复用户凭据(Figure 8)。

Figure 8. risky sign-ins detected.

  • 在这个例子中，这次登录触发了2个风险告警:
    • 1.登录者来自新的位置(a new location).
    • 2.登录者源自Tor.

此外，仅在通过"多因素身份验证"(MFA,multifactor authentication)验证了其身份之后，才允许用户更改密码。

  • 通常部署了许多"防御措施"(defenses)，以防止"防御措施被故意禁用"、或"防御措施未部署"的情况。如
    • "多因素身份验证"之类的管控措施将阻止攻击者使用这些被窃取的凭据；
    • 其他"以身份为中心的"(identity-centric)管控措施仅允许来自健康设备的登录。如"终端检测和响应"(Endpoint Detection and Response)或"移动设备管理"(Mobile Device Management)解决方案判断该设备为健康的、非恶意的设备。

表格:

Phase Zero Trust Architecture Perimeter-based Architecture
2."识别阶段" - Identify 优点:能够基于"多种因素"(multiple factors)快速对异常登录发出一条告警。 缺点:可能会因为员工出差等原因，而产生误报。 Score: 5 没有部署额外的能力，无法测量。 Score: 0
3."遏制阶段" - Contain 优点:用户访问的下一个资源通过"多因素认证"(MFA)进行身份验证，并且用户的密码将被更改。 缺点:在没有额外工作的情况下，这只适用于利用"身份提供者"(the identity provider)的应用程序，并且可能会造成"空白"(gaps). Score: 5 没有部署额外的能力，无法测量。 Score: 0
Total Score 10/10 0/10

原表格:

6.3 Suspicious use of mailbox forwarding rules

表格:

Phase Zero Trust Architecture Perimeter-based Architecture
2."识别阶段" - Identify 优点:Microsoft Cloud App Security发出一条告警，指示配置了可疑的收件箱转发。 缺点: N/A Score: 5 没有部署额外的能力，无法测量。 也可以通过检查SMTP mail flows,或其他"消息日志"(message journaling)也可以检测到。 Score: 0
3."遏制阶段" - Contain 优点:自动遏制，包括遏制"已被控制的用户"(the compromised user)，基于策略定义驱动的用户凭据的重置。 缺点:此遏制仅适用于有问题的用户，而不适用于受攻击者的消息影响的下游用户。 Score: 3 没有部署额外的能力，无法测量。 Score: 0
Total Score 8/10 0/10

原表格:

6.4 Inadvertent sharing of sensitive file by user

表格:

Phase Zero Trust Architecture Perimeter-based Architecture
2."识别阶段" - Identify 优点：通过定义策略，MCAS能够识别此应用程序级别的信号。可获得有关"访问尝试"(access attempts)的更多详细信息。 Score: 5 优点：LightSquid能够突出显示"离开网络的数据"(data leaving the network)，如果部署了其他拦截或DLP工具，它们将识别出敏感数据。 缺点:报告对于这个用例是原始的，因为它以"URL"和"数据流"为中心——非常适合用于识别未批准的内容,但对xx来说不够详细。 Score: 3
3."遏制阶段" - Contain 优点：虽然没有对这个test进行配置，但MCAS具有功能："撤消共享"(revoke sharing), "隔离文件"(quarantine the file), "应用加密"(apply encryption), "通知用户"(notify the user), "启动其他工作流"(start an additional workflow)等...所有有效的遏制步骤。此外，可以部署预防性的、实时的管控措施，以防止将敏感文件上传到一个共享的位置。 Score: 5 没有部署额外的能力，无法测量。 Score: 0
Total Score 10/10 3/10

原表格:

6.5 Results

从数据中可以看出，"零信任网络模型"(Zero Trust Network models)的优势明显大于"管控环境"(the control environment)。随着场景演变为更深入的应用程序和终端的上下文，"基于边界的安全控制"(perimeter-based security controls)失去了提供有意义的"可见性"能力、"控制"的能力。

test Score - Network security Score - Zero Trust Network
"将窃取到的数据传到未经授权的云服务"(Exfiltration of Data to unauthorized cloud service) 10 10
"失陷的用户凭据"(Compromised user credentials) 0 10
"邮箱转发"(Mailbox forwarding) 0 8
"粗心共享了敏感文件"(Inadvertent sharing of sensitive file) 3 10
Total 13 38

7. Recommendations

建议。

  • 虽然这些测试是在简单的环境中进行的，但是数据说明了：
    • (1)在不同安全模型中识别事件、遏制事件的关键差异。
    • (2)在与云服务一起使用时，还表明了基于边界的模型的不足之处。

为了回答本文前面提出的假设，显而易见，零信任网络对云服务具有可见性，并且可以为事件响应者提供更多的好处。

小结一下，基于网络的安全性无法完成2个目标，因为它缺乏识别特定场景所需的"深度应用程序上下文"(the deep application context)。这是因为可见性受限于"活动"(activities)的网络角度，如果没有丰富的"数据包重组"(packet reassembly)和大量上下文，网络设备就没有足够的"智能"(intelligence)来识别活动。

相反，"零信任网络"能够快速识别事件、遏制事件，因为它将"应用程序日志"(the application logs)作为信号包含在内。这在其他"使用了不同的信号"的场景中是重复的：如来自"身份"(identity)和"终端"(endpoint)的信号。

  • 事件响应者应考虑以下建议：
    • 1."集中化应用身份"(Centralize application identities) - 它可以作为核心PDP，并提供"单一的日志"(a singular logging)由表及里地来检测异常的身份验证和授权。
    • 2."使用应用的活动数据"(Consume application activity data) - 在这个例子中, CASB(cloud access security broker)使用了丰富的活动数据，作为应用内部的用户活动信息的整合点。但"基于网络的安全模型"肯定没有CASB, 这种场景或许可以考虑这种过渡步骤: 将来自应用程序的"数据"合并到SIEM之类的"中央位置"(central location)，并可以配置规则以实现告警。
    • 3."考虑事件响应中集成的威力"(Consider the power of integration in incident response) - 在上面的例子中，识别事件、遏制活动之间有直接的关联，这通常是通过组件之间的内置集成完成的。在这两个阶段之间的时间间隔越短，一个事件就可以越快地得到解决，而且更重要的是，可能降低严重性或影响。

8. Conclusion

  • 这项研究虽然针对"简化版"的企业环境表示，但它强调说明了:
    • 在识别和遏制阶段，当企业结合"云服务"和"零信任原则"时，防御人员和响应人员都明显受益。在应用程序"洞察"(insights)需要比网络"审查"(inspection)提供更多上下文的场景中、或者在必须组合多个信号的场景中，零信任网络原则比传统网络具有优势。
    • 当前的威胁状况作为了外部的推动力，从本研究提供的数据中我们可以看到，当前的威胁状况几乎要求了: 企业在迁移到云服务以实现关键业务功能时，需要积极接受这些原则。

References

Cichonski, P., Millar, T., Grance, T., & Scarfone, K. (2012). Computer security incident handling guide: recommendations of the National Institute of Standards and Technology. Gaithersburg, MD: U.S. Dept. of Commerce, National Institute of Standards and Technology.

Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2019). Zero Trust Architecture, Draft. Gaithersburg, MD: U.S. Dept. of Commerce, National Institute of Standards and Technology.

Scarfone, K., & Hoffman, P. 800-41 Guidelines on Firewalls and Firewall Policy, 800-41 Guidelineson Firewalls and Firewall Policy (2009). Retrieved from https://csrc.nist.gov/publications/detail/sp/800-41/rev-1/final

Class materials for SANS SEC504, Hacker Tools, Techniques, Exploits, and Incident Handling.(n.d.).

Email Collection. (n.d.). Retrieved January 1, 2020, Retrieved from https://attack.mitre.org/techniques/T1114/.

Verizon. (2019). 2019 Data Breach Investigations Report. Retrieved from
https://enterprise.verizon.com/resources/reports/2019-data-breach-investigations-report.pdf


文章来源: http://xz.aliyun.com/t/7882
如有侵权请联系:admin#unsafe.sh