上篇文章简单论述了“安全运营”的基本定位和业务模块,本文将针对各业务模块的建设及运营思路展开论述,希望对各位同学有所帮助。
【安全运营目标和业务之间的关系】
上文提到,安全运营是站在资产价值链的视角,全局、长周期运营价值资产的安全状态的过程,这个运营过程也一定要有个关键目标或衡量指标,我们把它叫做安全运营的目标。大量项目总结发现,最终的目标就两个,一是要控制风险,二是要合规。控制风险可以使用各种SLA指标来评价,汇总的指标有MTTD平均检测时间和MTTR平均响应时间等。合规的指标评价可以采用等保、关基的相关指标。
安全运营业务是安全运营目标的拆解,要支撑安全运营目标的达成或持续优化,因此,所有的安全运营业务都应该有相对应的可拆解指标来支撑安全运营目标的达成,上下相承。所以,六大安全运营业务模块依据安全运营目标展开拆解,各自制定业务目标和评价指标,与安全运营目标相呼应。大概逻辑如下:
本文所提出的安全运营业务由六大模块组成,是一种建议的分类方式,各位同学也可以按照自洽的逻辑分类业务模块,并论述清楚相互关系即可。下面我们尝试逐一拆解安全运营业务模块。
【安全运营业务模块-资产运营】
经常有同学或专家讲到,安全防守的第一步就是梳理资产。为什么要梳理资产?要梳理哪些资产?资产梳理清楚了对安全防守或安全运营能起到哪些关键作用?
-
首先,保护对象是资产,安全运营的关键保护对象是单位的核心业务系统及系统上承载的数据,因此关键需保护的资产是重要的运营标的。
-
其次,安全运营中,判断攻击是否误报、是否成功、影响大小都需要资产信息的辅证。在这里,资产是多维信息的集合,以帮助研判。如,操作系统、安装的软件、安全域信息、业务系统信息等。
-
然后,安全运营中,实际的运营责任归属,需要资产信息。比如漏洞修复,需要找到修复责任人;比如安全事件处置,需要找到业务/系统的责任人。
-
再次,安全态势研判中,更需要资产信息。比如展示哪些业务系统受攻击?哪些资产漏洞较多?等等。
基于以上分析,资产运营的目标首先应该是围绕关键资产尽可能多、尽可能全的收集管理资产数据。这些资产数据可包括实体类的,如服务器、云主机、终端、网络设备、安全设备;或业务类的,如业务系统,开放服务,或软件类的,如操作系统、应用软件、中间件;或数据类的,如账号信息等。其次是要尽可能动态的更新资产信息,以保证信息的准确可用。
如何收集资产信息?可以学习CAASM的方法,对接多元资产系统,各种可以提供资产数据的系统都是可对接的第三方,如EDR系统、流量分析系统、LDAP系统、资产测绘类系统等等。也可以开放资产新增,资产导入,资产上报等功能。
如何管理资产信息?需要构建资产类信息的管理逻辑,如资产入网的逻辑,什么类型的资产入网需要走什么手续,需要具备什么技术条件;需要构建资产入库、出库的逻辑,如资产从发现到审批入库需要有什么流程和审批确认路径;需要构建资产的管理台账,以方便资产信息的日常运营维护,最好是能够将各类型资产按照各维度进行管理,如资产位置、资产组织归属、资产业务归属等逻辑进行管理。
管理好的资产如何用起来?这是资产运营的关键,日常运营中的日志、告警、脆弱性、工单、大屏等数据,需要跟资产进行关联展示,方便运营;为了方便分项,需要通过资产展示的信息有攻击数量、攻击类型、告警数量、脆弱性数量、待处置工单数量等;运营流程中,人工节点也需要通过资产进行关联,如告警处置责任人,漏洞修复责任人,审批责任人等。在设计安全运营业务时,通过资产可将各业务及流程连接起来,充分发挥资产价值。
资产运营相关的流程有哪些?要运营好资产,也就是要做到及时动态更新资产,可以分两种,一种是新资产,一种是历史资产的更新。针对新资产可以通过资产入网流程、资产入库流程展开运营;针对历史资产更新,可以通过资产变更流程展开运营;当然在其他流程运营时,也可以同步开展资产的运营,如漏洞运营时发现资产责任人已变更,就需要及时同步发起更新流程等。
如何评价资产运营质量?可以通过设定如下指标来评价资产运营质量,如周内资产审核率、资产入库率、资产信息的告警覆盖率等。
脆弱性是老生常谈的问题,也是经常开展的安全业务,很多单位通过采购漏洞扫描系统,开展定期漏扫/整改服务,或者采购漏洞管理系统,通过漏洞闭环管理解决脆弱性问题。下面来简单分析,在安全运营业务中,为什么要开展脆弱性运营工作?应该如何开展脆弱性运营的工作?脆弱性运营和安全告警运营又有什么样的关系?
-
首先,安全事件的发生大概率是由于系统或网络的脆弱性问题而引发,做好脆弱性运营可以降低安全事件发生的概率。这就像一个人身体健康,一般不容易感冒是一个道理。
-
其次,脆弱性运营的几个基本要素是,发现脆弱性问题,管理脆弱性问题的处理,再次验证问题是否存在。因此脆弱性运营的关键目标是形成一个闭环的运营管理流程,不断发现脆弱性问题,消除或控制脆弱性问题带来的影响。
-
最后,脆弱性运营的结果和告警信息可以关联,脆弱性运营的高质量会推动告警运营的高质量,一来可以降低告警量,二来可以辅助告警研判。这也是单独的漏洞闭环系统无法完成的。
因此,脆弱性运营的目标首先应该是尽可能多的发现当前资产中的脆弱性问题,这些脆弱性问题可以包括漏洞、弱密码、配置错误等。其次是要根据脆弱性严重性/影响等级,完成资产脆弱性的修复或缓解闭环,以持续降低资产脆弱性的隐患。
如何发现资产脆弱性信息?可以采纳常规的漏洞扫描系统的结论,可以接受行业监管给到的数据,可以接收来自EDR等主机检测系统给出的数据。将这些多元数据汇集,就形成了一套相对全面的资产脆弱性信息库。同时,也需要提供脆弱性信息新增、上报和接收能力。
如何管理资产的脆弱性闭环?需要构建脆弱性修复闭环的管理逻辑,如脆弱性问题如何下发给资产责任人,资产责任人如何完成修复,修复后谁来确认,如何自动化复测是否已修复,还需要考虑批量的脆弱性问题如何下发和管理闭环,基于资产的批量脆弱性问题如何下发和管理闭环等。需要构建基于上级/行业主管单位下发的脆弱性问题如何修复和管理闭环。需要构建作为上级主管单位如何对下级下发和管理脆弱性问题。简单总结,脆弱性运营相关的流程有漏洞闭环流程、弱密码闭环流程、漏洞缓解管理流程等。
如何评价脆弱性业务的质量?需要构建基于脆弱性管理闭环的SLA评价机制,持续提升运营能力。可以有如下指标,如月内漏洞修复率、紧急漏洞修复时长、无法修复漏洞占比、无法修复漏洞的缓解占比等。当然,还有其他维度的评价指标,如漏洞修复建议的质量等。
大多数场景下谈到安全运营,都是在讲告警运营或安全事件运营,这也是安全运营最关键和重要的业务,风险控制的指标更多依赖告警运营达成。告警运营的目标是更全面覆盖、更准确的发现威胁,更快速遏制和处置威胁,定期复盘经验优化检测分析策略,以期待更进一步准确的发现威胁。
如何更全面覆盖、更准确发现威胁?安全建设的大部分投入都在解决此类问题,从边界部署IPS、IDS、WAF类产品,到主机部署检测软件,到网络侧部署流量分析,到全网收集安全日志,通过SIEM的关联分析能力发现更多威胁,再到基于AI技术的异常行为分析等,都在试图更全覆盖,更准确发现攻击威胁。本文不对此展开详细讨论。
如何更快速遏制和处置威胁?这本质是一个组织能力问题,如果有长期的运营沉淀,就可以做到参考过往经验,快速遏制和处置;当缺少足够的经验时,基于每个告警都要逐一排查、研判,然后制定处置方案进行处置。因此,要达成这一目标,就需要从组织、流程、经验沉淀等方面统筹考虑,本文重点从业务角度进行论述。
-
首先,要完成告警7*24小时排查的需求,需要有常态化的告警监控管理业务,保障所有的告警都经过了排查。针对不同场景的监控业务可设置不同的SLA时效,如重保场景。
-
其次,针对排查后的重要安全告警,要开展研判分析业务,给出处置建议,保障告警处置准确。针对不同场景的研判分析可设置不同的SLA时效,如应急场景、重保场景和常态化场景要有不同。
-
然后,针对需要处置的安全事件,要开展遏制和处置业务,根据处置建议完成处置。针对不同场景的处置可设置不同的SLA时效,如应急场景、重保场景时效要求更高。
-
最后,要开展定期总结和复盘业务,总结经验,优化规则,完善流程,统计绩效。在补充业务中,可设计告警入知识库的业务,告警转预警的业务等。
如何构建运营组织?仅从告警运营角度看,运营组织的建设需要基于安全运营总目标展开设计,如7*24小时运营场景,MTTD和MTTR指标要求相对高,响应及时性达到较高等级,这种情况下的运营组织就需要考虑业务专岗,部分岗位三班轮岗,做好组织机制设计和业务流程设计,并设定好SLA指标,通过一段时间的运营检验,形成稳定状态后,此组织构建基本完成。如果是降低要求,如5*8,MTTD和MTTR指标相对宽松,则可以设计一人多岗,减少人员投入。保证业务可闭环,指标可达成,运营目标可支撑即可。
告警运营相关的流程有哪些?告警运营的相关流程较多,举例如,告警监控流程、事件处置流程、应急处置流程、重保监控&处置流程、预警流程、上级通报事件处置流程等等,流程的设计和运营现场紧密相关,可横向参考不建议直接复用。
告警运营和资产、脆弱性等数据关系?告警的运营中,涉及到研判分析都需要和资产数据、脆弱性数据的关联,涉及到遏制、处置,都需要和资产的责任人数据相关联。因此,资产、脆弱性、告警三类数据最好在一个平台上,一套统一的数据表达格式,方可实现运营效果及价值的最优。
因此,单独的资产漏洞管理系统,无法将告警运营整合;单独的XDR系统,缺少了完整的资产、脆弱性运营能力,也无法实现完整的风险控制的运营目标;资产、脆弱性和告警的运营,三者统一和兼容,才能很好的承接安全运营的总目标。
综上,本文尝试解构了安全运营业务的设计思路,从安全运营目标的设定,到安全运营业务分目标的拆解,再到资产运营、脆弱性运营、告警运营三个运营业务的关键设计思路进行了论述。后续文章会继续分析另三个业务模块,敬请期待。
原文始发于微信公众号(解构安全运营):二篇:解构”安全运营业务“