1. 前言 — 為何「單一設備日誌」並不足夠 #

在安全日誌監控作業中，「某個 IP 位址是否可疑」的判斷，通常是各自獨立於個別設備的日誌來進行的。

• FW 掃描多個埠 → 封鎖
• Web 伺服器收到弱點掃描 → 警示
• VPN 認證多次失敗 → 帳號鎖定

每一台設備各自做出判斷。這是標準的維運方式。

然而，實際的攻擊往往更有組織性，是跨越多個層級、按照協同劇本運作的。

舉例來說，假設攻擊者依照以下順序嘗試入侵。

1. Reconnaissance via FW (port scan)           ← L1 Network Layer
2. Vulnerability scan on public web port       ← L4 Application Layer
3. Brute force against SSH or VPN              ← L3 Authentication Layer
4. After intrusion, lateral movement in internal network  ← L5 Endpoint Layer

如果各設備分別偵測，每個事件看起來都只是「稍微可疑的單一行為」而已。FW 團隊會認為「不過是又一次例行掃描」，Web 伺服器團隊會認為「不過是又一個掃描程式」，VPN 團隊會認為「又是一次暴力破解嘗試」，各自分別應對。

然而，這四項活動其實是同一名攻擊者連續的行動。若將其視為一個連續的劇本來看，應對的優先順序、封鎖範圍與警示等級都會大幅改變。

BASTION 的多層關聯活動偵測，正是「以單一 IP 為軸心，將多台設備各自的偵測結果跨時間、跨層級疊加」的機制。本文將排除我們已申請專利（2026 年）的數學公式部分，說明其設計理念與運作機制。

2. 「層級」的概念 — 從五種視角整理日誌 #

BASTION 將日誌整理為以下五個「層級」。

這種層級分類並非機械式的設備分類，而是對應「攻擊進展階段」的分類。L1 是偵察，L2 是路徑探索，L3 是認證突破，L4 是應用程式弱點，L5 則是內部活動。一般而言，攻擊的進展會沿著層級由低往高推進。

「某個攻擊 IP 在多個層級中都被觀測到」這一事實，正是「攻擊正在推進到下一階段」的強烈指標。

3. trace-registry — 依 IP 彙整跨層觀測狀態 #

在分析每台設備的日誌時，BASTION 會累積「這個 IP 何時、在哪個層級、被觀測了幾次」的資訊。這稱為 trace-registry。

其概念結構大致如下（實際數值僅為範例）。

{
  "traces": {
    "203.0.113.42": {
      "layers": {
        "L1_network": {
          "first_seen": "2026-05-10T13:01:23+09:00",
          "last_seen":  "2026-05-10T13:42:11+09:00",
          "count": 47,
          "context": ["FW block: port_scan", "FW block: ssh_attempt"]
        },
        "L4_app": {
          "first_seen": "2026-05-10T13:35:08+09:00",
          "last_seen":  "2026-05-10T13:41:55+09:00",
          "count": 12,
          "context": ["webserver 404: vuln_scan", "webserver 403: forbidden_path"]
        }
      },
      "layer_count": 2,
      "total_count": 59
    }
  }
}

此結構的重點在於它是依「層級」而非「設備」來彙整。若存在多台 FW，全部都會被視為 L1 網路層。反之，若單一伺服器同時輸出 Apache（L4）與 auditd（L5）日誌，則會被視為來自兩個層級的訊號。

此外，各層級的觀測結果會以能讓攻擊進展清晰可辨的粒度，沿著時間軸記錄下來。

4. Coherence 函數 — 將「跨層協同性」量化 #

接下來要談的是 BASTION 的核心部分。

「某個 IP 在多個層級中被觀測到」這件事本身尚不構成一次攻擊活動（campaign）。即便同時在 L1 與 L4 被觀測到，這兩者也有可能只是時間上各自獨立、彼此無關的行為。

因此，我們定義了一個以數值評估「跨層協同性」的函數，稱為 coherence 函數 C(i,t)。

此函數在概念上結合了以下四個要素。

1. 跨層耦合強度 — 哪些層級被同時觀測到
2. 時間鄰近度 — 觀測時機相隔多近
3. 觀測量的大小 — 各層級觀測到的程度（次數）
4. 時間衰減 — 較舊的觀測結果影響力會遞減

具體的數學形式（跨層耦合矩陣 K_ℓk、衰減率 γ、強度項 Φ 等）因已申請專利（2026 年）而不對外公開，但概念上其形式如下：

C(i,t) = function of "cross-layer coupling × temporal proximity × observation magnitude × temporal decay"

C(i,t) 的值介於 0 到 1 之間。數值越大，代表該 IP 的行為「跨層協同」的可能性越高。

5. 攻擊活動判定 — 超過閾值時自動採取行動 #

在計算出每個 IP 的 C(i,t) 之後，超過閾值者將被判定為「攻擊活動（campaign）正在進行中」。

此處重要的設計決策如下：

1. 判定為確定性（deterministic）：coherence 值是否超過閾值，是以機械式方式判定的。我們不依賴 LLM 的推論
2. 閾值可依環境調整：預設值是根據內部概念驗證所決定，但可依客戶環境進行微調
3. 判定理由具可解釋性：所有輸出都會顯示「哪些層級被觀測到幾次，因此判定為攻擊活動」

判定理由輸出範例（數值已遮蔽）：

[COHERENCE_CAMPAIGN] ip=203.0.113.42  C=███
  L1_network: count=███ first=████ last=████
  L4_app:     count=███ first=████ last=████
  reason: layer_count=2 + coherence > threshold

由於判定依據被明確揭示，維運人員可以自行確認觀測到的事實，在理解的基礎上核准自動化防禦，而不是單純信任 AI 的黑箱判斷。

6. 協同攻擊群組偵測 — 偵測「以群組形式呈現的協同性」 #

到目前為止，我們探討的是「單一 IP 是否跨層協同」。這本身已相當強大，但現實中的攻擊更為精密。

例如，利用雲端服務供應商上多個 IP 進行的有組織弱點掃描。單一 IP 各自的頻率過低，不足以超過活動偵測閾值，但若彙整整個子網或 ASN 範圍，其活動的組織性便一目瞭然。

因此，BASTION 具備「以群組為單位評估 IP」的機制。

• 依子網分組 — 同一 /24 內的 IP 群組被視為一個集合
• 依 ASN 分組 — 同一 ASN 內的 IP 群組被視為一個集合

針對每個群組，我們會計算群組 coherence（GC）。GC 是將各成員 IP 的 coherence 值彙總後，再乘上依群組規模而定的加成係數。

具體的數學形式同樣不對外公開，但概念很單純：

GC = Σ C(i,t) × boost(group_size)

由 10 個 IP 組成的群組，比由 3 個 IP 組成的群組更有可能是「有組織的攻擊」，因此會套用加成。

此機制稱為群組關聯偵測（協同攻擊群組偵測）。它以數學方式建模了「個別看來微小的訊號，若以群組視角觀察，可能具有重大意義」這樣的概念。

7. 實際維運偵測案例（匿名化） #

以下是我們內部正式環境中（截至 2026 年 5 月），由群組關聯偵測捕捉到的一個群組案例，其中 IP 與組織名稱已做遮蔽處理。

[GROUP_CAMPAIGN] type=asn group=AS█████  size=17  GC=███
  Member IPs: ████.██.██.███,  ████.███.██.██,  ███.███.███.███, ... (17 items)
  Observed layers: L1_network (FW block), L4_app (vuln scan)
  Time window: 24 hours
  Action: All 17 IPs auto-blocked across boundary FW + DMZ Agents

這是一起在 24 小時內，從某大型雲端服務供應商的 17 個 IP 觀測到跨 2 個層級（FW 掃描與 Web 弱點掃描）有組織活動的案例。每個個別 IP 的量都不足以觸發傳統 SIEM 的活動偵測，但以群組角度來看，其活動明顯具有意圖。

偵測完成後，這 17 個 IP 被同時傳播並封鎖於邊界 FW 及對外伺服器端的 DMZ Agent 群組中（層疊式防禦，詳情將另文說明）。

8. 與 SIEM／SOAR 的差異何在 #

傳統的 SIEM 或 SOAR，其實只要撰寫關聯規則，也能實現「彙整多台設備進行綜合判斷」。那麼差異究竟在哪裡？

最大的差異在於「能夠偵測未知場景」。SIEM 會漏掉未寫入規則的攻擊。而多層關聯檢視的是跨層協同性這種普遍性特徵，因此能適應新型攻擊手法。

9. 設計上的取捨 #

坦白說，這套機制存在幾項取捨。

1. 計算成本：對所有 IP 計算 C(i,t)，會隨著被觀測 IP 數量增加而拉長處理時間。BASTION 透過將計算範圍限制在 trace-registry 中記錄的近期活躍 IP 來緩解此問題。

2. 閾值調整：降低閾值會增加誤判，提高閾值則會增加漏判。這與環境有關，安全的做法是初期先設定得保守偏高，再依觀測情況逐步調低。

3. 已知 IP 的漏判：白名單中的 IP（自家伺服器、合作夥伴、CDN 等）必須排除在判定範圍之外。這是透過另一套機制來管理的。

4. 大型雲端 ASN 的特性：像 AWS 或 Microsoft 這類大規模 ASN，其中包含大量合法使用者。即使群組關聯偵測顯示群組規模龐大，也不應立即封鎖，而是透過 CAP（每個群組可封鎖 IP 數量上限）來安全地加以限制。

這些都在設計階段就已被認知，並已備有相應的對策。BASTION 的設計原則之一是「安全包絡（safety envelope）」 — 也就是無論何時，都內建有能在失控時實體限制損害範圍的機制。

10. 未來發展 #

多層關聯引擎本身已達到足夠成熟的運作水準，但仍有改善空間。

• 自適應閾值：透過學習環境正常水準來自動調整閾值（構想階段）
• 依時段調整靈敏度：在夜間與上班時段套用不同的靈敏度
• 擴展至其他維運領域：應用於安全以外的維運領域（品質、效能）（評估中）
• ASN 信任分數：根據過往行為計算各雲端 ASN 的信任程度

以上將依序實作。