Post

Security Automation Playbooks

Security Automation Playbooks

Overview

Every security event starts with the same manual steps. A suspicious IP shows up in the logs and someone has to look up the WHOIS, check geolocation, run it against threat feeds, and document the findings. A brute force alert fires and an analyst has to pull the auth logs, count the failures, check timing, and decide if the account is compromised. These workflows are predictable, repetitive, and slow when done by hand.

I built this playbook framework to automate those initial triage steps. Each playbook encapsulates a complete investigation workflow, runs it against real or simulated data, and outputs structured findings with recommended response actions.

GitHub


Available Playbooks

Suspicious IP Investigation

Takes an IP address and runs it through a full investigation workflow: reverse DNS lookup, geolocation via ip-api.com, ISP and ASN identification, proxy/VPN detection, and hosting provider checks. Flags known malicious indicators and generates manual follow-up links for AbuseIPDB and VirusTotal.

1
python runner.py suspicious_ip --input 185.234.72.19
1
2
3
4
5
6
7
8
9
10
11
  [+] Investigating IP: 185.234.72.19
  [+] Address type check
      Public IP address
  [!] Reverse DNS
      No PTR record found
  [+] Geolocation
      Amsterdam, Netherlands
  [+] ISP
      Hostkey B.V.
  [!] Hosting detection
      IP belongs to a hosting provider

No PTR record and a hosting provider in the Netherlands. That’s a pattern worth investigating further.


Suspicious Login Triage

Analyzes authentication logs for brute force patterns. Counts failed attempts per source IP, measures the rate of attempts, detects when a successful login follows a burst of failures, and flags when privileged accounts (admin, root) are targeted. Outputs immediate response actions.

1
python runner.py suspicious_login
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
  [+] Analyzing IP: 185.234.72.19
      5 failed, 2 successful
  [!] Brute force detection
      Threshold exceeded: 5 failures before success
  [!] Timing analysis
      0.12 attempts/sec over 60 seconds
  [!] Post-brute-force success
      Account may be compromised

  Findings:
    [CRITICAL] BRUTE_FORCE_DETECTED: 5 consecutive failed logins
    [CRITICAL] SUCCESS_AFTER_BRUTE: Successful login after failures
    [HIGH] PRIVILEGED_ACCOUNT_TARGET: admin account targeted

  Actions:
    - IMMEDIATE: Force password reset
    - IMMEDIATE: Revoke active sessions
    - BLOCK: Add source IP to firewall blocklist
    - INVESTIGATE: Search for lateral movement
    - HARDEN: Enable MFA on privileged accounts

Five failures followed by a success on the admin account. The playbook catches it, scores it as critical, and lays out exactly what to do next.


IOC Enrichment

Takes a comma-separated list of indicators (IPs, domains, hashes, URLs) and enriches each one with available context. Automatically classifies the IOC type, runs the appropriate lookups, checks against a local threat list, and flags anything that matches known malicious indicators.

1
python runner.py ioc_enrichment --input "185.234.72.19,evil-payload.com,44d88612fea8a8f36de82e1278abb02f"

The enrichment handles mixed IOC types in a single run. An analyst can paste a list from a SIEM alert, a threat report, or an email header and get context on everything at once.


Log Anomaly Detection

Scans authentication and system logs for five categories of anomalous behavior:

Off-hours access. Flags successful logins outside business hours (before 7 AM, after 7 PM). Legitimate employees sometimes work late, but off-hours access combined with other signals is worth investigating.

Impossible travel. Detects when the same user logs in from two different countries within a timeframe that makes physical travel impossible. A login from the US followed by a login from Russia two minutes later means one of those sessions is compromised.

Failed auth spikes. Counts failed login attempts per user and flags when the threshold is exceeded. Service accounts that suddenly start failing are often being targeted.

Privilege escalation. Catches any privilege escalation events in the log data. Even legitimate escalations should be audited.

After-hours file access. Flags file access events outside business hours, especially from accounts that don’t normally work late.

1
python runner.py log_anomaly
1
2
3
4
5
  Findings:
    [CRITICAL] IMPOSSIBLE_TRAVEL: jsmith US -> RU in 2min
    [HIGH] AUTH_FAILURE_SPIKE: svc_backup had 6 failed attempts
    [HIGH] PRIVILEGE_ESCALATION: admin escalated at 08:05
    [MEDIUM] OFF_HOURS_FILE_ACCESS: intern01 accessing files at 23:47

Four different anomaly types caught in one pass. Each finding has a severity level and the summary includes recommended response actions.


Architecture

The framework is built around a runner engine that loads and executes playbook modules:

1
2
3
4
5
6
7
security-playbooks/
  runner.py              Execution engine
  playbooks/
    suspicious_ip.py     IP investigation
    suspicious_login.py  Login triage
    ioc_enrichment.py    IOC enrichment
    log_anomaly.py       Log anomaly detection

Each playbook is a standalone Python module with a run() function. The runner provides a shared API for logging steps, recording findings with severity levels, and recommending actions. Adding a new playbook is as simple as creating a new file in playbooks/ with a description and a run() function.

This modular design means the framework grows with the analyst’s needs. A new detection or investigation workflow is one file and it immediately integrates with the runner’s logging and reporting.


Design Decisions

No external dependencies. The entire framework runs on Python’s standard library. Geolocation uses ip-api.com (free, no key). AbuseIPDB and VirusTotal are stubbed with manual follow-up links since they require API keys. This makes the tool immediately usable without any setup.

Structured output. Every playbook produces findings with severity levels (INFO, LOW, MEDIUM, HIGH, CRITICAL) and categorized actions (IMMEDIATE, BLOCK, INVESTIGATE, HARDEN, MONITOR). This structure makes it easy to feed results into a ticketing system or SIEM.

Sample data included. Each playbook ships with realistic sample data so the workflows can be demonstrated and tested without connecting to live infrastructure. In production, the data sources would be swapped for real SIEM feeds, log aggregators, or API integrations.


Tools and Skills

  • Python (standard library)
  • Incident response automation
  • Threat intelligence enrichment
  • Log analysis and anomaly detection
  • Brute force and impossible travel detection
  • Security orchestration design
  • Modular framework architecture
This post is licensed under CC BY 4.0 by the author.