声明：本文只代表笔者本人的观点，不代表所在公司和部门的意见。

通过网络层面开展基于情报的威胁监测，这是一种非常高效费比的技术方案，也是建设本地威胁情报中心的核心能力之一。然而，我研究过不少落地案例后发现，结果往往非常不尽如人意：要么检测不完全，数据能力没有充分利用；要么安全运营人员被淹没在一堆堆的垃圾告警中，连去看一下的兴趣都没有。为什么会造成这种结果？这源于尽管实现思路简单——无外乎数据的碰撞，但其中还是存在一些误区的：缺乏对威胁情报的深入了解和检测分析活动的实践，甚至有些从最初的架构设计上就决定了不太可能会有满意的效果。下面就我的实践和理解，剖析一下检测系统成功设计和运营的要素。

作为基于威胁情报的监测系统的核心，威胁情报平台（TIP）一般来说是必要的组件，它负责汇集各种来源的威胁情报数据，赋能包括防火墙、IDS/IPS、NDR、SIEM/SOC系统在内各种检测设备和安全分析人员。TIP汇集的情报数据中，直接可以用来执行检测和监测的数据就是IOC（Indicator Of Compromise），还有各类可以支持分析研判的元数据和信誉信息。理想情况下，各种来源的数据以明文形式提供，TIP平台可以方便地进行去重、验证、融合，这对于开源数据应该是可以的，但对于部分商业来源的重要数据则是有问题的。

这里就涉及到商业逻辑：很多TIP厂商也会同时是情报数据厂商，与其他数据厂商很可能存在竞争关系。一般的开源数据也就罢了，数据厂商基本上不会愿意把自己的核心数据落到友商的TIP平台上，这再明显不过的道理会直接导致客户将来行事是事倍功半还是事半功倍。要知道数据服务不同于实现在产品里的逻辑功能，甲方可能觉得自己是出钱的，应该要什么就有什么，但实际上作为乙方的数据提供者天然占据信息优势，完全可以根据获得的商业收益决定输出的数量和质量。客户如果不同时进行多源采购，连个质量比较的机会都没有。由此导出，在检测架构的设计上需要允许安全厂商提供基于非明文数据的检测方案，然后对多家厂商输出的判定结果再做关联整合。如此的架构设计当然很不完美，因为检测数据层面的融合不再可行，大规模的批量关联拓展分析也不行了，但对于一个定位基于IOC做检测的系统来说至少是可用的，而且有望充分发挥多家厂商的数据能力。当然，如果客户预算足够多，全部明文也不是完全不可能，因为这符合价高者得的商业逻辑，但绝大部分客户不可能那样。

在技术限制的层面上，海量基础数据的本地化对绝大多数用户也不可行。被动DNS、样本信息数据、Whois数据条目量巨大且需要经常性更新，需要极大的存储计算资源。即便海量的数据在建设之初有个一次性的落地，日常更新的数据量也是巨量的；即使网络畅通也会消耗大量的带宽，更不用说很多物理和逻辑隔离的网络，基本不可能做到数据的及时更新，数据很快就会过时并与云端失去同步。基于以上这些限制，如果有些客户想在本地构建一个类似VirusTotal效果的系统，除非自身有海量基础数据的收集能力，最好不要轻易尝试，不然基本会以失败告终。

基于威胁情报的检测系统必然涉及情报数据的引入，主要来源无外乎几类：开源采集、商业采购、联盟交换、用户自产。其中能起到核心作用的来源当然是商业采购。开源的数据一般会包括在商业数据中，因为没有一个情报厂商会不把开源采集及其关联拓展纳入到自己的情报生产流程中。情报联盟由于能力不对等导致的贡献不匹配其实很难有效运作，用户自产只能起到非常有限的补充作用。

开源数据鱼龙混杂，收集容易研判难，因为一般用户不太可能同时有：

• 海量的历史被动DNS数据

• 海量的终端活动信息

• 海量的多来源文件样本

• 规模化的动静态自动化样本分析平台

• 看样本就像看一眼片子就知道啥肿瘤的医生那样的分析人员

• 数百万级别的商业基础数据采购

• 不可言说渠道来源的信息输入

事实上，如果用户自己具备如上的资源，那还要专业的情报厂商干什么？本质上，用户采购威胁情报购买的就是情报厂商打包后的基础数据及其分析研判能力。如果只是接入些甚至准确度都非常可疑的告警日志，提取些IP和文件Hash就当作威胁情报就太过家家了。

各家大安全厂商都有自己独有的数据视野：有的自有安全产线齐全，能收很多特色数据；有的主动扫描收集能力强，能积累不少历史记录；有的蜜罐运营得不错，能及时发现新攻击活动；有的社区搞得热闹，有群众能提供线索和拓展；有的钞能力强大，能买不少基础数据；有的能依靠比较强的数据交换联盟支撑。以我对一些厂商数据能力的了解，数据存在相当大的非重合部分，所以，如果费用允许，强烈建议同时采购几家能力厂商的，但最好不要超过三家，因为市面上靠谱的情报厂商也没几家。这里又涉及到一个问题，如何评价各家厂商的威胁情报数据质量，我推荐现网流量环境下的测试，这当然也有很多坑，以后有机会单说吧。

另外，再说一下多源数据的融合，在我眼里这基本是个伪需求，有些TIP厂商号称用了什么AI的技术来融合多源情报，你可以想像两个不同厂商对于某个相同IOC定性矛盾的场景，有限的上下文信息使神奇的AI也不可能帮上啥忙，最终还是得依靠来源厂商的信誉做出取舍。

• DNS请求和回应：最好是递归解析的流量，用于黑域名的检测，定位C2受害者

• NetFlow：主要是5元组信息，用于检测不使用域名的直连IP的C2活动，确认DNS来源告警的真实性

• URL：如果可以通过明文协调获取的话，用于黑URL的检测

• 数字证书：直接定位使用了已知黑证书的网络基础设施或用于后续的关联拓展

• Payload：一般收集的会话的前部的字节流，用于一些恶意代码的检测、确认和排除，确认DNS或NetFlow来源告警的真实性

• 网络应用的指纹：结合漏洞情报定位一些存在漏洞的资产

• 文件样本：配合后续的文件动静态的扫描检测

IOC的特性决定了它主要用于检测已知的威胁活动。一般的流量探针由于性能限制，只会最多加载数十万到百万级别的IOC数据，情报厂商出于显性效果的考虑会优先输出流行度最高的数据以预期产出最多的告警，但最流行的大概率并不是最重要的，因为涉及的攻击活动大多为非定向类型的威胁，而针对高价值目标的定向攻击往往比较聚焦，不太可能出现在高命中概率的优先输出IOC列表中。对于实时流量检测，Kill Chain各个环节中可观测对象并非一直存在，结合加载IOC量的限制又进一步恶化了流量分析引擎中的实时检测效果。

应用IOC除了对当前的状况进行检测，另外更重要的使用场景为追溯过往。作为尽最大可能捞取攻击线索的机制，全量离线异步的匹配计算必须考虑设计到整个检测架构中，元数据想当然的需要保留一定时间的历史记录，以备在新IOC被确认以后回溯过往的历史。在此类场景中，数据厂商的批量私有IOC数据可以通过某种单向Hash的形式，比如布隆过滤器，提交到大数据平台执行批量的匹配，结果统一汇集到态势平台进行融合。当然，海量元数据会对存储、传输和计算带来极大的压力，设计策略和机制去除占大头的白数据可能是个缓解方案。这些元数据统一汇聚到一个大数据计算平台，可以被多个基于情报的检测引擎或设备共享，数据厂商对同一份现实数据给出自己的检测答案，也使评价厂商的现实能力成为可能。

目前我所看到的威胁检测类产品项目中，“重初期建设数据、轻后期运营“基本是一种常态，这也是导致项目的安全效果不佳的主因之一。就我个人经验而言，威胁检测类项目要出成果，数据采购费用应该在整个监测项目占到合适的比例，比如30%以上。

我们必须了解驱动安全检测设备或服务的核心是数据、规则、模型和人员，它们是整个系统的灵魂，没有这些，态势威胁感知系统就跟OA系统没区别。对于情报数据厂商在实际环境下的检测能力表现需要有一个定期的评价机制。在情报数据费用总盘子内根据考核的结果进行倾斜分配，通过奖优罚劣形成良性竞争，使客户自己的数据投入效果最大化。评价标准可以预先商定，然后根据自己业务方向的变化进行适时调整。威胁情报服务是乙方协助客户取得业务成功，反过来客户也需要学会牵引乙方，这当然也对客户本身的能力提出了更高要求。多源数据引入的要义不仅仅在于互相补充视野，更在于通过对产出成果的比较来发现优秀的供应商，并通过赛马形成持续改进的压力，这样对于甲方和乙方都好。

需要强调的是，准确的IOC不等于准确的告警。典型的IOC类型，比如IP、域名、文件Hash，都是些简单的原子化数据。域名之类的访问和非特定端口的IP连接其实非常容易被正常的活动触发，引发不准确的告警。事实上，即便IOC集是100%准确，由此触发的告警可能还有50%以上是不准确的。基于IOC的告警只能作为威胁事件的线索，需要后期的分类分级，通过更多数据和行为的验证、人工经验的介入做进一步的确认，才能形成确定性的事件。

大多数没有得到正常运营的威胁监测系统，特别是NDR类设备，如果每天滚动着上万的告警，其中至少99%是误报或不重要的。没有基本运营的检测系统只会是一个输出垃圾的机器，遗憾的是这样被荒废的系统，我见得实在太多了。如何避免呢？简单的应对是配备必要的运营人员。一个在客户侧运行的威胁监测系统，最少需要配备一个中低技能的驻场和一个高水平人员的远程支持和巡检。本地人员需要有基本的安全知识，进行明显误报的削减，发现自己处理不了的可疑线索转到远程寻求支持。高水平的人员永远都是缺乏的，我也不认为AI能快速地解决这个问题，所以，他们必须在远程同时支持多个点上报的分析处理任务，如此才能在商业上做到支持成本可控。现在很多所谓的专家在提倡多利用TTP类型的威胁情报，在其指导下执行威胁狩猎。我想说的是理想很丰满、现实更骨感。连准确的基于IOC的告警运营都没做到位，对于一般安全投入的客户来说，成本极高的本地威胁狩猎先就别想了，一点一点来吧。

总体来说，情报数据和运营人员的成本需要在项目总投入中划出来，理想情况应该占到总成本的50%以上。只有系统软硬件的建设而没考虑后续运营投入的项目必定失败，不会有例外。

1. 实时流量检测与全量历史元数据异步检测结合

2. 共享同一个元数据事实池，允许安全厂商进行背对背的基于私有情报的检测

3. 多源数据采购和效果比较评价

4. 必须的安全运营人员投入

5. 高投入占比的数据和运营的安排

END