基于风险损失量化模型的网络安全应急处置技术研究
2021-01-10韩志峰郑瑞刚许暖
韩志峰,郑瑞刚,许暖
(1.中移动信息技术有限公司,北京100033;2.中国移动通信集团安徽有限公司,安徽合肥230000)
1 引言
近年来,随着万物互联、人工智能等新技术革命的到来,网络安全进入了大安全时代,涉及到国家安全、国防安全、基础设施安全、城市安全以及社会民生安全。网络安全已经成为企事业单位的支撑角色,并逐渐演变成了生产要素,其重要性不言而喻。
整个网络世界一直在动荡中发展。自从云计算、大数据、AI等技术大范围应用后,网络攻击者们更加肆无忌惮,早已实现网络攻击武器的升级。面对这样严峻的挑战,作为安全防守者,应及时提升安全防护能力水平,应用更加科学合理的技术手段,及时发现和阻止每一次的攻击行为。
过去二三十年,国内主流安全能力建设的重心放在安全防护、阻止和检测等领域,但在安全响应环节仍然存在很大的短板。越来越多的企业开始重视安全应急响应,尤其是应急响应处置的速度、质量。
今天,很多大型的企业或组织已经能够较为准确地识别一起安全攻击事件,但在响应处置环节仍然存在重大短板。尤其是对风险严重性的判断、风险遏制手段的决策和风险响应措施的执行,缺少科学合理和自动化的应对机制,导致安全响应频繁落后于攻击者。其很大一部分原因是缺乏可靠地风险损失量化评估模型,无法第一时间给出量化指标为响应处置提供决策依据。
2 主流安全风险处置逻辑
主流网络安全事件风险处置的框架或逻辑是:通过有效的感知系统收集各类系统的日志、活动和告警,之后通过相关的分析技术(可以结合AI、大数据)判定安全事件的风险等级,然后予以告警通知,或采取初始的响应动作。主流风险识别与治理框架,如图1所示。
针对安全风险处置逻辑,目前国内外已有相关的机构或企业在开展各类尝试。总体来说,先要对风险进行计算,之后开展对应的处置措施。常见的风险计算主要有定量、定性和两者结合等方式的计算。但此类风险计算逻辑往往偏于单一场景和静态数据,缺乏动态调整和决策能力支撑,对后续安全策略下发缺少足够的实战参考价值。
以某省级移动运营商为例,过去多年的网络安全建设已经取得一些成绩,各类检测手段、防护策略也已经部署,但落实到具体的安全事件处置时,往往在风险识别、计算和决策等环节仍然需要大量的人工参与和不确定性。这导致事件处置和响应缺乏可衡量的机制,无法做到经验和逻辑的传承和复制,不利于综合安全能力的建设,更不能满足新时代下网络安全攻防场景的综合挑战。
3 国内风险计算和处置现状
国内主流厂商或企业的风险计算逻辑和处置策略通常缺少量化指标,风险计算维度单一,风险处置粗暴,总的可以概括为定性计算为主、过度依赖专家经验、缺少可复制性。
3.1 定性计算为主
大多数安全事件风险计算以定性计算为主,例如给出高、中、低或紧急、重要、一般、轻微等说明,告警信息通常以图文方式在产品仪表盘进行展示,缺乏可以数字化衡量的基础。
3.2 依赖个人经验
风险计算依赖工程师经验。同样一个SQL注入告警或Webshell利用事件,不同的工程师给出的严重度判断是不一样的。单纯看安全设备告警信息,普通工程师可能会定级为很高,但是了解攻击行为和影响范围的人员可能认为是个低风险。
3.3 缺少可复制性
数据判定取决于样本库或人员主观逻辑,不具备动态适配能力。因为风险判断结果不同,导致响应所采取的措施也不同。而且风险判断依赖人工,数字化衡量不精确,导致风险处置逻辑不具备可复制性。
4 国外风险处置发展现状
国外一些新型的攻防理念和技术通常较为领先,在安全风险计算和处置领域也早已诞生一系列的标准。通常的风险计算适用于风险评估,而作为事件响应处置的风险计算虽然有量化方式,但仍然缺少动态适应的能力,并且与国内环境也存在适配的问题。
4.1 标准的模型仅适合资产风险评估
图1 主流风险识别与治理框架
已有的风险计算模型主要是信息安全风险评估领域的ISO27005标准,通常从资产维度做风险评估,不适合对安全事件进行风险评估。应对实时变化的安全攻防事件,现有的风险评估模型和方式显然不能满足需求,安全防护者必须寻求新的突破。
4.2 风险计算过程僵化
资产通常是一个固定的对象,围绕资产计算的因素也是固定的,因此容易通过简单的输入得出一个风险值。但事件通常是动态的,而且每个事件发生的上下文并不一样,因此其风险计算逻辑和处置逻辑与普通资产完全不一样。传统风险计算的量化模式过于僵化,缺少上下文知识关联。
4.3 自动化风险处置剧本依赖专家经验
一些企业或机构已经意识到动态风险计算和处置的重要性,并开始了相关的探索,例如:IACD框架正在寻求实现自适应动态风险治理。虽然已经有了自适应的思想,并采取了自动化的手段,但风险计算和决策逻辑本身仍然落后。已有的安全策略剧本仍然需要专家提前完成,并且针对风险处置的逻辑需要不断调整,严重依赖人员。
4.4 缺乏国内业务特征支撑
此外,国外相关的技术实现和规范往往有与其适配的技术场景和业务特征。相较于国外环境,国内企业或组织的安全管理需求、方法和机制有很多差异的地方,还不能直接照搬。安全手段和技术的使用要适配国内业务特征适配,对大型基础设施企业、重点机关单位等组织更是如此。
5 现实安全应急响应的痛点
网络安全应急响应通常需要企业内部多组织、多人员相互配合,完成一起事件的处置。这样事件运营过程通常需要安全系统或人员基于已有的安全告警信息,进行综合风险判断,最终决策要采取的响应动作。但现实应用场景与理想的标准模型存在的巨大的差异,实际响应过程中有很多痛点和问题。
5.1 业务系统间存在依赖路径
业务系统之间的通常有这个相互依赖或关联的关系。企业业务逻辑比想象的复杂得多,不仅仅是简单的几个网站或系统。现在信息系统往往都是分布式、集群模式构建,分为前端、中台、后台和底层数据等模式。系统内部有层级依赖,系统之间有相互依赖关联。例如管理系统需要调用SSO单点登录系统,业务系统需要与OA系统关联等,如图2所示。
当一个系统出现安全风险或者问题时,受影响的可能还包括其他系统。因此,评价一个安全事件所产生的风险,需要更加科学、合理的计算方法。
5.2 缺少信息关联导致告警不准
传统安全告警基于配置检查或漏洞扫描,依赖于特征库覆盖范围和特征库的更新。漏扫不及时,不准确都会影响到告警和后续处置。安全事件日志的完整性、及时性和准确性也会影响已有的告警统计分析。传统的安全风险发现都是单个时间点的状态值计算,即使增加了一些关联分析,也是继续静态数据的叠加计算,仍然存在误报、漏报的问题。
6 基于风险损失量化模型的应急处置方法
6.1 主要思路
经过过去几年网络安全事件运营的积极参与和快速、高质量的安全应急处置策略的持续探索,文章针对上述遇到的问题和难点,给出了一种基于风险损失量化模型的网络安全应急处置的技术对策。基于此,传统的安全风险计算和处置的逻辑和质量将得到更大的改进优化。
图2 业务系统依赖关系图
要解决风险计算难以量化,过于依赖人员,容易产生单点依赖,不支持动态更新的问题,尝试着从如下思路解决:构造一种新的风险损失量化模型计算方法,将事件类型、严重度、资产严重度、系统依赖关系等等因素纳入到风险计算逻辑,由此打破僵化,拒绝静态,规避单点计算。
6.2 实现方法
基于风险损失量化模型的网络安全应急处置方法,是对当前主流风险计算和处置的一种优化,是安全攻防实战过程的实践与总结。为满足应急处置风险决策要求,系统设计需要遵循必要的原则,例如清晰的定义系统、科学地计算数据,数字化体现风险和损失。参与风险和损失计算的关键要素至少包括:资产严重度、漏洞严重度、受影响资产和被依赖资产、当前系统安全风险等级。
传统风险计算表达式主要是面向单资产的风险计算,以风险计算因子的乘积作为最终结果,如:
风险 = 威胁×影响×可能性
基于风险损失量化模型的计算方法实际上要计算多个依赖项各自的风险,并将结果再根据一定的逻辑合并,从而产生本次计算的数值。
以某个安全攻击事件为例,针对目标资产的直接风险计算逻辑如下:
A = 资产重要性(金额), V=漏洞严重程度(百分比;表示资产受影响的概率),L=当前内部网络整体风险等级 (百分比,表示对漏洞防护的失效率)。
核心逻辑是 f'= A*V*L,注意这里的A,V,L通常都表现为概率分布(比如我们无法确定多少用户可能会受到一次攻击的影响),因此最终结果由将以数值模拟得出:f=MC(f'),MC表示蒙特卡洛模拟。伪代码如下:
Sum <- 0
for (i from 1 to 1000) {
A <- random(A_min, A_max);
V <- random(V_min, V_max);
L <- random(0, 1);
Sum <- Sum + A*V*L
}
r <- Sum/1000
由于目标资产可能是其它关键系统的依赖项,因此根据依赖路径,其它系统可能也存在风险,我们将其称为间接风险。以网站遭黑客SQL注入导致用户信息泄露为例,直接风险表现为老用户失去信任、不再使用产品带来的经济损失。间接风险是由此带来的政府罚单、排查问题、修复系统、长期的信誉损失等等。每一项间接损失,都可以按照前述直接风险的计算方式来进行量化,数据是可复用的。
综合风险由直接风险和所有间接风险的求和得出:
R=最终风险数值, M=风险计算模型
d=依赖被攻击资产的一个对象,可能有多个对象
模型M是针对当前目标资产风险和依赖该资产其它项的综合风险计算模型。通过该模型可计算出某个攻击事件可能产生的最终风险损失数值。
此外,用户还可以从信息安全三要素C、I、A角度对模型做细化,计算在不同侧重面的风险损失数值,从而满足不同场景、不同业务的风险管理要求。针对机密性、完整性和可靠性的影响,可采采取的响应措施也不尽相同。
M' =风险计算模型变化版
C=保密性、I=完整性、A=可用性
风险计算的数值取值有一个集合空间,例如[0,9]。安全人员可以根据具体需要动态调整名参数和输出格式,从而实现适合自身的风险损失量化计算过程。下图是整个风险损失量化模型下,网络安全应急处置的整体流程,如图3所示。
根据不同的风险数值可以决策出要开展的应急响应处置动作,典型的风险处置的决策选项包括网络封禁、应用封禁、通知告警、提升系统风险等级、冻结用户账号、用户降低权限、启动防病毒升级等等。
6.3 应用落地
技术团队一直在探索尝试将基于风险损失量化模型的网络安全应急处置技术应用在某企业内部的网络安全防护平台的风险处置环节。迄今为止,该平台已经集中了态势感知安全告警、CMDB(配置管理数据库)、资产系统、业务关系拓扑、知识图谱和安全剧本编排能力。其中关键环节是在安全剧本中使用模型计算的结果进行智能化的风险决策,根据风险计算的结果给出风险处置的手段,并在特定场景下直接采取风险处置手段。
目前该技术思路已经在成熟使用,重点实现了动态风险决策、自适应风险治理等目标,如图4所示。
如图4所示,图中的主要逻辑是安全事件发生后,系统会根据事件的严重度、资产的重要性、资产漏洞弱点信息和受影响的可能性等做基础风险计算,之后使用两个以上的风险计算模型,对资产及依赖该资产的其它资产项风险做综合计算,最终获得综合风险损失精细化计算数值。
这个数值在实际应用中可以体现为损失的金额,根据事先确定的风险等级定义,转化为风险等级。系统根据风险等级及风险类型智能决策要采取的措施,如资产单点隔离、资产网段隔离、系统账号停用、攻击流量清洗等手段,如表1所示。
图3 网络安全应急处置的风险计算和处置决策流程
表1损失数值金额与等级映射关系(示例)
自适应的风险治理除了需要能够动态计算安全事件风险数值并予以决策支持外,还需要能够和企业内部安全管理系统打通,实现动态获取全局风险,并根据事件风险实时更新已有的系统风险等级。只有这样风险计算才不会成为单个事件的过程,而涉及到全局系统,成为真正意义上的自适应安全防护,该过程如图5所示。
如上图所示,安全威胁被发现后系统自身的整体风险等级也参与了模型计算。根据最终计算结果,识别出要执行的安全策略。而当安全策略执行完成后,再次执行风险计算模型,同时更新系统整体综合风险等级。通过该过程,安全风险计算不仅仅与单个事件有关,更增强了与整体系统风险的关联关系,使得自适应安全风险治理在技术上成为可能。
图5 风险损失量化模型参与整体系统风险等级计算实现自适应安全防护
7 技术应用价值
通过基于落地风险损失量化计算模型的网络安全应急处置技术,企业可以实现真正动态自适应的安全风险治理。以一个具体的事件为例。
态势感知告警:“某个员工账号被攻击者盗用,正在通过一个CDN IP地址访问CRM系统。”
针对上述场景,主流的风险计算逻辑会判定为一个风险等级很高的安全事件,需要安全人员对访问这IP地址立即采取封禁措施。但针对来访者IP地址进行直接封禁过于暴力,容易导致正常用户访问企业服务受到影响。
通过本文提到的基于风险损失量化模型的网络安全应急处置技术,系统可以根据该事件自身的严重度、受影响系统、访问来源、访问途径等方式计算出一个数值。根据该数值可以决策出多个安全处置措施,其中操作影响度最低的是:冻结该员工账号。系统可以优先自主决策和执行该策略,然后同步通知安全人员跟进。
越来越多的应用实践表明,基于风险损失量化模型的网络安全应急处置技术可以为企业带来革命化的安全运营体验,总体受益在多个方面都有体现。
(1)降低误报,提升告警准确度
企业业务系统纷繁复杂,每天面临各类攻击威胁,安全告警事件量大,误报问题严重,应急响应工作应接不暇。通过实施基于风险损失量化模型的安全应急处置系统后,收效明显。由于风险计算逻辑更加科学,风险判定的准确性大幅提升。误报率下降带来的效果是安全告警处置决策更加精准、智能,响应更加有目标,效果更好。
(2)缩短时间,提高应急响应效率
因为有了自动化、智能化的决策依据,安全事件处置速度更快,响应时间大大幅缩短,处置效率得到了提升。部分场景甚至可以无需人工参与,做到7×24小时自动化运营。
8 结束语
本文探讨了一种基于风险损失量化模型的网络安全应急处置技术方法。通过该方法,企业或组织可以改进当前安全事件运营过程中风险计算不科学,决策依据不足,响应不及时的问题。该方法和策略已经在相关企业的实践中得到应用,并取得了一些成绩。基于该方法的探索和落地事件,企业将获得高速、高质量的安全事件响应风险计算方法,综合安全风险处置能力得到更大的提升。
9 术语
SIEM:Security Information & Event Management,安全信息事件管理。
SOC:Security Operating Center,安全运营中心。
IACD:Integrated Adaptive Cyber Defense,集成自适应网络防护。