引言

在上篇文章中，我們將 n8n 整合為 OpenClaw 的 MCP 伺服器，建立了工作流程自動化的基礎。在文章的最後，我寫下了「未來展望」如下：

安全警報自動分流：Sysdig 警報 → 資訊收集 → 嚴重度判斷 → 通知

自那以來，我們著手於這項目標。將自宅的 Mac Mini 上運行的 AI 委託於 24 小時 365 天的安全監控，這正是我們的努力方向。

Sysdig Secure 已經能在 K8s 叢集上檢測到威脅，並將警報發送至 Slack，但問題在於，即使警報發送來，最終還是需要自己打開儀表板，確認內容，判斷嚴重性，並考慮應對——這樣的手動工作仍然存在。在工作或深夜收到警報時，無法即時回應。

簡而言之，透過將 OpenClaw 打造成 AI SOC 分析師，我們實現了一個由 AI 自主處理警報的自動分流、深入調查、Telegram 通知及每日摘要生成的世界。

然而，這個過程並不只是「寫寫提示」這麼簡單。需要進行 8 輪的需求定義審查，標註 61 項問題，以及與「如何設計檢測與分析的角色分配」這一關鍵問題的抗爭——預料之外的連串戲劇。

在家建立企業級 SOC

▲ SOC 導入前後的比較：從手動應對的世界轉變為 AI 駐守的 SOC

Before: 只收看警報的世界

之前的運作過程如下：

• Sysdig Secure 檢測到警報 → 發送至 Slack #security-alerts
• 當偶然查看到 Slack 時才會意識到「啊，警報來了」
• 打開 Sysdig 的儀表板確認內容
• 自行判斷是否嚴重
• 深夜或工作中的警報則會被擱置至隔天

即便是家庭實驗室，運行著四節點的 K8s 叢集，警報還是會不斷發生。由於正在運行以 Falco 為基礎的檢測規則，因此會正確捕捉到對 /etc/shadow 的讀取或可疑的過程運行。然而僅僅檢測是沒有意義的。如果不去操作「分析→判斷→應對」的循環，那就不能稱之為 SOC。

After: AI 駐守的 SOC 世界

構建後的世界變為：

24/7 自動分流：警報一發送，AI 就會在線程中發布分流結果，包括嚴重性、MITRE ATT&CK 技術 ID、影響範圍以及推薦初動的結構化報告。

自動深入調查：對於 Critical/High 警報，自動使用 Sysdig MCP 進行雙階段調查（資訊收集 → Diamond Model 假設驗證）。

智能通知：不會因為深夜的低警報而被喚醒，只有 Critical/High 會即時通知到 Telegram。

每日摘要：每個早上 8 點，通過 Telegram 獲取前一天的全部警報統計、K8s 健全性和趨勢。

企業級 SOC 的對應

有趣的是，企業級 SOC 的工具堆疊能夠直接映射到家庭實驗室中。

在企業環境中，通常使用的 3 層（Tier 1 分流 → Tier 2 分析 → Tier 3 獵捕）的 SOC 模型，但在家庭實驗室中，我們將其壓縮為 2 層：

• AI 層（OpenClaw）：自動執行 Tier 1 分流 + Tier 2 深入調查
• 人員層（自己）：Tier 3 威脅獵捕 + 最終判斷

在 6 個交接點（HP-1〜HP-6）明確定義 AI 與人之間的邊界，破壞性操作（Pod 刪除、認證資訊輪換、節點重啟）必須徵得人類的批准，這是一種安全設計。

設計過程：需求定義書被審查 10 次的故事

為什麼要從需求定義開始

從上次的 n8n 整合（27 個任務、一天完成）經驗中，我感受到「先定義好需求，實作會更順利」的道理。SOC 運作比 n8n 複雜得多，包含 12 本劇本、18 種 ATT&CK 技術、9 個指標和 14 個 E2E 測試——這些若隨意實作將極為不智。

因此，我們不進行任何實作，從徹底提高需求定義書的質量開始。

10 次審查發現的 61 件問題

需求定義書從 v1.0 演進至 v1.9，這一過程中進行了 8 輪的審查，發現並修正了總計 61 件的問題。

隨著審查的重複進行，質量明顯提升：

特別令人印象深刻的是 REV1 的 Critical 指摘：MITRE ATT&CK 的子技術 ID T1543.005 和 T1552.007 竟然在官方矩陣中不存在。因為我試圖將針對容器環境的檢測模式強行映射到 ATT&CK 上，但卻使用了不存在的 ID。在將其明示為自訂映射 (*) 後雖然已經解決，但若無審查，錯誤的 ATT&CK ID 就會流入生產環境。

採用的框架

在設計 SOC 運作時，我們採用了以下框架：

架構

組件結構

▲ 家庭實驗室 SOC 架構 -- 映射到 NIST CSF 2.0 的 6 機能

系統由三個主要組件組成：

1. Sysdig Secure（SaaS）：基於 Falco 的 K8s 叢集運行時檢測。與 OpenClaw 進行的 21 種 MCP 工具連接。
2. OpenClaw Gateway（Mac Mini）：AI SOC 分析師。利用 Sysdig MCP + n8n MCP 執行分流及調查。
3. n8n（Docker）：工作流程自動化。提供網頁獲取（威脅情報）等作為 MCP 工具。

▲ n8n 的執行歷程：MCP Server Trigger → get_current_time / fetch_webpage。所有執行在幾毫秒內成功

警報生命週期

▲ 警報的 6 階段生命週期：檢測→通知→分流→調查→應對→記錄

警報以二階段處理：

第一階段（檢測→分流）：

1. Sysdig Secure 利用 Falco 規則檢測運行時事件
2. 通過 Webhook 發送至 Slack #security-alerts
3. OpenClaw AI 自動在線程內發佈分流結果

第二階段（調查→記錄）：

4. Critical/High 警報將在 Sysdig MCP 上自動進行深入調查
5. 利用 Diamond Model 進行 4 假設驗證（正常運行/權限提升/外部侵入/自動化異常）
6. 生成事件報告 → 記錄至 Slack 線程 + GitHub Issue

MCP 工具的全景

此次專案最具特色的是，完整地將 52 種 MCP 工具映射至 SOC 功能之中。

Sysdig 的 21 種工具將 SOC 功能細化為如下：

檢測系:  sysdig_list_runtime_events, sysdig_get_event_info
調查系:  sysdig_get_event_process_tree, sysdig_run_sysql, sysdig_generate_sysql
K8s 監控: sysdig_k8s_list_nodes, sysdig_k8s_list_workloads, sysdig_k8s_list_pod_containers
資源: sysdig_k8s_list_top_cpu_consumed_*, sysdig_k8s_list_top_memory_consumed_*
故障檢測: sysdig_k8s_list_top_restarted_pods, sysdig_k8s_list_top_unavailable_pods

「提示即產物」— AGENTS.md 的設計

不是代碼，而是提示作為產物

此次專案中最重要的發現是，產物不再是代碼，而是提示。

AGENTS.md 是定義 OpenClaw 的「人格」的文件。於此記載 SOC 分析師的行為——嚴重度的判斷標準、ATT&CK 映射的規則、分流的輸出格式、升級條件——所有內容皆以此為基礎。

AGENTS.md 的結構

壓縮版 AGENTS.md（336 行，11052 字元）的主要部分如下。

嚴重度表：將 Sysdig 的警報嚴重度轉換為 SOC 的 4 段的規則。

▲ 將 Sysdig 的警報嚴重度映射至 SOC 的 4 段。MTTR 目標也相連結以管理應對速度

因為 Sysdig 的 High 為最高嚴重度，所以沒有明示嚴重度的警報，例如 Runtime Event 和 Notable Events 也被附上 High = Critical/High 處理的規則，以優先應對。

分流輸出格式：AI 在線程發布的分流結果模板。

1. 標題（嚴重度 / ATT&CK Txxxx / 影響範圍）
2. 摘要（1-2 句的中文總結）
3. 檢測規則（Sysdig 規則名稱 + 條件）
4. 影響評估（商業影響 + 緊急度）
5. 推薦初動（3 項目檢查清單）
6. 追加調查（Sysdig MCP 深入調查建議）
7. 攻擊指標（IOC/IOA 分類 + Pyramid of Pain 級別）

ATT&CK 映射指南：與 18 種技術的檢測模式對應的表格。AI 將參考此表格，附上適當的技術 ID 至各個警報。

T1059  命令直譯器         ← sh/bash 執行
T1609  容器管理命令         ← kubectl exec
T1611  跳出到主機           ← /proc/1/root, nsenter
T1496  資源劫持             ← CPU 異常 + Stratum 協議
T1552  認證資訊竊取        ← /etc/shadow, ServiceAccount Token
...（全 18 種技術）

深入調查工作流程：對於 Critical/High 警報自動執行的雙階段調查。

第一階段: 資訊收集（MCP 6 工具鏈）
  sysdig_get_event_info → sysdig_get_event_process_tree
  → sysdig_run_sysql（同 Pod 1h） → sysdig_k8s_list_workloads
  → sysdig_k8s_list_pod_containers → CPU/記憶體分析

第二階段: Diamond Model 假設驗證
  H1: 正常運作 H2: 權限提升 H3: 外部入侵 H4: 自動化異常
  基於 Adversary/Infrastructure/Capability/Victim 軸分析各假設

自我進化的提示：特筆的是，AGENTS.md 中直接嵌入了「假陽性模式列表」。當操作員在警報線程中回覆「FP」時，AI 會自動提取該模式並新增至列表，隨著運行而變得更加智慧的系統。

為什麼是「檢測由 Sysdig 負責，分析由 AI 負責」？

「如果 AI 聰明，檢測也讓 AI 來做不是更好？」——這是合理的疑問。然而，檢測和分析所需的特性完全不同。

檢測所需的東西：Sysdig Secure 利用 eBPF 實時監控內核級的系統調用（過程執行、文件存取、網路通信）。當 Falco 規則符合時，瞬間觸發警報——毫秒級的即時反應和在相同輸入下總是返回相同結果的決定性重現性是其特點。

分析所需的東西：「這個警報真的危險嗎？」「多個警報是否有關聯？」「當觀看整個命令鏈時，哪些攻擊手法的組合？」——這類基於上下文的判斷正是 AI 發揮真實價值的領域。

這表示，Sysdig 捕捉了「發生了什麼」，而 AI 判斷「這意味著什麼」——這一角色分配正是 AI SOC 的設計原則。

這種分離在運作上也帶來了好處：

• 耐故障性：即使 AI 關閉，檢測依然持續進行，Slack 還是會持續發送警報
• 成本效率：讓 AI 處理所有系統調用是不現實的。在檢測時先進行過濾再交給 AI
• 可審計性：檢測規則具有確定性和可重複性。可以在事後檢查「為什麼會產生這個警報」

💡 實作提示：AGENTS.md 有 20000 字的上限，因此將運作規則本身（11052 字）與詳細步驟書 SOC-REFERENCE.md（25717 字）的內容分為 2 個檔案。即使是提示設計，也需要與「代碼的模組化分割」相同的發想。

實際運作：AI 在做什麼？

接下來，我們將查看實際運行中的 SOC 的具體輸出。僅僅談設計可能無法消除「真的能運行嗎？」的懷疑，因此展示一些真實的分流結果。

▲ 實際的 Slack #security-alerts 畫面：左側為警報列表，右側線程為 AI 的分流結果

實例：認證資訊探索警報的分流

在測試用 busybox 容器中執行 /etc/shadow 的讀取與憑證檔案的搜尋後，Sysdig 檢測到 尋找認證憑證 的警報。該警報發佈至 Slack #security-alerts 後，僅數秒內，OpenClaw 在線程中自動發佈以下分流結果：

## 🟠 Medium | T1649 + T1003 + T1083 | Pod: test-recon-blog (nuc2/default)

### 概要
在 busybox:latest 容器中執行了用於尋找、竊取認證資訊的複合偵察命令，且是以 root 權限執行。

### 執行命令鏈（⚠️ 重要）
sh -c cat /etc/shadow; find / -name "*.key" -o -name "*.pem" 2>/dev/null; whoami; exit 0

在單一 shell 中執行 3 階段的偵察：
  1. cat /etc/shadow → 竊取密碼雜湊 (T1003)
  2. find / -name *.key -o -name *.pem → 尋找憑證與私鑰 (T1649)
  3. whoami → 確認權限 (T1083)

### ATT&CK 映射
| 戰術              | 技術       | 根據                     |
|-------------------|-----------|--------------------------|
| Credential Access | T1649     | 尋找密鑰與憑證檔案        |
| Credential Access | T1003     | 讀取 /etc/shadow        |
| Discovery         | T1083     | 全系統檔案掃描           |
| Execution         | T1059     | 藉由 sh 執行複合命令     |

### 攻擊指標
- IOA: busybox + /etc/shadow + 憑證搜尋的組合（Pyramid of Pain: TTP 級別）
- IOC: proc.hash.sha256=786295... (查找二進位)
- IOC: Pod test-recon-blog / 映像 busybox:latest 在 default ns 中
### 推薦初動
- [ ] 即時刪除 Pod: kubectl delete pod test-recon-blog -n default
- [ ] 調查 Pod 的創建來源（kubectl get events / audit log）
- [ ] 檢查同一節點(nuc2)的相關事件

值得注意的幾點：

• 命令鏈的自動分解：AI 自動將單一的 sh -c 包含的 3 階段偵察分解，並為各自附上 ATT&CK 技術 ID
• Pyramid of Pain 的應用：不僅僅將其視為單一的哈希值（易於更改），而是將其分類為 TTP 級別（行為模式）——重點在於那些不易被攻擊者改變的指標
• 可行的推薦初動：甚至提供具體的 kubectl delete pod 指令

MCP 工具的連鎖調用

在上述的分流過程中，AI 在背後自動調用以下 Sysdig MCP 工具：

1. sysdig_get_event_info        → 獲取警報詳情
2. sysdig_list_runtime_events   → 搜尋同一 Pod 的相關事件
3. sysdig_get_event_process_tree → 可視化過程樹

對於一個警報，AI 連鎖調用了 3 個 MCP 工具，在生成分流結果前堆疊相關上下文。人類若要在 Sysdig 的儀表板上開啟同樣的信息收集工作，則需耗費數秒，AI 卻能在短時間內完成。

多個警報的相關分析

當同一 Pod 同時發生兩個警報（Terminal shell in container + Find Authentication credentials）時，AI 將自動執行 相關分析：

### 檢測規則
| 規則                             | 重要度 |
|----------------------------------|--------|
| Terminal shell in container      | Medium |
| Find Authentication credentials   | Medium |

這兩條規則在同一時間發生→ 在容器內先獲取 shell 後，再尋找認證資訊的模式（Kill Chain: Execution → Credential Access）

判定：根據 Pod 名稱中的 "test-recon" 模式及 kubernetes-admin 的即時刪除，認為此次行動為安全測試，但仍需確認創建者的意圖。

雖單獨視為 Medium 的警報，但通過多個警報的時間性和空間性相關的分析，AI 能呈現出攻擊鏈的全貌。

假陽性的自動學習

隨著運行，我們發現 node-exporter 定期會發出掃描 SUID/SGID 檔案的警報。操作員當在線程中回覆「FP」後：

未來將自動給予類似的警報添加 [FP候補] 標籤，逐步減少噪音。這是 運作中越來越聰明的 SOC。

5 階段 × 43 任務的實作

根據任務定義書，執行了 5 個階段及 43 個任務。

階段 1 的亮點：首次分流

在階段 1 時，最讓人感動的是 AI 對測試警報首次返回分流結果的瞬間。

當我們透過 kubectl run 在 busybox 容器中讀取 /etc/shadow 時，Sysdig 檢測到了該行為，並將警報發布至 Slack。幾秒後，OpenClaw 提交了結構化的分流結果：

• 嚴重度：High
• ATT&CK：T1003（作業系統憑證傾倒）/ T1609（容器管理命令）
• 影響範圍：default namespace 的 busybox Pod
• 推薦初動：Pod 的即時刪除、Pod 的創建來源調查...

原文出處：https://qiita.com/takao-shimizu/items/7cb1d8b48cd442e07962