從 WAF 或 Suricata 寫下一行告警開始，到防火牆多出一條封鎖、再到期自動解除為止，中間經過 Vector、od-bridge、BeakPlatform 的哪些關卡，每一關做什麼判斷。
離開 Vector 的事件長這樣（OCSF 風格，平台契約 v1.0）。六個軸線欄位是整條鏈的相容性契約：後面的 SLA、併案、風險分數、處置中心清單全部只讀這六個。
{
"correlation_id": "6f1d…", // 冪等鍵，平台看到重複就直接回 duplicate
"source_system": "coraza", // 或 suricata；平台 API key 的 scope 限定來源系統
"event_class": "web_activity", // suricata 是 network_activity
"occurred_at": "2026-09-15T00:12:34Z",
"severity_id": 4, // 1 Low … 4 Critical
"finding": { "title": "SQL Injection Attack Detected via libinjection",
"rule_id": "942100", "rule_set": "OWASP CRS" },
"actor": { "ip": "203.0.113.42", "xff": "…", "country": "TW", "user_agent": "…" },
"target": { "host": "www.example.com", "url": "/?id=1' OR 1=1--", "service": "waf-nginx" },
"evidence":{ "raw_log_ref": { "type": "modsec", "locator": "<transaction id>" } }
}
od-bridge 是安裝包裡唯一自寫的程式，一個 Python 程序同時跑兩個迴圈。它的身分來自安裝時的「開通字串」（ODN1. 開頭，由平台端 od_node_pairing.py 產生），裡面包了平台網址、事件受理金鑰（API Key，具 od_intake scope）與執行帳號（service account）。
| 迴圈 | 做什麼 | 細節 |
|---|---|---|
| ingest（被動） | 收 Vector 的 POST，加 HMAC 簽章轉送到平台 /api/open_defense/intake | 簽章 sha256=HMAC-SHA256(secret, "{ts}\n{body}")，標頭 X-OD-Key-Id／X-OD-Timestamp／X-OD-Signature；secret 是 base64 解碼後的 raw bytes。平台回什麼就原樣回給 Vector（5xx 一律轉成 502），並在 /forwards 頁留一筆 |
| executor（主動） | 每 5 秒 GET /api/open_defense/decisions?status=pending，只處理 enforcement_points 含自己負責執行點的決策 | 先用 sa_id / sa_secret 換 JWT（預設 15 分鐘），過期前 60 秒自動續。拿到決策先 PATCH picked_up，逐一呼叫 enforcer，最後 PATCH applied（全成）、partial（部分）或 failed（全失敗，附錯誤）。連續 401 會指數退避到 10 分鐘，429 依 Retry-After 等 |
| 執行點 | 落地到哪 | 支援的動作 | 實際效果範圍 |
|---|---|---|---|
| nftables | 主機 B 的 inet secstack blocklist／blocklist6 set，帶 timeout | block（加元素，TTL 交給 kernel）、unblock（刪元素，已不存在也算成功）。allow 不支援 | 只影響「以該 IP 為封包來源、直連主機 B 本機程序」的流量，見第 5 篇 |
| crowdsec | 本機 CrowdSec LAPI（127.0.0.1:8081），以 od-bridge 這個 machine 身分寫 type=ban 決策 | block、unblock；target 可為 ip／cidr／country／asn | 沒有 bouncer 就只是清單；接了 bouncer 的任何主機都能消費 |
| edl | state.json 為權威，重新渲染 blocklist.txt／allowlist.txt，由 :8500/edl 與 /edl/allow 提供（後者就是總覽第三節第 4 條，平台「放行」決策的落地點） | block、allow、unblock（從兩份清單移除）。每 60 秒自動剔除過期項目 | 取決於誰來抓：PAN-OS、FortiGate、pfSense 等支援 External Dynamic List 的防火牆 |
| cloudflare | 預留，未實作（指「把封鎖推到 Cloudflare IP List」這個執行點；Cloudflare Tunnel 入口本身是完整支援的） | 一律回 not_configured | 無 |
EDL 為什麼是「重新渲染整份」而不是「追加一行」。EDL 是防火牆定期抓的純文字檔，格式裡沒有每筆的 TTL，抓到什麼就是當下的政策。追加式寫法永遠刪不掉過期項目，清單只會長到防火牆拒絕載入。所以 od-bridge 把每筆的 expires_at 存在自己的狀態檔，每次異動與每分鐘 prune 都重寫整份檔案。輸出刻意不加註解與標頭，因為只有部分設備接受「位址 空格 註解」的寫法。
一個常見誤區，SOC的日常就是海量的案件單，這世界已經瘋狂到不可能僅依靠人工就能處理，光是機器人自動攻擊分分鐘打出數百筆的噪音就不可能也沒必要都建立簽單，這三個SOC流程都是在【防禦端】就直接阻擋，【平台端】的資安表單中不會顯示，只有達到風險指標的才會建立案件單給人員判斷
風險鑑定不可能做達到100%無誤判，判斷標准太嚴會造成過多偽陽性單，太鬆會放任攻擊通過，這中間的模糊區間正是需要人工判斷的空間。BeakPlatform 有設計由AI Agent進行案件助審的流程Node，目前支援Claude / Codex 兩廠的Agent，且不是API方式，特別設計透過 Claude -p 這樣的單次處理，非API方式來省錢，API方式暫時不放出來免得燒了大家錢包，有設計一個AI使用額度控制器但我還是先免責好了。
至於AI SOC主動參與只要拉2條線就能完成，留待您自行設計。
| 判斷 | 規則 | 為什麼這樣設計 |
|---|---|---|
| 路由（決定案件類型） | 表 od_form_template_mappings：priority 大的先比對，第一個命中就採用；match_rules 全部條件 AND；運算子只有 12 個（eq、ne、in、not_in、gt、gte、lt、lte、contains、startswith、endswith、exists），沒有 regex。無命中回 422，不塞給預設表單 | 一條規則就是一種案件類型，指向哪張表單就決定走哪個流程。不做 regex 是為了避免 ReDoS；fail-closed 是為了不讓未分類事件靜默混進某個流程 |
| 併案降噪 | 同 actor_ip + 同 finding_rule_id、60 分鐘窗內併進既有案件：事件數累加、嚴重度取最大、風險分數重算。任一鍵為空就不併；OCSF 事件只與 OCSF 併、原生格式只與同來源併 | Vector 已經封頂，但仍可能一分鐘內同 IP 多條規則各到一筆；併案讓 SOC 看到的是「一個攻擊者」而不是「五張單」 |
| 風險分數 | min(100, severity×15 + min(24h 內同 IP 事件數, 6)×5 + min(歷史封鎖次數, 3)×10)；≥ 60 建議 block，否則 observe | 規則式而非模型，因為資料量還不足；歷史封鎖次數刻意跨偵測器計算，同一 IP 被不同系統看到正是風險升高的訊號 |
| SLA | severity ≥ 4 為 15 分鐘、= 3 為 60 分鐘、以下無。起點是案件送出時間 | 標準版只在清單上顯示；SOC 團隊版與單人版有流程節點真的在計時（見下表） |
| 保護清單（總覽第三節第 5 條：禁封清單） | 只檢查 action=block 且目標是 ip／ipv6／cidr；三層來源（企業內建 16 條出廠網段、平台設定的可信代理與額外網段、企業自訂）；目標與保護網段有交集即擋；豁免項目須目標完全落在豁免網段內才生效 | 偵測器架在流量出口，看到的來源常是反向代理自己；無人時段的自動封鎖若沒有這道，會反覆封掉自家設備而且沒人發現。交集與包含語意刻意不對稱：前者防「封 0.0.0.0/0」，後者防「豁免一台變成整段可封」 |
案件走哪個流程，由路由規則指向哪張表單決定。安裝包的 --provision 只建「人工簽核 → 結束」的最小鏈路，不會產生任何決策；要走完整圈得再佈建下面三個之一並啟用路由。這三個SOC是為iThome讀者設計的流程，必須搭配 企業管理自動化與執行框架-以SOC運作為實例 的 BeakPlatform 平台才能運作
單人版的設計原則值得單獨記住：自動處置永遠是可推翻的、而且會自己過期。24 小時 TTL 是安全網不是懲罰：人沒來上班也會自動解封，誤封不會變成永久事故；攻擊若持續會再觸發、再開案、再封，短 TTL 不留缺口。反過來 72 小時會讓一次誤判痛三天，而單人組織週末沒人能手動解封。
這三個SOC架構如有雷同，都是巧合！
| 狀態 | 誰能寫 | 意義 |
|---|---|---|
| pending | 平台（DecisionWriter） | 剛寫入，等執行端來拉。只接 EDL 的部署會一直停在這裡，所以平台端 EDL 的過期判斷看 expires_at 不看狀態 |
| picked_up | 執行端 | od-bridge 已拿到，正在落地 |
| applied | 執行端 | 所有執行點成功。要看 application_result 才知道每個執行點的真實回報，曾有 nft 不存在卻回成功的案例 |
| partial | 執行端 | 部分執行點失敗（例如 CrowdSec machine 憑證不在） |
| failed | 執行端 | 全部失敗，附錯誤摘要 |
| expired | 只有平台 cron | TTL 到期，平台同時新增一筆 unblock 給執行端去拉 |
| revoked | 只有平台管理員 | 人工撤銷，同樣以一筆 unblock 落地 |
nftables 這一側另有 kernel 自己的 timeout：block 加元素時帶 timeout s，就算平台與 od-bridge 都掛了，kernel 也會在 TTL 到期時自行剔除。兩層到期機制各自獨立，這是為了讓「解封」不依賴任何單一元件活著。
iThome鐵人賽
看影片追技術