企业官网建设流程全解析

1. 项目概述：从威胁检测规则到可执行查询

在安全运营中心（SOC）或者任何负责日志分析、威胁狩猎的团队里，我们常常面临一个核心矛盾：如何将业界广泛认可、描述清晰的威胁检测逻辑，快速、准确地应用到我们自己的日志分析平台中？Sigma 规则的出现，为解决这个矛盾提供了一个优雅的答案。它就像一份用通用语言写成的“威胁检测食谱”，详细描述了要寻找什么（攻击特征），但具体用什么“锅灶”（查询引擎）和“食材”（日志字段）来烹饪，则需要本地化适配。

我最近处理的一个典型场景，就是将数百条来自开源社区（如 SigmaHQ）的 Sigma 规则，批量转换并集成到我们基于 Elastic Stack（Elasticsearch + 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 的完整链路

一个完整的集成链路通常包含以下几个环节：

1. 规则获取与整理：从 SigmaHQ 官方仓库或其他可信来源克隆或下载 Sigma 规则集。建议建立本地的规则仓库，并做好版本管理（如使用 Git）。
2. 环境准备与字段映射分析：这是最容易被忽视也最关键的一步。你需要清楚你的 Elasticsearch 索引中，日志字段的命名是什么。Sigma 规则使用的是通用字段名（如CommandLine、Image），而你的日志里对应的字段可能是process.command_line和process.executable。sigma-cli通过一个叫fieldmapping的配置文件来处理这个映射。你需要根据自己环境的日志模式（如 ECS - Elastic Common Schema），创建或调整这个映射文件。
3. 批量转换执行：使用sigma-cli对规则目录进行批量转换，输出为包含 Elasticsearch Query 的文件（通常是.json或.txt）。
4. 查询验证与优化：将生成的 Query 在 Kibana Dev Tools 控制台或直接通过 API 在少量数据上测试，确保语法正确且能返回预期结果（或无结果）。根据测试结果，可能需要对规则本身或字段映射进行微调。
5. 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管道使用内置的字段映射，但很可能不匹配你的实际环境。因此，创建自定义映射文件是必须的。

1. 找到映射文件模板：sigma-cli安装后，其字段映射配置通常位于 Python 包的sigma/pipelines/elasticsearch/目录下，或者你可以在 Sigma 项目 GitHub 仓库中找到示例。更简单的方法是，运行一次转换，观察其使用的默认映射逻辑。
2. 创建自定义映射文件：新建一个 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字段在你的日志中不存在，可以注释掉或留空，转换时会忽略或报错（取决于配置）

3. 如何确定映射关系？这需要你对自己的数据非常了解。最有效的方法是：
   • 在 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)" } } }

验证要点：

1. 语法检查：运行后没有语法错误。
2. 字段存在性检查：确认process.name和process.command_line字段在你的索引中确实存在且被正确索引（非keyword类型字段可能需要通配符查询，text类型字段则需注意分词）。
3. 数据匹配检查：如果可能，构造一条测试数据写入 ES，看查询是否能正确命中。这是验证字段映射是否正确的终极方法。

实操心得：不是所有 Sigma 规则都能完美转换。有些规则使用了复杂的逻辑组合、正则表达式或尚未被 sigma-cli 完全支持的 Sigma 语法。在批量转换后，建议对输出结果进行一次快速扫描，重点关注那些转换失败（输出中 query 字段可能为 null 或包含错误信息）的规则，需要手动处理。

4. Kibana 集成：让查询发挥价值

生成查询只是第一步，让它在 Kibana 中“活”起来，成为日常运营的一部分，才是最终目标。集成方式主要有三种，适用于不同场景。

4.1 方式一：Discover 与 Logs 应用中的即席狩猎

对于安全分析师来说，最直接的用法就是将转换好的 Query String 直接粘贴到 Kibana Discover 页面的搜索栏中。Kibana 的 KQL（Kibana Query Language）和 Lucene Query String 语法大部分兼容。

操作步骤：

1. 打开 Kibana Discover，选择正确的索引模式。
2. 将查询字符串（例如process.name: (\"wscript.exe\" OR \"cscript.exe\")）粘贴到搜索框。
3. 点击查询。你可以保存这个搜索，命名为对应的规则标题，方便下次快速调用。

优势：灵活、快速，适合在事件调查或威胁狩猎时，临时验证某个假设或搜索特定攻击痕迹。

局限：需要手动操作，无法实现自动化监控。

4.2 方式二：构建监控仪表盘（Dashboard）

对于需要持续关注的高风险或关键检测项，可以将其可视化在 Dashboard 上。

操作步骤：

1. 在 Discover 中用好一个查询，并保存这个搜索（Save）。
2. 进入 Dashboard，创建新的可视化（Visualization）。
3. 选择“Lens”或“TSVB”等可视化类型，数据源选择你刚才保存的搜索。
4. 配置可视化，例如创建一个“计数”指标，显示匹配该规则的日志事件数量随时间的变化趋势图。
5. 将多个相关规则的可视化组件排列在一个 Dashboard 上，形成一个威胁检测全景视图。

优势：直观、实时，便于团队在安全运维大屏上全局感知威胁态势。

局限：仍然是“被动观察”，需要人工发现图表异常。

4.3 方式三：创建 SIEM 检测规则（Detection Rule）—— 自动化告警

这是最强大的集成方式，能将 Sigma 规则转化为真正的自动化检测引擎。这主要在 Kibana 的Security > Detections功能中实现（需要 Elastic Security 功能许可）。

操作步骤：

1. 进入 Security 应用下的 “Detections” 标签页。
2. 点击 “Create new rule”。
3. 选择 “Custom query” 作为规则类型。
4. 在 “Custom query” 输入框中，粘贴你从 sigma-cli 转换得到的 Elasticsearch Query DSL。注意，这里通常需要完整的 Bool Query 格式，而不仅仅是 Query String。你可以使用sigma convert -t elasticsearch --pipeline es-dsl来生成更适配的 DSL。
5. 配置规则元数据：填入从 Sigma 规则中提取的标题、描述、严重等级（Severity）、MITRE ATT&CK 战术与技术 ID 等。
6. 配置规则运行计划：索引模式、运行间隔（如每5分钟）、历史数据回溯范围。
7. 配置告警动作：当规则匹配时，可以发送邮件、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 查询性能优化策略

1. 避免过度使用通配符：Sigma 规则中常见的*通配符在query_string中性能开销很大，尤其是在字段开头使用（如*password*）。尽可能将其转化为更具体的词项查询或短语查询。如果无法避免，考虑使用wildcard查询，并对该字段设置合适的映射（如keyword类型）。
2. 利用索引映射与分词：确保查询中使用的字段被正确映射。对于需要全文搜索的字段（如命令行参数），使用text类型并配置合适的分词器；对于需要精确匹配或聚合的字段（如进程哈希值），使用keyword类型。不恰当的映射会导致查询无法命中或性能低下。
3. 拆分复杂规则：一些 Sigma 规则非常复杂，包含大量OR和AND条件。可以评估是否将其拆分为多个更简单、更具体的规则。这样不仅易于管理，也便于单独禁用问题规则，同时 ES 执行多个简单查询有时比一个巨大复杂查询更高效。
4. 使用时间范围过滤：在 Detection Rule 中，务必通过range过滤器严格限制@timestamp的范围，只查询最近的数据。绝对不要进行无时间限制的全历史扫描。

5.2 规则库的持续管理与更新

安全威胁日新月异，Sigma 规则库也在不断更新。你需要建立一套流程来管理本地规则库的更新、转换、测试和部署。

1. 版本控制：使用 Git 管理你的sigma-rules目录和自定义的fieldmap.yml文件。这样可以清晰追踪规则变更，方便回滚。
2. 自动化流水线：可以搭建一个简单的 CI/CD 流水线（如使用 Jenkins、GitLab CI）。当规则库 Git 仓库有更新时，自动触发sigma-cli转换任务，生成新的查询文件，并自动运行一系列基础测试（如语法验证）。
3. 分级部署：不要一次性将所有新规则投入生产告警。建议设立“监控-告警”两级。新规则先以“监控”模式（仅在 Dashboard 显示或低严重度告警）运行一段时间，收集误报数据并调优，稳定后再提升为“高严重度告警”规则。
4. 定期复审与下线：定期检查现有规则的触发情况。对于长期（如数月）未触发、或误报率极高的规则，进行审查、优化或下线。保持规则集的精简和有效。

5.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 集成，不是一个一劳永逸的“魔法”。它是一个强大的效率倍增器，将你从手动编写成千上万条查询语句的苦役中解放出来，让你能更专注于更高价值的工作：分析威胁情报、调优检测逻辑、以及响应真实的安全事件。这个过程始于工具，但成于你对自身数据和安全需求的理解。