介绍如果您向资深 SOC（安全运营中心）分析师询问网络 IDS（入侵检测系统）或 IPS（入侵防御系统），他的回答可能会包含诸如“警报太多”和“误报”之类的短语。在 Uber，我们面临着同样的数量、准确性和可管理性挑战。每天，超过 90,000 条 IDS 规则会被多次解析、分析、更新、过滤并部署到我们的网络传感器上。Aristotle v2 的创建是为了使我们能够自动化此过程，应用基于归纳的情报提取，并增强规则元数据以减少误报，并帮助确保适当的 IDS 警报得到适当的关注。
概述Uber 的 IDS 规则集更新过程涉及多个步骤，如图 1 所示。整理和分发规则非常简单，并且对于所有 Suricata™ 部署来说都是通用的。决定要包含哪些规则以及如何修改这些规则是第 4 步“过滤规则集”中要做的事情，也是本篇博文的重点。
图 1：IDS 规则集更新过程。
背景IDS 警报由按照规则（或“规则集”）控制的逻辑运行的 IDS 引擎生成。从基本层面上讲，IDS 规则可以被认为是针对网络流量和连接状态的高级模式匹配。最流行的开源网络 IDS 引擎是Suricata和Snort ™。本文重点介绍 Suricata，但其概念和实践也适用于 Snort。
IDS 规则选择方法选择将哪些规则应用于特定传感器会对误报率、不良 IDS 警报和引擎性能产生重大影响。例如，保护 Linux® Web 服务器池的传感器不需要运行旨在检测针对 Windows® 文件共享的攻击的规则。
规则分类从历史上看，规则集消费者在选择启用或禁用哪些规则时使用了两个大“旋钮”。第一个是“classtype”，这是一个具有有限选项集的本机规则关键字，由规则集提供商定义并尝试对规则进行分类。通常，定义的type 类别不超过几十个，常见值包括“trojan-activity”、“attempted-dos”和“bad-unknown”。第二个旋钮是规则集提供商放置规则的文件的文件名，他们通常会将规则分成不同的文件，名称如“sql.rules”、“scan.rules”和“trojan.rules”。
这些“旋钮”的主要问题是它们不允许一对多映射。每个旋钮仅支持单个规则的单个值。这种缺乏灵活性可能会造成限制。例如，检测最近发现的漏洞工具包活动的规则应该放入“current-events.rules”、“exploit.rules”还是“web-client.rules”文件（仅列举几个选项）？“classtype”字段也存在类似的挑战，其中检测到的活动可以合法地分为多个类别。这些有限、生硬的规则分类机制过于宽泛，无法支持现代部署所需的规则集微调灵活性。
人工审核为了针对特定环境优化规则集，必须对其进行调整。这通常需要耗费大量人力，持续不断。事实上，一些公司每天都要手动检查每条新规则，决定是否应将其纳入，然后根据需要进行调整。然而，这很快就会变得繁重，而且显然无法扩展，尤其是如果现有规则也必须定期重新调整的话。
元数据存在一个“元数据”关键字，由 Suricata 和 Snort 等 IDS 引擎支持，允许将任意键值对嵌入到每个规则中。这对于决定启用哪些规则非常有用，因为可以根据元数据的内容过滤规则。Suricata 还将元数据包含在 IDS 警报中，可用于更明智的后处理、决策和关联。
元数据键值对与传统规则分类相比具有明显的优势，包括：
一对多映射： 例如，“协议”元数据键可以具有值“http”和“tcp”任意键名和值： 分类不必局限于预定义的有限选项更好的方法2019 年提出了基于键值的 IDS 规则元数据的BETTER（更好的增强目的论和分类嵌入规则）模式。它认识到需要一对多元数据映射，并试图为常用的元数据键和（在某些情况下）值带来一些结构和标准化。一家供应商Secureworks ® 在其 Suricata 规则集产品中完全实现了 BETTER，而其他供应商（如Proofpoint ET Pro ®）的规则集具有部分兼容性。BETTER 从未得到业界的广泛采用，但它的主要概念仍然存在，使用元数据进行规则集过滤仍然是一种可靠的策略。
许多规则集提供商确实会填充元数据，但几乎所有规则集提供商的做法都严重限制了使用元数据作为规则过滤手段的有效性。具体来说，规则集存在以下一个或多个缺点：
缺少元数据：规则集中未使用适用的元数据键值对，或者元数据键值对被选择性地应用，而不是普遍应用。如果所有适用的元数据都应用于所有适用的规则，则基于元数据的规则集过滤是最有用的，如果不是这种情况，则实用性会急剧下降。例如，当有 400 多个规则可以以相同的方式分类时，在规则集中的 20 条规则上设置元数据“攻击目标 http 服务器”，使得基于该键值对的过滤价值有限。值格式不一致：例如，“cve”键值可能显示为“cve_2023_1234”、“cve_2023_1234_cve_2023_2468”、“2023_1234”、“2023-1234”等。如果没有规范化的命名法，准确过滤就会变得具有挑战性。值格式不佳：这包括在指定时间/日期字符串时不使用标准日期时间格式（如ISO 8601） 。亚里士多德 v12019 年，Secureworks发布了Aristotle (v1)，这是一款开源 Python 工具，允许用户根据元数据键值对“过滤”（启用或禁用）规则。通过使用具体的布尔代数，可以定义“过滤字符串”来控制规则选择。这可能非常强大，但 Aristotle v1 的实用性受到所提供规则中元数据的丰富性（或者说缺乏）的限制，这是由规则集供应商控制的，并且手动维护起来很麻烦。由于大多数规则集供应商不提供全面的元数据和/或没有具有精确编程过滤所需的精度和一致性的元数据，因此需要比 Aristotle v1 更多的功能。
元数据及其他亚里士多德 v2Uber 最近对Aristotle进行了重大改进，推出了Aristotle v2。这些更新增加了对元数据规范化、增强和操作的支持。图 2 显示了 Aristotle v2 的不同组件，我们将对其进行更详细的讨论。
图 2：Aristotle v2 组件。
过滤Aristotle v1（基本上是“过滤规则集”步骤）在支持元数据的布尔过滤方面做得很好，甚至包括为某些键指定数值关系的能力（例如，“created_at > 2023-01-01”）。在支持此类比较的键列表中，Aristotle v2 添加了risk_score（稍后会详细介绍该键）。
此外，Aristotle v2 中引入了基于正则表达式进行过滤的功能。虽然这确实会影响过滤性能，因为它会向布尔表达式添加非文字元素，但它确实提供了强大且经常需要的功能。具体来说，可以使用“rule_regex”关键字将正则表达式匹配应用于整个规则，或者使用“msg_regex”关键字将范围限定为“msg”字段。
正常化为了解决由于缺乏一致的元数据值格式而带来的过滤挑战，Aristotle v2 支持某些元数据键值的规范化。具体来说，支持以下规范化：
CVE键值已标准化为YYYY-<num>格式。如果值中表示多个 CVE 并以“_”串在一起（例如，“cve_2021_27561_cve_2021_27562” [ sic ]），则所有已识别的 CVE 都将被标准化并包含在内。非 BETTER 模式键mitre_technique_id和mitre_tactic_id的值将被放入符合标准的mitre_attack键中。日期键值（由以“_at”或“-at”结尾的任何键名称确定，例如created_at）将尝试规范化为 ISO 8601 格式YYYY-MM-DD。增强虽然规范化元数据是必要且有用的，但它无法解决缺少元数据的问题。但是，规则不仅仅是元数据，所以我们提出了一个问题：“我们能否从规则的本体中识别、推断、归纳或以其他方式推断细节，并用这些信息扩充规则元数据？ ”这导致创建了 Aristotle v2 来分析每个规则的本体并通过以下增强功能添加/更新元数据的能力：
流键的值规范化为“to_server”或“to_client”协议键和适用值cve键和适用值。这些值基于从原始规则中提取的数据，例如“msg”字段、“reference”关键字等。mitre_attack键和适用值。这些值基于从规则的“reference”关键字中提取的数据敌对键和适用值（“dest_ip” 或 “src_ip”）——这些值是从“target”关键字中获取的值的逆值classtype键和适用值文件名键和适用值 - 如果规则是从文件加载的，则该值将是规则来源的文件名originally_disabled键和布尔值在每条规则内部添加，用于过滤detection_direction键（见下文）检测方向虽然网络 IDS 规则可以是单向的，但绝大多数规则都是针对客户端-服务器通信的一侧编写的。此外，规则通常通过指定源和目标的 IP 地址组来确定范围。IP 地址组是用户定义的，但几乎总是包含变量“HOME_NET”和“EXTERNAL_NET”。其理念是，HOME_NET 是用户或公司拥有的 IP 地址组，旨在受到保护；EXTERNAL_NET 是用户网络“外部”的 IP 组，通常是通用互联网。EXTERNAL_NET 通常（但不一定）定义为 HOME_NET 中未指定的所有内容。
detection_direction元数据键尝试规范规则检测的流量方向性。为此，规则的源和目标部分经过处理并缩减为“$HOME_NET”、“$EXTERNAL_NET”、“any”或“UNDETERMINED”，并用于设置 detection_direction 值，如图3 所示。
图 3：detection_direction 值和条件。
了解规则的“检测方向”对于确定检测到的内容的重要性和严重性非常重要。例如，考虑一条规则，该规则检测已知由感染 Mirai 恶意软件的设备生成的流量。这种入站流量（来自 EXTERNAL_NET 并定向到 HOME_NET）通常可归类为扫描，并被认为只不过是互联网噪音。然而，这种出站流量（来自 HOME_NET 并定向到 EXTERNAL_NET）很好地表明您的网络上有受感染的设备，并且它是活跃僵尸网络的一部分。后一种情况比前一种情况更严重，应如此处理。规则及其关联的 IDS 警报需要能够传达这些现实情况。准确地对规则及其 IDS 警报进行分类，以便可以以编程方式响应它们非常重要，这就是后置过滤器修改发挥作用的地方。
PFMod（后置滤波器修改）Aristotle v2 提供了在规范化、增强和初始过滤字符串应用之后进一步过滤和修改规则集的选项。这称为 PFMod（后过滤修改），允许根据过滤字符串识别规则，然后对这些规则采取特定的“操作”。
PFMod 操作PFMod 操作包括添加/删除元数据、启用/禁用规则、设置优先级以及对完整规则执行基于正则表达式的“查找和替换”功能。支持的 PFMod 操作包括：
禁用：禁用该规则。enable：启用规则。请注意，要使“已禁用”的规则进入 PFMod 进行考虑，它们必须首先在初始过滤字符串匹配阶段进行匹配。add_metadata：YAML 键值对，其中 (YAML) 值是要添加的元数据键值对，例如“protocols http”。请注意，如果已经有使用给定键的元数据，则不会覆盖它，除非值也相同，在这种情况下不会添加任何内容，因为它已经存在。add_metadata_exclusive：YAML 键值对，其中 (YAML) 值是要添加的元数据键值对（例如“优先级高”）。如果给定的元数据键已存在，则用新值覆盖它。delete_metadata：如果给出了元数据键值对（例如“former_category malware”），则从规则中删除该键值对。如果仅给出了元数据键名称（例如“former_category”），则删除使用给定键的所有元数据，无论其值如何。regex_sub：对规则执行正则表达式查找和替换。set_<keyword>：将IDS 规则字符串中的<keyword>设置为给定值。如果规则不包含给定的关键字，则添加该关键字并将值设置为给定值。支持的关键字包括“priority”、“sid”、“gid”、“rev”、“msg”、“classtype”、“reference”、“target”、“threshold”和“flow”。对于整数关键字（“priority”、“rev”、“gid”和“sid”），可以通过在整数值前加上“+”或“-”来使用相对值。例如，操作“set_priority “-1″”将导致规则中现有的优先级值减少 1。set_<arbitrary_integer_metadata>：与“add_metadata_exclusive”类似，允许设置或更改任意基于整数的元数据键值，但也支持相对值以及默认值。格式如图 4 所示。
图 4：用于设置任意基于整数的元数据的 PFMod 操作语法。
笔记：
<arbitrary_integer_metadata>字符串对应于元数据键名称，并且必须至少包含一个下划线（'_'）字符。所引用的元数据键应该具有与整数对应的值。在给定的 <value> 前面加上 '+' 或 '-' 将分别导致规则中现有的元数据值增加或减少给定的<value>。如果元数据键不存在，则该值将设置为给定的<default>值（如果提供），否则不会进行任何更改。示例如图5所示。
图 5：PFMod 操作示例设置任意基于整数的元数据键值对。
PFMod 规则PFMod 条件和操作由 PFMod 规则控制（不要与 IDS“规则”混淆）。PFMod 规则在 YAML 文件中定义，并以深度优先、线性的方式处理。这意味着您可以定义广泛适用于许多（或所有）规则的操作，然后拥有更具体的 PFMod 规则，这些规则将更精确的操作应用于这些规则的子集。如图 6 所示，PFMod 规则文件可以“包含”其他 PFMod 规则文件，以便于组织。
图 6：使用include加载多个 PFMod 文件的示例文件。
除了包含语句之外，PFMod 规则文件还可以包含多条规则。图 7 显示了更新 IDS 规则和元数据的 PFMod 规则文件示例。
图 7：指定规则的示例 PFMod 文件。
风险评分Uber 部署的每条 Suricata 规则都会收到一个“风险评分”。这些风险评分在规则集编译时自动生成，并由 PFMod 规则作为元数据值应用。规则元数据（包括risk_score）包含在 Suricata 警报中，并在事件处理中发挥重要作用。稍后将详细介绍。
维护当新规则添加到 Uber 使用的规则集中时（这种情况每天都会发生），它们会自动接受我们现有的 Aristotle v2 管道的约束，该管道包括过滤和应用非平凡的 PFMod 逻辑来相应地塑造和分类每条规则。因此，通过使用 Aristotle v2 作为可靠的“设置后就忘掉”机制，可以避免手动分析和调整每条新规则。当然，我们会明智地偶尔重新审视规则集过滤和 PFMod 逻辑，以使规则集与当前环境和预期的流量模式保持一致。
文档有关 Aristotle v2 的更多详细信息及其使用方法，请参阅在线文档。
聚合、关联、风险评分和警报Uber 每天处理数十亿个事件，包括数十万个 IDS 警报。事件来自无数来源，包括日志文件、供应商产品、内部系统、自定义检测和 IDS 等传感技术。与安全相关的事件称为“信号”，会获得一个与信号相关联的“风险评分”值，该值由单个整数表示。信号的风险评分值在下游聚合和关联算法中起着至关重要的作用，这些算法最终决定某个信号或一组信号是否有资格发出需要响应的正式元警报。换句话说，“风险评分”值量化了响应的必要性和适当的级别。根据所需的级别，响应通常采取安全分析师手动调查的形式，和/或安全编排和响应 (SOAR) 管道中的一系列程序化操作。
Uber 的信号评估、汇总和关联是一个复杂的过程（更不用说响应管道了），其复杂细节不在本文的讨论范围内。但是，总体策略围绕着我们所说的“基于实体的警报”展开。对于给定的时间窗口，信号按实体（例如 IP 地址、主机、用户等）分组，并应用关联算法来确定是否应创建可操作的元警报。来自各个信号的风险分数值在此计算中起着重要作用，因为它们被加权并相加，最终与用于做出最终决定的阈值进行比较。信号的权重（可以被认为是调高或调低风险分数）基于各种标准，包括实体特征，并且通常涉及与其他数据源的关联。例如，对于用户实体（其中用户是管理员）的信号，其权重高于与非管理员用户相关的信号。类似地，涉及来自已知受认可漏洞扫描程序的 IP 地址实体的信号权重较低，而涉及已知属于负责金融交易的孤立网络的 IP 地址实体的事件权重较高。请注意，如果风险评分足够高和/或权重修改，单个信号就足以生成元警报和响应。
在实践中，聚合和关联与常见实体相关的信号已被证明是一种识别值得响应的事件和事件组合的有效方法。借助 IDS 警报，Aristotle v2 在选择启用哪些规则、包含哪些元数据以及每条规则应携带的风险分数值方面发挥着至关重要的作用。IDS 警报元数据（尤其是风险分数值）使 Suricata 警报得到更好的管理，从而使分析师不会被警报或误报所淹没。
结论通过使用 Aristotle v2 规范化、增强和操作规则元数据，可以准确描述、以编程方式理解和随意修改规则。将具体的布尔代数应用于元数据键值对会产生强大的过滤功能，使我们能够策划 Suricata 规则集以仅在特定环境中运行适用的规则。规则会根据明确和推断的目的论动机和本体论现实自动调整。自定义元数据值（例如“risk_score”）会智能地添加到每个规则中，从而实现有效的下游关联，从而最大限度地减少误报并使值得注意的警报得到适当的关注。结果是一个可扩展、可控制且准确的 Suricata 规则集管理和响应解决方案。
作者:
David Wharton
David Wharton is a Staff Security Engineer on the Threat Detection team, part of Uber's larger Cyber Defense organization. In addition to creating Aristotle v2, Aristotle v1, and the BETTER schema, he has crafted and reviewed tens of thousands of IPS rules which over the years have blocked tens of billions of malicious packets.
出处:https://www.uber.com/en-JP/blog/network-ids-ruleset-management-with-aristotle-v2/
