这是该系列的第二篇文章，专门介绍为SIEM系统创建现成的相关规则的方法。 在上
一篇文章中，我们为自己设定了这个任务，描述了在执行该任务时将获得的优势，并列出了阻碍我们前进的主要问题。 在本文中，我们将开始寻找解决方案，并从
转换“世界”模型及其在事件规范化阶段的表现形式的问题开始。
在第一篇文章中描述了
转换“世界”模型的问题。 让我们简要回顾一下它的本质：当现象在事件源处发生时（例如，在OS中启动进程），它以不同的格式固定，首先是在内存中，然后是在OS事件日志中，然后是在SIEM系统中。 处理的每个阶段都伴随着数据丢失，因为在OS级别上存在一个“世界”模型，而在OS日志中，则存在另一种受日志方案限制的字段集。 因此，存在一个具有大量参数的模型向另一个参数的反射（变换），而参数数量较少。 由于SIEM也有自己的“世界”模型，因此在SIEM中将事件规范化并保存是另一种因数据丢失而发生的转换。
很难找到一种方法，可以将一个模型转换成另一个模型而不会造成损失。 知道此限制后，有必要制定一种标准化的方法以及形成事件方案的字段列表的方法，在该方法中不会丢失信息，这对于信息安全事件的关联和进一步调查很重要。
在SIEM框架内，模型由方案表示-一组字段，初始事件中的数据适合标准化过程。 将来，专家将使用它来创建关联规则。 为了使事件调查人员和负责制定相关规则的人员明确解释标准化事件，该方案必须满足以下基本属性：
- 统一处理任何类型和来源的事件；
- 清楚描述谁与谁互动以及如何互动；
- 保持互动的本质和背景。
在制定规范化规则的过程中，必须在初始事件中找到有关交互的信息，并将其分解为专门指定的字段。 对于交互的上下文和本质，需要做同样的事情（在下一篇文章中将对此进行更多介绍）。
随之而来的问题是：是否有可能确定出满足所有可能的IT和信息安全源所产生的任何事件的典型交互方案？ 如果是这样，这些方案是什么样的？
要找到这些问题的答案，您需要转向分析，并尝试分析尽可能多的已在SIEM解决方案中开发并运行的规范化规则，以识别常见模式。 作为此类工作的一部分，有可能从来自Positive Technologies MaxPatrol SIEM和Micro Focus ArcSight等解决方案的100多种不同来源分析3,000多种标准化规则。 分析得出以下结论：
- 存在典型的交互方案。
- 通常，在每个单独的事件中，都有有关网络级别和应用程序级别的交互的信息。
- 典型的交互模式可能在不同的级别上有所不同，因此必须予以考虑。
网络和应用层通信方案
我们描述了每个级别的典型方案。 在此之前，您需要突出显示事件中始终存在的实体。 此外，基于它们，将建立交互方案。 这些包括：
- 主题 。 影响对象的实体。 例如，用户更改注册表项或IP 10.0.0.1的主机，将数据包发送到IP 20.0.0.1。的主机。
- 对象 。 受主题影响的实体。
- 来源 通常，主机注册主体与对象的交互并自行生成事件。 例如，源将是一个防火墙，记录从主机（IP为10.0.0.1的主题）到主机（IP为20.0.0.1的对象）的数据包传输。
- 发射器 在某些情况下，SIEM并非直接从源接收事件，而是从这些事件通过的中间服务器接收事件。 最简单的示例是中间syslog服务器。 一个例子更加复杂-当发送器可以是管理服务器时，例如，Kaspersky Security Center。 在这种情况下，源是Kaspersky Endpoint Security的特定代理。
但是，并非所有实体都可以在事件中同时出现（稍后会详细介绍），因此，重要的是要首先签订协议，因为在这种情况下，该方案的相应字段已填写。 这将有助于将来清楚地区分由于专家（正在制定规范化规则）的错误而未填写这些字段的情况与原始事件中实际上没有包含任何实体数据的情况。
让我们继续进行交互模式和事件示例。 为了清楚起见，所有示例都将基于文件日志，系统日志消息或关系数据库中的记录给出，但它们可用于其他日志格式，例如二进制。
网络层
网络级实体的主要标识符是IP地址。 重要的是要理解，在应用程序级别可能还存在其他相关标识符-通道级别的MAC地址FQDN。 问题出现了：他们是在谈论同一实体还是不同的实体？ 这些标识符可以随同一实体随时间变化吗？ 单独的文章将专门讨论这个问题，现在让我们详细讨论一下网络级别的交互模型的主要标识符是IP地址这一事实。
因此，此级别的典型交互方案可以分为两类-基本的和退化的。
基本互动方案
方案1.完整的交互方案在此模型的框架内，如果在SIEM输入处收到事件，则可以区分所有主要实体：主题，对象，源，发送器。 在交互方案中，主题作用于对象。 此效果注册（观察）源并生成事件。 来自源的事件进入发送器，并从源进入SIEM。
下面的事件捕获了Stonesoft防火墙（现为Forcepoint）在主机之间进行的网络交互解决，而事件本身并非直接进入SIEM，而是从中间syslog服务器进入SIEM。
在这里：
40.0.0.1-发送器（中间syslog服务器），
30.0.0.1-源（防火墙节点），
10.0.0.1-主题（发送UDP数据包），
20.0.0.1-一个对象（接收UDP数据包）。
图2：不带变送器的直接收集图并非总是在交互方案中是发射机。 通常，当使用中间服务器（例如syslog服务器）来传输事件时，或者当从中收集事件的解决方案具有集中式管理系统（例如，卡巴斯基安全中心，Check Point智能控制台或Cisco Prime）时，就会出现这种情况。 在此方案下，事件直接从源头落入SIEM。 此事件描述了大多数事件。 顺便说一句，如果其中没有中间的syslog服务器，并且我们直接从防火墙接收了事件，则可以在
图1中看到此类事件的示例。
在这里：
30.0.0.1-源（防火墙节点），
10.0.0.1-主题（发送UDP数据包），
20.0.0.1-一个对象（接收UDP数据包）。
方案3.与许多对象的交互在网络级别上，这种交互方案非常少见，并且通常对于网络设备的事件而言是典型的。 在该方案中，一个主题与许多对象进行交互，在描述多播，单播或广播广播的事件中也存在类似的交互。
请注意，有时许多对象可以由公共标识符（子网地址或广播地址）组合在一起。 应该记住这一点，因为在分析事件（包括相关规则级别）时，您可以轻松地跳过潜在的重要交互，因为在这种方案中，对象地址隐藏在组地址的后面。
以下示例演示了来自IGMP中继服务器的事件，通过该事件广播多播成员资格请求。
在这里：
30.0.0.1-源（IGMP中继服务器），
10.0.0.1-主题（请求组成员），
224.0.0.252-对象（多播地址）。
退化方案
主体，客体和来源是基本交互方案组中的基本实体。 但是，在某些情况下，事件中可能缺少实体之一。
方案4.没有对象的交互在主体报告其内部状态发生变化的情况下（即，他同时扮演主体和客体的角色），这种模式通常是典型的。 例如，可以在工作站上的配置更改或恶意软件检测事件中观察到此交互。 但是，此信息不是由主体自己记录的，而是由集中管理系统记录的，并存储在他的日记中。
该示例显示Symantec Management Server如何捕获其管理的Symantec Endpoint Protection代理已在其主机上检测到恶意文件。
在这里：
30.0.0.1-源（Symantec Management Server），
10.0.0.1-主题（Symantec Endpoint Protection代理）。
方案5.结合主体和客体在来源中的作用当SIEM从源接收到报告其内部状态发生更改的事件时，最后一种退化的交互方案通常会出现这种情况：例如，重新配置设备或软件，启用或禁用网络端口。 在这种方案中，源的作用与主题和客体的作用相吻合。 与以前的方案不同，SIEM中的事件直接发生。
在此示例中，基于Cisco IOS的交换机报告其接口已转换为UP状态。
这里
30.0.0.1是源（开关）。
应用等级
在此级别上，存在已知实体的交互：主题，对象。 但是，有关源和发送器的所有信息都直接保留在网络级别，而没有反映在应用程序级别。
所有类型的事件中的大多数都在网络级别和应用程序级别同时包含交互。 但是，我们注意到，由应用程序软件（例如1C：Enterprise，Microsoft SQL Server或Oracle Database）直接生成的事件可以只包含应用程序级交互。
此外，附加的
资源实体出现在应用程序级别。
资源是中间实体，主体通过该中间实体无需直接交互即可对对象施加影响。 例如，向Alex授予Bob访问MyFile的权限。 这里Alex是Subject，Bob是Object，MyFile是Resource。 请注意，在此示例中，Alex不会直接与Bob互动。
重要提示 ：应用程序级别的事件可以包含“主题”和“对象”的附加参数，以及“资源”本身。 例如，诸如“文件”之类的资源的其他参数可以是其所在的目录或其大小。
在这种情况下，主题，对象和资源由名称或唯一标识符标识：数据库中的电子邮件地址，文件名，目录名，表名。
考虑特定于应用程序层的其他交互模式。
图6.资源交互在此图中，主题通过中间资源间接作用于对象。 通常，使用这种方案的事件在数据库审核日志中或在操作系统级别使用文件和目录的访问权限时都清晰可见。
该示例显示了来自Oracle数据库审计数据库的条目。 它修复了撤消用户角色的过程。
在这里：
“ ALEX” -主题（撤消角色的用户名），
“ BOB” -对象（被撤消的用户名），
“ ROLE” -资源（已撤销角色的名称）。
图7.与许多资源的交互在应用程序级别以及网络级别，存在此类事件，在这些事件中，主题通过许多资源立即与对象进行交互。 这种情况很少见，但有时对象的数量也超过一个。 修复批量操作时，会出现这些类型的事件。 例如，向一个用户授予对多个文件的访问权限或更改策略中包括的一组规则。
在该示例中，用于保护虚拟环境的解决方案vGate安全代码捕获了对新策略的添加。
在这里：
“ Admin @ VGATE” -主题（更改策略集的用户名）
“基础” -对象（策略集）
“安装和维护文件系统的完整性”，“检查SNMP代理的设置”，“禁用VMware Tools的自动安装” -资源（添加的策略的名称）
主体与客体互动渠道的模型
在所有方案中，我们区分了不同的实体（对象，对象，资源，源，发送方），并指出了它们之间的所谓交互通道。 让我们更详细地讨论SIEM必须使用的“世界”大型模型的倒数第二个组成部分-主题和客体之间交互渠道的模型。 回想一下，最后一个组件是交互的上下文（下一篇文章将对此进行专门介绍）。
因此，有两个实体相互交互。 作为此交互的一部分，数据从一个实体传输到另一个实体。 这些可以是带有数据，文件或管理命令的网络数据包。 在这种情况下，所形成的通道可以以“管道”的形式表示，沿着该管道有定向的数据和命令流。 这样的模型在网络级别清晰可见，但在应用程序级别则不太明显（请参阅
示例 ）。
数据通道模型基于这样的模型，SIEM接收到的每个事件可能包含描述以下信息：
- 通道本身的参数是“管道”，
- 通过此“管道”传输的数据。
通常，信道由诸如会话标识符，数据传输协议，信道建立时间，完成时间，持续时间之类的参数来描述。 事件中的数据的特征在于加密算法使用的格式，已传输的数据包数，已传输的字节数。
考虑一个事件示例，该事件包含有关交互渠道的数据。 这是来自思科身份服务引擎（ISE）的事件，这是一个用于识别和控制访问的过程管理系统，该系统将用户的网络会话记录为记帐过程（记帐）的一部分。
在这里：
“ Acct-Session-Id = 1A346216”，“ Acct-Session-Time = 50”，“服务类型=成帧”，“成帧协议= PPP” -通信通道参数，
“ Acct-Input-Octets = 43525”，“ Acct-Output-Octets = 122215”，“ Acct-Input-Packets = 234”，“ Acct-Output-Packets = 466” -通过通道传输的数据参数。
一次事件中实体与渠道互动模型的示例
因此，我们研究了网络级别和应用程序的交互方案以及交互通道的模型。 接下来，我们显示一个示例，该示例在一个事件中如何组合不同级别的交互方案并使用有关信道模型的信息。
在这里，我们看到了来自防火墙的事件-Cisco自适应安全设备（ASA），其中固定了传出TCP连接。
该示例清楚地表明，在一个事件中，存在网络级别和应用程序级别的实体。 在网络级别上，主题和对象之间的交互方案，由源确定。 没有发射器。
在这里：
30.0.0.1-源（Cisco ASA），
10.0.0.1-主题（连接者的地址），
20.0.0.1-一个对象（它们所连接的对象的地址）。
在应用程序级别，一个简单的方案仅包含主题和对象：
“ ALEX” -主题（连接的用户名），
“ BOB” -对象（他们连接到的用户的名称）。
同样在这种情况下，有数据传输通道的描述，但没有数据本身的描述：
“ TCP”是创建通道所依据的协议，
“ 136247”是频道会话标识符。
结论
我们强调的典型交互方案如何提供帮助？
- 首先 ，在编写相关规则和分析事件时，专家应了解到达SIEM的每个事件中存在哪些实体。 为此，有必要在事件规范化阶段明确标识实体：主题，对象，资源，源和传输器。
- 其次 ，在规范化过程中，重要的是要考虑到事件包含有关网络级别和应用程序级别的交互的信息。 这两种交互都可以在一个事件中同时出现。
- 第三 ，交互本身是一个复合结构，其中存在有关所形成的通道以及通过该通道传输的数据的信息。
因此，SIEM内置的“世界”模型由一组字段（一种方案）表示，应包含用于描述以下内容的部分：
- 在网络级别 ：
- 主题
- 对象；
- 来源；
- 发射器
- 互动渠道；
- 通过通道传输的数据。
- 在应用程序级别 ：
对于每个实体，必须定义一组唯一标识它的属性。 在网络级别，实体由IP，MAC或FQDN标识。 在应用程序级别，按名称或ID。 模式必须具有用于存储这些标识符的专用字段。
在退化的交互方案中，一个实体可以一次组合多个角色。 在规范此类事件时，有必要明确定义规则，以填充计划中负责整个实体集的所有字段。 将来，这将有助于相关规则不会错过部分交互。
让我们解释一下：以合并主题和客体在源代码中的角色为例。
如果在归一化期间仅填充负责源的方案的字段，则分析特定对象上的配置更改的关联规则将仅错过我们需要的事件，因为对象的字段将为空。在编写相关规则时，重要的是要清楚地了解我们正在使用哪种模式和交互级别的事件。这将有助于正确解释参与事件的实体的角色。结果，能够描述整个典型交互集的通用方案如下所示：
面向交互的现场方案下一阶段是将我们在初始事件中观察到的交互的含义或语义的“世界”包含在SIEM模型中。实践表明，仅知道工作站上的用户Alex已连接到域控制器是不够的，重要的是要了解这是一次登录尝试，并且有可能失败。在编写相关规则时，最好对正在发生的现象进行语义处理，而不仅仅是处理事件字段中的数据。当然，您可以通过查看标准化事件中的数据以某种方式解释和理解含义，但是需要帮助SIEM中的相关器来做到这一点。在下一篇文章中，我们将讨论分类及其如何帮助唯一解释事件中那些交互的含义。我们还将汇总所有描述内容，并制定规范化从不同来源获得的事件的方法论的基本原理。
系列文章：SIEM深度：现成的关联。第1部分：纯粹的行销还是无法解决的问题？SIEM深度：现成的相关性。第2部分。反映“世界”模型的数据模式（本文）SIEM深度：现成的关联。第3.1部分。SIEM深度 事件的分类：现成的相关性。第3.2部分。SIEM深度 事件标准化方法：现成的相关性。第4部分。作为SIEM 深度关联规则的上下文的系统模型：即席关联。第5部分。开发相关规则的方法