1. 项目概述从威胁检测规则到可执行查询在安全运营中心SOC或者任何负责日志分析、威胁狩猎的团队里我们常常面临一个核心矛盾如何将业界广泛认可、描述清晰的威胁检测逻辑快速、准确地应用到我们自己的日志分析平台中Sigma 规则的出现为解决这个矛盾提供了一个优雅的答案。它就像一份用通用语言写成的“威胁检测食谱”详细描述了要寻找什么攻击特征但具体用什么“锅灶”查询引擎和“食材”日志字段来烹饪则需要本地化适配。我最近处理的一个典型场景就是将数百条来自开源社区如 SigmaHQ的 Sigma 规则批量转换并集成到我们基于 Elastic StackElasticsearch Kibana的日志分析环境中。这个过程的核心工具就是sigma-cli。简单来说这个项目就是利用sigma-cli这把“瑞士军刀”将 Sigma 规则.yml 文件批量转换成 Elasticsearch Query DSL领域特定语言并最终在 Kibana 的 Discover、Dashboard 或 SIEM 应用中落地形成可监控、可告警的检测能力。这不仅仅是简单的格式转换。它涉及到规则库的管理、字段映射的适配、查询性能的优化以及如何在 Kibana 中高效地管理和使用这些生成的查询。对于任何一个希望提升威胁检测覆盖率和响应速度的团队来说掌握这套流程都是极具价值的。无论你是刚开始接触 Sigma 的安全分析师还是负责搭建检测平台的工程师理解从 Sigma 到 Elastic Query 的完整链路都能让你事半功倍。2. 核心工具链与工作流设计在开始动手之前我们需要理清整个工作流和所需的工具。这不仅仅是运行一条转换命令那么简单一个健壮的流程能避免后续大量的手动修正和混乱。2.1 Sigma 规则与 sigma-cli 解析Sigma 规则的核心是一个 YAML 文件它定义了检测逻辑。一个典型的规则包含title标题、description描述、logsource日志源如 Windows 安全日志、Sysmon、detection检测条件等部分。detection部分是灵魂它使用一种声明式的语法来描述匹配模式例如寻找特定的命令行参数、进程名或注册表键。sigma-cli是 Sigma 项目的官方命令行工具用 Python 编写。它的核心功能是充当一个“翻译器”。它内置了针对不同后端Backend的转换器比如elasticsearch、splunk、qradar等。当指定-t elasticsearch时它会调用相应的转换模块将 Sigma 规则中的抽象逻辑翻译成具体的 Elasticsearch Query DSL。这里有一个关键概念管道Pipelines。Sigma-cli 支持在转换过程中应用一系列处理器Processor这构成了管道。例如一个典型的转换管道可能是sigma convert -t elasticsearch --pipeline es-qs。这个es-qs管道是专门为生成 Elasticsearch Query String Query 而优化的它会进行一些默认的字段名映射和语法调整。理解并选择合适的管道是保证生成查询可用性的第一步。2.2 从规则到 Kibana 的完整链路一个完整的集成链路通常包含以下几个环节规则获取与整理从 SigmaHQ 官方仓库或其他可信来源克隆或下载 Sigma 规则集。建议建立本地的规则仓库并做好版本管理如使用 Git。环境准备与字段映射分析这是最容易被忽视也最关键的一步。你需要清楚你的 Elasticsearch 索引中日志字段的命名是什么。Sigma 规则使用的是通用字段名如CommandLine、Image而你的日志里对应的字段可能是process.command_line和process.executable。sigma-cli通过一个叫fieldmapping的配置文件来处理这个映射。你需要根据自己环境的日志模式如 ECS - Elastic Common Schema创建或调整这个映射文件。批量转换执行使用sigma-cli对规则目录进行批量转换输出为包含 Elasticsearch Query 的文件通常是.json或.txt。查询验证与优化将生成的 Query 在 Kibana Dev Tools 控制台或直接通过 API 在少量数据上测试确保语法正确且能返回预期结果或无结果。根据测试结果可能需要对规则本身或字段映射进行微调。Kibana 集成将验证通过的查询应用到 Kibana 的不同场景Discover / Logs手动搜索用于即席威胁狩猎。Dashboard创建可视化图表用于态势监控。SIEM / Security应用创建检测规则Detection Rule实现自动化告警。这个链路的顺畅程度直接决定了检测能力部署的效率。接下来我们就深入到每个环节的实操细节中。3. 实战sigma-cli 批量转换全流程理论说得再多不如动手做一遍。我们假设你已经有一个本地的 Sigma 规则目录例如./sigma-rules/并且你的 Elasticsearch 集群基本遵循 ECS 规范。3.1 环境搭建与 sigma-cli 安装首先确保你的系统有 Python 3.7 环境。安装sigma-cli最推荐的方式是通过 pip 从 PyPI 安装pip install sigma-cli安装完成后验证安装和查看帮助sigma --version sigma convert --help注意在实际生产环境中建议使用虚拟环境如venv或pipenv来安装避免污染系统 Python 环境也便于管理依赖。如果遇到pyyaml或ruamel.yaml等依赖问题通常升级 pip 或指定版本安装即可解决。3.2 关键配置定制化字段映射默认的es-qs管道使用内置的字段映射但很可能不匹配你的实际环境。因此创建自定义映射文件是必须的。找到映射文件模板sigma-cli安装后其字段映射配置通常位于 Python 包的sigma/pipelines/elasticsearch/目录下或者你可以在 Sigma 项目 GitHub 仓库中找到示例。更简单的方法是运行一次转换观察其使用的默认映射逻辑。创建自定义映射文件新建一个 YAML 文件例如custom-fieldmap.yml。其结构如下# custom-fieldmap.yml fieldmappings: # 通用进程字段映射 ProcessName: process.name Image: process.executable CommandLine: process.command_line ParentImage: process.parent.executable # 通用网络字段映射 DestinationIp: destination.ip DestinationPort: destination.port SourceIp: source.ip SourcePort: source.port # Windows 特定事件字段映射 TargetObject: winlog.event_data.TargetObject EventID: winlog.event_id # 如果某个Sigma字段在你的日志中不存在可以注释掉或留空转换时会忽略或报错取决于配置如何确定映射关系这需要你对自己的数据非常了解。最有效的方法是在 Kibana Discover 中查看一条典型日志比如一条 Sysmon 进程创建事件。对照 Sigma 规则中常用的字段列表如来自sigma/sigma-specification文档找出你日志中对应的 ECS 字段路径。对于非标准或自定义字段你需要建立自己的映射字典。这个过程可能需要迭代多次。3.3 执行批量转换命令有了映射文件就可以进行转换了。基本命令格式如下sigma convert -t elasticsearch --pipeline es-qs -c ./path/to/custom-fieldmap.yml -o ./output/queries.json ./sigma-rules/windows/process_creation/-t elasticsearch: 指定目标后端为 Elasticsearch。--pipeline es-qs: 使用 Elasticsearch Query String 管道。这是最常用的一种生成的是query_string查询。你也可以尝试es-dsl管道生成更复杂的 Bool Query。-c ...: 指定自定义的字段映射配置文件。-o ...: 指定输出文件。如果输入是一个目录所有转换后的查询会汇总到一个 JSON 数组中输出到这个文件。如果输入是单个文件则输出该文件对应的查询。最后是 Sigma 规则目录或文件的路径。批量处理技巧你可以写一个简单的 Shell 脚本或 Python 脚本遍历整个sigma-rules目录按子目录如windows/,network/分别转换和输出便于后续分类管理。使用--output-fields参数可以控制输出内容。例如--output-fields rule,query可以只输出规则标题和查询本身使得输出文件更简洁。转换成功后打开queries.json你会看到一个 JSON 数组每个元素包含规则 ID、标题、描述和生成的 Elasticsearch Query。3.4 转换输出解析与初步验证转换输出的查询通常长这样{ id: 4878b6c4-6c2d-4e7a-8b93-7a5a5b5e5c5a, title: Suspicious Execution via Windows Script Host, description: Detects suspicious execution of scripts via wscript or cscript, query: process.name: (\wscript.exe\ OR \cscript.exe\) AND process.command_line: (*.jse OR *.vbe OR *.vbs) }这里的query字段值就是一个 Elasticsearch Query String。你可以直接将其复制到 Kibana Dev Tools 中进行测试GET your-index-pattern-*/_search { query: { query_string: { query: process.name: (\wscript.exe\ OR \cscript.exe\) AND process.command_line: (*.jse OR *.vbe OR *.vbs) } } }验证要点语法检查运行后没有语法错误。字段存在性检查确认process.name和process.command_line字段在你的索引中确实存在且被正确索引非keyword类型字段可能需要通配符查询text类型字段则需注意分词。数据匹配检查如果可能构造一条测试数据写入 ES看查询是否能正确命中。这是验证字段映射是否正确的终极方法。实操心得不是所有 Sigma 规则都能完美转换。有些规则使用了复杂的逻辑组合、正则表达式或尚未被 sigma-cli 完全支持的 Sigma 语法。在批量转换后建议对输出结果进行一次快速扫描重点关注那些转换失败输出中 query 字段可能为 null 或包含错误信息的规则需要手动处理。4. Kibana 集成让查询发挥价值生成查询只是第一步让它在 Kibana 中“活”起来成为日常运营的一部分才是最终目标。集成方式主要有三种适用于不同场景。4.1 方式一Discover 与 Logs 应用中的即席狩猎对于安全分析师来说最直接的用法就是将转换好的 Query String 直接粘贴到 Kibana Discover 页面的搜索栏中。Kibana 的 KQLKibana Query Language和 Lucene Query String 语法大部分兼容。操作步骤打开 Kibana Discover选择正确的索引模式。将查询字符串例如process.name: (\wscript.exe\ OR \cscript.exe\)粘贴到搜索框。点击查询。你可以保存这个搜索命名为对应的规则标题方便下次快速调用。优势灵活、快速适合在事件调查或威胁狩猎时临时验证某个假设或搜索特定攻击痕迹。局限需要手动操作无法实现自动化监控。4.2 方式二构建监控仪表盘Dashboard对于需要持续关注的高风险或关键检测项可以将其可视化在 Dashboard 上。操作步骤在 Discover 中用好一个查询并保存这个搜索Save。进入 Dashboard创建新的可视化Visualization。选择“Lens”或“TSVB”等可视化类型数据源选择你刚才保存的搜索。配置可视化例如创建一个“计数”指标显示匹配该规则的日志事件数量随时间的变化趋势图。将多个相关规则的可视化组件排列在一个 Dashboard 上形成一个威胁检测全景视图。优势直观、实时便于团队在安全运维大屏上全局感知威胁态势。局限仍然是“被动观察”需要人工发现图表异常。4.3 方式三创建 SIEM 检测规则Detection Rule—— 自动化告警这是最强大的集成方式能将 Sigma 规则转化为真正的自动化检测引擎。这主要在 Kibana 的Security Detections功能中实现需要 Elastic Security 功能许可。操作步骤进入 Security 应用下的 “Detections” 标签页。点击 “Create new rule”。选择 “Custom query” 作为规则类型。在 “Custom query” 输入框中粘贴你从 sigma-cli 转换得到的 Elasticsearch Query DSL。注意这里通常需要完整的 Bool Query 格式而不仅仅是 Query String。你可以使用sigma convert -t elasticsearch --pipeline es-dsl来生成更适配的 DSL。配置规则元数据填入从 Sigma 规则中提取的标题、描述、严重等级Severity、MITRE ATTCK 战术与技术 ID 等。配置规则运行计划索引模式、运行间隔如每5分钟、历史数据回溯范围。配置告警动作当规则匹配时可以发送邮件、Slack 消息或创建 Jira 工单等。一个完整的 Detection Rule 查询部分可能如下{ query: { bool: { must: [ { query_string: { query: process.name: (\wscript.exe\ OR \cscript.exe\), analyze_wildcard: true } }, { wildcard: { process.command_line: { value: *.vbs } } } ], filter: [ { range: { timestamp: { gte: now-5m } } } ] } } }优势实现了真正的自动化、可告警的威胁检测是构建主动防御能力的关键。局限需要 Elastic Security 许可规则调优避免误报需要持续投入。重要提示在将任何 Sigma 规则大规模投入生产告警前必须在预发布环境或通过历史数据回溯进行充分的误报测试。许多开源 Sigma 规则是基于特定环境撰写的直接使用可能产生大量噪音。5. 高级调优与性能考量当规则数量成百上千时性能和效率就成为必须考虑的问题。粗暴的转换和部署可能会拖慢 Elasticsearch 集群。5.1 查询性能优化策略避免过度使用通配符Sigma 规则中常见的*通配符在query_string中性能开销很大尤其是在字段开头使用如*password*。尽可能将其转化为更具体的词项查询或短语查询。如果无法避免考虑使用wildcard查询并对该字段设置合适的映射如keyword类型。利用索引映射与分词确保查询中使用的字段被正确映射。对于需要全文搜索的字段如命令行参数使用text类型并配置合适的分词器对于需要精确匹配或聚合的字段如进程哈希值使用keyword类型。不恰当的映射会导致查询无法命中或性能低下。拆分复杂规则一些 Sigma 规则非常复杂包含大量OR和AND条件。可以评估是否将其拆分为多个更简单、更具体的规则。这样不仅易于管理也便于单独禁用问题规则同时 ES 执行多个简单查询有时比一个巨大复杂查询更高效。使用时间范围过滤在 Detection Rule 中务必通过range过滤器严格限制timestamp的范围只查询最近的数据。绝对不要进行无时间限制的全历史扫描。5.2 规则库的持续管理与更新安全威胁日新月异Sigma 规则库也在不断更新。你需要建立一套流程来管理本地规则库的更新、转换、测试和部署。版本控制使用 Git 管理你的sigma-rules目录和自定义的fieldmap.yml文件。这样可以清晰追踪规则变更方便回滚。自动化流水线可以搭建一个简单的 CI/CD 流水线如使用 Jenkins、GitLab CI。当规则库 Git 仓库有更新时自动触发sigma-cli转换任务生成新的查询文件并自动运行一系列基础测试如语法验证。分级部署不要一次性将所有新规则投入生产告警。建议设立“监控-告警”两级。新规则先以“监控”模式仅在 Dashboard 显示或低严重度告警运行一段时间收集误报数据并调优稳定后再提升为“高严重度告警”规则。定期复审与下线定期检查现有规则的触发情况。对于长期如数月未触发、或误报率极高的规则进行审查、优化或下线。保持规则集的精简和有效。5.3 处理转换失败与特殊语法在批量转换中你肯定会遇到一些规则转换失败或转换结果不理想的情况。常见原因和应对策略如下问题现象可能原因排查与解决思路转换后query字段为null或空1. 规则语法不被当前sigma-cli版本支持。2. 使用了未实现的 Sigma 功能如某些聚合条件。3. 规则文件本身格式错误。1. 升级sigma-cli到最新版。2. 查看转换时的错误信息sigma-cli通常会有警告或报错输出。3. 手动检查该 Sigma 规则的 YAML 语法。可能需要手动重写该规则的检测逻辑。查询语法错误在 ES 中执行报错1. 字段映射错误导致生成了不存在的字段名。2. 生成的 Query String 中包含特殊字符未转义。3. 管道选择不当生成了不兼容的 DSL。1. 核对字段映射文件确保关键字段正确。2. 在 Kibana Dev Tools 中简化查询逐步定位出错子句。对于特殊字符尝试用反斜杠转义或使用keyword字段的term查询替代。3. 尝试换用es-dsl管道生成 Bool Query通常容错性更好。查询能执行但结果为空怀疑未命中1. 字段映射不匹配查询条件对应不上实际数据。2. 日志源不匹配规则针对的是 Sysmon但你的数据是 WinEventLog。3. 查询条件过于严格或数据本身不存在。1. 这是最常见的问题。取一条你认为应该被命中的样本日志逐一对比规则中的条件和你日志中的字段值。2. 检查 Sigma 规则的logsource部分确认与你的数据源一致。3. 放宽查询条件测试例如先只保留一个最核心的条件看是否能命中数据。面对无法自动转换的复杂规则最终的解决方案往往是手动重写。基于你对规则意图的理解和你自身日志模式的知识直接在 Kibana Detection Rule 中编写 Elasticsearch DSL。这虽然增加了工作量但往往能产生最精准、最高效的检测逻辑。6. 踩坑实录与经验总结回顾整个从 Sigma 规则到 Kibana 集成的过程我踩过不少坑也积累了一些让流程更顺畅的经验。第一大坑字段映射的“最后一公里”。理论上如果大家都严格遵循 ECS映射会很简单。但现实是很多日志代理、解析管道会对字段名进行修改或添加前缀。我的经验是不要假设一定要验证。建立一个“映射验证表”针对常用的 Sigma 规则类别进程创建、网络连接、文件事件等各找几条典型规则用转换后的查询去扫描最近几天的真实数据。如果扫不出任何结果而你又确信环境中存在相关行为那几乎肯定是字段映射出了问题。第二大坑查询性能的“温水煮青蛙”。初期规则少查询慢点感觉不到。当规则数量超过 100 条并且以分钟级频率执行时对 ES 集群的压力就显现出来了。我的建议是从一开始就养成好习惯1) 在 Dev Tools 中执行查询时关注返回结果下方的took耗时字段2) 对于扫描大量数据的查询务必加上合理的时间范围过滤3) 定期使用 Kibana 的 Stack Monitoring 或 Elasticsearch 的 Profile API 来分析慢查询。一个实用的技巧建立规则知识库。不要只把转换后的 JSON 文件扔在那里。我习惯用一个 Markdown 文件或一个小型数据库来记录每条规则的信息原始 Sigma ID、转换后的查询、部署状态测试/监控/告警、最近触发时间、常见误报来源、调优记录等。这在你需要排查告警、优化规则或者向团队新人介绍检测能力时是无价之宝。关于网络热词“Kibana 登录 certificate has expired”这虽然与 Sigma 转换无直接关系但却是运维 Elastic Stack 的常见问题。这通常意味着 Kibana 用于连接 Elasticsearch 的客户端证书已过期。解决它需要更新 Elasticsearch 集群的证书并重新配置 Kibana 的kibana.yml中的elasticsearch.ssl.certificateAuthorities路径。这提醒我们在构建这套自动化检测流程时底层平台的稳定性是基础需要规范的证书管理和运维流程。最后我想说sigma-cli批量转换与 Kibana 集成不是一个一劳永逸的“魔法”。它是一个强大的效率倍增器将你从手动编写成千上万条查询语句的苦役中解放出来让你能更专注于更高价值的工作分析威胁情报、调优检测逻辑、以及响应真实的安全事件。这个过程始于工具但成于你对自身数据和安全需求的理解。