信息安全协作

初稿——期待评论、反馈和阅读建议！

Martin Connarty
7分钟阅读 · 2022年2月8日

在我的博客文章《威胁情报主导内容创作——第一部分》中，我写道威胁情报和狩猎是我们设计后续检测内容的根源，这导致了各种机器可读对象的产生，例如规则本身、威胁档案、剧本（及其响应行动），以及与我们检测它们所需的数据源组件的联系。

在另一篇博客文章（安全价值金字塔）中，我也讨论过安全团队的真正价值应该用于寻找未知威胁，这受到底层实施方式的影响。

例如：您设计了一个OT子网络，但它具有互联网连接，因此您决定使用Snort规则进行监控——这些规则是针对已知威胁的，但如果触发，SOC必须确定这是否是未知威胁的一部分。这些较低层级也将对威胁模型和您的威胁狩猎方法产生主要影响。

在本文中，我想讨论继续发展这些协作机会的必要性，我们需要就如何做到这一点达成共识，以及我们如何实现这一目标的一些想法。

协作的力量

上图可能笨拙地试图展示的是，与甚至您所在行业面临的威胁相比，仅针对您和您的组织的独特威胁（已知和未知）只是极小的一部分，更不用说世界其他地区了。

因此，协作的目标应该是安全团队能够主要关注那个小子部分中的威胁。成功的协作意味着面对每个人的威胁可以从众包的最佳实践中受益。正确做到这一点意味着团队中的才能和想象力专注于新的和创新的内容，这些内容会反馈到协作社区中。

当前协作

信息安全社区是广泛的——供应商、独立研究人员、庞大而沉默的大多数人只是继续工作——其中有我们其他人只能梦想的人才。我相信我们天生是利他的，当我们发现新事物时，我们会兴奋，并喜欢与他人分享。

一些例子：

漏洞

国家漏洞数据库（NVD）和CVEDetails.com等网站多年来一直是审查产品漏洞状态的事实上的场所。通过在这里使用共同语言（CVE），我们能够以我们都理解的方式集体讨论和分享这些漏洞。

攻击工具与技术

社区衍生的工具和技术多年来一直是对手模拟/（实际对手）的主要内容，漏洞研究也是如此。其中许多是利他共享的，尽管许多可能具有更险恶的起源。

事件

最近的Log4Shell事件是（并且仍然是）对人们对其技术栈信心的最大冲击之一。随着大多数安全世界关注这一点，包括我在内的许多人前往Twitter等社区跟踪最新发展和建议。整个社区能够从群体思维方法中受益，这也是我首次涉足Twitter空间，@GossiTheDog在这里运行了一个公开呼叫以提供帮助。

信息安全的Github化内容

这篇博客文章试图站在巨人及其思想的肩膀上，其中之一是John Lambert关于信息安全Github化的文章，它讨论了社区共享内容的不同方式及其好处——例如Sigma规则、Mitre ATT&CK、Jupyter笔记本等，当我们堆叠它们时可能产生的影响。

https://medium.com/@johnlatwc/the-githubification-of-infosec-afbdbfaad1d1

Mitre ATT&CK 2022路线图继续了这一点，其中最相关的一点是检测对象的引入。我假设这将朝着类似Sigma的格式发展，以共享检测逻辑。

所有人使用的共同语言

Mitre在ATT&CK框架中统一战术和威胁语言方面所做的工作是革命性的。例如，它几乎已成为衡量EDR响应能力、映射内部检测能力等的行业标准。尽管我对如果不正确使用可能带来的危险有看法，例如“我们有一个覆盖该内容的规则，因此我们有覆盖”，但它为喜欢自行其是的行业提供了方向。

Mitre ATT&CK框架现在链接到检测这些威胁所需的数据源和特定元素，而OTRF OSSEM（https://github.com/OTRF/OSSEM）等项目正在努力将这些与设备生成的实际事件联系起来。最初，Atomic Threat Coverage（https://github.com/atc-project/atomic-threat-coverage）项目真正开始让我思考如何构建整个检测生命周期，并在我看来应该如何将所有内容缝合在一起。尽管有所有这些，它们目前还不是行业中的共同语言，这仍然是一个挑战。

挑战

透露我们的手牌

安全有点两难——如果我们都共享我们的检测和预防方法，那么对手也会知道这些，并可以努力规避它们，但如果不共享，我们很可能在重复彼此的工作——这些时间本可以用于发现未知。

反论点是，通过在一段时间内以受控方式观察攻击展开，您可以对对手有更深入的了解，例如他们的基础设施或TTP。

最终，我认为需要取得平衡，但当我们决定共享我们的检测内容和控制措施时，安全团队可以继续专注于根除未知，然后生成新的内容，再共享回去。这创建了一个正反馈循环，并大大增加了对手的成本——他们的重点必须转向规避共享的检测规则，但即使那样，它们很可能只是非常临时的规避。

神化和质量控制

虽然我认为安全社区是奇妙的，但我可以看到一些潜在问题。

神化

通常在社区中，我们信任我们学会信任的人——那些有良好洞察力的人，或者那些已经产生伟大内容的人，以及那些在受人尊敬的角色中的人。这些都没有错，然而它确实引入了一种偏见，因为他们是拥有平台的人，因此他们的声音更强烈地被听到。

通常我不认为这是一个问题，但我认为的主要风险是他们是人。人们有生活，他们有意见（有时有争议），他们可能被公交车撞到。社区中有一些人，无论是通过他们维护的工具，还是他们能够穿透噪音并给出清晰信息的能力，对日常安全都有巨大影响，他们的缺席会被感受到。

因此，协作应该能够独立于个人或一小群人存在，以试图从内容中去除任何偏见或议程。

质量控制

如果社区以社区方式生成新内容，我们如何验证它：

a) 具有合理的保真度/信噪比——内容的质量很重要，最终，如果我们要在自动化决策中 potentially 依赖共享内容，就会存在以负面方式影响业务的风险。质量应该如此，我们从一开始就了解噪声水平可能是什么。

b) 意图不是恶意的？——虽然许多人在我们共享的内容上是利他的，但会有其他人（包括对手自己）可能想要造成伤害或削弱我们的能力。

c) 提供足够的信息——在检测内容中，上下文是王道。仅仅提供“坏IP”列表而没有任何关于它们为什么坏以及在什么条件下的上下文，在我看来是浪费每个人的时间。

解决方案和未来

我相信Mitre一直在做的几乎将整个安全周期吸收为可共享对象的工作，我认为对网络防御可能是改变游戏规则的，不一定是因为它都是原创的——通常它们类似于许多其他项目的最佳部分，而是因为它们已经如此成熟。我希望看到这一点增长，然后安全供应商与之对齐（例如Splunk将其CIM映射到Mitre ATT&CK的数据源/数据组件）。

在我看来，我们都在独立创建相同的内容是没有意义的——虽然我理解Mitre ATT&CK只是已经已知（和共享）的内容，但我们真的不应该都在为自己重写那里的内容，而我们可以根除新的和有趣的威胁。

我相信在10年内，IT将几乎完全驻留在云中，并且更常见的是作为SAAS运行。我们今天面临的许多威胁将演变成新的威胁，我们将不得不对服务提供商给予更多信任。这可能意味着安全团队的角色将转向更多的威胁狩猎能力，因为技术栈的标准化意味着安全内容几乎在他们不知情的情况下被应用。我不知道，但我认为未来10年可能会对我们如何看待安全产生重大影响。

#信息安全
#信息安全
#蓝队
#Mitre攻击
#原子威胁覆盖

作者：Martin Connarty
72位关注者 · 33位正在关注
尚无回应