微軟Defender XDR簡介
微軟的XDR(Extended Detection and Response)可以整合微軟其他資安產品,並能全面性偵測從 email、endpoints、applications到identity的任何惡意活動。這一些惡意活動,可以有效的阻擋Cyber Kill Chain的攻擊,並且能立即修復與保護組織的數位資產。下圖顯示了在每一個Defender XDR的產品下,攻擊都能無所遁形。
上圖可以分為四大面向來取得這些監控資料,並且進行偵測與減緩行動:
- Endpoint
- Identity
- Applications
XDR的回應場景
以下為一些XDR的回應場景範例。
威脅偵測
下圖描述 Microsoft Defender for Endpoint 偵測到惡意攻擊(可能來自任何來源,包括email或 USB 隨身碟)的場景。
使用者在沒有MDO(Microsoft Defender for Office 365)的保護下開啟email或 使用USB 隨身碟開啟附件。一旦附件打開,惡意軟體就會感染電腦。使用者不知道發生了攻擊。但 MDE(Microsoft Defender for Endpoints)偵測到此攻擊,會提供如何回應此威脅,並向資安團隊提供有關威脅的詳細資訊。這台受感染的裝置會無法存取企業的資源 — MDE 向 Intune 傳達此裝置上的風險等級已變更的訊息。配置了 MDE 風險等級嚴重性的 Intune 合規性政策將被觸發,並將帳號標記為不符合組織資安政策。 Microsoft Entra ID 中建立的條件存取(Conditional Access)會阻擋使用者存取應用程式。
補救措施(Remediation)
- MDE remediates threat— 透過自動修復、資安人員手動批准式修復或分析師手動調查威脅。
- MDE 還透過將有關此攻擊的資訊新增至 Microsoft 威脅情資系統,在整個企業和使用微軟的 Microsoft MDE的其他微軟客戶中修復此威脅
共享情資並恢復存取
- Restore Access — 修復受感染的裝置後,MDE 會向 Intune 發出訊號以變更裝置的風險狀態,然後 Microsoft Entra ID Conditional Access允許存取企業資源。
- 修正 MDO 和其他威脅變體 — Microsoft 威脅情資中的威脅資料會讓 Microsoft 的其他工具使用,以保護組織攻擊面的其他部分。 MDO 和 Microsoft Defender for Cloud 使用這些訊號來偵測和修復電子郵件、辦公室協作、Azure 等中的威脅。
當使用者的裝置仍然受到有惡意軟體時
限制存取
Conditional Access會知道裝置現在是甚麼狀況,因為MDE通知了 Intune,然後 Intune 更新了 Microsoft Entra ID 中裝置的合規狀態。
在此期間,使用者無法存取公司資源。這包含了所有對新資源請求,並阻止目前對有CAE(continuous access evaluation)服務的資源的任何存取。員工的裝置可以做其他事情,例如看 YouTube、維基百科以及其他不需要公司身份驗證的雜事,但無法存取公司資源。
恢復存取
一旦威脅得到補救和清除,MDE 就會再次觸發 Intune 更新 Microsoft Entra ID, Conditional Access會恢復使用者對公司資源的存取權。這樣可以確保可能控制這些設備的攻擊者無法存取公司資源,從而降低組織面臨的風險。
Microsoft Defender XDR在SOC的角色
下圖顯示 Microsoft Defender XDR 和 Microsoft Sentinel 如何整合到現代 SOC 中。
SecOps模型 — 功能與工具
雖然資安團隊的大小與組織規模和其他因素而異,但資安運作由幾個不同的職能組成。每個職能/團隊都有一個主要關注領域,也必須與其他職能和外部團隊密切合作才能有效。上圖描繪了具有一個甚麼專家都有的團隊的完整模型。在較小的組織中,這些職能一個人或幾個人來扛,由 IT 維運(對於技術角色)執行,或由領導/代表作為臨時職能執行(對於事故管理)。
分類與自動化
從上圖中,我們將從處理回應性告警開始:
- 自動化 — 透過自動化近乎即時地解決已知事故(Incident)類型。這些是組織三天兩頭遇到的定義明確的攻擊。
- 分類(aka Tier 1)-分類分析師專注於快速修復大量仍需要人類判斷的一般性的事故類型。這些人員的任務通常是批准自動修復工作流程,並識別任何需要升級或與調查團隊(Tier 2)協商的異常或特殊的情況。
分類和自動化的主要學習內容:
- 90% true positive(真的有發生)—
為任何需要資安人員回應的警報源設定 90% true positive的品質標準,這樣就不需要應對大量的假警報 - 告警比率(Alert Ratio) —
根據 Microsoft Cyber Defense Operations Center的經驗,XDR 告警產生大部分高品質告警(這是微軟自己說的),其餘部分來自使用者報告的問題、基於一般性日誌查詢的警報和其他來源 - 自動化是告警分類團隊的關鍵因素,因為它有減輕手動作業的負擔(例如,提供自動化調查,然後在批准為此事故自動構建的補救措施之前提示團隊進行人為審查)
- 工具整合 — 將 XDR 工具整合到 Microsoft Defender XDR 中,是縮短 Microsoft CDOC 修復時間的省時技術之一,這樣資安團隊就可以擁有一個用於端點、電子郵件、身分等的控制台。這種整合使分析人員能夠快速發現並清除攻擊者的網路釣魚電子郵件、惡意軟體和受感染的帳號,以免造成重大損害。
- 聚焦 — 這些資安團隊無法保持對所有類型的技術和場景的快速解決能力(因為資安事件類型實在是太多了),因此將注意力集中在與組織業務相關的少數技術領域和(或)場景上。大多數情況下,這與使用者生產力有關,例如電子郵件、端點 AV 告警(相對於進行調查的 EDR)以及使用者報告的第一個回應。
調查與事故管理(Tier 2)
Tier 1處理不了就會升級到這,並直接監看更複雜的攻擊者的告警。特別是觸發行為警報(trigger behavioral alerts)、與關鍵業務資產相關的特殊情況告警以及監控正在進行的攻擊活動的告警。該團隊還主動定期檢查分類團隊的告警分類表,並可以在剩餘時間使用 XDR 工具主動進行威脅搜尋。
該團隊對少量且更複雜的攻擊進行更深入的調查,這些攻擊通常是由人類攻擊者進行的多階段攻擊。團隊試驗新的或不熟悉的告警類型,以記錄分類團隊和自動化的流程,通常包括由 Microsoft Defender for Cloud on Cloud 託管應用程式、VM、容器和 Kubernetes、SQL 資料庫等產生的告警。
事故管理-該團隊負責管理事故的非技術面,包括與其他團隊(如公關、法務、高階管理層和其他業務利害關係人)的協調。
獵捕與事故管理(Tier 3)
這是一個多學科團隊,專注於識別可能躲過回應偵測(reactive detections)的攻擊者並處理影響業務的重大事故。
獵捕-團隊主動尋找未偵測到的威脅,協助升級和進階取證以進行回應性調查,並完善告警/自動化。這些團隊更採用假設驅動模型(hypothesis-driven model),而不是回應性告警模型,也是紅/紫團隊與資安團隊協作的地方。
T1 — T3的流程範例
- 分類分析師會說環境中存在惡意軟體告警並進行調查(例如,使用 Microsoft Defender XDR 控制台)
- 雖然大多數分類案例都得到了快速修復,但這次分析師觀察到惡意軟體可能需要更多參與/高階修復(例如,設備隔離和清理)。分類將案件升級給調查分析師(T2),由他負責調查。分類團隊可以選擇繼續參與並了解更多資訊(調查團隊可能會使用 Microsoft Sentinel 或其他 SIEM )
- 驗證調查結論(或進一步深入研究)並繼續進行補救,結案。
- 隨後,獵捕(T3)在審查已結束的事故以掃描值得深入研究的共通點或異常情況時可能會注意到此案例:
- 可能適合自動修復的偵測
- 多個類似事故可能有共同的根本原因
- 其他可能的流程/工具/告警改進 —
在一個案例中,T3檢視了該案例,發現使用者陷入了技術騙局。然後,此偵測被標記為潛在的更高優先等級告警,因為詐騙者已設法獲得裝置的管理員等級存取權限。較高的風險暴露。
威脅情資
威脅情資團隊提供背景脈絡和洞察來支援所有其他資安職能(在大型組織中使用威脅情資平台 )。這可能包括許多不同的面向,包括
- 針對活躍事故的回應性技術研究
- 對攻擊者群體、攻擊趨勢、高調攻擊、新興技術等進行主動技術研究。
- 策略分析、研究和洞察,為業務和技術流程及優先事項提供資訊。
Microsoft Security Graph
Microsoft Graph 提供統一的可程式化模型,可用於存取 Microsoft 365、Windows 和Enterprise Mobility + Security中的資料。就是用來跟第三方應用程式串接的平台。
Microsoft Graph API 提供單一端點 https://graph.microsoft.com。可以使用 REST API 或 SDK 存取端點。 Microsoft Graph 還包括一組強大的服務,用於管理使用者和裝置身分、存取、合規性和安全性,並協助保護組織免於資料外洩或遺失。
Microsoft Graph expose REST API 和client libraries來存取以下 Microsoft 雲端服務上的資料:
- Microsoft 365 核心服務:Bookings、Calendar、Delve、Excel、Microsoft Purview eDiscovery、Microsoft 搜尋、OneDrive、OneNote、Outlook/Exchange、People(Outlook 聯絡人)、Planner、SharePoint、Teams、To Do、Viva Insights
- Enterprise Mobility + Security services:進階威脅分析、進階威脅防護、Microsoft Entra ID、Identity Manager 和 Intune
- Windows services: activities, devices, notifications, Universal Print
- Dynamics 365 Business Central 服務
Microsoft Graph Security API
Microsoft Graph security API 是一種中間服務(或broker),它提供單一程式介面來串接多個 Microsoft Graph security providers。對 Microsoft Graph security API 的請求將聯合到所有適用的security provider。結果將被聚合並以common schema返回到請求應用程式,如下圖所示。
開發人員可以使用 Security Graph 建置智慧安全服務:
- 整合並關聯來自多個來源的資安告警
- 將告警串流傳輸至SIEM
- 自動將threat indicators傳送至 Microsoft 安全解決方案來產生告警、執行封鎖或允許操作
- 解析脈絡資料以便為調查提供資訊
- 發現從數據中學習並訓練資安解決方案的機會
- 自動化 SecOps 以提高效率
Microsoft Graph Security API 有兩個版本。
- Microsoft Graph REST API v1.0
- Microsoft Graph REST API Beta
Beta 版本提供了仍處於preview status的新的或強化的 API。對於資安團隊來說,兩個 Microsoft Graph API 版本都支援使用 runHuntingQuery 方法進行進階搜尋。此方法包括 Kusto 查詢語言 (KQL) 中的查詢。以下為一個在Microsoft Defender XDR進行進階獵捕範例。
POST https://graph.microsoft.com/v1.0/security/runHuntingQuery
{
"Query": "DeviceProcessEvents | where InitiatingProcessFileName =~ \"powershell.exe\" | project Timestamp, FileName, InitiatingProcessFileName | order by Timestamp desc | limit 2"
}
或者也可以用 Graph Explorer視覺化的方式: