Theory — Security Automation
Theory — Security Automation
This page covers the core concepts behind security automation — what it is, how it works, and how it fits into Day 5's labs.
What Is Security Automation?
Security automation means using automated tools to detect, respond to, and remediate security events without human intervention. In the cloud context, it typically involves three layers:
Automation handles the repetitive parts so humans can focus on the complex ones.
Three Approaches to Fixing Problems
When a security issue is detected, you have three options for fixing it:
1. Manual Fix (Human Action)
The alert is sent to an analyst, who investigates and fixes the issue manually.
When to use: Complex incidents requiring investigation, one-off issues, or when the fix involves business decisions.
2. Encoded Policy (Preventive)
The issue is prevented from happening in the first place through Azure Policy or a pipeline gate.
When to use: Recurring issues with clear rules, configuration problems that are obvious to detect.
3. Automated Remediation (Reactive)
The system detects the issue and fixes it automatically.
When to use: Repetitive, well-understood issues where the fix is deterministic and low-risk.
Logic Apps for Alerting and Response
Azure Logic Apps provide the glue between detection and response[^logic-apps]. They can trigger on events (like a Sentinel alert) and perform actions (like sending an email or disabling a user account)[^logic-apps-triggers].
Common Automation Scenarios
| Scenario | Trigger | Action |
|---|---|---|
| Critical alert notification | Sentinel incident created | Send Teams message with incident details |
| User account compromise | Azure AD sign-in anomaly detected | Disable user account, send to IT admin |
| Storage account exposed | Policy violation detected | Disable public access, notify security team |
| Pipeline tampering | Defender for DevOps alert | Block pipeline, alert DevOps lead |
Example: Alert Notification Logic App
A typical alert notification Logic App follows this flow:
- Trigger: Sentinel creates a new incident (or a webhook fires on an alert)
- Condition: Check severity level (Critical vs High vs Medium)
- Action (Critical): Send Teams message to the security channel with incident details and link
- Action (High): Create a ServiceNow ticket
- Action (Medium): Log to a monitoring table
You can build these in the Azure portal under Logic Apps → New, or define them as code using Bicep or Terraform for version control.
When to Auto-Remediate vs Alert-Only
This is the most important decision in security automation, and it's where many organisations get it wrong. Use this framework:
| Factor | Auto-Remediate | Alert Only |
|---|---|---|
| Fix certainty | The fix is always correct | Uncertain or context-dependent |
| Impact of wrong action | Low (no user impact) | High (could disrupt business) |
| Repetition | Happens frequently | One-off or rare |
| Complexity | Simple, deterministic | Requires investigation |
| Regulatory concern | No audit requirements | Must document human decision |
Examples
Auto-remediate: Disable a storage account's public access when a policy violation is detected. The fix is always correct, the impact is limited to that storage account, and it happens frequently.
Alert only: A user account shows unusual sign-in patterns. You don't know if it's a compromised account or just a travelling employee. Disable the account automatically and you might lock out a legitimate user — better to alert and investigate first.
The Risk of Over-Automation
Automation is powerful, but it introduces risks that manual processes don't:
False Positives
If your detection rule fires incorrectly, automation will act on bad data. A false positive in auto-remediation means you might:
- Disable a legitimate user account
- Block traffic to a production service
- Delete data that was actually important
Mitigation: Start with alert-only mode. Monitor for false positives. Only enable auto-remediation when the detection accuracy is high and the consequences of a false positive are low.
Business Disruption
Automated responses don't understand business context. A policy that blocks all outbound connections from a VM might stop an automated deployment that was running legitimately.
Mitigation: Use exceptions carefully, test automation in non-production first, and always have a rollback plan.
Alert Fatigue
Too many alerts — especially ones that trigger automated responses — lead to analysts ignoring them. If every alert is "critical," none of them are.
Mitigation: Tune your rules to reduce noise. Group related alerts. Only auto-remediate when you're confident the detection is accurate.
Key Takeaways
- Security automation has three layers: detection, response, and remediation.
- Azure Policy remediation tasks fix non-compliant resources but aren't real-time.
- Logic Apps connect detection events to response actions (notifications, account actions, etc.).
- Auto-remediate when the fix is certain and low-risk; alert-only when context matters.
- Over-automation causes false positives, business disruption, and alert fatigue — start conservative and scale up.
Sources
- Sentinel playbooks based on Logic Apps — Microsoft Learn