# IwoooS 主流 AISOC 資安控制路線圖

| 項目 | 內容 |
|------|------|
| 日期 | 2026-06-25 |
| 狀態 | 主流框架補齊；只讀控制路線圖；專業資安營運體制已補強 |
| 適用範圍 | AWOOOI / AwoooP / IwoooS、所有主機、網站前後台、API、Nginx / Gateway、Docker / systemd、K8s / ArgoCD、CI/CD、Gitea / GitHub、Harbor / registry、Wazuh、Kali 112、監控告警、備份還原、AI Agent 與供應鏈 |
| runtime 授權 | `false` |
| active scan 授權 | `false` |
| 自動封鎖授權 | `false` |

## 1. 主流參考來源

此路線圖把業界主流框架與 AISOC 產品實務拆成 IwoooS 可執行工作包。引用這些來源不代表採購或切換產品；目前只作為控制域、證據欄位與優先序校準。

| 類別 | 主流來源 | IwoooS 採用方式 |
|------|----------|-----------------|
| 企業資安治理 | [NIST CSF 2.0](https://www.nist.gov/cyberframework) | 以 Govern / Identify / Protect / Detect / Respond / Recover 建立總控管框架 |
| 控制庫 / GRC | [NIST SP 800-53 Rev. 5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) | 把 access control、audit、configuration、incident response、contingency、supply-chain controls 轉成 IwoooS evidence backlog |
| ISMS 管理系統 | [ISO/IEC 27001](https://www.iso.org/standard/27001) | 建立 risk register、control owner、exception register、內部稽核與持續改善節奏；目前只做對照，不宣稱認證 |
| 基礎控制優先序 | [CIS Controls v8.1](https://www.cisecurity.org/controls/v8-1) | 轉成資產、帳號、弱點、告警、備份、稽核與應變的 P0/P1 清單 |
| 零信任 | [CISA Zero Trust Maturity Model 2.0](https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model) | 補 identity、device、network、application、data、visibility / automation 五大成熟度 |
| 已遭利用弱點 | [CISA KEV](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) | 弱點優先序不可只看 CVSS，必須關聯 KEV、公開入口與 exploit exposure |
| 弱點風險排序 | [FIRST EPSS](https://www.first.org/epss/) | 將 CVSS、KEV、EPSS、公開入口、可利用性與資產重要性合併，形成修補 SLA |
| 攻擊技術 | [MITRE ATT&CK Enterprise](https://attack.mitre.org/matrices/) | 偵測規則、告警分類、hunt playbook 與 coverage gap 用 ATT&CK 映射 |
| 防禦技術 | [MITRE D3FEND](https://d3fend.mitre.org/) | 每個 ATT&CK technique 必須映射防禦 countermeasure 與 evidence |
| 事件應變 | [NIST SP 800-61 Rev. 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final)、[CISA Incident / Vulnerability Response Playbooks](https://www.cisa.gov/resources-tools/resources/federal-government-cybersecurity-incident-and-vulnerability-response-playbooks) | incident case、triage、containment、eradication、recovery、post-incident、vulnerability response 統一成 case gate |
| CSIRT 能力 | [FIRST CSIRT Services Framework](https://www.first.org/standards/frameworks/csirts/csirt_services_framework_v2.1) | 定義 IwoooS / AwoooP / owner / reviewer / responder 的服務目錄、交接與升級分工 |
| AppSec | [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/) | 前後台、API、auth、session、input / output、logging 與 access-control 驗收 |
| SSDLC 成熟度 | [OWASP SAMM](https://owasp.org/www-project-samm/) | 把治理、設計、實作、驗證、營運納入軟體安全成熟度 |
| 供應鏈 | [OpenSSF SLSA](https://slsa.dev/) | 建立 provenance、hosted build、artifact integrity 與防竄改基準 |
| OSS 風險評分 | [OpenSSF Scorecard](https://openssf.org/projects/scorecard/) | 針對第三方 repo / package 做 branch protection、dependency update、token permissions、signed release 等風險分級 |
| SBOM 標準 | [SPDX](https://spdx.dev/) / [CycloneDX](https://cyclonedx.org/) | Harbor、image、npm、Python、K8s manifest、AI model / dataset metadata 都要能產出或接收 BOM evidence |
| Artifact 簽章 | [Sigstore / Cosign](https://docs.sigstore.dev/cosign/signing/signing_with_containers/) | Harbor / container image / SBOM 先做簽章與驗章路線圖，不立即改 pipeline |
| GitHub / repo security | [GitHub Secret Scanning](https://docs.github.com/code-security/secret-scanning/about-secret-scanning) | 對齊 secret scanning、push protection、code scanning、dependency review 缺口 |
| 元件驗證 | [OWASP SCVS](https://owasp.org/www-project-software-component-verification-standard/) | 補 SBOM、dependency、license、來源可信度與修補優先序 |
| AI 風險 | [NIST AI RMF](https://www.nist.gov/itl/ai-risk-management-framework) | AI Agent、模型路由、資料外洩、成本、品質與人審 gate 納入風險管理 |
| LLM / GenAI 安全 | [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/) | 補 prompt injection、sensitive disclosure、tool misuse、supply chain、excessive agency |
| AI 攻擊技術 | [MITRE ATLAS](https://atlas.mitre.org/) | AI Agent / 模型 / RAG / tool calling 的 adversarial tactics 映射 |
| AI 控制矩陣 | [CSA AI Controls Matrix](https://cloudsecurityalliance.org/artifacts/ai-controls-matrix) | 雲端 AI 系統安全、責任、稽核與合規控制補齊 |
| SIEM schema | [OCSF](https://ocsf.io/) | Wazuh、Nginx、Docker、K8s、Gitea、Harbor、Sentry、SigNoz 事件正規化方向 |
| 偵測規則 | [Sigma](https://sigmahq.io/sigma/) | Detection-as-code 規則格式，避免只靠 UI 內建規則 |
| 威脅情報 | [MISP](https://www.misp-project.org/) / [OpenCTI](https://filigran.io/platform/opencti/) | IOC、TTP、campaign、actor 與內部 incident case 做關聯 |
| Open SIEM / XDR | [Wazuh](https://wazuh.com/) | 端點、FIM、vulnerability、config assessment、compliance 與 SIEM 的第一層 |
| NDR / IDS | [Suricata](https://suricata.io/) / [Zeek](https://zeek.org/) | Kali 112 或獨立 sensor 先做被動 network evidence，不先開 IPS |
| Case / SOAR | [TheHive / Cortex](https://strangebee.com/thehive/) | Incident case、observable enrichment、人工審查與 playbook 草案 |
| 雲原生 runtime 偵測 | [Falco](https://falco.org/) | Docker / K8s syscall、container escape、privilege escalation、suspicious shell、secret access 先列成 P1 passive detection gap |
| 雲端 SIEM / AISOC | Microsoft Sentinel + Security Copilot、Google SecOps / Agentic SOC、Palo Alto Cortex XSIAM、CrowdStrike Falcon Next-Gen SIEM / Charlotte AI、Splunk ES / SOAR、Elastic AI SOC Engine、IBM QRadar SOAR、SentinelOne Purple AI | 只借鑑能力模型：AI-ready data、triage、investigation、case、SOAR、UEBA、TI、AI assistant 與 human-in-the-loop |
| K8s / 容器硬化 | [NSA / CISA Kubernetes Hardening Guidance](https://www.cisa.gov/news-events/alerts/2022/03/15/updated-kubernetes-hardening-guide)、[CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes)、[CIS Docker Benchmark](https://www.cisecurity.org/benchmark/docker) | K8s / Docker / registry / runtime policy 先做只讀差距盤點，再開維護窗口 |
| Nginx / Gateway | [NGINX Security Controls](https://docs.nginx.com/nginx/admin-guide/security-controls/) | Nginx 變更需版本化、diff、owner、rollback、route smoke、TLS 與 upstream evidence |

## 2. 必做控制域

### 2.1 2026-06-25 體制化補強

IwoooS 的資安機制要符合業界主流做法，不能只停在「有 Wazuh、有 Kali、有告警」。本輪把控制面補成可被審計、可分工、可驗證、可逐步自動化的營運體制：

| 構面 | 固定數字 | 導入目的 |
|------|----------|----------|
| 主流框架 | `14` | NIST CSF、NIST SP 800-61、CIS、CISA、MITRE、OWASP、Wazuh、Alertmanager、OpenTelemetry、SLSA / SBOM、NDR 與 Kali 對齊 |
| 營運角色 | `9` | 明確分開 control owner、SOC reviewer、incident commander、platform owner、service owner、evidence custodian、change manager、AI security reviewer 與 risk owner |
| 事件生命週期 | `8` | 從準備、偵測、分流、調查、圍堵決策、清除復原、事後學習到持續改善 |
| 成熟度階段 | `7` | L0 分散觀測到 L6 受治理低風險自動化；目前不越過只讀 evidence / owner packet |
| 驗證 Gate | `18` | owner、scope、source-to-live diff、redaction、secret absence、Wazuh registry、Kali scope、alert receipt、case id、rollback、maintenance window、postcheck 與 production smoke |

本體制引用主流框架只代表控制模型與優先序校準，不代表採購、切換平台、啟用 active response、執行 Kali active scan、修改 Nginx、reload Alertmanager、發 Telegram live send 或允許 AI agent 直接處置。

### 2.2 2026-06-25 作戰系統入口

新增 `docs/security/IWOOOS-SECURITY-OPERATING-SYSTEM.md` 作為 IwoooS 資安作戰系統入口。它把主流框架、SOC / CSIRT / DevSecOps 分工、SEV0-SEV4 即時危害分流、24 條工作流、9 欄告警訊息合約、8 階 AI 自動化閉環、12 個驗證階段、12 條 no-false-green 規則與 7 個跨 session 同步檢查點統一到一份 snapshot。

目前作戰系統完成的是 source / snapshot / guard / frontstage 可驗證控制面：`source artifact=100%`、`evidence-weighted=56%`、`runtime response=0%`、`Wazuh manager registry acceptance=0%`。這個入口不會覆蓋既有資產總帳、外部入侵防堵矩陣或 SOC / SIEM / Kali / Wazuh 控制矩陣，而是把它們排進同一條作戰路線。

| 優先 | 控制域 | 要做什麼 | 第一階段驗收 |
|------|--------|----------|--------------|
| P0 | 資產與暴露面 | 建立 host、domain、route、service、port、package、container、repo、workflow、secret metadata、backup、AI agent 完整 inventory | 每個資產有 owner、用途、風險、來源證據、最後觀測時間 |
| P0 | 高價值配置管控 | Nginx、firewall、DNS、TLS、WireGuard、Docker compose、systemd、K8s manifests、ArgoCD、workflow、runner、Harbor、backup config 全部納入 config-control | 未經 owner packet 不可 reload / restart / sync / rotate / change |
| P0 | Wazuh 端點與 FIM | 主機 agent、manager health、agent status、FIM baseline、auth / sudo / process / persistence / package / service event 欄位先只讀接入 | 有 Wazuh event ref 與 host alias，不保存 raw secret / raw payload |
| P0 | Kali 112 證據節點 | Kali 工具版本、health、scope、允許 profile、禁止 profile、輸出 envelope、rate limit、維護窗口、rollback owner | Kali 維持 observe-only；active scan 與 `/execute` 均為 `0 / false` |
| P0 | SIEM 資料正規化 | 以 OCSF / Sigma 口徑定義 event schema、dedupe fingerprint、severity、confidence、asset、owner、ATT&CK technique | Wazuh / Nginx / Docker / K8s / Gitea / Harbor / Sentry / SigNoz 有 mapping 草案 |
| P0 | 偵測工程 | ATT&CK coverage、D3FEND countermeasure、Sigma rule、測試資料、false-positive budget、no-false-green gate | 每條偵測規則有 technique、資料源、測試、owner、disable 條件 |
| P0 | Incident case | 建立 case schema：alert、asset、owner、timeline、evidence refs、decision、containment、recovery、postcheck、lesson learned | 沒有 case 就不能宣告事件處置完成 |
| P0 | 通知與告警鏈 | Prometheus、Alertmanager、Telegram gateway、Sentry、SigNoz、Wazuh alert 需有 route、receiver、receipt、silence / dedup / inhibit review | route 200 不等於告警鏈健康；需 receipt evidence |
| P0 | 身分與 secret | SSH、sudo、service account、runner token、deploy key、webhook、OIDC、AI tool token、break-glass 全部只收 metadata，不收 value | Secret value / hash / partial token 一律拒收 |
| P0 | 已知遭利用弱點 | CISA KEV、公開入口、服務版本、container image、package、Nginx / K8s / Docker / Git / runner / Wazuh / Harbor 關聯 | KEV 命中需高於一般 CVSS 優先處理 |
| P0 | 備份 / 還原 / 鑑識 | backup freshness、offsite、restore drill、forensic preservation、chain of custody、evidence retention | 沒有 restore drill 不能宣告 DR 完成 |
| P0 | AI Agent 安全 | AI agent 權限、tool allowlist、prompt redaction、output validation、cost gate、human review、excessive agency 防護 | AI 不可直接 host write / secret read / auto block / production deploy |
| P0 | GRC / 例外管理 | risk register、control owner、exception register、accepted risk、expiry、review cadence、audit evidence | 沒有有效期限與 owner 的例外不可長期存在 |
| P0 | 入侵處置生命週期 | preparation、detection / analysis、containment、eradication、recovery、post-incident 全部形成 case fields | 不可只用「服務恢復」宣告入侵處置完成 |
| P1 | NDR / 網路觀測 | Suricata / Zeek passive sensor、DNS / TLS / HTTP / flow logs、east-west visibility、egress anomaly | 先 passive，不開 IPS / auto block |
| P1 | SOAR / Playbook | TheHive / Cortex 類 case 與 enrichment model，先做 playbook 草案、dry-run、approval gate | SOAR action 預設 `0 / false`，只允許人工批准後執行 |
| P1 | Threat Intelligence | MISP / OpenCTI 類 IOC / TTP / campaign / actor / malware / CVE 關聯 | IOC 不可直接封鎖，需 evidence / owner / blast radius |
| P1 | K8s / Docker 硬化 | CIS / NSA-CISA 對照：RBAC、NetworkPolicy、Pod Security、image scan、least privilege、audit log、secret mount | 先盤點，不直接 kubectl / helm / ArgoCD sync |
| P1 | Runtime threat detection | Falco 類 syscall / container / K8s event detection、rule owner、false-positive budget、SIEM forwarding | 先寫 detection gap，不開自動 kill / quarantine |
| P1 | 供應鏈與 artifact | SLSA、SBOM、Cosign、provenance、dependency review、CodeQL / SAST、secret scanning、license | 先產生缺口矩陣，不立即改 workflow 或切 GitHub primary |
| P1 | AppSec / API | ASVS / SAMM：auth、authorization、session、input validation、rate limit、CORS、CSRF、security headers、audit log | 高風險 API 需 contract、test、owner 與 abuse case |
| P1 | AISOC AI 助理 | 借鑑 Sentinel / Google SecOps / XSIAM / Charlotte AI / Splunk / Elastic / QRadar / Purple AI：摘要、查詢、triage、case draft | AI 只能建議與摘要，不可直接處置 |
| P2 | Exposure Management | 外部攻擊面、弱點、身份、雲端、SaaS、repo、AI agent、資料流合併成 exposure graph | 有風險 score、owner、evidence、aging |
| P2 | UEBA / 行為分析 | 使用者、服務帳號、runner、AI agent、host process、network egress 建立 baseline | 先告警候選，不自動停權 |
| P2 | Purple team / 驗證 | ATT&CK emulation、tabletop、BAS / canary、偵測回歸測試 | 只在維護窗口和授權 scope 內執行 |
| P2 | Compliance / Audit | ISO 27001 / SOC 2 類 evidence folder、control owner、audit log、exception register | 證據只收脫敏摘要與 refs |
| P3 | MDR / 24x7 流程 | 值班、升級、RACI、SLA、runbook、on-call、事故演練 | 人與流程準備完成後再談 automation |

## 3. AISOC 能力模型

主流 AISOC 不是「AI 自動幫你修」。它的成熟能力應拆成以下 10 層，且每層都有人工閘：

1. **AI-ready data foundation**：事件、資產、身份、弱點、網路、repo、container、AI agent log 必須先正規化。
2. **Alert triage**：AI 可做摘要、去重、severity 建議、相似事件關聯，但不能直接關閉告警。
3. **Investigation plan**：AI 可產生調查步驟、查詢語句、需要的 evidence refs 與預期結果。
4. **Threat hunting**：AI 可協助 Sigma / YARA-L / query draft，但規則需 reviewer 驗收。
5. **Case drafting**：AI 可建立 incident case 草案，必須由人確認 owner、scope、impact、decision。
6. **Enrichment**：AI 可讀 CTI / KEV / ATT&CK / asset metadata，不可讀 secret value。
7. **Playbook dry-run**：SOAR playbook 預設只跑 dry-run，輸出 blast radius、rollback、postcheck。
8. **Human-in-the-loop response**：隔離、封鎖、reload、restart、patch、secret rotation、deploy 都需獨立 runtime approval。
9. **Continuous learning**：每次事件回寫 detection gap、false positive、missing telemetry、runbook update。
10. **Governed autonomy**：只有低風險、可回滾、已演練、有 receipt 的動作才能逐步開自動化；IwoooS 目前全部維持 `0 / false`。

## 4. 立即優先順序

1. **P0-A 資產 / 配置總清冊**：把所有主機、服務、網站前後台、API、Nginx、Docker、K8s、CI/CD、repo、AI agent、backup、監控告警統一成 asset graph。
2. **P0-B Wazuh / Kali 112 / SIEM evidence envelope**：定義 Wazuh event、Kali finding、SIEM correlation、alert receipt、case id 的最小欄位。
3. **P0-C Nginx / Gateway config-control**：Nginx 常被亂變動，需建立 canonical source、rendered diff、owner packet、nginx -T readback、rollback ref、route smoke。
4. **P0-D 端點入侵偵測與鑑識**：Wazuh FIM、auth、sudo、process、persistence、package、service、network connection、Docker event。
5. **P0-E 告警鏈 no-false-green**：Alertmanager / Telegram / Sentry / SigNoz / Wazuh alert 必須有 receipt，不可用 route up 代替。
6. **P0-F KEV / package / image / SBOM 關聯**：公開入口與 host package 若命中 KEV，優先於一般弱點。
7. **P0-G Incident case gate**：任何入侵、異常封鎖、端口變更、主機重啟，都必須形成 case 與 postcheck。
8. **P0-H AI Agent 權限閘**：所有 AI / Codex / Gemini / OpenClaw / Hermes / NemoTron / worker tool 權限列入 identity inventory 與 tool allowlist。
9. **P1-A NDR passive sensor**：Kali 112 或獨立 sensor 建立 Suricata / Zeek passive 計畫，不先開 IPS。
10. **P1-B Detection-as-code**：ATT&CK / D3FEND / Sigma / test fixture / false-positive budget。
11. **P1-C Supply-chain hardening**：SLSA / SBOM / Cosign / secret scanning / CodeQL / dependency review / artifact provenance。
12. **P1-D K8s / Docker benchmark**：CIS / NSA-CISA 差距盤點與維護窗口草案。
13. **P1-E AISOC triage assistant**：AI 先做 read-only triage / summary / case draft；不可執行 response。
14. **P1-F CSIRT / GRC operating model**：定義事件服務目錄、RACI、例外期限、accepted risk、audit evidence、升級 SLA。
15. **P1-G Runtime threat detection gap**：Falco / Wazuh / Docker event / K8s audit event 的資料源與 rule backlog。
16. **P1-H SBOM / VEX / provenance intake**：SPDX / CycloneDX、VEX、Cosign verify、OpenSSF Scorecard 與 package freshness 先進 inventory。

## 5. 驗收與停止線

每一項若缺以下欄位，不得從候選升級為已完成：

- `owner role / team`
- `decision`
- `decision reason`
- `affected scope`
- `redacted evidence refs`
- `rollback owner`
- `maintenance window`
- `postcheck`
- `alert receipt`
- `case id`
- `secret absence attestation`
- `runtime approval id`

停止線固定如下：

- 沒有 owner，不做 runtime 動作。
- 沒有 rollback，不做變更。
- 沒有 maintenance window，不更新套件、不重啟、不 reload。
- 沒有 postcheck，不宣告完成。
- 沒有 alert receipt，不宣告告警鏈健康。
- 沒有 restore drill，不宣告 DR 完成。
- 沒有 Wazuh / SIEM / case evidence，不宣告入侵處置完成。
- 沒有 human approval，不開 Wazuh active response、Kali active scan、SOAR action、auto block。

## 6. 本階段邊界

本文件是主流 AISOC / SOC / SIEM / XDR / SOAR / CTI / AppSec / Supply-chain / AI security 的工作路線圖，不是操作授權。它不批准 SSH、Kali active scan、Kali `/execute`、Wazuh active response、Nginx reload、firewall change、K8s sync、workflow 修改、secret rotation、Telegram live send、SOAR action、auto block 或 production write。