我們可以自動化動作，而不自動化決策……

[[197888]]

一直以來的反饋都表明，至少安全團隊是非常渴求自動化的。但這種渴望受制于懷疑和恐懼。懷疑威脅檢測的準確性，恐懼威脅控制或緩解響應自動化的后果，以及自動化出錯可能造成的不良影響和破壞。

長期工作于網絡安全領域的人知道，這種現象并不新鮮。反垃圾郵件和入侵防御系統(IPS)的承諾尚歷歷在目，對其異常和攻擊檢測能力的過度自信所造成的混亂，就開始啪啪打臉。

安全自動化

很多公司都有IPS，但卻以非阻塞模式運行，直接降級成入侵檢測系統(IDS)使用。而且這種趨勢至今未減：公司企業引入自動化功能到現有技術中，比如安全信息及事件管理(SIEM)、終端檢測與響應(EDR)、安全自動化與編配(SAO)解決方案等，但卻不相信它們的自動化能力，僅僅在發送通知或執行威脅情報查詢之類基本任務上應用自動化。

這基本上無視了檢測功能已大幅改進的事實，尤其是在應用了行為建模和機器學習驅動的方法之后。真是應了那句老話：千萬別嘗試用技術來解決社會問題。因為問題本身就不是基于技術的，而是基于信任——或者信任的缺失。這里面涉及的3個基本原則是：

安全運營團隊可評估風險影響，但評估不出對生產的影響

安全運營團隊深居象牙塔內，專注在威脅的風險和影響上，難以建立并維護對生產環節現狀的感知。受影響系統是不是任務關鍵的?系統是否不穩定?是否遺留系統?系統當前是用于處理年度財務報告，還是在被付費客戶使用?這些問題，安全運營團隊往往難以感知。

禁用無關緊要的用戶賬戶看起來很簡單，但該用戶賬戶很可能是用于執行關鍵過程的。依賴、復雜性和未知因素，都是自動化的痛腳。這些正好是大多數安全運營團隊要么缺乏要么信息過時的數據點——但卻對事件響應或修復過程的執行方式有影響。這并不是說事件或漏洞根本不用處理，而是強調需要額外的時間或特定的方式進行處理。

可以自動化動作，但不自動化決策

當然，可被自動化的東西，遠不止實際控制或修復響應過程。很多工作，比如事件優先級劃分、額外所需信息及上下文的獲取、利益相關者通知等，都可以被自動化。另外，若動作已經過審查，也是可以自動化的。最簡單的場景里，這意味著向IT運營團隊發送事件通知——包括問題描述、潛在影響、解決問題所需的動作等，然后請他們確認動作執行，或者拒絕執行自動化動作而手動處理。我們可以自動化動作，而不自動化決策。

可隨信任與信心的增加而擴展自動化

IT運營往往過載，于是從安全運營到IT運營的傳遞，往往在響應上有長長的延遲。在諸如勒索軟件之類的事情情況下，這種延遲意味著，是控制住局面還是只能災難恢復的差別，是單純的事件還是完完全全的數據泄露的差別。工作過載的一隊人會反對能讓自己更輕松的辦法，這簡直是違反人類直覺的事，然而，人性就是這樣。不過，即便如此，我們依然可以幫助緩解疑慮和擔憂，建立信任和信心。

方法就是：記錄哪些動作是手工執行的——同個動作由人代替機器執行的次數，并計算出人和機器做同個動作在所消耗時間與資源上的差異。其思想精髓在于：如果多次接到需要相同手工動作的類似事件通知，那么此類事件便可以很安全地自動化處理。畢竟，我們有審計線索來證明這一點，也有數據來建立業務案例。更重要的是，我們也能收集數據，勾勒出哪些事務或位置不能安全地自動化。

或許在某個業務部門可以安全進行的自動化，在另一個業務部門就是完全不可接受的。自動化過程必須支持粒度，無論是指標收集，還是自動化配置時。理想狀態下，不管使用哪種自動化技術，都必須支持該方法，并提供所需的各項指標。技術可以輔助建立信任，但最終，必須讓你期望信任你的對象感受到。