如果日誌是各式各樣的食材,
那關聯分析就是我們鍋碗瓢盆來幫我們料理食物,
所以事件回應大概就是幫我們決定好的時候,
我們可以怎麼樣來享受這樣的菜餚了。
我們過去這幾天的時間,針對 SIEM 最重要的兩大功能,
日誌蒐集 與 關聯分析 做了介紹與分享,
而這兩大塊核心功能也都是威脅管理 (Threat Managememt) 中,
屬於威脅偵測 (Threat Detection) 的範疇:
滿足日誌可視化,以及針對異常情形進行偵測。
我們在這幾天分別談了:
第五天,談什麼是日誌跟正規化
第六天,談如何在不同系統收集日誌
第七天,談主流 SIEM 的日誌授權機制
第八天,談關聯分析機制如何實現
第九天,談關聯分析機制的延伸與應用
第十天,談案例庫與攻擊矩陣的實務經驗
接著我們就要進到威脅管理的後半段:
也就是「威脅回應」(Threat Response):
SIEM 怎麼樣在偵測到特定事件後的執行相關應變措施。
從可視化 (Visibility)、威脅偵測 (Detection),
到威脅調查 (Investigation)跟現在的威脅回應 (Repsonse),
分別是 SIEM 的四大支柱與核心功能。
而在偵測與回應 (Detection and Repsonse) 框架裡,
偵測,則是包含了可視化跟威脅偵測與調查兩大部分,
而 「回應 (Response)」 則是針對事件的告警觸發後的著墨。
簡言之,事件回應就是觸發相應告警後接續的處置流程
或是所謂的 Incident Response (IR),
意即我們常聽的事件回應或事件響應。
在 NIST 裏,也有專門定義 IR 程序的事件流程與建議作法,像是:
NIST 800-61:電腦安全事件處理手冊
NIST 800-83:電腦惡意軟體事件預防及處理
NIST 800-86:整合鑑識技術手冊
這些都是由 NIST 主導與建議的相關標準與做法。
而落在實務層級來看,
像我們之前「SIEM 與威脅管理」介紹的 X-Force 框架:
這些都會是事件回應計畫當中會去著墨與定義的內容。
無論有多少推薦或標準的事件回應架構或方法,
落在 SIEM 的事件回應的範疇內,
基本上都是由關聯分析、觸發規則後,
產生告警 (Alert) 或是資安事件 (Incident)。
告警,有時僅是做提示性通知,不見得就是威脅事件,
但當相關條件具足、確定是一起攻擊事件時,
就會直接產生一個個資安事件讓分析師進一步查察。
我們直接舉一個例子,來說明一個完整的事件回應的流程:
當我們收到用戶回報,可能疑似點了可疑郵件時,第一線資安人員就要先針對這樣的「告警」要不要進入正式的資安應變流程,所以會先檢查郵件的附件或是可疑連結,先到外部網站,例如 VirusTotal 等網站查詢,如果確定是可疑的 URL 時,可能會再看看是否有造成端點感染或入侵?網路層有無相關異常的流量發生?有無系統遭到異常登入?當檢視相關實質證據或紀錄,確定是一筆資安事件時,就會進入事件回應程序。
當正式進到事件回應時,
我們就會把上述情境的過程拆解成一個個任務 (Task),
開始針對例如,附件的 Hash 是不是既有的 Malware?
端點影響的範圍、層級到多廣多深?
這次事件是屬於哪一類的攻擊類型?
網路釣魚?勒索郵件?還是供應鏈攻擊?
隨著不同樣態的攻擊模式,也會觸發相應的調查機制,
而過程中也要確認是否違反相關 SLA 或是法規遵循?
有無證據需保存?啟動事件鑑識的必要性?
有無通報時效或是相關部門單位,如法務、公關須介入?
這一串串的處理流程,都會包含在一個完整的事件回應內,
也就是一個資安單位或是 SOC 中心提供資安服務時,
都需要替客戶考量、規劃與執行的。
傳統上 SIEM 在事件回應這個領域上,
比較為人詬病的是它常僅當作日誌收集與分析,
而回應的發生多數得仰賴第三方資安解決方案與工具,
常讓人覺得無法阻敵於當下、緩不濟急之感。
因此把戰線拉前至端點的偵測與回應 (EDR),
就是現在 EDR 蔚為風潮的原因之一。
而目前主流事件回應的做法,
多數還是得仰賴專業的資安分析師與 IR 小組,
來做資安事件判斷與相關事件內容調查。
也因為資安事件的告警一天動輒數十個,
而每個告警可能都得仰賴數小時的細節確認,
故整體的威脅調查與回應都比較算是「勞力密集型」的型態。
我們常聽到的資安專業人力不足,
某個程度也是因為資安牽涉的面向實在太廣,
故在人力、時間與專業資源上,
也比較難以及時滿足市場與需求方的要求。
今天介紹 SIEM 之於事件回應的概覽與流程,
以及透過一個實例瞭解事件回應牽涉的方方面面。
明天我們會就這個主題再往深入的分享:
現在的 SIEM 解決方案,
如何解決與彌補回應 (Repsonse) 的短板,
同時還能繼續發揮它原先資安大腦與指揮官的中樞角色。
我們明天見!祝秋節愉快~