今天來繼續分享之前的經驗了

如果回到五年前，如果問我甚麼 SOC 或者 SOAR 最重要的是甚麼?
我可能會把答案的核心放在 SIEM 上。

Log 有沒有正常收進來？Parser 有沒有正確解析？Rule 有沒有觸發？Alert 有沒有產生？不同設備的資料能不能整合進同一個平台？
這些問題，到現在依然很重要，也依舊是碰到的部分。

從五年前的甚麼都不知道，從一開始負責產品建置、日誌收集，到後來陸續做事件分析、自動化處理、IR、SOC 維運，甚至開始參與團隊管理之後，我對「SOC」這件事情的理解，其實已經跟一開始不太一樣了。

現在如果再問我一次，我的答案可能會不太一樣。一個合格的 SOC，我覺得已經不能只看它一天可以產生多少 Alert，而是這麼龐大的資訊進來之後，我們到底能不能從裡面找出真正需要處理的事件，並且知道接下來該怎麼做。

而在這整個過程中，SIEM 就是其中很重要的一個工具。

一開始，我最在意的是「資料有沒有進來」，因為沒有資料也就不能表示系統的功能。
剛開始接觸 SIEM 時，我的工作很自然地會圍繞在「系統」本身。
一套 SIEM 要能運作，第一件事情當然是要有資料。
Firewall、EDR、Proxy、Windows、Linux，以及環境裡各種不同的設備，都可能產生大量 Log。
所以很多時間其實都花在：

• Log Source 有沒有正常送資料？
• SIEM 有沒有收到？
• 格式能不能正確解析？
• 欄位 Mapping 對不對？
• 不同設備之間的資訊能不能關聯？
• Sensor、Collector 或其他元件有沒有正常運作？
  雖然這些都是很基礎的東西，但是往往都是這些基礎的東西能夠提供證據，查詢到哪邊被攻擊甚至是可以反推到源頭的重要證據。
  至於我碰到的產品是一個叫做 stellar cyber 的產品，對於當初的我，最重要的目標往往是"資料有沒有都有收到"以及"哪邊還有資料可以收集"這兩件事情上。

Log 收得越多，就代表看得越完整嗎？
做了一段時間之後，會思考真的甚麼都收集就表示可以有更全面的資料嗎?
雖然跟客戶當然是要說是，但是站在 SOC Analyst 的角度來看，事情沒有那麼單純。

假設今天的環境如下:
Firewall
│
EDR ──────┐
│ │
Proxy ────┼──→ SIEM ──→ Alert
│ │
Server ───┤
│ │
Network ──┘

所有資料都進來了。
SIEM 一天產生幾百、幾千甚至更多的 Alert。
這時候真正的問題反而才開始：
哪些 Alert 是真的重要？

如果分析人員每天花大量時間確認最後證明沒有風險的事件，那 SIEM 雖然「有在運作」，SOC 卻不一定真的有效率。那只是有在運作但是人員根本沒有心思好好思考真的可能的問題，而是只是為了處理KPI而處理事件。

獨自一個人的時候沒有想太多，但當你還有其他人員的事情也要顧的時候，就會思考這樣子的 SOC 真的是一個有效的方式嗎?

所以做久之後，我開始在意的就不只是 Alert 的數量了，而是這些 Alert 之間到底有沒有關聯？我們能不能從原本看起來沒有關係的資訊裡，慢慢拼出一個事件？

例如單獨看到一筆 Firewall Log，可能沒有什麼特別。
但如果把它和 Endpoint、Authentication、Network Behavior，甚至其他時間點發生的事件放在一起，意義就可能完全不同。

SOC 困難的地方是要如何利用 SIEM 把這麼多 [資訊] 整理 [事件]
我們來用簡單的例子來說明資訊的關聯性，假設 SOC 中心是一個商業大樓的中控室，SIEM 則是中控室上面顯示所有感測器的防護系統。
他會收集可能類似門禁系統、監視系統、空調系統...等多個系統資料，
今天門禁刷卡失敗一次，其實沒什麼；監視器看到一個人在走動，也不一定有問題；某扇門被打開，也可能只是正常使用。
但如果今天是凌晨兩點，一張平常不應該出現的門禁卡刷開機房，同一時間監視器也拍到人進去，接著某個設備又出現異常，這幾件事情放在一起看，意義就完全不同了。

SIEM 很重要的一個價值，就是幫我們把這些原本分散的資訊串起來。
但問題也就在這裡：你要怎麼知道哪些資訊應該被串在一起？

這也是 SOC 困難的地方。SIEM 收進來的資料可能很多，但真正困難的是怎麼設定關聯邏輯，讓 Firewall、EDR、Windows 或其他來源的資訊可以互相對得起來，最後讓分析人員在看到的不是幾十個分開的 Alert，而是一個「可能正在發生什麼事情」的事件。

但有了事件，問題就沒有了嗎?
很遺憾還有
就算今天 SIEM 成功的把這些資訊關聯起來，整理出一個事件了，但最後還是會回到 SOC 人員身上。

• 哪些是真實事件?
• 要從哪邊開始查?
• 影響哪些設備?
• 是否通報?
• 有無辦法立即處理?

這些也還是要人員去判斷，後續再帶領其他人開始熟悉怎麼操作或者認識系統時發現的問題。
以前都是自己處理時，大部分知道如何處理哪些要處理或者找資料。
但如果不是只有自己處理時，而是其他人也一起時問題就會出現。
我自己知道該做甚麼，但不代表其他人知道，而每個人的學習方式也都不同。

所以現在回頭看，SOC 真正困難的可能從來都不只是工具
也是從這時候開始，我才慢慢發現，一個 SOC 要能夠運作，光是 SIEM 能不能把事件找出來其實還不夠。當只有自己一個人的時候，很多事情可以依靠自己的經驗處理。
但是當開始有其他人一起加入，問題就會變成：
怎麼讓大家知道這個事件該看什麼？
什麼情況需要繼續追？
什麼情況需要通報？
又有哪些事情其實可以不用一直靠人重複處理？
這些問題後來也讓我開始接觸 SOP、事件處理流程以及自動化。
而這也是我現在跟五年前最大的差別。
五年前的我可能比較在意：
「資料有沒有進來？SIEM 有沒有成功產生 Alert？」

現在的我還是會在意這些事情，畢竟沒有資料，後面什麼事情都不用談。
但我會再多問幾個問題：
「這些 Alert 對分析人員真的有意義嗎？」
「我們能不能從這些 Alert 裡看出正在發生什麼事情？」
「發現事件之後，我們知不知道接下來要怎麼處理？」

所以如果現在再問我一次，一個成熟 SOC 的核心價值是什麼？
我現在的答案可能會是：
不是每天可以處理多少 Alert，而是能不能從大量的資訊裡找出真正重要的事件，讓人知道怎麼判斷、怎麼處理，最後再把這些經驗留下來。

至於後面的「怎麼處理」、「怎麼讓不同的人有比較一致的判斷方式」，以及「哪些事情可以交給自動化」，其實又是另外一個很大的問題。

這些我留到明天聊