awoooi/docs/security/SOC-SIEM-KALI-WAZUH-INTEGRATION-CONTROL.md

# IwoooS SOC / SIEM / Kali 112 / Wazuh 整合控制矩陣

| 項目 | 內容 |
|------|------|
| 日期 | 2026-06-25 |
| 狀態 | `soc_siem_kali_wazuh_integration_control_ready_no_runtime_action` |
| 工具 | `scripts/security/soc-siem-kali-wazuh-integration-control.py` |
| Snapshot | `docs/security/soc-siem-kali-wazuh-integration-control.snapshot.json` |
| 主流 AISOC 路線圖 | `docs/security/MAINSTREAM-AISOC-SECURITY-CONTROL-ROADMAP.md` |
| runtime gate | `0` |

## 1. 目的

此矩陣把「整體資安監控、告警、Kali 112 與業界主流機制」整合成 IwoooS 可驗收的 SOC 控制面。它不是再多一張靜態規劃表，而是把 Wazuh、Kali 112、Prometheus / Alertmanager、SigNoz、Sentry、Nginx / gateway、host forensic、Docker / systemd、K8s / ArgoCD、Gitea / runner、Harbor / SBOM、backup / DR 都拉進同一條事件鏈。

本階段仍是 repo / snapshot / guard / 前台可視化控制，不是 runtime 授權。它不呼叫 Wazuh API、不呼叫 Kali、不 SSH、不讀 live log、不送 Telegram、不 reload Prometheus / Alertmanager、不建立 SOAR case、不啟用 Wazuh active response、不跑 active scan、不改 firewall / Nginx / K8s / workflow / secret。

## 2. 導入的主流框架

| 框架 | 導入方式 |
|------|----------|
| NIST CSF 2.0 | 以 Govern、Identify、Protect、Detect、Respond、Recover 當 IwoooS SOC 主流程骨架 |
| NIST SP 800-61 Rev. 3 | 將 incident response 建議轉成 case gate、postcheck 與 lesson learned 回寫 |
| CIS Controls v8.1 | 導入資產盤點、漏洞管理、稽核日誌、惡意程式防護、復原與權限審查 |
| CISA Zero Trust Maturity Model | 補 identity、device、network、application、data、visibility 與 automation 成熟度 |
| CISA KEV | 已知遭利用漏洞作為套件 / image / public service 修補優先序 |
| MITRE ATT&CK / D3FEND | 用攻擊技術、資料源、防禦 countermeasure 與 coverage gap 校準偵測工程 |
| OWASP ASVS / SAMM | 前後台、API、auth、access-control、secure SDLC 與 logging 驗證，不落 secret |
| Wazuh XDR / SIEM | endpoint、FIM、rule、decoder、alert 與 active response dry-run 邊界 |
| Wazuh Active Response | 只採能力模型與 dry-run / rollback gate；目前不啟用 response |
| Prometheus Alertmanager | 導入 grouping、dedup、routing、silence、inhibit 與 receipt 驗收 |
| OpenTelemetry | 以 traces、metrics、logs、resource 與 semantic conventions 關聯 incident evidence |
| SLSA / Sigstore / SBOM | 將 provenance、artifact signing、SBOM 與驗章納入供應鏈 lane |
| Suricata / Zeek NDR | 先預留被動網路偵測 lane，IPS / inline blocking 需獨立批准 |
| Kali tooling | Kali 112 作為只讀健康、工具版本、scope 與 finding normalization 節點 |

## 3. 控制域

| 控制域 | 第一階段要求 |
|--------|--------------|
| 資產與 owner | 所有 host、service、repo、domain、gateway、runner、backup asset 都要有 alias 與 owner mapping |
| Endpoint / host log | auth、process、network、package、systemd、Docker 訊號要能指到 redacted evidence ref |
| FIM / persistence | 以 Wazuh FIM、process tree、systemd、cron、authorized_keys、port binding 做持久化判讀 |
| Vulnerability / KEV | CVE、KEV、套件、image、SBOM 與 maintenance window 綁在一起 |
| NDR / IDS | Suricata / network detection 先做 passive telemetry lane，不直接變 IPS |
| Wazuh SIEM | 只接 health ref、agent status ref、event ref、rule / decoder readback，不接 raw payload |
| Kali 112 | 只接 health、tool version、scope、normalized finding envelope，不接 `/execute` |
| 告警路由 | Prometheus / Alertmanager / Telegram / no-false-green / noise budget 要一起驗證 |
| Incident / Case | finding 升級要有 owner、severity、confidence、dedupe、SLA 與 escalation |
| 鑑識保存 | chain of custody、retention、redaction、raw payload absence 必須可驗 |
| 配置漂移 | Nginx、firewall、K8s、runner、workflow、secret metadata、host config diff 皆納管 |
| 供應鏈 | Gitea、runner、workflow、deploy key、Harbor、SBOM、image 與 release evidence 串回 SIEM |
| IAM / secret | SSH、sudo、token、cookie、env、runner secret 只能收 metadata，不收 value |
| Web / API AppSec | auth decision、access deny、rate-limit、security headers、CORS、webhook 要有 logging 與 owner |
| Backup / DR | backup existence 不能當 restore proof；restore drill、offsite、escrow、rollback 才能驗收 |
| Reporting | dashboard、KPI、LOGBOOK、frontstage marker 必須保持 0 / false 邊界 |

## 4. 固定數字

| 指標 | 數值 |
|------|------|
| 主流框架 | `14` |
| 營運角色 | `9` |
| 事件生命週期階段 | `8` |
| 成熟度階段 | `7` |
| 驗證 Gate | `18` |
| 控制域 | `16` |
| C0 控制域 | `12` |
| C1 控制域 | `4` |
| 訊號源 | `12` |
| 控制候選 | `20` |
| C0 控制候選 | `12` |
| C1 控制候選 | `8` |
| P0 控制候選 | `12` |
| P1 控制候選 | `8` |
| owner 必填欄位 | `42` |
| reviewer checks | `36` |
| outcome lanes | `14` |
| blocked actions | `103` |
| owner response received / accepted | `0 / 0` |
| Wazuh event refs accepted | `0` |
| Kali scope / finding envelope accepted | `0 / 0` |
| active response / active scan / SOAR / auto block | `0 / 0 / 0 / 0` |
| runtime gate / action button | `0 / 0` |

## 5. 專業資安營運體制

本輪補強不是把工具名稱堆到頁面，而是補上業界 SOC / CSIRT / DevSecOps 需要的責任、流程與驗證口徑。所有角色都只代表審查責任，不代表 runtime action 授權。

| 類型 | 數量 | IwoooS 採用方式 |
|------|------|-----------------|
| 營運角色 | `9` | IwoooS control owner、SOC reviewer、incident commander、platform owner、service owner、evidence custodian、change manager、AI security reviewer、executive risk owner |
| 事件生命週期 | `8` | 準備治理、偵測正規化、分流排序、調查關聯、圍堵決策、清除復原、事後學習、持續改善 |
| 成熟度階段 | `7` | L0 分散觀測到 L6 受治理低風險自動化；目前停在 L1 / L2 只讀證據與 owner packet |
| 驗證 Gate | `18` | owner mapping、source-to-live diff、脫敏證據、secret absence、Wazuh registry、Kali scope、alert receipt、case id、rollback、maintenance window、postcheck、production smoke 等 |

這代表 IwoooS 後續對「主機疑似入侵、Wazuh agent 消失、Nginx 被改、端口被關、告警格式不專業、AI agent 過度執行」都必須先形成 case / evidence / owner / rollback / postcheck，再進入人審或 dry-run。沒有這些欄位時，前台可以顯示風險與下一步，但不能顯示成已修復、已授權或可執行。

## 6. 第一批 P0 優先順序

| 優先 | 候選 | 狀態 |
|------|------|------|
| P0-1 | 資產與 owner 對應表先完整 | `waiting_soc_owner_packet` |
| P0-2 | Wazuh agent / manager / indexer / dashboard health ref 收件 | `waiting_soc_owner_packet` |
| P0-3 | Host auth / process / network / FIM 訊號正規化 | `waiting_soc_owner_packet` |
| P0-4 | Kali 112 health / tool version / scope approval 串接 | `waiting_soc_owner_packet` |
| P0-5 | Kali finding 只接脫敏 envelope，不接 raw output | `waiting_soc_owner_packet` |
| P0-6 | Prometheus / Alertmanager / Telegram 告警鏈 no-false-green | `waiting_soc_owner_packet` |
| P0-7 | Sentry / SigNoz 與主機入侵線索關聯 | `waiting_soc_owner_packet` |
| P0-8 | Nginx / firewall / route / TLS / gateway drift 關聯到 SIEM | `waiting_soc_owner_packet` |
| P0-9 | Gitea / runner / workflow / secret metadata 供應鏈關聯 | `waiting_soc_owner_packet` |
| P0-10 | CISA KEV / CVE / package / image 風險排序 | `waiting_soc_owner_packet` |
| P0-11 | Incident case / owner response / escalation queue | `waiting_soc_owner_packet` |
| P0-12 | 鑑識證據、chain of custody、redaction 與保存期 | `waiting_soc_owner_packet` |

## 7. Runtime 升級順序

1. Repo / snapshot / guard / frontstage marker 完成。
2. Owner 補齊 Wazuh、Kali、host forensic、gateway diff、alert route、supply-chain、KEV / CVE、backup / DR 的脫敏 evidence refs。
3. Reviewer 驗收 raw payload absence、secret absence、dedupe fingerprint、noise budget、rollback owner 與 postcheck owner。
4. 只讀 ingestion 或 mirror 可在獨立批准後啟用。
5. Active response、Kali active scan、credentialed scan、SOAR case create、firewall containment、IPS / blocking 另開維護窗口與 runtime approval。

## 8. 禁止動作

本階段明確阻擋 Wazuh live API 查詢、Wazuh active response、Wazuh agent / rule / decoder 變更、raw Wazuh payload 儲存、Kali `/scan`、Kali `/execute`、Nmap / Nuclei / Nikto / Trivy / Lynis live scan、Kali package update、Kali reboot、SSH / sudo、host log 讀取、Docker / systemd、Nginx、certbot、DNS、firewall、WireGuard、NodePort、NetworkPolicy、ArgoCD、kubectl、Helm、Prometheus reload、Alertmanager reload、Grafana / SigNoz / Sentry / Langfuse 設定、Telegram 實發、SOAR playbook、auto block、secret rotation、workflow / runner / deploy key / webhook / repo secret 變更、raw packet / raw log / 未脫敏截圖、database migration、production write、runtime gate、action button、force push、refs sync 與 GitHub primary switch。

## 9. 完成度

- SOC / SIEM / Kali / Wazuh 整合控制矩陣：`100%`
- 業界主流資安營運體制補強：`100%` 來源端
- 前台只讀可視化：待本輪驗證
- 高價值配置 monitoring / alerting / observability 只讀成熟度：`78%`
- security evidence tooling 只讀成熟度：`88%`
- Wazuh event refs accepted：`0%`
- Kali active scan / `/execute`：`0%`
- SOAR / active response / auto block：`0%`
- runtime gate / action button：`0%`

下一步不是直接掃描或封鎖，而是收齊 owner packet：Wazuh event refs、Kali scope refs、host forensic refs、alert chain refs、gateway diff refs、supply-chain refs、KEV / CVE refs、incident case refs、rollback owner 與 postcheck。驗收前 IwoooS 不宣稱主機乾淨、不宣稱木馬已清除、不宣稱 SIEM 已完成閉環，也不提供任何執行按鈕。

## 10. 2026-06-18 主流 AISOC 補齊

已新增 `docs/security/MAINSTREAM-AISOC-SECURITY-CONTROL-ROADMAP.md`，把主流框架與 AISOC 解決方案拆成 IwoooS 可執行工作包。補齊範圍包含 NIST CSF、CIS Controls、CISA Zero Trust、CISA KEV、MITRE ATT&CK / D3FEND、OWASP ASVS / SAMM / SCVS、SLSA、Sigstore、NIST AI RMF、OWASP LLM Top 10、MITRE ATLAS、CSA AI Controls Matrix、OCSF、Sigma、MISP / OpenCTI、Wazuh、Suricata、Zeek、TheHive / Cortex，以及 Microsoft Sentinel / Security Copilot、Google SecOps / Agentic SOC、Cortex XSIAM、CrowdStrike Falcon Next-Gen SIEM / Charlotte AI、Splunk ES / SOAR、Elastic AI SOC Engine、IBM QRadar SOAR、SentinelOne Purple AI 的能力模型。

主流 AISOC 不是自動修復器。IwoooS 採用的順序是先建 AI-ready data foundation，再做 alert triage、investigation plan、threat hunting、case drafting、enrichment、playbook dry-run、human-in-the-loop response、continuous learning 與 governed autonomy。當前全部 response / containment / auto block / SOAR action / Wazuh active response / Kali active scan 仍為 `0 / false`。

補齊後第一優先順序如下：

1. P0-A 資產 / 配置總清冊。
2. P0-B Wazuh / Kali 112 / SIEM evidence envelope。
3. P0-C Nginx / Gateway config-control。
4. P0-D 端點入侵偵測與鑑識。
5. P0-E 告警鏈 no-false-green。
6. P0-F KEV / package / image / SBOM 關聯。
7. P0-G Incident case gate。
8. P0-H AI Agent 權限閘。

## 11. 2026-06-25 專業體制化補強

本輪把原本 `7` 個主流框架擴到 `14` 個，並新增 `9` 個營運角色、`8` 段事件生命週期、`7` 階成熟度與 `18` 個驗證 Gate。這些欄位已寫入 `docs/security/soc-siem-kali-wazuh-integration-control.snapshot.json`，並由 `security-mirror-progress-guard.py` 固定檢查。

新的完成度口徑：

- SOC / SIEM / Kali / Wazuh 整合控制矩陣：`100%` 來源端。
- 業界主流體制化補強：`100%` 來源端。
- IwoooS 資安體制完整度：`70% -> 76%` 來源端；owner evidence、Wazuh manager registry truth、Kali active scan、SOAR / active response 與 runtime gate 仍維持 `0%`。
- 前台可視化：需完成 production desktop / mobile smoke 後才可宣告 production visible。
- runtime / host write / active response / active scan / auto block：全部維持 `0 / false`。

## 12. 2026-06-25 作戰系統上層整合

SOC / SIEM / Kali / Wazuh 控制矩陣已被納入 `docs/security/IWOOOS-SECURITY-OPERATING-SYSTEM.md`。該作戰系統是上層營運體制，用來固定：

- `20` 個主流框架參照。
- `24` 條資安工作流，其中 `12` 條為 P0。
- `5` 條 severity lane，將已確認入侵、已遭利用弱點、credential exposure、Wazuh agent 消失與 Nginx / firewall drift 排到前面。
- `9` 欄告警訊息合約，要求告警必須白話、可行動、可驗證，不得只貼 raw log。
- `8` 階 AI 自動化閉環與 `12` 個驗證階段。
- `12` 條 no-false-green 規則，避免 route 200、Dashboard up、agent active、CD success 或 UI 可見被誤判成資安完成。

新作戰系統已由 `scripts/security/iwooos-security-operating-system.py` 產生 snapshot，並接入 `security-mirror-progress-guard.py`。目前只代表 source / snapshot / guard / 前台控制面收斂；Wazuh manager registry、Kali scope、alert receipt、incident case、host forensic 與 runtime response 仍維持 `0%` 或 `0 / false`。