来源：https://blog.apnic.net/2021/10/20/sigma-a-generic-log-signature-format/

对IT系统和网络的大多数攻击都表现在事件日志中，这些日志存储在许多组织的SIEM系统或其他日志存储解决方案中。这使得它们成为检测网络中入侵者的好地方。然而，挑战并不多。

第一个挑战是了解和开发攻击技术的特征列表。这通常是一项耗时的任务，因为必须在实验室环境中复制攻击，并且必须在日志背景噪声中识别特定于攻击的日志记录。来自威胁情报界的某人可能已经共享了签名，但其格式与该组织的SIEM不兼容。转换来自不同查询语言并使用不同字段命名的查询是一项容易出错的任务。

另一个挑战是许多组织将日志存储在不同的存储库中。这可能是由于合并和收购，也可能是一个组织的战略。可能还有技术原因或简单的许可原因，这意味着只有特定的日志被摄取到SIEM中，而其余的日志则进入所谓的数据湖。不同的日志存储库意味着需要用不同的查询语言来编写日志签名。

Sigma是一个试图解决这些挑战的开源项目。它由三个部分组成:

（1）通用Sigma规则格式的语言规范。

（2）一个包含超过1000条攻击技术规则的存储库。

（3）将Sigma规则转换为各种查询格式的工具。

它都是开源的，可以在SigmaHQ GitHub组织中找到。可以使用以下命令行在本地克隆它:

git clone https://github.com/SigmaHQ/pySigma.git

一、Sigma规则是什么样的?

让我们以CVE-2020-0688的Sigma规则为例(图2)。这是最近的一个Exchange Server漏洞，被威胁行为者积极利用，以在托管有漏洞的Exchange实例的组织中获得立足之地。在不同的博客文章中描述了对利用企图的检测，这是Sigma规则的基础:

这个Sigma规则有五个组成部分:

1、元数据，包括标题、唯一标识符和一些进一步的信息，这些信息允许分析人员将检测规则上下文化。

2、日志源定义，将签名与某条日志绑定，此处为webserver日志。

3、检测规则本身是在将日志事件字段与特定于利用尝试的值关联起来的定义中定义的。

4、这些检测项与一个条件链接在一起。

5、最后，规则包含一些额外的信息，比如有趣的事件属性，包括规则匹配的事件、已知的误报、严重性级别，以及MITRE ATT&CK战术和技术的链接。

图3显示了针对另一个Exchange Server漏洞CVE-2021-26857的另一个Sigma规则。

构成Sigma规则的元素与第一个例子相同，但是检测逻辑完全不同。该规则描述了由Sysmon或许多端点检测和响应(EDR)产品触发的进程创建事件(1)。Exchange服务器的统一消息工作进程通常不会产生进程，除非在崩溃的情况下，有时会产生Windows错误报告进程，这在检测规则及其条件(2)中定义。

二、规则的转换

下一步，利用Sigma转换工具sigmac将Sigma规则转换为目标查询语言。该工具可以安装pip:

pip install sigmatools

或者在一个虚拟的Python环境中，所有的依赖都可以用Pipenv从克隆的Sigma库中衍生:

pipenv shell

让我们假设结果查询应该在基于elasticsearch的SIEM中使用，该SIEM使用ECS字段命名方案。这可以通过从Sigma库克隆的根目录运行以下命令简单完成:

tools/sigmac -t es-qs -c ecs-proxy   rules/web/web_cve_2020_0688_msexchange.yml

参数-t选择Sigma转换器的后端，该后端负责将规则转换为目标查询语言。后端es-qs转换为Elasticsearch查询字符串，可以粘贴到Kibana中。参数-c选择一个配置。配置ECS -proxy与Sigma转换器一起提供，并为代理日志实现ECS命名方案。结果查询将是:

(http.request.method:"GET" AND url.original.keyword:(*\/ecp\/* OR *\/owa\/*) AND url.original.keyword:*__VIEWSTATE\=*)

现在我们来转换第二条规则。这一次，我们需要一些额外的配置来将通用日志源process_creation映射到特定的日志源。假设我们所处的环境中使用Elasticsearch作为SIEM，使用Sysmon作为日志源，为端点上的进程创建生成事件。转换命令如下:

tools/sigmac -t es-qs -c sysmon -c winlogbeat rules/windows/process_creation/sysmon_cve_2021_26857_msexchange.yml

命令行中提供了两个配置。配置sysmon对应具体的日志源和事件标识符。winlogbeat将Sigma规则中的字段名映射到winlogbeat使用的ECS方案。结果查询是:

((winlog.event_id:"1" AND winlog.channel:"Microsoft\-Windows\-Sysmon\/Operational") AND winlog.event_data.ParentImage.keyword:*UMWorkerProcess.exe AND (NOT (winlog.event_data.Image.keyword:(*wermgr.exe OR *WerFault.exe))))

在使用Windows审计日志记录的环境中，只有更改一些命令行参数才能为Splunk SIEM转换相同的规则:

tools/sigmac -t splunk -c windows-audit -c splunk-windows rules/windows/process_creation/sysmon_cve_2021_26857_msexchange.yml

它会导致这个Splunk查询:

((EventCode="4688" source="WinEventLog:Security") ParentProcessName="*UMWorkerProcess.exe" NOT ((NewProcessName="*wermgr.exe" OR NewProcessName="*WerFault.exe")))

三、为Sigma项目和展望做出贡献

因为Sigma项目是开源的，它依赖于贡献。该项目托管在GitHub上，通过导航到目标目录并添加一个新文件，可以通过web界面贡献新的规则:

Sigma Wiki包含一个规则创建指南和一个可以用来创建新规则的模板。不要犹豫——在合并pull请求之前，规则会被检查，问题会被修复或提出建议。

反馈也很有价值，例如，如果检测规则在某些条件下导致假阳性，那么反馈可以打开一个问题;或者，如果它已经被积极用作检测，并且可以被确认为有用，那么小的拉取请求可以将规则的状态从实验状态改变为稳定状态。目前，大部分规则仍处于实验阶段，还有很大的改进空间。

您可以贡献的另一个领域是转换工具。目前，在pySigma库中开发了一个完整的重写。此外，一个新的CLI正在开发中，但尚未发布。在未来，后台将作为独立的项目来维护，许多来自当前Sigma转换器的后台需要移植到psigma，或者一些目前不再维护的后台需要有人来维护。