SOAR、SIEM、Data enrichment 分別在做什麼

SIEM 是收東西的那個平台。各種設備、各種系統的 log 全部往它那邊丟，它做關聯、做比對，覺得不對就發告警。它的作用是蒐集巨量 log 然後找出關聯，可以透過規則的撰寫使其更加符合現有的環境。

SOAR 是能夠動手的那個。告警出來之後，照著 playbook 把該做的動作串起來跑：查這個 IP、撈這封信的header、判斷真假、該擋的擋掉。它的價值在於自動化，可以省去很多簡單但重複的工作，而且它串得到的範圍比 SIEM 廣，外部的情資來源、別家廠商的 API 都可以接進來。

註記:我沒有看過SOAR實際運作起來的樣子，在產品面這段我沒有那麼熟，我是依據書上的定義來撰寫的，如果有經驗的大大歡迎給予回饋!

Data enrichment 跟上面兩個不太一樣，它不是一個平台，是一種做法。

意思是資料進來的當下就先把情資附上去。一筆 log 裡有一顆對外的 IP，在它寫進去的那一刻就順手查這 IP 的信譽、是不是已知的惡意節點，然後把答案一起存進那筆紀錄。等到告警跳出來，分析師不用再開另一個視窗去查那個 IP，答案已經在告警裡面了。

Day10 我講了 STIX 跟 TAXII。有一題問的是怎麼讓分析師快速判斷一顆 IP 是不是惡意的，我選了「把情資用 STIX/TAXII 的格式送給 IPS」。

錯的地方有兩層。一層是 STIX/TAXII 管的是情資怎麼寫、怎麼送過來，跟分析師查得快不快是兩回事。另一層是送給 IPS 的意思是叫它去擋，那是阻斷，可是題目問的是查。

我那時候是看到專有名詞就跟著走了。

這個分法是概念上的，實際產品界線可能就沒有分的這麼清楚。現在不少 SIEM 本身就內建了編排與自動化，晚點提到那份 Sentinel 的文件就是 SIEM 跟 SOAR 寫在一起的。

哪些可以自動化?

有一題在問，哪一件工作最適合交給自動化。

我當時是拿「這件事的重複次數」在挑的。哪個選項步驟最多、最像一條流水線，我就挑哪個。結果錯了。

後來才知道要看的不是它重複幾次，是整條跑完之後停在誰手上。中間九步都是機器在跑，最後一步要人去判斷、去跟進、去打一通電話確認，那這件事還是卡在人身上。自動化省掉的是前面九步的時間，不是「交出去就不用管」。

只要需要somebody to do something，那最後還得是人。

能不能自動化先問自己三個問題

重複嗎。 一年做一次的事自動化起來不太划算，寫腳本跟測試的時間可能比手動做十年還久。

規則講不講得清楚。 「信心值超過 5 就擋掉」是規則，「看起來怪怪的圖檔就歸檔」不是。後者寫不成條件式，因為「看起來怪怪的」本身沒有定義，它是人眼在判斷(或者通靈)。

做錯了收得回來嗎。 這個是我覺得最該考慮的點。

加一條防火牆規則、發一封通知信、產一份報表，做錯了改回來就好。但有些事情不能復原，切斷某條網路、停掉某台機器，斷了網、關了機，證據可能就隨之揮發了，更加重要的是問自己，這件事交給機器，放不放心，你願不願意把決定權交給自動化。

所以這種動作通常會留一個確認關卡：機器把該查的都查完、該準備的都準備好，最後那一下按鈕給人按。它還是自動化，只是沒有一路自動到底。

playbook 不是自動化本身

Playbook 這個詞我一開始以為就是自動化。

它其實是那份寫好的流程：碰到這種事，第一步做什麼、第二步做什麼、什麼情況下走哪一條分支。微軟把 Sentinel 的 playbook 說明成「一組回應與修補的動作與邏輯，可以當成例行程序來跑」，文件在這。

同一份東西，印出來貼在牆上讓人照著做，它是 SOP；餵給一個平台讓平台照著跑，它才變成自動化。所以 playbook 是輸入，不是那台機器。

反過來說，流程本身沒寫清楚的話，工具買回來也沒東西可以餵。

工具也是同一種問題

選工具其實也是在問「這件事要的產出是什麼」。

要一份交得出去、證明我們有定期做弱點掃描的報告，那是弱點掃描工具的事，OpenVAS、Nessus 這一類。

要知道某台機器開了哪些埠、上面跑的是什麼版本，那是 Nmap，Day04、Day05 都在用它。Nmap 不是弱點掃描器，他不會產出報告來告訴你該修哪。

要看封包裡實際傳了什麼，那是 Wireshark 或 tcpdump。

要攔下一個 web 請求、改幾個參數再送出去，那是 Burp Suite。

選工具要看目的。要的是報告、是清單、是封包，還是要改請求，讓猩猩去爬樹，鯊魚去游泳，不然工具再強用在不對的地方都是白費工夫(還有錢)。