靜態儀表板已死：SIEM+ 動態安全態勢分數的工程實踐
發布於： Eventus Engineering Blog（eventus.blog）
作者： Eventus Technologies 工程團隊
在資安產業，我們有一個很糟糕的習慣：把「數量」等同於「風險」。當傳統 SIEM 儀表板顯示 10,000 個告警時，狀態指示燈轉紅、態勢分數跌到零，主管也跟著恐慌。
但任何 Tier-1 SOC 分析師都知道，針對一個對外公開 IP 的簡單自動化連接埠掃描，就能在三分鐘內產生 5,000 筆原始防火牆拒絕記錄。那不是 5,000 個獨立的重大威脅，而是一個低層級事件。
當我們打造 SIEM+（siem.plus）時，我們知道如果只是把原始告警數量餵進 UI，就會重現我們原本想消除的「告警疲勞」。我們需要一種方法，把資料湖中的雜訊轉化為能在董事會議桌上使用、並真正反映風險的指標。
以下深入介紹 SIEM+ 動態安全態勢分數、懲罰衰減演算法，以及我們如何迫使 LLM 將威脅映射到合規框架，同時避免幻覺。
🧠 步驟一：事件分組（意圖去重）
產生真正的資安分數，第一步是避免 AI 把每一筆日誌都當成獨立事件。
由於我們使用事件驅動的彙整層（從底層資料湖擷取輕量摘要），AI 引擎會收到成批活動。我們設計 LLM 流程執行意圖去重。
如果 AI 引擎看到同一位使用者先後出現 50 次登入失敗，接著發生 MFA 繞過，它不會輸出 51 個告警，而是產生一個 JSON 物件：一個事件案例（Case）。這個 Case 包含根本原因、時間軸與嚴重性，大幅降低評分引擎的分母。
⚖️ 步驟二：懲罰衰減演算法
把雜訊整合成獨立 Cases 後，我們需要針對特定安全類別（例如身分與存取管理、網路邊界）計算實際的安全態勢分數（0–100）。
我們沒有採用會讓分數過快跌到零的線性扣分，而是依據分組 Cases 的嚴重性，而非原始告警，實作客製化的懲罰衰減演算法。
評分引擎會評估兩個主要因素：
- 嚴重性加權： 每個 Case 都會被分配基礎扣分；Critical 事件扣分很重，Low 事件則只造成輕微影響。
- 對數衰減： 當大量相似 Cases 同時出現，系統會套用衰減函數。同類型的後續事件不會一次又一次扣除完整分數。
這套邏輯確保單一重大 MFA 繞過對態勢分數的傷害，遠高於 1,000 次低層級防火牆連線探測，更準確地反映真正的基礎架構風險。
🛡️ 步驟三：動態框架映射（NIST 與 CIS）
靜態合規儀表板出了名地脆弱。它們依賴硬編碼規則，例如「Rule ID 404 觸發就標記 NIST PR.AC-1」。基礎架構一改變，映射就失效。
我們設定 SIEM+ AI 引擎，將 Cases 動態映射至 NIST CSF v2.0 與 CIS Controls v8。為避免 LLM 捏造不存在的合規代碼，我們使用注入官方框架文件 RAG（檢索增強生成）內容的嚴格系統提示。
AI 會評估攻擊本質，例如未經授權的電子郵件轉寄規則，並將它映射至遭違反的正確控制項家族。
🏗️ 步驟四：以嚴格資料契約駕馭 AI
打造 AI 驅動平台最困難的部分之一，是駕馭 LLM 的不可預測性。你不能只把原始對話文字餵給結構化企業儀表板，然後期待它正確呈現。
即使我們的終端使用者不會接觸原始程式碼或 JSON，只會看到簡潔、適合主管閱讀的介面，我們的後端仍高度依賴確定性的資料契約。我們強制 LLM 輸出嚴格格式化的 JSON payload，限制在精確 schema 內，若產生額外欄位則大幅懲罰。
以下是 AI 引擎在幕後產生、並傳遞給 UI 的結構化情報示例：
{
"ui_category": "Cloud & Infrastructure Security",
"has_log_coverage": true,
"score": 72.5,
"cases": { "critical": 0, "high": 2, "medium": 4 },
"frameworks": { "nist_v2": "PR.DS", "cis_v8": "CIS_CONTROL_5" },
"evidence_string": "Score degraded due to 2 High-severity cases: Public S3 bucket misconfiguration and unauthorized IAM role assumption."
}
結果：可執行的資安
透過結合 Case 分組、懲罰衰減演算法與動態 JSON schema 生成，SIEM+ 在 SOC 第一線與企業董事會之間搭起橋樑。
資安工程師能取得所需的完整脈絡與修復步驟，CISO 則能取得準確反映基礎架構健康狀況、具備數學依據且可辯護的安全態勢分數。