Security-Eng-Muhammad-Ali/eol-risk-detection-soar

# EOL 风险检测与自动化响应流水线 这是一个基于威胁情报驱动的检测工程项目，构建于 **Wazuh SIEM** 之上并部署在 **AWS EC2** 上。该项目能够识别环境中的生命周期结束 (EOL) 软件，利用实时的 **CVE** 和 **CISA KEV (已知被利用漏洞)** 数据丰富扫描结果，并为关键发现自动触发 **SOAR 工作流**。 这个项目超越了简单的 EOL 检测（“该软件已过时”），实现了**基于风险的优先级排序**（“该软件已过时，且正在野外被积极利用”）——这与 CISA 的 SSVC 和 EPSS 等行业框架背后的理念相同。 ## 问题描述 大多数 EOL/漏洞扫描器会将所有问题都标记为同等紧急，从而导致告警疲劳。安全团队最终会面对数百个“严重”级别的发现，却无法确定实际应优先修复哪些内容。该项目通过基于**现实世界中的可利用性**对 EOL 发现进行评分来解决此问题，而不仅仅依据软件的过时程度。 ## 架构 ``` ┌─────────────────────┐ │ Wazuh Agents │ (Linux + Windows, AWS EC2) │ Syscollector module │ → collects OS/software inventory └──────────┬───────────┘ │ ┌──────────▼───────────┐ │ eol_detector.py │ → pulls inventory via Wazuh API │ │ → checks OS versions against │ │ endoflife.date API └──────────┬───────────┘ │ eol.json ┌──────────▼───────────┐ │ risk_scorer.py │ → cross-references findings with: │ │ • NVD API (CVE + CVSS data) │ │ • CISA KEV feed (actively │ │ exploited CVEs) │ │ → calculates tiered risk score └──────────┬───────────┘ │ eol_risk.json ┌──────────▼───────────┐ │ Wazuh Manager │ │ Custom decoder + rules│ → generates severity-based alerts │ │ (Low / Medium / High / Critical) └──────────┬───────────┘ │ Critical alerts only ┌──────────▼───────────┐ │ Wazuh Integration │ → custom webhook script │ (custom-eol-webhook) │ └──────────┬───────────┘ │ HTTPS POST ┌──────────▼───────────┐ │ n8n (SOAR) │ → receives alert payload │ Webhook → Google │ │ Sheets workflow │ └──────────┬───────────┘ │ ┌──────────▼───────────┐ │ Google Sheets │ → auto-logged findings for │ (auto-logged ticket) │ tracking and reporting └───────────────────────┘ ``` ## 核心功能 - **自动化 EOL 检测** — 使用 Wazuh Syscollector 清单数据 + [endoflife.date](https://endoflife.date) API 来标记运行不受支持 OS 版本的 agent。 - **CVE 富化** — 通过 [NVD API](https://nvd.nist.gov) 查询与每个 EOL 发现相关的已知漏洞，包括 CVSS 严重性。 - **感知漏洞利用的风险评分** — 将 CVE 与 [CISA 已知被利用漏洞 (KEV)](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) 目录进行交叉比对，以识别在野外被积极利用的漏洞，而不仅仅是理论上有风险的漏洞。 - **分层严重性模型** — 根据加权公式（EOL 状态 + 是否有 CVE + CVSS 严重性 + 是否被积极利用 + 暴露程度）将发现评为低 / 中 / 高 / 严重，从而减少告警疲劳。 - **原生 Wazuh 集成** — 自定义解码器和规则将丰富后的发现直接接入 Wazuh dashboard，并带有相应的严重性级别（规则 ID 100420–100423）。 - **SOAR 自动化** — 严重级别的发现会通过 Wazuh 的原生集成框架自动触发 n8n 工作流，将结构化的事件数据实时记录到 Google Sheets 中——无需人工分类。 ## 技术栈 | 组件 | 工具 | |---|---| | SIEM | Wazuh 4.14.5 (一体化，自托管) | | 云基础设施 | AWS EC2 (Wazuh 服务器 + Linux 和 Windows agent) | | 检测脚本 | Python 3 (`requests`) | | 威胁情报来源 | NVD API, CISA KEV Feed, endoflife.date API | | SOAR / 自动化 | n8n (云端) | | 告警接收端 | Google Sheets | ## 风险评分逻辑 | 因素 | 评分权重 | |---|---| | 基础分 (软件处于 EOL) | +1 | | 该版本存在已知 CVE | +3 | | 最高 CVSS 分数 ≥ 7 (高/严重) | +3 | | CVE 被列入 CISA KEV (被积极利用) | +5 | | 资产面向互联网 | +3 | | 总分 | 风险等级 | |---|---| | 0–3 | 低 | | 4–5 | 中 | | 6–8 | 高 | | 9+ | 严重 | 这确保了**并非所有 EOL 软件都被视为同等紧急**——只有具备真实世界利用证据的发现才会被升级为“严重”，这符合企业漏洞管理实际确定补救优先级的方式。 ## 示例：端到端检测 **发现：** 在某 agent 上检测到了 Windows Server 2012 (自 2023-10-10 起处于 EOL)。 **富化结果：** - 通过 NVD 找到了 10 个相关 CVE - 最高 CVSS 分数：10.0 - 在 CISA KEV 目录中匹配到 2 个 CVE (`CVE-2012-0767`, `CVE-2012-1535`) - **风险评分：12 → 严重** **生成的 Wazuh 告警 (规则 100423，级别 14)：** **自动化响应：** 告警触发 Wazuh 的集成模块，向 n8n 发送 webhook，进而在 Google Sheet 中追加一行结构化数据——在无需分析师干预的情况下创建了可审计的实时记录。 ## 截图 **Wazuh Dashboard — 严重 EOL 风险告警** 针对在 CISA KEV 目录中匹配到 2 个 CVE 的 EOL Windows Server 2012 资产，触发了自定义规则 (100423，级别 14)。  **Google Sheets — 通过 SOAR 工作流自动记录的发现** 通过 Wazuh → n8n webhook 集成，实时将严重级别的发现自动追加到 Google Sheet 中，包含 CVE 数量和匹配的 KEV ID——无需人工干预。  ## 仓库结构 ``` eol-detector/ ├── eol_detector.py # Pulls agent OS inventory, checks against endoflife.date ├── risk_scorer.py # Enriches EOL findings with CVE + KEV data, calculates risk score ├── asset_tags.json # Manual exposure/criticality tagging per agent └── wazuh_config/ ├── local_decoder.xml # Custom JSON decoder reference ├── local_rules.xml # Custom rules (100420–100423) for tiered alerting └── integrations/ ├── custom-eol-webhook # Wazuh integration wrapper script └── custom-eol-webhook.py # Sends enriched alert data to n8n webhook ``` ## MITRE ATT&CK 映射 EOL 和未打补丁的软件是以下行为的常见促成因素： - **T1190 – Exploitation of Public-Facing Application** (Initial Access) - **T1210 – Exploitation of Remote Services** (Lateral Movement) 标记具有活跃利用证据的 EOL 资产，直接支持了对这些技术的主动防御。 ## 经验总结 / 故障排除笔记 该项目涉及的实际调试过程反映了生产环境的检测工程工作： - 诊断出 **decoder 不匹配**问题，即 Wazuh 中的 `log_format: json` 会静默覆盖自定义 decoder 并转而使用内置的 JSON decoder —— 规则必须引用 `json` 而不是自定义 decoder 名称。 - 发现 **Wazuh 集成脚本在文件权限不正确时会静默失败**（`wpopenv()` 会拒绝组可写的集成脚本）—— 通过将权限设为 `550` 而非 `750` 解决了该问题。 - 发现了 **n8n 中草稿与发布状态之间的差异**，即已编辑的节点配置（Append 与 Append-or-Update 操作）在显式发布之前不会反映在实时的 webhook 中——这提醒了我们，在工作流自动化工具中，“已保存”和“线上生效”并不总是一回事。 ## 未来增强计划 - [ ] 将检测范围从 OS 级别的 EOL 扩展到单个软件包（例如 web 服务器、数据库） - [ ] 通过真实的 CMDB 添加资产关键性/面向互联网的标记，而不是手动编写 JSON - [ ] 通过 cron 定期调度 `eol_detector.py` 和 `risk_scorer.py` 以实现持续监控 - [ ] 针对有意保留的遗留系统添加例外/风险接受处理机制 - [ ] 扩展 SOAR 工作流，增加自动创建工单 (Jira) 以及针对严重级别发现的 Slack/Teams 通知功能 ## 作者 **Muhammad Ali** 初级 SOC 工程师 | 检测工程与 AI 辅助 SOC 爱好者

标签：GPT, PB级数据处理, SOAR, Wazuh, 威胁情报, 安全运维, 实时处理, 开发者工具, 无线安全, 漏洞管理, 逆向工具