SANS:2018年SOC调查报告

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/weixin_34178244/article/details/85186356

2018年8月份,SANS发布了第二次SOC调查报告。
SANS:2018年SOC调查报告
标题"The Definition of SOC-cess?"可以理解为:如何定义SOC的成功(success)?
总体上来看,今年的情况跟去年差不多。

SANS对SOC的定义是:SOC是人、流程和技术的结合,它通过主动的设计和配置、持续地系统状态监测、检测意外动作和非预期状态去保护组织的信息系统,力图尽可能地降低不良影响造成的伤害。(A combination of people, processes and technology protecting the information systems of an organization through: proactive design and configuration, ongoing monitoring of system state, detection of unintended actions or undesirable state, and minimizing damage from unwanted effects.)
同时,SANS认为SOC成功的标准是其是否有效干预了对手企图破坏组织资产可用性、机密性和完整性的尝试。一般地,SOC通过主动地把系统变得对损害更具弹性,以及更加快速地检测、遏制和消除对手的能力来做到这一点。(We define the success criterion for a SOC as: when it intervenes in adversary efforts to impact the availability, confidentiality and integrity of the organization’s information assets. It does this by proactively making systems more resilient to impact and reactively detecting, containing and eliminating adversary capability.)
SANS发现,SOC似乎是一个很大很复杂的系统,但实际上31%的SOC团队只有2到5个人。
SANS:2018年SOC调查报告
而另外一个安永针对1200个组织(其中大部分是大型和有钱的单位)的调研显示,48%的受访者没有SOC。

SANS从SOC的能力和SOC的架构两个方面进行了调研。
SOC团队主要做什么?
SANS:2018年SOC调查报告
从上图可以看出来,SOC的主要活动包括:应急响应(96.8%的受访者表示)、安全监测与检测(96.6%)、SOC架构与工程化、安全管理、数据保护与监测、修复、安全规划,等等。上图还显示了每个活动是自己内部完成,还是借助MSSP来达成,抑或两者结合的比例。可以看出,SOC团队自己搞的比例比较高。

不同行业的SOC团队规模,并没有显著的趋势:
SANS:2018年SOC调查报告

SOC的部署架构(模式)
SANS:2018年SOC调查报告
可以看出基于云的SOC比重还是比较低的。
SANS:2018年SOC调查报告
如上图所示,在未来十二个月的规划中,依然是自建大集中式的SOC为主,但云SOC的比重稍有增加,同时建设正规SOC的意愿更强,如下图:
SANS:2018年SOC调查报告

仅有54%的SOC建立了SOC度量指标,SANS表示“这不是一个好现象”。至于一般都建立了哪些指标,如下图所示:
SANS:2018年SOC调查报告
这个图我还是比较感兴趣的。报告还提及了一些小众的指标,譬如:处理中高级问题的耗时(还是陷入告警的茫茫大海?)、钓鱼事件计数、威胁猎捕相关的统计性数据。
针对上述度量指标,大部分依然还是手工计算,如下图所示:
SANS:2018年SOC调查报告
我个人认为,要想真正做到度量自动化是很难的,首先就是对指标的一致化的清晰的定义,这一点就很难。需要在度量的有效性和度量的可行性之间取得一个平衡。

SOC用到了哪些安全技术和工具?
SANS:2018年SOC调查报告
上图也算是一个SOC技术流行度的排行。
对这些安全技术和工具的满意度如何?
SANS:2018年SOC调查报告
SANS将排第一的NGFW给出了B+的评分,而对最后一位的资产发现与管理的满意度评定为F。
需要注意的是,SOC高度依赖人的技能和经验,因此,不同水平的人对相同的技术评判是不同的。我个人建议大家可以关注最满意的和最不满意的几个技术。

触发响应流程的告警来源,或者说SOC分析师主要看什么日志来触发应急响应,如下图:
SANS:2018年SOC调查报告
可以看出,主要看终端,IDS,IPS和防火墙的告警,其次是SIEM告警。也可以看出一般都要看多种告警,而不会集中到某个点上。此外,异常检测的结果、威胁捕猎的结果和威胁情报也很重要。
对多源数据的关联分析,主要依靠SIEM,如下图:
SANS:2018年SOC调查报告
说明SIEM依然是事件分析的核心。

响应方式这块,如下图所示,大部分都做到了响应流程与SOC的集成:
SANS:2018年SOC调查报告
针对不同的相应技术,总体的满意率较低,起码低于SOC技术和工具的满意度。最满意的网络取证分析技术也仅仅被SANS评定为C。
SANS:2018年SOC调查报告
这个图值得自己研究一番。

SOC面临的主要挑战如下图所示:
SANS:2018年SOC调查报告
合格的人才依然是最大的问题。究其原因,SANS认为SOC这个活天然就是一个复杂高难度的事儿,涉及面太广,不仅是技术面要求广,业务面也很广。那么能否搞出一个NB的技术和工具降低对人的要求呢?我个人认为,目前看还不现实,从前面的分析可以看到目前对于AI和ML的满意度依然很低,而且新出现的一些技术对人的要求更高。

SOC对智能设备,包括工控、物联网的管理程度还比较低,但应该予以重视。
SANS:2018年SOC调查报告
SANS特别强调了基于行为基线来进行相对较为封闭的IoT设施的安全监测的方法。

SANS结论:以下问题依然阻碍着SOC的发展。
1)缺乏有效的和集成化的工具;
2)缺乏有效的资产发现与管理技术;
3)自身组织内部的隔阂与分立;
4)人员缺乏,关键技能缺乏;
5)自动化的有效性还不够,关联分析能力还有差距;
6)对SOC成功的定义和度量还很缺乏。

SANS最后表示:A key finding of the survey was that only about half of the SOCs are using metrics. Not only are meaningful metrics critical to running an effective SOC, but they are absolutely mandatory to have any chance of persuading management to provide the resources needed to overcome the barriers identified in the survey.

后续,我还将继续根据这份报告结合我个人体会发表观点,敬请关注。

【参考】
SANS:2017年SOC调查报告

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

SANS:2016年安全分析调研报告
SANS:2015年安全分析与安全智能调研报告
SANS:2014年安全分析与安全智能调研报告
SANS:2013年度安全分析调查报告

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

没有更多推荐了,返回首页