案例研究
PDF零信任的到来：这意味着什么？
与 Michael Loftus、Andrew Vezina、Rick Doten 和 Atefeh Mashatan 的讨论
过去，企业网络安全就像城堡和护城河。首先，保护边界，然后在内部进行“信任，但要验证”。
当然，边界是企业网络。但现在这又意味着什么呢？现在大多数员工至少有一部分时间在家工作——通常使用他们自己的智能手机或笔记本电脑——而且组织越来越依赖云计算，企业范围的单一边界已经不复存在。
而且，在过去二十年中，企业安全漏洞已成为常规新闻，信任也基本上消失殆尽。
约翰·金德瓦格 (John Kindervag) 在十多年前阐述了零信任企业防御策略，他解释说：“这个概念围绕着这样一个原则构建：不应信任任何网络、用户、数据包、接口或设备——无论是在（企业）网络内部还是外部。有些人认为零信任是关于使系统变得可信，但它实际上涉及从网络安全策略中消除信任的概念。”
说起来容易做起来难，这是自然而然的。尽管如此，这项工作进展如何？我们请多伦多都会大学 (TMU) 网络安全研究实验室的创始人兼主任 Atefeh Mashatan 与三位长期从事企业安全工作的专业人士探讨了这个问题：Equitable (EQ) 银行的首席信息安全官 (CISO) Andrew Vezina；Centene Corporation 的信息安全副总裁兼 Carolina Complete Health 的首席信息安全官 Rick Doten；以及拥有丰富企业安全经验的 IT 顾问 Michael Loftus。
ATEFEH MASHATAN 零信任安全模型引起了广泛关注。有些人称之为网络安全的“黄金标准”，而另一些人则认为这不过是组织早就应该采用的网络实践的营销术语。真相是什么？
MICHAEL LOFTUS 这介于两者之间的某个位置，因为零信任是一个概念框架，它挑战了长期以来的假设，即如果您在防火墙边界内，并且是某个特定企业域的一部分，那么您和您的设备都将被授予隐式信任。实际上，零信任挑战了任何形式的隐式信任都可以被认为是安全的想法。
但如果您要问，“这些所谓的新的零信任措施是否经常包含以前部署过的技术？”，答案是“绝对是！”。在多因素身份验证 (MFA) 和高级分析方面尤其如此。然而，我是否仍然认为零信任可以被认为是新的和热门的东西？当然！
最终，事实是，零信任是一种方法，它涉及在用户和设备的身份验证方式以及风险管理方式方面采取不同的做法。这一切都是因为我们将不再假设环境的任何部分都可以被授予隐式信任。
AM 但我们不应该一直这样做吗？
ML 我不会这么说，因为我认为零信任的出现是为了回应我们在转向更分布式环境中所吸取的许多不同教训，在这些环境中，应用程序、数据和身份机制现在都驻留在云端。随着这种转变，曾经足以保护企业场所内与企业网络连接的人员的安全机制变得不足。
AM 您认为零信任环境的绝对最低要求是什么技术？您认为哪些其他功能非常理想？
ANDREW VEZINA 每当我构想零信任架构时，我都会从中间开始向外扩展。一切似乎都回归的中心要素是信任引擎，它负责决定是否应该允许某个特定用户从某个特定设备访问某个特定资源或应用程序。正如 Mike 所指出的，这曾经是一个更简单的调用，基于用户是否可以提供正确的 Active Directory 密码。但是现在，在零信任下，这种情况正在两个主要方面发生变化。
首先，在用户及其身份验证方面，我们将使用更丰富的信息集。这里最大的变化是从简单密码到多因素身份验证的转变。我们还开始看到许多新的功能和工具，它们将能够利用与用户登录特征相关的所有遥测技术。
第二个值得注意的重大改进是能够更有效地验证设备身份，这仅仅是因为我们能够获得更多关于人们在尝试访问环境时通常使用的设备的信息。实施零信任的行动始于将所有身份验证决策推送到应用程序，以便可以将更多上下文纳入决定是否应授予对所请求资源的访问权限。
从那里，您可以开始考虑人们将如何访问应用程序，以及这表明您的网络应该是什么样子——请记住，您将不再需要局域网或企业网络作为信任方法，也就是说，我们正在转向一种安全模型，在这种模型中，网络用户来自何处基本上无关紧要，因为您将依赖用户和设备遥测技术进行身份验证，而不是网络告诉您的信息。
通过 SASE（安全访问服务边缘）和类似技术，还可以简化和改善用户体验。从根本上说，这只是为用户提供了一条更简洁、更轻松的路线，让他们可以从他们碰巧所在的任何地方到达他们想要使用的任何应用程序。反过来，这导致了一种架构，您依赖通常基于云的 SASE 技术以安全的方式提供对 Internet 的访问，即使您也依赖软件定义边界技术来允许从 Internet 连接到用户可能请求的任何应用程序或资源。
AM 现在您已经让我们了解了 SASE 如何与零信任相结合，您能否比较两者以指出它们的异同？
AV 首先，我会将零信任描述为一种策略，而 SASE 是一种技术，在过去几年中，它在很大程度上取代了许多组织曾经用来评估用户流向 Internet 的流量（即他们的出口流量）的整类本地工具。通常，这包括 Web 内容过滤、恶意软件分析，甚至可能包括数据丢失防护分析，以及其他一些功能。
在 SASE 之前，一切都建立在企业网络之上。因此，如果用户在家工作并出于任何原因想要访问 Internet，他们首先必须登录企业网络，进行 VPN（虚拟专用网络）连接以进入网络，然后执行发夹弯以返回 Internet——通过企业代理和恶意软件工具，以及可能沿途的三、四或五个不同的安全工具。借助 SASE，用户无需先跳到企业网络，而是通过 SASE 提供商进行路由，所有必要的安全功能都通过云模型提供，该模型与零信任策略互补，因为它不需要企业网络。
由于这两个概念是互补的，因此似乎大多数正在实施零信任架构的组织现在也在转向 SASE。话虽如此，两者并非必然相互依赖。也就是说，您可以实施 SASE，但仍然可以采用传统的安全模型。并且至少在理论上，可以在没有 SASE 的情况下实施零信任，但在目前的技术条件下，这可能会被证明是困难的。
RICK DOTEN 我倾向于将 SASE 视为基础设施，正如 Andrew 所指出的，它取代了以前在本地运行的各种工具。是的，将所有这些都放在云端肯定会简化用户的事情。该基础设施仍然为实施所有策略决策提供了一个中心点。这一切都很棒，特别是对于没有大量基础设施并且可能已经在很大程度上依赖基于云的应用程序和服务的 中小型组织而言。对于他们来说，SASE 是理想的选择。
但我代表一家非常大的公司，在这种公司中，这将被视为牺牲可见性和控制力，因为它不允许直接管理和配置所有不同的功能集和监控选项，即使我们被允许在高层次上设置规则和控制事物。
最重要的是，SASE 非常适合希望依赖专门的外部基础设施来处理其所有安全监控、响应和控制的中小型组织。这当然有望减轻他们自己的管理负担，并基本上为他们的用户提供了一条通往他们所有应用程序的干净管道。
然而，这不一定会对所有组织都有效。除了规模问题外，还有某些受监管的行业（尤其是在美国），公司可能不愿意将受保护的数据（例如医疗保健信息和客户财务信息）外包给 SASE 提供商。在这方面，重要的是要记住，SASE 提供商会希望以解密形式查看某些内容，尤其是在行为监控方面。
零信任似乎最好被描述为一种策略或方法，也就是说，它有点模糊且难以确定。当然，这对于那些销售网络安全产品和服务的公司来说绝对是一份礼物。
事实上，零信任得到了真正的热情推广。行业媒体在报道零信任以及为营销它所做的努力时，通常使用“炒作”一词。然而，即使是批评者也 readily agree 这种方法的某些方面完全是明智的。
有一件事似乎是肯定的：关于零信任是否能够实现所有营销泡沫，陪审团仍在审议中。
AM 迄今为止，可以公平地说，零信任策略主要在北美站稳脚跟。例如，在欧洲，您看不到很多零信任计划的启动。此外，值得注意的是，NIST（国家标准与技术研究院）是迄今为止唯一发布零信任架构指南的标准机构。
为什么所有这些精力似乎都集中在北美？
RD 这是一个有见地的问题，因为它指出零信任正在向美国的公司积极营销，而不是向其他人营销那么多。这确实让您想知道这里可能发生了什么。我认为这背后的根源是美国通过微妙地操纵恐惧、不确定性和怀疑来销售产品的历史——所谓的“FUD 因素”。在这种情况下，宣传大致是这样的：“这是一个极其复杂的问题，对您来说太大了，您无法独自处理。但是，只要付出一定的代价，我们就可以提供帮助。”作为北美人，我们已经习惯于对这种营销做出回应，但这不一定是世界其他地方的习惯。事实上，在许多欧洲国家，这种做法是非法的。
我确实认为零信任在美国被炒作了，坦率地说，我为我们的行业以及 NIST 感到尴尬。事实上，如果您仔细查看 NIST 指南中的文本，您会发现与每个大型供应商已经提出的叙述密切相关的论点——有时使用完全相同的词语。
最近我一直在思考这个问题，因为在当前的圆桌会议上，有很多关于数字化转型以及将一切推向云端的讨论。老实说，整个零信任宣传与此有点太吻合了。事实上，我认为零信任只不过是安全领域数字化转型的附带概念。
有趣的是，这些东西甚至都不是特别新鲜。我的意思是，当您考虑一下时，我们已经有网络访问控制很长一段时间了。早在 20 年前，您就可以连接到 VPN，该 VPN 会仔细检查您的环境，以确保您的操作系统是最新的，您的防病毒保护已打开并已连接，并且您加载了正确版本的软件等等。所有这些都涉及远程访问。我们还有行为监控和基于风险的监控。
这些概念并不新鲜。唯一的区别是，虽然我们过去常常通过企业基础设施中的门户访问所有这些应用程序，但现在我们可以在不通过企业基础设施的情况下在云端访问它们——这很棒，但并不完全是零信任营销可能让您相信的巨大飞跃。
AM 你们其他人是否同意零信任策略被过分夸大了？
AV 我在很大程度上赞同 Rick 的怀疑态度。多年来，我们肯定看到了许多新的安全方法，无论是技术形式还是策略形式。大约 15 年前，恶意软件沙箱作为识别恶意软件的新方法被引入，这是一个我想到的例子。在此之前，我们都使用基于签名的防病毒检测，但效果不佳。然后，这项新技术问世，事实证明这是一个明显的改进。但它也被很大程度上过分宣传为解决漏洞的方案，因此为一些供应商赚取了数十亿美元。现在，它对于大多数组织来说只不过是基本要求，并且它实际上从未设法解决问题。它在某些情况下有所帮助，但随后攻击者进化了。
可以认为，零信任有点不同，因为它是一种策略，而不是一种战术对策。但我们还不知道它是否会实现炒作，而红队演习可能是评估其有效性的最佳方法之一。
事实上，近年来，我参与了针对传统防御运行的几次不同的红队演习。每次攻击都有不同的目标并使用了不同的方法。但共同的主题是，一旦攻击者在环境中站稳脚跟，他们就可以采取许多不同的途径横向移动，以获取他们想要破坏或在执行某种目标（如数据盗窃或勒索软件）过程中使用的任何重要资产。
在我们公司最近的红队演习中，我们为攻击者提供了环境中两个初始立足点。机器 #1 是连接到企业网络的传统工作站，它被赋予了通常随之而来的信任。机器 #2 更符合零信任的要求，因为它无法连接到企业网络或网络上的任何其他机器。相反，它只能用于连接和使用少量应用程序。
当从这台机器发起攻击时，攻击者发现他们被困在该用户的工作区中，无法横向移动。至少在这种情况下，不信任企业网络的决定限制了横向移动的可能性，从而阻止了这些攻击者实现他们的目标。
相反，对于机器 #1 及其传统的安全架构，攻击者可以轻松地横向移动到企业网络上的其他机器和用户帐户，这最终使他们能够实现他们的目标，而 SOC（安全运营中心）则忙于响应攻击。鉴于此结果，我认为旨在遏制横向移动的架构非常有前景。
RD 我完全同意。我们过去常常开玩笑说，虽然企业网络外部可能坚硬而脆，但内部通常被证明是柔软而有嚼劲的。对于任何承诺减少攻击者横向移动能力的防御措施，都有充分的理由支持。
我也赞赏您的恶意软件沙箱示例。那里的最大教训是人们隐含地信任了这种说法。我八年前有一个恶意软件沙箱，它在 60% 的时间内完全按照宣传的那样工作。另外 40% 的时间，它没有。我的意思是，它没有打开恶意软件，它没有阻止它，它只是把它丢进了邮箱，这只是说明了回到供应商驱动的环境的危害，在供应商驱动的环境中，您购买了东西，安装了它，然后只是简单地期望它能工作。真正的危险是虚假的安全感，让您觉得您真的不需要对这种情况做任何事情，因为您已经受到保护。再猜猜！
AM 人们一定觉得这个领域的所有炒作令人不安。我们应该注意哪些明显的迹象？
RD 我们当然不是在谈论任何类似于公然谎言和歪曲的东西。我认为这更多的是供应商没有为客户提供他们需要的所有帮助，以过滤营销宣传中的华丽辞藻。请注意，零信任作为一个概念是一种非常好的方法。但如果它碰巧与您组织的风险和流程不太匹配，那么它就不适合您。
AV 我认为最好的说明方式是举例说明。一些供应商将身份治理作为实施零信任策略的关键。
身份治理中更突出的控制措施之一是根据特定频率或基于特定事件审查或重新认证用户访问权限的做法。这是每个审计师最喜欢的安全控制措施。但我发现很难将其与零信任的核心原则联系起来，而其他身份控制措施，如 MFA 和中央信任引擎，显然与之对齐。
无论对零信任有何评论，它都不是魔法，也不会通过几个简单的步骤实现。作为企业安全整体方法的巨大变革，无论营销可能暗示什么，它都必然需要大量的努力、大量的投资和充足的时间。
然而，尽管如此，维持更传统的方法并非可行的选择，因为企业攻击面现在已经变得更大，风险更高，并且威胁模型已经从几年前遇到的那些模型演变出多种方式。
那么该怎么办？
AM 让我们更深入地探讨一下零信任实施的问题。这有多复杂？
ML 有多复杂？这可能因人而异。现实情况是，这代表着重大的技术转变，这永远不会是微不足道的。无论您是专注于身份验证还是希望更改您的网络并转向 SASE 提供商，您都面临着一些艰苦的工作，这需要一些时间。
现在市场上发生的大部分事情都集中在身份验证方面——MFA、基于云的 IdP（身份提供商）和应用程序身份验证协议。这仅仅是因为我们多年来使用 Active Directory、Kerberos 和 Windows NTLM（新技术 LAN 管理器）所做的一切都不适合零信任世界。当然，SASE 也在蓬勃发展。
AM 遗留系统和流程在多大程度上使事情复杂化？
ML 如果您依赖旧式 VPN 以及本地目录和存储，那么肯定很难在这条道路上走得很远。在我看来，您真正需要的是一个支持云的 IdP，以及尽可能靠近最终用户出口流量的能力。
然而，所有这些遗留问题的真正问题在于它如何削弱您利用整个零信任方法的能力。也就是说，如果您有很多遗留应用程序，您或许可以采用零信任来更好地控制最终用户访问，但您也无法采用许多零信任实践，仅仅是因为您将无法拦截大多数遗留协议。
AM 一旦组织决定采用零信任，它面临的最大挑战是什么？
AV 如果该组织碰巧正在运行遗留应用程序，正如 Mike 刚才所建议的那样，它可能会面临一些重大困难，无论从零信任的角度还是从云迁移的角度来看都是如此。
在用户方面，还有很多繁重的工作要做。首先，您需要确保您拥有合适的技术来处理用户身份验证。您可能还希望以集中方式提供该技术，以处理您的大多数（如果不是全部）应用程序。这意味着将所有这些遗留应用程序集成到集中式身份提供商。
因此，会有相当多的工作要做，但——除了处理遗留技术之外——我不认为这是一项特别具有挑战性的工作。尽管如此，毫无疑问，这代表着大量的繁重工作，您必须在您的转型路线图中确定正确的位置来进行这些投资。
AM 该路线图中的一些早期步骤可能是什么样的？
RD 这可以追溯到自动化任何业务流程的基本原理——了解已经存在的东西，规划您需要去的地方，然后确定您的安全漏洞可能在哪里出现。在这方面，挑战已经很熟悉了。但是，再加上与遗留与现代相关的问题，我们已经讨论过了。然后还有规模问题，这不仅限于单位数量，因为您还需要考虑所有新应用程序、由于并购活动而产生的所有事情、所有新用户涌入——同时注意到这一切本质上是动态的。
AM 假设组织做出了良好的购买决策并且有一个良好的零信任路线图。它仍然可能面临哪些实施挑战？
AV 大多数失败的组织都是因为实施不完整。组织很容易选择错误的身份提供商，该提供商不一定提供全方位的功能——或者，更有可能的是，仅集成了公司 20% 的应用程序，从而将所有其他应用程序都卡在旧模型中。如果事实证明是这种情况，那么就有必要保留旧的企业 LAN，这意味着公司最终将采用一半一半的架构——这可能会被证明非常具有挑战性。
我认为困难会出现的第二个领域是在端点方面。也就是说，有必要拥有正确的代理（或两个代理，甚至三个代理），以便从端点向上游传输遥测数据到身份源。许多检测功能可能需要投资 EDR（端点检测和响应）功能，以将某种健康遥测数据中继到集中式决策引擎。所有这些都很困难。
很有可能大多数组织目前在其端点上没有能够处理此问题的代理，这意味着他们将需要更换其核心端点技术以获得更现代化的功能，而这反过来又意味着他们所有工作站都需要更新到正确的操作系统级别。
因此，您在这里遇到了两个重大挑战。我会将两者都描述为“地面层问题”，需要解决这些问题才能使取得体面的进展成为可能。
这仍然留下了我认为尚未解决的问题。其中之一是：这种架构应该如何为特权用户工作？他们如何融入到这个图景中？通常，他们的大部分工作都在企业网络上完成。事实上，过去已经实施了一些经过验证的会话管理功能，考虑到这一点。这些功能将如何适应这种新架构？可能已经有人在研究这个问题，但我不太清楚该解决方案会是什么样子。
同样，我也不知道将为开发人员做出什么样的规定——他们有自己的特殊要求。也就是说，他们也经常在企业网络上工作，并且往往有异常高的性能需求。绝对有一些问题仍然有待解决。
RD 作为长期以来一直专注于应用程序云安全的人，我担心的是，到目前为止，零信任几乎完全被视为一个技术问题。现实情况是，了解业务需求也同样重要。IT 安全不仅仅是保护 IT；而是保护业务。我认为我们目前缺乏的是一种治理流程，该流程将经营业务的人员与负责技术运营的人员联系起来，以便他们可以协同工作，以确保这些零信任工作的结果实际上最终满足了业务部门应用程序和数据的弹性、安全和隐私要求。
工程师也确实并不总是考虑用户体验，或者完全理解客户对延迟时间或给定流程中步骤数量的容忍度限制。这也正是来自更多与客户联系的同事的意见可以证明有用的地方。对于降低风险也可以这样说，因为需求清单不能替代可以从经过实践检验的经验中学到的东西。
AM 您能否借鉴自己的经验，指出人们可能遇到的一些具体实施挑战？
AV 我首先想到的是——至少对于规模较大的组织，考虑到它们的规模和所涉及的数据量——即使开始朝着零信任方向发展，也很难获得所需的投资。但总的来说，已经有计划在进行中，旨在进行某些改进，以保持基础设施的最新状态。通常，至少其中一些将与为更好地保护环境而需要做的事情合理地吻合。
例如，也许您的网络出口解决方案即将续订，这意味着您也可以考虑将所有这些都转移到 SASE 模型。或者，也许有些应用程序正在推动组织迁移到云端。作为其中的一部分，您还可以考虑重新设计身份验证过程，使其更符合零信任策略。
这只是想说，需要强有力的领导才能将零信任策略推到前台，并开始安排所有必要的投资。坦率地说，我认为有些组织会在这方面失败，即使所有概念都得到了理解，并且公司有动力向前迈进，这种情况也可能发生。如果事情不能及时实施，这一切都无关紧要。
RD 这里最大的挑战之一也是最古老的挑战之一：组织内部政治。当涉及到为一家大型公司实施像零信任计划这样包罗万象的事情时，您谈论的是协调十几个或更多团队的努力。我的意思是，有身份团队、端点团队、应用程序团队、VPN 团队、云团队等等。
因此，协作、整合和协调成为了关键。让不同的团队合作并朝着相同的方向前进可能极具挑战性，仅仅因为你需要考虑到所有这些不同的各自为政的领域，而且你总会发现一些人根本没有准备好迎接变革。处理这类问题通常比处理技术问题要困难得多。
AV 但是现在，如果我们换个角度，看看另一方面，你会发现所有规模较小（可能也更年轻）的公司，它们的技术债务负担较轻，我们会发现一组非常不同的问题。我们刚才讨论的许多问题在那里都不会是问题。相反，可能会出现执行架构细节方面的问题。例如，负责分配访问权限的人员可能只是简单地授予人们对云提供商整个租户空间的完全管理权限。或者他们可能正在向他们的堆栈中添加工具，这些工具将立即开始寻找某些功能——但是，尽管这些功能碰巧在那里，但没有人启用它们。或者他们可能期望他们的 SASE 提供商执行某些功能，但却忽略了开启必要的检查功能。
这只是想说，许多小型组织都受到这些执行失败的困扰，因为他们往往专家较少，或者可能只有少数通才员工。他们更容易遗漏一些细节。
AM 关于什么 不 该做，有什么建议吗？
RD 并非建议你不应该听取供应商的意见，但不要期望完全坦诚。这呼应了 Andrew 刚才关于规模较小、不太成熟的组织所提出的观点：由于他们缺乏相关经验，他们最终将 更 依赖他们的供应商。这可能会成为一个问题。供应商会试图说服你，如果你购买他们特定的平台，你就会实现零信任。但这行不通，因为这实际上更像是一个旅程。有地图可以帮助你朝着正确的方向前进，但没有任何可衡量的指标可以让你知道你是否已经到达。这只是你需要通过使用你的系统来弄清楚的事情。
你绝对需要一个计划和一些明确的指导方针。没有这些就不要开始这段旅程。不过，如果计划很简单也没关系。事实上，我们喜欢说吃大象最好的方法就是一口一口地吃。所以，先从一件事开始。特别是如果你是一个小型组织，请将注意力集中在那一件事上。只需确保你已经识别出系统中的每个人，并在所有事物上都启用了 MFA。然后你可以从那里扩展。但要分步骤进行；不要试图一次完成所有事情。
还有一件事：在你的脑海中有一套明确的业务需求之前，不要开始这段旅程。否则，供应商会试图为你塑造议程——而这可能不会带来好的结果。
版权 © 2022 由所有者/作者持有。出版权已授权给 。
最初发表于 Queue 杂志 第 20 卷，第 4 期—
在 数字图书馆 中评论这篇文章
更多相关文章
Christoph Kern - 软件安全的开发者生态系统
如何设计和实施信息系统，使其安全可靠，是一个复杂的话题。软件安全和安全的高级设计原则和实施指南都已确立并被广泛接受。例如，Jerome Saltzer 和 Michael Schroeder 关于安全设计原则的开创性概述发表于近 50 年前，各种社区和政府机构发布了关于如何避免常见软件漏洞的全面最佳实践。
Michael Gardiner, Alexander Truskovsky, George Neville-Neil, Atefeh Mashatan - 车辆的量子安全信任
在汽车行业，现在从装配线下线的汽车有时被称为“移动数据中心”，以承认它们包含的所有娱乐和通信功能。自动驾驶系统也已在开发中取得进展，但这并没有减轻人们对安全的担忧。事实上，汽车网络安全的风险似乎将变得更高，而当代网络安全的某些基础正变得毫无意义。
© 保留所有权利。