【注】本文转载自凌晨的微信公众号,原标题为《未来SOC:SANS 2017年关于SOC的调研报告》,翻译自SANS今年5月份发布的同名报告。


执行摘要

       根据新SANS调查,SOC还在持续增长中。受访者表示,SOC的主要优势是灵活性和适应性,而其最大的弱点是缺乏可见性:SOC仍然无法检测到以前未知的威胁。调查还发现,需要在预防,检测和应对功能方面实现更多的自动化,特别是在预防和检测方面,受访者使用的工具大部分是相同的。

作为一个信号,SOC逐渐的多功能和成熟,67%的受访者表示对其响应的灵活性感到满意,65%的人对整体响应时间感到满意,64%的受访者对攻击的遏制能力感到满意。然而,SOC和NOC的协同和有效性的满意度,以及检测以前未知的威胁的能力,下降到50%以下,这也是SOC最不“满意”的地方,达到45% 。这些表明更多的自动化和集成将帮助组织将其SOC提升到一个新的水平。

SANS:2017年SOC调查报告_SIEM

大多数SOC(83%)定义了事件的概念,57%的受访者表示他们利用指标衡量SOC的绩效。然而,使用指标的人中有69%需要大量的人工努力才能编制这些指标。这是另一个可以自动化的领域,SOC-NOC的信息共享将帮助组织将其SOC提升到更高水平。然而,只有32%的SOC与网络运营紧密结合,只有12%组织做了这两个团队的技术整合。

这种整合不足可能部分归因于受访者利用的各种架构。总体而言,目前61%的企业将其安全,响应和修复功能集中到SOC中,28%将其SOC功能分散到不同的安全,响应和修复部门。受访者也将其功能与云进行混合,特别是针对其预防能力。

 虽然组织SOC正在日益成熟并扩大其能力,随着IT运营的关系更紧密和协调,有明显的改善安全运营的机会。 SOC可以通过指标更好地进行自评估,更好地了解如何更有效地为组织服务。以下将讨论这些问题、建议和最佳实践。



(一)SOC架构


309名受访者参加此次调查,通常被称为技术人员(50%),其角色包括开发人员,架构师,分析人员,管理人员或某种形式的运营人员。管理人员(经理,总监,高级人员或C级高管)占40%的受访者,另外8%的受访者从事与事件响应有关的工作,2%是审计人员。

最大部分(14%)在网络安全公司工作,13%来自银行和金融,12%来自技术,10%来自政府部门。参见图1。

SANS:2017年SOC调查报告_安全运营中心_02

 这些数据与大多数其他SANS调查有所不同,后者前两位的类别通常是政府和金融行业。网络安全业务的人数众多,可能表明基于云的SOC和有关员工的增长趋势。

 1.1 地点和集中化

调查中所代表的组织在全球各地开展业务(见图2),总部设在美国的有54%,总部设在欧洲的有22%。

SANS:2017年SOC调查报告_SANS_03

数据表示,其大部分SOC(61%)目前集中在一个中心,但我们并没有询问这些集中式SOC实际位于哪里(推测他们是否位于与总部相同的地点 )。

 第二大类(28%)表明其SOC功能分散在不同的安全和响应组中,17%将的所有的SOC功能云化,如图3。

SANS:2017年SOC调查报告_安全运营中心_04

 

1.2 规模和SOC

潜在影响SOC架构的另一个因素是组织的规模。受访者来自各种组织规模,最大的种类是来自中型组织(251至1000名员工和合同商)、中到大型组织(2,000至15,000名员工)。总体而言,66%的员工和合同商的人数不足10,000人。我们决定将组织规模分为如下类别,超过1000的大型组织(这是“大型”公司的传统衡量标准),参见图4。

SANS:2017年SOC调查报告_安全管理平台_05

  调查结果显示,SOC规模并不紧密依赖于组织规模,至少对于员工数量在10,000以下的组织而言。 SOC的总体规模,从小的、中型、到中大型组织(即员工在10,000以下)似乎是只有两到五名全职雇员(FTE)职位。参见图5。


SANS:2017年SOC调查报告_安全管理平台_06


1.3 SOC人员

本次调研,问的是SOC的规模,不是组织确定什么规模合适。确定规模大小的主要参数是:

 •所需能力 - 合规性,定制化,内部或大部分外包

 •性能目标 - 检测,响应,取证,时间(9点到5点或7*24)

•复制 - 对地理区域不同SOC的潜在需求,例如欧盟针对欧盟数据的SOC

 •预算 - 限制对能力,性能和重复的交付

 1.4 与云的混合

 云计算在本次调查中占基础设施46%,21%的受访者表示在未来24个月内将实现云计算,另有21%表示其SOC功能将在未来24个月中架构在一个或多个云提供商上。

在管理其SOC的具体能力方面,受访者表示,大多数活动主要由内部处理,特别是其安全路线图和规划,安全架构、工程以及安全管理等战略活动,超过78%内部管理。

 组织依靠外包服务的前几个的活动,与内部资源相结合,是威胁研究(44%),数字化取证(38%),安全监控和检测(35%)以及电子发现和法律证据收集(33%)。参见图6。

SANS:2017年SOC调查报告_安全管理平台_07

如果组织没有采取行动来增强的可见性、情报以及案例,实际上并不能从外包中受益。

1.5 SOC和NOC

受访者以多种方式描述了SOC与NOC的关系。有分离(43%),没有NOC,或与NOC没有关系,几乎没有直接沟通。有不同程度的融合:21%在紧急情况下共同工作,20%在一起工作,但在技术上没有整合,只有12%的技术上有整合(见图7)。

SANS:2017年SOC调查报告_SIEM_08

 SOC和NOC之间的互动为组织提供了改进其检测和响应能力的机会,因为SOC和NOC具有类似的目标:保护组织的信息资产并保持业务运行。

在许多组织中,职责分离造成了可见性的孤岛。在2017年SANS关于安全整合和优化的调查中,超过80%的受访者在报告中提到了重大障碍,报告、风险状况可视化,检测新威胁能力是前三大担忧。缺乏管理层和人员配置,也是问题。没有管理支持和行动,孤岛将继续阻碍SOC、NOC和响应人员之间的信息的自由分享。


(二)SOC能力


SOC对组织成功承担了很大的责任,其提供的能力正在持续增长。基于反馈结果,预防和检测功能之间存在很多重叠,而响应操作有一些差别。例如,网络入侵检测和响应对于检测和预防同样重要,而终端检测和响应(EDR)是最常用的响应能力。SIEM被更常用于检测,很少用于预防 - 例如,威胁情报更常被用于检测。

 如本文前面的架构部分所述,SOC开始将基于云的服务与自己的内部服务相结合,反馈表明,服务更常用于预防和检测功能。例如,超过50%的受访组织使用基于云的服务进行渗透测试,使用威胁情报来实现其预防能力,而平均来说,10%的用户正在使用这两种服务进行检测。云检测的最多用途是拒绝服务和分布式拒绝服务(DDoS),大概有40%以上,情报是云检测服务第二高,低于40%。

 同时,云服务很少用于响应能力,除了恶意软件的逆向工程之外,在不到25%的受访者组织中使用云服务。

 2.1 预防?

 通过SOC服务或内部的集合,超过71%的SOC提供了图8所列的前17名预防能力。

SANS:2017年SOC调查报告_SOC_09

预防能力是试图阻止攻击成功。在调查中,91%使用在线网络入侵检测和预防系统(NIPS)来防止攻击成功。防御能力基于网络的对异常的动作的流量内容进行检查,以及一旦识别不适当的内容或通信就终止通信。

 
 2.1.1 云服务预防

在图8所列的20项预防性控制措施中,不包括“其他”,不到10%的使用14种控制作为服务。三个答案是:只有10%到20%服务,只有20%以上的服务。,仅用作服务的前三个SOC功能是渗透测试(26%),DoS / DDoS缓解(23%)和威胁情报(21%)。

 SOC提供的最少选择的预防能力包括欺骗能力(42%)和应用白名单(66%)。


 2.1.2 白名单不容易

 应用程序白名单主要是一种预防工具,并且还有一些检测优势。然而,根据我们的经验,SOCs不使用应用程序白名单,因为在建立和维护列表时的开销。在大多数环境中,部署应用程序白名单的工具已经通过具有AppLocker的Microsoft Windows的企业版本(从Windows 7可用)获得。许多端点保护工具套件还提供限制执行的能力。在大多数IT环境中,白名单难以维护并保持最新状态。


2.2 检测?

在调查中,82%的受访者表示,他们的SOC进行了Windows事件日志监控,而84%的受访者使用SIEM报告和分析; 86%的用户将日志管理和网络入侵检测与预防作为其首选检测工具。这些是熟悉的基线检测控制。参见图9。

SANS:2017年SOC调查报告_安全运营中心_10

Windows事件日志监视涉及很大的数据量,来监控系统的运行状况和状态。为了处理过载,可以采用一些策略。首先,组织可以通过威胁情报来针对感兴趣的指标进行有针对性的检查。新的威胁情报出现时,需要在以前的数据上应用。第二个选择是分析人员进行威胁追踪时,对可能无法通过自动关联的威胁进行分析。这个过程是耗时的,但有必要长期改进。最后,SOC可以使用系统提供的相关性来识别用于检测和验证的异常情景。这也被称为用例开发,相关性的自动化应该是威胁追踪的输出。

2.3 响应?

只有在我们检测到威胁的时候,我们才能做出响应。这是该用到威胁情报工具(如对手欺骗,威胁运动跟踪,威胁归因和威胁处理)的地方。然而,这些功能在SOC提供的响应能力列表中得分最低。参见图10。

SANS:2017年SOC调查报告_SOC_11

2.3.1 聚焦终端

根据SANS调查,终端是许多响应能力场景的重点,这表明用户的终端往往是攻击的初始点。终端也代表了一个组织的“不信任但是内部”的用户网络钓鱼风险,下载感染,或携带应用程序漏洞。

用户终端的修复很容易,因为只有一个用户受到修复过程的影响。在服务器上,通常有很多员工或客户受到影响,有时候会有不可接受的可用性中断。

2.3.2 云服务响应?

SOC很少使用基于云的服务的响应,响应服务主要是内部完成的。这是有道理的,因为大多数工具供应商都调查事件并提供建议,甚至是打补丁。但是修复和其他响应功能通常由受影响的组织来处理。

最常见的组织是外包逆向工程,这可能是因为需要专业化,执行事件响应也需要。

2.4 监控?

 有趣的是,物联网(IoT) - 所有人员连接到的计算机网络,不像传统用户系统(如电话或笔记本电脑),并没有被SOC覆盖。参见图11。

SANS:2017年SOC调查报告_SIEM_12

只有9%的受访者表示他们SOC支持所有物联网系统,而21%的人表示SOC没有计划支持智能系统。 最常见的答案是目前有部分涵盖(24%)。


 2.5 日志?

中央收集和汇总所有日志,以及更长的保留时间有助于有效监测、网络威胁情报和威胁追踪。根据反馈,只有9%的用户集中了100%的日志,而最大的部分(26%)提到集中了51%到75%的日志,如图12所示。

SANS:2017年SOC调查报告_安全管理平台_13

 在没有所有可用数据的情况下操作是事件响应活动中经常遇到的情况。对于日志没有集中,有几个可能的解释,包括:

将所有数据全部集中到一个地方有技术难度。网络带宽可能很贵。

收日志的政治挑战。考虑到许多SOC服务于咨询角色而不是技术分析能力,只有当组织的一些下属部门要求帮助并共享特定数据时,才能收到数据。

保留日志的挑战。大多数SOC在有限的时间内保留和存储日志,这将在下面讨论。

 在SOC保留的日志中,57%的合规性数据保留一年或更少,而42%的不受管制的数据保留一年或更短。如果被调查的事件在一年内,这是足够的。不幸的是,像Verizon的2016年数据泄露报告和SANS调查这样的行业研究显示,在许多情况下发现之前的时间长于一年。
 

2.6 有意义?

 在调查中,77%的受访者表示,他们的SOC正在使用SIEM工具将不同的源数据拼凑在一起,去找攻击的模式。这是一个昂贵的建议,但通常比定制的更有效益,23%的受访者表示他们正在使用内部开发的API和仪表板。见图13。

SANS:2017年SOC调查报告_SIEM_14

 

 有许多专门的系统可以帮助模式匹配和指导。例如,由38%的受访者选择的网络威胁情报(CTI)平台作为其SOC能力的一部分,为创建信息关联创造了机会。他们持续收集攻击者行为有助于分析人员寻求攻击指标,例如:

•IP地址

•SMTP网关

•恶意软件编程技术

•常用的对手战术

 •对手工作时间

•首选攻击目标

 在调查中,38%的受访者表示正在使用日志收集和聚合工具来分析其事件数据。或者,正如一位受访者坦率地回应的那样,他们通过“运气”相关联。SIEM工具往往会因为数据很大而面临挑战,因为它们尝试关联所有的东西。另一方面,日志聚合维护原始的数据集合,根据需要进行分析处理。

威胁追踪是SOC的责任领域。即使有设备和软件,分析人员也必须调整该技术,以适应组织不断变化的IT环境以及威胁环境。攻击的对手是人。对手具有适应性,积极性和盈利能力。一些SOC正集成威胁追踪功能作为标准功能的一部分。

反馈表明,组织正在使用多个平台来帮助关联性,这意味着分析人员收集、关联和修复的多个平台和控制台。

 通过自动数据收集和关联进行威胁追踪,可提高分析人员可以调查和修复未知威胁的速度。对于已知的威胁,在相关引擎中包含学习情报是提高准确性和性能的方法。


(三)指标和性能


在这项调查中,只有17%的受访者缺乏对事件的正式定义,这对防御者和分析人员来说是一个重要的起点衡量标准(见图14)。

SANS:2017年SOC调查报告_SANS_15

对于运行的SOC来说,没有正确定义检测或响应什么是有效运行的主要障碍。大多数组织(45%)确实具有具体影响类别的正式定义。第二大类使用的是不太正式的方法:“高于正常噪音水平的任何攻击事件”。

也有2%的人表示自己的组织有意避免定义事件,因为它将触发法律行动,他们知道应避免什么。这是一个有趣但并不罕见的问题。所有SOC都必须符合法律指导,组织有些行动可能非常昂贵。挑战是一些法律上的注意事项会阻止SOC做最佳做法。


 3.1 评估SOC?

 纽约市前市长Ed Koch由于要求指标而闻名。然而根据调查,只有57%的受访者有SOC指标。其余的人是否回答“否”或“未知”。这意味着43%的SOC不知道“他们在怎么做”。参见图15。

SANS:2017年SOC调查报告_安全管理平台_16

 调查结果显示,编制指标涉及大量的人员投入,69%的受访者表示该过程是大量或完全手工的。参见图16。

SANS:2017年SOC调查报告_SIEM_17


我们可以看到手动组件与理想状态不一致:“始终如一地衡量,没有主观标准、花费不多的收集,以自动化方式...“

   关键是为系统进行数据收集和持续分析数据,以了解SOC正在做什么以及它做得如何。图17显示了如何跟踪和报告指标?

SANS:2017年SOC调查报告_安全运营中心_18

3.2 追踪指标

有关受访者正在跟踪的一些指标的列表,请参见图18。

SANS:2017年SOC调查报告_安全运营中心_19


3.3 性能的满意度

见图19。

SANS:2017年SOC调查报告_SOC_20

 解决未知问题意味着发现它们。这需要揭示看起来是正常的,因为实际上是有问题的。包括通过日志审查来查找恶意活动。其次,这需要使用外部提供的信息进行分析,以及通过威胁追踪得到的内部威胁信息。

受访者对SOC的灵活性响应最满意。例行程序和自动化是效率和速度的方法,第二个满意的响应“总体响应时间”。


(四)结论


SOC是一个新的和发展中架构,在许多跨组织有一些共识,应该做什么:日志,监视,关联和响应。事件的概念在SOC中似乎很明显,但似乎缺乏绩效和业务符合度评估,这是改进的重要领域。

调查显示,大量的SOC数据收集和分析是通过手动方法完成的,意味着需要每天筛选和关联数百个事件。数据收集和分析的自动化可以使SOC团队有信心地处理绝大多数告警。

许多组织正在将部分SOC功能托管到服务提供商。该模式通过将任务转移给第三方来寻求效率,但会降低与业务需求相关的定制的行动和本地化知识库。

 使用明确的指标来表达绩效有助于改进SOC。开发有用的指标需要重用可用数据,以及选择对特定业务需求有价值的绩效标准,并衡量SOC检测和修复活动的有效性。然而,衡量标准是具有挑战性的,因为对于SOC中的重要指标业界还没有有共识。

改进的另一个机会是NOC和SOC之间更有效的协作。SOC和NOC可以共享数据访问,以帮助IT运营部门做出有效的决策,并帮助SOC进行有效的监控决策。威胁追踪和相关度是组织在未来24个月内应该改善的一些领域。

明年,我们可能看到关于SOC是什么能达成更好的共识。


【参考】

SANS:2017年网络威胁情报现状调研报告

SANS:2016年网络威胁情报现状调研报告


SANS:2016年安全分析调研报告

SANS:2015年安全分析与安全智能调研报告

SANS:2014年安全分析与安全智能调研报告

SANS:2013年度安全分析调查报告


SANS:2014年日志管理调查报告

SANS:2012年度日志管理调查报告

SANS:2011年度日志管理调查报告

SANS:2010年度日志管理调查报告