基于安全大数据的威胁建模与自动化响应

点击蓝字关注我们

施泽寰：在实际工作中，企业一般会采购不同厂家的安全产品，构建自身的安全防御体系，这也导致了需要采集的数据类型繁杂，所以一般我们前期需要根据规划（比如根据网络区域，安全风险，威胁场景等因素），对不同类型的数据（像安全设备、网络设备、系统日志、应用日志以及流量等数据）进行采集，并在完成相关数据采集之后，再对数据进行范式化。而在范式化的过程中，如果没有内置的解析规则以及灵活的解析能力，就需要对相应的数据源逐个进行解析，这会耗费大量的实施时间，从而导致在上层应用场景的分析/交付上投入不足。

结合日志易实际经验，我认为日志处理和安全检测是一个包含全数据采集、数据清洗、数据存储查询、数据分析、威胁建模等一系列环节在内的威胁统一管理的全过程。其面临的挑战主要有三个：

一是（用户环境中的）数据采集以及清洗等日志基础处理能力的不足。这直接影响到安全威胁检测模型的构建。在很多环境下，我们看到在进行了日志统一管理之后，实际效果并不突出，可能最终只是沦为了一个日志存储平台。安全数据资产得不到真正有效的挖掘和利用，深层价值凸显不出来，因此对于安全数据资产的深度管理和有效利用是目前日志统一管理所面临的一个挑战。

第二个是告警噪声太多。随着企业安全管理与防御体系的不断发展，即使是一些中小企业，每天各类安全设备/系统产生的告警数据都是数以万计的，在如此量级的数据下，难以通过人工的方式，逐一进行响应处置。同时，也需要从噪声（安全设备所产生的误报）中去提取真正的攻击行为，所以通过基于聚合、统计、关联分析以及安全场景等模式构建威胁检测模型，与外部数据（如情报数据，资产信息，漏洞信息等）进行匹配，提升告警精准度是解决这一挑战的有效途径。

第三个是安全人员缺乏。随着企业安全管理与防御体系的不断发展，绝大部分企业安全人员负责的工作内容也不断增加，除了各种设备的维护，日常的日报、周报以及月报等，安全合规管理，项目管理等已经耗费大部分人力，更遑论进行常态化的安全运营（如威胁检测、威胁分析以及威胁响应等）。所以这也是目前MDR市场逐步火热的一个原因。当然，自动化响应也是企业解决上述一些重复性安全工作的一种解决方案。

我们目前已经在SIEM安全大数据分析平台中，内置了解析规则库，支持国内外主流的设备/系统的数据预处理，也支持多种解析方式（如正则解析，划选解析，KV解析，XML解析，JSON解析，数据脱敏，自定义规则解析，字段补全等方式），可大大提高数据清洗的交付效率。同时，我们还基于不同类型、不同品牌的安全相关数据，定义了一套数据标准，统一对数据进行范式化。

施泽寰：以日志易的安全分析平台为例，它是基于自研的高性能搜索引擎（Beaver）的威胁检测、响应与分析平台。Beaver可以满足企业用户安全大数据搜索和安全威胁建模基础需求，并提供了安全态势，威胁处置，调查分析，资产管理，漏洞管理，规则管理，任务管理，情报管理等能力。基于历史长周期数据以及实时数据，针对企业内外部威胁进行检测、分析以及响应，并通过自动化能力，帮助用户减少发现/响应威胁的时间，提高安全运营效率。

业界有个术语叫做“威胁狩猎”，指的是安全人员产生假设，进而围绕着这个假设，对安全数据进行主动分析与验证。一般由某个告警事件/异常事件，如用户权限发生变更（可疑提权）为出发点，展开调查分析，又或者因某个指标异常，如DNS请求数激增、DNS子域名字段熵值激增，进而展开威胁狩猎。日志易的安全分析平台基于自研搜索引擎Beaver，并通过SPL（Search Processing Language）灵活及迅速地完成某类威胁的狩猎。SPL语言是专为实现对日志这种非结构化数据进行搜索、分析而开发的处理语言，它实现了数百个SPL函数及指令，全面覆盖日常安全分析工作的需要，并对接了多种机器学习算法，以实现安全场景的异常检测。

无论是边界突破、还是内网横向移动等不同场景下的攻击，都可以通过SPL中的不同函数对相关的安全数据进行分析处理，从而发现可能存在的异常；此外，日志易安全分析平台，还具有图分析功能。通过把企业用户的安全数据以及相关的信息，如资产信息、漏洞信息，可视化为一个攻击关系图，从而去发现一些可能存在异常的实体。这些实体可能是一个IP、一个主机、一个用户或者是某个域名等等，然后再对这些实体进行展开进一步的调查，去发现威胁告警、异常事件与其关联性，实现对安全威胁与风险的探索与调查分析。所以日志易的特点在于基于自研的自研搜索引擎Beaver，通过SPL（Search Processing Language）与图分析为用户提供灵活的安全分析与威胁建模能力，实现不同维度安全数据（安全设备告警，流量、主机日志，应用日志，情报信息，资产信息以及漏洞信息等）的关联，从而探索企业网络中可能存在的异常事件，并进行攻击链路回溯。

施泽寰：首先，我们把数据类型概括为两个维度，一个是网络维度，如来自防火墙、WAF等网络、安全设备的数据；以及HTTP、DNS、TLS、SMB、DHCP等协议的流量数据；另外一个是端点维度，如主机系统日志（Linux/Windows/AIX等），HIDS/EDR的数据，基于特定的安全场景、不同的数据源可生成不同的规则。我们的安全分析平台威胁检测规则库主要基于1000+的规则场景库，而且规则库也是基于外部态势、项目实践以及安全研究，不断进行更新迭代。

而目前市场，主要有黑名单检测与白名单检测两种思路。黑名单检测思路一般以聚合、统计、关联分析（特征匹配，情报关联、时序关联等）作为规则场景的主要落地模式。例如：当在某个安全设备（如WAF或IPS）发现了一个攻击来源，未知攻击者采用通过该IP地址发起多次不同类型的漏洞利用尝试，虽然从告警结果上看都未成功，但是此时发现被攻击的对象（资产），此后在某段时间后（这里的时间周期定义需要衡量）出现了一些异常行为（比如出现新的账号或原有账户出现权限变更等行为），那么从攻击角度上看，有可能出现WAF Bypass/IPS Bypass等（小概率事件）的情况，那么两个事件之间会存在关联性（指的是多次漏洞利用尝试与账户异常行为之间），可以将其配置为关联规则，当触发告警时，值得我们更加关注。所以这种安全场景就属于一个威胁检测规则。

另一种白名单检测思路，一般有异常检测模式。一般来说，在企事业单位中，大部分的事件（比如系统层上发生的事件、网络层上发生的事件）都是属于正常事件。而异常事件，一般都是小概率事件。我们需要去发现这些小概率事件，如执行不常见的命令，出现不常见的父子进程，第一次出现的进程，第一次出现的账户，静默账户（比如30天没登录行为）出现第一次活动等，所以也需要基于历史的数据构建正常基线，之后再与实时数据进行对比，进而发现异常行为，这也是目前一类规则场景的落地方式。

施泽寰：基于我们的研究与实践，我们认为自动化响应实现的前提是要确保告警的准确度，威胁检测模型要能够输出精准的分析，然后再将这些告警交给自动化响应平台（或者说模块）去处理。如果告警的误报率很高，噪声很大，这种情况下做自动化响应是没有意义的，反而会影响到业务。所以，SIEM是实施SOAR的前提。

目前的安全事件自动化响应过程是怎样的？举个例子，当平台检测到了边界区域一个WEB类的攻击事件（比如某个简单场景：某个源地址发起多次SQL注入或某个源地址发起多种不同类型的攻击向量）后，能够自动地针对这一攻击事件中的源地址进行情报查询判断，并智能地根据情报查询结果，判断该攻击IP是否已经被标记为恶意标签；如果它被标记为恶意标签，并且已经在平台封禁列表中，系统则结束响应流程；如果不在平台封禁列表中，则再进一步判断，该IP地址是第一次出现还是此前出现了多次，并根据它出现的频率智能化、自动化地联动边界安全设备实现不同时长的封禁，这是一个常见的的自动化响应过程。

而人工响应主要是指通过人工来针对一些不在自动化安全知识库（或者说不存在对应的Playbook）中的安全事件或者说一些可疑线索进行响应处置。人工响应也包括了分析工作（类似于前面提到的威胁狩猎），因为这是一个基于不同安全场景下，分析各种问题并做出决策的过程，而从我们看来，自动化响应前期需要人工响应的验证，判断某类安全事件是否可以采用固化的自动化分析响应流程，同时也需要企业单位各个部门（比如由安全部门主导，业务相关部门，网络相关部门参与）之间去进行评审，对流程无异议后，便可形成自动化响应流程。

所以自动化响应和人工响应之间的配合，以现实环境来看，很难达到对所有的安全事件都进行自动化响应。而自动化是由人工分析响应衍生出的产物，人工响应始终具有重要意义。具体的分配情况，在具备安全运营相关技术与流程制度的前提下，我们认为80%的安全事件应该交给自动化响应流量进行处理，人工专注于20%的安全事件的深层关联分析与响应。

施泽寰：国外SOAR市场相对国内市场较为成熟，目前我们看到主要有两种技术路线，一种为以Case Management为目的，以Splunk Phantom为代表，一种是融合了Chat ops的理念，也衍生出如作战室的功能，以Demisto（被Palo Alto收购，改名为Cortex XSOAR）为代表，但其最终要达到的目的都是相同的。即降低对安全事件的处置时间，提高响应效率。

其中Case Management的方式来看，以Event（事件）和Case（某个事件或者某些事件形成的）作为驱动，通过定义好的Playbook（剧本）来实现整个流程的自动化响应。这种技术路线实现层级和理念也非常明确，更接近一种决策思路，所以要实现SOAR的能力，也就是要具备可视化流程编排（通过拖拉拽的方式，快速定义剧本）、组件化（应用管理）能力和任务管理能力。

从架构而言，第一层级是剧本（Playbook），其中包含了流程的决策步骤（如过滤、判断、格式化以及人工审核等基础能力）和应用组件（如某类安全设备的某个接口，自定义的API接口）；第二个层级是应用，即集合了某个产品的所有接口，可在Playbook中提供选择调用；第三个层级是动作（Action），即对应着具体的某个接口，比如情报查询接口、IP查询接口；第四个为资产，比如说企业中部署了10个防火墙，这就是10个资产，在编排Playbook的时候，需要定义和哪一个资产进行联动；第五个层级为用户，系统在对资产进行联动的时候，需要安全设备上一个有相应响应权限的账户去进行联动。

而在联动的过程中一般会有两类动作，一个是“读”的动作，一个是“写”的动作。“读”的动作就是通过接口从安全设备或其他第三方系统中获取信息；“写”的动作就是通过接口，往安全设备或其他第三方系统添加/更新/删除新的策略，比如说，把某个IP地址写到防火墙的黑名单中以此来实现对恶意IP的阻断，通过用户来实现权限控制。

第二种路线其实与第一种殊途同归，融合了Chat ops的理念。在某个安全事件发生之后，在对其进行响应处置过程中，需要增强各个部门之间或不同人员之间的协作，并能较为智能地推荐合适的处置动作。这种路线就是将这一逻辑和理念延伸到SOAR中来，其实就是结合攻防对抗历史经验，通过加强安全体系中各个产品和模块之间的主动调用和深度配合，来实现更智能的自动化响应。

施泽寰：未来安全响应处置从我们的研究与实践情况来看，还是会朝着自动化与智能化的方向发展，应用场景（不仅仅只是一系列的分析判断后，去封禁IP/锁定账户）也会越来越丰富。而且随着安全编排与自动化响应的发展会帮助安全人员从重复性的安全运营工作（比如威胁管理）中脱离出来，让安全人员能把更多的精力投入到安全分析层面的工作中去，由此来发现一些潜在的或者威胁更大的安全风险，这种风险对企业造成的危害性往往会更大，所以我们也认为，对威胁狩猎场景的探索也会进一步深入。

同时，自动化响应也可以更加智能。举例来说，平台在触发告警之后，可以基于过往同类型的案例进行综合评估，为用户推荐一个合适的处置策略和解决方案。所以，在我们看来，自动化和智能化是未来安全响应处置的两个发展特点。