卡内基梅隆大学报告《迁移到云中面临的风险，威胁和漏洞概述》笔记

前阵子看到NUKE在大群分享2019年卡内基-梅隆大学软件工程学院的一篇研究报告《迁移到云中面临的风险，威胁和漏洞概述》，针对这个报告做了些翻译和笔记，权当做知识储备。

这个报告是他们帮美国国防部DOD对美国三大云服务商（CSP）：AWS、Azure和GoogleCloud做的安全评估调查的结果，当然也提到了一些其他的云服务商的情况。报告重点讲迁移到云后可能存在的安全风险和漏洞。当然，是比较高层次的问题了。

首先是这份报告的风险管理流程评估方法参考了欧洲网络和信息安全局ENISA在2012年的一篇论文《云计算：信息安全的利益、风险和建议》中的方法，对每个风险和漏洞用四段论来描述：简要说明、威胁概率和影响图、基于漏洞的威胁示例、减缓建议（个人更愿意理解为响应手段COA）。

整个评估结果看下来，简而言之一个原则：不要过于信任你的云服务提供商CSP。

因为内容较多，我一个一个拆着看，有不少内容并不一定是原文，而是加了我的一些理解和想法。如有不正确之处，还请拍砖。

下图，是报告开篇介绍的一个经典的云和传统数据中心混合的IT计算环境场景图。

下面进入正题。

一、上云降低了可见性和控制力

1、简要说明

研究者基于调研结果，认为：在将资产和对应的运营迁移到CSP提供的云上后，组织就会失去对这些资产和运营活动的部分可见性和控制权。因为，一些策略和基础架构的责任会随之转移到CSP身上。而实际的责任转移取决于使用的云服务模型是SaaS、PaaS还是IaaS，也导致组织在安全监控和日志记录方面的范式要做相应的改变：包括需要加强对应用、服务、数据、用户信息的监控与日志分析，而网络侧的监控则也会变得成本更高。

从调研结果来看，组织只能通过SLA来约束CSP，而CSP是否愿意在SLA之外提供更多的监控能力和原始数据/元数据输出，则是看CSP自己是否愿意。部分顶级云服务商会提供这类的数据和监控能力，但是很难与传统数据中心的IT设施集成复用，且综合成本实际远大于传统数据中心（因为云所特有的收费模式）。

2、威胁概率和影响

从评估来看，从IaaS—PaaS—SaaS，此类风险的威胁概率逐步升高，意味着失去的可见性和控制力越多。但是从影响来看，任何云服务模式都是一样的，这也是云环境的特性之一。

3、威胁示例

以某云为例，虽然只提供IaaS和PaaS服务，但在SLA中没有对应的监控能力和原始数据/元数据输出条款，从而导致上云之后，很可能用户无法进行有效的监控，丧失可见性和控制力。即使勉强开放获得，无论短期还是长期来看的综合成本也会高于数据中心侧。

4、COA

需要求CSP针对不同的云服务模式提供对应的基础服务记录/监控能力和可见性输出能力。例如：

CSP需提供服务，记录所有对应的云上用户操作并主动监控日志和预警。
CSP需提供服务，记录所有数据访问行为并主动监控日志和预警。
CSP需提供服务，记录所有API接口调用并主动监控日志和预警。
CSP需将基础设施类比视为源代码，实施适当的变更控制程序，定期检查更改，并及时告知用户。
CSP需做好配置管理访问控制，以防止或监测未经授权的更改，同时，将这类底层能力以服务形式反馈给用户。
CSP需做好自身的安全监控和运营工作，并为用户提供对应的服务反馈。
CSP需根据不同的云服务模式，将对应的安全监控功能开放给对应的用户，供其使用。
CSP需建立可视化、可配置的告警机制，让用户可自定义用户操作、数据访问和API调用的异常监测告警。
CSP需用堡垒机等手段来执行强制访问控制，同时开放给用户，为其提供可见性。

二、按需自助服务简化了未经授权使用的难度

1、简要说明

云的按需自助服务配置功能，可使组织人员绕过数据中心和办公网络的已有管控措施，未经授权使用额外的服务，在这份报告中，研究人员将这个叫做影子IT。

尤其是PaaS和SaaS服务模式下，未经授权使用云服务的可能性增加。在没有安全管控和IT管控、运维监管的情况下，云服务商在SLA范围内给于用户的极大自主权，会给组织带来风险。从而导致恶意软件感染和数据泄露事件的增加，因为组织无法保护其不了解的资源，也无法看到被刻意隐藏的云上资源，无论是网络，还是数据。

2、威胁概率和影响

于上一条一样，从IaaS—PaaS—SaaS，此类风险的威胁概率逐步升高，而影响则是一致性的。

3、威胁示例

例如某员工在内部云共享VPC获取资源后，自行搭建的服务器未作防护，导致中了挖矿木马，而共享VPC的云上特性，直接导致攻击者控制一台云主机后，可以此为跳板攻击所有其他VPC内的云主机。而往往基于信任原则，VPC内的云主机相互间都是高信任度的，甚至许多云主机部署时压根没有考虑，或者有意调低安全管控措施，以方便业务和开发使用。

再例如，一个使用IaaS的组织，DevOps团队的一名程序员，有可能基于对新的工具的兴趣，在采购前或不熟悉的情况下，直接在云上资源中配置和安装试用版的工具，并可能从数据中心的开发、测试区域复制数据和代码，以对工具做测试和评估。这时候，工具是否可靠，工具是否有后门或漏洞，都无法追踪和得到有效监控。

4、COA

1）需要配置细粒度较高的组织安全策略，考虑各种情况下禁止非指定人员自行配置未经授权的云服务。对类似的动作进行全面监控和告警。

2）需CSP提供服务和能力，确保用户请求访问云服务时，能做到根据具体情况进行高细粒度的访问权限授权，甚至可以将对云服务的访问强制默认不允许，必要时单独授予例外。

3）需CSP在SLA中明确，并有流程和技术手段确保非指定IT代表，不给其他用户开放权限或提供服务。

4）需CSP提供服务监控日志记录和告警能力，以实现对所有新的服务配置都能产生与用户强关联的日志记录和告警。

5）需CSP提供服务能力，实现基于角色的访问控制RBAC能力来控制对服务的访问，并有窗口可定期审查角色，以及对新添加角色和角色越权行为进行监控和告警。

6）需CSP配合组织建立标准的配置基线，对组织既定基线外的CSP配置资源访问动作进行识别、记录和告警。

7）需CSP提供云访问安全代理应用程序CASB，帮助组织检测安全策略违规行为，例如自行配置和数据泄露。这类能力只能由CSP才能提供。

8）无论哪种云服务模式，都需CSP提供全面的数据传输/存储加密、流向追踪和数据丢失保护等基础数据安全能力，并开放给组织侧进行技术和策略控制。

三、管理API的暴露与失陷

1、简要说明

对于CSP而言，由于对外提供公共服务，必然会将其管理API公开，以方便用户用这些API来管理云服务并与之交互，也就是我们说的管理平面。且不论这些API可能包含与操作系统、数据库等API相同的安全漏洞的问题，仅这个API是公开的，甚至是可以通过外部网络访问的，就必然会暴露在外，极易找到且便于攻击者进行研究。而数据中心的管理API则不同，是在内不对外公开的，攻击者要拿下这些API，需要更多、更麻烦的操作和寻找。

而且，这种暴露和影响，基于云特性下，是会关联到其他CSP客户的。

2、威胁概率和影响

从IaaS—PaaS—SaaS，此类风险的威胁概率逐步升高，但其威胁的影响反而是下降的。因为越是底层，管理平面暴露和失陷造成的后果越大。

3、威胁示例

无论是哪家CSP，云管理平面在自己内部都是同一套，极少出现针对不同客户提供不同的管理API的。依稀记得是15年左右，某云曾经出过类似的案例，管理API的越权漏洞被恶意利用，导致多个云上客户的数据丢失。还有道听途说是某工业云，也曾因为公有云环境的云管平台API暴露问题，导致线下私有化部署的一些工业私有云平台的工控系统因同样的漏洞被攻击。

4、COA

1）CSP需自己参考业内的最佳实践，确保自身的S-SDLC足够健壮和全面。

2）CSP需提供和确保能记录和监控所有管理API的所有访问和操作，即对整个管理平面的全面监控，并需开放给对应的用户。

3）在授予访问管理API的服务、应用程序和用户授权时，必须实施最小特权原则，并做定期检查和变更提醒。

4）使用RBAC控制对服务的访问，定期检查角色，记录角色的所有动作，并设置相应的监控告警和变更提醒。

5）CSP需确保使用用户级权限配置服务和应用程序。

6）CSP需将根一级的功能移动到角色层面，做好监控，记录和分析其用途，并做行为分析与跟踪。

7）CSP需具备自动化的服务计费检查能力，以侧面确定和反映正在使用的服务是否正常。

8）确保访问组织网络所需的凭据与用户访问管理API所需的凭据是不一样的，不能图省事用同一个。

四、云上多个租户下，失败的逻辑隔离

1、简要说明

CSP无论使用哪种云基础架构，平台自身或支持多租户的相关底层应用，都可能存在已知或未被发现的系统/软件漏洞，一旦被利用，极可能导致逻辑隔离变成空谈。一旦逻辑隔离失效，多租户只会给攻击者带来更大的便利性，因为攻击面比单租户更大。此外，混合云模式下，可能还会连带影响云下的私有云和传统数据中心。

SaaS服务模式下，这类攻击较为常见，也有不少类似的报告。IaaS和PaaS模式较少见，但也不是没有。虽然没有成功的攻击报告。但是，从2009年起第一个此类漏洞的验证报告提交至AWS之后，到18年1月的英特尔、AMD和ARM处理器设计漏洞，以及Project Zero报告的四个带概念验证POC的漏洞报告，都证实了云平台确实可能存在漏洞，致使攻击者可在一定条件下跨逻辑隔离边界进行数据访问，或直接导致逻辑隔离失效。

2、威胁概率和影响

从IaaS—PaaS—SaaS，此类风险的威胁概率逐步升高，而影响则是一致性的。

3、威胁示例

报告中举了几个例子，第一个是攻击者利用被盗的凭证执行缓存侧的侧信道攻击，以通过共享CPU缓存从组织获取敏感数据。这类问题据说在一些老架构的CSP的产品中仍然存在。

其他几个例子则是通过获取高权限的账户（没说怎么获取，总有办法和机会的），例如VM配置权限账户、容器管理员、数据库管理员账户（嗯，总会有人暴露的），在通过已知的漏洞，将恶意代码放入CSP计算平台，或是给虚拟机加载带有恶意代码的版本，或是找到虚拟机管理程序的漏洞，以实现横向扩展。虽然没太理解意思，总感觉这说的就是云上虚拟机逃逸技术。

4、COA

1）需CSP对虚拟机逃逸技术的防护有深入的研究，并由相应的解决方案

2）需CSP及时跟进虚拟机管理程序的漏洞，并通过测试、代码检查等方式，确定自身使用方法和定制开发的代码不会存在可被利用的漏洞。

3）需CSP提供对所有数据访问流向（不仅南北，还有东西）的记录和监控，并能设定正向、反向的规则模型做实时/准实时的监测告警和变更提醒。

4）使用堡垒机来限制访问，实施强制访问控制并为用户提供对应的可见性。

5）需CSP确保数据在传输和存储过程中全程加密，并为自己和用户都提供KMS功能。

6）审查CSP的供应链安全，采用的底层开源组件、框架和其他基础设施在设计之初是否有做足够的安全考量，并在使用过程和供应服务中是否有足够可信的安全实践，例如S-SDLC、定期的安全风险评估等。

五、不完整的数据清除

1、简要说明

纵观CSP的云服务，目前普遍存在一个较大的安全风险，就是与数据清除相关的威胁。因为用户对其数据再云中物理存储的位置缺乏可见性和控制力，也没有太多的办法对其数据删除操作后物理存储位置是否也真的、有效的、及时的做了删除进行验证。而在多租户环境下风险更大，因为数据会分布在CSP基础设施的不同物理位置的不同存储设备中。

而现状是数据删除机制和程序各个CSP都不一样，有做的好一些的，也有完全不透明的，还有压根说不清楚的。但普遍的是，CSP都不会给使用者一个验证机制来验证这个问题，甚至有意回避这个问题。CSP仅仅能做的，就是在SLA中做出承诺，但没人能对这个承诺做出取证判断。

此外，即使是做得比较好的CSP，数据删除是否删干净了，以及数据删除是否及时，也是绕不开的两个坎。依稀记得AWS还是哪家云大厂曾经出过一个测试报告，但那是在理想环境下的单一测试，并不代表真实复杂环境下也能达到理想效果。

2、威胁概率和影响

虽然从从IaaS—PaaS—SaaS，此类风险的威胁概率逐步升高，但从概率分布而言，三类服务模式的概率差距不大，这是与其他风险不太一样的地方。而从影响来看，云的特性导致此类威胁的影响是一致性的。

3、威胁示例

曾听人曾说过，云的基础设施实际经常会因断电、断网或其他种种原因脱机或故障，但是很多这类故障和问题，对上层的客户和应用是无感的。然而，当这个时候应用或客户要删除数据时，实际这些数据并没有像想象的那样删掉了。在CSP飞速发展的那几年中，几乎所有换下来的物理机器上面，都有着大量的残余数据，且找不到属主。虽然有相应的解决方案，但是出于成本考量，CSP大多不会全面采用，而只是部分采用，甚至只是做个样子应付监管和评估。而在美国，就在前几年记得有过数起因此引发的法律诉讼案例。

4、COA

这个方面用户没有太多的主导权和办法，只能靠CSP的自觉，包括：

CSP需指定与数据删除相关的策略和SLA，明确其有效、及时删除数据的技术机制和流程，用户要做相应的评估。
CSP需提供合理的数据恢复政策和数据复制策略，以侧面验证其数据删除机制的有效性。
CSP需提供清理磁盘的策略、技术机制和流程，并尽量接受用户的不定期抽查。
CSP需加密所有存储的数据，确保数据残留不可读，即加密擦除。但是，这个靠自觉。
CSP需具备技术手段，做到实时/准实时监控和掌握所有客户数据的存储和使用位置，并可基于特定数据进行跟踪。
CSP需提供使用和存储数据的详细说明，使用户可以明确删除数据操作的节点、位置和操作方法。
CSP需限制对数据备份、磁盘清理和基础设施下线/利旧等的操作和访问权限，并对其操作做全程记录和监控告警。

以上是迁移到云上的主要风险。接下来是云和内部部署的威胁与风险，即组织需要解决的云和传统数据中心混合时的可能风险。

六、被盗证书

1、简要说明

这个风险基于一个假定前提：攻击者获得了组织用户的云凭据访问权限。在这个前提下，攻击者可以访问CSP的服务以配置其他资源或是直接定位组织的资产，只要云凭据允许他/她访问相关配置。而如果是获得CSP管理员的云凭据访问权限，则可以访问所有云上各个组织的系统和数据。

这个威胁实际上算是极小概率事件，不过传说国内某云有发现过此类风险路径的可行性，我估计报告既然给DOD做的，类似问题估计也有发现。

2、威胁概率与影响

从威胁概率与影响来看，无论哪种模式的云，威胁可能性都是一样，但是根据被获取的云凭据的归属权限不同，可能会造成不一样的影响。具体可见下图。

3、威胁示例

除了上面说的例子，报告中列举了另一个例子，就是当攻击者知道目标组织使用某家CSP服务的时候，可能会通过针对该组织的IT员工、外部服务商等的钓鱼，进入其邮件或账户，再针对性找到具备高权限账户权限的员工。这个示例比较烂大街。

不过真实案例中，听说过有攻击团队特意针对某些目标组织，在网络上收集经常在外做与云和数据中心的开发、运维相关的技术分享的人，获取到对应的微信账号、邮箱号、手机号，再做针对性的钓鱼，或是直接用无间道形式踩点。只能说有各种想不到的操作。

4、COA

1）愿花钱的话，建议组织为自己的云用户账号启用多重身份认证。

2）CSP需提供多样的访问控制手段来实现CSP管理员的最小特权和职责分离原则。

3）组织需使用CSP提供必要的加密手段来实现传输和存储数据加密。例如同态加密。

4）CSP需提供服务监控所有用户操作和数据访问的日志记录和告警能力。

5）建议建立和使用系统化的安全密钥管理流程，CSP最好能提供相应的KMS服务。

6）CSP需将根一级的功能移动到角色层面，做好监控，记录和分析其用途，并做行为分析与跟踪。

可以看到，这些COA大多与上面的建议类似。

七、供应商绑定使得向其他CSP迁移变得更加复杂

这个风险的话，个人绝对意义不大，所以就不详细说，核心的意思是，万一用的这家CSP有重大问题，要做迁移的话，金钱、时间和人力成本绝对高昂到吓死你。印象中，美国政府就吃过这个亏，所以这次DOD采购微软云，也是综合考虑了CSP企业的综合实力做出的考量。题外话，本人最近对此有切身体会。

八、IT运营的复杂性大幅提升

1、简要说明

云和传统数据中心混合的模式，给IT运营带来更大的复杂性工作：一是IT员工需学习和适应新的混合架构，其中的集成、运维、安全都有很多新的挑战；二是IT人员需承担更多的工作职责，并要具备一定的管理能力；三是资产、数据迁移和维护所需的技能水平大幅提升了，对人的技术栈要求更全面。

此外，报告特别提到了密钥管理和加密服务、运维和安全监控服务的复杂性提升问题。因为CSP在这块的能力不一，且底层架构也各不一样，相关服务、技术和工具不一定和传统数据中心使用的能做好兼容和统一化管理。还有就是安全漏洞，按报告说法，迁移到云上，实际意味着需要兼顾的安全漏洞可能会随着整体架构的复杂度进一步增加、诱发和集中爆发。

2、威胁概率和影响

3、威胁示例

由于是公开报告，在这块的示例都说的很简单。不过因为是帮DOD出的报告，所以里面说的需要大量培训，需要采购第三方工具做监控和管理，没有足够的资源和人力来维护，云上基础设施导致资产和应用关系不够直观，以及云上和云下资源的兼容和统筹管理等等问题，估计也是DOD目前已经碰到过的问题。

4、COA

针对这个没有太好的COA措施，报告里面重点提的就是以下几点：

CSP需要提供完整的、准确的配置管理工具功能说明文档，供组织相关人员进行评估。
CSP需和组织一同对相关人员进行培训。
组织需要考虑自身系统和业务应用如何做到较低成本、方便的重新配置与维护，即架构解耦、可扩展性、可替换性、兼容性等方面要重点考量。

CSP需配合组织将现有的安全策略和监控能力与CSP提供的对应策略和能力进行映射，并考虑如何补全。

九、内部威胁

1、简要描述

与字面意思不同的是，报告在这个篇幅着重讲的是应对内部威胁时，云+数据中心混合模式的调查取证会更加复杂，甚至无法进行。传统数据中心所有数据、基础设施和人都是可控的，在调查取证时不会受到制约。而云的特性导致，这种调查取证在云上几乎不可能实现：因为CSP无法提供其中一些关键的功能，例如磁盘上的原始数据取证、原始流量取证。

这个问题，貌似也是目前公安取证界的一个难点，不过我了解的不深。估计大多取证只能基于某个时间段某个主机归谁注册使用了来判断。流量和数据都只能靠对端，而不能靠云端，甚至只能靠黑对应的云主机来做。

2、威胁概率和影响

3、威胁示例

报告里面举了一个很惊悚的例子，就是CSP管理员打算出售云上敏感信息来赚黑钱，可以直接窃取，也可以安插木马和后门，而不一定会需要管理员权限，也不一定会有日志记录。个人估计，这个案例可能是有真实背景的。

4、COA

主要的COA建议与前面很多是重合的，姑且一看：

1）云用户账户启用多重身份认证。

2）CSP需提供多样的访问控制手段来实现CSP管理员的最小特权和职责分离原则。

3）组织需使用CSP提供必要的加密手段来实现传输和存储数据加密。例如同态加密。

4）CSP需提供服务监控所有用户操作和数据访问的日志记录和告警能力。

5）CSP需将根一级的功能移动到角色层面，做好监控，记录和分析其用途，并做行为分析与跟踪。 6）CSP需将基础设施类比视为源代码，实施适当的变更控制程序，定期检查更改，并及时告知用户。

后面几个都是一些通用性的，我就简单过一下。

十、数据丢失

简单说起来，就是云上的数据的灾备问题。这里除了我们常提到的火灾、地震等物理不可抗力导致的物理机器损坏外，还提到一点，如果在云端，加密密钥丢失了的话，数据也等同于丢失了。此外，CSP的数据存储模式如果不公开的话，也可能因为信息不对等导致数据对视。而CSP如果被收购，或者倒闭，或是改变服务模式，也有类似的问题存在。而在示例中，报告提到CSP遭到广泛的磁盘损坏，而且很多CSP宣传的多地备份，实际并不是真的，备份是在，但是无法读取。相应的COA建议，集中在对CSP的SLA中的RTO和BCP/DRP措施进行考察和测试，并需要培训和演练来让组织人员熟悉。

十一、供应链攻击

这个指的是，CSP可能会将自己的部分基础设施、产品或运维工作交给第三方供应商。但是这些第三方供应商可能无法满足/支持组织的供应商要求，包括合规性、技术实力、安全能力、运维能力和抗商业风险能力。越是使用单个CSP，这类风险可能越大。而多CSP的话，也需要有一支供应链调查团队来支撑这块的工作。

在示例中，就提到了芯片、网络设备隐藏的后门。行内人都知道，这些案例很多不是空穴来风。

相应COA措施中，因为美国DOD和政府在这块管控较严，因此是建议做CSP供应商审查，要求其遵守与CSP一样的安全最佳实践，并审查是否符合FAR法规中提到的NIST SP 800-171规范标准。

十二、尽职调查不足

报告中说的比较晦涩，按我理解，实际意思就是不能随随便便就决定迁移到云，需要启动完整的尽职调查，包括各方面的安全风险评估、安全控制措施落地情况、合规情况、共享责任模型、SLA及实际落地情况、定价和技术支持结构、基础架构、运营机制、过往安全事件、偿付能力、供应商情况、人员技术能力、人员稳定性等等。至于COA建议这块，报告没说太多。不过在今年DOD另外两篇文档和国会证词中，几个负责人都提到，尽职调查这块最好是聘请专业的外部咨询机构，尤其是云方面的第三方专家来做评估。个人表示，深以为然。

至此，全篇报告正文大致内容结束。最后的摘要和一致性建议基本与前面所说的大同小异，就不再多说。

最后附上附录，报告根据NIST SP 800-53 Rev4给出的安全控制类别映射（到云上）的建议清单（机翻版本）。

附录：安全控制类别映射（到云上）的建议清单下载

另附上报告中部分的参考书目：

Boyens, Jon; Paulse, Celia; Moorthy, Rama; & Bartol, Nadya. NIST Special Publication 800-161, Supply Chain Risk Management Practices for Federal Information Systems and Organizations. NIST. April 2015.
Cancila, Mindy; Toombs, Douglas; Waite, Alan, & Khnaser, Elias. 2017 Planning Guide for Cloud Computing. Gartner. 2016.
Centrify. Six Best Practices for Securing Amazon Web Services. 2016
European Network and Information Security Agency (ENISA). Cloud Computing: Benefits, risks and recommendations for information security. 2012. https://resilience.enisa.europa.eu/cloud-security-and-resilience/publications/cloud-computing-benefits-risks-and-recommendations-for-information-security
Gordon, Adam. The Official (ISC)2 Guide to the CCSP CBK, 2nd Edition. John Wiley & Sons, Inc. 2016. https://www.wiley.com/WileyCDA/WileyTitle/productCd-1119276748,miniSiteCdSYBEX.html
Heiser, Jay. Everything You Know About SaaS Security Is Wrong. Gartner. 2016. https://www.gartner.com/doc/3339317/everything-know-saas-security-wrong
Horn, Jann, “Reading privileged memory with a side-channel,” Google Project Zero, January 2018. https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-withside.html
Khnaser, Elias. Designing a Public Cloud Exit Strategy. Gartner. 2017. https://www.gartner.com/doc/3564517/designing-public-cloud-exit-strategy
Knipp, Eric; Clayton, Traverse; & Watson, Richard. A Guidance Framework for Architecting Portable Cloud and Multicloud Applications. Gartner. 2016. https://www.gartner.com/binaries/…/a_guidance_framework_for_architecting.pdf
McAffe Labs. 2017 Threat Predictions. 2016. https://www.mcafee.com/us/resources/reports/rpthreats-predictions-2017.pdf
MacDonald, Neil & Young, Greg. Best Practices for Securing Workloads in Amazon Web Services. Gartner. 2015. https://www.gartner.com/doc/3030318/best-practices-securing-workloadsamazon
Tim Sandage & Ted Staffan. Automating Security in the Cloud: Modernizing Governance Through Secure Design. O’Reilly. 2016. http://shop.oreilly.com/product/0636920051787.do
Yunghans, Erik & Simkin, Scott. Changing the Game in Public Cloud Security. The SANS Institute. 2017. https://www.paloaltonetworks.com/resources/webcasts/changing-the-game-in-publiccloud-security