在 Day18，我們成功把 Alert Logger 接入 Detection Engine，讓 BehaviorGuard 偵測到可疑程序後，可以自動將警告儲存到 JSONL 檔案。

目前 BehaviorGuard 已經能夠讀取 Kali Linux 的程序資訊，並根據事先建立的偵測規則產生 Alert。

不過，當警告數量越來越多時，就會遇到另一個問題：

如果系統一天產生幾百筆甚至幾千筆 Alert，資安人員難道要一筆一筆查看嗎？

因此，Day19 我們要建立 Alert Summary（警告摘要），讓 BehaviorGuard 可以自動統計不同風險等級的 Alert 數量。

一、什麼是 Alert Aggregation？

Alert Aggregation（警告彙整）是將大量安全警告依照特定條件分類或統計，讓資安人員能夠快速掌握整體安全狀況。

例如，一台主機可能出現以下事件：

• Python 直接執行命令列程式碼。
• 程序建立異常的網路連線。
• 重要系統檔案遭到修改。
• 可疑程序嘗試建立持久化機制。

如果每一筆 Alert 都需要人工查看，資安人員的工作負擔就會非常大。

因此，可以先根據風險等級進行統計。

常見的 Severity（風險等級）包括：

不過，Severity 並不代表一定發生攻擊，而是偵測規則對事件給予的風險判斷。

例如 python3 -c 雖然可能被攻擊者用來執行惡意程式碼，但也經常被正常的開發人員使用，因此不能只因為出現這個指令，就直接判定主機遭到入侵。

二、今天的實作目標

今天的功能不需要修改 Detection Engine，而是直接讀取之前保存的日誌。

整個流程如下：

Kali Linux
     ↓
Process Monitor
     ↓
Detection Engine
     ↓
產生 Alert
     ↓
Alert Logger
     ↓
logs/alerts.jsonl
     ↓
Alert Summary
     ↓
統計 Severity 數量

這次的重點是將原本一筆一筆的警告，整理成更容易閱讀的統計資訊。

三、建立 Alert Summary

首先進入 BehaviorGuard 專案：

cd ~/behaviorguard

建立新的 Python 檔案：

nano agent/alert_summary.py

加入以下程式碼：

import json
from collections import Counter
from pathlib import Path

# 自動找到 BehaviorGuard 專案目錄
BASE_DIR = Path(__file__).resolve().parent.parent
LOG_PATH = BASE_DIR / "logs" / "alerts.jsonl"


def main():
    if not LOG_PATH.exists():
        print("[INFO] No alert log found.")
        return

    severity_count = Counter()
    total = 0

    with open(LOG_PATH, "r", encoding="utf-8") as f:
        for line in f:
            try:
                alert = json.loads(line)
            except json.JSONDecodeError:
                continue

            if not isinstance(alert, dict):
                continue

            severity = str(
                alert.get("severity", "UNKNOWN")
            ).upper()

            severity_count[severity] += 1
            total += 1

    print("\n========== BehaviorGuard Alert Summary ==========")
    print(f"Total Alerts : {total}")
    print("-----------------------------------------------")

    for severity in ["CRITICAL", "HIGH", "MEDIUM", "LOW"]:
        print(f"{severity:8} : {severity_count[severity]}")

    if severity_count["UNKNOWN"]:
        print(f"UNKNOWN  : {severity_count['UNKNOWN']}")

    print("================================================\n")


if __name__ == "__main__":
    main()

程式碼說明

1. 使用 JSON 讀取日誌

alert = json.loads(line)

由於我們之前將 Alert 儲存成 JSONL 格式，每一行都是獨立的 JSON 物件，因此可以逐行讀取資料。

2. 使用 Counter 統計數量

from collections import Counter

Counter 是 Python 提供的計數工具，可以計算不同項目出現的次數。

例如：

MEDIUM
MEDIUM
HIGH
MEDIUM

經過 Counter 統計後：

MEDIUM : 3
HIGH   : 1

這樣就不需要自己建立複雜的計數邏輯。

3. 使用 pathlib 處理檔案路徑

BASE_DIR = Path(__file__).resolve().parent.parent

之前 Day18 曾經遇到 Terminal 工作目錄不同，導致找不到日誌檔案的問題。

這次改成利用程式檔案的位置尋找專案目錄，降低相對路徑造成的影響。

四、實際測試結果

完成程式後，在 Kali Linux 執行：

python3 agent/alert_summary.py

這次實際取得的結果：

========== BehaviorGuard Alert Summary ==========
Total Alerts : 3
-----------------------------------------------
CRITICAL : 0
HIGH     : 0
MEDIUM   : 3
LOW      : 0
================================================

代表目前日誌共有三筆 Alert，而且全部都屬於 MEDIUM 等級。

這三筆紀錄包括 Day17 手動建立的一筆測試 Alert，以及 Day18 兩次真正由 Process Monitor 偵測到的 Python 程序警告。

Day18 曾經偵測到：

Rule      : BG-CMD-002
Name      : Python Inline Code Execution
Severity  : MEDIUM
Process   : python3
Parent    : zsh

當時系統執行：

python3 -c 'import time; print("Day18 Test"); time.sleep(5)'

BehaviorGuard 成功辨識出符合 BG-CMD-002 規則的行為，並將警告保存至 JSONL。

而今天的 Alert Summary 就是讀取這些紀錄，再進行統計。

需要注意，目前的統計包含測試資料，而且只是計算 Alert 數量，還沒有進行重複警告合併或事件去重。

五、BehaviorGuard 真的有讀取 Linux 系統嗎？

在這幾天的實作中，我也重新確認了一件事情：

BehaviorGuard 是真正讀取 Kali Linux 系統的資訊，還是只是在分析我們自己製造的假資料？

答案是，目前的 Process Monitor 確實會讀取 Kali Linux 的實際程序資訊。

我們在之前的程式中使用：

status_path = f"/proc/{pid}/status"
cmdline_path = f"/proc/{pid}/cmdline"
exe_path = f"/proc/{pid}/exe"

Linux 的 /proc 是一種虛擬檔案系統，裡面提供核心與程序相關資訊。

例如：

透過這些資訊，我們可以知道目前 Linux 系統有哪些程序正在執行，以及它們的父子關係。

例如，Day18 真正偵測到的程序：

PID       : 2515396
PPID      : 2515322
Process   : python3
Parent    : zsh
Ancestors : [2515322, 2515306, 2515300, 1]

這些 PID 與 PPID 是從當時的 Kali Linux 程序資訊取得，而不是我們自己手動填入的。

不過，目前 BehaviorGuard 是在 Kali Linux 虛擬機中執行，因此監控範圍主要是該 Linux 環境，並沒有直接監控 Mac 主機上的程序。

此外，目前採用每秒掃描一次的方式，仍可能漏掉存活時間非常短的程序。

六、今日心得

今天的實作讓我了解到，資安監控系統除了 Detection（偵測）之外，也需要能夠整理與分析大量的事件資料。

之前我們一直在建立不同的偵測規則，希望 BehaviorGuard 能夠發現更多可疑行為。

但是隨著 Alert 越來越多，如果沒有適當的統計與分類功能，資安人員反而很難快速掌握系統狀況。

透過今天的 Alert Summary，我們已經可以直接讀取 JSONL 日誌，並依照 Severity 統計不同風險等級的數量。

另外，今天也更清楚了解目前 BehaviorGuard 的運作方式。

它並不是完全依靠模擬資料，而是已經可以透過 Linux /proc 取得真實程序資訊，再交由 Detection Engine 進行分析。

當然，目前仍然只是初階的端點監控系統，距離真正企業使用的 EDR 還有許多功能需要完善，例如更完整的事件收集、誤判控制、集中式日誌管理，以及自動化事件回應。

下一篇 Day20，我們將開始建立 Response Engine，讓 BehaviorGuard 不只是發現可疑行為，也能根據不同風險等級提出對應的回應動作。

初期會先採用 Dry Run（模擬執行）方式，不直接終止程序或封鎖連線，避免因為誤判而影響系統正常運作。