安全人员最头疼的问题之一是大量警报。即使在过滤掉噪音之后，这个数字也仍然远超安全团队的处理能力。同时，招聘熟练安全专业人员的预算也很少，少到连其他专业人员兼职安全的预算也不够。因此，似乎只剩下一条道路了，自动化。
自动化响应可以分成三个进阶，我们结合以下三个场景来了解：
情景1：潜在的内部威胁
某用户机构的IT管理员账号被用来登陆访问并修改以前从未触碰过的系统。这可能是对潜在内部威胁的预警，但也可能什么都不是。异常活动会触发一个playbook，向IT管理员及其主管的移动设备上推送通知。他们可以选择在活动目录中禁用用户账号，或者ServiceNow中打开一个ticket做进一步调查。
场景2：特权账号访问异常
高级管理人员的特权账号正被用来从一个不寻常的地理位置操纵公司信息。该事件触发了一个playbook，以控制潜在的威胁，并通知安全团队。账号的权限受到限制，推送通知发送给安全管理员，并将消息发送给安全团队，以验证活动的合法性。
情景3：复杂的失陷指征
一家医疗诊所的患者住院系统显示PowerShell活动异常，与已知的勒索软件攻击活动一致。该事件立即触发一个playbook，以隔离失陷主机，并在边缘层阻止外部资源的通信，以防止传播到其他主机。
分析
第一个场景是一个组织在其响应计划中探索自动化的早期阶段的示例，它允许在执行对安全控制的更改之前进行人工引导的决策。如，禁用用户账号。同时，也推动了进一步的调查工作。在这一阶段，组织希望确保了解资产(系统)的关键性，并将其归类为“关键资产”，以开展自动化响应工作。
第二个场景是一个组织开始拥抱自动化的例子。某个条件触发安全控制并自动调整成更严格的限制，并在调查人员验证活动合法性的同时，仍然允许用户访问内部资源。这一阶段，具备了在调查工作进行的执行安全控制措施，显然超越了“非黑即白”的早期自动化阶段。
第三个场景则是真正的自动化响应。自动化系统在主机和边缘层安全控制自动执行操作，以防止传播和入侵。速度至关重要，因此没有人为的决策点。尽管会向相关者发出某种通知，以便对受影响的系统进行进一步的取证和加固。
总而言之，上述三种情况都需要采取多种措施，包括通知相关人员和调整安全控制。大多数开始实施自动响应的组织都会在条件满足时通知员工，直到安全控制措施不会产生中断业务的意外后果。然后再找到并优化需要改进的地方，以逐步实现自动化。最终，判断一个组织是否做到了真正的自动化响应，要看其是否对自身的安全态势感到满意，并能够以自己的节奏采取控制措施，平衡流程自动化和人机交互，以满足其安全需求。
