根据联邦安全运营中心的最佳实践,SOC可以保护组织免受计算机网络内未经授权的活动的侵害,至少包括检测、监视和分析可疑活动,并主导对恶意活动的响应,进而有助于问题恢复 ,还能够为用户出具可疑网络安全事件的报告。SOC通常由安全分析人员组成,这些安全分析人员被有效地组织起来,协作进行检测、分析、响应、报告,并阻断网络安全事件。
美国联邦政府将SOC视为各个联邦机构(相当于我们的“部委”)的必备安全组件,借助SOC来实现其各个联邦机构的集中的安全可见性。通俗地说,就是通过SOC来实现“看见”的能力。
2017年,ATC(美国技术委员会,American Technology Council)在13800号总统行政令的要求下,向总统提交了一份《联邦IT现代化》报告。在报告中,提出了将联邦政府SOC能力SaaS化(称为SOC as a Service,SOC服务化)的构想。
报告认为,很多联邦机构缺乏资源和专业能力构建他们自身的SOC。因此,ATC提议那些有足够能力建立并运营自身SOC的联邦机构可以将其能力封装为SaaS服务,输出给那些缺乏相应能力的联邦机构。同时,那些缺乏SOC运营能力的联邦机构也可以去购买外部的商业SaaS服务。ATC认为此举将有利于增强现有联邦网络的融合,尤其是针对联邦网络的云应用。而一个更加融合的SOC将有助于获得更好的网络可见性、更通畅的沟通,更灵活的功能扩展性。
SOC服务化的价值还包括:
1)提升安全能力输出的业务连续性;
2)有助于实施在应用级和数据级的敏感数据保护能力;
3)更好地对来自于不同云供应商和厂商的各种类型的日志和数据流进行统一处理;
4)能够对不同联邦机构的不同云环境进行集中统一的管理,获得对混合云的统一可见性。
报告还提出了SOC服务化的具体行动时间安排:1)在此报告发布后180天内梳理出具体的SOC服务化的能力清单(服务目录);2)在210天内那些有意成为SOC服务商的联邦机构或商业服务商要输出相应的报价模式。同时,被选中的无能力自建SOC的联邦试点机构要形成向SOC服务化迁移的计划。
同样在EO13800的要求下,OMB也在2018年5月发布了题为《联邦网络安全风险判定报告和行动计划》(Federal Cybersecurity Risk Determination Report and Action Plan)的报告。在这份报告中,OMB对联邦机构的SOC能力进行了更加具体的评估。
根据OMB的这份报告,联邦机构对其网络“看见”的能力堪忧,尤其是缺乏检测数据渗漏的能力。OMB的风险评估显示,73%的联邦机构在检测和相应数据渗漏这块处于中高风险状态;只有40%的机构能够检测加密的数据外泄;只有27%的机构表示他们有能力对大规模数据访问行为进行检测和调查,而对该能力进行过验证的机构就更少了。风险评估同时显示联邦机构的应急响应能力成熟度整体偏底。只有52%的机构具备经测试验证过的应急响应流程,仅17%的机构真正能够在安全事件发生后去分析事件响应数据。这表明,联邦机构缺乏有效的应急响应流程,并且也无法在实战中开展有效的应急响应工作。
为了应对这些挑战,DHS正在紧锣密鼓地开展CDM(持续诊断与缓解)计划,并将其作为联邦机构整体安全能力标准化、集中化战略的重要一环。目前,联邦机构的SOC主要借助CDM来实现对网络的可见性,包括对恶意代码和恶意行为的持续监控和应急响应流程。当网络中出现安全事件后首先由CDM进行响应。
OMB发现不少联邦机构说他们没有足够的合格全职员工去运营SOC,超过70%的机构表示在SOC运营方面的投入不足100万美元。此外,有些联邦机构还部署了多套SOC,并采用不同的流程和技术。更糟糕的是,一个联邦机构内部的多个SOC之间的协同性极差,缺乏威胁信息和情报的共享。这都使得网络的可见性和运维的有效性大打折扣。
针对上述两个问题,OMB和DHS提出了对应的行动方案。
1)针对有的SOC由于资源和人员有限导致运营不起来的问题,通过SOC服务来解决,让优秀的联邦机构自己的SOC能力输出给那些弱的机构,或者让那些弱的联邦机构去购买商业的SOC服务(SOC as a Service)。这个行动方案也正是ATC报告中所提议的。
2)针对有个联邦机构存在多个SOC且协同性差的问题,进行SOC运营合并,形成针对这个机构的单一统一运营。这种合并需要指定一个主控SOC,但不是将所有的下级或者分散的SOC去掉,也不是说将这些下级SOC的数据都送到主控SOC中,而是要形成一种在主控SOC调度下的多SOC协同分工的机制,重点是信息的共享,决策的一致性,对于具体响应动作的执行肯定还是分散的。
综上,OMB在2018年10月份(也就是2019财年初),以备忘录(M-19-02)的形式明确了SOC未来的工作安排(要通过预算体现出来)。这项工作名为“SOC合并”,核心内容是根据《联邦网络安全风险判定报告和行动计划》要求,增强各个联邦机构的SOC成熟度。要求各个联邦机构在2019年4月16之前提交企业级【注:这里的企业(enterprise)级就是一级/部委级,往下叫component级,即二级机构】网络安全运营成熟度计划,并在2020年9月30日之前【即2020财年底】完成SOC的成熟度计划,或者合并SOC,或者将SOC迁移到SaaS,或者兼而有之。
SOC运营成熟度计划必须包括以下内容:
1)提供当前企业范围内内网络安全运营的运作模型及其描述;
2)具体描述SOC合并或者将SOC迁移到服务商,以提升网络安全运营成熟度的方法;
3)列出受影响的政策,流程,设施,团队,合同,预算帐户或与该计划相关的任何其他事项;
4)提供目标状态的网络安全运营运作模型及其描述;
5)阐明可立即执行的行动时间表;
6)列举出因为预算问题而无法立即执行的行动,并给出解决建议;
7)给出持续改进网络安全运营模式的关键活动和里程碑节点。
从这份备忘录可以看出,首先,美国的每个联邦机构都已经上了SOC,但总体效果不尽如人意。其次,2019年和2020年的SOC核心工作就是合并SOC,迁移SOC,采购SOC服务,提升SOC的集中度、运营成熟度和运营效果。目标就是获得更好的网络可见性,通过与CDM的配合更好地进行网络持续监控和检测,发现入侵攻击和违规,并更快速有效地的做出响应处置。
在各种指令要求下,各个联邦机构已经行动起来,纷纷制定各自的SOC成熟度计划并着手落实。譬如,DHS自身作为一个机构也正在准备新一轮的SOC服务采购。
最后,笔者小结一下,对于美国(民事)联邦机构而言,上不上SOC不需要讨论了,是规定动作,问题在于怎么用好SOC。而对于怎么用好SOC这块,他们目前的思路是1)对于有多个SOC的单位做好SOC(逻辑)合并工作;2)对于安全运营能力太弱的单位让其购买内部或者外部的SOC服务。
对于我们而言,我国的政府部委SOC建设没有明确的法规要求,建设时间前后跨度大,未建、已建、在维皆有,标准不一,内涵不尽相同,运营能力也是参差不齐,总体效果恐怕比美国更差。笔者期望通过研究他们的SOC现状和发展计划,能对我们的SOC建设和运营有所启发。
声明:本文来自专注安管平台,版权归作者所有。文章内容仅代表作者独立观点,不代表士冗科技立场,转载目的在于传递更多信息。如有侵权,请联系 service@expshell.com。