在前面的實作中，我們已經逐步完成 BehaviorGuard 的 Process Monitor、Detection Engine、Correlation Engine、Alert Logger 與 Alert Summary。

目前 BehaviorGuard 已經能夠讀取 Kali Linux 的程序資訊，透過自訂的偵測規則判斷可疑行為，並將 Alert 儲存成 JSONL 日誌。

不過，到目前為止，我們的系統主要還是以 Detection（偵測）為主。

當系統發現可疑行為時，只會產生警告並保存紀錄，並不會進一步決定該如何處理。

但在真實的資安環境中，光是發現攻擊還不夠，還需要思考：

當系統發現可疑行為時，應該採取什麼回應措施？

因此，Day20 我們正式開始實作 BehaviorGuard 的 Response Engine（事件回應引擎）。

今天先從最基本的 Dry Run 模式開始，讓系統根據 Alert 的風險等級產生建議的回應動作，但不會真正終止程序或封鎖網路。

一、什麼是 Incident Response？

Incident Response（資安事件回應）是指組織發現資安事件後，進行分析、控制影響、排除威脅及恢復正常運作的過程。

例如，某台企業電腦突然執行可疑程式，並且嘗試連線到陌生的外部伺服器。

資安監控系統可能會先產生 Alert，接著由資安人員確認事件是否真的具有威脅。

如果確認有風險，就可能採取以下措施：

1. Process Termination（終止程序）：停止正在執行的可疑程序。
2. Host Isolation（主機隔離）：限制受影響主機的網路通訊，降低威脅擴散的可能性。
3. Block IP（封鎖 IP）：阻止與特定可疑 IP 的通訊。
4. Further Investigation（進一步調查）：蒐集更多證據，確認事件是否真的具有威脅。

但這些措施並不是任何情況都適合直接執行。

例如，假設系統把正常的資料庫服務誤判為惡意程序，如果自動將它終止，就可能造成企業服務中斷。

因此，在實際執行 Response 前，需要考慮誤判、風險、程序身分以及可能造成的影響。

二、什麼是 Dry Run？

Dry Run 可以理解成「模擬執行」。

意思是系統會判斷應該執行什麼動作，但不會真的執行。

例如：

BehaviorGuard 發現 HIGH Alert
          ↓
Response Engine
          ↓
判斷建議動作
          ↓
Recommend process termination
          ↓
Mode: DRY RUN
          ↓
Executed: False

這代表系統建議終止程序，但實際上沒有執行終止動作。

為什麼需要 Dry Run？

因為我們目前的 Detection Rule 還在持續開發與測試，不能保證每個 Alert 都是真正的惡意行為。

例如，之前建立的 BG-CMD-002 會偵測：

python3 -c 'print("Hello")'

這種指令可能被攻擊者利用，但也可能只是開發人員正常測試 Python 程式。

如果只要偵測到就直接終止程序，就很容易發生 False Positive（誤判）造成的問題。

因此，今天先採用 Dry Run，確認 Response Engine 的判斷邏輯是否正確。

三、建立 Response Engine

首先進入 BehaviorGuard 專案：

cd ~/behaviorguard

建立 Response Engine：

nano response/engine.py

加入以下程式碼：

# BehaviorGuard Day20
# Response Engine - Dry Run

def handle_alert(alert):

    rule = alert.get("rule", "UNKNOWN")
    severity = alert.get("severity", "UNKNOWN").upper()
    pid = alert.get("pid", "N/A")

    print("\n========== BehaviorGuard Response ==========")
    print(f"Rule       : {rule}")
    print(f"Severity   : {severity}")
    print(f"PID        : {pid}")

    # 根據風險等級決定建議動作
    if severity == "CRITICAL":
        action = "Recommend host isolation"

    elif severity == "HIGH":
        action = "Recommend process termination"

    elif severity == "MEDIUM":
        action = "Recommend further investigation"

    else:
        action = "Monitor only"

    print(f"Action     : {action}")
    print("Mode       : DRY RUN")
    print("Executed   : False")
    print("============================================\n")

程式碼說明

1. 取得 Alert 的基本資訊

rule = alert.get("rule", "UNKNOWN")
severity = alert.get("severity", "UNKNOWN").upper()
pid = alert.get("pid", "N/A")

這裡利用 Python 字典的 get() 方法取得資料。

如果 Alert 沒有提供特定欄位，就使用預設值，避免因為缺少欄位而直接發生 KeyError。

其中 .upper() 會把文字轉成大寫，讓程式能以一致的格式判斷風險等級。

2. 根據 Severity 選擇回應動作

這次建立了四種基本回應策略：

這樣的設計稱為 Rule-Based Response（規則式回應）。

也就是系統根據事先設定的條件，選擇對應的處理方式。

不過，這只是初步的回應建議。未來如果要真正自動終止程序或隔離主機，仍然需要增加其他判斷條件，而不能單純依照 Severity 就執行。

3. 使用 Dry Run 避免實際執行

print("Mode       : DRY RUN")
print("Executed   : False")

今天的 Response Engine 只有選擇動作與顯示結果的功能，並沒有加入 os.kill()、防火牆修改或其他真正改變系統狀態的操作。

因此，測試不會真的終止程序或隔離主機。

四、實際測試 Response Engine

完成程式後，我們分別使用 MEDIUM、HIGH 和 CRITICAL 三種風險等級進行測試。

測試一：MEDIUM Alert

首先模擬之前建立的 BG-CMD-002 規則。

PYTHONPATH=. python3 -c '
from response.engine import handle_alert

handle_alert({
    "rule": "BG-CMD-002",
    "severity": "MEDIUM",
    "pid": 1234
})
'

實際執行結果：

========== BehaviorGuard Response ==========
Rule       : BG-CMD-002
Severity   : MEDIUM
PID        : 1234
Action     : Recommend further investigation
Mode       : DRY RUN
Executed   : False
============================================

BehaviorGuard 成功將 MEDIUM 等級的 Alert 對應到「建議進一步調查」。

因為 MEDIUM 通常還需要更多證據才能判斷是否有實際威脅，所以目前不建議直接執行破壞性處置。

測試二：HIGH Alert

接著模擬 BG-PROC-001 規則，也就是之前建立的 Web Shell 相關程序偵測規則。

使用以下測試資料：

{
    "rule": "BG-PROC-001",
    "severity": "HIGH",
    "pid": 5678
}

實際執行結果：

========== BehaviorGuard Response ==========
Rule       : BG-PROC-001
Severity   : HIGH
PID        : 5678
Action     : Recommend process termination
Mode       : DRY RUN
Executed   : False
============================================

這次系統正確判斷 HIGH 等級，並產生「建議終止程序」的回應。

不過，PID 5678 只是測試資料，系統並沒有真的嘗試終止該程序。

測試三：CRITICAL Alert

最後測試 CRITICAL 等級。

這次使用之前 Correlation Engine 建立的 BG-CORR-005 規則作為模擬案例。

{
    "rule": "BG-CORR-005",
    "severity": "CRITICAL",
    "pid": 9999
}

實際執行結果：

========== BehaviorGuard Response ==========
Rule       : BG-CORR-005
Severity   : CRITICAL
PID        : 9999
Action     : Recommend host isolation
Mode       : DRY RUN
Executed   : False
============================================

可以看到系統成功辨識 CRITICAL 等級，並提出主機隔離的建議。

Host Isolation 的目的是限制受影響主機的網路通訊，避免可能的攻擊進一步擴散。

不過，在實際企業環境中，主機隔離可能影響遠端管理及正常服務，因此需要更完整的授權、例外處理與復原機制。

五、今天的測試結果

經過三次測試，Response Engine 都成功產生對應的回應建議。

三次測試都顯示：

Mode       : DRY RUN
Executed   : False

代表我們成功完成基本的回應策略判斷，而且沒有對 Kali Linux 進行實際處置。

需要特別說明的是，今天使用的是人工建立的測試 Alert，目的是驗證 Response Engine 的判斷邏輯。

目前尚未將 Response Engine 自動串接到真正的 Detection Engine，因此今天並不是完整的即時自動回應測試。

六、今天學到的資安觀念

今天最重要的觀念是 Detection 與 Response 的差別。

Detection 是發現問題，Response 則是決定如何處理問題。

例如：

Detection
發現可疑 Python 程序
       ↓
Alert
產生風險警告
       ↓
Response
判斷是否需要調查或處置

另外，也了解到 False Positive 對 Response 的影響。

在偵測系統中，誤判可能只是多出一筆不必要的 Alert。

但在自動回應系統中，誤判可能導致正常程序被終止，甚至造成主機與網路服務中斷。

因此，自動化 Response 必須比單純的 Detection 更謹慎。

除了 Severity，未來還應該考慮程序是否屬於重要服務、是否存在多個相關警告，以及是否需要人工確認等條件。

七、今日心得

Day20 是 BehaviorGuard 專案的一個重要進展。

在前面幾天，我們花了很多時間建立 Detection Rule、Correlation Engine 與日誌紀錄功能。

雖然已經可以發現可疑行為，但我一直希望 BehaviorGuard 不只是顯示警告，而是能夠進一步協助資安人員決定該如何處理。

因此，今天正式建立了 Response Engine 的第一個版本。

這次實作讓我了解到，事件回應並不是簡單地把可疑程序關掉，而是需要考慮事件的嚴重程度、誤判風險，以及回應動作可能造成的影響。

透過 Dry Run，我們可以先驗證回應策略是否符合預期，再逐步評估是否適合加入真正的自動處置功能。

目前的 Response Engine 仍然很基礎，只會根據 Severity 顯示建議動作，還沒有串接真實的 Detection Alert，也沒有完整的回應條件判斷。

不過，至少我們已經開始從單純的 Detection，逐步朝向 Detection + Response 發展。

下一篇 Day21，我們將把 Response Engine 接入真正的 Process Monitor，讓 BehaviorGuard 偵測到可疑程序後，可以自動產生對應的 Response 建議，同時繼續保留 Dry Run 模式，確保測試安全。