剛開始使用 Stellar Cyber 做 SOC 工作時，我在首頁就看過攻擊鏈的畫面。
但當時，我完全不清楚它代表什麼，只把它當成平台上的統計資訊。

後來聽到「Kill Chain」這個名詞，我才主動查詢，開始理解攻擊鏈的基本概念。在後續查看 Alert、分析 Case 的過程中，我又逐漸加深認識，也開始理解它與 MITRE ATT&CK 的關係。

我的學習過程，大致就是先在工作中遇到不懂的東西，查資料建立初步理解，再透過使用慢慢補上認知。

Day 9 整理了 ATT&CK Mapping 如何幫助我們理解告警中的行為。這一篇，我想再往前走一步：

面對大量 Alert，我如何決定先看哪些，又如何透過 Case 理解它們之間的關係？

一、Kill Chain 與 ATT&CK，分別幫助我理解什麼？

先把兩個容易混在一起的概念分開。

Lockheed Martin 提出的 Cyber Kill Chain，將入侵活動整理成七個階段，協助防禦方理解攻擊過程，以及可能介入阻止的位置。

MITRE ATT&CK 則進一步整理攻擊者的戰術目的與具體行為。

我現在會用兩個問題幫助自己區分：

Kill Chain：這項活動可能位於攻擊過程的哪個階段？

ATT&CK：攻擊者可能想達成什麼目的，又使用了什麼方法？

不過，兩者不能直接一對一套用。

MITRE 官方說明，Cyber Kill Chain 使用有順序的階段描述較高層次的攻擊目標；ATT&CK 的 Tactic 則沒有固定順序，一次入侵也不一定會出現所有 Tactic。MITRE ATT&CK FAQ

因此，不能看到幾個 ATT&CK 標籤，就直接按照畫面位置串成完整攻擊流程。

另外，產品介面可能有自己的階段劃分與呈現方式。本文提到「攻擊鏈後段」時，指的是我使用 Stellar 時查看的區域，不直接把它等同於原始 Cyber Kill Chain 的某個固定階段。

二、理解概念後，我開始調整查看 Alert 的順序

實際工作中，我主要會看兩個地方：Alert 與 Case。

我通常先快速看過 Alert 名稱，留意有沒有看起來異常的內容，再查看 High、Critical 等級的告警，進一步了解是否有值得注意的整體行為。

後來，我也會優先查看平台歸在攻擊鏈較後段的 Alert。

對我來說，這一區的訊號更值得注意。我在這裡遇到的內容，比較像本機或內部疑似滲透活動，因此會優先花時間確認。

但這裡要區分兩件事：

優先查看，是我安排分析注意力的方式；它不代表我已經確認攻擊發展到了那個階段。

這也接續 Day 9 的觀念：Mapping 或分類可以幫助理解行為，但最後仍然要回到 Alert 實際提供的資料。

三、值得優先注意的區域，也有很多噪音

優先查看某一區，不代表那裡的每一筆 Alert 都需要採取處置。

在我的使用經驗裡，這一區比較常造成噪音的是 SMB 連線相關告警。

面對這些訊號，我會先觀察一段時間，再向客戶詢問正常使用的網段範圍，補上對環境的理解。接著，參考 Alert 顯示的資料傳輸量設定閾值，減少需要重複查閱的低傳輸量告警。

實際處理時，我用過兩種方式：

調整規則，讓部分符合條件的活動不再產生 Alert。

在畫面上篩選，隱藏/過濾掉特定的 Alert。

這兩種做法影響不同。畫面篩掉的告警仍可能存在；調整規則則會影響告警是否產生。

閾值也不是設定一次就結束。我會在調整後繼續觀察，再與客戶討論，反覆修改。

這段經驗承接了 Day 8 的噪音調校：環境裡哪些活動常見、哪些值得注意，需要持續確認。低於資料傳輸量閾值，只是篩選條件，本身不能證明活動安全。

我希望透過這些調整，減少重複查閱的負擔，讓注意力能留給需要進一步分析的訊號。

四、有了 Case，我為什麼還是先看 Alert？

Stellar 會把相關 Alert 整理到 Case 中，方便一起查看。

但我仍然會先看 Alert，因為我希望留意是否有值得注意、卻沒有出現在 Case 裡的訊號。

這是我的查閱習慣，不代表我已經證明平台漏掉了哪些事件，也不能保證自己看過就一定沒有遺漏。

對我而言，兩個畫面提供不同角度：

看 Alert 時，我先確認個別告警在說什麼；進入 Case 後，再看平台整理出的關係。

如果只停留在個別 Alert，很容易一直在看一筆又一筆的內容。Case 則提供了一個把相關資訊放在一起理解的入口。

五、Case 的圖示，讓關係更直觀

Case 對我最直接的幫助，是圖示。

透過圖示，我可以比較直觀地看到 IP 之間的連線、使用者帳號、外部來源，以及一些內部使用的程序。

原本分散在不同告警中的資訊，放在同一個畫面後，比較容易看出它們之間有哪些聯繫。

不過，Case 裡的 Alert 數量不一定少。依我的經驗，有時只有一兩筆，有時也可能到幾百筆。

即使平台已經整理好，我仍然會盡可能查閱其中的資訊，包括：

哪些 IP 之間有連線？

涉及哪個使用者帳號？

活動發生在什麼時間？

告警實際由什麼行為觸發？

圖示讓我比較容易找到需要查看的關係，但關係本身還需要解讀。

例如，同一台設備出現在多筆 Alert 裡，確實值得一起查看；至於這些活動是否屬於同一次攻擊，仍需要更多資訊支持。

六、看見關聯，距離理解完整事件還有一步

整理這篇文章時，我覺得需要特別區分「看見關聯」與「確認攻擊鏈」。

Case 把訊號放在一起，提供的是分析入口。要把它們描述成一段攻擊過程，還需要確認活動之間是否有足夠的連結。

這可以轉成幾個後續查證問題：

• 時間接近的活動，是否真的有前後關係？

• 相同 IP 背後，是否確實是同一台設備？

• 告警呈現的是連線嘗試，還是已經有其他活動證據？

• 是否可能有正常的業務或管理用途？

• 現有資料還缺少什麼？

這些是整理文章後歸納出的查證方向，不代表我已經在某次事件中完成所有檢查，或還原過一條完整攻擊鏈。

我目前能分享的，是自己如何利用 Alert、Case 與客戶提供的環境資訊，逐步理解活動。

客戶的回覆也很重要。平台可以提供觀察到的訊號，但設備用途、對外服務、允許的連線範圍，以及防護與更新情況，往往還需要向客戶確認。

有了這些背景，才能繼續討論後續如何處理。

七、從統計畫面，到分析時會使用的參考

回頭看，我最初只是把首頁的攻擊鏈當成統計資訊。

後來查詢 Kill Chain，讓我建立基本概念；接著在實際分析中，它開始影響我查看 Alert 的優先順序。

Case 則讓我更容易看到不同 IP、帳號與程序之間的關係。但我仍會查看個別告警，也需要透過觀察與客戶討論，理解環境中的正常活動。

這些經驗還不足以讓我宣稱，自己已經能完整還原攻擊鏈。但至少，我開始從「這裡有多少告警」，往「這些活動之間可能有什麼關係」繼續思考。

Day 7 提到，Alert 是調查起點，不是事件結論。

到了 Day 10，這個觀念仍然成立：

即使多筆 Alert 已經被整理成 Case，我們仍然需要確認，它們之間的關係究竟代表什麼。