終於來到最後一天！
回頭看 Day1，當時的 BehaviorGuard 只是一支簡單的 Python 程式，負責讀取 Linux 系統中正在執行的 Process（程序）。
我們透過 /proc 收集 PID、PPID、UID、Command 等資訊，試著了解一台 Linux 主機目前正在執行什麼。
經過 30 天的開發，BehaviorGuard 已經逐步加入 Process、Network、File、Persistence 等行為偵測能力，也建立了 Correlation Engine（事件關聯引擎）、Response Policy（回應政策）、受控環境的自動化回應，以及 Security Dashboard（資安監控儀表板）。
這次鐵人賽，我最初的目標就不只是製作一套 IDS（入侵偵測系統）。
因為我認為真正的資安防禦，不應該只停留在「發現可疑行為」。
更重要的是：
系統發現可疑行為後，能不能理解事件之間的關係？能不能正確評估風險？又能不能在安全的條件下採取回應？
這也是我為什麼將專案命名為 BehaviorGuard。
今天這篇文章，我會回顧整個開發過程，整理已經完成的功能、實際測試結果與尚未解決的限制，作為這 30 天的最終總結。
BehaviorGuard 是一套以 Python 開發、運作於 Linux 環境的實驗性 EDR（Endpoint Detection and Response，端點偵測與回應）原型。
這裡先解釋三個名詞。
Endpoint 指的是企業或組織網路中的裝置。
例如員工電腦、伺服器、虛擬機器等。
這些裝置可能成為攻擊者入侵的目標，因此我們需要監控裝置上的活動。
BehaviorGuard 目前主要針對 Linux 主機，觀察程序執行、網路連線與檔案異動等資訊。
Detection 是利用收集到的事件，判斷是否符合特定可疑行為。
例如：
kunyo
Web Server 啟動 Shell
↓
BG-PROC-001
↓
HIGH Alert
或者：
Python 使用 -c 執行程式碼
↓
BG-CMD-002
↓
MEDIUM Alert
這些事件本身不一定都是攻擊，但可能值得進一步調查。
Response 是系統在發現可疑行為後採取的處理方式。
例如記錄告警、建議人工調查、要求審核，或在明確授權的實驗環境中終止測試程序、暫時封鎖測試 IP。
因此，BehaviorGuard 的核心概念是：
收集行為 → 偵測異常 → 關聯證據 → 決定回應 → 保留稽核紀錄。
目前我們整合出的系統架構如下：
Linux Endpoint
│
BehaviorGuard Agent
│
┌───────────────┼──────────────┐
│ │ │
Process Monitor Network Monitor File Monitor
│ │ │
└───────────────┼──────────────┘
│
Detection Engine
│
Detection Rules
│
Alert Event
│
Event Pipeline
│
Event ID / Timestamp
│
┌──────────────┴──────────────┐
│ │
Alert Logger Correlation Engine
│ │
│ Correlation Alert
│ │
└──────────────┬──────────────┘
│
Response Dispatcher
│
Response Policy
│
┌─────────────┴─────────────┐
│ │
DRY_RUN / Controlled Lab
REVIEW_REQUIRED Response
│ │
└─────────────┬─────────────┘
│
Response Audit
│
JSONL Log Storage
│
Flask API
│
Security Dashboard
其中我認為最重要的設計，就是把每個功能拆成不同模組，再透過共同的 Event Pipeline 整合。
因為實際的資安事件可能同時涉及程序、網路和檔案活動，如果這些模組彼此獨立，就很難分析完整的事件經過。
Day1 時，我們使用 Python 讀取 Linux 的 /proc 目錄。
在 Linux 中，每一個程序都有對應的 PID（Process ID，程序識別碼）。
而 PPID（Parent Process ID）則代表建立該程序的父程序。
例如：
systemd
│
└── sshd
│
└── bash
│
└── python3
透過 PID 與 PPID，我們可以理解程序之間的父子關係。
一開始，我們收集的資訊包括：
{
"pid": 1234,
"ppid": 1000,
"uid": 1000,
"name": "python3",
"command": "python3 -c ...",
"executable": "/usr/bin/python3"
}
其中 Command 特別重要。
因為單純看到 python3，不能代表使用者正在做什麼。
但是如果看到：
python3 -c 'print("Hello")'
就能知道 Python 是直接從命令列接收程式碼執行。
這也是我們後來建立 BG-CMD-002 的基礎。
隨著開發進度推進，我們逐漸加入不同的 Process 和 Command 規則。
例如：
| Rule ID | 偵測行為 | 風險 |
|---|---|---|
| BG-PROC-001 | Web Server 啟動 Shell | HIGH |
| BG-CMD-001 | curl/wget 下載內容後直接交給 Shell 執行 | HIGH |
| BG-CMD-002 | Python Inline Code Execution | MEDIUM |
其中 BG-CMD-001 是典型的可疑命令模式：
curl https://example.com/script.sh | bash
這種寫法會把下載的內容直接交給 Shell 執行。
不過必須注意，這裡只是在說明命令形式，並不代表所有使用這種方式的行為一定是惡意攻擊。
真正的資安分析仍然需要考慮執行來源、使用者、程序關係與其他證據。
EDR 不是只看 Process Name，而是要了解程序執行時的上下文。
同一個 bash 或 python3，在不同情境下可能代表完全不同的行為。
完成 Process Monitor 後，我們開始分析 Linux 主機上的 TCP 網路連線。
這裡主要使用 ss 取得 Socket 資訊，再整理出對應的程序與連線狀態。
例如：
Process : socat
PID : 2942453
State : LISTEN
Local : 127.0.0.1:19999
這代表有一個 socat 程序在本機 Port 19999 等待連線。
我們建立的網路規則包括：
| Rule ID | 偵測行為 |
|---|---|
| BG-NET-001 | Suspicious Network Listener |
| BG-NET-002 | Suspicious Connection |
| BG-NET-003 | Unexpected External Connection |
Network Monitor 除了觀察 IP、Port、State，也會收集程序資訊，盡可能將網路活動與程序上下文串在一起。
這與只觀察封包的 NIDS（Network Intrusion Detection System）有所不同。
NIDS 主要從網路流量角度觀察通訊；端點監控則有機會知道是哪一個本機程序建立了連線。
當然，BehaviorGuard 目前的 Network Monitor 仍有能力限制，不能直接與成熟的 NIDS 或企業級 EDR 相提並論。
開發到 Day28 時，我們發現一個問題。
原本 Network Monitor 會持續記住曾經看過的連線特徵，可能造成記憶體累積，也可能讓重新出現的事件被忽略。
因此我們新增 NetworkStateTracker，比較前後兩次輪詢的結果：
new_keys = current - self.active
disappeared = self.active - current
這樣可以辨識新出現與消失的連線。
我們使用 socat 進行真實測試，兩次啟動相同 Port，分別成功觸發 BG-NET-001。
這證明新的 Listener 程序能再次被觀察，而不是永遠被舊有告警狀態抑制。
接著我們開始監控 Linux 的檔案異動。
File Monitor 使用 Python Watchdog 接收檔案系統事件，例如：
CREATED
MODIFIED
DELETED
MOVED
除了檔案路徑，我們也加入更多檔案資訊：
其中 SHA256 是一種雜湊演算法，可以把檔案內容轉換成固定長度的摘要。
它不是用來加密檔案，而是用來協助辨識檔案內容是否改變。
| Rule ID | 偵測行為 |
|---|---|
| BG-FILE-001 | Sensitive File Modification |
| BG-FILE-002 | Sensitive File Deletion |
| BG-FILE-003 | Suspicious Script Creation |
| BG-FILE-004 | Hidden File Creation |
| BG-FILE-005 | Executable Permission Added |
例如，當系統在暫存位置發現新的 .sh 檔案時，可能觸發：
BG-FILE-003
Suspicious Script Creation
Severity: MEDIUM
Persistence（持久化）是指攻擊者設法讓程式在重新登入、重新開機或其他特定條件下，仍有機會繼續執行。
Linux 常見的持久化位置包括：
/etc/crontab
/etc/cron.d/
~/.bashrc
~/.ssh/authorized_keys
/etc/systemd/system/
BehaviorGuard 因此加入 Cron、systemd、Shell Profile 與 SSH Authorized Keys 等相關偵測規則。
不過，這些位置原本就是 Linux 的正常管理機制。
例如管理員新增 Cron Job 並不一定是惡意行為，所以我們仍然需要搭配其他證據進行分析。
另外，專案主要使用 /tmp/behaviorguard_test 建立隔離測試目錄，模擬系統檔案結構，避免為了測試而直接修改真實系統設定。
我認為整個 BehaviorGuard 專案最有特色的功能，就是 Correlation Engine。
因為攻擊行為通常不會只包含單一動作。
例如一個可疑流程可能包括：
執行 Python 程式
↓
建立 Shell Script
↓
修改 Cron 設定
↓
等待後續自動執行
如果每個行為都只產生獨立告警，分析人員需要自己整理事件之間的關係。
因此我們開始開發 Correlation Engine，希望系統能協助找出可能相關的事件。
這條規則用來關聯 Python Inline Code Execution 與外部網路連線活動。
概念是：
BG-CMD-002
+
BG-NET-003
↓
BG-CORR-002
透過時間窗口等條件，系統可以辨識值得進一步分析的組合。
後續我們加入 Process Lineage（程序血緣關係）的概念。
除了單純比較事件時間，也考慮程序的父子與祖先關係，讓關聯判斷有更多上下文。
例如：
Python Execution
↓
Interpreter Network Activity
↓
Unexpected External Connection
↓
BG-CORR-005
在後續開發中，我們進一步建立 BG-CORR-006，整合 Process、File 與 Persistence 三種事件。
其中最關鍵的條件包括：
例如：
BG-CMD-002
Python Inline Execution
│
▼
BG-FILE-003
Suspicious Script Creation
│
▼
BG-PERSIST-001
Cron Persistence
│
▼
BG-CORR-006
Multi-Source Correlation
後來我們也針對不同 UID、不同路徑與重複事件等情況進行測試，避免只要三種 Alert 同時出現就直接判斷為同一條攻擊鏈。
這裡是我特別想強調的一點。
Correlation 代表系統找到相關的證據，不代表已經證明攻擊確實發生。
例如兩個程序在相近時間執行，並不一定代表它們具有直接的因果關係。
因此，Correlation 的目的應該是協助調查、提高可疑行為的可見性，而不是取代所有人工判斷。
一開始規劃專案時，我就希望 BehaviorGuard 不要只有 Detection。
因此我們逐步建立 Response Engine、Dispatcher、Policy 與 Audit Logger。
不過，真正執行 Response 並不是看到 HIGH Alert 就直接終止程序。
因為一旦規則誤判，就可能造成正常服務中斷。
因此目前的 Response 設計分成兩種情境。
對一般即時監控事件，系統主要採用：
Alert
↓
Response Policy
↓
DRY_RUN
↓
REVIEW_REQUIRED / INVESTIGATE
↓
Audit Log
其中 DRY_RUN 的意思是記錄或模擬回應決策，不直接執行該項破壞性動作。
例如我們曾經觸發：
BG-NET-001
Suspicious Network Listener
Severity: HIGH
系統回傳：
Action : BLOCK
Decision : DRY_RUN
Executed : False
這代表一般 Live Alert 沒有直接執行封鎖。
但我們也希望能驗證真正的自動化回應機制，因此另外設計受控實驗入口。
目前已完成過的測試包括：
這些功能都有額外限制，例如檢查測試程序的 PID、執行命令與啟動時間，或將網路封鎖限定在特定測試 IP。
不過，Controlled Lab 仍然會產生真實系統動作，因此不能只因為一般 Live Alert 顯示 DRY_RUN，就認為所有情況都不會進行實際處置。
不論最後有沒有執行實際動作，都應保留：
Event ID
Rule
Action
Status
Target
Reason
Timestamp
這樣才能知道系統為什麼做出某個回應決策，並在後續調查時追溯。
我認為這是 Response Engine 和單純寫一行 kill 指令最大的差別。
隨著功能增加，我們開始面臨一個問題：
Process、Network、File 各自能產生 Alert，但如果它們使用不同方式記錄或處理事件，就很難建立完整的調查流程。
因此我們建立共同的 Event Pipeline。
主要功能包括：
Detection Alert
↓
產生 Event ID
↓
寫入 Alert Log
↓
Correlation Engine
↓
Response Dispatcher
↓
寫入 Response Audit
其中 Event ID 是重要的關聯欄位。
例如：
Alert Event ID:
69d62374-bdac-4e94-8abb-5252ff19bfdb
對應的 Response 紀錄會使用相同的 Event ID。
在進入 Day29 Dashboard 前，我們執行了一次真實的 File End-to-End 測試。
測試方式是在隔離目錄建立新的 Shell Script，不執行腳本內容。
結果成功觸發：
BG-FILE-003
Suspicious Script Creation
Severity: MEDIUM
接著系統完成：
Detection
↓
Event Pipeline
↓
Alert Logger
↓
Response Dispatcher
↓
Response Audit
最後透過程式驗證，Alert 與 Response 使用相同 Event ID。
實際檢查結果包括：
[PASS] Real File Detection
[PASS] Unified Event Pipeline
[PASS] Alert written to JSONL
[PASS] Matching Response written to JSONL
這證明 File Detection 到 Response Audit 的真實流程已經成功運作。
另外，過去的日誌中也存在實際的 Correlation 告警及對應來源事件。
但是這不代表所有模組都已經在同一次測試中完成完整端到端驗收，因此仍然需要保留測試範圍上的區別。
Day28 時，我們沒有繼續增加偵測規則，而是回頭檢查系統的可靠性。
這次最重要的發現，是 Process Monitor 可能漏掉短暫程序。
目前 Process Monitor 主要採用 Polling（輪詢）收集 /proc 資訊。
例如每隔一秒掃描一次。
如果某個程序只執行 0.1 秒，就可能剛好在兩次掃描之間啟動並結束。
因此，即使 Detection Rule 完全正確，也可能沒有事件可供分析。
我們比較每秒掃描一次，以及每 0.2 秒掃描一次的程序觀察率。
每組測試 15 次，結果如下：
| 程序存活時間 | 1.0 秒輪詢 | 0.2 秒輪詢 |
|---|---|---|
| 0.1 秒 | 0% | 53.3% |
| 0.3 秒 | 20% | 100% |
| 0.5 秒 | 46.7% | 100% |
| 1.0 秒 | 100% | 100% |
從結果可以發現，縮短輪詢間隔後，短暫程序的觀察率確實有所提升。
但即使縮短到 0.2 秒，0.1 秒程序仍然可能被漏掉。
需要特別說明的是，這次 Benchmark 是使用獨立的 psutil 掃描程式，測量程序觀察能力，並不是完整 BehaviorGuard 的 Detection Rule 告警率。
此外，增加輪詢頻率可能提高 CPU 和系統呼叫負載，但我們尚未完成正式的資源消耗比較。
Detection Rule 再完整，如果 Telemetry（遙測資料）沒有收集到事件，後面的分析就沒有辦法運作。
這也是我們未來需要研究 Linux Audit、eBPF 等事件式監控技術的原因。
在前面完成主要後端架構後，我們開始思考：
如果一般使用者不熟悉 Linux Terminal，要怎麼快速查看 BehaviorGuard 的告警？
因此 Day29 使用 Flask、HTML、CSS 和 JavaScript 建立 Security Dashboard。
BehaviorGuard Agent
↓
Detection / Correlation / Response
↓
alerts.jsonl / responses.jsonl
↓
Flask API
↓
JavaScript
↓
Security Dashboard
目前 Dashboard 會讀取真實 JSONL 日誌，呈現告警統計、風險分布、事件來源、告警清單與 Response 紀錄。
在 Day29 的測試畫面中，我們成功讀取：
| 項目 | 數量 |
|---|---|
| Total Alerts | 36 |
| Critical | 0 |
| High | 14 |
| Medium | 22 |
| Correlations | 3 |
| Response Records | 63 |
這些資料不是手動寫死，而是來自 BehaviorGuard 先前產生的日誌。
除了統計資料，我們也加入 Alert Investigation（告警調查）功能。
例如點擊 BG-CORR-006，就能查看該事件的 Event ID、風險等級、相關證據，以及三筆來源事件：
BG-CMD-002
↓
BG-FILE-003
↓
BG-PERSIST-001
↓
BG-CORR-006
同一個調查畫面也成功顯示：
AUTO_POLICY → DRY_RUN
RESPONSE_DECISION → REVIEW_REQUIRED
後來我們進一步把 Dashboard 改成多個功能頁面，並加入右側 Drawer 調查面板、搜尋篩選與定期更新的程式碼。
目前新版首頁已成功顯示，但新版本的選單操作、Drawer 和每 5 秒自動更新仍需要完成完整的互動驗收。
因此，這部分屬於已完成實作、部分功能已驗證的階段。
回顧整個專案，大致可以分成以下幾個階段。
| 開發階段 | 主要內容 |
|---|---|
| Day1～4 | Linux Process 收集、程序資訊與初步偵測 |
| Day5～6 | Command Detection 與可疑執行行為 |
| Day7～8 | Network Monitor 與網路偵測規則 |
| Day9～11 | File Monitor、檔案事件與 SHA256 |
| Day12 | Persistence Detection |
| Day13～14 | Correlation Engine 與 Process Lineage |
| Day15～16 | 開發環境整理、Continuous Process Monitor |
| Day17～24 | 逐步完善事件關聯、Response 與系統整合 |
| Day25～26 | Unified Event Pipeline、Response Policy、受控回應 |
| Day27 | Multi-Source Correlation 與 Unified Agent |
| Day28 | Reliability、去重、Graceful Shutdown 與 Benchmark |
| Day29 | Flask Security Dashboard 與 Alert Investigation |
| Day30 | 最終成果整理、驗收狀態與專案總結 |
這 30 天不只是把幾個 Python 檔案寫出來，而是逐步把不同功能整合成一套具有基本 EDR 架構的系統。
整理前面已完成的測試，我們可以得到目前的功能狀態：
| 功能 | 測試成果 |
|---|---|
| Process Monitor | 成功偵測 Python Inline Execution |
| Network Monitor | 成功偵測本機可疑 Listener |
| File Monitor | 成功偵測檔案建立與修改 |
| Persistence Detection | 成功觸發 Cron 與 Shell Profile 規則 |
| Correlation Engine | 已完成多項關聯規則測試 |
| Multi-Source Correlation | BG-CORR-006 已產生實際關聯事件 |
| Event Pipeline | 真實 File E2E 測試通過 |
| Response Policy | DRY_RUN 與受控條件測試通過 |
| Controlled Lab Response | 已有終止測試程序與暫時封鎖測試 IP 的成功紀錄 |
| Alert Deduplication | 已完成規則及 Watchdog 測試 |
| Graceful Shutdown | 三個監控器正常關閉 |
| Network State Tracker | 新的 Listener 可再次觸發偵測 |
| Configurable File Watch | 已在指定測試目錄接收事件 |
| Configurable Process Polling | 設定驗證及獨立 Benchmark 完成 |
| Flask API | 成功讀取真實日誌 |
| Dashboard Overview | 已在瀏覽器實測 |
| Correlation Investigation | 已成功顯示來源事件及 Response |
| Dashboard 新版互動功能 | 已實作，仍待完整驗收 |
這些測試讓我們有一定的證據說明 BehaviorGuard 的主要架構已經整合。
但我們仍不能將它宣稱為通過所有測試的正式商用 EDR。
尤其在資安領域，測試通過代表特定條件下功能正確，不代表其他環境或所有攻擊情境也一定正確。
完成這 30 天後，我認為誠實說明系統限制，比一味宣稱功能完整更重要。
目前 Process 和 Network Monitor 仍主要依賴週期性掃描。
如果程序或網路連線存在時間非常短，可能完全落在兩次掃描之間。
未來可以研究 Audit 或 eBPF 等事件來源，改善短暫活動的可見性。
目前的規則主要針對特定可疑行為模式。
例如 Python Inline Execution、可疑 Listener、Cron Persistence 等。
真正的企業環境中，攻擊技術非常多樣，還需要更多規則、行為基準與誤報控制。
而且某些規則可能偵測到正常的管理操作，因此不能單靠單一 Alert 就直接判斷為入侵。
目前我們已經使用 UID、路徑、時間窗口與部分程序關係進行關聯。
但這些證據還不等於完整的因果追蹤。
例如兩個程序使用同一個檔案路徑，不一定代表它們具有直接的攻擊關係。
未來可以加入更完整的程序建立事件、檔案操作來源和跨程序因果資訊。
目前一般 Live Alert 主要採取 DRY_RUN 和人工審核建議。
受控實驗環境則可以執行事先限制的回應。
但真正企業級 Response 還需要處理權限管理、動作審批、回復機制、錯誤處理與業務影響等問題。
例如暫時封鎖 IP 後，除了封鎖元素到期，也需要確認相關防火牆資源能正確清理。
目前 Dashboard 使用 Flask 開發伺服器，僅綁定本機 127.0.0.1。
還沒有完整的登入、角色權限、HTTPS 部署與正式的 API 存取控制。
此外，Dashboard 目前主要呈現日誌，不具備完整 Agent Heartbeat、集中式資料庫或跨主機管理能力。
我們驗證了正常啟動、事件處理與 Graceful Shutdown。
但尚未完成數小時甚至數天的連續運作測試，也沒有證明大量程序與網路連線同時存在時，系統仍能保持穩定。
這也是未來需要補強的工程工作。
雖然 30 天鐵人賽結束，但 BehaviorGuard 還有不少可以延伸的方向。
研究 Linux Audit 或 eBPF，降低 Polling 對短暫程序的漏報問題。
加入更多程序、網路、檔案與 Persistence 行為規則，並建立可重現的測試資料集。
讓 Correlation 不只依靠時間和路徑，也能利用完整 Process Tree、事件因果關係與跨來源證據進行分析。
建立更嚴格的授權、審核、回復與稽核流程，讓自動回應可以逐步從實驗環境走向更真實的部署場景。
目前 Agent 和 Dashboard 主要在同一台 Kali VM 中運作。
未來可以考慮：
Linux Endpoint A ─┐
│
Linux Endpoint B ─┼── Central Server
│ │
Linux Endpoint C ─┘ ▼
Security Dashboard
讓多台端點把事件傳送到中央伺服器，再統一分析和管理。
這時就必須認真處理 HTTPS、API Authentication、存取權限與傳輸完整性等安全問題。
目前 BehaviorGuard 的 Detection Engine 主要是規則式偵測。
未來也可以研究使用機器學習分析程序行為、網路連線頻率、命令執行特徵等資料，協助發現原本規則沒有明確定義的異常模式。
但機器學習並不代表一定比規則式偵測更好。
模型仍然需要足夠的資料、正確標籤、誤報評估與可解釋性，才能對資安分析產生實際幫助。
回頭看這 30 天，我覺得自己最大的收穫，不是學會了多少 Python 語法，而是開始理解一套資安系統為什麼需要不同模組，以及這些模組要如何合作。
一開始，我對 PID、PPID、UID、Shell、Process Tree 等 Linux 基礎概念並不熟悉。
當時只是透過 /proc 取得程序資料，甚至不太明白這些資訊到底可以拿來做什麼。
但隨著規則增加，我開始理解：
PID 可以用來識別程序，PPID 可以協助追蹤父子關係，而 Command、UID 和 Executable 則能提供程序執行時的上下文。
後來加入 Network Monitor，我開始把 IP、Port、Socket State 和 Process 連在一起。
加入 File Monitor 後，我又學到檔案權限、SHA256、隱藏檔案和系統敏感路徑的概念。
而 Correlation Engine 則讓我明白，真正的資安事件往往不是單一行為，而是多個事件組合而成。
這 30 天有不少時間花在修改程式、處理模組整合問題，以及確認測試到底有沒有成功。
例如 Day28 的 Benchmark，第一次竟然得到全部 100% 的程序觀察率。
一開始看起來非常成功，但後來才發現測試程式本身的等待方式有問題，導致掃描頻率完全不符合原本的設定。
修正後，我們才真正量測出短暫程序可能被漏掉的現象。
這件事讓我印象很深刻。
因為它提醒我：
不能只是看到程式顯示 PASS，就認為系統真的沒有問題。
我們還需要確認測試方法、測試範圍和測試資料是否合理。
另一個重要的收穫，是理解 Response 的風險。
一開始我覺得，既然系統能發現惡意程序，那就應該自動終止它。
但實際設計後才發現，如果告警本身是誤判，直接終止程序可能造成正常服務中斷。
因此我們才逐步加入 Policy、DRY_RUN、Controlled Lab 和 Audit Log。
這讓我開始理解，好的資安防禦不一定是動作越快、越激烈就越好。
更重要的是有沒有足夠證據、是否符合授權，以及能不能追溯和回復。
Day29 建立 Dashboard 後，我第一次能夠直接在瀏覽器看到自己前面完成的功能。
從告警數量、風險分類，到 BG-CORR-006 的三筆關聯事件，以及對應的 Response Decision，都能透過畫面查看。
這讓我覺得整個專案終於不再只是散落在不同資料夾裡的 Python 程式，而是逐步形成一套能展示架構與實際成果的資安系統。
30 天前，我從一支最基本的 Linux Process Monitor 開始。
30 天後，我們已經做出一套具有以下能力的實驗性 Linux EDR 原型：
Process Monitoring、Network Monitoring、File Monitoring、Persistence Detection、Correlation Analysis、Response Policy、Controlled Lab Response、Audit Logging，以及 Security Dashboard。
當然，BehaviorGuard 還不是一套可以直接部署到企業環境的成熟 EDR。
它仍然有 Polling 漏報、偵測覆蓋率不足、進階因果分析有限、Response 安全控制需要持續完善，以及 Dashboard 尚未產品化等問題。
但對我來說，這 30 天最重要的不是把系統做得多麼完美，而是透過實際開發，開始理解一套 EDR 系統從資料收集、行為偵測、事件關聯到回應稽核的完整流程。
我也學到，資安工程不只是找到攻擊，而是要確認資料可靠、判斷合理、回應安全，並且能讓分析人員理解整個事件經過。
最後，很高興自己能夠完成這次 30 天鐵人賽。
感謝閱讀這系列文章的每一位讀者！
BehaviorGuard 的 30 天挑戰到這裡告一段落，但這個專案不會只停留在 Day30。未來我希望持續完善它，讓它成為自己學習藍隊資安、EDR 與事件回應技術的重要作品。
Day30 完賽，BehaviorGuard 持續進化！
iThome鐵人賽
看影片追技術