然后我们了解到，一群爱好者决定安排为期两周的冲刺关于为Sigma项目编写规则的内容，该项目旨在创建用于描述SIEM系统规则的统一格式，并得到140多个参与者的支持。我们对事件的新闻很感兴趣，因为作为SIEM供应商，我们密切关注社区的发展。
当组织者联系我们并邀请PT专家安全中心团队参加冲刺时，请想象一下我们的惊喜！活动参与者组成了开放安全协作开发（OSCD），这是一个由信息安全专家组成的国际计划，旨在传播知识并总体上提高计算机安全性。我们很高兴同意参加，以便将我们的经验用于共同安全。
本文是如何产生的
当我们开始编写规则时，我们意识到对Sigma-rules的语法没有详尽的描述，尤其是在俄语中。知识的主要来源是GitHub和个人经验。有好几篇好文章（用俄语和英语），但是其中的重点从规则的语法转移到了对Sigma-rules适用范围的分析或特定规则的创建上。我们决定使初学者更容易熟悉Sigma项目，分享我们自己的经验，在一处收集有关其用法和语法的信息。当然，我们希望这将有助于扩展OSCD计划并在将来创建一个大型社区。
由于材料很多，我们决定以三篇文章的形式发布说明：
- , ( ).
- . , .
- (, , , , ) .
Sigma
Sigma是用于描述基于日志数据的检测规则的统一格式。规则存储在单独的YAML文件中。Sigma允许您一次使用统一语法编写规则，然后使用特殊的转换器以受支持的SIEM系统的语法获取规则。除了各种SIEM系统的查询语法之外，还支持创建以下类型的查询：
- Elasticsearch查询，
- grep实用程序启动行带有必需的参数，
- Windows审核日志PowerShell字符串。
后两种类型值得注意，因为它们不需要额外的软件来分析日志。分别在Linux和Windows上开箱即用地支持grep实用程序和PowerShell解释器。
用于描述基于日志的检测的统一格式的存在使共享知识，开发开源安全性和帮助信息安全性社区抵抗新出现的威胁变得更加容易。
一般语法
首先，应该说规则有必要的部分和可选的部分。GitHub上的官方Wiki中对此进行了记录。规则概述（来源：官方Wiki）如下：
几乎任何规则都可以大致分为三个部分：
- 描述规则的属性（元信息）；
- 描述数据源的属性；
- 描述触发规则的条件的属性。
每个部分都对应于title所需的高级属性（除了title之外，最后一组包括其他可选的高级属性），logsource和detection。
规则结构的另一个功能值得一提。由于规则是使用YAML标记语言描述的，因此Sigma开发人员已发现了一些用处，因为YAML格式允许将多个YAML文档放置在一个文件中。对于Sigma-将多个规则合并到一个文件中，即创建“规则集合”。当有多种检测攻击的方式并且您不想复制描述性部分时，此方法很方便（如相应部分中所述，您不仅可以复制规则的描述性部分）。
在这种情况下，规则通常分为两部分：
- 具有收集项目的一般属性的部分（通常是所有字段，日志源和检测部分除外），
- 描述检测的一个或几个部分（日志源和检测部分）。
如果文件包含单个规则，则该语句也适用，因为我们从一个规则中获取了一个简并的集合。规则的集合将在本系列文章的第三部分中详细讨论。
接下来，我们看一个假设规则的例子。应当注意，这种形式的注释通常不在规则中使用，此处仅用于描述字段。
典型规则说明
创建Sigma规则的示例
在描述语法的细节并讨论Sigma规则的功能之前，让我们考虑一个创建这样的规则的小例子，以弄清楚这些或那些属性值的实际来源。关于这一主题，有一篇很好的英文文章。如果您已经尝试编写自己的规则并弄清楚应在YAML文件属性中指定哪些数据，则可以继续进行下一节，其中对事件源部分进行了详细说明（我们也将这一部分称为日志源）。
让我们描述如何创建一个规则来检测SettingSyncHost.exe作为“脱离陆地二进制文件”（LOLBin）的使用。规则创建通常涉及三个阶段：
- 进行攻击并收集必要的日志，
- 通常对检测的描述，
- 检查创建的规则。
进行攻击
该规则的想法已在Hexacorn博客中充分记录。仔细阅读后，很清楚需要采取什么步骤来重复本文中描述的结果：
- 将要运行的程序复制到任何可写目录。本文建议选择％TEMP％，但是您可以选择自己选择的路径。值得考虑的是，将在此目录中创建一个子目录，并使用您在步骤4中指定的名称。
- , , , (wevtutil.exe, makecab.exe, reg.exe, ipconfig.exe, settingsynchost.exe, tracelog.exe). , findstr.exe. , SettingSyncHost.exe Binary Search Order Hijacking (MITRE ATT&CK ID: T1574.008).
- , ( settingsynchost.exe cmd PowerShell,
cd < >). - :
c:\windows\system32\SettingSyncHost.exe -LoadAndRunDiagScript <___> - SettingSyncHost.exe.
Sysmon与sysmon-modular项目中的配置文件一起 安装在系统上。因此，日志的收集是自动进行的。编写规则时会看到哪种日志对写检测有用。
Sigma规则形式的检测描述
在此步骤中，可以采用两种方法：找到在检测逻辑中最接近的现有规则并对其进行修改以适合您的需要，或者从头开始编写规则。在初始阶段，建议坚持第一种方法。为了清楚起见，我们将使用第二种方法编写一条规则。
我们创建一个新文件，并尝试在名称中简要扼要地描述其本质。在这里，您应该遵守现有规则的样式。在本例中，我们选择名称win_using_settingsynchost_to_run_hijacked_binary.yml。接下来，我们开始用内容填充它。让我们首先在规则的开头填充元信息。我们已经拥有为此所需的所有数据。
我们简要描述规则在现场检测到的攻击类型
title，更详细的说明-在说明字段中，对于新规则，通常设置状态：实验性。可以通过多种方式生成唯一标识符；在Windows上，最简单的方法是在PowerShell解释器中运行以下代码：
PS C:\> "id: $(New-Guid)"
id: b2ddd389-f676-4ac4-845a-e00781a48e5f其余领域不言而喻，我只建议提供指向有助于理解攻击的资源的链接是明智的。这将有助于那些将进一步理解该规则的人，也对原始研究的作者为描述攻击所做的努力表示敬意。
我们现阶段的规则如下：
接下来，您需要描述日志的来源。如上所述，我们将依赖Sysmon日志，但是，随着通用类别的出现，习惯上使用process_creation类别来创建流程。有关广义类别的更多信息将在下面讨论。请注意，习惯上在定义字段中编写有关配置源的注释和建议，例如Sysmon配置功能：
现在有必要描述检测逻辑。这是最耗时的部分。可以通过许多标准来检测这种攻击，我们的示例并未声称涵盖所有可能的检测方式，因此，我们将描述一种可能的选择。
如果您查看发生的事件，则可以构建以下链。
首先，我们从起始行c开始该过程（PID：4712）：\ windows \ system32 \ SettingSyncHost.exe -LoadAndRunDiagScript join_oscd
请注意，该过程的当前工作目录是用户的TEMP目录。
接下来，正在运行的进程将创建一个批处理文件并开始执行。
执行批处理文件指令的过程收到了标识符7076。对事件进行进一步分析后，我们看到ipconfig.exe文件的启动，该文件不包含系统文件中固有的元数据，此外，该文件位于具有临时文件的文件夹中：
建议考虑启动其可执行文件不位于该文件的进程。在系统目录（C：\ Windows \ System32）中，并且如果父进程启动行包含子字符串“ cmd.exe / c”，“ RoamDiag.cmd”和“ -outputpath”。让我们用Sigma语法描述这一点并获得最终规则（可用于描述检测逻辑的结构的详细分析将在我们有关Sigma的系列文章的下一部分中给出）：
检查规则是否有效
我们将转换器启动到PowerShell查询中：
对于我们的情况，此查询将无法获得所需的结果，因为排除过滤器还会找到父流程可执行文件的映像的路径。因此，我们只是表示在单词Image之前不应该有字母t-单词Parent的末尾：
我们看到找到了我们的事件。该规则有效。
这就是实践中创建Sigma规则的方式。接下来，我们将详细描述负责检测的字段，即日志源的描述。
检测描述
该规则的主要部分是检测的描述，因为这是包含有关在何处以及如何查找攻击迹象的信息。此信息包含在日志源（位置）和检测（方式）属性的字段中。在本文中，我们将仔细研究logsource部分，并在本系列的下一部分中介绍检测部分。
事件源部分的描述（logsource属性）
事件源的描述包含在logsource字段的值中。本部分描述将从中传递检测部分事件的数据源（检测属性将在下一部分中讨论）。本节介绍了检测所需的源本身，平台和应用程序。它可以包含三个由转换器自动处理的属性，以及任意数量的可选元素。基本领域：
- 类别 -描述产品的类别。此字段的值示例：防火墙，Web，防病毒。同样，该字段可以包含广义类别，下面将进行讨论。
- 产品是创建日志的软件产品或操作系统。
- 服务 -将日志限制为某些服务子集，例如Linux的“ sshd”或Windows的“ Security”。
- 定义 -用于描述源功能的附加字段，例如，设置审核的要求（很少使用，可以在GitHub上找到此字段的规则示例）如果源有任何详细信息，建议使用此属性。
GitHub上 的官方Wiki 定义了一组字段，必须使用这些字段才能使规则成为交叉产品。下表中汇总了这些字段。
| 类别 | 产品 | 服务 |
|---|---|---|
| 视窗 | 安全 | |
| 系统 | ||
| sysmon | ||
| 任务计划程序 | ||
| WMI | ||
| 应用 | ||
| DNS服务器 | ||
| 驱动框架 | ||
| 电源外壳 | ||
| 经典的Powershell | ||
| linux | 认证 | |
| 经审核 | ||
| 克拉马夫 | ||
| 阿帕奇 | 访问 | |
| 错误 | ||
| process_creation | 视窗 | |
| 代理 | ||
| 防火墙 | ||
| 网络服务器 | ||
| 域名系统 |
接下来，我们将更详细地描述一些日志源，指示已使用的事件字段，并给出使用这些字段的规则示例。
代理类别事件字段
| 类别 | 产品/服务 | 领域 | 例子 |
|---|---|---|---|
| 代理 | 尿酸 | proxy_ursnif_malware.yml | |
| 尿道延伸 | proxy_download_susp_tlds_blacklist.yml | ||
| c-uri查询 | proxy_susp_flash_download_loc.yml | ||
| 尿干 | proxy_susp_flash_download_loc.yml | ||
| 用户代理 | proxy_powershell_ua.yml | ||
| cs字节 | -- | ||
| 饼干 | proxy_cobalt_amazon.yml | ||
| CS主机 | proxy_cobalt_ocsp.yml | ||
| CS方法 | proxy_downloadcradle_webdav.yml | ||
| 域名服务器 | proxy_apt40.yml | ||
| cs推荐人 | -- | ||
| CS版本 | -- | ||
| sc字节 | -- | ||
| 状态 | proxy_ursnif_malware.yml | ||
| src_ip | -- | ||
| dst_ip | -- |
此源的事件字段的描述
-------------------------------------------------- ------------- c-uri - URI, c-uri-extension - URI. c-uri-query - URI, c-uri-stem - URL ( :) . URIstem - c-useragent - UserAgent HTTP- cs-bytes - , cs-cookie - cookie, cs-host - Host HTTP- cs-method - HTTP- r-dns - DNS- cs-referrer - Referrer HTTP- cs-version - HTTP, sc-bytes - , sc-status - HTTP- src_ip - IP- dst_ip - IP-
防火墙事件字段
| 类别 | 产品/服务 | 领域 | 例子 |
|---|---|---|---|
| 防火墙 | src_ip | -- | |
| src_port | -- | ||
| dst_ip | -- | ||
| dst_port | net_high_dns_bytes_out.yml | ||
| 用户名 | -- |
此源的事件字段的描述
--------------------------------------------------------------- src_ip - IP- src_port - , dst_ip - IP- dst_port - , username - ,
Web服务器类别的事件字段
| 类别 | 产品/服务 | 领域 | 例子 |
|---|---|---|---|
| 网络服务器 | 尿酸 | web_cve_2020_0688_msexchange.yml | |
| 尿道延伸 | -- | ||
| c-uri查询 | -- | ||
| 尿干 | -- | ||
| 用户代理 | -- | ||
| cs字节 | -- | ||
| 饼干 | -- | ||
| CS主机 | -- | ||
| CS方法 | web_cve_2020_0688_msexchange.yml | ||
| 域名服务器 | -- | ||
| cs推荐人 | -- | ||
| CS版本 | -- | ||
| sc字节 | -- | ||
| 状态 | -- | ||
| src_ip | -- | ||
| dst_ip | -- |
此源的事件字段的描述
--------------------------------------------------------------- c-uri - URI, c-uri-extension - URI. c-uri-query - URI, c-uri-stem - URI ( :) . URI stem - c-useragent - UserAgent HTTP- cs-bytes - , cs-cookie - cookie, cs-host - Host HTTP- cs-method - HTTP- r-dns - DNS- cs-referrer - Referrer HTTP- cs-version - HTTP, sc-bytes - , sc-status - HTTP- src_ip - IP- dst_ip - IP-
广义类别
由于Sigma是用于描述基于日志的检测规则的通用格式，因此此类规则的语法应能够描述不同系统的检测逻辑。某些系统使用具有汇总数据而不是事件的表，并且来自不同来源的数据可能会描述相同的情况。为了统一语法并解决类似问题，引入了一种通用的日志源机制。目前，已经创建了一个这样的类别-process_creation。您可以在patzke.org博客上阅读有关此内容的更多信息。可以在分类法页面上找到此类别的字段列表（此页面还描述了其他受支持的类别）。
广义类别事件字段process_creation
| 类别 | 产品 | 领域 | 例子 |
|---|---|---|---|
| process_creation | 视窗 | 联合时间 | -- |
| 流程向导 | -- | ||
| ProcessId | sysmon_raw_disk_access_using_illegitimate_tools.yml | ||
| 图片 | win_susp_regsvr32_anomalies.yml | ||
| 文件版本 | sysmon_susp_file_characteristics.yml | ||
| 描述 | sysmon_susp_file_characteristics.yml | ||
| 产品 | sysmon_susp_file_characteristics.yml | ||
| 公司 | sysmon_susp_file_characteristics.yml | ||
| 命令行 | win_meterpreter_or_cobaltstrike_getsystem_service_start.yml | ||
| 当前目录 | win_susp_powershell_parent_combo.yml | ||
| 用户 | win_susp_schtask_creation.yml | ||
| 登录向导 | -- | ||
| LogonId | -- | ||
| TerminalSessionId | -- | ||
| 完整性等级 | -- | ||
| 冲动 | win_renamed_paexec.yml | ||
| md5 | -- | ||
| sha256 | -- | ||
| ParentProcessGuid | -- | ||
| ParentProcessId | -- | ||
| 父图像 | win_meterpreter_or_cobaltstrike_getsystem_service_start.yml | ||
| 父命令行 | win_cmstp_com_object_access.yml |
此源的事件字段的描述
--------------------------------------------------------------- UtcTime - UTC ProcessGuid - GUID ProcessId - PID Image - FileVersion - , Description - , Product - , Company - — , CommandLine - CurrentDirectory - User - , LogonGuid - GUID LogonId - TerminalSessionId - IntegrityLevel - , imphash - - md5 - MD5- , sha256 - SHA256- , ParentProcessGuid - GUID ParentProcessId - PID ParentImage - ParentCommandLine -
更新
在准备本文时，添加了新的通用类别：
- network_connection（示例sysmon_powershell_network_connection）
- dns_query（示例sysmon_regsvr32_network_activity）
- Registry_Event（sysmon_rdp_settings_hijack示例）
- file_creation
- process_access（sysmon_lsass_memdump示例）
- image_load（示例sysmon_mimikatz_inmemory_detection）
- process_terminated
它们都涉及Windows日志事件和Sysmon日志事件中的重复信息。我们建议您在编写规则时使用现有的广义类别。由于该项目正在积极开发中，建议跟随新类别的出现并根据进一步的创新来更新您的规则。
现有规则中的事件源使用情况统计
下表显示了用于描述日志源的最常见结构。最有可能的是，您会发现其中一种适合您的规则。
关于某些最常见来源使用描述字段组合的统计信息（破折号表示没有此字段）：
| 规则数 | 类别 | 产品 | 服务 | 样本语法 | 一条评论 |
|---|---|---|---|---|---|
| 197 | process_creation | 视窗 | -- | 日志来源：
类别：process_creation 产品：Windows |
Windows系统上进程创建日志的一般类别。包括Sysmon
EventID = 1 和Windows安全事件日志 EventID = 4688 |
| 68 | -- | 视窗 | sysmon | 日志来源：
产品：Windows 服务：sysmon |
Sysmon事件 |
| 48 | --
|
视窗 | 安全 | logsource:
product: windows service: security |
Windows Security Event Log |
| 24 | proxy | — | — | logsource:
category: proxy |
- |
| 15 | — | windows | system | logsource:
product: windows service: system |
Windows System Event Log |
| 12 | accounting | cisco | aaa | logsource:
category: accounting product: cisco service: aaa |
Cisco AAA Security Services |
| 10 | — | windows | powershell | logsource:
product: windows service: powershell |
Microsoft Windows PowerShell Event Log |
| 9 | — | linux | — | logsource:
product: linux |
Linux |
| 8 | — | linux | auditd | 日志来源：
产品：linux 服务：auditd |
Linux事件，澄清特定服务的日志（AuditD子系统） |
编写规则的技巧
编写新规则时，可能会出现以下情况：
- 现有规则中已经使用了正确的事件源。
- 使用此事件源的存储库中没有一个规则。
如果您遇到第一种情况，请使用现有规则之一作为模板。也许所需的日志源已经在其他规则中使用，那么这意味着不同SIEM系统的插件（后端转换器）的作者很可能在映射中已将其考虑在内，因此您的规则应立即正确处理。
在第二种情况下，有必要使用现有规则的示例来了解如何使用类别，产品和服务标识符。创建自己的日志源时，建议将其添加到现有后端的所有映射中。其他贡献者甚至开发人员都可以做到这一点，主要是告知这种需求。
我们在现有规则中创建了可视化的日志源描述字段组合：
日志源分布
将统计信息用于日志源属性子字段的组合
在本文中，我们提供了一个创建简单规则的示例，并讨论了事件源的描述。现在，您可以应用所获得的知识，查看Sigma存储库中的规则，并找出在特定规则中使用了哪些源。请关注我们的出版物：在下一部分中，我们将介绍Sigma规则中最困难的部分-描述检测逻辑的部分。
作者：积极技术开发和专家服务部（PT专家安全中心）专家Anton Kutepov