我们总结了一系列有关开箱即用的相关规则的文章。 我们设定了一个目标，以制定一种方法，该方法将使我们能够创建可以“开箱即用”且误报最少的关联规则。
图片： 软件营销结论中提供了本文的所有要点，并在同一地方以图形
图表的形式展示了该方法。
简要介绍以前的文章中发生的情况：他们描述了标准化事件的一组字段应该是什么样的-
图表 ； 使用哪个事件
分类系统； 如何使用分类系统和方案来统一规范事件的
过程 。 我们还检查了相关规则实施的
上下文，并检查了SIEM应该了解的有关其监视的自动化系统（AS）以及原因。
以上所有方法和推理都是构建相关规则开发方法的基础。 是时候将它们放在一起并查看整个图片了。
制定相关规则的整个方法包括四个部分：
- 准备资源和环境；
- 事件的规范化及其丰富化；
- 使相关规则适应AS的上下文；
- 达成积极协议。
准备源和环境
相关规则对生成源的事件起作用。 在这一点上，相关规则所需的信号源存在于扬声器中并正确配置非常重要。
准备源和环境步骤1 ：
考虑规则的一般逻辑，并了解需要哪些事件源。 如果您是从头开始开发或采用现成的
Sigma- correlation
规则 ，则需要基于事件从其起作用的来源进行了解。
第2步 ：
确保所有必要的来源都在公司内，并且可以将其收集。 当规则对来自以下几种来源的一系列事件进行操作（源1的事件A）-（源2的事件B）-（源3的事件C）持续5分钟时，可能会出现这种情况。 如果您的公司没有至少一个来源，那么这样的规则将变得毫无用处，因为它将永远行不通。 您需要了解，原则上是否可以从必要的来源收集事件，以及您的SIEM是否可以提供事件。 例如，源将事件写入文件，但是文件已加密，或者源上使用了非标准数据库进行存储，无法通过标准ODBC / JDBC驱动程序来确保对其进行访问。
步骤3 ：
将源连接到SIEM。 不管听起来多么陈腐，但在此步骤中，有必要实现事件的收集。 通常有很多问题。 例如，组织问题，当IT管理明确禁止连接到关键任务系统时。 在技术上，如果没有其他设置，则SIEM代理（SmartConnector，通用转发器）在收集事件时仅会“杀死”源，从而导致拒绝服务。 将高负载的DBMS连接到SIEM时通常会观察到这一点。
步骤4 ：
确保正确配置了对源的审核，并且在SIEM中收到了关联所需的事件。 相关规则期望某些类型的事件。 它们必须由源生成。 经常发生这样的情况：为了生成规则所需的事件，必须额外配置源：启用高级审核并配置某种格式的日志输出。
启用扩展审核通常会影响SIEM中从源接收到的事件流（EPS）的数量。 由于消息来源本身和SIEM属于不同部门的责任，因此始终存在禁用扩展审核的风险，结果，必要的事件类型将停止出现在SIEM中。 通过监视每个源的事件流，或者监视每秒事件（EPS）的变化，可以部分检测到此问题。
步骤5 ：
验证事件正在进行中，并配置源监视。 在任何基础架构中，迟早都会出现网络或源本身的故障。 此时，SIEM与源失去联系，无法接收事件。 如果源是被动的，并将其日志写入文件或数据库，则发生故障时事件不会丢失，并且SIEM将能够在恢复通信后接收它们。 如果源是活动的，并且例如通过syslog将事件发送到SIEM，而没有将其另外保存到任何地方，则一旦失败，事件将丢失，并且您的关联规则也将不起作用，因为所需的事件将不会等待。 深入研究，您会发现，即使在使用被动源时，在故障后恢复通信时，也不能保证相关规则会奏效，尤其是那些使用时间窗的规则。 考虑上述规则示例：（源1的事件A）-（源2的事件B）-（源3的事件C）持续5分钟。 如果在事件B之后发生故障，并且在一个小时内恢复了连接，则关联将不起作用，因为事件C在预期的5分钟内不会到达。
牢记这些功能，应配置对收集事件来源的监视。 该监视应监视源的可用性，事件从源到达的及时性，收集事件流（EPS）的力量。
监视系统的触发是第一个提示，说明出现了影响所有或部分相关规则性能的负面因素。
事件的规范化及其充实
仅收集关联所需的事件还不够。 到达SIEM的事件必须严格按照公认的规则进行规范化。 我们在另
一篇文章中介绍了标准化问题以及标准化方法的形成。 通常，此块的特征可以是与垃圾
进场 ，垃圾出场（
GIGO ）进行斗争。
规范化和丰富事件步骤6和
步骤7 ：
根据方法，根据类别对事件进行分类并对事件进行规范化。 我们不会详细介绍它们，因为我们在
“事件标准化方法”一文中详细考虑了这些步骤。
步骤8 ：
根据类别丰富缺少和附加信息的事件。 通常，传入事件并不总是包含相关规则起作用所必需的信息。 例如，一个事件仅包含主机的IP地址，但没有有关其FQDN或主机名的信息。 另一个示例：一个事件包含一个用户ID，但是该事件中没有用户名。 在这种情况下，应从外部资源（数据库，域控制器或其他目录）中提取必要的信息，并将其添加到事件中。
重要的是要注意，事件的分类发生在标准化之前的最开始。 除了类别定义用于规范事件的规则这一事实外，它还设置了如果事件本身未包含在外部源中必须寻求的数据列表。
使关联规则适应AS上下文
准备好输入数据（事件）并进行关联规则的开发之后，有必要考虑传入事件的详细信息，AS本身及其可变性。 关于这一点的更多信息，请参见
“系统模型作为关联规则的上下文”一文 。
使关联规则适应AS上下文步骤9 ：
了解每个来源的事件发生频率，确定相关的时间窗口。 当需要在给定的时间间隔内预期某个事件的到来时，关联规则通常会使用时间窗口。 在制定此类规则时，重要的是要考虑接收事件的延迟。 它们通常是由两个因素引起的。
首先 ，源本身可能不会立即将事件写入数据库，文件或通过syslog发送事件。 该延迟时间必须在规则中进行估算并考虑在内。
其次 ，向SIEM交付事件存在延迟。 例如，配置来自数据库的事件收集，以便每10分钟执行一次事件请求，当然，在这种情况下5分钟的关联窗口不是最佳解决方案。
当有必要开发一种可同时处理多个来源事件的关联规则时，问题就更加复杂了。 在这种情况下，重要的是要了解它们的交货时间可能不同。 在最坏的情况下，事件将以随机顺序出现，并违反时间顺序。 在这种情况下，关联规则的开发者需要清楚地了解SIEM何时实现关联（在事件时间或事件何时到达SIEM中）。 我注意到事件到达时间的相关性是在伪实时模式下处理事件的技术上最简单，最常见的选择。 但是，此选项只会加剧上述问题，而不能解决这些问题。
如果您的SIEM在事件时间中提供了相关性，则很可能存在用于重新排序事件的机制，这些机制可以恢复事件的实际时间顺序。
如果您了解时间窗口太大而无法在流上进行关联，则必须使用回溯关联机制，在该机制中，将根据计划从SIEM数据库中选择已保存的事件，并执行关联规则。
步骤10 ：
建立例外机制。 在现实世界中，总会有一个具有特殊行为的对象不应该由特定的关联规则处理，因为这会导致误报。 因此，在规则制定阶段，应建立机制以将此类对象添加到异常中。 例如，如果您的规则适用于计算机的IP地址，则需要一个表列表，您可以在其中添加规则无法使用的地址。 同样，如果规则适用于用户登录名或进程名称，则必须预先使用规则逻辑中的表排除列表。
这种方法将使您能够自动或手动将对象添加到异常中，而不必重写规则的正文。
步骤11 ：
定义关联规则适用性的物理和逻辑边界。 在制定关联规则时，重要的是要首先了解规则的适用范围（范围）以及它们是否存在。 在制定逻辑和调试规则时，必须专注于该领域的细节。 如果规则开始处理超出此区域范围的数据，则误报的可能性会增加。
可以区分两种类型的范围：物理范围和逻辑范围。 物理范围是公司和邻近的网络，逻辑范围是AS，业务应用程序或业务流程的组成部分。 物理区域的示例：DMZ网段，内部和外部子网，远程访问网络。 规则的逻辑范围示例：ACS TP，计费，PCI DSS段，PD段或仅特定的设备角色-域控制器，访问交换机，核心路由器。
您可以通过表列表设置关联规则的范围。 它们可以手动或自动填充。 如果您在公司中有时间进行资产管理（资产管理），那么所有必要的数据可能已经包含在SIEM中创建的AS模型中。 这些表格列表的自动生成使您可以在公司范围内动态包括新资产。 例如，如果您有一个仅与域控制器一起使用的规则，则在模型中将修复在域林中添加新控制器的问题，并将其纳入规则范围。
通常，可以将用于例外的表列表视为黑名单，而将负责规则范围的列表视为白名单。
第12步 ：
使用说话者模型来阐明上下文。 在制定识别恶意行为的关联规则的过程中，重要的是要确保它们可以实际实施。 如果不考虑这一点，则揭示潜在攻击的规则的触发结果将是错误的，因为此类攻击可能根本不适用于您的基础架构。 我将举例说明：
- 假设我们有一个关联规则，可检测到服务器的远程RDP连接。
- 防火墙尝试连接到myserver.local服务器的TCP端口3389。
- 规则触发，您开始以高优先级分析潜在事件。
在调查过程中，您迅速发现在myserver.local 3389上它已关闭并且从未被任何服务打开，并且Linux在那里。 这是一个误报，导致您花了一些时间进行调查。
另一个示例：尝试利用漏洞CVE-2017-0144时，IPS发送签名触发事件，但是在调查过程中，事实证明相应的补丁程序已安装在受攻击的计算机上，因此无需以最高优先级响应此类事件。
使用扬声器模型中的数据将有助于解决此问题。
步骤13 ：
使用实体标识符，而不是其源密钥。 如文章
“作为关联规则的上下文的系统模型”中已经描述的那样，资产
的 IP地址，FQDN甚至MAC都可以更改。 因此，如果您在关联规则或表列表中使用资产的源标识符，则过一会儿，由于完全禁止的原因，很可能会收到误报，例如，DHCP服务器只是将该IP发布给了另一台机器。
如果您的SIEM具有识别资产，跟踪资产变更并允许您使用其标识符进行操作的机制，则应使用标识符，而不是资产的源密钥。
达成积极协议
接近创建关联规则的最后一步时，我们记得规则的结果是SIEM中引发的事件。 负责任的专业人员必须对此类事件做出回应。 尽管本系列文章的目的不包括考虑事件响应过程，但应注意，有关事件的部分信息已在创建相应的关联规则的阶段生成。
接下来，我们考虑在配置用于触发相关规则和生成事件的参数时必须考虑的基本点。
达成积极协议步骤14 ：
确定在出现大量误报的情况下聚合和关闭的条件。 在调试阶段以及其运行过程中，如果您不遵循此技术:)，则可能会发生规则错误警报。 每天有1或2次旅行是很好的，但是如果一条规则有成千上万的旅行怎么办？ 当然，这表明该规则需要进一步发展。 但是，必须确保在这种情况下出现如此大量的误报：
- 它没有影响SIEM性能。
- 在大量的误报中，真正重要的事件没有丢失。 甚至还有一种单独的攻击类型，旨在将主要的恶意活动隐藏在许多错误的活动之后 。
如果在整个系统整体或每个规则的级别上创建关联规则时，可以设置事件汇总条件和规则紧急关闭条件，则可以解决此类问题。
事件汇总机制将不允许创建数百万个相同的事件，而是将新事件“胶合”到一个事件（如果它们相同）。 在极端情况下，即使事件的汇总也带来了沉重的负担，建议在每单位时间（分钟，小时，天）超过给定操作次数时，配置自动禁用关联规则。
步骤15 ：
定义用于生成事件名称的规则。 此项目通常被忽略，尤其是当他们没有为其公司制定规则时，例如，如果第三方公司负责实施SIEM和制定规则。
相关规则及其产生的事件的名称应简短，并清楚反映特定规则的本质。如果公司中有多个人使用事件和关联规则，则建议您制定命名规则。与SIEM合作的整个团队必须理解并接受它们。步骤16：定义影响事件重要性的规则。在发生事件的最后阶段，大多数SIEM解决方案都可以让您设置其重要性和重要性。某些决策甚至可以基于事件的上下文和其中涉及的对象来自动计算重要性。如果您的SIEM专门进行事件重要性的自动计算，则有必要根据其计算方式和计算公式进行计算。例如，如果根据事件中涉及的资产的重要性来计算重要性，则需要事先认真考虑公司中的资产管理问题。如果您手动设置事件的重要性，建议您开发一个至少考虑以下因素的计算公式：- 规则适用范围的重要性。例如，与在关键业务系统区域中发生的事件完全相同的事件相比，关键任务系统区域中的事件可能更为关键。
- 事件中涉及的资产和用户帐户的重要性。
- 该事件在公司中再次发生。
同样，就像在命名事件中一样，重要的是所有有关方面都必须清楚而平等地理解事件重要性形成的规则。结论
总结一下我们系列文章的结果，我认为有可能创建开箱即用的关联规则。解决方案可能是组织和技术方法的融合。SIEM本身必须能够执行某些操作，但是操作它的专家必须能够执行并了解某些操作。总结一下：- 该方法包括以下块：
- 准备源和环境。
- 事件的规范化及其充实。
- 使相关规则适应AS上下文。
- 达成关于肯定的协议。
- 每个部门都有组织和技术组成部分。
- 从技术角度来看，从事件收集到事件生成，所描述的块几乎影响所有基本的SIEM功能。
- 这种方法的几乎所有技术组件都可以由现有的外国公司以及一些国内SIEM解决方案提供。
- 在本周期的前几篇文章中，对该方法的步骤进行了更详细的考虑和论证。文章末尾提供了指向它们的链接。
开发“开箱即用”的相关规则的方法论非常感谢所有人精通整个系列文章，或者至少阅读了这些内容。如果您有任何问题，请写信给他人或在评论中提问。我很乐意讨论。
系列文章：SIEM深度：开箱即用的相关性。第1部分：纯粹的行销还是无法解决的问题？SIEM深度：现成的相关性。第2部分。数据模式反映了 SIEM深度的“世界”模型：“开箱即用”的相关性。 第3.1部分。 SIEM深度 事件的分类：现成的相关性。第3.2部分。SIEM深度 事件标准化方法：现成的相关性。第4部分。作为SIEM深度关联规则的上下文的系统模型：即席关联。第5部分。开发相关规则的方法（本文）