1. 项目概述从“黑盒”到“白盒”的威胁检测进化在安全运营中心SOC待过几年的朋友大概都经历过这样的场景告警控制台突然弹出一堆高优先级警报你点进去一看触发告警的是一个陌生的规则名称比如Suspicious_PowerShell_EncodedCommand。你手头有进程命令行、有父进程信息但你就是不太确定这个规则到底在检测什么它的逻辑边界在哪里为什么这个特定的参数组合就被判定为“可疑”你只能依赖规则描述里那几句可能已经过时的注释或者干脆去问编写这条规则的同事——如果他还没离职的话。这就是传统“黑盒”式威胁检测的典型困境。我们大量使用着商业EDR、开源IDS或是SIEM平台自带的规则集却对其内在逻辑一知半解。规则成了“魔法”我们成了“魔法”的被动使用者。而Sigma的出现正是为了打破这种局面。它不是一个具体的检测工具而是一种开源的、标准化的威胁检测规则语法。你可以把它理解为威胁检测领域的“通用语言”或“中间件”。它的核心价值在于将检测逻辑Whatto detect与执行引擎Whereto run解耦。简单来说用Sigma语言写好一条检测规则后你可以通过社区维护的转换工具称为Sigmac将其“编译”成适用于不同后端的格式比如Splunk的SPL、Elasticsearch的KQL、微软Sentinel的KQL甚至是一些EDR产品的原生查询语言。这意味着你的检测逻辑从此具备了可移植性不再被某个特定的厂商或平台锁死。更重要的是Sigma规则本身是纯文本的YAML文件人类可读性极强。阅读一条Sigma规则你就能清晰地理解检测者意图寻找的威胁指标IOC或攻击行为TTP这极大地促进了安全团队内部以及社区之间的知识共享与协作。所以这个项目不仅仅是学习一种语法更是掌握一种构建透明、可控、可移植的威胁检测体系的核心能力。无论你是安全分析师、威胁猎人还是SOC工程师理解并能够编写Sigma规则都意味着你能将你的威胁洞察快速、准确地转化为覆盖整个企业IT环境的自动化检测能力从被动的告警响应者转变为主动的检测策略设计者。2. Sigma规则核心架构与设计哲学拆解要编写自己的规则必须先吃透它的设计哲学和文件结构。Sigma规则不是随意的脚本它有一套严谨的、面向日志数据的模型。2.1 规则文件解剖一个YAML文档的构成一条完整的Sigma规则就是一个YAML文件通常以.yml或.yaml为后缀。其结构可以分解为以下几个核心部分1. 元数据部分这部分描述了规则“是谁”、“关于什么”以及“有多重要”。它对于规则管理和分类至关重要。title: Suspicious Execution of Certutil for File Download id: 9a8b7c6d-1234-5678-90ef-abcdef123456 # 全局唯一UUID status: test # 状态stable, test, experimental, deprecated description: Detects the use of certutil.exe to download files from remote sources, a common LOLBin abuse technique. author: Your Name / Your Company date: 2023-10-27 modified: 2024-01-15 tags: - attack.t1105 # MITRE ATTCK 技术ID - attack.defense_evasion - attack.execution - car.2013-05-009 # Cyber Analytics Repository 映射 - tool.certutil - technique.download logsource: category: process_creation product: windowstitledescription: 清晰、准确地概括规则目的。好的描述应包含攻击手法如LOLBin滥用和威胁场景。id: 必须使用UUID v4确保全球唯一。可以使用在线生成器但团队内部最好有固定前缀。status: 标记规则成熟度。test状态规则不应直接投入生产告警可用于狩猎或低优先级监控。tags: 这是Sigma规则的灵魂之一。强烈建议关联MITRE ATTCK框架。这不仅有助于分类还能在ATTCK Navigator等工具中进行可视化整体评估检测覆盖范围。logsource: 指定规则适用的日志来源。这是实现跨平台可移植性的关键。category如process_creation,dns_query,file_event和product如windows,linux,aws的组合告诉转换器应该针对哪种类型的日志进行查询构建。2. 检测逻辑部分这是规则的核心定义了“查什么”。detection: selection: Image|endswith: \certutil.exe CommandLine|contains|all: - -urlcache - -split - -f filter: CommandLine|contains: ? condition: selection and not filterselection: 定义需要匹配的“可疑”条件集合。这里可以包含一个或多个字段的匹配条件。filter: 定义需要排除的“误报”条件。将已知的良性活动如管理员的标准管理命令放在这里是减少噪音的关键。condition: 布尔逻辑表达式将selection和filter组合起来定义最终的触发条件。支持and,or,not,1 of selection*等复杂逻辑。3. 上下文与响应部分这部分告诉分析师“如果触发了该怎么办”以及“这个规则有多可靠”。level: high falsepositives: - Legitimate administrative use of certutil for certificate management (though unlikely with -urlcache -split -f combination) - Some software deployment tools might use similar patterns (verify with environment) references: - https://lolbas-project.github.io/lolbas/Binaries/Certutil/ - https://attack.mitre.org/techniques/T1105/level: 告警级别critical,high,medium,low,informational。这应与潜在影响和置信度挂钩。高误报可能性的规则应适当降低级别。falsepositives:极其重要。诚实地列出已知或潜在的误报来源。这能极大节省后续事件调查Triage的时间也是规则作者专业性的体现。references: 提供背景知识的链接如LOLBAS项目、MITRE ATTCK页面、相关威胁报告等。注意一个常见的误区是将所有条件都堆在selection里然后用复杂的condition去连接。更好的实践是selection聚焦于“攻击指标”filter聚焦于“误报排除”condition保持简洁如selection and not filter。这使规则逻辑更清晰便于后续维护和调优。2.2 Sigma的设计哲学可移植性与抽象层Sigma的核心魅力在于其“一次编写多处运行”的能力。这得益于它在检测逻辑和查询实现之间引入了一个抽象层。传统模式为Splunk写一个SPL查询为Elastic再写一个DSL查询为Sentinel再写一个KQL查询。同一条检测逻辑需要维护多份代码且难以保证一致性。Sigma模式编写一份Sigma规则YAML。当需要在Splunk中部署时使用Sigmac转换器配合Splunk后端配置生成SPL当数据迁移到Elastic时使用同样的规则和Elastic后端配置生成KQL。这个抽象层的关键在于logsource和字段映射。Sigma规则中使用的是通用字段名如Image,CommandLine,ParentImage。不同的日志源如Windows 4688事件、Sysmon事件、EDR日志中对应这些语义的字段名可能完全不同例如进程路径在4688事件中叫NewProcessName在Sysmon Event 1中叫Image。Sigma转换器内部维护了这些映射关系。当你指定logsource: product: windows, category: process_creation并选择splunk-windows后端时转换器会自动将Image映射到 Splunk 中 Windows 4688事件对应的正确字段名。这种设计带来的直接好处是降低技术债检测逻辑集中管理平台变更时只需重新生成查询无需重写逻辑。促进知识共享社区规则如Sigma HQ官方仓库可以被任何人使用无论其底层技术栈是什么。提升审计效率安全审计人员可以直接阅读YAML规则来理解检测控制措施而无需去理解各种不同的查询语言。3. 从零开始编写你的第一条Sigma规则实战演练理论讲得再多不如动手写一条。我们以检测一个经典的攻击手法为例攻击者使用wmic进程调用cmd.exe来执行命令这是一种常见的父进程-子进程关系滥用用于绕过一些基于静态进程树的检测。3.1 第一步明确检测目标与数据源检测目标识别出由wmic.exe创建的cmd.exe进程并且该cmd.exe执行了可疑命令例如执行whoami来探测当前权限。数据源我们需要进程创建日志。在Windows环境下最理想的数据源是SysmonEvent ID 1因为它能提供最丰富、最一致的进程信息包括完整的命令行、父子进程关系、哈希等。如果只有Windows安全日志4688事件也可以但字段名和信息的完整性会稍差。我们在规则中通过logsource来声明。3.2 第二步构建检测逻辑我们先在纸上或脑子里梳理逻辑选择条件Selection我们关心的是cmd.exe被创建的事件。父进程条件这个cmd.exe的父进程是wmic.exe。命令行指示器这个cmd.exe执行了whoami命令。过滤条件Filter可选需要考虑是否有合法的管理脚本或系统任务会使用wmic调用cmd可能很少但为了严谨我们可以先留空或在后续根据误报情况添加。现在将其转化为Sigma的YAML结构。我们从最基础的骨架开始title: WMIC Process Calling CMD with Whoami Execution id: 123e4567-e89b-12d3-a456-426614174000 # 请务必替换为你生成的UUID status: test description: Detects potential discovery activity where WMIC spawns CMD to execute whoami, often used for privilege enumeration. author: [Your Name] date: 2024-05-17 tags: - attack.t1059.003 # MITRE: Command and Scripting Interpreter: Windows Command Shell - attack.t1082 # MITRE: System Information Discovery - attack.execution logsource: category: process_creation product: windows detection: selection: Image|endswith: \cmd.exe ParentImage|endswith: \wmic.exe CommandLine|contains: whoami condition: selection level: medium falsepositives: - Legitimate system administration scripts (rare) references: - https://attack.mitre.org/techniques/T1059/003/3.3 第三步优化与增强规则上面的规则是有效的但可以更健壮。攻击者可能会对命令进行简单的混淆。whoami可能被写成whoami.exe。可能带有参数如whoami /all。可能大小写混用如WhoAmI。Sigma提供了强大的转换器Transformations和修饰符Modifiers来处理这些问题。使用修饰符优化detection: selection: Image|endswith: \cmd.exe ParentImage|endswith: \wmic.exe CommandLine|contains|all: - whoami condition: selection这里我们只用了contains。我们可以使用re正则表达式修饰符来匹配更灵活的模式detection: selection: Image|endswith: \cmd.exe ParentImage|endswith: \wmic.exe CommandLine|re: (?i)whoami(\.exe)?(\s|$) condition: selection(?i)表示忽略大小写。(\.exe)?匹配可选的.exe扩展名。(\s|$)确保匹配的是独立的命令而不是像notwhoami这样的字符串的一部分。它要求whoami后面跟着空白字符或直接是行尾。增加健壮性——考虑更多可疑命令 攻击者可能不仅运行whoami还可能运行systeminfo,ipconfig,net user等发现命令。我们可以使用1 of selection*语法来构建一个“选择器列表”。detection: selection_cmd: Image|endswith: \cmd.exe ParentImage|endswith: \wmic.exe selection_commands: CommandLine|re: (?i)whoami(\.exe)?(\s|$) CommandLine|contains|all: - net - user CommandLine|contains: systeminfo CommandLine|contains: ipconfig condition: selection_cmd and 1 of selection_commands*在这个逻辑中selection_cmd定义了可疑的进程关系。selection_commands是一个列表定义了多个可疑的命令行模式。condition: selection_cmd and 1 of selection_commands*表示当满足可疑进程关系并且命令行满足selection_commands列表中的任意一个条件时规则触发。这比写多个独立的and条件更清晰、更易扩展。3.4 第四步测试与转换你的规则规则写好了但它还只是一个YAML文件。我们需要将其转换为实际日志平台能执行的查询语言。1. 安装Sigma命令行工具Sigmac 最方便的方式是通过Python的pip安装。pip install sigmatools2. 转换规则 假设你的规则文件名为wmic_cmd_whoami.yml。转换为Splunk SPLsigmac -t splunk -c config/splunk-windows.yml wmic_cmd_whoami.yml-t指定目标后端splunk,es-qs,ql,sentinel等。-c指定字段映射配置文件。Sigma工具包通常自带常用配置位于tools/config/目录下。转换为Elasticsearch KQLsigmac -t es-qs -c config/ecs-windows.yml wmic_cmd_whoami.yml3. 手动验证生成的查询永远不要直接将转换后的查询投入生产务必先在一个测试环境或时间范围较广的开发面板中运行一下检查语法是否正确。查询是否过于宽泛可能产生海量结果。查询是否过于严格可能漏掉真正的事件。字段名是否与你的实际日志映射匹配。config文件是通用模板你可能需要根据自己环境的日志采集方式比如用的是Winlogbeat还是直接Agent转发Sysmon的解析方式进行微调。4. 编写高质量Sigma规则的进阶技巧与避坑指南掌握了基础语法后要写出真正高效、低噪的规则还需要一些“内功心法”。4.1 字段选择与通配符的智慧优先使用确定性的字段Image进程路径和CommandLine是黄金组合但也要善用其他字段。OriginalFileName进程的原始文件名不受重命名影响。恶意软件经常将自身命名为svchost.exe但OriginalFileName可能暴露其真身。HashesMD5, SHA1, SHA256, IMPHASH用于匹配已知恶意样本的哈希值确定性极高但只适用于已知威胁。ParentCommandLine父进程的命令行。有时攻击链的关键信息藏在父进程里。例如一个由powershell.exe -enc ...创建的rundll32.exe比一个由explorer.exe创建的rundll32.exe可疑得多。谨慎使用通配符*和?很强大但滥用会导致性能灾难和误报。避免开头通配符CommandLine|contains: *http://evil.com*是低效的。如果可能尽量使用endswith或re进行更精确的匹配如CommandLine|re: https?://[^/]*evil\.com。明确路径分隔符匹配路径时使用endswith: \system32\whoami.exe比contains: whoami.exe好得多可以避免匹配到用户目录下的合法文件。4.2 条件逻辑的构建艺术condition字段是规则的“大脑”。复杂的逻辑可以通过将选择器分组来实现使规则结构清晰。场景检测可能的内存转储工具如procdump被非常规进程调用。detection: selection_tool: Image|endswith|all: - \procdump.exe - \procdump64.exe - \sqldumper.exe # 另一个合法的转储工具但可能被滥用 selection_suspicious_parent: ParentImage|endswith|all: - \word.exe - \excel.exe - \outlook.exe - \chrome.exe - \firefox.exe selection_common_parent: ParentImage|endswith|all: - \taskmgr.exe # 任务管理器调用是常见的 - \mmc.exe # 管理控制台调用可能是合法的 - \services.exe # 服务崩溃转储 condition: selection_tool and selection_suspicious_parent and not selection_common_parent这条规则的意思是检测由Office套件或浏览器等非系统管理进程创建的转储工具执行但同时排除了由任务管理器、MMC或服务控制器创建的常见合法场景。这种“包含排除”的结构逻辑非常清晰。4.3 性能优化让你的规则跑得更快在大型日志环境中一条编写不当的规则可能会拖垮整个查询系统。将最严格、最不可能匹配的条件放在前面大多数查询引擎如ES、Splunk会按顺序评估条件。如果第一个条件就能过滤掉99%的事件后续条件的计算压力就小多了。例如先匹配特定的Image再匹配CommandLine中的字符串。避免在condition中使用过多的or1 of selection*在Sigma层面很清晰但转换后可能变成一个很长的OR列表。如果可能尝试合并条件或寻找更通用的模式。利用时间窗口Sigma规则本身不包含时间范围但在部署时应将其与合理的调度时间窗口结合。对于高频事件如网络连接查询最近1小时的数据对于低频事件如账户创建可以查询24小时。定期评审和归档对于长期没有触发、或误报率极高的规则应考虑将其状态改为test或deprecated并从生产调度中移除避免不必要的计算开销。4.4 版本控制与团队协作Sigma规则是代码应该用对待代码的方式管理它。使用Git将规则仓库置于Git版本控制之下。每次修改都有记录便于回滚和审计。建立代码审查流程新的或修改的规则在合并到主分支生产规则集前应由另一位安全同事进行审查。审查重点逻辑是否正确、误报是否考虑周全、标签是否准确、性能影响如何。目录结构可以按MITRE ATTCK战术Tactic组织规则目录如rules/credential_access/也可以按数据源分类如rules/windows/process_creation/。选择一种适合团队习惯的方式。集成CI/CD管道可以设置自动化流程当规则被推送到仓库时自动用Sigmac转换并测试语法甚至自动部署到测试环境的SIEM中。5. 从规则到检测工程构建可持续的威胁检测体系编写单条规则是技能而管理成百上千条规则使其持续、有效、低噪地运行则是一门工程。5.1 规则的测试与验证框架单元测试针对单条规则模拟攻击测试在隔离的测试环境中实际执行规则所要检测的攻击行为如运行那条WMIC命令确保规则能够触发。误报测试收集或模拟一批正常的业务活动日志运行规则查询确保不会或极少产生误报。可以将这些正常活动模式逐步添加到规则的filter部分。转换测试确保规则能正确转换为所有你正在使用的后端查询语言Splunk, Elastic, Sentinel等。集成测试针对规则集回归测试集维护一个包含历史攻击样本和正常活动样本的日志数据集。每当规则集更新时对整个数据集运行所有规则检查1) 已知攻击是否仍能被检测到避免回归2) 已知的正常活动是否不会触发新告警控制误报。性能基准测试在模拟生产数据量的环境中运行关键规则监控查询执行时间和资源消耗。5.2 规则的生命周期管理一条规则不是写成就一劳永逸的。它有自己的生命周期提案与设计基于威胁情报、内部事件或攻击模拟发现的需求设计规则逻辑。开发与测试编写Sigma YAML进行单元测试和误报评估。评审与部署通过团队评审后转换并部署到生产SIEM的测试或低优先级阶段。调优与运营监控规则的触发频率、误报率、检出率True Positive Rate。根据运营反馈持续调优selection和filter。退役与归档当攻击手法过时、日志源变更、或规则被更优的规则替代时将规则状态改为deprecated并从生产调度中移除但代码仍需归档保存。建立一个简单的看板或表格来跟踪每条规则的状态experimental,test,stable,deprecated、负责人、最后调优日期、近期误报次数等对于管理大型规则集至关重要。5.3 与威胁情报的融合Sigma规则可以成为威胁情报TI的“可执行”载体。许多威胁情报平台TIP或开源威胁情报源如OTX Pulse开始提供Sigma格式的检测规则。消费外部TI将社区如Sigma HQ, SOC Prime Threat Detection Marketplace发布的、与自身环境相关的规则经过评估和适配后纳入自己的规则库。这是一个快速提升检测覆盖度的好方法。生产内部TI当内部调查发现一种新的攻击手法时立即将其模式固化为Sigma规则。这条规则本身就是一份宝贵的内部威胁情报资产可以用于全网狩猎和未来检测。5.4 度量与改进你的检测有效吗“我们部署了500条检测规则”这本身没有意义。更重要的是检出率规则真正发现了多少已验证的安全事件误报率规则触发的告警中有多少是误报一个每天触发上百次、99%都是误报的规则其运营成本可能超过其安全价值。平均响应时间从规则触发到分析师开始调查平均需要多久过于嘈杂的规则会导致告警疲劳延长响应时间。ATTCK覆盖度使用ATTCK Navigator可视化你的Sigma规则集看看在ATTCK矩阵的哪些战术和技术上你有检测覆盖哪些还是盲区。这能指导你未来规则开发的重点方向。编写Sigma规则起点是掌握YAML语法和转换工具但终点是构建一个透明、可度量、可持续演进的主动防御能力。它迫使安全团队更深入地思考攻击的本质、数据的形态以及检测的精确性。当你能够熟练地将一个威胁想法转化为一条精准、高效的Sigma规则时你就不再仅仅是安全工具的操作用户而是成为了企业安全态势的真正塑造者。