Geekly articles weekly

SIEM深度：现成的相关性。 第3.2部分。 事件规范化方法

如何正确规范事件？ 如何规范来自不同来源的类似事件，而又不会忘记或混淆任何事情？ 但是，如果两位专家独立进行此操作怎么办？ 在本文中，我们将共享一种可以帮助解决此问题的通用规范化方法。

事件规范化方法

图片： Martinoflynn.com

最常见的是，关联规则基于标准化事件。 因此，事件的规范化及其执行的正确性直接影响相关规则的准确性。

由事件规范化引起的问题在第一篇文章（ 此处 ）中提出，而解决方案在后续文章（ 此处和此处 ）中提出。 现在，我们总结前面描述的内容，并形成规范事件的一般方法。

首先，我们回顾一下我们开发了哪些标准化级别的工具：

  1. 存储从事件检索到的数据所需的通用字段架构。 其特点：

    • 它考虑了事件中实体的存在：事件的主题，对象，源和传输者以及资源。
    • 当事件包含网络级别和应用程序的实体，并且事件具有多个主题和/或对象时，提供正确的规范化。
    • 允许您明确标识和维护主题与对象之间交互过程的结构
  2. 事件分类系统，能够反映IT或IB事件的语义 。

事件规范化方法


标准化事件的整个方法包括三个步骤：

  1. 对事件的专家评估。
  2. 交互方案的定义。
  3. 事件类别定义。

为了更容易理解该工具的工作原理，我们将选择一个事件并根据我们的方法详细考虑所有标准化步骤。

假设我们有一个来源-DBMS Oracle数据库，具有以下网络地址：

  • IP ：10.0.0.1；
  • 主机名 ：myoracle;
  • FQDN ：myoracle.local。

SIEM代理从此源卸载以下事件：



步骤1.对事件的专家评估


在规范事件的过程的最开始，了解此事件的含义很重要。 足以对自己说它的本质。 如果专家从最初的（尚未标准化的）事件不了解源头正在发生什么过程，那么我们正在谈论的专家很有可能会错误地对其进行标准化。 那么我们可以谈谈什么样的正确的相关规则运算呢？

专家正确解释事件的程度存在问题。 例如，专家可以了解下一个事件意味着什么吗？



如果在原始示例中，本质可以从事件本身的文本中捕获，那么在这种情况下，您需要充分了解使用的源以及在哪种情况下它会生成类似的事件。 有时，您甚至必须部署带有信号源的单独展位，以完全重现它向SIEM发送复杂且难以解释的事件的情况。

让我们回到原始示例，其中包含来自Oracle数据库的事件。 在这个阶段，专家应该这样思考：

“ 作为专家，我相信最初的事件描述了Oracle数据库中一个用户从另一个用户撤消角色的过程 。”

步骤2.确定交互方案


上一步使我们可以确保至少可以了解事件的一般含义。 现在，我们将详细分析如何区分实体并确定其交互方案。

根据这种方法，对于每种交互方案，必须描述规范化事件字段中关键实体标识符的分布规则。 同时，为以下各项定义了规则：

  1. 网络级实体
  2. 应用程序级别的实体。

重要的是要记住，在某些方案中，主题等于对象，而等于来源。 对于此类方案，必须明确定义填充所有三个实体的字段的规则。 如果不这样做，则在关联规则或事件搜索级别，问题将开始，并且将出现其他逻辑，以正确解释空字段。 关于这一点，在这篇文章中专门讨论交互方案 。

让我们看看该方法的这一步骤如何在初始示例中进行 ：

  • 网络级交互方案 ：没有发送器的完整直接收集方案。
  • 在应用程序级别的交互方案 ：通过资源的交互。

对于这些方案，可以定义以下归一化规则：

  1. 网络层实体：
    • 主题 ：
      • 字段：src.ip = <空>
      • 字段：src.hostname = alex_host
      • 字段：src.fqdn = <空>
    • 对象
      • 字段：dst.ip = 10.0.0.1
      • 字段：dst.hostname = myoracle
      • 栏位：dst.fqdn = myoracle.local
    • 来源（与对象匹配） ：
      • 字段：event_source.ip = 10.0.0.1
      • 字段：event_source.hostname = myoracle
      • 字段：event_source.fqdn = myoracle.local
    • 发射器 ：
      • 字段：forwarder.ip = <空>
      • 字段：forwarder.hostname = <空>
      • 字段：forwarder.fqdn = <空>
    • 互动渠道 ：
      • 字段：interaction.id = 2342594

  2. 应用程序级别的实体（元素集合）：
    • 主题 ：
      • 字段：主题[1] .name =“ Alex”
      • 字段：主题[1] .type =“帐户”
    • 对象
      • 字段：对象[1] .name =“鲍勃”
      • 字段：对象[1] .type =“帐户”
    • 资源 ：
      • 字段：资源[1] .name =“ MYROLE”
      • 字段：资源[1] .type =“角色”

步骤3.定义事件类别


在确定了事件的所有关键实体之后，有必要描述事件中反映的过程的本质，并将其转换为规范化语言。 为了这些目的，使用了一种用于事件分类的系统。 在单独的文章中详细讨论了事件分类系统，现在让我们看看它如何在实践中工作。

为了统一规范化，分类系统定义了以下规则：

  1. 对于IT和信息安全事件的每个级别的每个类别，专家组成一个目录，其中包含在初始事件中需要找到并进行规范化的信息的列表。
  2. 如果为事件分配了任何类别，则专家必须根据目录查找所需的信息并对其进行规范化。
  3. 每个类别都定义了一组需要填充的规范化事件架构字段。

因此，为事件选择的类别在以下各项之间建立了直接对应关系：

  • 事件语义；
  • 根据所贴类别，从事件中提取重要信息；
  • 规范化事件方案的一组字段，其中此信息必须为“放置”。

通过这种方法，您可以从任何事件的类别中清楚地了解规范化事件的哪些字段中的数据。

如果发现在新资源的支持下，需要从某个类别的事件中另外提取一些重要信息，则将其输入到目录中。 在这种情况下，您需要：

  • 定义规则以填充事件模式的字段
  • 对以前所有受支持来源中的此类事件进行规范化审核；
  • 将新信息添加到以前的标准化事件。

这样，可以保持所做更改的一致性。 考虑原始示例。

根据分类系统，此事件具有以下类别：

  • 分类系统 ：IT活动
  • 一级类别（一级） ：用户和权限
  • 第二级类别（2级） ：用户
  • 第三级类别（3级） ：操作

此类别的目录如下所示：

  1. 当规范“ 用户和权限”类别中的事件时，重要的是要了解：
    • 如果使用特权升级，那么将以该身份代表执行该过程。
      • 字段：主题[i] .assign
    • 动作是否成功。
      • 字段：result.status
    • 返回码是什么。
      • 字段：result.status.code

  2. 在规范用户类别的事件时，重要的是要了解：
    • 是否有关于用户计算机的IP地址，主机名或fqdn的任何信息。
      • 字段：src.ip，src.hostname，src.fqdn
      • 字段：dst.ip，dst.hostname，dst.fqdn
    • 用户使用哪个帐户进行连接。
      • 字段：主题[i] .name，对象[i] .name
    • 在操作系统中是否有关于他的帐户的任何信息。
      • 字段：主题[i] .osname，对象[i] .osname
    • 是否有任何域帐户信息？
      • 字段：主题[i] .domain，对象[i] .domain
    • 是否有关于用户应用程序的任何信息。
      • 字段：主题[i] .application，对象[i] .application

  3. 当规范“ 操纵”类别中的事件时，重要的是要了解：
    • 操作类型。
      • 字段：interaction.type
    • 发生了什么变化。
      • 字段：对象[i] .name，对象[i] .type-更改帐户时
      • 字段：资源[i] .name，资源[i] .type-资源更改时
    • 发生了什么变化。
      • 栏位：物件[i] .modify
      • 字段：资源[i] .modify
    • 如果操作是在资源上，则其所有者是谁。
      • 字段：资源[i] .owner

我们已经给出了本指南来说明其形成的原理，因此并不假装它是准确和完整的。

结果，通过这种方法标准化的事件如下所示：

方法第三步中的标准化事件的示例
方法第三步中的标准化事件的示例。

结论


经验表明，通常是归一化错误和缺乏统一的归一化规则，经常会导致相关规则的误报。 现在，我们有了一种方法，该方法即使无法摆脱，也至少可以最小化问题的影响。

因此，总而言之，该方法包括三个步骤：

  • 第一步 专家试图了解初始事件中描述的现象的一般本质。
  • 第二步 专家可以确定事件中网络和应用程序级别的主要实体：主题，对象，源，发送器，资源，交互通道。 它会在事件中隔离它们并确定这些实体的交互模式。 每个方案都会生成用于将这些实体放置在规范化事件（方案）字段中的规则。 在一篇专门介绍实体交互方案的文章中对此进行了详细描述。
  • 第三步 专家确定第一，第二和第三级别的类别。 对于每个类别，它都会创建一个目录，其中包含对数据进行规范化的信息，该数据的描述在规范化事件中很重要，该信息涉及规范化事件的哪些字段必须“放入”发现的数据。

现在，从构建“即开即用”的关联规则的过程中，我们仅被实体本身（资产）不断变化的问题所分隔。 它们的地址更改，引入了新资产，淘汰了旧资产，切换了群集节点，并且虚拟机从一个数据中心移至另一个数据中心，有时甚至改变了地址。 如何克服这些问题，我们将在本周期的下一篇文章中进行讨论。


系列文章：

SIEM深度：现成的相关性。 第1部分：纯粹的行销还是无法解决的问题？

SIEM深度：现成的相关性。 第2部分。数据模式反映“世界”模型

SIEM深度：现成的相关性。 第3.1部分。 事件分类

SIEM深度：现成的相关性。 第3.2部分。 事件规范化方法（ 本文 ）

SIEM深度：现成的相关性。 第4部分。系统模型作为关联规则的上下文

SIEM深度：现成的相关性。 第5部分。开发相关规则的方法

Source: https://habr.com/ru/post/zh-CN433606/

More articles:


All Articles