谷歌BeyondCorp系列论文(六):构建健康机群(附论文合集下载)

前言


       随着企业大规模的采用移动互联网和云计算技术,传统的采用防火墙建立的“城堡”安全模式,变得越来越不安全。2014年12月起,Google先后发表6篇BeyondCorp相关论文,论文提供了一种新的安全模式,设备和用户只能获得经过验证的资源,构建软件定义安全的雏形。另外,论文也介绍了BeyondCorp的架构和实施情况,为传统网络架构迁移至BeyondCorp架构提供依据参考。


       为推动国内安全技术和理论与国际同步,在国内传播国际优秀实践,中国云安全联盟秘书处组织专家翻译BeyondCorp相关论文,供大家学习参考。


       本文档一共由BeyondCorp的六篇论文组合而成:

       [1] BeyondCorp:一种新的企业安全方案

       [2] 谷歌BeyondCorp:从设计到部署

       [3] BeyondCorp:访问代理

       [4] 迁移到BeyondCorp:提高安全性的同时保持生产力

       [5] BeyondCorp :用户体验

       [6] BeyondCorp:构建健康机群


       关注“云安全联盟CSA”公众号回复“谷歌BeyondCorp系列论文”,可以下载该系列论文合集。


【第六篇】BeyondCorp:构建健康机群


       任何系统的安全等级不可能超过其信任的所有其他系统的安全性。BeyondCorp项目帮助谷歌基于其信任的计算平台,明确定义并施行访问决策,将安全策略从保护服务转变为保护可信平台。此前发表的BeyondCorp系列论文中,详细讨论了谷歌对设备“正本清源”所使用的各类工具,但尚未深入探讨建立设备信任的机制。


       我们如此关注计算平台的安全性是有据可依的,业内大量证据已经表明[1],终端用户已经成为各类攻击的首要目标,并且其攻击手段层出不穷。攻击者通过设计巧妙的社会工程学攻击,将恶意代码安装到设备上,随后即可利用现代操作系统的大量攻击面发起攻击。高级攻击者目的在于利用设备固有的信任、设备的身份凭证、或者已授予用户的信任来进一步利用系统。


       为了成功防止这种持续的在可信内容(企业Web应用程序、企业凭证)和不可信内容(外部软件库、社交媒体、个人电子邮件等)的混合环境中可能遭受的破坏,平台自身必须具有层次化的、一致的若干控制措施,最终,作为设备机群(fleet)的构成要素,计算平台就成为了新边界。


基于前期工作展开


       本文描述的工作内容主要基于白皮书“大规模设备机群管理”[2]和之前发表的5篇BeyondCorp论文[3]。在这些前期工作的基础上,我们的目标是通过以下方式进一步增强BeyondCorp模型:


       1、从通用的控制视角来定义健康设备机群;

       2、确保始终如一地全面应用和衡量这些控制措施,并强制执行;

       3、基于持续度量推动控制措施的闭环改进。


定义待保护环境面临的威胁


       与其他安全防护工作类似,我们首先必须定义待保护环境所面临的威胁。在创建威胁列表时,需要考虑一类攻击而不是各种可能的单一攻击向量。攻击者会持续发现新的攻击向量,这意味着很难穷举环境可能面临的所有威胁。但是,如果成功减少了某一类攻击,即可减少对这一类威胁中的多数攻击向量[4]


       从一个较高的层面来看,平台应该考虑的威胁类别包括:


       1、未知设备:由未知的或非受控设备对敏感系统发起的访问;

       2、平台失陷:利用计算平台上操作系统或软件的错误配置;

       3、安全控制旁路:未生效或错误配置的安全策略导致的系统失陷;

       4、非法提权:通过代码的执行导致系统特权被接管,且持续控制;

       5、软件失陷:恶意软件安装和持续存在;

       6、 持续攻击:由于缺乏检测而导致攻击者长期攻击;

       7、 认证旁路:通过被盗密码或绕过认证机制,造成平台失陷;

       8、 数据泄漏:对磁盘、内存或传输中的敏感数据发起未授权访问;

       9、 攻击隐蔽:由于缺乏日志和监控手段导致攻击者长期持续存在;

       10、攻击抵赖:攻击者通过掩盖其攻击痕迹而妨碍取证分析。


通过改善设备机群健康来解决环境威胁


       定义威胁后,就可以更好地识别出缓解这些威胁所需的控制措施。并且进一步在服务访问时对这些控制措施的状态进行度量(有效性、是否开启等)。表1列出了上述各种威胁类别对应的控制措施,对一个理想的可信平台来说,这些措施是必不可少的。


图片

表1 威胁种类和潜在缓解机制


健康设备的特征


       健康的设备机群由健康的设备组成,这些设备的健康由工具、流程和设备健康维护团队提供保障。设备如满足以下条件,即可认为是健康的:


  • 可以承受大部分攻击;

  • 提供了足够的检测和度量能力,在出现问题时能及时止损。


       下面我们将深入研究,为什么这些控制手段至关重要。


       设备机群清单库和资产管理


       硬件是操作系统和应用程序运行的基础。通过限制硬件配置的差异性,可以更有效地判断出设备机群中设备的能力和不足。设备清单系统通过设备访问开通机制,为可访问敏感系统的设备范围进行了明确界定。


       操作系统&软件配置管理


       软件管理是保证设备机群健康的关键组件。一个集中式的软件管理基础设施有利于保证平台配置的一致性,以确保可信平台满足以下条件:


       默认是安全的,并且随着时间的推移仍能保持最小偏离;

能持续地进行安全的升级。


       为正在运行的操作系统、敏感的软件栈和安全代理打补丁的能力对于健康的安全态势至关重要,软件配置的管理也同样不可或缺(如软件自动更新策略)。


       安全策略强制执行


       可信平台应始终如一执行安全策略,并且报告和记录与预期策略之间的偏差。安全策略通常与上面提到的操作系统管理和配置策略交织在一起,但安全策略是独一无二的,是用户无法规避的强制访问控制策略。例如,通过同时登录限制策略可以减少横向移动的威胁;默认禁用root权限,有助于缓解恶意进程可能造成的危害。


       防止系统接管


       通过叠加防护层,确保恶意软件无法破坏系统的安全性。在高级恶意软件屏蔽掉主机日志子系统之前,确保主机可以报告异常行为。


       软件完整性及控制


       可以限制未授权代码在平台上执行。常用策略包括,仅允许已知的“好”软件运行,明确阻止可疑“坏”软件运行。我们通常会选择白名单策略,因为明确定义出工作所需的所有应用程序是可行的,但需要阻止的所有潜在坏人或恶意软件却无穷无尽,无法枚举出来。


       可远程验证平台的状态


       平台应具备基于密码学的完整性验证机制,在底层平台上提供从固件到运行的操作系统的完整性保证。可行的机制包括:第一命令执行控制[5]、安全启动和远程验证。


       平台和用户的可靠认证


在尽可能的情况下,用户账密信息存储应使用系统上的硬件支持或硬件隔离。Windows Defender Credential Guard[6]就是一个很好的例子。


       数据保护


       我们假设每位用户的系统都有一些敏感数据,因此敏感数据在存储和传输过程中都应该被加密。为了应对设备丢失或被盗的情况,设备应支持远程数据擦除功能,可以销毁一切存储在系统上的数据和长期凭据。


       基于日志记录和日志收集进行威胁检测


       为了提供纵深防御,平台威胁模型应该假设攻击者能够绕过预设控制措施并且设备存在攻破的可能性。为了缓解此类风险,平台需记录这类事件。日志应该记录发起操作的用户和设备的相关属性,对所有敏感数据的访问或修改,包括对平台安全控制机制、状态和行为的更改都应该详细记录。这些信息应该输出到一个集中式日志记录工具,理想的日志记录策略必须能够阻止未授权进程对其篡改。


       平台响应能力/检测和响应


       如果检测到威胁,平台应该提供有效手段,让得到授权的入侵分析师可以进行远程事件响应。诸如GRR之类的工具可以提供远程访问能力来执行这类分析[7]。人工检测工作应尽可能保持在最低限度,因为它无法规模化地应对广泛的攻击行为。理想情况下,授权分析师应该能够创建用于调查取证的有效时间线,可以从受影响系统中一次性的拉取数据来进一步调查,通过复现事件,检测和响应团队可以全面了解发生的情况并做出相应的响应。


维护健康的设备机群

       

       具有上述控制特征的一组客户端设备构成了一般意义上健康安全的设备机群。为了达到这个状态,首先要弄清楚如何一步一步地建立平台信任。


       建立信任


       敏感的服务只能通过可信设备访问,我们为系统信任划分等级,基于特征和行为,设备能够获得不同的信任等级[8]。


       然而,这种方法带来了“鸡生蛋蛋生鸡”的问题:将设备转化为可信状态,需要首先访问客户端软件库,而客户端软件库本身就是一个敏感系统。为了解决这个问题,在设备从不可信到可信的迁移过程中引入了“已识别”状态。状态为“已识别”的设备是指那些清单库认为信誉良好但由于某种原因还未取得信任的设备。可以允许这些设备访问客户端软件库的某个子集,以便安装补救软件。补救软件使得机器能够报告设备状态、下载和安装所需补丁,并采取所有必要步骤来满足对于可信平台的要求。


       随着健康设备机群构建工作的开展,就会更加了解自身环境,就会更有信心地开通访问权限。另一个挑战就是需要确保技术和业务的不断演化过程中,信任能够持续得到保证。下文将讨论随着技术和业务的演进如何保持设备机群良好的健康状态,以及如何在健康状况恶化时迅速纠正。


       对抗设备熵


       一旦设备发放到用户手中,其安全性会逐步减弱,因为随着时间推移,安全性难以避免的会衰减。在对抗设备熵的过程中,我们发现了一些有用的策略。


       第一条策略,也是最强大的策略,即将访问决策与清单系统集成。在获得授权内部资源的访问权限前,所有的设备都应在列且被信任。对机群的每一台设备,在接收和镜像的过程中,确保其信息都添加到公司清单库。对于任何上报为失踪、被盗或丢失的设备,应立即删除其访问权限。为了保证用户能及时报告设备丢失或被盗,要求用户必须在收到新的替换设备之前进行主动报告。


       对访问环境的任何设备状态变化采用严密的监测和度量手段非常重要。Facebook的OSQuery[9]是一个优秀的开源监测工具,适用于Linux、OS X和Windows系统:它可以监测设备属性,如设备的操作系统版本、关键软件的补丁级别和加密状态。


       另外,补丁和配置管理工具[10]能够改变设备的状态,将不可信的设备转换为可信的设备。BeyondCorp通过限制用户访问的方式,强制用户进行某些必要操作,例如重新启动或接受更新。


       检测不健康的主机


       在主机的整个生命周期中,某些操作或不作为都可能会导致设备转变到不健康状态。信任推断引擎[11]通过持续信任评估来检测设备状态变化。当设备不能满足信任标准,则将设备的信任状态降低为“已识别”,通知机器的所有者并为其提供设备的修复指导。


       检测与响应团队可以为信任决策提供额外的信息,这个团队有权删除对任何恶意设备的信任。


       提供灵活的策略


       乍看起来,设备机群健康状况的定义是一项简单的任务。但是,和大多数IT环境一样,魔鬼总是隐藏于细节(和例外)之中。在处理大量不同的操作系统和各种用例时,会遇到许多这样的细节问题。


       为设备机群上线控制措施时,我们会尝试为策略的合规性设置一些阈值,而不是一上来就提出绝对严格的要求。这种策略允许用户在良好的状态下更灵活地运作,并能避免使用会让用户崩溃的严格规则集(这会导致用户寻求规避手段)。例如,如果用户需要安装非关键补丁,我们会在降低其访问权限前给予一个宽限期。


       同时,通过一些防范控制措施为事件监测和响应功能提供信号也非常重要。为此,我们努力将这些控制措施集成到安全信息和事件管理管道中,以便可以报告和记录策略相关数据。捕获访问有关的数据可以帮助后续的调查取证和事件检测,这些数据可能包括什么时候允许访问,以及根据策略,什么时候对访问进行了拒绝。


试点并推广这些原则


       这是一个典型的由安全团队及其合作伙伴主导的项目,从开发到上线,始于设计和原型阶段,小规模测试,从设备机群和用户那儿搜集反馈并逐步完善。我们逐渐达成一项策略,即首先在监控模式下推出控制措施并建立内部试用团队(Dogfood)[12]以方便调试。例如,我们可能会推送一个新的USB审计代理到部分硬件工程师组织,因为这部分人员经常与自定义USB组件交互。通过这种方式,发现在大样本量的情况下,边缘情况并不会集中涌现。还有种方案,按照地理位置来划分内部测试,当然必须在变更实施前准备好本地支持人员。


       在新控制措施上线时,清晰的沟通有助于了解新政策及其存在的原因。将每个控制措施映射到它所解决的威胁可以帮助每个人理解安全团队选择特定操作的原因。高度透明和对标准的清晰解释帮助我们加深了与用户间的理解,建立了与干系人的共识。当他们看到我们并没有任何隐藏的目标或动机时,就会充分参与到这一愿景及目标的规划中。一般来说,负责这种安全驱动的变革团队可以从清晰的全局目标阐述中受益,使得每项行动师出有名,更有利于争取到合作伙伴团队的支持,这种支持会形成一个良性循环,为“如何使设备机群更安全”带来更好的闭环。


平台度量和一致性控制


       一旦定义了预期效果的基线,会发现某些控制措施无法普遍应用,因为无论是设备本身还是管理/策略层面,平台的能力都参差不齐(有时甚至能力差别很大)。例如,Chrome操作系统的Secure Access提供了可靠的软件控制,但是Linux却没有开箱即用的防恶意软件的能力。为了确保整个设备机群获得一致的安全性,需要对安全评估进行规范和统一。虽然希望在不同平台上100%实现完全相同的控制效果是不可能的(因为平台能力和威胁模型不同),但也并非绝对,对于所有需要实施的控制,可以将评估标准统一为“对安全风险是否有效”。


       为了完成统一评估,分析了所有相关平台目前在满足控制效果方面的现状。然后,评估了现状和理想差距的总体情况。为谷歌管理的每个平台都创建了总体设备机群健康报告——这不是“成绩单”,而是对其能力的分析材料。针对每个平台,都需评估以下方面:


  • 平台是否能够支持控制措施?

  • 控制措施是否默认开启?

  • 控制措施的状态是否可以度量?

  • 设备机群是否合规?


       要推动各项目标的可度量行和可比较性,可能需要考虑:


  • 将这些策略统一到标准的度量单位中:如,自补丁发布以来的时间,地理位置,数量等;

  • 从相对量的角度来推动度量的标准化:如,和当前版本的偏离量、功能特性的实现比例等。

       难点在于如何设置这些评估标准。一旦拥有了各平台的可比较的度量标准,探讨设备机群健康状况的能力将大大提高。


       当防护控制措施无法生效或者仅部分生效时,可以寻找其他的方式来消除风险,例如,更全面的监控/检测在某些平台下可以作为防护控制措施的补偿。这种评估方式可能看起来有点主观,有点依赖于对平台抵御攻击能力的整体感觉。现代操作系统有非常复杂的攻击面、能力和威胁模型;我们发现聚合所有这些信息的最佳方式,仍然要采用手动比较设备所需特性与实际具备的特性。这种比较允许我们能够围绕项目提出顶层建议,以填补缺失并提高项目的优先级。无论是基于什么数据得出的结论,重点是必须记录下这些结论背后的缘由,或至少记录下产生结论的过程,这能让应急安全工程师之外的人了解设备机群的状态。


与理想情况的偏差


       尽管在定义、上线、测量和强制执行控制上,我们都做出了最大努力,但仍不可避免地需要面对这样一个严峻的现实:要部署100%统一的控制措施过于理想,这种理想也许仅存在于独角兽自由玩耍的上古神秘国度,那里没有恶意软件,没有国家级的网络攻击者。现实是残酷的,我们需要针对偏差制定计划、进行根因分析、妥善处理例外情况。


       许多偏差的发生是在所难免的,包括流程中断、管理工具故障、不稳定的版本发布或其他各类原因,都可能造成偏差。例如,为系统打上最新补丁总是会有延迟的。重要的是要了解什么时候需要对设备机群全范围内的例外情况进行处理,需要防止异常规模的增长,但不要总是通过控制措施来强硬纠偏。如果懂得如何在威胁模型和用户影响之间权衡,就不难做出正确的决策。


       例外情况应该可以被度量并且有明确的时间窗口限制。我们建议在整个设备机群范围采用一致的方式对根因进行分类,以便了解当前差距,并明确出哪些控制措施不适用于某些设备机群或某类用户。如果例外在不断更新(又或者永不过期),控制手段就会失效。这时应重新设计控制措施甚至重新审视这项控制措施在设备机群中的角色。


启动


       那么,如何将本文讨论的BeyondCorp原则应用到你的设备机群呢?一般包含以下4个步骤:


       1、定义需要重点考虑的安全控制措施;

       2、找到度量这些控制措施的方法;

       3、判断设备机群的不合规项;

       4、修改工作流,让其符合预定安全策略,或将其定义为例外。


       第一步十分关键,目的是为了确定想要实现的目标。我们不应毫无根据地开始创建安全控制,而是应该明确这些控制是针对某项威胁的具体应对机制。明确列举出威胁列表,不仅能够为度量控制的有效性提供启发,还能为梳理每个特性的优先级提供一个框架。当为这些特性进行定义和排序时,需要咨询合作伙伴的意见(详见下文“经验教训”)。当已经明确威胁及缓解这些威胁的控制措施时,就可以通过测试来评估这些控制措施的有效性,包括单元测试、端到端的红队渗透测试等。基于这些举措,可以进一步明确这些控制是否有助于在实践中达到安全目标。


       为了持续确定设备的安全态势,必须能够对其当前状态与理想状态进行监测和度量。如果尚不能实现度量,需要在设备机群安装度量监测软件来收集相关数据。不过,即便获得了原始监测数据也才只完成了一半,我们还需要定义待测量设备的理想状态。由于设备机群所包含的设备多种多样,需要定义多个理想状态,尽可能覆盖所有潜在的用例。


       一旦可以度量设备机群的安全态势,就可以开始检查设备实际状态与理想状态的偏差。一些偏差可能不会带来安全风险(因为它们可以通过补偿控制来缓解),但仍有许多偏差将会暴露风险。一开始,我们就需要确保新设备从员工使用它们的第一时间起就符合控制要求。确保所有新设备都能从一个已知的良好状态开始加入机群,这样我们就可以将注意力放在设备机群中的其他设备上来提高设备机群的整体健康状态。


       建立一个例外框架,这样在执行一个重要的新控制措施时,就可以先为现有的设备机群创建例外。此时整个设备机群的偏差将保持静止不变,于是就可以保持新设备符合要求的同时逐步修复现有设备。一旦将问题明确隔离到设备机群的例外集合中,就可以将故障原因进行分类,就能够发现整个设备机群或工作流所共有的一些问题。首先解决其中规模最大、风险最大的问题,以最小的代价获得最大的安全性。重复这样的分类及修复过程,直到已经解决了设备机群中的所有问题。如果用户的工作流与所需安全特性明显不兼容,这种情况可以作为例外特殊处理。


       虽然这个系统需要许多不同团队的大量协作和努力工作,但完成这项工作可以提升我们在面对持续攻击时的灵活性。


经验教训


       制定一个连贯的计划来衡量和评估信任和设备机群的健康状况并不是一个短期项目。完全达成本文所描述的目标(以及BeyondCorp的其他目标)需要许多重要资源。因此,希望谷歌在过去几年中学到的一些经验教训可以为读者们节省一些时间和麻烦。


       尽早设置目标里程碑


       尽早设定关键目标里程碑。确定重要资产并对它们进行(至少粗略的)排名。这样有助于有效地分配资源,并为实施大型项目提供合理的动机。将设备机群管理系统的数据整合到授权决策过程中,是一个很好的初始里程碑。仅此一项就可以防止未知设备访问关键服务,同时还能生成一份已知良好设备清单。


       确定如何处理例外


       在项目中尽早定义例外处理框架。每个设备机群中都包含那些无法完全符合理想安全状态的设备。确定例外管理的流程和技术实现是成功部署的关键。定义允许创建例外的各种场景及其理由,记录这些场景,确定允许该例外的最大时间窗口,梳理已有例外的审核过程。


       与合作伙伴互动并且尽早影响其他团队


       BeyondCorp的成功实施需要整个IT部门的配合。尽早与合作伙伴和可能受影响的团队展开合作,这样会大大提升后续实施上线的顺畅性。


       例如:


  • 设备采购和上线团队需要确保在设备加入或退出设备机群时,设备机群管理系统进行更新,保持最新状态。

  • 其他安全团队在定义设备的安全属性时可以提供有价值的输入,来自安全团队的各种输入对整个项目的价值重大。

  • 传统的IT支持团队将负责绝大多数用户升级。他们必须了解项目的目标,并能够帮助解决用户问题。


       同时,我们也需要知道如何与那些会受到影响到的用户进行沟通,确保普通用户能够真正遵循并完成自我修复过程,减少故障排除时间,减少IT负担。


结论


       保护员工设备安全是保护企业关键信息资产安全的基石。为此,我们彻底评估并定期检查所有企业设备来确保其健康状况,只有已知安全设备可以访问关键的内部系统和信息。


       员工及其设备已经引起了坏人的注意,因此我们有义务在保证其安全性的同时维持生产力。为了达成这一目标,需要强烈的设备机群健康意识,明确的策略和衡量标准,以及处理目标偏差的流程。通过一致的控制和强制执行,每个企业都可以提升设备机群的健康和安全性,提高对不断增加的各类攻击和威胁的防御能力。


致谢


       BeyondCorp仍然是谷歌当前一项大型的跨团队项目,该项目有很多贡献者,在此我们想要特别感谢赛勒斯·威苏那(Cyrus Vesuna)在协助完成定义平台通用可信控制方面的工作。


参考文献:


       [1]Executive Summary”: https://www.verizonenterprise.com/resources/reports/rp_DBIR_2018_Report_execsummary_en_xg.pdf; Mandiant, M-Trends 2018: https://www.fireeye.com/content/dam/collateral/en/mtrends-2018.pdf.

       [2] Google, “Fleet Management at Scale,” November 2017:https://services.google.com/fh/files/misc/fleet_management_at_scale_white_paper.pdf.

       [3] https://cloud.google.com/beyondcorp/#researchPapers.

       [4] New variants often stretch the common understanding of classes of attacks, so you can’t ignore variants completely. For instance, the industry thought we had a good grasp on microarchitecture security up until 2018—see Jann Horn, ProjectZero (Google), “Reading Privileged Memory with a Side-Channel,” January 3, 2018: https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html.

       [5] Such as Intel’s Boot Guard: https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/4th-gen-core-family-mobile-brief.pdf.

       [6] Microsoft’s Defender Credential Guard: https://docs.microsoft.com/enus/windows/security/identity-protection/credential-guard/credential-guard.

       [7] https://github.com/google/grr.

       [8] For a description of trust levels and calculation, see B. Osborn, J. McWilliams, B. Beyer, M. Saltonstall, “BeyondCorp: Design to Deployment at Google”: https://ai.google/research/pubs/pub44860.

       [9] https://osquery.io/.

       [10] For more on the tools we use at Google, see “Fleet Management at Scale: How Google Manages a Quarter Million Computers Securely and Efficiently”: https://ai.google/research/pubs/pub46587.

       [11] For more on the trust inference system and the other moving parts of our BeyondCorp model, see B. Osborn, J. McWilliams, B. Beyer, M. Saltonstall, “BeyondCorp: Design to Deployment at Google”: https://ai.google/research/pubs/pub44860.

       [12] Dogfood: early release of products to employees to get feedback and catch bugs before a wider release.


关注“云安全联盟CSA”公众号回复“谷歌BeyondCorp系列论文”,可下载该系列论文合集。


图片

转自于微信公众号-云安全联盟CSA


云深互联

        深互联, 取名自古诗:“只在此山中,云深不知处”,旨在通过新一代SDP(软件定义边界)网络隐身技术,使应用程序“隐身”于互联网之中,只对授权用户可见,让黑客无从发起攻击,从而有效保护企业数据资产,让每一家企业数据安全上云,实现高效地互联互通。云深互联成立于2012年,已经成功服务不同行业的500强企业及政府单位,覆盖金融 、能源 、交通 、制造 、地产 、教育、零售等领域。成功获得晨兴资本、IDG资本、达晨创投等一系列知名投资机构数亿元融资。

图片


分享到:

深云SDP

零信任SDP专业平台

立即试用

立即试用