📚 课程目录第2章关联规则语言与语法基础

2. 关联规则语言与语法基础

关联规则工程的第一步不是写规则，而是理解“规则用什么语言表达”。不同SIEM平台的规则语法差异很大，但抽象到结构层面，它们共享同一套骨架：元信息 + 数据源选择 + 匹配条件 + 聚合/关联 + 输出动作。掌握这套骨架后，迁移到Sigma、SPL或AQL只是换“方言”。

一、三种主流规则语法的定位差异

Sigma是厂商中立的检测规则描述格式，用YAML书写，本身不执行检测，而是通过转换器编译成各平台查询。它的价值在于“一次编写、多平台复用”，适合做规则资产库的源头。SPL（Splunk Processing Language）是面向事件的管道式查询语言，以 search 开头，用 | 串联命令，擅长在海量事件中做统计、关联和时序分析。AQL（AQL Query Language，常见于QRadar等平台）是面向字段与条件的结构化查询语言，语法接近SQL，强调对规范化字段的过滤与聚合。

三者的核心区别可以概括为：Sigma描述“检测什么”，SPL描述“如何一步步处理事件流”，AQL描述“从哪些字段中筛选出什么”。工程实践中常见做法是用Sigma维护规则源，再编译为SPL或AQL落地执行。

二、规则结构的通用骨架

无论哪种语法，一条可运行的关联规则都包含以下要素：

标识与元信息：规则ID、名称、描述、严重级别、作者、参考链接。Sigma用 title、id、level 等字段表达。
数据源：指定日志类型或索引。Sigma用 logsource（product/category/service），SPL用 index= 或 sourcetype=，AQL用 SELECT ... FROM events 配合 WHERE 限定日志源。
检测逻辑：Sigma的 detection 块，SPL的搜索与管道命令，AQL的 WHERE 条件。
条件表达式：Sigma用 condition 组合多个选择器，SPL用布尔运算符和管道，AQL用AND/OR/NOT。
输出与响应：告警字段、分组方式、触发阈值。

下面这张图展示了三种语法在同一检测目标下的结构映射关系，帮助建立“同构不同形”的认知。

三、字段引用：规则与日志之间的“接口”

规则能否命中，取决于字段名是否与日志解析后的字段一致。这是关联规则工程中最容易出错的环节。Sigma使用逻辑字段名（如 Image、CommandLine、ParentImage），由转换器映射到目标平台的真实字段。SPL中字段来自索引时的提取，常见如 src_ip、dest_ip、user、process_name。AQL则依赖QRadar的DSM解析出的规范字段，如 sourceip、destinationip、username、processname。

字段引用有三种常见写法：精确匹配（Image: "C:\\Windows\\System32\\cmd.exe"）、通配匹配（CommandLine: "* -enc *"）、列表匹配（Image|endswith: "\\powershell.exe"）。Sigma还支持字段修饰符，如 contains、startswith、endswith、re、base64offset，这些修饰符在编译时会转换为对应平台的语法。

字段名大小写敏感性与平台有关。Sigma逻辑字段通常首字母大写，SPL字段多为小写，AQL字段名不区分大小写但建议统一小写。编写规则前务必用一条已知日志验证字段是否存在、值格式是否匹配。

四、条件表达式：从单条件到多条件组合

条件表达式决定规则的“判断逻辑”。Sigma的 condition 支持 and、or、not、1 of、all of、1 of them 等写法。例如：

detection:
  selection:
    EventID: 4688
    CommandLine|contains: '-enc'
  filter:
    User|endswith: '$'
  condition: selection and not filter

这段规则的含义是：匹配进程创建事件（EventID 4688）且命令行包含 -enc，同时排除以 $ 结尾的机器账户。SPL中对应写法为：

index=win EventCode=4688 CommandLine="*-enc*"
| where NOT match(User, "\$$")
| table _time, host, User, CommandLine

AQL中则写成：

SELECT QIDNAME(qid), sourceip, username, processname
FROM events
WHERE EventID = 4688
  AND CommandLine LIKE '%-enc%'
  AND username NOT LIKE '%$'

三种写法表达同一检测意图，但字段名、通配符和否定逻辑的写法各不相同。工程中建议先用Sigma写规则，再编译为目标平台语法，减少手工翻译带来的偏差。

五、聚合与关联：从单事件到多事件

真正的“关联规则”往往需要跨事件聚合。SPL用 stats count by src_ip 统计频次，用 transaction 将同一会话的事件归并，用 timechart 做时序分析。AQL用 GROUP BY 配合 HAVING count(*) > N 实现阈值告警。Sigma本身不直接表达复杂聚合，但可通过 condition 中的 | count() > N 扩展语法或借助转换器映射到平台聚合能力。

一个典型的暴力破解检测规则：5分钟内同一源IP对同一目标账户失败登录超过10次。SPL写法为：

index=auth action=failure
| bin _time span=5m
| stats count by src_ip, user, _time
| where count > 10

这里 bin 负责时间分桶，stats 负责分组计数，where 负责阈值判断。三个命令串联形成完整的聚合检测链。理解这条链，就理解了SPL关联规则的核心模式。

六、语法迁移的实践建议

面对多平台环境，建议建立“Sigma为源、平台语法为编译目标”的工作流。具体做法：用Sigma维护规则库，通过 sigma-cli 或 pySigma 转换器生成SPL、AQL或其它平台查询；对转换结果做字段映射校验，重点检查字段名、通配符、时间窗口和阈值是否与目标平台语义一致；最后在测试索引上回放历史日志，确认命中结果符合预期。

需要特别注意的是，Sigma的 logsource 到平台索引的映射不是自动完成的，需要维护一份映射表。例如 product: windows, category: process_creation 在Splunk中对应 index=win EventCode=4688，在QRadar中对应 LOGSOURCETYPENAME(devicetype)='Microsoft Windows Security Event Log'。这份映射表的质量直接决定规则迁移的准确率。

不要直接把Sigma规则中的字段名当作目标平台字段名使用。例如Sigma的 Image 在Splunk中可能是 process_name 或 New_Process_Name，取决于你的字段提取配置。迁移后必须逐字段验证。

掌握规则语法不是终点，而是起点。真正决定规则质量的，是对日志字段的理解、对攻击行为的拆解，以及对误报来源的持续治理。语法只是把这些理解翻译成机器可执行表达的工具。