????在上一篇文章中，我們看到了如何對案件通過相關性迅速找到事件發生的根源，但查找到威脅僅僅只是個開端，后續如何流程化的解決這個威脅，實現安全編排和自動相應。也是安全團隊所需要去完成的工作，而這個過程，Azure Sentinel作為SOAR平臺，也能夠幫助客戶將整個case解決的流程給自動化。

????點擊View Full Details

點擊case最右邊的view playbook，就會出現整片右邊的菜單欄，這些是微軟根據特定的case所預先生成和定義的自動化腳本，您只需一鍵RUN選擇所需要執行的動作，就會觸發對應的安全動作。

如果您對于所列的安全修復措施想做額外的修改和補充，您只需點擊需要改進的action，通過Logic App自己設計觸發的邏輯及動作。

此外，在Playbook中，微軟現在支持連接ServiceNow, Jira等ticket system來對接到客戶的案件平臺，對案件做有序的追蹤，解決和記錄。

除了以上一系列對于安全事件的快速響應機制，Azure Sentinel 還為客戶提供了客制化安全防御的功能。

????一段時間以來，公眾對于安全可能一直存在一種固定認知，即安全與防御是緊密關聯的，殊不知，一個成熟的安全團隊，也會根據客戶的行業屬性，長時間對于公司內部應用，人員的使用情況的熟悉，進行主動的威脅追蹤。借用Azure Sentinel中的Hunting模塊，客戶就可以為企業度身定做一款安全的矛，主動地去定位及清掃企業環境可能存在地風險。

??????? 舉個場景，某企業客戶中，他們的安全團隊清楚的了解，他們公司設計的應用所在的托管服務器常年都只由同一個用戶名做登錄，因此，即使公司內部存在其他賬號，可能可以被賦予相應的權限，在公司內部受信任的IP登錄這臺Host，但即使針對這個看似正常的行為，我也希望對這一個行為進行監控。因此他可以通過Hunting對所有這臺托管機上新登錄的這個操作進行監控及告警：

這里，我們就以針對一臺服務器的登錄情況，建立Query，并定期觸發這個搜索，返回相應的結果給到安全團隊。

微軟的安全專家團隊已經為客戶可能關心的幾十種場景，針對不同的log來源，編寫了對應的查詢語句腳本，羅列給到客戶進行選用。大家可能會比較疑惑的是，Bookmark會有什么用處，其實它是為了方便安全團隊在今后的事件中，提前做個標記，方便之后將相關聯的事件能夠做匯聚，可以把比如服務器上單個用戶名的正常登錄狀態與兩三個月前，該用戶在其他某處的異常登錄狀態做關聯，分析這個ID的行為狀況。從而幫助安全團隊對威脅進行預判。

點開Query，我們就可以把所有新用戶登錄成功及登錄失敗的事件都查看到，并且做了一個計數。

仔細來看搜索語句就可以看到，具體的搜索邏輯在這個查詢中是通過Event ID來進行篩選。這里的EventID的4624，4625在Windows Security Log中都指的登錄相關的事件。因此如果想了解對應到Linux機器中的登錄情況，就可以去搜索在Syslog中對應登錄狀態的EventID或者EventType來放到查詢語句中做查找。

如果對于這里所使用的查詢語句不太熟悉，建議大家學習Azure Log Analytics中的查詢語句的規范。如果是對于使用的場景不太熟悉，則可以借助微軟團隊建立的Query庫中的各種Hunting不同事件的Notebook中進行學習：

簡單介紹下Azure Notebook，它是微軟提供的運行在Azure云平臺上的Jupyte rNotebook，幫助大家快速的進行代碼的調試和計算而不用擔心底層承載的物理機的性能。 Azure 的安全團隊也利用這個平臺，為客戶真實場景中碰到的主動防御的場景，編寫了不同的腳本。

????點擊Clone Azure Sentinel Notebooks,就會跳轉到屬于每個人自己的Notebook的目錄，并且把github上Azure Sentinel中的部分都clone到你的目錄中。

????我們進到其中一個Hunt demo來一起看下：

????在這個Notebook的目錄下，微軟的安全工程師會按上圖所示的邏輯把Hunt的腳本描述清楚，如Description中，會把暴力破解的幾個場景羅列并解釋清楚，并建議給客戶推薦的數據收集來源。

????????接下來我們來看下如何Hunting攻擊者的暴力破解。

????????首先，當然需要從海量的日志數據中，把可疑的SSH登錄的事件都篩選出來，借助Azure在各個組件中內置的檢測機制，利用ML的分析能力，在事件發生的第一時間，就能夠去判斷事件自身是否異常。

????????那再經過Azure 日志分析的大漏斗以后，就可以定位到發生可疑登錄的服務器，找到這些服務器的IP地址等信息，經由其IP找到它與公司內部其他服務器間的流量往來，從而定位公司內部可能遭受公司的整個面。

?

回到Azure Sentinel的平臺，不知道大家是否還記得，在上篇文章中，我們提到過，Case是由Alerts匯聚而成，那想問的是Alerts又是從何而來。那接下來，我們就來看下Alerts的出處，以及是否公司可以根據自己的企業應用使用情況，來自行定義Alerts。

我們回到Azure Sentinel的面板上，來看下Alert是的定義。打開左側欄的Analytics：

我們就會發現，之前Case中的一系列Alerts其實都來自于這個警報庫。那我們也嘗試著自己來添加一個Alert，點擊左上角的添加：

?

?

????這里能看到對于一個警報，我們可以自己定義命名警報的名稱和嚴重級別。

然后就是最核心的部分，自定義查詢語句，比如對于Azure中所有創建資源的動作，或者流量達到什么峰值之類的。如果對于查詢語句不太了解，推薦可以到左側欄中的Community，跳往Github中，來參考微軟安全團隊及其他貢獻者定義的特殊事件的查詢方案。另外對于所需要查詢的范圍，也可以通過限定操作人員，服務器主機或者IP的形式進行精細查詢。

點擊藍色按鈕，我們跳轉到社區來仔細查看下由微軟團隊及其他貢獻者所定義的警報類型及搜索機制。

?

????????進入Detections子目錄后就能根據你所連接的數據集，選擇相應的Query語句，修改編輯后就可以應用于之后新創建的Alert rule里了。
????????接下來我們回到Analytics來繼續看下可以對警報進行的其他配置。

在定義完警報的類型及覆蓋的主體后，可以接著設定其觸發的閾值以及運行的時間表。并且這里可以連接到前文提到的Playbook，從而設定自動化的程序，比如對于虛機暴力破解的警報，可以接入Playbook來啟動安全團隊較高的響應機制，任命負責人員進行調查等。如果對于一些警報，如果其發生的頻次較高，也可以在最后打開壓縮的設定，從而降低警報的數量對于安全人員的調查的阻礙。

?

?????以上就是對Azure Sentinel的初步嘗試，可以看到的是，Azure Sentinel背靠微軟強大的安全解決方案以及ML的分析能力，今后會在其與更多的微軟一方的解決方案如Office 365 ATP相結合，依托于強大的AAD體系(Azure B2B, Azure B2C)，將監測的顆粒度可以落到每個人員的ID上，幫助企業建立新型的企業安全邊界應對當前開放的企業辦公環境。保證企業中每個員工靈活高效的辦公方式的同時，保護企業的數據及資產安全。

總結

以上是生活随笔為你收集整理的Azure Sentinel -- 初探系列二 案件调查及追踪的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。