Security Operations Center — 通常缩写为SOC , 从字面意思上来看,就三个单词,安全,行动,中心,也有人称SOC为安全操作中心或者安全运营中心,其实通常,一个东西,你怎么称呼它其实并不重要,重要的是你怎么去解释它。这里面主要是中文(运营,操作,行动)对应的范围不同,运营的范围更大一些。这是一篇翻译的文章,其中自行加入了我自己读起来通顺的语言转换方式,不习惯的可以跳到文章尾巴上,有原文的链接。这个是哥周五欠曾经请我喝过羊汤的哥们的作业,看在羊肉的份上,也就找篇看得过去的翻译下应付应付。哈哈哈。。。

Rapid7 这公司,说实话,要不是在绿盟的时候因为一个自主可控的项目,撸了一遍metasploit的Java GUI 和ruby的后台,还有那一堆shellcode,我是真的不会关注它,不过那时候,貌似,meta还没被收购吧。怀旧不是好事.老衲需要休息!

SOC 是什么?

SOC 通常是用于监视,检测和响应在组织业务上可能面临的安全问题和事件而设立的中心化指挥部,它可能是有办公大楼的组织也可能只是虚拟的组织,取决于组织的规模和面临问题的复杂程度,作为更大的事件检测与响应程序的一部分,有几种实现SOC的方式 ----内部自建,共同管理,完全管理外包

你可以把SOC想象成电影中的战情室,一个黑暗的房间,里面摆满了复杂的地图,花哨的显示大屏和戴着耳机的分析师,然而,大多数现实中的SOC 可能并不具备电影中的场景,更准确的说,SOC是一个为了检测,验证,响应你环境中的威胁,而由具备不同安全角色和职责的人组成的正式或非正式团队。

谁需要一个SOC

无论公司的规模和存在的目的是什么,有一个专门的组织级别的团队来对组织的安全操作和事件进行持续的监控,并对任何可能出现的问题进行响应是很有必要的,也是有价值的。一个安全团队的各种职责可能异常复杂,SOC不仅可以作为一个战术控制台(指挥控制)来授权团队的相关成员进行日常任务的处理,也可以作为一个战略中心(威胁态势感知?),让团队了解更大,更长期的安全趋势。

通常,一个常规的安全操作中心主要是跟踪一个组织可能遇到的任何数量级的告警,包括通过技术手段和工具监控产生的告警,以及员工,合作伙伴和外部来源发出的潜在威胁通知,然后,SOC 开始调查并验证相关来源的告警和报告的威胁事件,以便确定告警的真实性(很多告警并不是真实的威胁,误报),如果安全事件被认为是有效的而且需要被响应和处理,SOC 就将其移交给适当的人员或者团队进行响应和恢复。

作为整个事件检测和响应计划的一部分,SOC 的有效运行需要将专业知识(安全专家),流程(安全流程),和组织(人员组织)的复杂组织和融合,这也是为什么不是每个组织都有能力和资源在自己内部构建SOC的原因,所以他们在外部寻找并选择相应的机构和组织来协助他们管理他们自己的SOC,甚至是完全外包。

建立SOC需要的什么基础组件?

在SOC成为一个组织的选择之前,有许多支持组件是必须到位的。首先,你需要一个好的攻击面管理程序(漏洞&资产管理&风险评估产品),包括用于所有威胁在出入口通道处的威胁阻止技术,定期的漏洞扫描(包括补丁),渗透测试,用户身份验证和授权,资产管理,额外的应用测试(包括漏洞修复)以及远程存取管理。

接下来才是事件响应计划,通常,将SOC(安全运营中心)引入IDR(事件检测与响应)的主要目标是提升在组织环境中检测威胁的有效性,如果一个安全缺口(breach)被发现后没有在事件响应过程中得到定位并定期进行测试,那么你可能只是处理了有效的IDR程序中的一些组件。

最后,具备适当的灾难恢复计划也是非常重要的,一个安全缺口(breach)只是组织需要灾难恢复的一个具体例子,一旦检测到的安全缺口(breach)被完全确定了影响范围以及相关受影响的资产,应用程序和用户,就需要一个适当的计划来恢复正常的业务操作流程。这就是灾难恢复。

建立SOC 需要考虑的三个因素

考虑到 SOC 实现的固有复杂性,在建设一个公司的SOC 时需要考虑很多事情,无论是内部自建还是外包,SOC 成功的关键有如下三个要素:

人员:

了解SOC 分析师的角色和职责是为你安全运营中心选择所需要的技术的重要前提。您创建的团队和您给他们的任务将取决于您组织的现有结构。例如,如果您正在构建一个SOC来增强现有的威胁检测和响应能力,那么您需要考虑SOC团队成员负责哪些特定任务,哪些任务属于非SOC IDR团队。您还需要在SOC分析师之间划分职责,以便清楚地了解谁处理高精准告警、谁验证低精准告警、谁来提升告警级别、谁查找未知威胁等等。许多安全操作中心使用分层架构来帮助员工建立清晰的职责和层次结构。

技术:

决定什么技术是SOC所需要的取决于建立SOC的时候所设置的分析师的角色和职责以及他们的时间花在什么地方?因为人员和技术(要素)决定了你建立SOC的成本,他们将使用什么技术?比如,他们需要一组工具用于日志聚合,用户行为分析,终端审查(排查),实时搜索等等,查看SOC分析人员如何使用这些技术以及确定现有的技术是帮助还是阻碍了安全运营过程,以及确定是否需要新的技术取代旧的技术是非常重要的,此外,将通讯工具放置在合适的位置来帮助分析师更好的协同工作也很重要。

流程:

建立上述人员和技术遵循的流程是你开始建立安全运营中心时需要考虑的最后一个组件,我们需要考虑的是,如果一个安全事件需要验证,报告,提升级别并移交给另外一个团队,会发生什么?你将会使用什么样的收集和分析工具,流程必须足够精确,以便让事件调查过程能够按事件重要性级别进行处理,同时要保持一定的宽松性,避免陷入分析过程的细节中。流程可以让SOC更有效,也可以让SOC变得更无效,是值得努力去认真做的事。

上面几个因素同样可以应用到外包型的SOC中,在这种情形下,外包型SOC将成为企业值得信任的合作伙伴,因此,他们能够主动定期的与你保持沟通是完全必要的,因为在合作中保持透明和反馈来确保你的SOC 成功和有效,至关重要。

https://www.rapid7.com/fundamentals/security-operations-center/

声明:本文来自继之宫,版权归作者所有。文章内容仅代表作者独立观点,不代表安全内参立场,转载目的在于传递更多信息。如有侵权,请联系 anquanneican@163.com。