具有元信息的属性
标题（标题属性）
标题简要描述了规则的本质。此文本字段的长度最多为256个字符。在这里，您应该给出最短和最宽敞的描述。请遵循以下准则：
- 请勿将“ Detects ...”之类的构造用作标题。没有这个，很明显规则会检测到某些东西。
- 使用不超过50个字符的宽大标题。
- 在描述字段中写任何解释和重要评论（我们将作进一步考虑）。
规则的详细说明和其他说明（描述属性）
如果标题包含对该规则的简要描述，以便对它的用途有一个一般性的了解，那么在描述字段中，您可以指定作者对该规则的所有细微差别和功能。它还简要介绍了建议使用此规则检测到的攻击。该字段的最大长度为65,535个字符。
规则的唯一标识符和相关规则的标识符（id，相对）
由于title和description属性的特定值可以是任意的，包括两个不同规则的相同值（永远不要这样做），因此它们不适合唯一地标识一个规则。需要一个更正式，唯一的标识符。绝大多数产品使用通用唯一标识符（UUID）来解决此问题。 Sigma的作者建议规则开发者遵循相同的路径，但是，任何标识符生成方案都可以用于私有规则。在公共存储库中，选择上述UUID作为创建标识符的方案。在本文的第一部分中，我们在示例规则中采用了相同的方法。如果您想将来发布规则或发送请求以将其添加到官方存储库，那么我们建议您遵循相同的方案来创建规则标识符。
唯一标识符可以以不同的方式生成，在Windows中，最简单的方法是运行以下PowerShell代码：
PS C:\> "id: $(New-Guid)"
id: b2ddd389-f676-4ac4-845a-e00781a48e5f在基于Linux内核的操作系统上，可以使用uuidgen实用程序：
$ echo “id: `uuidgen`”
id: b2ddd389-f676-4ac4-845a-e00781a48e5f如果对规则进行了重大更改，则必须更改其标识符。创建新标识符的情况：
- 改变规则的逻辑；
- 在保留原始规则的同时从现有规则继承规则（对于规则改进的情况也是如此）；
- 合并规则。
对于规则的继承和合并的情况，有一个特殊的标识符与类型（type属性）的四个可能值相关。
让我们考虑一下在某些情况下，我们可能会发现使用相关的标识符很有用。为了清楚起见，我们将只写X，Y，Z而不是UUID格式的长标识符。
在第一种情况下，新规则（id：X）是从现有规则（id：Y）派生的。如果我们在新规则中改进了工作逻辑，则可能会发生这种情况，但是由于某些原因，我们希望保留旧规则。因此，我们的规则具有已保存的父规则，并且将来可以使用：
第二种情况与第一种情况类似，除了一个事实：不保留旧规则。也就是说，我们从根本上重写了该规则，并且有必要分配一个新的标识符，而旧的标识符已经过时（废弃）并且将不再使用。因此，我们有一个重写的规则（id：Y），我们决定不再需要它。新规则接收到一个标识符（id：X）。在Sigma规则中，类似的情况将如下所示：
在第三种情况下，考虑一种情况，其中由于合并两个或更多现有规则而出现新规则。新规则（id：X）是合并两个规则（id：Y，Z）的结果。重要的是要注意，合并中涉及的两个父规则都将保留并可以进一步使用。在Sigma规则中，类似的情况可能看起来像这样：
尽管在合并过程中未定义规则的顺序，但为了清楚起见，在注释中对它们进行了编号。
第四种是重命名。顾名思义，重命名旧规则时会应用标识符之间的这种关联类型。实际上，实际上没有使用这种类型。作为使用的一个例子，作者列举了一种更改用于创建标识符的方案的情况（我们记住，UUID不是唯一可能的命名方案）。
规则就绪状态（状态属性）
根据规范，规则可以处于以下三种状态之一：
- 稳定-可以在实际基础架构中使用该规则来检测攻击，无需进行任何修改；
- 测试-规则几乎是稳定的，但需要稍作调整；
- 实验性的-这样的规则会产生大量的误报，但同时也会揭示出有趣的事件。
通常，在实际基础架构上运行规则之前，该规则具有实验状态，因为尚不清楚它会多久产生一次错误。此外，经过几个月的测试，如果规则编写得当且没有产生错误（或存在可忽略的错误），则会将其转移到稳定类别中。否则，将进行更正并再次检查。官方Sigma信息库中没有测试状态的规则。
分发规则所依据的许可证（许可证属性）
分发规则所依据的许可证。这个领域来自自由软件的世界。很少指定它，但是如果指定，它必须符合SPDX ID规范。
规则创建者（作者属性）
该字段列出了规则的所有作者。被认为是很好的形式，不仅可以指示编写规则本身的人，而且可以指示检测的原始思想的作者。
链接到有助于制定规则的研究（参考属性）
编写Sigma规则时，习惯上包含指向有助于或启发规则创建的原始文章，推文和研究的链接。除了表达对他人工作的尊重外，此类链接以后还有助于了解规则的工作原理。
事件字段可用于分析以显示何时触发规则（字段属性）
由于该规则的作者对攻击算法及其在执行过程中生成的事件有深刻的了解，因此他可以从事件中选择字段列表，以帮助SOC操作员或信息安全团队的另一名员工了解事件。
规则误报的情况（属性误报）
误报字段对于检测规则而言非常不常见。它不会以任何方式影响事件验证的过程，但是它会做两件事：
- 帮助用户确定给定的规则触发器是否为错误。
- 再次提醒开发人员该规则可能被错误触发。这样的想法可以帮助开发人员编写更精确的规则。
各种标签和标签（标签属性）
通常，此字段用于MITER ATT＆CK和CAR标签。强烈建议您立即对规则进行分类，因为这样的标记使您可以将Sigma规则与其他信息安全项目集成在一起。但是，格式不只将规则的作者限制为此类标签，您可以放置任何标签。
规则集
根据YAML标准，一个文件（在其术语流中）可以包含多个YAML文档。这是实现得益于YAML文档标签-三个连字符（“---“）对于适马格式，这些文件可以是独立的西格玛规则或行动的文件。
对于第一种情况，一切都很简单：一个文件包含了完整的西格玛规则通过YAML文档标签彼此分隔（示例规则/ proxy / proxy_ursnif_malware.yml）
第二种情况更为复杂：如果顶级action属性具有以下三个值之一，则将YAML文档视为一个action文档：
- global — , YAML- . action- . : , Sigma- ;
- reset — , action-;
- repeat — repeat .
注意：action属性可以出现在规则中的任何位置。
规则集合最常见的用例是为类似事件定义多个Sigma规则，例如Windows安全性EventID 4688和Sysmon EventID1。这两个事件都是由于创建进程而出现的，它们的来源不同。给定方案的Sigma规则集合可以包含三个操作文档：
- 定义通用元数据字段和检测指标的全局操作文档。
- 定义Windows安全事件日志和事件EventID = 4688的来源的规则。
- 定义Windows Sysmon事件日志和事件EventID = 1的源的规则。
替代解决方案可以是：
- 定义通用元数据字段的全局操作文档。
- Windows Security Event Log ( EventID=4688) .
- Action- repeat, logsource EventID , . 2.
action-
在本节中，我们将详细详细介绍Sigma如何根据action属性的值生成摘要规则。包含动作属性且值为global的YAML文档被视为此文件中的全局文档，并且它们的字段将添加到所有其他文档中。
注意：如果当前文档包含带有重置值的action属性，则不会向其添加全局文档字段。
使用全局文档的逻辑如下：解析器遇到全局文档（包含具有全局值的action属性的文档）后，它将其字段添加到特殊缓冲区中并继续下一个文档。让我们将此特殊缓冲区称为GLOBALYAML，它将在将来帮助在图中引用它。
重要：由于文档边界由“ ---”标记定义，因此务必将这些标记正确放置在文件中。
在下面的示例中，第一个YAML文档包含一个值为global的action属性。本文档的边界扩展到第一个文档标记。因此，将整个第一个文档写入全局缓冲区。然后将该缓冲区的字段添加到每个后续文档中。结果，我们在输出端得到两个规则。方案1。使用YAML文档标签的正确定义处理一条简单规则 但是，如果删除或忘记了第一个标签，则YAML DOCUMENT 2的所有字段都将包含在全局文档中。结果，我们只会在输出中得到一个带有一组错误的搜索标识符的规则。因此，在此类复合规则中正确标记YAML文档非常重要。
方案2。处理前一条规则-如果您忘记放置YAML文档的第一个标签，
则应注意，全局文档不一定要放在开头。如果您查看前面的两个方案，那么它并不总是YAML DOCUMENT1。此外，它不必是单数形式。下图清楚地说明了这一点。方案3。处理包含用于设置全局YAML文档的各种选项的规则 因此，我们考虑了与正确放置YAML文档标签有关的问题。我们还看到，您可以使用具有全局值的action属性以不同的方式设置全局YAML文档。接下来，让我们看一下使用action属性的两个剩余值-重置和重复来转换规则的方案。
方案4.处理包含带有复位和重复值的动作属性的规则
关于Sigma项目还有什么要说的
Sigma不仅是我们在本系列文章中介绍的一组格式化规则。
在我们的出版物中，我们专注于描述规则的格式和语法。但是规则只是项目的一半，第二个是sigmac转换器使用的后端。按照惯例，这些转换器可以被认为是具有通用输入和特定输出的“适配器”。正是这种“适配器”的存在使通用描述格式变得非常有用。在这种情况下，使用哪种受支持的系统都无关紧要，Sigma允许您描述这种想法和检测算法，而sigmac转换器的一个或另一个后端负责目标系统的特定语法和字段映射。
但是，不要假定通过下载规则并将其转换为所需目标系统的语法，即可解决与为系统填充专业知识相关的所有问题。我们将简要讨论为什么Sigma目前不是开箱即用的解决方案，以及为什么有必要了解规则的语法。
当前的Sigma挑战
Sigma是一个积极发展的项目，与任何成长中的项目一样，Sigma也有自己的挑战。我个人认为它们是发展点和增长领域。好吧，由于这是一个开源项目，因此合力可以为项目某些部分的开发做出重大贡献。我将列出目前提及框架主要调用的内容：
- . .
- , Windows- (. ). , .
- Wiki , . .
- experimental — , .
- .
- , .
根据我自己的经验，我会说，当我熟悉Sigma项目并参加OSCD时，清单上的第一项被证明是最重要的。事实证明，MaxPatrol SIEM和Sigma中的语法之间的差异并不仅限于关键字的语义和相关规则的设计。我们的某些想法无法用Sigma语法来描述，因为在此阶段尚无事件关联的可能性。相关机制允许您搜索事件字段的通用值并将此类事件彼此关联。当我们要准确地建立事件之间的关系时，这很有用。例如，在一个用户会话中跟踪事件。为此，您需要通过LogonID字段的值或其等效项绑定事件。
应该注意的是，使用Sigma非常成功地描述了点检测或基于非直接相关事件的检测。
解决这些问题和其他问题的一种方法是积极参与OSCD Sprint之一。而且由于任务很多，每个人都可以找到他感兴趣的东西。
新的冲刺即将到来，加入我们！
我们感谢第一回合的组织者对活动的高质量进行以及对参与者的细心态度。手工填写并发送给每个参与者的唯一个性化明信片是什么？就我们而言，我们计划继续参与新的冲刺，并为Sigma信息库做出切实可行的贡献。
阅读我们的系列文章并熟悉规则的格式之后，您将可以运用自己的专业知识，为整个信息安全社区造福。
确保参加第二次冲刺。单独参加并组建团队，让我们一起使世界更安全！
OSCD倡议联系人：
作者：积极技术开发和专家服务部（PT专家安全中心）专家Anton Kutepov