sigma相关文档信息

相关git仓库

Sigma规则

该项目的主要目的是提供一种结构化的形式，研究人员或分析师可以在其中描述他们曾经开发的检测方法，并使其可以与他人共享。

 

Sigma 用于日志文件，Snort 用于网络流量，YARA 用于文件

 

Sigma的日志规范

sigma-specification/Sigma_specification.md 在 main ·SigmaHQ/sigma-specification (github.com)

 

id: 唯一标识

 

logsource: category , product, service

       “category”值用于选择由特定产品组（如防火墙或 Web 服务器日志）

       “product”值用于选择某个产品的所有日志输出

       “service”值仅选择产品日志的子集，例如 Linux 上的“sshd”

       可以根据logsource指定检测对应的索引

 

detection格式：

detection:    定义检测规则的属性，包含一组搜索标识符。

     （1）列表中的所有映射项逻辑上用“或”连接  

     匹配 EvilService 或 svchost.exe -n evil 的字符串列表

       keywords:

               - EVILSERVICE

               - svchost.exe -n evil

      （2）Map中的所有元素用逻辑“与”连接 

匹配日志 Security 和 (事件 ID 517 或事件 ID 1102)

       selection:

                     EventLog: Security

                     EventID:

                            - 517

                            - 1102

搜索标识符(不分大小写，可用通配符*?)

可用修饰符(end/startswith/contains)        

如ImageLoaded|endswith: '\kprocesshacker.sys'

       （3）condition         指定检测的触发条件。

 

 

 

 

目前，存储库提供三种类型的规则：

 

通用检测规则 – rules目录

       与威胁无关，其目的是检测潜在威胁参与者曾经、可能或将要使用的技术或过程的行为或实现。

 

威胁搜寻规则 - rules-threat-hunting目录

               范围更广，旨在为分析师提供搜寻潜在可疑或恶意活动的起点

 

新兴威胁规则 – rules-emerging-threats目录

       是涵盖特定威胁的规则，在特定时间段内及时且相关。这些威胁包括特定的 APT 活动、利用零日漏洞、攻击期间使用的特定恶意软件,...等。

 

Sigma适用日志源

sigma-specification/Taxonomy_specification.md at main · SigmaHQ/sigma-specification (github.com)

 

可以看到大部分规则都是支持sysmon,或channel日志。

且大部分字段是对齐的sysmon的字段。

Lunix相关的日志源支持的很少。

 

sigma检测规则到日志源的字段转化

由上可知，大部分对应了sysmon,

好像也有方法可映射字段，不知道在哪

sigma-specification/Sigma_specification.md at main · SigmaHQ/sigma-specification (github.com)

Backends | Sigma Detection Format (sigmahq.io)

转化应该需要用到pipeline,backend.

管道通常用于确保 Sigma 中使用的字段正确映射到每个 SIEM 中使用的字段

处理管道定义一系列转换，这些转换在将 Sigma 规则转换为目标查询语言之前应用于该规则。

 

处理管道被编写为 YAML 文件（通常由最终用户使用）或 Python 代码（通常由 Sigma 后端开发人员使用）。

 

Sigma规则模板

请确保在要推送到公共存储库的规则中设置了以下字段：

 

title: a short capitalised title with less than 50 characters

id: generate one here https://www.uuidgenerator.net/version4

status: experimental

description: A description of what your rule is meant to detect

references:

    - A list of all references that can help a reader or analyst understand the meaning of a triggered rule

tags:

      使用来自 MITRE ATT&CK 的标签、CAR 和 CVE 编号的标签。

    - attack.execution  # example MITRE ATT&CK category

    - attack.t1059      # example MITRE ATT&CK technique id

    - car.2014-04-003   # example CAR id

author: Michael Haag, Florian Roth, Markus Neis  # example, a list of authors

date: 2018/04/06  # Rule date

logsource:                      # important for the field mapping in predefined or your additional config files

        产品（例如 Linux、Windows、Cisco）

        服务（例如 Sysmon、LDAPD、DHCP）

        类别（例如process_creation）

    category: process_creation  # In this example we choose the category 'process_creation'

    product: windows            # the respective product

detection:

    selection:

        FieldName: 'StringValue'

        FieldName: IntegerValue

        FieldName|modifier: 'Value'

    condition: selection

fields:

    - fields in the log source that are important to investigate further

falsepositives:

    - describe possible false positive conditions to help the analysts in their investigation

level: one of five levels (informational, low, medium, high, critical)

 

 

反斜杠的使用

反斜杠在 Sigma 中有两种功能：

1. 作为普通值的反斜杠
2. 作为前缀来转义具有特殊意义的字符：反斜杠 \ 本身，以及通配符 * 和 ?。

这样处理反斜杠的优点是包含单个反斜杠的值（常见情况）可以以普通方式表达。然而，一些特殊情况需要额外的转义：

• 包含单个反斜杠的值可以以普通方式表达：C:\Windows\System32\cmd.exe。
• 不要使用反斜杠转义单个反斜杠，写前一个例子中的普通值而不是 C:\Windows\System32\cmd.exe。
• 如果要表示两个普通反斜杠，使用四个反斜杠：\\foo\bar 结果为 \foo\bar。
• 写 \\ 表示两个反斜杠。
• 写 * 表示普通通配符 * 作为结果值。
• 写 \* 表示普通反斜杠后跟通配符 * 作为结果值。
• 写 \* 表示普通反斜杠后跟普通 * 作为结果值。
• 注意反斜杠在正则表达式中有特殊语义。

值修饰符

虽然技术上可以随意链接值修饰符，但并不是所有的组合都是有意义的。应遵循以下排序规则：

• 添加通配符的修饰符（如 startswith、endswith 和 contains）不应跟在编码修饰符（如 base64、base64offset）之后，因为它们也会编码通配符本身，导致丧失通配符的特殊功能。
• 值修饰符链不应以字符集编码修饰符（如 utf16、utf16le、utf16be 和 wide）结尾。结果值在内部表示为字节序列而不是文本字符串，并包含通常难以在查询中处理的空字符。因此，应该在这些修饰符之后使用编码修饰符（如 base64、base64offset）。
• 通常，不建议将 re 类型修饰符与任何其他修饰符组合。
• 一般来说，all 可以放在任意位置，因为所有修饰符都可以处理单个值以及列表，但按惯例应将此修饰符放在末尾。

一些常见的组合是：

• |contains|all：列表中的所有值都包含在记录的值中。这对于以无序方式表示命令行参数很有用。
• |utf16|base64offset|contains：值是 Base64 编码的 UTF16，可能包含在值的任意位置（例如，作为更大 Base64 值的一部分）。

在设置级别时应用以下指南：

• 关键级别的规则不应触发误报，并且具有高度相关性。
• 高级别的规则触发高度相关的威胁，需要手动审核（罕见的误报 > 需要基准化）。
• 高级别和关键级别的规则表示一个事件（如果不是误报）。
• 低级别和中级别的规则表示可疑活动和政策违规。
• 信息性级别的规则具有信息性特征，通常用于合规性或关联目的。

网页端服务

sigconverter.io, a user-friendly converter for Sigma rules. This project is designed to keep in sync with the pySigma project's backends.

 

与pySigma项目的后端同步。

 

这个服务应该是pySigma项目的前端使用服务。

 

其实是通过sigma-cli进行转化的。

 

sigconverter.io - sigma rule converter

可以选择elastic的siem_rule进行转化，将sigma规则转化为查询语句。

 

或者 规则映射。

 

 

 

 

之后可以进一步将其插入mysql数据库中。

 

 

Pysigma

SigmaHQ/pySigma: Python library to parse and convert Sigma rules into queries (and whatever else you could imagine) (github.com)

 

文档pySigma Documentation — pySigma documentation (sigmahq-pysigma.readthedocs.io)

 

pySigma 是一个用于解析和转换 Sigma 规则为查询的 Python 库

 

支持将规则转换为查询语言的后端和

 

用于转换日志数据模型规则的处理管道被分离成专门的项目。

 

pySigma is a python library that parses and converts Sigma rules into queries. It is a replacement for the legacy Sigma toolchain (sigmac) with a much cleaner design and is almost fully tested. Backends for support of conversion into query languages and processing pipelines for transforming rule for log data models are separated into dedicated projects to keep pySigma itself slim and vendor-agnostic. See the Related Projects section below to get an overview.

 

 

 

SIEGMA

github项目

 

目的是使用一个预定义的配置/映射集合， 利用Sigm规则格式与引擎，自动化生产SIEM规则。

      

       可以简单的根据特定用例添加自定义字段