【论文阅读】Sharing cyber threat intelligence:Does it really help?

威胁情报共享

2024.2-分享网络威胁情报：真的有帮助吗？

我觉得这篇文章像一个做的很完整、考虑很多方面细节的测评工作的技术博客，整个结构就是树形的，提问，总结，再更小的研究点再提问，再总结，如果是博客的话可能读起来反而会更清晰，而文章被拆成论文的结构就要上下来回翻看。这个CTI-Lense框架也不是很像框架因为实际做的测评工作细节都没有体现在框架图中，更像一个工作流的总结吧。

这个文章标题问的，一个很大的问号，好像是质疑STIX的标准，真的有抽取出来威胁情报最本质核心的内容来共享吗？但读完就发现不是这样，而是就在STIX的标准下，去评价这个标准哪里在实践中被很好利用，哪里在实践中有不足。只不过做的工作真的很全面。

我在想如果只是数据集构建和评估工作，只要工作量足够，问题问的恰当，就也能发NDSS吗？为什么能发NDSS，可能动机正是直击威胁情报领域的痛点，问的问题又很恰当，然后工作量很大图画的比较好，自构建的数据集对未来其他研究很有用？在原文的附录中有写道开源地址
https://www.ndss-symposium.org/wp-content/uploads/2024-228-paper.pdf

摘要 提出了一个名为 CTI-Lense 的框架，用于从公开可用的 CTI 来源列表中收集和分析STIX数据的数量、及时性、覆盖范围和质量等四个方面来进行评估。

动机：以往的开放式CTI研究主要集中在有限范围的基本IoC数据类型上，而高级的 CTI（例如 TTP、威胁参与者、安全规则和 APT 活动）如何有效共享很少有人研究。

尽管有STIX的可用性，但在实践中没有有效传播。比如①其数量无法覆盖所有的网络威胁且提供商生成的STIX具有很高的重复率、②时效性无法保证、③标准中指定的许多对象和属性在实践中并未使用、④STIX 数据具有不正确的威胁参与者或不完整的信息，等四个方面的问题。

RQ 针对以上四个方面的问题，提出了以下四个研究问题

RQ1 公开生成和共享的 STIX 数据的数量如何？即评估每天共享的唯一 STIX 对象的计数，以确定公开共享的 STIX 数据量是否足以覆盖大量新的网络威胁。

RQ2 发现网络威胁后，STIX数据的共享速度如何？即评估从最初检测到威胁到公开发布相应 STIX 对象的时间间隔，以确定数据的及时性。

RQ3 公开共享的STIX数据在多大程度上涵盖了广泛的网络安全威胁？即评估分析了 STIX 对象和属性在公开可用的 STIX 数据的大型数据集中的分布，以确定 STIX 标准的实际覆盖范围。

RQ4 STIX数据在表示网络威胁的正确性和完整性方面的质量如何？即评估STIX 数据中的对象和属性是否根据 STIX 标准准确使用，以及生产者是否正确分配了有效值，以确定数据的可靠性。

STIX标准 旨在表示各种复杂的网络安全威胁信息，如APT、威胁行为者及其关系。STIX中包含的威胁信息被描述为Indicator对象和其相应Title 和 Type属性，其中包括可观察对象、指标、TTP、漏洞利用目标、行动方案、活动和威胁参与者。

STIX标准实例https://oasis-open.github.io/cti-documentation/stix/examples

STIX 生态系统中的实体：

①标准化组织（例如，OASIS）发布了STIX规范

②生产者（例如，安全分析师）根据 STIX 标准分析网络威胁并生成 STIX 数据

③生产者通过由 MITRE 或 AlienVault OTX 等服务提供商管理的平台（例如，STIX 数据存储库或 TAXII 服务器）共享 STIX 数据

④消费者使用标准协议（如 Git 或 TAXII）从此类平台获取 STIX 数据

⑤消费者利用这些数据来分析安全事件或最大限度地降低网络风险

CTI-Lense框架和dataset

最左侧一列分别是不同的数据集；

①编译了来自七个公开可用的 TAXII 服务器和三个存储库的 STIX 数据集。主要将 STIX 作为的 CTI 数据集进行分析，根据其对象和属性评估数量、及时性、覆盖率和质量

②“incident”数据集是来自 Malpedia、安全新闻网站和 CVE 的叙述性文本数据集。包含标题、描述和出版时间，用它来衡量及时性

③“APT report”数据集是卡巴斯基等知名公司的安全专家报告的另一个叙述性文本数据。包含有关恶意 IoC、威胁参与者和恶意软件类型的信息，用它来评估 STIX 数据的质量

④“AV report”数据集是从三个广泛使用的扫描服务（VirusTotal、MetaDefender 和 HybridAnalysis）收集的 JSON 格式的 CTI 数据集。包含反恶意软件扫描结果和 IoC 提交时间，用它来分析 STIX 数据的及时性和质量。

注意，数据集①是作者的自创数据集，时间跨度从2014年10月31日到2023年4月10日，共收集了6,362,065个对象（是从10,392,889 个数据中去重得到的，其中STIX 1收集了3,894,595个，STIX 2收集了2,467,470个），数据来源于七台TAXII服务器：AlienVault OTX,Hail a TAXII, IBM X-Force Exchange, Cyware,PickupSTIX, Unit42, and Limo from Anomali以及三个开源仓库：JamesBrine,DigitalSide, and MitreAttack。在聚合公共STIX数据源时，参考了STIX官网以及其他论文列出的84项服务，但最终只选择了10项（删除的原因是有些服务需要付费、或者无法访问、或者作为STIX却无法用TAXII 服务器共享）。

PS，作者在把xml格式的STIX 1转化为json格式的时候用了一个开源仓库https://github.com/STIXProject/python-stix

实验设计

RQ1 数量和重复率：

计算不同来源每天共享的 STIX 数据对象的数量

计算不同来源的每月共享 STIX 数据的数量

比较基于唯一属性值的对象来测量源内部和源之间的重复 STIX 数据的比例

RQ2 及时性：

计算安全事件发生后，STIX数据需要多长时间才能公开发布

计算STIX数据的公开后，主流扫描服务（如VirusTotal 、HybridAnalysis和MetaDefender ）的注册时间

进行了Granger因果关系分析，以确定安全事件的发生是否会导致STIX数据对象的更多共享。

RQ3 覆盖率：

计算数据集中的对象和属性的数量，并将它们与 STIX 标准中指定的总数进行比较。

覆盖率随时间推移的变化。

RQ4 质量：

计算不正确的值和不当使用，关注每个 STIX 版本的三个对象中的值，

STIX1: Indicator, TTP和威胁参与者

STIX2: Indicator,恶意软件,和威胁参与者

不正确的值是指违反 STIX 正确性的错误值实，可能是拼写错误，大小写错误

不当使用是指值存在于对象中，但未分配给精确属性的情况，比如可能需要检查了 TTP 的值（12cc14bbbc421275c3c6145bfa186dff）是否真的与 Lazarus 组织相关联。需要使用安全专家撰写的威胁报告来了解事实真相，不当使用是指也有可能是错误的属性，比如为真正的属性写在了description中。

ATMDtrack应该是Malware Instance，而不应该存在于Description中

不同的生产者会对Indicator对象的质量有影响吗?

实验结果

• RQ1 数量和重复率（在数据集①上）：

  • RQ1.1计算不同来源每天共享的 STIX 数据对象的数量

    

    在数据集①中，从2014 年 10 月 31 日至 2023 年 4 月 10 日，总共共享了 10,392,889 个 STIX 对象，相当于平均每日共享 3,371 个 STIX 对象。在总共 10,392,889 个共享的 STIX 对象中，只有 6,362,056 （61.22%）在所有数据源中是唯一的。因此，平均每天只有 2,063 个独特的对象被公开共享

    超过 9,419,073 个对象 （90.63%） 是通过 TAXII 共享的，973,816 个对象 （9.37%） 是从外部仓库共享的。在 TAXII 上，前 3 个最常见的数据源是 AlienVault OTX、Hail a TAXII 和 IBM X-Force Exchange，而外部仓库里JamesBrine 最为普遍。

  • RQ1.2计算不同来源每月共享的 STIX 数据的数量

    

    在数据集①的时间跨度上，红色区域表示 STIX 数据量快速增加的时期，而蓝色区域表示量快速减少的时期。

  • RQ1.3比较基于唯一属性值的对象来测量源内部和源之间的重复 STIX 数据的比例

    表二后两列是STIX 数据源中在同一源 （In dup.） 和不同源 （Out dup.） 中重复 （dup.） 对象的比例。共享对象的数量与各种数据源中的重复数量没有直接关系，共享对象数最多的 Hail a TAXII 的重复比例最低。相比之下，通过 TAXII 共享的 STIX 2 数据的重复率相对较低，但通过外部存储库共享的数据的重复集中度较高。

总结 STIX 1 的共享频率高于 STIX 2，但 STIX 2 数据的共享最近显着增加，同时也有新的来源。数据主要来自AlienVault OTX、Hail a TAXII和IBM X-Force Exchange等领先的安全公司，主要通过TAXII。这种集中意味着开放的STIX数据集主要依赖于少数几个来源。虽然各提供商之间的重复数据水平较低，但各个提供商内部仍存在大量重复。这强调了在部署之前删除重复数据的必要性。总体而言，自 2016 年以来，共享 STIX 数据的趋势一直在上升。

• RQ2 及时性（在数据集②和④上）：

  • RQ2.1 计算安全事件发生后，STIX数据需要多长时间才能公开发布

    重点关注了两种臭名昭著的网络攻击：Mirai僵尸网络和WannaCry勒索软件,测量从VirusTotal首次检测日期开始，每次攻击的恶意软件样本的哈希值作为属性值共享到 STIX 对象中所需的天数。

    对于恶意软件变体，随机选择了 100 个恶意软件哈希值

    

  • RQ2.2 计算STIX数据的公开后，主流扫描服务（如VirusTotal 、HybridAnalysis和MetaDefender ）的注册时间（在数据集④上）

    比较了STIX数据的生成时间与热门扫描服务上相应数据的提交时间，如VirusTotal 、HybridAnalysis和MetaDefender等病毒样本库。我们特别关注 Indicator 对象中存在的 Observable 属性，因为 Observable 属性包含四种类型的数据类型之一：IP 地址、域、文件哈希或 URL，一些服务中不包含这些日期的就没考虑了。

    从 VirusTotal 收集了 70,997 个文件哈希和 374,973 个 URL，从 MetaDefender 收集了 31,290 个文件哈希，从 HybridAnalysis 收集了 14,924 个域、10,179 个文件哈希、836 个 IP 和 8,055 个 URL。然后将 Indicator 对象的时间戳属性与 HA 、MD、VT的首次提交时间值和扫描开始时间值进行比较

    

    图 5 显示了每种数据类型的 STIX 数据生成和扫描服务数据提交之间的时间差。例如，HA-Domain 表示域数据在 HybridAnalysis 中出现与相同域数据在 STIX 中出现之间的天数。这些差异是通过从每个服务的数据提交时间中减去 STIX 数据生成时间来计算的。如果时效性为正值，则表明STIX数据的生成速度快于服务的提交时间。

  • RQ2.3 进行了Granger因果关系分析，以确定安全事件的发生是否会导致STIX数据对象的更多共享。（在数据集②上）

    为了获取每日安全事件的数量，我们收集了 Malpedia 的 12,133 篇帖子、热门新闻网站的 15,671 篇帖子以及 STIX 数据集同一时期发布的 151,431 个 CVE。利用Granger因果关系，通过将时间滞后从 1 天变为 30 天来分析因果关系。微弱的证据表明，Malpedia 和安全新闻网站上报告的安全事件与数据集②中共享 STIX 数据之间存在因果关系（ STIX 数据在 Malpedia 和安全新闻网站报告事件后分别在 2-4 天和 2-12 天后共享，p < 0.05）。 然而，我们没有发现任何重要的证据表明CVE的发布与STIX数据共享之间存在因果关系，所有时间滞后值的p>为0.05。

总结 STIX 数据的生产者会在安全事件发生后的 2-4 天内积极生成和共享它们。然而，除了域名和URI数据外，STIX的功效尚未得到证实，因为大多数STIX数据的生成速度比其他商业服务慢得多。

• RQ3 覆盖率（在数据集①）：

  • RQ3.1 计算数据集中的对象和属性的数量，并将它们与 STIX 标准中指定的总数进行比较。

    首先分析了数据集，以确定这些生产者最常使用的对象类型（见表IV）尽管 STIX 1 和 STIX 2 分别定义了 8 种和 20 种类型的对象，但其各自的数据集中仅使用了 6 种 （75%） 和 15 （75%） 种对象类型。使用最广泛的对象类型是 Indicator，无论 STIX 数据集的版本如何，它占比都在 90% 以上，之所以广泛使用是因为它们包含可观察对象，例如恶意软件的哈希值或 URL 字符串。

    PS，尽管与 STIX 1 相比，STIX 2 中使用的属性数量似乎更多，但我们发现造成这种差异的主要原因是 STIX 2 定义了几个额外但简单的元数据，例如 Created、Modified 和 Spec 版本

    

    因此我们进一步研究了 Indicator 中使用的属性，表 V

    几乎所有的 STIX 1 指标对象都包含 Title （100%） 和 Observable （99.92%） 属性。相比之下，标签（32.62%）和指标类型标签（17.13%）很少使用或根本不使用。

    

  • RQ3.2 覆盖率随时间推移的变化

    分析每个源的对象和属性使用情况，以分析随时间推移的覆盖趋势。每个源提供的对象类型和属性的数量总体上也在增加，但随着时间的推移，对象类型的数量仍然有限。

    每个源的 Indicator 对象中每月使用的平均属性数

    

    每个源每月使用的 STIX 对象类型的平均数量

    

总结 STIX数据主要基于Indicator对象，占所有数据的90%以上。大多数 Indicator 对象都包含简单的入侵信息指示器，例如恶意文件哈希或 URL 字符串，而其中少数对象包含用于检测网络攻击的安全规则或用于检测或预测多步攻击的攻击步骤的信息。此外，我们发现用于 STIX 数据的对象类型和属性的数量因数据源而异。

• RQ4 质量（在数据集①③④中）：

  • RQ4.1 恶意软件、TTP和威胁参与者的不正确值

    通过查询三个数据源来生成威胁行为者和恶意软件家族的真值数据集：Malpedia 、MITRE ATT&CK 和MISP GitHub作为GT

    结果发现两个 STIX 版本的 19% 的威胁参与者对象都包含 TTP 名称或恶意软件名称。此外，STIX 1 和 2 中 62% 和 58% 的 TTP 和恶意软件与任何条目都不匹配。

    

    造成这种不匹配的原因是部分STIX生产者在给恶意软件、组织命名时用了部分简写、或者大小写、或者拼写错误

  • RQ4.2 恶意软件、TTP和威胁参与者的不当使用（在数据集③中）

    验证 Observable 属性的值，例如 Threat actor、TTP 和 Malware，只有在STIX 1 中的威胁参与者属性是准确率比较高，STIX 1 中TTP、STIX 2中的威胁行为者和恶意软件属性都很低。

    

    除此之外，还讨论了 Indicator 对象未精确地使用属性的情况，威胁信息存在于description中，而不是其真正所属的属性，

    

  • RQ4.3 Indicator（在数据集④中）

    从三个服务中检索扫描报告：VirusTotal、HybridAnalysis 和 MetaDefender，收集了不同类型可观察的indicators的值，包括恶意软件、域、URL 和 IP 地址的哈希值，它们对应于 FileObjectType、DomainNameObjectType、URIObjectType 和 AddressObjectType 属性作为GT（即数据集④）

    结果发现总结了从三个服务处收集的报告得出的统计数字。我们总共在 Indicator 对象中查询了 672,985 个 Observable 数据，分别获得了 VirusTotal、HybridAnalysis 和 MetaDefender 的 652,452 条（96.95%）、623,492 条和 655,213 条（97.36%）报告

    

    每个源的 FileObjectType 、URIObjectType数据几乎可以在所有三种扫描服务中找到，准确度很高。但尽管大多数（超过99%）的AddressObjectType数据和DomainNameObjectType数据都存在于所有三种扫描服务中，但它们的检测率较低。

    特别的更详细地分析了 672,985 个 STIX 数据的 VirusTotal 检测结果。根据阈值评估准确性，该阈值表示报告阳性的异常检测引擎的最小数量，选择的阈值范围为t = 2到39。当阈值设置为小于20时，大多数可观察类型的精度变为 0，但FileObjectType 的准确度超过 90%，表明，STIX 提供了有关FileObjectType的已验证信息。

    

  • RQ4.4 生产者对Indicator质量的影响（在数据集④中）

    很好奇 STIX 数据的有效性是否因生产商而异。为此，我们按生产者划分了 Indicator 对象，并将它们与 VirusTotal 检测结果进行了比较。将 Indicator 对象分为三组：来自具有已知身份的生产者（phishtank.com 和 dshield.org）的对象和没有生产者信息的生产者。基于两年内共享的 672,985 个 Indicator 对象的 VirusTotal 扫描报告。

    具有生产者名称的Indicator对象中，99.99%由 phishtank.com 生成，准确率高达 99.79%，远高于没有生产者名称。有生产者名称的 URIObjectType 对象的准确性高于没有生产者名称的对象的准确性。但是，在 AddressObjectType 对象的情况下，情况正好相反。dshield.org 上的15个对象的准确率非常低，为6.67%，明显低于没有生产者名称的对象（50.63%）。因为这些对象用于指定 IP 地址，而 IP 地址具有易失性，且评估样本过少，只有15个。

    

总结 产商没有按照 STIX 标准中的意图正确使用对象或属性。我们报告了两种常见的误用。首先，STIX 并不总是包含准确的值，尽管 STIX 包含的文件对象和 URI 的经过充分验证的值。其次，生产者经常没有正确选择对象和属性来表示值。相反，它们以叙述性的方式描述特定信息，而不是使用特定的 STIX 属性。

讨论

有效

• STIX可以有效地用于检测新的攻击网站（URL类型共享快）

无效

• 网络安全专业人员没有足够的 STIX 数据来满足他们的 STIX 要求
• 删除重复的 STIX 数据至关重要。
• STIX 尚未被有效地用于防止恶意软件攻击（文件类型共享慢）
• 实践中使用的 STIX 数据类型数量有限，Indicator中缺乏安全规则碍攻击检测自动化
• 生产者习惯用叙述性的方式描述特定信息，而不是使用特定的 STIX 属性

建议

• type 属性的常用词汇表
• 培训生产者玩完整使用STIX 标准中各种对象和属性
• STIX自动化生产工具