441
技術社區[雲棲]
安全自動化在於信任，而非技術
我們可以自動化動作，而不自動化決策……
一直以來的反饋都表明，至少安全團隊是非常渴求自動化的。但這種渴望受製於懷疑和恐懼。懷疑威脅檢測的準確性，恐懼威脅控製或緩解響應自動化的後果，以及自動化出錯可能造成的不良影響和破壞。
長期工作於網絡安全領域的人知道，這種現象並不新鮮。反垃圾郵件和入侵防禦係統(IPS)的承諾尚曆曆在目，對其異常和攻擊檢測能力的過度自信所造成的混亂，就開始啪啪打臉。
安全自動化
很多公司都有IPS，但卻以非阻塞模式運行，直接降級成入侵檢測係統(IDS)使用。而且這種趨勢至今未減：公司企業引入自動化功能到現有技術中，比如安全信息及事件管理(SIEM)、終端檢測與響應(EDR)、安全自動化與編配(SAO)解決方案等，但卻不相信它們的自動化能力，僅僅在發送通知或執行威脅情報查詢之類基本任務上應用自動化。
這基本上無視了檢測功能已大幅改進的事實，尤其是在應用了行為建模和機器學習驅動的方法之後。真是應了那句老話：千萬別嚐試用技術來解決社會問題。因為問題本身就不是基於技術的，而是基於信任——或者信任的缺失。這裏麵涉及的3個基本原則是：
安全運營團隊可評估風險影響，但評估不出對生產的影響
安全運營團隊深居象牙塔內，專注在威脅的風險和影響上，難以建立並維護對生產環節現狀的感知。受影響係統是不是任務關鍵的?係統是否不穩定?是否遺留係統?係統當前是用於處理年度財務報告，還是在被付費客戶使用?這些問題，安全運營團隊往往難以感知。
禁用無關緊要的用戶賬戶看起來很簡單，但該用戶賬戶很可能是用於執行關鍵過程的。依賴、複雜性和未知因素，都是自動化的痛腳。這些正好是大多數安全運營團隊要麼缺乏要麼信息過時的數據點——但卻對事件響應或修複過程的執行方式有影響。這並不是說事件或漏洞根本不用處理，而是強調需要額外的時間或特定的方式進行處理。
可以自動化動作，但不自動化決策
當然，可被自動化的東西，遠不止實際控製或修複響應過程。很多工作，比如事件優先級劃分、額外所需信息及上下文的獲取、利益相關者通知等，都可以被自動化。另外，若動作已經過審查，也是可以自動化的。最簡單的場景裏，這意味著向IT運營團隊發送事件通知——包括問題描述、潛在影響、解決問題所需的動作等，然後請他們確認動作執行，或者拒絕執行自動化動作而手動處理。我們可以自動化動作，而不自動化決策。
可隨信任與信心的增加而擴展自動化
IT運營往往過載，於是從安全運營到IT運營的傳遞，往往在響應上有長長的延遲。在諸如勒索軟件之類的事情情況下，這種延遲意味著，是控製住局麵還是隻能災難恢複的差別，是單純的事件還是完完全全的數據泄露的差別。工作過載的一隊人會反對能讓自己更輕鬆的辦法，這簡直是違反人類直覺的事，然而，人性就是這樣。不過，即便如此，我們依然可以幫助緩解疑慮和擔憂，建立信任和信心。
方法就是：記錄哪些動作是手工執行的——同個動作由人代替機器執行的次數，並計算出人和機器做同個動作在所消耗時間與資源上的差異。其思想精髓在於：如果多次接到需要相同手工動作的類似事件通知，那麼此類事件便可以很安全地自動化處理。畢竟，我們有審計線索來證明這一點，也有數據來建立業務案例。更重要的是，我們也能收集數據，勾勒出哪些事務或位置不能安全地自動化。
或許在某個業務部門可以安全進行的自動化，在另一個業務部門就是完全不可接受的。自動化過程必須支持粒度，無論是指標收集，還是自動化配置時。理想狀態下，不管使用哪種自動化技術，都必須支持該方法，並提供所需的各項指標。技術可以輔助建立信任，但最終，必須讓你期望信任你的對象感受到。
本文轉自d1net（轉載）
最後更新：2017-07-26 12:03:56