寫到最後一天

回頭看這個系列，從一開始使用 GitHub Actions 蒐集威脅情資、寄送通知，到後來研究 CAPEv2 的惡意程式動態分析，再進入 Malcolm 的網路流量分析與原始碼研究，接觸的技術越來越多。

但工具研究得越多，我越覺得有一個問題值得在最後談清楚：

當系統發現一個可疑 IP、一個惡意程式樣本，或一筆 Suricata 告警時，接下來應該做什麼？

能夠收到通知，只代表我們取得了一條線索；能夠分析樣本，也不代表已經知道企業內部是否遭到影響。真正困難的工作，是把不同來源的證據連結起來，確認事件發生的原因、影響範圍，以及接下來應該採取什麼行動。

這也是我希望透過這 30 天，逐步建立起來的觀念。

一、先回頭看：這個平台究竟要解決什麼問題？

最初的想法，是希望將原本需要人工查看的資安資訊，整理成可以自動蒐集、判斷及通知的流程。

例如，資安團隊每天可能會接觸到漏洞公告、惡意 IP、可疑網域、惡意程式分析報告等資訊。若全部依賴人工閱讀，很容易耗費時間，也不容易持續追蹤相同的威脅是否再次出現。

因此，系列一開始從 GitHub Actions 著手，嘗試建立自動化蒐集、資料整理、狀態保存與郵件通知的流程。

接著，我把研究範圍延伸到 CAPEv2。原因很簡單：知道某個檔案可疑，和知道它實際執行時做了什麼，是兩件不同的事。

再往下研究 Malcolm，則是因為即使我們已經知道某個樣本的行為，還是需要回答另一個問題：

企業內部的網路上，究竟有沒有出現相關活動？

這三個方向對應到不同的工作需求。

這些工具各自有明確的用途，但安裝完成並不代表整套平台就已經具備完整的自動化能力。

例如，GitHub Actions 蒐集到的 IOC，不會因為系統裡同時安裝了 CAPEv2，就自動送進沙箱分析；CAPEv2 產生的 PCAP，也不會因為 Malcolm 已經啟動，就必然自動進入網路分析流程。

中間仍然需要資料交換、介面整合、格式轉換、工作排程，以及必要的錯誤處理。

這是研究完整架構時，不能跳過的一個現實。

二、用一個事件，把前面研究的技術串起來

假設某天，資安團隊收到一則威脅情報，指出某個可疑程式可能與特定外部網域有關。

同一天，企業內部的一位使用者也回報，電腦執行某個下載檔案後，出現不尋常的網路活動。

我們先不要假設這兩件事一定有關，而是思考：如果要調查這個案例，前面研究的工具分別能提供什麼幫助？

1. 從威脅情報開始，但不要直接把情報當成結論

首先，透過既有的情資收集程序，取得來源公告、可疑網域、IP 位址、檔案雜湊值，以及相關的發布時間與說明。

這時候的重點不是把每一筆 IOC 都直接放進封鎖清單，而是先保留資訊的來源及背景。

例如，一筆 IP 情資可能來自數天前的惡意活動報告。到了今天，該 IP 是否仍由同一個惡意服務使用？它是否與共用主機、CDN 或其他正常服務有關？這些問題都需要進一步確認。

情資蒐集程式應該盡可能保留原始來源、觀察時間、取得時間及資料狀態，避免只留下單一 IP 或網域，最後卻無法追溯判斷依據。

對這個階段而言，情資的價值是提供調查方向，而不是代替調查。

2. 利用 CAPEv2 觀察可疑樣本的實際行為

假設企業取得了使用者下載的檔案，且經初步判斷，需要進一步分析。

在確認檔案適合進行沙箱分析後，可以將樣本送入 CAPEv2 的隔離環境，觀察它在執行期間產生的活動。

調查人員可能關注的資訊包括程序行為、檔案異動、相關設定資料，以及樣本嘗試建立的網路連線。

分析完成後，CAPEv2 可能產生行為報告、擷取檔案、相關 IOC，以及分析期間記錄的 PCAP 等資料；實際結果取決於樣本行為、沙箱設定與分析是否成功。

這裡需要特別注意，沙箱觀察到的活動不一定能完整呈現所有行為。有些樣本可能因為環境檢查、反沙箱機制或執行條件不符而沒有觸發預期行為。

因此，沒有觀察到可疑活動，不代表樣本一定安全。

另外，若要將 CAPEv2 的 PCAP 交給 Malcolm 分析，仍需要確認檔案的保存位置、匯入程序與相應設定。這是整合時需要另外處理的環節，不是兩套工具原生就會自動完成的工作。

3. 回到 Malcolm，確認網路上是否存在相關活動

有了初步情資與樣本分析結果後，下一步是確認企業網路是否曾出現相關通訊。

這時候，Malcolm 就能發揮作用。

如果情資指出某個網域或 IP 值得關注，調查人員可以利用 Malcolm 搜尋已保存的網路資料，檢查相關位址是否曾出現在 DNS 查詢、連線紀錄或其他協定活動中。

不同元件提供的資訊也有所不同。

Zeek 可以提供 DNS、連線及其他協定紀錄，協助建立網路活動的時間線；Suricata 可以提供符合偵測規則的告警；Arkime 則能用來搜尋相關工作階段，並在封包資料可用時進一步檢查通訊內容。

OpenSearch Dashboards 適合用來搜尋、篩選與觀察整體資料，Filebeat 與 Logstash 則負責資料的收集、處理及傳遞。

假設調查人員發現，企業內某台工作站在使用者回報問題的時間附近，確實曾與情資中的網域建立連線。這會增加兩者存在關聯的可能性，但仍不足以單獨證明該工作站遭到感染。

接下來，還需要比對目的 IP、連線時間、協定細節、樣本分析結果，以及端點上是否有相關程序或檔案活動。

如果找不到相關網路紀錄，也不能直接認定事件沒有發生。資料可能已經超出保存期限，流量可能沒有經過感測器，或者相關行為發生在其他網路區段。

網路資料能告訴我們觀察到了什麼，但不能保證所有行為都被完整觀察到。

4. 將網路證據與端點資料交叉比對

如果網路紀錄顯示可疑活動，調查就不應停在 Malcolm 的搜尋結果。

接著應查看端點 EDR、Windows 事件日誌、程序執行紀錄，以及企業能取得的其他相關證據，確認哪個程序建立連線、是否有檔案被執行，以及是否出現其他異常活動。

如果有證據顯示同一個樣本、網域與特定工作站之間存在可驗證的關聯，就能逐步建立事件時間線。

例如：

以上是方便說明調查方法的模擬時間線，不是真實事件紀錄。

而且，若這些時間來自不同系統，還必須先確認時區、時間同步與事件時間的定義，才能判斷先後關係。不同資料若存在時間偏差，很容易導致錯誤的事件重建。

調查的目的，是將每個判斷建立在可追溯的證據之上，而不是把時間接近的紀錄直接當成因果關係。

三、工具接起來還不夠，真正困難的是資料與責任的交接

前面的案例看起來很完整，但如果真的要將這些步驟實作成自動化平台，還有不少工作要處理。

首先是資料格式。情資、沙箱報告、PCAP、Zeek 日誌及 Suricata 告警都有不同的資料結構。如果沒有明確的欄位定義、識別方式與交換機制，後續便很難進行可靠的關聯分析。

其次是資料生命週期。IP、網域與檔案雜湊值的有效性並不相同。有些情資只在特定時間內具有參考價值，因此必須保留來源、時間與狀態，並設計去重、更新及過期處理機制。

第三是執行失敗的處理。樣本可能無法啟動，分析程序可能逾時，網路資料也可能因為感測器或資料管線異常而不完整。若自動化流程只設計成功路徑，就很容易把「沒有取得結果」誤認為「沒有發現威脅」。

最後是權限與安全控制。CAPE 分析環境必須妥善隔離；可疑檔案不能因為要自動分析，就任意移到一般工作環境執行；封鎖 IP、隔離端點或修改防火牆規則等操作，也應有明確的授權與審核機制。

我認為，一套可維護的整合平台至少要把下列事情定義清楚：

這些事情不像安裝工具那樣容易展示成果，卻會直接影響系統在正式環境中是否可靠。

四、AI Agent 可以參與哪些工作？哪些事情仍然不能交給它自行決定？

這個系列也談過 AI Agent。對威脅情資與鑑識平台而言，我認為 AI 最有價值的地方，是協助調查人員減少整理資訊與重複查詢的時間。

例如，當系統發現一筆可疑連線時，Agent 可以在授權範圍內查詢相關紀錄，整理時間線，比對已有的情資與樣本分析報告，最後產生一份包含證據來源、尚待確認事項及建議調查方向的摘要。

它也可以協助生成查詢條件、檢查資料是否存在缺漏，或針對不同元件的輸出整理可供分析師閱讀的報告。

但這不代表 AI 的判斷可以直接取代證據。

如果 Agent 發現某個 IP 出現在威脅情資中，就直接封鎖企業內所有相關連線，可能影響正常業務；如果僅因為沒有查到告警，就認為主機安全，也可能忽略資料可見性不足的問題。

因此，我會把 AI Agent 定位為調查與決策的輔助工具，而不是不受限制的自動應變執行者。

尤其在端點隔離、帳號停用、封鎖網路連線等可能影響業務的操作上，應根據風險、權限及事件應變政策決定是否需要人工核准。

自動化的目標不是讓系統在沒有人參與的情況下做最多事情，而是讓每一次需要人員判斷時，都已經準備好足夠的資料與清楚的依據。

五、最後一天的心得：完成的不是工具清單，而是理解一條調查流程

回頭看這個系列，我從情資蒐集開始，接觸了 GitHub Actions、CAPEv2、Malcolm，以及它們所涉及的資料處理與分析工具。

這段過程讓我更清楚地認識到，資安平台不是把幾套開源軟體安裝在同一台主機上就完成了。真正需要設計的，是資料從哪裡來、經過哪些處理、能支持什麼判斷，以及判斷之後該如何採取行動。

威脅情資提供線索，CAPEv2 協助觀察可疑樣本的行為，Malcolm 提供網路側的分析與調查能力，端點資料則能補足網路紀錄無法回答的問題。這些證據相互補充，但每一種資料都有自己的限制。

至於整套平台是否已經達到全自動運作，還必須看資料交換、工作排程、失敗處理、結果驗證及應變控制是否真正完成。這些不能單靠元件清單來證明。

對我而言，這 30 天最大的收穫，不是記住了多少工具名稱或設定檔，而是開始用一條完整的調查流程思考問題：先取得線索，再驗證行為，接著確認實際影響，最後才決定怎麼處理。

如果未來要繼續把這套架構往企業實務推進，我會優先選擇一個明確的使用情境，先讓情資、樣本、網路紀錄與調查結果能夠可靠地交換，再逐步增加自動化能力，而不是一開始就追求所有元件都能互相呼叫。

畢竟，對資安團隊而言，最重要的不是有多少工具可以使用，而是當真正的事件發生時，我們能不能根據可靠的證據，知道發生了什麼、影響了誰，以及接下來應該做什麼。

這就是我想透過這個系列留下的重點：自動化的終點，不是讓工具彼此連線，而是讓調查更有依據，讓每一個決策都更容易被驗證。

系列文章回顧

如果想回頭了解這個系列，可以從以下幾篇開始：

1. Day 01：由 GitHub Actions 開始——從威脅情資蒐集、資料整理到自動化通知，建立整個系列的起點。

2. Day 10：什麼是 CAPEv2——認識惡意程式動態分析，以及如何從樣本取得行為與鑑識線索。

3. Dynamic Incident Response: A Framework for Security Teams——理解資安事件調查如何根據新證據反覆調整方向，而不是只按照固定步驟執行。

4. AI Agent 已從「被動回答」進入「長時間自主工作」——延伸思考 AI Agent 如何參與多步驟任務，以及自動化過程中的人工監督與風險控制。

5. Day 21：認識 Malcolm——理解 Malcolm 作為網路流量分析平台的定位，以及它如何整合不同開源元件。

6. Day 22：Malcolm Components 架構——掌握 Zeek、Suricata、Arkime、OpenSearch 等元件的分工與整體架構。

7. Day 26：Malcolm 的 Arkime 到底在做什麼——從網路 Session 搜尋深入封包檢視，理解網路鑑識的實際調查方式。

8. Day 27：Malcolm Filebeat 如何整合 Zeek、Suricata 與系統日誌——從原始碼了解日誌收集、資料處理及下游管線的整合方式。