![âå¨èæ
æ¥âçå¾çæç´¢ç»æ]()
文丨中文（e1knot）
美团安全工程师，负责集团整体威胁情报与态势感知能力的建设，曾在DEFCON China、ISC等会议上分享了多个威胁情报应用的案例与方法。
随着用户数量、业务量的增长，互联网企业的业务系统也变得越来越复杂，大量的访问日志、庞大的代码仓库、数十万或百万计的IDC资产以及几万种开源组件构成了庞大的业务系统，但是随之而来的是大量的威胁，体现在了可产生告警的设备数量非常大，使得产生的告警非常之多，并且部分告警是完全无效或者不可运营的。正是由于告警数量的庞大，安全运营团队背负着巨大的心理压力和负担去处理，最后发现是个误报或者说是个无意义的告警，久而久之安全运营就会疲于应付告警，这个时候一旦有攻击出现，往往就会在很短的时间内失去整条防线，也就是经常说的一个段子：每年在安全上砸了一堆钱，但是实际上还是很容易被人家打进来了。庞大的资产、日志、流量，加上海量的不可运营的告警，也就间接对业务系统产生了大量的威胁。
通过对各种角度上的威胁进行梳理后，我们可以把整个互联网企业可能面临的安全威胁分为三大类，一类是以通用组件漏洞、僵木蠕为首的面向基础设施的威胁，第二类是以业务系统缺陷、越权漏洞为代表的面向业务系统的威胁，第三类是以POI/UGC爬取、欺诈流量（也就是刷差评/好评的）等面向业务数据层面的威胁。有了威胁，才能去谈威胁的情报。
在梳理完上述威胁后，笔者第一时间也去问询了一些同行业的朋友，但是老朋友的反馈多为“买买买”，当然这个可以理解，因为最省事儿的方法就是买买买，但是仔细思考之后，笔者发现了“买买买”之后会衍生出来一大堆的问题，比如说如何评价威胁情报做的好不好，这也是笔者在接手威胁情报能力建设之后被老大挑战的最多的问题之一；第二个问题似乎更现实一点，那就是威胁情报团队的绩效怎么去给，或者说如何评价威胁情报团队的工作对整个安全建设工作是有实际意义的，这两个问题其实在企业里面是常见但是不太好作答的问题。除了评价和KPI的问题，威胁情报本身由于先天的滞后性和本身的缺陷，也有很多不是很好解决的问题，由于问题多了所以便有了以下的段子。
首当其冲的是情报的准确性，很多情况下我们抓到一条情报之后，无从判断真伪，更有的时候直接抓到了就直接定性是虚假情报了，这样无形增加了很多的运营成本。第二个问题就是消息不对称，很有可能情报从原始处获取到了之后，由于生产的问题导致情报出现了失真，最后拿到手里是残缺甚至是错误的情报，安全运营拿到了之后不知道如何处理这类的情报，在这里举一个例子，在漏洞预警中，可能不小心没有注意到告警描述里面的prior，导致了影响版本的误判。
第三个问题其实更比较常见，我们买了很多IOCs、买了很多情报服务，数据量可能非常之巨大，但是实际上能拿来运营的往往就那么几条。举一个很常见的例子，我们在购买的IOC中只会提及IP是个扫描器、是个僵尸网络，从来没有人主动了解也没有人去询问他扫描了哪个端口，被哪个家族的僵尸网络bot控制了，更有甚者会将一些公司的正常资产标记成恶意的，这个时候没有人为威胁情报的结果负责，标签就变成了无意义的话题。安全运营的同学见的多了自然就会对威胁情报产生了严重的质疑，再加上前面提到的安全运营会因为海量的告警出现了告警懈怠，导致真正有用的情报没有能够及时处理，让真的威胁情报变成了”无效情报“，变成了为企业添堵。
最后就是情报的滞后，举个很简单的例子，就是通用漏洞的威胁情报。通用漏洞的情报很多时候都是看到朋友圈大量转发或者群里大面积讨论才知道有漏洞了，实际上这个漏洞很有可能是很早之前就发了修复补丁大家完全没注意的。
再举个很现实的例子，在今年7月12号的时候Squid（一款Web代理软件，广泛用于各大企业中）发布了一次安全更新，安全更新提到了包含认证、溢出等五个漏洞，CVSS评分最高6.8，但是到了今年8月底的时候，ZDI的一篇文章彻底引爆了这个漏洞，导致朋友圈疯狂转发，我们抛开这些告警来看，实际上这个漏洞已经有了一个月左右的窗口期，这就是典型由于消息滞后所导致的重要情报漏过，这个时候也会对企业的系统造成威胁。
这个时候，绝大多数都会想到，我们要去建立一套完整的威胁情报体系和运营流程，但是这个时候往往又会收到老板的连环追问:
● 买了威胁情报服务是不是全接进来？● 威胁情报数据质量是否有保证？
● 能不能及时产生有效的威胁情报通知或者工单？
● 工单有没有人跟进闭环或者处理？
● 解决以后有没有事后复盘等等问题接踵而至…
看完这些你可能有点想放弃了，但是经过仔细考虑一下自己的KPI之后，你会发现买买买的方法并不能解决这些问题。所以这个时候你就会考虑构建自己的威胁情报能力了。威胁情报的这一概念实际上是2013年被Gartner带火的，Gartner对于威胁情报的定义是: 威胁情报是一种基于证据的知识，包括了情境、机制、指标、隐含和实际可行的建议。威胁情报描述了现存的、或者是即将出现针对资产的威胁或危险，并可以用于通知主体针对相关威胁或危险采取某种响应。就目前看，这一定义对整个威胁情报行业甚至是安全行业都有一定的指导意义，但是这一个定义的普适性很高，正是由于其普适性高的原因直接导致了我们在企业实际安全运营时候发现，Gartner所定义的威胁情报并不适用于实际的安全运营场景，原因是未对业务层面上的威胁进行定义。如果要建立一个完整的威胁情报体系，那么就必须要把业务系统、业务数据等业务层面的攻击面以及闭环流程也纳入进来，这样的话我们对于针对企业各个层次上的威胁都有对应的威胁情报能力，这就是我们所认为的真实环境下应具备的威胁情报能力：能够为发现潜在或已发生的威胁（包括但不限于业务数据、业务系统和基础设施）提供有效且可靠的消息类型或者知识类型的数据，且该数据能够通过安全运营进行高自动化的闭环处理能力，称之为威胁情报能力，提供的数据称之为威胁情报数据。
诸多血淋淋的案例和运营经验告诉我们，威胁情报的能力构建不是简单“买买买”就能搞定的，“买买买”不能解决实际的安全运营问题，这个时候我们就需要自己打造威胁情报能力体系了。但是在正式开始威胁情报的建设前，我们需要明确威胁情报能力的一个指标，也就是如何去评价威胁情报能力建设的好坏，我们通过内部的讨论以及我们对于安全运营的经验和实践，为我们的威胁情报能力设置了四个比较现实的目标：低延时、高精度、可运营和能闭环。
所谓低延时，目标是为了减少安全应急团队的等待时间，缩短威胁响应的时间，并且尽量减少人工的介入，让威胁情报能力能够几乎100%自动化的运营，减少因为人为原因而等待的时间，同时又保证有效情报的输入和处理，所以自动化率和有效情报转化率是在这部分需要关注的问题。所谓高精度，指的是采集威胁情报数据的渠道足够稳定，质量足够高，来源足够可靠，并且通过高准确度的算法来让情报的精准度和内容丰富度达到可运营的标准及以上，这里就需要考验情报生产算法和情报渠道的可靠性和稳定性，稳定的情报数据和渠道是高品质威胁情报的基石。
所谓可运营，是指我们的情报成品也就是FINTEL（全称为是Final Intelligence，在情报界的表示交付的情报成品）的质量是否能够高可读、高可用同时具备闭环的特性，这个时候可操作性成为了评价这部分的指标。
最后就是能闭环，前面提到了情报如果不能够运营和闭环的话，实际上就是无效情报，这个时候的考核指标可能就是闭环成工单的数量。
在确定了清晰的目标之后，就应该开干了，我们在建设威胁情报能力体系的过程中，把整个威胁情报能力体系划分成了四个部分：1. 威胁情报数据
2. 情报生产工具
3. 情报管理平台
4. 安全运营团队
这也就是外界所说的人+数据+平台的方式建设体系。
这里数据既包含了内部的诸如流量、日志、安全设备告警，也包含了外部的IOC、风控情报、第三方商业情报等外部情报数据，平台这部分比较好理解，主要是为了提高运营效率，理想中的威胁情报平台至少需要包含采集端、生产端和传送端，其中采集端主要负责聚合各个来源的数据并且完成诸如分类、去除杂讯、去重等预处理工作；生产端负责的工作主要完成的事情是对威胁情报的修饰、加权分析、高阶聚合操作，将威胁情报由预处理数据转换成可用的情报成品FINTEL；而在传播端则是将不同种类的情报成品FINTEL按照需求和运营方式传递给不同的人，完成后续运营和闭环的工作。截止到目前，我们在现有威胁情报体系中已经建成了一个基于威胁情报生命周期且兼容现有安全架构的威胁情报运营体系，同时建成了两个情报平台和三个数据库，两个平台其中一个负责完成情报的闭环管理，我们叫它MT-Nebula，另一个完成情报按需推送，我们叫它MT-Radar，三个数据包含用来刻画外部资产画像、外部资产指纹数据库，用来存放通用组件漏洞的漏洞信息数据库，以及集成了公开IOC、自爬取情报和第三方商业情报的外部情报数据库。在此基础上，我们也建立了四个情报反馈渠道，包含人工、自动化、第三方和SRC，我们的SRC是既收漏洞也收情报的。
首先我们先来谈一下企业的威胁情报生命周期，根据我们的业务特性和运营与闭环模式，我们根据实际的安全运营经验和威胁情报的一些理论知识将威胁情报能力的运营和信息的闭环分为了四个阶段，分别是：威胁情报策略制定、威胁情报采集与分析、威胁情报成品交付与情报运营和事后的复盘分析。我们认为威胁情报能力应该是一个规划导向的安全能力，并且威胁情报计划是一个高度可操作的详尽计划，所以在日常的威胁情报工作中，我们对情报规划这一部分看的很重，甚至一度认为没有规划后面做的很多东西可能都是错的甚至是完全相悖的。在实际操作中，我们可能有35%甚至更长的时间和精力是在做一个可操作的威胁情报计划，计划的内容包含了评价的指标、不同类型情报的运营与闭环的策略、需要接入哪些类型的威胁情报、情报与资产数据的交互标准、交付规范等问题。好的规划确实会事半功倍，同时也会让运营效率更高。其次是威胁情报能力建设工作中技术含量最高的一部分，情报采集和分析，在这部分主要的工作点是数据完整性确认、情报数据预处理、分析建模、精加工和修饰调整。目前从效果来看的话，在粗处理阶段引入机器学习的分类方法，会使后期情报数据精加工的工作变得异常容易，但是在精加工阶段，机器学习又显得非常”添乱“，一方面是因为客户的需求众口难调，另一方面是准确度的问题。在精加工完毕后，我们需要对FINTEL添加佐料，佐料的作用是为了后面增加情报的可运营性。
下一步进入了一个非常重要且非常难做的环节，威胁情报成品的交付和运营。如果前面做了详实且可执行的威胁情报计划，在这里就变得轻松了许多，按部就班按照计划执行即可，需要考察威胁情报的准确性和闭环成工单的数量，威胁情报运营手段与其他的安全运营手段相比没有什么特殊之处。
最后一个阶段就是威胁情报运营结果的复盘和总结，这部分主要是为了解决情报反馈出来的问题，也就是所谓的“分锅大会”，这一点往往是情报产生实际价值的时候。值得注意的是，情报的计划可能会随着多个case的积累而发生改变，并且解决问题不应该是追责，而是应该闭环。
当我们完成了对威胁情报能力生命周期的构建之后，下一步就是基于这一部分周期来设计一个完整的威胁情报体系。在设计这一部分体系的时候，首当其冲要考虑的应该是威胁情报体系应当兼容现有的安全体系，其次，要完全按照情报的生命周期逐渐累加必要的数据和分析方法，最后将这些能力和威胁情报生产算法平台化和规范化。
我们在经过一段时间的运营和实际的应用的结果来看，结合我们现有的安全能力和体系，我们的威胁情报体系如下图所示，该体系分为了五个层次，分别对应上文中威胁情报生命周期中的四个环节，规划部分对应策略制定环节，数据研判、情报处理、情报分析对应采集与分析环节，情报运营、闭环处理和复盘分析分别对应情报运营环节。
在情报规划阶段，我们需要考虑的内容是我们会面临何种类型的威胁、我们如何去收集发现这些威胁所对应的威胁情报、收集到的威胁情报如何加工成我们想要的FINTEL成品、成品如何交付和运营、闭环策略分别是什么等问题。紧接着就是数据研判，所谓数据研判第一件事情是先确认内部的数据是否完整、可用，因为内部数据的不可用很有可能会影响后面的数据交叉分析，除此之外，外部情报也要保证按照事先的情报计划接入对应的数据，保证数据是充足的，我们在综合了业务安全情报和基础安全情报后，优先考虑接入了黑产情报渠道监控、Github监控和人工反馈渠道，而老生常谈的IOCs、OSINT数据、第三方商业情报数据甚至是我们自己构建的指纹数据库，则以API的形式对外提供检测服务，允许其它安全设备接入获取对应的数据，达到为安全赋能的目的，同时我们允许人工反馈情报，实现现有情报源的有机补充。
当数据准备完毕后，接下来就是情报数据的预处理环节，预处理需要解决的问题包含：情报来源格式不统一的问题、情报来源不可信的问题、情报素质低的问题、情报重合的问题等，在经过预处理后，我们将会得到一个具备初步可分析条件的威胁情报数据，成为粗产品。
在拿到粗产品后，我们需要对粗产品进行进一步的精加工，其目的是为了保证情报满足我们最初设计的目标，达到目的和效果。在经过分析后，我们就会得到完整的情报FINTEL成品。
紧接着我们在得到FINTEL成品后，会通过各种形式让情报进入运营状态，这些形式不拘泥于表象，包括但不限于工单、信息推送等。同时在这里，平台化的能力沉淀就显得十分重要。到此，我们的情报能力矩阵就介绍完毕。
以上内容让我们对情报体系有了一个初步的了解，但是作为技术能力最强的分析，我们需要详细阐述一下情报的分析过程，为了方便大家的理解，我会以漏洞情报作为例子来阐述一下具体的操作，整体流程如下图所示：![]()
首先在一条情报进来之后，他可能是多种形式，可能是一个微信群聊的截图、一篇新闻，也有可能是一条Twitter，大概率也可能是一个很丰满的JSON数据，至于STIX、TAXII、CyBox这种也会存在，那么这个时候我们就需要将这些数据通过各种方法整合成我们大概能看懂的一个粗产品。我们以漏洞情报为例来说明，当我们拿到一个原始的漏洞数据的时候，他可能是一个GitHub上的issue，也可能是一封来自于Openwall的邮件，更有可能是某个群里一句话，通过绝大多数的实验和实际场景，我们认为邮件是一个比较好的切入点，因为既包含了issue又包含了openwall的列表，所以我们往往会以邮件作为重要的情报来源之一。在获取上述情报来源后，需要对情报进行初加工，这一部分依赖的技术主要是OCR技术和NLP技术，OCR技术的作用是用来识别图片中的文本信息，提取出其中的文本，达到了图片转文字的效果，在这一部分处理后，我们剩下的多为文本情报了，这个时候NLP技术将会帮助我们提取其中的关键信息如词性、词频等，比如说专有名词、时间等，获取到这些信息之后，我们将会把这些分析结果向量化，使用机器学习方法（如目前的机器学习网红算法XGBoost）对这些词进行聚类，然后通过自己训练的模型将关键信息分类，整理到一条数据结构中。对于我们的漏洞而言，在上一步获取到源数据之后经过上面提到的方法，我们整理出了以下内容，当然内容不完全正确。很明显这个时候情报仍然是不可用的，因为虽然有了漏洞信息，但是情报仍然不可读、不可用，这个时候我们就需要通过其他的情报进行交叉填充，完成对情报数据的补充，如上面提到的漏洞，详情可以通过MITRE和NVD的官方数据库获取详情。由于我们获得了版本号，所以在CPE数据或者SWID数据中，我们可以拉取对应厂商对应产品下该版本的所有分支版本，这样就可以获得完整的影响范围。另外我们也可以从官方公告中获取CVSS数据，来辅助判断影响范围。这个时候，我们大概就得到了一个详实的数据结构，但是这仍然不是我们想要的FINTEL，这部分只能作为情报的粗加工产品，传递至精加工的流程。在我们拿到粗加工的情报产品后，我们会和内部数据进行交叉分析，同时引入数据的校准机制，目前这部分工作绝大部分依靠人工，少部分依赖正则表达式，同时我们还会对情报封装快捷操作和功能，将一些必要的英语通过翻译API翻译成中文方便运营的理解，并且通过不同的影响范围，人工或者自动地调整情报成品中各个情报源的比重来完善这一情报生产模型，这一过程称之为情报生产模型的迭代，再经过人工修饰后，我们就得到了情报的FINTEL成品。一个好的FINTEL必须满足以下条件：保证情报内容可在短时间之内读懂，所有评估所需要素一应俱全，提供闭环所需解决方案，影响范围一目了然，方便后续运营闭环操作。当然同类型FINTEL的交付模式应有对应的交付验收，以保证情报FINTEL满足运营团队的运营需要。
接着上面的漏洞情报，我们最终交付的情报成品是这样的。通过上述的运营方式，我们一般可以最少提前行业内的预警十几个小时获知此漏洞的存在，目前获取的最长时间差为7天时间。
生成的威胁情报成品如果还有包含信誉类检测的功能，我们应当保证这些功能是被安全设备调用的，这也是威胁情报赋能的一种表现。企业内部的安全产品如果按照生产环境和办公环境划分的话，生产环境的三大件是IDS、WAF和防火墙，办公环境的三大件是DLP、EDR和邮件网关（绝大多数EDR厂商的前身都是杀软厂商，所以杀软和EDR在好的产品中应该是打包的）。对于各自的三大件，情报的赋能限于检测和查询，如以下的告警则是和HIDS进行联动的应用场景。当然业务层面上的情报，除了与反爬系统联动之外，最好的应急方式是拉群定损，这个时候情报的评价就会体现在快不快上，因为快意味着损失会少，产出会更明显一些。在庞大的复杂系统下去干威胁情报，难度不亚于刷王者级副本，从获取威胁情报到完全闭环一个告警是一个极其困难且有很大挑战的过程。虽然很多企业在构建威胁情报的时候都不约而同的选择了以买买买为核心的情报能力构建，但是一直“买买买”实际上不能解决“未运营的威胁情报不会产生任何使用价值”的问题。其实威胁情报能力对于企业安全的价值最重要的两点是减少信息不对称带来的损失、赋能于安全提高威胁发现率。但是由于行业内各家对于威胁情报的理解和看法都不尽相同，所以在威胁情报具体落地实施的情况下都是各走各的路，各有千秋。但是我们始终认为威胁情报是规划导向的产物，在实际威胁情报运营和闭环中，我们发现很多问题在规划阶段就可以完全避免这一类问题的发生。所以在构建企业级威胁情报能力的时候，往往坑在规划，重在生产，难在运营，结果取决于闭环的结果。
但是即使做好了，在面对考核和评价的时候，往往也要给自己定一个小目标，也就是评价威胁情报能力好不好的四大标准：速度快、情报准、可运营、能闭环。有了体系，就需要将能力沉淀下来，构建人+平台+数据的解决方案，在威胁情报体系建设中，情报体系、自动化平台、数据资源、获取渠道都是会影响威胁情报能力的关键指标，过程不重要，在结果导向的环境下，FINTEL的好坏才是成败的关键，因为FINTEL的好坏直接决定运营难度，好的FINTEL需具备易读懂、可操作、能运营的特性，让运营同学一看就能用。
虽然各家对于威胁情报的看法不尽相同，但是希望这篇文章阐述到的观点能够成为一个可供同行参考的模型，这才是真正意义上的威胁情报为行业赋能。
美团安全部的大多数核心人员，拥有多年互联网以及安全领域实践经验，很多同学参与过大型互联网公司的安全体系建设，其中也不乏全球化安全运营人才，具备百万级IDC规模攻防对抗的经验。安全部也不乏CVE“挖掘圣手”，有受邀在Black Hat等国际顶级会议发言的讲者，当然还有很多漂亮的运营妹子。目前，美团安全部涉及的技术包括渗透测试、Web防护、二进制安全、内核安全、分布式开发、大数据分析、安全算法等等，同时还有全球合规与隐私保护等策略制定。我们正在建设一套百万级IDC规模、数十万终端接入的移动办公网络自适应安全体系，这套体系构建于零信任架构之上，横跨多种云基础设施，包括网络层、虚拟化/容器层、Server 软件层（内核态/用户态）、语言虚拟机层（JVM/JS V8）、Web应用层、数据访问层等，并能够基于“大数据+机器学习”技术构建全自动的安全事件感知系统，努力打造成业界最前沿的内置式安全架构和纵深防御体系。
随着美团的高速发展，业务复杂度不断提升，安全部门面临更多的机遇和挑战。我们希望将更多代表业界最佳实践的安全项目落地，同时为更多的安全从业者提供一个广阔的发展平台，并提供更多在安全新兴领域不断探索的机会。
发表评论
您还未登录，请先登录。
登录