146 lines
9.3 KiB
Markdown
146 lines
9.3 KiB
Markdown
# IwoooS 資安作戰系統
|
||
|
||
| 項目 | 內容 |
|
||
|------|------|
|
||
| 日期 | 2026-06-25 |
|
||
| 狀態 | `iwooos_security_operating_system_ready_no_runtime_action` |
|
||
| 工具 | `scripts/security/iwooos-security-operating-system.py` |
|
||
| Snapshot | `docs/security/iwooos-security-operating-system.snapshot.json` |
|
||
| runtime gate | `0` |
|
||
|
||
## 1. 目的
|
||
|
||
本文件把 IwoooS 從「資安頁面與只讀清冊」推進成可治理、可分工、可驗證、可逐步自動化的資安作戰系統。它不是宣告 Wazuh、Kali、Nginx、主機或告警鏈已完成修復,而是把業界主流做法落到 AWOOOI 的固定控制面:
|
||
|
||
1. 有完整工作範圍:主機、服務、網站前後台、API、Nginx / gateway、DNS / TLS、Docker / systemd、K8s / ArgoCD、CI/CD、Gitea / GitHub、Harbor / registry、Wazuh、Kali 112、監控告警、備份還原、AI Agent 與供應鏈。
|
||
2. 有清楚分工:資安作戰負責人、SOC 審查人、事故指揮、平台 owner、服務 owner、證據保管、變更管理、供應鏈 owner、AI 安全審查與風險 owner。
|
||
3. 有即時危害優先序:已確認入侵、已遭利用弱點、credential exposure、Wazuh agent 消失、Nginx / firewall drift 先進 P0。
|
||
4. 有告警訊息合約:告警不能只貼 raw log,必須說清楚發生什麼、影響什麼、證據 ref、AI 分流、候選動作、owner gate 與驗證方式。
|
||
5. 有停止線:沒有 owner、rollback、維護窗口、postcheck、alert receipt、Wazuh / SIEM / case evidence 或 human approval,不得開 response、scan、reload、封鎖或正式寫入。
|
||
|
||
本階段仍維持只讀 source / snapshot / guard / 前台呈現。它不連主機、不呼叫 Wazuh / Kali、不 SSH、不讀 secret、不送 Telegram、不 reload Nginx / Alertmanager、不改 firewall / K8s / workflow,也不啟用 active response、active scan、SOAR 或 auto block。
|
||
|
||
## 2. 導入的主流框架
|
||
|
||
| 類別 | 框架 | IwoooS 用途 |
|
||
|------|------|-------------|
|
||
| 治理 | NIST CSF 2.0、NIST AI RMF | Govern / Identify / Protect / Detect / Respond / Recover 與 AI 風險治理 |
|
||
| 事件應變 | NIST SP 800-61 Rev. 3 | case gate、分流、回應、復原、事後學習 |
|
||
| 基礎控制 | CIS Controls v8.1 | 資產、帳號、弱點、audit log、malware defense、backup |
|
||
| 零信任 | CISA Zero Trust Maturity Model | identity、device、network、application、data、visibility / automation |
|
||
| 弱點優先序 | CISA KEV、FIRST EPSS | 以已遭利用、可利用機率、公開入口與資產重要性排序 |
|
||
| 攻防語言 | MITRE ATT&CK、MITRE D3FEND | detection coverage、data source、defense countermeasure、purple-team |
|
||
| AppSec | OWASP ASVS、OWASP SAMM | 前後台、API、auth、logging、secure SDLC |
|
||
| SIEM / XDR | Wazuh、OCSF、Sigma | endpoint / FIM / event schema / detection-as-code |
|
||
| 告警與觀測 | Prometheus Alertmanager、OpenTelemetry | grouping、dedupe、routing、receipt、trace / metric / log correlation |
|
||
| 供應鏈 | SLSA、SPDX / CycloneDX、Sigstore / Cosign | provenance、SBOM、artifact signing、verify |
|
||
|
||
引用這些框架只代表控制模型與優先序校準,不代表採購、切換產品、啟用 active response 或自動處置。
|
||
|
||
## 3. 固定數字
|
||
|
||
| 指標 | 數值 |
|
||
|------|------|
|
||
| 主流參考框架 | `20` |
|
||
| 營運角色 | `10` |
|
||
| severity lane | `5` |
|
||
| 工作流 | `24` |
|
||
| P0 工作流 | `12` |
|
||
| P1 工作流 | `8` |
|
||
| P2 工作流 | `4` |
|
||
| 告警訊息合約欄位 | `9` |
|
||
| AI 自動化閉環階段 | `8` |
|
||
| 驗證階段 | `12` |
|
||
| no-false-green 規則 | `12` |
|
||
| 跨 session 同步檢查點 | `7` |
|
||
| blocked action | `18` |
|
||
| source artifact 完成度 | `100%` |
|
||
| evidence-weighted 資安作戰系統完成度 | `62%` |
|
||
| SOC / SIEM 框架可視化成熟度 | `92%` |
|
||
| Wazuh manager registry 驗收 | `100% / 6` |
|
||
| runtime response | `0%` |
|
||
| owner response received / accepted | `0 / 0` |
|
||
| runtime gate / action button | `0 / 0` |
|
||
|
||
`62%` 是保守 evidence-weighted 完成度:代表作戰制度、優先序、資料結構、前台邊界、guard 與 Wazuh manager registry 脫敏驗收已形成;不代表主機乾淨、Wazuh agent 全數恢復、入侵已清除、Nginx 已修好或 response 已授權。
|
||
|
||
## 4. P0 工作流優先順序
|
||
|
||
| 優先 | 工作流 | 第一階段目標 |
|
||
|------|--------|--------------|
|
||
| P0-01 | 資產 / 暴露面總圖 | host、domain、route、service、port、package、repo、runner、secret metadata、backup、AI agent |
|
||
| P0-02 | Wazuh manager registry truth | agent total、active、disconnected、last seen、expected minimum、Dashboard / API mismatch |
|
||
| P0-03 | 主機入侵與鑑識 | auth、sudo、process、network、FIM、persistence、package、service、Docker event |
|
||
| P0-04 | Nginx / Gateway config-control | source-to-live diff、rendered diff、nginx test ref、route smoke、rollback |
|
||
| P0-05 | SSH / firewall / WireGuard / NodePort baseline | before / after、actor、impact、operator notification、restoration evidence |
|
||
| P0-06 | 身分與 secret metadata | SSH、sudo、deploy key、runner token name、webhook secret name、OIDC、break-glass |
|
||
| P0-07 | 告警可讀性與 receipt | Telegram / Alertmanager / Wazuh alert card、dedupe、noise budget、receipt |
|
||
| P0-08 | Incident case gate | case id、timeline、owner、decision、containment、recovery、postcheck、lesson learned |
|
||
| P0-09 | KEV / exposure / package SLA | CISA KEV、EPSS、public exposure、asset criticality、maintenance window |
|
||
| P0-10 | 備份 / 還原 / 鑑識保存 | restore drill、offsite、escrow、chain of custody、retention、rollback proof |
|
||
| P0-11 | Runner / workflow / supply-chain | Gitea、workflow、runner、deploy key、Harbor、SBOM、Cosign、SLSA |
|
||
| P0-12 | AI Agent 權限閘 | tool allowlist、redaction、cost、privacy、approval、excessive agency |
|
||
|
||
## 5. Severity 分流
|
||
|
||
| 等級 | 條件 | 目標 |
|
||
|------|------|------|
|
||
| SEV0 | 已確認入侵或 active exploitation | 15 分鐘內形成 case / freeze / containment 候選;不得無 owner 直接執行 |
|
||
| SEV1 | 公開入口高風險、KEV、credential exposure、Wazuh agent 消失 | 30 分鐘內形成 owner packet、證據缺口與維護窗口草案 |
|
||
| SEV2 | Nginx / firewall / runner / workflow / runtime drift | 4 小時內完成 diff、owner、rollback 與 postcheck 計畫 |
|
||
| SEV3 | 告警噪音、coverage gap、dashboard degradation | 1 個工作日內進入 backlog 與 no-false-green 修正 |
|
||
| SEV4 | 治理、文件、成熟度與低風險 hardening | 納入週期報告與例外期限,不得混成緊急事件 |
|
||
|
||
## 6. 告警訊息合約
|
||
|
||
每一則會進入 Telegram、AwoooP Run、Work Item 或 IwoooS 前台的資安告警,都必須包含:
|
||
|
||
1. `event_title`:短標題,讓人一眼知道事件。
|
||
2. `severity_and_confidence`:嚴重度與信心,不用一串 raw 指標代替。
|
||
3. `asset_alias_and_scope`:只用脫敏 alias 與受影響範圍,不顯示個人 namespace 或內部原始識別。
|
||
4. `what_happened_plain_language`:用人能讀懂的語言說明發生什麼。
|
||
5. `why_it_matters`:說明可能造成的資安或服務影響。
|
||
6. `redacted_evidence_refs`:脫敏證據參照,不貼 raw log、secret、token、完整 process dump 或工作視窗對話。
|
||
7. `ai_triage_lane`:入侵、配置漂移、供應鏈、runtime gate、owner review、告警鏈等 AI 分流。
|
||
8. `next_candidate_action`:候選下一步,例如 owner request、dry-run、維護窗口草案、postcheck plan。
|
||
9. `owner_gate_and_verification`:誰要決策、哪個 gate 擋住、驗證如何做。
|
||
|
||
## 7. AI 自動化閉環
|
||
|
||
IwoooS 不是單純看板。每一個資安訊號要算進 AI 自動化主線,必須能走完:
|
||
|
||
`sensor_evidence -> normalizer_redaction -> ai_triage_lane -> candidate_generation -> owner_gate -> execution_boundary -> verifier_readback -> learning_writeback`
|
||
|
||
目前前 4 段已在 source / snapshot / UI 層明確化;owner gate、runtime execution、verifier live readback 與 learning writeback 仍待 owner evidence 與獨立批准。
|
||
|
||
## 8. No-false-green 規則
|
||
|
||
以下情況一律不得宣告資安完成:
|
||
|
||
- route `200` 不等於資安通過。
|
||
- Dashboard up 不等於 Wazuh agent registry 已恢復。
|
||
- agent active 不等於入侵事件結案。
|
||
- alert quiet 不等於告警鏈健康。
|
||
- backup fresh 不等於 restore drill。
|
||
- CD success 不等於 runtime 授權。
|
||
- UI 可見不等於 owner acceptance。
|
||
- AwoooP approval 不等於資安批准。
|
||
- 外部 Agent 宣稱不等於鑑識證明。
|
||
- transport connection 不等於 registry acceptance。
|
||
- source snapshot 不等於 live truth。
|
||
- 一般「批准繼續」不等於維護窗口。
|
||
|
||
## 9. 驗證指令
|
||
|
||
```bash
|
||
python3 scripts/security/iwooos-security-operating-system.py --root .
|
||
python3 scripts/security/security-mirror-progress-guard.py --root .
|
||
python3 scripts/security/iwooos-config-control-guard.py --root .
|
||
```
|
||
|
||
## 10. 邊界
|
||
|
||
本文件不授權 SSH、主機寫入、Wazuh active response、Kali active scan、Kali `/execute`、Nginx reload、firewall change、Docker / systemd restart、ArgoCD sync、kubectl apply、workflow modification、secret rotation、Telegram 實發、SOAR action、auto block、production write 或 force push。
|
||
|
||
下一步是將 P0-07 告警可讀性與 receipt、P0-04 Nginx / Gateway config-control、P0-03 主機入侵與鑑識這三條合併成下一個可驗收 owner packet。Wazuh manager registry truth 已有 6 個公開別名通過脫敏驗收,但所有 runtime / host write / active response / scan / auto block 仍維持 `0 / false`。
|