Sigma检测规则实战：一份YAML统一日志查询，贯穿代码安全监控

像我们这种常年跟安全告警打交道的人其实都有同一个感觉告警越来越多真正能看出问题的时间越来越少。代码安全、日志安全、主机安全每一层都堆着一堆工具但工具和工具之间往往是割裂的。SIEM 里塞满了原始日志规则写得五花八门换一个平台就要重写一遍查询语法换个后端就要换一套检测逻辑。这不叫安全体系这叫规则维护地狱。Sigma 就是从这个痛点里长出来的东西。它是一套开放的、基于 YAML 的检测规则描述规范只要你用它的标准格式写一条规则就能通过转换工具输出成 Elasticsearch、Splunk、QRadar、Microsoft Sentinel 等不同后端能直接吃的查询语句。换句话说它把“检测规则”从具体平台里解耦了让你用一份规则跑遍所有日志分析系统。所以我在给团队引入新工具的时候第一件事往往不是采购商业产品而是先把 Sigma 搭起来作为“侦察兵”用最轻的方式把该看的信号先捞出来再决定要不要上重武器。这篇文章我会把 Sigma 在企业代码安全监控里的实际用法、规则拆解、转换流程、踩坑记录连带着怎么把它和代码仓库、CI/CD 流水线结合起来一次性讲清楚。这份经验适合安全工程师、DevOps/DevSecOps 实践者也适合刚刚开始搭日志检测体系、不想被厂商绑定的技术负责人阅读。文章里所有规则和命令均是我个人在同类场景下的推荐写法写出来的是可直接复制的工程配置不是空谈架构。1. 为什么我把 Sigma 当成代码安全体系的“侦察兵”1.1 代码安全不只是“扫描代码”这一件事很多人听到“代码安全”四个字第一反应是静态代码扫描SAST、依赖漏洞扫描SCA、软件成分分析。没错这些都是代码安全的重要组成但它们解决的是“代码本身有没有问题”而不是“运行环境里有没有人正在利用这些问题”。真正让我形成“侦察兵”这个判断的是某次攻防演练里的真实体会。攻击者已经通过一个第三方库漏洞拿到了测试环境某台主机的命令执行权限SAST 和 SCA 都没拦下他因为我们确实没扫到那个已下线的老旧组件。但是他在主机上执行了下载脚本、改动了注册表、拉起了一个内存马。这些行为全部都真实地写在了系统日志里。只要能把这些日志里的小动作及时摘出来就能在事情闹大之前发现他。而 Sigma 恰好就是干这个的——把“可疑的行为特征”用一种统一、可移植的规则语言表达出来喂给日志查询系统去匹配。所以我把代码安全的范围拉宽了一层代码侧用 SAST/SCA 做“体检”运行侧用 Sigma/SIEM 做“巡逻”。两者组合起来才构成了完整的“发现-分析-响应”闭环。Sigma 不分析代码文件本身它分析的是代码运行后留下的行为轨迹所以它跟 CodeQL、Semgrep 这类静态工具不冲突反而互为补充。1.2 一条规则多处运行解决平台绑定问题早期团队里Splunk 一套规则Elasticsearch 一套规则云厂商自家的威胁检测又是一套规则。同一个“PowerShell 从远程地址下载并执行”的检测点要写三四遍不同的查询语法还得人为保证三边逻辑完全一致。只要两边语法细节稍有差异平台之间就会出现检测盲区明明一份日志里已经出现了可疑行为另一个平台就是查不出来。Sigma 的定位就是把这一层彻底抹平。它定义了检测逻辑的“中间表示层”你只描述“我要找什么”而“放在哪里找、用什么语法找”由转换器去处理。我在本地用一条规则验证完检测效果再批量转换输出成各平台查询语句提交到规则仓库整套流程大概五分钟。平台怎么换规则逻辑不动只换转换目标即可。这一点在现在基础设施流动性极强的环境下非常值钱。2. Sigma 规则解剖看似轻量实则五脏俱全2.1 一套规则的基础字段先看一条最普通的 Sigma 规则我拿一个 Windows 下可疑 PowerShell 执行为例子逐段拆开给你看title: Suspicious PowerShell Download and Execute id: 8b2f1d34-6e47-4c5a-9f4d-1f7c3d2e0a91 status: experimental description: Detects PowerShell downloading a script from remote and executing it in memory references: - https://attack.mitre.org/techniques/T1059/001/ author: ops-sec date: 2025/01/15 tags: - attack.execution - attack.t1059.001 logsource: category: process_creation product: windows detection: selection_img: Image|endswith: - \powershell.exe - \pwsh.exe selection_cmd: CommandLine|contains|all: - -ExecutionPolicy Bypass - IEX - DownloadString condition: selection_img and selection_cmd falsepositives: - Administrative troubleshooting scripts level: high这条规则的密度比一般查询语句高得多。title、description、references、tags这些元信息看起来只是方便人读的说明但它在规则管理上的价值反而被很多人低估。当规则数量超过一百条时没有元信息的规则就是一堆没法排序、没法关联的死代码。tags直接映射 MITRE ATTCK我可以按攻击战术编排做规则覆盖分析看看自己的监控体系到底覆盖到了哪些攻击路径哪些还是空白。真正决定检测逻辑的是logsource和detection。logsource声明了这条规则吃的日志类型比如process_creation进程创建、windowsWindows 平台这是为了让转换器知道该匹配哪些字段集。detection下面是一个个“选择器”每个选择器由字段名、修饰符和值组成最后用condition把这些选择器组合成一个布尔表达式。也就是说Sigma 不是在写死一条查询而是在写一套逻辑上完全可拆解的匹配蓝图。2.2 修饰符让匹配逻辑更精准的关键光看刚才的例子你可能还没意识到修饰符的重要性。Sigma 最灵活的部分就在字段名后面的|修饰符上。常用的有contains、startswith、endswith、all、re等它们决定了怎么匹配这个值。举个例子一个检测“进程命令行里出现过敏感字符串”的场景不加修饰符的写法是精确等值匹配出结果的前提是日志字段值跟规则值完全一样这在真实日志里几乎不存在。加contains就变成模糊子串匹配实用度立刻上来加all可以将多个条件并列要求全部命中加re就直接上正则表达式适合复杂模式。我不建议一上来就写正则。原因很简单正则在日志检索场景下消耗的机器资源比普通子串匹配高一个数量级而且很容易写错要么漏报要么把线上搜索性能压垮。我自己习惯是先用contains/endswith这类简单匹配搭出基础规则确认能稳定命中已知样本后再看有没有必要升级成精确的正则。也就是说先让规则“能跑”再让规则“跑得聪明”。2.3 条件组合与聚合窗口condition字段是布尔逻辑核心理解它才算真正理解了 Sigma。它可以写selection、selection1 and selection2、1/all of them甚至all of selection_*。这种可读性极强的语法让规则作者不用去管具体后端的查询语言只要把检测目标拆解成几个子条件就行。还有一个很多人没注意到的能力Sigma 支持聚合条件。比如“同一源 IP 在十分钟内触发了十次以上失败登录”这种必须在时间窗口内聚合的事件Sigma 用| count()操作也可以表达转换器会自动转成后端支持的聚合语法。detection: selection: EventID: 4625 LogonType: 3 timeframe: 10m condition: selection | count() by src_ip 10这条规则转换成 Elasticsearch 以后就是一段带 date histogram 的聚合查询转换成 Splunk 以后就是transaction命令。规则写一次聚合逻辑跟着语义走不用在每一家后端各写一遍窗口聚合。这也是我坚持“能用 Sigma 描述就不用裸查询”的最直接原因——工作量节省是小事逻辑一致性才是大事。2.4 编一条规则前的四步思考法我总结了一个比较固定的流程用来保证规则质量先定日志源。手上有哪些日志是进程创建、网络连接、DNS 查询还是认证日志不确定日志源规则写出来也没法落地。再定敌人行为。攻击者在这个日志源里会留下什么特征是文件名、命令行参数、网络地址还是时间频率异常要具体到一个可以被检索的特征。然后定误报边界。这个特征会不会出现在正常系统行为里如果会怎么排除比如仅监听管理端口的管理工具就需要加白名单条件。最后写规则并验证。先在测试环境用历史已知样本验证命中再放到最近几天的生产流量里跑误报率满意后才提交上线。这套流程看起来很朴素但能把规则从“纸面逻辑”推向“生产可用”。我见过太多规则作者只看样本不看误报结果规则上线第一天警报量直接把值班同事淹没了。3. 实操记录用 Sigma 工具链本地跑通检测3.1 最小化环境搭建在真实工程里我会优先用 Python 生态来搭建 Sigma 工具链因为它的后端插件最全、迭代最快。你需要的东西不复杂Python 3.9 以上pip 安装 Sigma CLI 与后端转换插件一条写好的规则文件一份可用的测试日志样本我推荐先装下面这些包这套组合覆盖了最常见的企业日志分析场景pip install sigma-cli pySigma-backend-elasticsearch pySigma-backend-splunk pySigma-backend-qradar装完以后有两个命令是我日常用得最多的。第一条是规则校验sigma validate rules/*.yml这个命令的作用是自动检查 YAML 语法、字段类型、必填项缺失、修饰符拼写等行为。它不会管规则逻辑好坏但能拦住大量低级错误。我习惯在自己写的规则进版本库之前都先跑一遍。第二条是规则转换把 Sigma 规则输出成目标平台的查询语法sigma convert rules/suspicious_powershell.yml --target elasticsearch --pipeline ecs_windows --output query.json这条命令背后做的事情就是把前面那段 YAMLdetection逻辑按照字段映射表和修饰符规则翻译成 Elasticsearch bool 查询。输出是 JSON直接可以贴到 Kibana 或者安全产品的 API 里用。3.2 用真实日志反推验证工具链搭好后的第一个关键动作不是去搜生产环境而是先拿有标注的历史样本做命中验证。我自己的做法是找一段确定包含恶意行为的旧日志转化成 JSON 或者 CSV在本地起一个 Elasticsearch 单节点把日志导进去再用转换出来的查询语句打一次确认能拿到目标告警。这件事千万不要跳过。测试环境里跑不出的规则放到生产环境也不会有奇迹。我前几年犯过的错误就是跳过验证直接把一条自认为写得完美的规则推到生产结果因为时间字段类型不匹配查询报错好在转换工具会打印明确错误信息才发现字段映射对错了。验证时我最关注两件事第一目标行为是否真的命中第二查询耗时是否在接受范围内。如果一条规则匹配全量日志要十几秒那就要质疑规则里是不是用了过多的正则或者全字段通配匹配需要继续优化条件组合。3.3 转换到不同后端逻辑不掉链子假设团队这边用的 Elasticsearch另一套安全运营平台是 Splunk场景很常见。Sigma 的价值在这一步直接拉满sigma convert rules/suspicious_powershell.yml --target splunk --output query.spl你看到的输出会是一段 Splunk 搜索语句比如(Image IN (*\\powershell.exe, *\\pwsh.exe) AND CommandLine IN (*IEX*, *DownloadString*, *ExecutionPolicy Bypass*))。字段名、通配符语法都已经自动适配好了。这里隐藏了一个更重要的工程细节pipeline参数。比如ecs_windows会帮助你自动把 Windows 原生日志字段映射成 Elastic Common SchemaECS标准字段。直接用原始字段名往往在跨后端后会失配用了 pipeline 以后转换器会把规则里的CommandLine映射为process.command_line。这个映射环节才是 Sigma 解决“平台鸿沟”的实质。你不需要自己去给每个环境手写转化脚本工具链已经替你完成了这一层对接。3.4 把规则当代码管起来规则文件本身就是 YAML 代码应该享受代码的待遇版本管理、评审、测试、发布。我建议在 Git 仓库里建一个sigma/rules目录按平台或日志类型分子目录配合 GitHub Actions 或 GitLab CI 跑三道检查格式校验sigma validate检查所有 新改动 规则。样例命中测试准备一组已知恶意样本、一组白样本在测试 Elasticsearch 中导入自动跑规则并断言结果。规则数量与覆盖度对比对比 MITRE ATTCK 标签覆盖率看看接口是不是持续有增长。这相当于把规则迭代流程工程化不再是人肉写规则、人肉上传、人肉改 bug 的单点操作。规则同样要经历 code review语义是否清晰、命名是否规范、误报排除是否合理。正因为 Sigma 是纯文本的它才能用普通 diff 工具来审一行改动意味着什么一目了然。4. 常见坑和排查技巧实录4.1 日志源字段映射错位这是我最常遇到的问题几乎没有例外。你在 Windows 日志里可能看到EventID: 4688但在 ECS 化之后字段名变成了winlog.event_id还有可能是event.code取决于管道收口和数据中间层的处理。如果规则使用了原始字段但转换 pipeline 指定了ecs_windows字段可能被映射走也可能因为映射关系缺漏而保持原样。我的排查思路很直白先确认测试环境里日志长什么样再跑转换输出最后对比结果中的字段名。如果字段名不对就会换成 pipeline 或直接修改规则里的字段名。不要侥幸认为所有后端字段定义都是同一个规范。4.2 转义、大小写和特殊字符的坑被折腾最多次的是反斜杠和引号。Windows 路径里到处是\而 YAML 本身也把\当转义符处理一不小心例子里的\powershell.exe写成了\p在解析时就变成了控制字符。老老实实加单引号锁字符串或者用双反斜杠是最稳妥的选择。大小写问题同样隐蔽。同一段命令行Windows 偶尔会保留原始大小写有些标准化管道又会统一转小写。如果规则里明确写了powershell.exe而日志标准化后变成了PowerShell.exe就漏报了。解决办法是优先用|endswith 通配符去匹配路径尾部或者提前规划好统一大小写策略。4.3 聚合规则的时间窗口timeframe是个容易让人误解的参数。在 Splunk 后端它会被转成时间范围桶在 Elasticsearch 后端可能对应着日期直方图的分桶大小。同样的timeframe: 10m两家后端统计的窗口边界可能不完全一致引发的告警结果也略有差异。针对高频误报和漏报我会手动检查各后端生成的聚合逻辑必要时在后端侧微调窗口参数。4.4 实用问题速查症状常见原因处理思路转换报错“unknown modifier”修饰符拼错或版本不支持检查 转换后查询无结果字段映射漂移或日志字段名不一致打开测试日志对比转换输出字段名告警量爆炸误报排除条件不足或匹配过宽增加白名单选择器、按and not exclusion组合条件查询性能慢过度使用正则、通配符前导换成 规则语法没问题但后端不识别pipeline 和后端插件版本不一致检查后端插件版本确认对 ECS 映射的支持度这张表其实是我自己的“规则排障第一页纸”。每次有新同事接手规则维护我给他们的第一份资料就是它。5. 接入代码安全流水线的工程改造5.1 日志即代码规则进版本库前面已经把 Git 管理说了一遍这里我想再强调一下为什么这比听起来更重要。你面前是一个持续迭代的代码仓库每次提交都有可能引入新的行为特征同时也会修复旧的问题。检测规则如果不跟着代码节奏演进安全监控很快就会落后于业务变化。我目前管理的规则仓库分四层core基地规则基本不常动、appsec应用安全相关事件、infra基础设施异常行为、incident响应过程中临时沉淀的规则。每个目录下按 MITRE ATTCK 战术标签建子目录。提交规则时强制关联一个 issue至少写清楚“为什么这条规则存在、预期拦截什么行为、白名单怎么设计”。5.2 从实时告警演进到 CI 阶段检测把 Sigma 放进 CI最直接的做法是每次构建后把单元测试和集成测试日志统一格式化为标准事件日志再跑一遍规则集及时发现开发阶段就出现的安全行为异常。这一步可以在功能测试阶段触发而不是等代码上线后靠 SIEM 从生产流量里发现。实际操作中我会在 CI 里加一个阶段叫security-log-scan注意这里不是静态源码扫描而是把应用运行过程中产生的结构化日志回放给规则引擎相当于做一次“动态安全行为回归测试”。比如一个服务在更新后突然开始反复访问外部地址SAST 不会报但 Sigma 规则配合 CI 日志流就能发现。这种模式在代码仓库里跑久了会让开发同学非常直观地看到安全规则的约束力而不是只在线上出问题时隔着屏幕挨骂。5.3 与 SAST/SCA 的分工和配合不要用 Sigma 去替代 SAST/SCA也不要用它们替代日志检测。在我的划分里SAST/SCA 负责代码本身的漏洞回答“代码有没有病”Sigma/SIEM 负责运行行为的风险回答“代码跑起来以后干了什么”两者重叠部分很少但配合起来非常有意思。最有价值的配合场景是SAST 报了一个高危漏洞确认可利用之后我立刻根据漏洞特征写一条 Sigma 规则覆盖攻击者利用该漏洞后的行为模式。也就是说代码漏洞被修复、样例被打上补丁的同时运行侧也有了持续监视该攻击模式的能力。这等于把一个单点漏洞的发现转化成了体系化的检测规则而不是修完就完事。5.4 控制规则规模避免监测反噬任何监控体系都会面临一个终极问题规则太多告警太吵。Sigma 的轻量特性反而容易让人失控因为写规则太容易了一个上午能堆十条规定。我给自己定了一个硬性指标每新增一条规则至少要在测试环境跑三天误报率超过百分之五就回炉重写或者直接砍掉。把规则数量控制在可维护的精简范围内比追求“尽量多覆盖”更实用。规则数量一旦过千维护成本会急剧上升没人能保证每条规则在真实环境里的质量。这时候你就可以体会到侦察兵的意义不在于把每个脚印都记录下来而在于知道哪些脚印必须有名字。6. 一点个人经验和扩展想法6.1 亲测有效的维护节奏我自己在项目里保持的节奏是这样周一花三十分钟看上周规则命中统计哪些规则曾经一周内没有命中哪些规则命中后确实对应真实攻击行为周三花二十分钟审新提交的规则周五统一跑一次规则库全量验证。每季度做一次 MITRE ATTCK 覆盖度复盘针对薄弱战术补充规则。这套节奏不需要占用完整工作日但能让规则库始终保持活力。还有一点必须提规则不是写得越怪就越厉害。真正一条好规则应当是一眼能看出它想找什么行为的规则。未来有人在排障时看这条规则应该能直接根据名字和描述定位它到底在监视什么。用词要直白、命名要有规律别在五年后让后来人翻开规则库面对一屋子谜语。6.2 后续还能往哪个方向延展现在的 Sigma 生态里规则共享已经非常成熟社区积累了覆盖大量攻击场景的开源规则库可以直接下载使用。再往后我关注的方向是把规则转成机器学习特征或者态势感知平台的事件编排规则让 Sigma 不再是孤立的“查询生成器”而是能参与自动化响应的规则引擎。另外一方面在代码安全侧把 CI 日志直接对接 Sigma 的工作也值得提前摸索。现在很多团队已经做到“代码变更即部署”那下一步自然就是“代码变更即检测”。“检测”的触发时机越靠前安全团队介入的成本就越低。一旦形成这样的自动化链路代码仓库里任何一个异常行为的首次出现就不再依赖某位值班工程师的灵光一现而是整套规则体系在替你盯梢。这种把规则前置、逻辑统一、工具轻量化的做法是我这几年做安全建设最一致的体会。与其不断叠重型设备不如先养好一两个能快速跑遍全场的侦察兵。毕竟安全这件事很多时候拼的不是火力多猛而是谁先发现敌人。