从EDR到威胁情报运营——浅谈终端化的情报部署

0x00 前言

emmm,一个多月没更新专栏了,主要原因是因为工作太忙了(在乙方舒服惯了到了甲方真的有些不适应)。由于工作的原因,目前在威胁情报的投入时间基本上也就投入了20%,剩下的时间都砸给了一件之前想都不敢想的难度的事儿上。boss说让搞安全得向全地球最牛逼的互联网公司Google看齐,于是乎20%的就放在这了。


0x01 站在风口上的猪——EDR

今年如果关注了RSAC2018的话,相信你一定观察到了EDR是名副其实的站在风口上的猪,实际上从2017年开始,无论是国内还是国外,各家安全厂商都在鼓吹EDR的重要性。所谓的EDR就是终端检测与响应的缩写(Endpoint Detection and Response),也就是关注与终端,保证终端的安全。那么威胁情报作为一项安全技术(而非数据),是不是也会跟站在风口上的猪一样终端化呢?有人肯定会说,你娃又在这里瞎扯淡了,威胁情报不就是一堆数据么,怎么处理这些数据和数据源才是重点,且不说放到终端上有没有用,就问你打算发什么放到终端上就是个很大的问题,所以终端化对于威胁情报就是扯淡,数据才是王道懂么?!那么威胁情报就真的不能终端化了么?

0x02 威胁情报与EDR——Alienvault Endpoint Threat Hunter

实际上在今年年初的时候,笔者最看好的威胁情报平台之一Alienvault OTX就已经上线了Endpoint Threat Intelligence的产品,名为Endpoint Threat Hunter,入口:AlienVault - Open Threat Exchange,这个产品的产品逻辑很简单:

  1. 首先你先要注册一个OTX账号(废话)
  2. 在你的服务器上安装Alienvault的Agent
  3. 部署完了之后在控制台上启动Agent然后进行预查询
  4. 等结果吧

在这里就可以使用rpm/deb/msi安装agent(实际上是基于OSQuery开发的),识别的方式为你的API_KEY。通过他们的描述我们大概就知道了,Alienvault的这个产品就是为了给匹配IOC,然后在终端上直接完成了检测,这样的话就完成了威胁情报的终端化。Agent将会收集设备数据并存储在OTX中,包括计算机名称,主机名称,外部IP,操作系统类型和版本。扫描返回其他数据,这些数据完全显示在“扫描结果”视图中。 这可能包括文件路径,IP地址和端口(源和目标),正在运行的进程的命令行,进程ID,进程工作目录,系统文件(SHA-1,SHA-256,MD5)上的文件散列。

Alienvault这样做的原因我大概推测了一下,可能是受到EDR思路和威胁情报生命周期的特性的影响,下一部分我们将讨论威胁情报的生命周期和运营。

0x03 威胁情报的生命周期和运营

上面说了这么多,就目前看来,绝大多数人搞威胁情报干的实际上就是一件事情——收集信息,这样的话就变成了:我们有威胁情报平台,我们关注了全球所有的N多安全信息源,关注了oss-security,关注了各种漏洞平台的漏洞情报,我们数据全球No.1。但是实际上这么做的话犯了一个很严重的误区,首先在企业安全里面任何的安全措施都必须要闭环(这是我boss说的,虽然我认为他说的没错),只有措施闭环了,才能谈运营,所以在安全运营环节比如漏洞响应跟进修复都是标准的workflow和生命周期的。所以威胁情报也是有生命周期的,那么威胁情报的生命周期是什么样的呢,我用一句话概括:一个中心,五个阶段。具体的话先上图:

左边待会儿在解释,先看右边。右边这个model实际上就是威胁情报的生命周期,大概来简述一下吧:

  1. 制定情报计划,确定我们需要交付何种类型的情报
  2. 按照情报计划,收集我们需要情报数据和原始数据
  3. 对原始情报信息进行预处理和应用场景分析,确定适用的范围和目标
  4. 按照情报计划,分析与处理之后的数据,生产最终的情报(也就是所谓的FINTEL)
  5. 输送FINTEL至客户(也就是安全运营团队)并使用情报
  6. 情报有效期结束,重新制定或修正现有的情报计划,进入下一个循环

所以威胁情报按照生命周期的话,核心应该是制定计划,然后完成收集、处理、分析生产、输送、完善修正现有情报计划的一个流程,这个也就是所谓威胁情报运营闭环。

好,现在说了那么多,我们再来强调另一个点:威胁情报的落地是case驱动而非是数据驱动的,所谓的case就是威胁情报的模型(比如攻击者的攻击套路)。如果你把威胁情报当作数据去理解的话,可能上述内容理解起来较为困难,在这里我希望大家把威胁情报当作facility和operation的结合去理解,你就会理解上面的内容了。

接下来我们看slide的左边,左边其实和右边是没有关联的,只是为了单纯方便排版。左边的几个point说明的实际上是对威胁情报团队考核的几个点(也就是KPI),由于本文不讨论详细的运营步骤和方式,所以这里说的简单一些:情报源、应用场景、FINTEL、情报计划、运营workflow这些是评估威胁情报运营能力的几个点。

0x04 面向终端的情报输送

本文的题目是威胁情报的终端化,所以按照前面我们说的生命周期,我们在输送情报的时候实际上就两种情况:面向机器和面向人,面向机器是直接把相对应的规则推送到机器上实现点对点的情报署,面向人就是直接输送给人,让人去处理。当然在这里我们讨论的是前者,因为后者实际上也是输送到机器,只是输送的成品会变成二次加工的FINTEL。

我们在制作输送模型的过程中应考虑以下几个问题:

  • 我需要输送何种类型的情报:YARA规则?MD5?IPtables规则?etc.?hotfix补丁?
  • 我需要输送面向何种目标的情报:中间件?核心技术?etc.?
  • 我需要收集目标的何种信息:中间件版本?操作系统版本?所用技术的名称和版本?
  • 我需要用何种介质输送终端情报:Agent?规则列表?运维脚本?

弄清楚了这些问题,你也就制作完成了一个对应的情报输送的计划,我们紧接着就是收集这些相关的情报,这里你可以选择爬虫、购买、自己获取等方式,取决于你的成本和你的精力。我们的理想情况是捕获到重要的情报,安全运营的同学在评估完毕后可以手动推送情报到终端,完成布防。

插一句:这里的情报不一定是一种,可以是一个完整的package集合,甚至是可以源自于一起安全事件,输送的实际上也就是所谓的case。举个例子,我现在截获了一个情报,有一批丧心病狂的人利用redis的漏洞挖矿,他们的主要手段和某安全社区里面提供的套路如出一辙,我们这样就可以直接在终端上部署一些我们对他们攻击行为分析的针对性情报:比如扫描特征、样本YARA规则、C&C服务器、矿池地址等,一旦检测到了,立刻就可以调用case的预案,完成对同类型事件的免疫。

0x05 总结

在威胁情报实际上有很多时候适合常规的安全运营模式一样有完整的闭环,我们不应该一味的追求数据上的大多,而忽视了一些实际上会用到的情况,只要有效,技术再lowbee也是值得的,无效但高大上的技术,往往做出来也就是个玩具(你懂的)。毕竟安全不是PR主导,而是实打实的效果检验。