Automating Incident Response: How AI Can Help Your SOC

The Alert Fatigue Problem

Here's a typical day for a SOC analyst: 500 alerts, 8 hours, 2 actual incidents buried somewhere in the noise. The rest? False positives, low-priority events, and alerts that could have been auto-resolved.

This isn't sustainable. Analysts burn out, real threats get missed, and security suffers.

Automation isn't about replacing analysts. It's about handling the tedious stuff so humans can focus on what requires human judgment. For the manual steps automation should eventually replace, our [Azure incident response playbook](/blog/cloud-incident-response-playbook-azure-2026) is a good baseline to start from.

What Can (and Should) Be Automated

Tier 1: Full Automation

These should happen without human involvement:

• Known false positives
• Automatic enrichment (adding context to alerts)
• Standard responses (password resets after phishing, blocking known-bad IPs)
• Compliance logging

Tier 2: Automation with Verification

Automation does the work, human confirms before execution:

• Account lockouts
• Quarantining endpoints
• Blocking domains/IPs

Tier 3: Human-Led, AI-Assisted

Complex incidents where AI provides analysis:

• Advanced malware investigation
• Insider threat cases
• Incident scoping

Building Your Automation Stack

SOAR Platforms

Popular options: Microsoft Sentinel + Logic Apps, Splunk SOAR, Palo Alto XSOAR, Tines. If Sentinel is part of your stack, our [threat hunting with Microsoft Sentinel and KQL guide](/blog/threat-hunting-microsoft-sentinel-kql-guide-2026) covers the queries that feed these automated playbooks.

Basic Automation Playbook: Phishing Response

1. Extract indicators (sender, URLs, attachment hashes)
2. Enrich (check threat intel, scan URLs, analyze attachments)
3. Auto-classify based on findings
4. Execute response actions
5. Document everything

AI-Enhanced Triage

AI can help prioritize alerts by analyzing context, recent activity, threat intelligence, and asset criticality. Before connecting any AI model to live alert data, review our [AI security risks and best practices guide](/blog/ai-security-risks-and-best-practices) so the triage layer itself doesn't become an attack surface.

Measuring Success

Common Pitfalls

1. Automating Too Much Too Fast

Start small. Pick one alert type, automate it well, measure results, then expand.

2. No Human Override

Always have a way to disable automation.

3. Poor Documentation

Every automated action should be logged.

4. Set and Forget

Automation needs maintenance. Threats evolve.

Practical Guide: PowerShell & CLI Commands for Incident Response

These are real commands you can use during incident response. Copy, adapt, and automate them.

Initial Triage Commands

Get system information:

# Windows - Basic system info
Get-ComputerInfo | Select-Object CsName, WindowsVersion, OsArchitecture, LastBootUpTime

# Linux - System overview
hostnamectl && uptime && who

Check running processes:

# Windows - Find suspicious processes
Get-Process | Sort-Object CPU -Descending | Select-Object -First 20 Name, Id, CPU, Path

# Windows - Processes with network connections
Get-NetTCPConnection | Where-Object {$_.State -eq 'Established'} |
    Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, OwningProcess,
    @{Name='ProcessName';Expression={(Get-Process -Id $_.OwningProcess).ProcessName}}

# Linux - Active connections with processes
ss -tunapl | grep ESTAB

Check scheduled tasks and persistence:

# Windows - Scheduled tasks (common persistence mechanism)
Get-ScheduledTask | Where-Object {$_.State -eq 'Ready'} |
    Select-Object TaskName, TaskPath, State

# Windows - Startup programs
Get-CimInstance Win32_StartupCommand | Select-Object Name, Command, Location

# Linux - Cron jobs for all users
for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l 2>/dev/null; done

Log Collection Commands

Windows Event Logs:

# Failed login attempts (last 24 hours)
Get-WinEvent -FilterHashtable @{LogName='Security';Id=4625;StartTime=(Get-Date).AddHours(-24)} |
    Select-Object TimeCreated, @{N='User';E={$_.Properties[5].Value}},
    @{N='Source IP';E={$_.Properties[19].Value}}

# Successful logins from new sources
Get-WinEvent -FilterHashtable @{LogName='Security';Id=4624;StartTime=(Get-Date).AddHours(-24)} |
    Where-Object {$_.Properties[8].Value -notin @(2,7)} |
    Select-Object TimeCreated, @{N='User';E={$_.Properties[5].Value}},
    @{N='LogonType';E={$_.Properties[8].Value}}

# PowerShell execution logs
Get-WinEvent -LogName 'Microsoft-Windows-PowerShell/Operational' -MaxEvents 100 |
    Where-Object {$_.Id -eq 4104} | Select-Object TimeCreated, Message

Linux Logs:

# Authentication failures
grep -i 'failed\|failure' /var/log/auth.log | tail -50

# SSH access
grep 'sshd' /var/log/auth.log | grep -E 'Accepted|Failed' | tail -50

# Sudo usage
grep 'sudo' /var/log/auth.log | tail -50

Containment Actions

Isolate a compromised machine:

# Windows - Block all outbound except management
New-NetFirewallRule -DisplayName 'IR-Block-Outbound' -Direction Outbound -Action Block
New-NetFirewallRule -DisplayName 'IR-Allow-Management' -Direction Outbound -Action Allow -RemotePort 22,3389 -Protocol TCP

# Linux - Block all outbound (iptables)
iptables -I OUTPUT -p tcp --dport 1:65535 -j DROP
iptables -I OUTPUT -p tcp --dport 22 -j ACCEPT  # Keep SSH

Disable compromised account:

# Windows - Disable AD account
Disable-ADAccount -Identity 'compromised_user'

# Windows - Force logout
query user /server:COMPUTERNAME
logoff SESSION_ID /server:COMPUTERNAME

# Linux - Lock account
passwd -l compromised_user
pkill -u compromised_user

Kill malicious process:

# Windows - Kill by name
Stop-Process -Name 'malware' -Force

# Windows - Kill by PID
Stop-Process -Id 1234 -Force

# Linux
kill -9 1234

Evidence Preservation

Hash suspicious files:

# Windows
Get-FileHash -Path 'C:\suspicious\file.exe' -Algorithm SHA256

# Linux
sha256sum /path/to/suspicious/file

Copy evidence with metadata:

# Windows - Copy preserving timestamps
robocopy 'C:\Users\victim\' 'E:\Evidence\' /COPY:DAT /E /LOG:evidence.log

# Linux - Copy with metadata
cp -a --preserve=all /home/victim /evidence/

Automation Script Template

Here's a basic PowerShell script to automate initial triage:

# IR-Triage.ps1 - Run on suspected compromised machine
$OutputPath = 'C:\IR-Evidence'
New-Item -ItemType Directory -Path $OutputPath -Force

# System Info
Get-ComputerInfo | Out-File "$OutputPath\system-info.txt"

# Network Connections
Get-NetTCPConnection | Export-Csv "$OutputPath\connections.csv"

# Running Processes
Get-Process | Select-Object Name, Id, Path, CPU | Export-Csv "$OutputPath\processes.csv"

# Recent Security Events
Get-WinEvent -FilterHashtable @{LogName='Security';StartTime=(Get-Date).AddHours(-24)} |
    Export-Csv "$OutputPath\security-events.csv"

# Create archive
Compress-Archive -Path $OutputPath -DestinationPath 'C:\IR-Evidence.zip'

Getting Started This Week

Day 1-2: Pick one high-volume, low-complexity alert type
Day 3-4: Build enrichment automation
Day 5: Add auto-classification
Week 2: Add response actions for clear-cut cases
Week 3+: Expand to other alert types

Automation is a force multiplier, not a replacement. The goal is a team of 5 operating like a team of 20, not a team of 0.

Frequently Asked Questions

What types of SOC tasks are best suited for full automation without human review?

Tasks best suited for full automation are those with well-understood, deterministic outcomes: enriching alerts with threat intelligence context, blocking known-bad IPs or domains from active blocklists, resetting passwords after confirmed phishing where policy requires it, and logging compliance events. These qualify because the correct action is unambiguous and the risk of an incorrect automated action is low. Tasks requiring judgment, such as account lockouts or endpoint quarantine, should include a human confirmation step.

What is SOAR and how does it differ from a SIEM?

SIEM (Security Information and Event Management) collects, normalizes, and correlates log data to surface alerts. SOAR (Security Orchestration, Automation, and Response) executes automated response actions based on those alerts. A SIEM tells you what happened; a SOAR does something about it. In practice they are complementary: Microsoft Sentinel combines both functions, while dedicated SOAR platforms like Tines or Palo Alto XSOAR integrate with existing SIEMs. Many modern security platforms blur the line between the two categories.

How do you measure the success of SOC automation?

The four metrics that best capture automation effectiveness are Mean Time to Acknowledge (MTTA), Mean Time to Respond (MTTR), alerts per analyst per day, and false positive rate. Targets vary by organization, but meaningful benchmarks are: MTTA under 10 minutes, MTTR under 2 hours for high-severity incidents, fewer than 50 meaningful (non-false-positive) alerts per analyst per day, and a false positive rate below 50%. Track these monthly and compare pre- and post-automation baselines.

What is the biggest mistake teams make when starting SOC automation?

The most common mistake is trying to automate too many alert types simultaneously without validating each one first. Automation errors compound: if a playbook incorrectly classifies a legitimate action as malicious and auto-blocks it at scale, the impact is much larger than a single analyst making the same mistake. The correct approach is to start with one high-volume, low-complexity alert type, run the playbook in observation mode for two weeks to validate its decisions, then enable automated response for that single type before expanding.

What are the most important forensic evidence preservation steps during incident response?

Preserve evidence before any remediation action. The critical steps are: create memory dumps of running systems before rebooting (memory contains process lists, network connections, and encryption keys), hash all suspicious files with SHA-256 and document the hash before touching them, use forensic copy tools that preserve metadata and timestamps rather than standard file copy, and document the chain of custody for all collected evidence. Evidence collected carelessly or after remediation is often inadmissible in legal proceedings and insufficient for insurance claims.