Security orchestration, automation, and response

From an alert to a workflow

A response playbook describes work to perform when a particular event occurs. It might gather context about an account, open a ticket, notify an analyst, or request a containment action from another tool. SOAR coordinates those steps across the connected systems. Workflows can run automatically or be started by an analyst.

Microsoft Sentinel playbooks are one implementation, built on Azure Logic Apps. Microsoft’s examples include enriching incidents, synchronizing tickets, and responding to compromised accounts or devices. That does not mean every deployment has those workflows configured, or that every step should run without review.

Give the workflow bounded authority

A playbook needs permission to run, and its connections need appropriate access to the systems they act on. Microsoft documents these separately. Automation does not remove the need to decide who may change an account or isolate a device.

For disruptive actions, decide when human approval is required and who owns a failed or partial run. Apply least privilege to the automation identity, and inspect the outcome rather than treating a started workflow as a completed response.

A SIEM can supply the detection that starts this process; SOAR coordinates what happens next. SOC scenario visibility helps trace that handoff. For account-related actions, identity containment review explains why a successful request to one service may still leave other access to address.

Sources

• Microsoft, Automate Threat Response with Playbooks in Microsoft Sentinel
• Microsoft, Create and Manage Microsoft Sentinel Playbooks

Related terms

• Security information and event management
• Incident response
• Least privilege
• Security control

See it in practice

• Can Your SOC See the Social Engineering Scenario You Just Ran?
• After Account Recovery, What Access Remains?