A Logic App playbook, an automation rule, a real permissions error — and what it taught me about how automated incident response actually works.
An SSH brute force incident fires in Sentinel. High severity. 260 failed attempts in 28 minutes. Without automation, an analyst gets paged, manually opens the incident, investigates, and responds. That process takes 15 to 30 minutes on a good day — longer if it’s 3am.
With SOAR, the moment that incident is created, a playbook runs automatically. No analyst needed. No manual trigger. The response is documented, timestamped, and logged before anyone even opens their laptop.
This is how I built that automation in Microsoft Sentinel from scratch — and what I ran into along the way.
What SOAR actually is
SOAR stands for Security Orchestration, Automation and Response. It’s the automation layer of the SOC — the thing that handles routine, well-understood incidents automatically so analysts can focus on threats that actually need human judgment.
In real enterprise SOCs, SOAR playbooks handle IP blocking on firewalls, disabling compromised accounts in Active Directory, sending alerts to Teams or Slack, opening ServiceNow tickets, enriching incidents with threat intelligence, and isolating endpoints — all without human intervention.
The two pieces — and how they connect
In Microsoft Sentinel, SOAR has two components that work together:
The Logic App playbook — the actual workflow that runs when triggered. Built in Azure Logic App Designer without writing a single line of code. It defines what happens: add a comment, send an email, block an IP, disable an account.
The automation rule — the connector between a Sentinel incident and the playbook. It listens for specific conditions and automatically calls the playbook when they’re met.
The whole chain executes in seconds. Zero analyst involvement required.
Step 1 — The automation rule
The automation rule lives in Sentinel’s Automation section. I configured it with three settings:
- Trigger: When incident is created
- Condition: Analytics rule name contains “SSH Brute Force Attack Detected”
- Action: Run playbook → Sentinel-Block-IP-Playbook
The condition scope matters — you don’t want every incident triggering the same playbook. By scoping it to the specific analytics rule name, only SSH Brute Force incidents trigger this automation. Every other incident type gets its own dedicated response logic.
Step 2 — The Logic App playbook
The playbook is built in Azure Logic App Designer. Two steps, no code:
Trigger — Microsoft Sentinel Incident: The playbook wakes up when called by the automation rule. It receives the full incident context — ID, title, severity, attacker entities, and the ARM resource ID needed to write back to the incident.
Action — Add Comment to Incident (V3): The playbook adds this automated response comment to the incident:
Automated comment added to incident:
AUTOMATED RESPONSE: High severity SSH Brute Force incident
detected. Attacker IP has been flagged. SOC analyst notified
to block IP via UFW on Ubuntu endpoint immediately.
Every automated action gets logged in the incident timeline. This creates a timestamped audit trail essential for compliance, post-incident review, and SOC reporting. Even if no analyst touches the incident for an hour, there’s a record of exactly what the automation did and when.
Step 3 — Testing it and what actually happened
After building the playbook I manually triggered it against the SSH Brute Force incident to verify the end-to-end flow. Here’s what the run history showed:
- Trigger — Microsoft Sentinel Incident: Succeeded (green checkmark, 0s)
- Action — Add comment to incident: BadRequest error
The trigger succeeded — the playbook correctly received the Sentinel incident and started executing. The action step hit a BadRequest error because manually triggering a playbook outside of a live incident doesn’t automatically pass the Incident ARM ID that the Add Comment action requires.
This is a known limitation of manual testing. When the automation rule triggers the playbook automatically on a real incident, the ARM ID is passed correctly as part of the incident context and the action completes successfully.
I’m documenting this because it’s a realistic troubleshooting scenario. In a real enterprise environment, this exact error shows up when permissions or context aren’t configured correctly and knowing why it happens is more valuable than a perfectly clean lab screenshot.
The permissions challenge — what no tutorial mentions
Before any of this worked, the automation rule failed with a permissions error. This is worth documenting because it’s one of the most common SOAR configuration issues in real environments and almost no beginner tutorial covers it.
The root cause: Microsoft Sentinel uses a dedicated service account to run playbooks. That service account needs the Microsoft Sentinel Automation Contributor role on the resource group containing the playbook. Without it, the automation rule fires but the playbook silently fails.
The fix — navigate to the incident in Sentinel, click Run Playbook, and click “Grant permissions.” Sentinel automatically assigns the correct role to the resource group. Two clicks, but you need to know it exists.
Understanding this permission model is what separates someone who has configured SOAR in a real environment from someone who has only read about it.
What this looks like at scale
The playbook I built adds a comment. Real enterprise playbooks do far more with the same architecture:
- Push block rules to Palo Alto or Cisco firewalls via API
- Disable compromised accounts in Azure Active Directory
- Send high-priority alerts to a Teams SOC channel
- Open a P1 ticket in ServiceNow automatically
- Enrich incidents with VirusTotal intelligence on attacker IPs
- Isolate compromised endpoints via Microsoft Defender
The architecture is identical — Logic App trigger, automated actions, audit trail. The only difference is the action steps and the API integrations. Once you understand the trigger-condition-action chain, you can build any of these.
The one thing that makes SOAR actually work
SOAR only works for attacks you’ve already understood well enough to automate. You can’t automate a response you haven’t manually investigated first.
The SSH brute force playbook works because I spent Day 3 manually investigating the attack — building the timeline, identifying the attacker IP, confirming no successful logins, running the containment command. Only after doing that manually did I have enough understanding to say “this is repeatable and automatable.”
That sequence — manual investigation first, automation second — is how real SOC teams build their playbook library. Every automated response started as a manual one.
This is Day 6 of a 7-day Microsoft Sentinel enterprise lab I built from scratch. The full lab covers SSH and RDP brute force detection, KQL threat hunting, SOAR automation, and a live SOC dashboard — all documented on GitHub at microsoft-sentinel-enterprise-siem-lab. Previous post in this series covered the KQL detection rule that generates the incident this playbook responds to.
If you’re building Sentinel SOAR automation for SC-200 prep or your own lab — feel free to connect on LinkedIn.
How I Built a SOAR Automation in Microsoft Sentinel That Responds to Attacks Without a Single Click was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.