SOC怎样适应云时代

将数据和过程迁移到云端给企业安全运营中心(SOC)提出了一些挑战。公司企业该如何收集、监视和分析基于云的安全数据呢？

随着越来越多的关键业务职能脱离现场环境迁移向云端，SOC面临适应改变和监视新环境的严峻挑战。有些SOC依赖供应商提供的管理与安全工具，有些采用第三方服务从其SaaS、PaaS和IaaS提供商处拉入数据，还有些则打造自己的安全门户。

INAP是一家数据中心、云及主机托管服务提供商，这家公司不仅要管理和保护其基础设施，还要为其客户提供管理及安全数据反馈。由于除60万平方英尺的数据中心外还为客户管理着多云实例，该公司的管理任务列表中还包括了所有主流云供应商提供的基础设施。

INAP全球云服务高级副总裁 Jennifer Curry 表示：这些环境中传统监视工具没用，用户访问不到网络，也接触不到底层基础设施。

云供应商，比如亚马逊、谷歌和微软，会提供数据反馈。INAP运用其API往自身系统中拉取日志和其他数据，但这一过程总是说起来容易做起来难。

用API时总会碰到范围和速度的改变，很难跟上这种变动。云空间里就是这样，变化多端是云环境的本质。发展很快，总在维护。

可行的时候，INAP会使用商业工具。在知道将会快速改变的情况下，INAP会编写解决方案并定制之。目前没有哪个平台能满足公司所有需求。INAP的定制对其客户而言是项增值服务，单个平台无法实现在发现更有效率的功能时进行加载或替换。

当然，INAP的部分核心业务定位就是云环境管理，该公司必须能够处理好这些事务并分配足够的人员专门负责此事。其他没有多云环境及服务管理业务的公司企业可能不具备类似的资源。

发现云服务问题

首先，很多安全团队甚至都不了解自家公司有多少云服务在用。BetterCloud主营SaaS应用管理及安全防护，其首席业务战略官 Shreyas Sadalgi 称，普通公司企业通常用他们公司的服务处理7个SaaS应用。

BetterCloud支持谷歌 G Suite、Okta、Dropbox、Slack、Box、Salesforce、Zendesk、Namely和 Office 365，今年还将在其新的社区交换平台上添加10个支持对象。只要有API，还可按客户需求连接其他云服务。

该公司目前拥有2,500家客户，其安全团队最为重视经许可的任务关键应用。Sadalgi认为：这些应用是客户想要保护的。长长的SaaS应用列表真没那么重要，因为所有任务关键工作都在这些经许可的应用里做了。

然而，专注一小撮经许可的云服务也许是个错误。云安全供应商Netskope产品管理总监 Gautam Kanaparthi 说：

我们问道‘你们在用多少个云服务’时，他们回答说10个，或许是20个。但当我们审查时，往往会发现数百个云应用，有时候甚至是数千个。

Netskope最近的云安全报告中，公司企业平均在用1,246个云服务，比一年前的1,022个上升了22%。其中包括175个人力资源相关的服务，170个市场营销相关的，110个协作相关，财务和客户关系管理各76个。这些应用中任何一个都有可能给出敏感业务数据，而且其中大多数都不是企业级可用的。

最大的问题出自身份与访问管理(IAM)领域，其次是监视、网络和日志记录。Kanaparthi称：这绝对是现代安全团队面临的巨大挑战。最主要的困难在于安全不再处于企业IT部门控制之下。过去所有流量都要经过企业数据中心，但现在可以从任何地点访问任何服务。这对安全团队而言是个全新挑战。

平台特定的安全与管理工具

大多数面向企业的云供应商提供的都是同样的管理与安全工具，无论是通过仪表板还是API提供，或者是双管齐下。但若使用仪表板，安全团队需在不同系统中切换。这就很头疼了。因为他们不得不学习各种不同工具的用法。而且也更难以检测同时袭击多个不同平台的攻击。

云提供商并非总能获取到安全团队所需的全部信息。比如说，某公司想确保员工从有口令和杀软保护的安全设备登录其SaaS服务。通常，SaaS提供商关注用户本身：用户有访问授权吗？但他们不会知道用户是不是从不安全的家用电脑登录。这才是企业客户当前的最大问题。

为解决这些问题，企业开始采用云访问安全代理(CASB)或单点登录解决方案。比如说，Pulse就出售装在用户设备上的软件客户端，可以监视并报警安全策略违反现象。公司的安全团队可以登录到基于云的仪表板上查看问题。

虽然Pulse解决了移动劳动力登录云应用的可见性空白，但安全团队又因此而新增了一个问题：他们需要登录的云仪表板又多了一个——一块没集成进其他云服务或自家SIEM的仪表板。

客户要的是能融入SIEM的数据馈送，但Pulse当前并没有这个功能，2019年晚些时候会增加这个集成。

将云应用登录数据馈送进SIEM或其他集中式安全平台的最佳办法是使用API，用一个脚本就能通过HTTPS拉取日志。该过程正变得越来越简单，但你必须弄清楚自己想要查看哪些数据，然后据此微调。

云数据反馈聚合器

为解决多云提供商安全管理问题，有些供应商打造了多云平台连接器，然后将之全都推入一个仪表板或数据馈送中去。Netskope的Kanaparthi称：

我们的API钩上所有这些应用，与所有供应商建立联系，提供单一管理面板。

Netskope还提供超细粒度控制，可以跟踪与公司外部人员共享最多文档的员工，监视有多少个人账户用作在Box和Dropbox之类文件共享服务。

我们也理解客户有SIEM且想将数据馈送进SIEM。所以，我们在Splunk上设有应用，并创建了可以插入其他任何SIEM应用的API。

将云数据拉入自有SIEM

大型企业的SOC一般都有自己的SIEM或类似的平台。如果一个云服务提供API数据馈送，其日志数据就能被拉入该SIEM供安全分析师在单一平台上审视自家各类系统。

面向企业的供应商通常都有这样的API，但某些情况下，SaaS应用的第一或第二版可能暂时没有这样的API可用。

有时候，数据是可用的，但客户没设置对数据的访问。比如说，微软有几种不同的 Office 365 许可版本，价格低的就没有提供所需的数据。最便宜的一版是E3许可。公司企业从现场Exchange环境迁往云端，觉得自己转向云端 Office 365 可以节省成本。但E3的安全日志与审计非常有限，与原先的现场Exchange环境不是同一个量级的，提供不了企业所需的日志功能。而且E3也不如E5许可或高级安全许可健壮。

攻击发生时，使用 Office 365 的公司并不能立即查看日志，得向微软发出请求，然后祈祷他们能返回些有用的数据。

即便设置了API，数据也推入了SIEM，问题仍未完结。很多SaaS供应商仍在完善其产品和安全功能，API随时在变。围绕这些数据的操作总在改变，跟上这种变化本身就是一大负担。

只要数据馈送领域发生改变，馈送就可能中断。或者，SaaS供应商添加新的功能，而馈送未能拾取。举个例子，去年亚马逊发布了GuardDuty，这是个很棒的安全服务，然后今年他们又推出了 Security Hub，是GuardDuty与其他服务的聚合。这是向简化服务到单一馈送所迈出的一步，但因为比之前的功能更丰富，企业想要用新服务就得更改自己的集成以融入该新添服务。

对客户而言，这意味着更多的工作，是客户的一大痛点，尤其是在聚合领域。没人会只消费一种东西，紧跟所有变动令人身心俱疲。对中型企业而言数据流会骤增，大多数安全预算支持不了这个。

Salesforce这样的成熟企业有自己的发布周期，也有详细的文档和提前测试的能力。但仍需有人跟进该服务，而这需要时间。有太多原因让公司企业想要将此类工作交托给别人。

Pondurance就是不想手动做这一切的公司之一。很多托管安全服务提供商都自行承担了这项工作，还未找到可靠的服务来从云服务提供商收集所有数据馈送并保持更新。但此类服务肯定是很多公司企业所渴求的。

同时，一些较老的SIEM平台在从云数据源收集日志数据时可能会遭遇麻烦，因为这些老旧平台原本只设计了处理现场系统数据馈送的功能。老旧平台在这方面存在架构性问题，只能跑在现场服务器上，但公司企业需要访问的服务依托云端。

不过，公司企业也在迎头赶上。比如说，Splunk就设置了云选项。Gartner刚刚发布了魔力象限报告，其中几个SIEM供应商如今开始提供云交付了。除了Splunk，还有IBM、AlienVault、BlackStratus、ManageEngine和Rapid7。

基于云的SOC

对很多公司而言，将其SIEM安置在安全数据所处的云端是有利的。遗留系统无法纳入这些数据，让这些数据通过防火墙就是件棘手的工作，需要做配置上的改动。如果SIEM就在云端，事情就简单多了，分分钟搞定。

而且，不仅仅是SaaS供应商和云计算平台会产生馈送，越来越多的服务正向云端迁移。就以下一代杀毒软件公司为例，杀软数据绝对需要进入SIEM，但一些最流行的杀软技术如今已位于云端，比如CrowdStrike和Cylance。

数据防丢失技术、入侵预防技术也在向云端迁移。Gartner报告指出，到2020年，25%的新SIEM实现将以服务形式交付，而这一数字在2017年仅5%。安全人才短缺和威胁态势的快速变化也驱动着很多公司寄希望于 SaaS SIEM 和共管式SIEM。

Netskope云安全报告：

https://resources.netskope.com/cloud-reports/netskope-cloud-report-october-2018

Gartner SIEM魔力象限报告2018获取地址：

https://www.splunk.com/en_us/form/gartner-siem-magic-quadrant/thanks.html