自動化響應要循序漸進 不能一蹴而就

安全人員最頭疼的問題之一是大量警報。即使在過濾掉噪音之後，這個數字也仍然遠超安全團隊的處理能力。同時，招聘熟練安全專業人員的預算也很少，少到連其他專業人員兼職安全的預算也不夠。因此，似乎只剩下一條道路了，自動化。

自動化響應可以分成三個進階，我們結合以下三個場景來了解：

情景1：潛在的內部威脅

某使用者機構的IT管理員賬號被用來登陸訪問並修改以前從未觸碰過的系統。這可能是對潛在內部威脅的預警，但也可能什麼都不是。異常活動會觸發一個playbook，向IT管理員及其主管的移動裝置上推送通知。他們可以選擇在活動目錄中禁用使用者賬號，或者ServiceNow中開啟一個ticket做進一步調查。

場景2：特權賬號訪問異常

高階管理人員的特權賬號正被用來從一個不尋常的地理位置操縱公司資訊。該事件觸發了一個playbook，以控制潛在的威脅，並通知安全團隊。賬號的許可權受到限制，推送通知傳送給安全管理員，並將訊息傳送給安全團隊，以驗證活動的合法性。

情景3：複雜的失陷指徵

一家醫療診所的患者住院系統顯示PowerShell活動異常，與已知的勒索軟體攻擊活動一致。該事件立即觸發一個playbook，以隔離失陷主機，並在邊緣層阻止外部資源的通訊，以防止傳播到其他主機。

分析

第一個場景是一個組織在其響應計劃中探索自動化的早期階段的示例，它允許在執行對安全控制的更改之前進行人工引導的決策。如，禁用使用者賬號。同時，也推動了進一步的調查工作。在這一階段，組織希望確保瞭解資產（系統）的關鍵性，並將其歸類為“關鍵資產”，以開展自動化響應工作。

第二個場景是一個組織開始擁抱自動化的例子。某個條件觸發安全控制並自動調整成更嚴格的限制，並在調查人員驗證活動合法性的同時，仍然允許使用者訪問內部資源。這一階段，具備了在調查工作進行的執行安全控制措施，顯然超越了“非黑即白”的早期自動化階段。

第三個場景則是真正的自動化響應。自動化系統在主機和邊緣層安全控制自動執行操作，以防止傳播和入侵。速度至關重要，因此沒有人為的決策點。儘管會向相關者發出某種通知，以便對受影響的系統進行進一步的取證和加固。

總而言之，上述三種情況都需要採取多種措施，包括通知相關人員和調整安全控制。大多數開始實施自動響應的組織都會在條件滿足時通知員工，直到安全控制措施不會產生中斷業務的意外後果。然後再找到並最佳化需要改進的地方，以逐步實現自動化。最終，判斷一個組織是否做到了真正的自動化響應，要看其是否對自身的安全態勢感到滿意，並能夠以自己的節奏採取控制措施，平衡流程自動化和人機互動，以滿足其安全需求。