昨天我們談到 SIEM 在過去、現在與未來的事件回應上，
開始從以往傳統日誌蒐集、開始強化 AI/ML 的整合，
未來也逐步向「XDR」的策略模型進化與邁進，
在在都是為了要能夠更快的提供更完善的偵測與更即時的回應。
今天事件回應的第三篇、也是小結的最後一篇，
我們會來分享現在目前市場聲量也不低的 SOAR 這件事，
在一個完整的 SOC 是如何使用好的工具協助我們做好事件回應。
在談一個好工具替我們執行事件回應時，
我們先來看看一個標準的事件回應 (IR) 會有什麼過程：
而再好的工具與完善的程序都仍需要倚賴人員來執行，
因此明確定義的資安權責角色 (Roles/Responsibilites)，
反而是能否執行好事件回應的前提與必要條件。
SOAR 是由 Gartner 2017年 所定義的：
資安協調、自動化與回應（Security Orchestration, Automation and Response, SOAR）
我個人喜歡稱它為自動化的資安維運工具，
因為協調跟回應的考量，都會在滿足資安維運時同步達到，
另一方面也可以讓人比較快理解到底 SOAR 是個什麼樣的概念。
首先我們會先聊到，為什麼我們需要 SOAR 的工具，
我們這邊整理四個常見在事件回應時會遇到的狀況：
結合上面事件回應的過程以及常遇到的痛點，
來對照到我們在 SOAR 工具層面會需要什麼樣的功能？
案件管理 (Case Management)，
用來協助我們在 SIEM 偵測到威脅告警之後，
決定是否正式開立資安事件/案件進行調查與回應，
故 SOAR 工具首要的即是案件管理的功能，
或是在 ITSM 中的 Ticket System 意即是類似功能。
人員角色與職責劃分(Roles/Responsibilites)
為了讓事件回應過程中，
能讓更多人維持在同一頁上 (keep everyone on the same page)，
在這個工具中關於不同角色權責、權限，
就必須要能夠有完善的定義，
例如一、二、三線威脅分析師、稽核角色、瀏覽角色等等。
自動化腳本/劇本機制(Playbook)
為了要能夠自動化/半自動化執行事件回應，
故 SOAR 功能會搭配動態劇本、腳本或 Script 的功能，
讓需要呼叫、整合其他資安解決方案的步驟，
或是相關人員通知、端點隔離或外部資料查詢比對等，
都可以有動態的編輯平台與功能，可以彈性撰寫。
像是端點解決方案做的威脅獵捕，也是一種自動/半自動的機制作法。
事件回應的戰情管理(Dashboard)
如同 SIEM 的戰情監控儀錶板一樣，
在匯聚所有的資安事件開單、調查、回應、修補的過程，
也需要有一個集中的可視化平台來做戰情管理。
除了管理案件本身之外，如果是承接與接受客戶委託服務的，
相關機制都可以量化成處理時效，可以有效衡量是否滿足 SLA，
以及知道各個處理環節節點所需耗用的時間，
來讓資安維運作業的時間資源可以有明確的數值參考。
通常在採用 SOAR 工具前的前置條件，
通常會是 SOC/SIEM 的運作已經非常成熟，
或是既有的流程與程序面都十分完備後，
再適時以開源或商售的 SOAR 工具來輔助實現。
在目前劃分上，SOAR 常會與 ITSM 領域一起看待，
因為一樣都是開單、處理、查處、回覆、時效等等的元素，
但具體的差別會是在 ITSM 的工具，是比較偏向 IT 服務台概念，
而 SOAR 系列的產品是融合 Cybersecurity Domain Knowledge，
具體差別就是背後有無完整的框架或方法論支撐與實現各項功能。
無論選擇開源、ITSM 或是 SOAR，
其實都可以達到事件回應的需求與目的，
端視乎企業組織需要花多少的工去實現；
而任一種方式都還是會有核心的工要來面對，也就是「腳本」。
因為「協調」跟「回應」其實在沒有工具之前，
SIEM 與 SOC 的團隊就已經能夠有既有機制來處理，
具體是「自動化」是否真正能夠有效降低維運成本，
也因此在事件回應這個「威脅回應」的範疇內，
關鍵還是會回到有無明確、妥適與完整規劃出：
組織自身的「人員」、「工具」與「流程」，
才會是能否實現高效「事件回應」的核心所在。
很高興鐵人賽事來到第 13 天，
我們談完了 SIEM 的三大核心、四大支柱，
包含日誌蒐集可視化、威脅關聯分析與事件回應，
希望到這邊各位邦友都還喜歡這個 SIEM 系列文章。
明天開始，我們會進入到「SIEM 的整合應用」章節，
分別在接下來的 8 天時間談談：
期待明日繼續與各位朋友空中相會，謝謝大家！
iThome鐵人賽
看影片追技術
看更多
