构建高质量攻击指标的几条建议

2018年04月14日

Indicator in STIX

本文内容翻译自: http://stixproject.github.io/documentation/concepts/creating-quality-indicators/

STIX团队已经看到了许多不同来源的攻击指标,并且了解好的STIX攻击指标是怎样的,以下是关于如何构建尽可能好的STIX攻击指标的一些想法。

1.不要只将可观测数据转化为攻击指标

构建低价值攻击指标的最常见操作是将大量看到的内容直接编码为攻击指标。举个例子:你收到一封带有恶意载荷的电子邮件,想将它分享为一个攻击指标。一种无脑的方法是将该电子邮件简单编码成STIX攻击指标,并将其与原始邮件主题、邮件主体、邮件地址和发件人地址一起分享。

发现问题了吗?通过在攻击指标中包含所有的这些数据,如果所有这些字段都匹配,那么攻击指标只能命中一个,这极大地限制了该攻击指标在其它场景的应用。替代方法是,识别哪些字段实际上表示了恶意活动,就只在攻击指标中包含这些字段。如果你还有其它数据,认为增加上下文内容可能有用,你可以将它包含在瞄准指标中的一项可观测数据值。

CybOX对象中的某些字段几乎从不应用于攻击指标,因为它们要么是短暂的,要么是针对特定的环境,要么可能由攻击指标的客户进行不同的解释或计算。例如,处理对象上的进程ID(PID)字段从不可执行变为执行,文件对象中的Peak_Entropy字段可能由不同的工具进行不同的计算。哪些字段通常有哪些有用的相关建议,请查看MAEC项目维护的列表,以从恶意软件样本中构建攻击指标。

2. 不要害怕将良性数据放在指标中(如果你知道你在做什么)

请注意,遵循第一条建议,并不意味着你从不将“良性”数据添加到你的攻击指标中:有时,个别良性数据的特定组合可以表示恶意行为。例如,对Google的DNS查询并不罕见,针对Google随机域名的DNS查询不太常见,但仍然是良性的(许多CDN使用随机域名)。结合特定注册表键值、运行的进程或其他网络流量等信息判断,它可能是某种恶意软件的电话卡。

如果继续使用这个方法,你应该确保使用组合(不论是攻击指标,还是可观测数据)的攻击指标不会只触发良性数据。你不应该使用一个单独的攻击指标来匹配Google的DNS查询,但将它作为其它针对性的可观测数据中AND的一部分,可能很有用。

3. 考虑误报和漏报

在统计学中,这称为第一类错误和第二类错误。基本上,你构建的任何攻击指标不可能可以完全检测到敌方:它可能会检测到实际上不是恶意的内容(误报),也可能检测不到恶意的内容(漏报),或者在大多数情况下,这两种情况都会存在。你可以也应该尽可能地减少这些攻击指标。但在某种程度上,这是一种平衡行为:构建更具体的攻击指标以尽可能地减少误报,同时构建更模糊的攻击指标以尽可能地减少漏报。

通过理解你希望使用哪些攻击指标来确定理想的平衡状态,FireEye的Doug Wilson给出了一些很好的建议:在构建用于检测的攻击指标时,应该倾向于减少误报;而在构建用于事件响应的攻击指标时,应该倾向于构建“噪音”攻击指标,以减少漏报。

4. 包含上下文内容

如果你的攻击指标只是表示一个IP地址或恶意域名列表,而没有任何其它信息,那么可以认为这个攻击指标是很糟糕的,STIX可能不适合你。它会带来很多开销,而不允许你表达任何新内容。另一方面,威胁分析师明白,没有上下文内容的黑名单并是不那么有用:如果你受到了网络攻击,你该做什么?你有哪些问题?思科就有一篇博客文章,解释他们如何使用这种额外的上下文内容来保证攻击指标真正可实施。

STIX对攻击指标有丰富的上下文内容表达能力,包括恶意攻击指标、关联的恶意软件、特定攻击活动进行溯源分析的置信度,或潜在的应对措施。如果您有这些数据,那么可以充分利用这些数据,来为你的客户提供最佳的威胁情报选择。

5. 考虑模式

STIX(CybOX)的另一个功能是可以在攻击指标的字段中包含模式。你不必完全匹配邮件主题,而只需要匹配其中的一部分。类似的,IP地址模式可能可以与子网范围,甚至是5个连续IP地址相匹配。友情提示:许多客户并不理解模式,所以谨慎使用。

PS:该功能在在STIX的攻击指标使用时,最常见的错误是:忘记在攻击指标的可观测数据的值中包含@condition属性。即使它只是“Equals”,为了便于客户理解,你也需要使用这个字段。可观测数据是他们可能看到的事物的模式,而不是你实际看到的内容。

6. 理解你的客户

该建议有时会与第五条建议矛盾,但作为情报生产方,你更应该理解你的客户接收攻击指标的能力。他们可以支持模式吗?他们可以支持更丰富的网络连接对象,还是仅支持IP地址对象?他们可以支持CybOX吗?还是使用Snort或YARA更好?

在生成针对大众客户构建攻击指标时,这可能很棘手。但作为一般规则,请考虑80%的客户可以处的攻击指标。目前,我们的估计是,为大众客户构建上下文内容的情报生产方应该将自己限制在更基本的对象和条件,以在简单的攻击指标共享配置文件中进行表示。

你可以做的一件用于支持所有级别客户的事情,就是构建多个攻击指标并使用攻击指标组合来创建OR条件。例如,如果您有一个SSDEEP哈希和一个SHA1哈希,不是将它们包含在同一个指标中,而是将它们拆分为单独的攻击指标,并使用OR将它们组合在一起。这样,理解SSDEEP的客户可以匹配模糊哈希,并且可以检测更多,而仅理解SHA1的客户仍能从该攻击指标中获得有价值的情报(并且可以忽略SSDEEP哈希)

额外的提示:并非所有内容都是关于攻击指标的

不是你分享的所有内容都需要成为一个攻击指标!是否有一个你想分享的恶意软件分析?可将其编码到MAEC并通过STIX TTP进行共享。是否有一个你见过的新的攻击模式,但没有任何攻击指标,该如何找到它?将其分享为STIX TTP w/ CAPEC的参考。网络攻击的新属性?使用STIX威胁主体或攻击活动进行表示。

这些在以后都可以会与攻击指标存在关联,但如果目前还没有这些指标,就没有理由强迫所有内容都是关于攻击指标的

关键词翻译

  • Indicators 攻击指标

  • Observables 可观测数据

  • Sighting 瞄准指标

  • Adversary 敌方

  • Context 上下文内容

  • Capaign 攻击活动

  • Course of Action 应对措施

  • Threat Actor 威胁主体

参考

【1】5 Tips to Create Quality Indicators,http://stixproject.github.io/documentation/concepts/creating-quality-indicators/

【2】信息安全技术 网络安全威胁信息格式规范


版权声明:本文为博主原创文章,转载请注明出处 本文总阅读量