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

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

情景1：潛在的內部威脅

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

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

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

情景3：復雜的失陷指征

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

分析

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

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

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

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