前面幾天，我陸續談到了 SIEM、EDR、NDR、Threat Intelligence，以及 Deception。

但這些工具最終都會碰到同一個問題：

當 Alert 出現之後，SOC 到底要怎麼判斷？

實際在 SOC 工作時，不可能看到一筆 Alert 就直接認定：

「攻擊發生了。」

同樣也不能因為 SIEM 把事件標成 Low Risk，就認為它不重要。

Alert 對我來說比較像是一個起點。

它告訴我：

這裡可能有東西需要注意，接下來才是分析人員真正開始工作的地方。

Alert 很多，我會先決定「哪一個先看」

SIEM 每天可能收到大量 Log，再從裡面產生不同類型的 Alert。

所以第一個問題通常不是：

「我要不要調查？」

而是：

「我要先調查哪一個？」

我自己會先從風險程度開始排序。

例如單筆 Alert 本身已經被判定為 High Risk，我通常會優先查看。

另外一種情況，是 SIEM 已經把多個相關事件進行整合，形成一個整體風險較高的事件或 Case，這種我也會優先處理。

所以最開始可以先簡單理解成：

大量 Alert -> Risk Level -> 高風險優先 -> 進入事件分析

但這裡有一個很重要的地方：

Risk Level 是我決定調查順序的參考，不是最後的事件判斷。

High Risk，不代表一定是攻擊

當我開始看一筆 Alert 時，我還是會回到前面文章提過的資訊。

例如：

• Alert Name
• Source IP
• Destination IP
• Source / Destination Port
• 發生時間
• 帳號
• 目標設備
• 連線次數
• 設備用途

假設 SIEM 今天產生一筆 High Risk Alert，但我實際看完之後，發現這個行為有可能是正常的。

我不會只因為 SIEM 說 High，就直接告訴客戶：

「你被攻擊了。」

我會把目前看到的證據以及我覺得有疑問的地方整理出來，再向客戶進行二次確認。

因為 SOC 看得到資安設備與 Log，卻不一定知道客戶所有的業務情境。

例如某個帳號突然登入 Server。

從 SOC 的角度來看可能很可疑，但客戶可能告訴我：

「今天晚上正在進行系統維護。」

確認之後，這筆事件的意義就完全不同。

如果最後確認屬於正常行為，接下來也不是只有把 Alert 關掉而已。

還可以進一步思考：

這個行為未來還會不會一直產生相同 Alert？

如果會，就要再評估 Rule 是否需要調整，或針對特定條件建立適當的 Exception / Whitelist。

Low Risk，也不代表可以不管

反過來也是一樣。

假設 SIEM 今天只把一個事件判斷成 Low 或 Medium Risk。

但我看到：

03:00 AM
某個帳號 -> 登入 -> AD / DC

這時候我不會因為畫面上寫著 Medium，就直接把它放到後面。

因為「凌晨登入」本身就可能偏離正常使用情境。

如果又牽涉到重要 Server、AD/DC、特殊帳號或其他異常行為，我就會提高它的調查優先度。

接著再詢問客戶：

這個時間真的有人在操作嗎？

有沒有排程？

有沒有維護作業？

這也是我認為 SOC 分析跟單純看 SIEM Dashboard 最大的差異之一。

系統可以提供 Risk Score，但分析人員還是必須加入 Context（情境）。

所以實際上的判斷比較接近：

SIEM Risk Score
      +
發生時間
      +
帳號
      +
資產重要性
      +
行為是否合理
      ↓
實際調查優先度

一筆 Alert，跟一個 Incident 並不是完全相同的事情

另外一個在 SOC 裡很重要的問題，是不能永遠只看單一 Alert。

假設同一台 Client 在凌晨出現：

01:03  → 掃描多台 Server TCP 445
01:05  → 出現 TCP 3389 相關行為
01:08  → AD/DC 出現相關登入紀錄

從系統角度來看，這可能還是三筆不同的 Alert。

每一筆也都有自己的風險等級與規則。

但對分析人員來說，如果這些事件發生時間非常接近，我就會開始把它們放在同一個事件脈絡裡一起看。

因為我要確認：

這些事情只是剛好同時發生，還是彼此之間真的存在關聯？

這裡也要特別注意。

不能因為：

「時間很接近」

就直接寫成：

「這是一條完整的攻擊鏈。」

因為中間仍然存在不確定性。

甚至 Source IP 不同，也不能單純依靠這一點就認定事件一定無關。

有些可能只是正常的網路活動，也可能正在進行探勘，還需要其他證據才能繼續判斷。

所以我比較會把它理解成：

SOC 不是看到幾個相似 Alert 就把它們拼成攻擊鏈，而是先找到可能的關聯，再利用其他證據確認或排除。

證據越多，事件的可信度也會改變

這時候就會進入另一個我很重視的地方：

有多少不同的證據正在支持同一件事情？

例如 Threat Intelligence 告訴我：

Source IP：A.A.A.A
Reputation：Malicious

這當然值得注意。

但只有這個資訊時，我還不會直接認定這個 IP 已經成功攻擊環境。

如果接下來又看到：

Threat Intelligence
→ IP 被標記為 Malicious

NDR
→ 發現該 IP 正在掃描多台設備

Firewall
→ 確實存在該 IP 的連線紀錄

這時候事件的可信度就開始提高了。

因為已經不是只有單一資料來源告訴我：

「這個 IP 可能有問題。」

而是不同的資料來源，都開始提供支持這個判斷的證據。

這也是為什麼 SOC 需要 SIEM、Firewall、EDR、NDR 等不同來源的資訊。

並不是因為：

「工具越多越安全。」

而是當事件真的發生時，我們可以從不同角度取得證據，再把它們交叉比對。

不一定要等攻擊成功，我才通知客戶

有些人可能會認為：

是不是一定要確認攻擊成功，SOC 才能通知客戶？

以我的實務經驗來說，我不會這樣做。

如果目前的證據已經讓我覺得行為可疑，我就會先通知客戶並詢問。

原因有兩個。

第一個是確認：

這是不是正常業務行為？

因為 SOC 不一定掌握所有客戶端的 Context，詢問本身也是調查的一部分。

第二個則是：

如果它真的有問題，可以提早進行防範。

如果一定要等到：

主機被入侵
↓
權限被取得
↓
橫向移動
↓
資料被加密

全部發生完才通知，那 SOC 的價值就只剩下告訴客戶：

「剛剛發生了一件事情。」

所以對我來說，SOC 的工作不只是事後證明攻擊成立。

在證據還沒有完全確定，但風險已經值得注意時提出預警，也是一件重要的事情。

客戶確認異常之後，事情才真正進入下一階段

假設我把事件提供給客戶，而客戶回覆：

「這不是我們的人做的。」

這時候事件的性質就改變了。

原本：

「可能是正常行為嗎？」

這個疑問已經被排除了一部分。

接下來就要開始考慮實際處置。

依照事件狀況，可能包含：

封鎖惡意 IP
       ↓
隔離受影響設備
       ↓
避免事件繼續擴散
       ↓
保留相關 Log / EDR / 系統資料
       ↓
後續事件調查與數位鑑識

但這裡有一件事情很容易被忽略：

處理事件的同時，也要保留證據。

如果發現設備有問題後，第一件事情就是把所有東西刪掉、重灌、清除 Log，雖然設備可能恢復了，但後面想知道：

攻擊者到底怎麼進來？

做過哪些事情？

還有哪些設備受到影響？

可能就沒有足夠的資料可以調查。

所以事件處置除了 Containment（圍堵），還要考慮 Evidence Preservation（證據保全），為後續的事件還原或 Digital Forensics 保留必要資料。

Alert 只是 SOC 工作的起點

如果把今天整個流程整理起來，我會把它理解成：

所以現在如果再問我：

SOC 分析人員看到 Alert 之後在做什麼？

我的答案不會只是：

「看 Alert，然後通知客戶。」

真正的工作其實是在不同程度的不確定性中，不斷利用 Risk、Context、Correlation 與 Evidence 去縮小可能性。

有時候最後證明只是正常行為。

有時候則是在攻擊還沒有造成更大影響以前，就找到值得注意的跡象。

因此我現在會把 Alert 看成：

Alert 不是事件的答案，而是一個需要開始驗證的問題。

而 SOC 分析人員真正要做的，就是想辦法找到足夠的證據，回答這個問題。