josh-talley/sigma-studio-elk

# Sigma Studio v2.0 + Enterprise ELK SIEM **发现 • 转换 • 部署 • 调优 • 循环** 基于生产环境 ELK SIEM 构建的企业级检测工程平台。Sigma Studio 将供应商无关的 Sigma 规则转换为原生 SIEM 查询，通过 API 在 Elastic 和 Splunk 间进行部署，并通过单个 Python CLI 管理完整的检测生命周期。  *检测规则在 Elastic 和 Splunk 的生产环境中触发：SSH 暴力破解、持久化机制、撞库、可疑进程执行等。完全通过命令行进行部署和管理。* **案例研究：[`date_trunc` 如何破坏 ESQL 关联规则](correlation-case-study/)** — pySigma Elasticsearch 后端中的一个假阴性缺口，导致关联规则静默漏过跨越固定时间边界的攻击。已通过受控 A/B 测试进行验证。 ## 目录 - [方法论](#the-approach) - [基础设施](#infrastructure) - [后端组合](#portfolio-backends) - [规则分类](#rule-classification) - [发现 (Discover)](#discover) - [转换 (Convert)](#convert) - [部署 (Deploy)](#deploy) - [调优 (Tune)](#tune) - [检测规则组合](#detection-rule-portfolio) - [安全运营](#security-operations) - [工程挑战](#engineering-challenges) - [ELK 健康检查](#elk-health-check) - [主要成果](#key-achievements) - [项目展示](#what-this-demonstrates) - [技术栈](#tech-stack) - [联系方式](#contact) ## 方法论 当前就业市场的技巧之一是证明你在机构层面解决问题的能力。我将自己置身于一家拥有托管 SIEM 客户的 MDR 服务提供商的角度，并采用“Client 1”模型设计了 Sigma Studio。 LightworksDevCo 是第一个客户：拥有多种 SIEM 后端配置（ELK + Docker 化 Splunk）、多个索引以及特定于客户端的规则调优。该系统旨在适应额外的客户、后端和配置。只要有 pySigma 后端和流水线，系统就是可扩展的。 ## 基础设施 - **ASUS NUC Pro 12:** 运行 ELK 8.x（Filebeat, Elasticsearch, Kibana, Auditbeat）的常开 Kali Linux 服务器。 - **Azure VM:** 将 Windows 事件日志发送到 ELK，用于跨平台规则测试。 - **Docker 化 Splunk Enterprise:** NUC 上的测试环境，用于多 SIEM 部署验证。 - **DuckDB:** 通过查询作为 git submodule 安装的 SigmaHQ 3000 多条社区规则，为 Discover 功能提供支持。 - **PostgreSQL:** 管理覆盖层配置、客户端设置和部署跟踪。 - **Tailscale VPN:** 通过网络访问控制连接所有设备。 - **Python CLI + Bash 封装:** Sigma Studio 的主要接口。 ## 后端组合 | 后端 | 状态 | 备注 | |---------|--------|-------| | **Elastic** (Lucene, ES\|QL, EQL) | 生产环境 | 已针对我的实时流水线进行测试。我有规则部署在所有三种查询语言中。 | | **Splunk** (SPL) | 测试环境 | nuc-k 上的 Docker 容器，用于 API 驱动的告警创建和验证。 | | **Chronicle** (YARA-L) | 转换 | 用于多平台转换和测试的 pySigma 后端。 | | **Sentinel** (KQL) | 转换 | 用于多平台转换和测试的 pySigma 后端。 | | **LogScale** (LogScale QL) | 转换 | 用于多平台转换和测试的 pySigma 后端。 | Sigma 后端和流水线处理比较棘手。有些平台仅支持 Windows，Elastic 拥有包含独立后端类的多种查询语言，而且在撰写本文时，只有 Splunk 和 Elastic 支持链式关联规则。系统适应了这些不对称性。当额外后端支持关联功能时，您只需更新 DB 配置并重新部署。 ## 规则分类 每条规则的部署类在运行时动态确定，而非在 YAML 中声明。规则保持可移植性；系统负责其余工作。 | 类别 | 含义 | 应用场景 | |-------|---------------|--------------| | **pySigma** | 通过带有字段映射流水线（例如 Elastic 的 ECS，Splunk 的 CIM）的 pySigma 进行干净转换。没有覆盖层修改输出。 | 每条规则的长期目标状态 | | **pySigma+** | pySigma 转换 *加上* DB 覆盖层调优：阈值、自定义调度、索引覆盖、排除过滤器、告警抑制 | 调优和客户端配置 | | **pySigma*** | *不带* 字段映射流水线的 pySigma 转换。查询在语法上有效，但字段名可能与目标 schema 不匹配。 | 跨平台流水线缺口的警告层级 | | **Correlation** | 解析为后端原生语法（ES\|QL 或 SPL）并链接基础规则的多事件聚合 | 带有关联键的规则 | | **Correlation+** | 关联 *加上* DB 覆盖层调优：调度覆盖、索引覆盖、标签 | 已调优的关联部署 | | **Override** | 完全绕过 pySigma。手写查询按原样部署。用于 pySigma 无法生成的模式，例如 EQL 时间序列。 | 当 Sigma 无法配合意图时的完全自定义处理 | ## 发现 (Discover) 我需要一种方法来搜索 SigmaHQ 社区仓库中的 3000 多条规则。Discover 提取 pandas DataFrame 并使用 DuckDB 查询它，可按 MITRE 技术、战术、平台、严重性、服务、关键字和规则 UUID 进行过滤。结果支持分页，您可以直接将规则暂存到 drafts 文件夹以供采用前审查。  *完整的搜索界面，支持 MITRE 技术、战术、平台、类别、服务、严重性、状态和关键字过滤。*  *在 SigmaHQ 中搜索 Windows 权限提升规则。结果显示标题、严重性、MITRE 标签、平台、目录路径和文件位置。*  *将搜索结果中的规则直接暂存到 drafts 文件夹以供审查。在提示符下输入规则编号，它们将被复制到您的工作目录。* ## 转换 (Convert) convert 命令将 Sigma YAML 同时转换为所有后端组合的原生查询语言。`--file` 标志显示带有规范字段映射的纯 pySigma 转换。`--client` 标志叠加客户端的后端配置文件和覆盖层配置，跳过不在客户端范围内的后端。任何活动的覆盖层（阈值、覆盖、调度）都显示在转换网格下方。  *单条 Windows 规则（通过 Certutil.EXE 可疑下载）转换为所有 5 个后端。注意 `pySigma*` 层级：某些平台不存在字段映射流水线，因此输出使用源字段名。星号是您验证字段兼容性的信号。*  *针对 Windows 计划任务规则的客户端特定转换。顶部网格显示每个后端的转换。下方是活动的 pySigma+ 和 Override 部署详情：查询语言、调度、索引模式和部署原因。*  *一条 Linux 社区规则（掩盖系统电源设置），在 Elastic 和 Splunk 上都有活动的 Override 部署。覆盖原因解释了为何绕过 pySigma：规范的 Sigma 字段映射无法清晰地映射到 Auditbeat 事件的 ECS `process.executable`/`process.args`。每个后端获得其独立调优的手写查询。* ## 部署 (Deploy) 当触发部署时，系统不仅仅是推送规则。它通过一系列门控确定哪些规则符合条件：针对现有部署的去重、关联基础规则的构建块抑制、后端兼容性检查和特定于平台的过滤。Linux syslog 规则不会尝试部署到专为 Windows 配置的后端。每个后端获得其自己的转换、健康检查和覆盖层解析。 同一条规则可以在单次调用中以 Lucene 部署到 Elastic，以 SPL 部署到 Splunk，各自拥有独立的调优。 ### 之前：空白状态   *Elastic Security 和 Splunk Enterprise 上的空白检测规则页面。未部署自定义规则。* ### `deploy --client LightworksDevCo --all-rules --all-backends`  *规则跨两个后端部署。每条规则在运行时分类，转换为目标查询语言，并通过 API 推送。关联基础规则（构建块）被自动保留。*  *关联规则与其链接的基础规则一起部署。系统解析关联链，转换为后端原生聚合（Elastic 为 ES|QL，Splunk 为 SPL），并部署完整的检测逻辑。* ### 之后：规则上线  *Kibana 检测规则中填充了跨 Lucene、ES|QL 和 EQL 查询类型的自定义规则，均通过 API 部署。*  *Splunk Enterprise 告警中填充了相同的检测组合，已转换为 SPL。* ### 生命周期管理 全生命周期支持：通过单个命令进行部署、更新和删除。  *`delete --all-rules --all-backends` 移除跨两个平台的规则，并进行完全对账。每条规则都被跟踪，每次部署都被记录。* ## 调优 (Tune) 调优通过覆盖层进行：即修改规则部署方式而不触及可移植 Sigma YAML 的数据库存储配置。覆盖层可以调整阈值、覆盖调度、交换索引模式或用手写的后端原生逻辑替换整个查询。规则文件保持可移植。调优保留在数据库中，作用于特定客户端和后端。 本演示使用 SSH 暴力破解成功（时间）关联规则。pySigma 自动为 ES|QL 和 SPL 生成有效的关联语法，但检测模式受益于特定于平台的查询语言。Elastic 上的 EQL 时间序列和 SPL 中基于统计的关联比通用聚合产生更紧密的检测逻辑。 ### 之前：原始转换  *关联规则通过 `convert --file` 跨所有 5 个后端转换。无客户端上下文，无覆盖层。pySigma 从可移植 YAML 生成关联语法。*  *使用 `convert --client` 进行客户端特定转换。平台严格性跳过非 Linux 配置的后端（Chronicle, LogScale, Sentinel）。Elastic 和 Splunk 仍在范围内，但尚未激活覆盖层。* ### 应用覆盖层  *为 Elastic 设置 EQL 时间序列覆盖。这将自动生成的 ES|QL 关联替换为 EQL 序列查询，匹配来自同一源 IP 的 SSH 身份验证失败和随后的成功登录。规则从 Correlation 重新分类为 Override。*  *为 Splunk 设置基于 SPL 统计的覆盖。相同的检测意图，不同的查询语言。每个后端通过其自己的覆盖层独立调优。* ### 部署与验证   *两个后端都通过 `deploy --all-backends` 接收调优后的规则。每个都作为 Override 类部署，带有手写查询、自定义调度和从覆盖层解析的特定于后端的索引模式。*  *触发检测：三次失败的 SSH 密码尝试，随后是来自同一源的成功基于密钥的登录。这匹配了覆盖层旨在捕获的时间模式。*  *SSH 暴力破解成功（时间）告警在 Kibana 检测告警中触发。*  *显示关联事件字段的告警详情。时间序列匹配：来自源 IP 的身份验证失败，然后在配置的窗口内成功登录。* ### 覆盖层生命周期 覆盖层独立于规则部署支持完整的 CRUD 操作。可以在不重新部署的情况下列出、检查、修改和移除它们。  *` --purge` 移除已部署的规则及其覆盖层配置，使规则恢复到空白状态以进行重新部署或重新分类。* ## 检测规则组合 这里的规则数量反映的是家庭实验室，而不是生产 SOC。重要的是规则类型的多样性、多 SIEM 部署以及管理它们的架构。同样的系统可以处理这个组合或十倍大小的组合。 ### Linux 检测：自定义规则 **网络与认证 (Filebeat)** | 检测规则 | 类型 | 逻辑 | MITRE ATT&CK | |---|---|---|---| | SSH 暴力破解 | Threshold | 2 分钟内同源 IP 5 次以上失败 | T1110.001, T1110.003 | | 端口扫描 | Cardinality | 15 分钟内同源 IP 10 个以上唯一端口 | T1046 | | 撞库 | Cardinality | 5 分钟内同源 IP 5 个以上唯一用户名 | T1110.004 | | 高危端口访问 | Threshold | 10 分钟内 5 次以上对敏感端口的 blocked 连接 | T1021, T1133 | | Sudo 认证失败 | Threshold | 5 分钟内 3 次以上提权失败 | T1548.003 | **主机活动 (Auditbeat)** | 检测规则 | 类型 | 逻辑 | MITRE ATT&CK | |---|---|---|---| | 敏感文件访问 | Query | 非系统进程访问 /etc/passwd, /etc/shadow | T1003.008 | | SSH 密钥修改 | Query | 对 authorized_keys 文件的更改 | T1098.004 | | 日志篡改尝试 | Query | 删除/截断 audit logs, syslog, auth logs | T1070 | | 可疑进程执行 | Query | 从 /tmp, /var/tmp, /dev/shm 执行的二进制文件 | T1036 | | 反向 Shell 检测 | Query | Shell 进程到外部 IP 的出站连接 | T1059 | ### 关联规则 | 检测规则 | 类型 | 逻辑 | MITRE ATT&CK | |---|---|---|---| | SSH 暴力破解（时间） | Correlation | 2 分钟内同源 IP 5 次以上 SSH 失败后成功 | T1110 | | Cron 任务持久化 | Correlation | 2 分钟内同用户/主机 2 次以上 cron 修改 | T1053.003 | *关联规则仅部署到支持原生聚合的后端（Elastic ES|QL, Splunk SPL）。构建块基础规则在多规则部署中自动抑制，以防止告警噪音。* ### SigmaHQ 社区规则（精选） | 检测规则 | 类别 | 平台 | MITRE ATT&CK | |---|---|---|---| | 网络嗅探 (tcpdump/tshark) | Override | Linux / Auditbeat | T1040 | | 通过 Systemctl 掩盖电源设置 | Override | Linux / Auditbeat | T1564 | | 通过 Auditctl 删除 Audit 规则 | Override | Linux / Auditbeat | T1562.001 | | ld.so.preload 修改 | Override | Linux / Auditbeat + Splunk | T1574.006 | *这些社区规则需要 Override 分类。规范的 Sigma 字段映射无法清晰地转换为 Auditbeat 内核事件的 ECS 字段。每个覆盖层都包含绕过的文档化原因。* ### Windows 规则（跨平台测试） | 检测规则 | 类别 | 平台 | MITRE ATT&CK | |---|---|---|---| | 通过 Certutil.EXE 可疑下载 | pySigma | Windows / Sysmon | T1105 | | 通过 Net.EXE 创建新用户 | pySigma | Windows / Sysmon | T1136.001 | | 可疑计划任务创建 | pySigma | Windows / Sysmon | T1053.005 | | 可疑编码 PowerShell 命令行 | pySigma | Windows / Sysmon | T1059.001 | | 通过 Whoami.EXE 枚举安全权限 | pySigma | Windows / Sysmon | T1033 | *Windows 规则来源于 SigmaHQ 并部署到我的 Azure VM 日志流水线。到目前为止，实验室一直以 Linux 为中心。这些规则证明了跨平台能力，并验证了跨后端的 Windows Sysmon 日志转换。* ### MITRE ATT&CK 覆盖范围 覆盖 9 个战术的 18 项技术：初始访问、执行、持久化、权限提升、防御规避、凭证访问、发现、横向移动和命令与控制。 ## 安全运营 ### 总体概览  *跨所有日志层级的顶层可见性。跨 auditbeat、security、system、infrastructure 和 application 流的约 8M 事件。来自生产环境的真实数据。* ### 安全监控  *SSH 认证模式、攻击来源分析、防火墙拦截趋势以及检测规则告警的实时订阅源。这是调查开始的地方。* ### 检测规则性能  *规则执行指标：跟踪了 20,000 多次执行，包含成功率、执行持续时间和调度延迟监控。3 个警告是预期中的阈值规则，在安静期间结果集为空。* ### 应用监控  *跟踪服务活动、会话计数和 schema 验证的自定义 NDJSON 应用日志。写入此层的每条日志都遵循我为项目维护的 ECS 8.0 集中式日志风格指南。* ## 工程挑战 构建 SIEM 并非即插即用。我沿途解决了几个问题： **数据质量。** 初始部署积累了 44M 文档，远超预期容量。调查追踪到源头是 Intel Meteor Lake 硬件生成了过量的遥测数据，掩盖了合法的安全事件。系统诊断、过滤器实施和完整的重新索引将语料库清理为约 8M 条可操作事件，且流水线零故障。 **IPv6 防火墙解析。** 28% 的防火墙事件解析失败。Elasticsearch ingest pipeline 预期的是 IPv4 特定的标头。构建了支持两种协议的灵活 grok 模式。修复以来解析成功率 100%。 **ECS 合规性。** 自定义应用日志使用了违反 ECS 8.0 的平面点分键。重构了日志库以生成适当的嵌套 JSON。所有日志源完全符合 ECS 8.0 字段要求。 **Auditbeat 集成。** Filebeat 的 auditd 模块丢弃 SYSCALL、EXECVE 和 PATH 事件，仅保留 USER_*/CRED_*/LOGIN 记录。部署了带有直接内核 netlink socket 的独立 Auditbeat 以实现完整的审计覆盖，外加用于 tier/logtype 元数据的自定义 ES enrichment pipeline。这就是基于主机的检测规则工作的原因。 **静默 SSH 事件丢失。** 一条将 SSH 暴力破解与成功登录关联的时间检测规则，尽管逻辑验证无误却从未触发。调查追踪到两层静默数据丢失。首先，OpenSSH 9.8+ 将 sshd 二进制文件拆分为独立的预认证和后认证进程，具有不同的 syslog 标识符；Filebeat 的输入过滤器仅匹配其中一个，静默丢弃了所有认证事件。其次，修复过滤器后，一个 dissect 模式将 SSH 端口和密钥指纹捕获为单个字符串，导致 Elasticsearch 整数类型检查失败并静默拒绝文档。这两项修复都是通过多阶段流水线追踪发现的单行更改。 **跨后端查询损坏。** 多 SIEM 转换从所有五个后端生成了相同的 Chronicle UDM 查询，而不是原生的 Lucene、SPL 和 KQL 输出。根本原因：pySigma 流水线在字段转换期间改变 SigmaRule 对象。当同一对象按顺序通过后端时，第一次转换的变形破坏了所有后续结果。通过在每次后端转换前从 YAML 重新解析修复，确保每次转换都从干净的对象开始。这是一个组合阻塞级 bug，因为跨平台查询生成是项目核心声明之一。 ## ELK 健康检查 自定义健康检查脚本提供单命令可见性以查看完整堆栈：服务状态、认证、集群健康、数据流和索引大小。  *Robert Diggs 是 RZA 的真名。Clifford Smith 是 Method Man。这些主机名是向 Wu-Tang Clan 致敬。* ## 主要成果 | 指标 | 结果 | |--------|--------| | **安全事件** | 处理了约 8M，流水线零故障 | | **检测规则** | 2 个 SIEM 平台上的 25 条规则，5 种规则类型，6 种规则类别 | | **MITRE 覆盖范围** | 9 个战术的 18 项技术 | | **后端** | 5 个目标（2 个已部署，3 个用于转换） | | **查询语言** | Lucene, ES\|QL, EQL, SPL, KQL, YARA-L, LogScale QL | | **ECS 合规性** | 所有日志源 100% | | **仪表板** | 5 个生产仪表板，24+ 个可视化 | ## 项目展示 - **检测工程** 覆盖完整的 Sigma 生命周期：发现、转换、部署和调优 - **多 SIEM 架构** 从单个可移植规则集定位 5 个后端平台 - **Python 工具** 包含 API 集成 - **运维思维** 包括去重、构建块抑制、漂移检测、客户端隔离、覆盖层调优 - **数据工程** 包含 ECS 兼容字段映射、ingest pipeline 设计、日志质量管理、4 层数据流架构 - **问题解决** 上述记录的每个工程挑战都是在没有外部帮助的情况下诊断和解决的 这是一个生产安全监控环境，而非教程部署。它处理真实流量，捕获实际威胁，并需要持续调优。每个仪表板、检测规则和工程决策的存在都是因为它解决了真实的监控需求。 ## 技术栈 **语言** - Python（CLI 应用程序，pySigma 集成，API 客户端） - SQL（PostgreSQL, DuckDB） - Bash（运维脚本，封装接口） **SIEM 平台** - Elastic Security 8.x（Elasticsearch, Kibana, Filebeat, Auditbeat） - Splunk Enterprise（Docker 化测试环境） **检测** - Sigma / pySigma（规则编写，字段映射流水线，后端转换） - SigmaHQ 社区规则集（通过 git submodule 获取 3,000+ 规则） - MITRE ATT&CK 框架映射 **数据与存储** - PostgreSQL（覆盖层配置，客户端设置，部署跟踪） - DuckDB（SigmaHQ 规则搜索和过滤） - pandas（用于 Discover 的 DataFrame 处理） **API** - Kibana Detection Engine API（规则 CRUD，激活，批量操作） - Splunk REST API（保存搜索管理，告警创建） **基础设施** - Kali Linux（ASUS NUC Pro 12，常开服务器） - Azure VM（Windows 事件日志发送） - Docker（Splunk 容器化） - Tailscale VPN（带 ACL 的 mesh 网络） **查询语言** - Lucene, ES\|QL, EQL (Elastic) - SPL (Splunk) - KQL (Sentinel) - YARA-L (Chronicle) - LogScale QL (Falcon LogScale) ## 联系方式 **Joshua Talley** - Email: josh@joshtalley.com - LinkedIn: [linkedin.com/in/josh-talley](https://linkedin.com/in/josh-talley) - CompTIA Security+ 认证 - Python Institute PCEP 认证 *版本 2.0 | 2026 年 2 月*

标签：AMSI绕过, DevSecOps, EDR, Elasticsearch, ELK 技术栈, ESQL, FTP漏洞扫描, Python CLI, SecOps, Sigma 规则, 上游代理, 云安全架构, 域名分析, 威胁检测, 安全编排, 安全运营, 应用安全, 异常检测, 扫描框架, 测试用例, 网络安全, 脆弱性评估, 规则转换, 请求拦截, 越狱测试, 逆向工具, 隐私保护