Guides

Python for SOC Analysts (Defence Automation)

By Ravindra Bagale, Cyber Security trainer · LinkedIn · Published: 29 September 2026 · Last updated: 30 September 2026

Python for SOC analysts means using small, readable scripts to parse logs, enrich indicators, de-duplicate alerts and draft triage notes on authorised data — so L1/L2 work gets faster without turning the SOC into an exploit workshop.

Raw log → parse → filter → enrich → note / ticket fields
Script without scope = shadow IT risk
Print secrets = instant incident

What do I need before this guide?

• SOC context: What is SIEM / how SOC uses it.
• Optional hunt partner: Threat hunting for beginners.
• Optional phishing triage: Analyse a phishing email like a SOC analyst.

What should a SOC Python script do (and not do)?

Do:

1. Parse exports from your SIEM / EDR / mail gateway.
2. Deduplicate noisy fields (same user failing 500 times).
3. Join two authorised CSVs on a key (user, host, hash).
4. Format timelines and IOC lists for IR tickets.
5. Unit-test your parsers on sample fixtures in git.

Do not:

1. Build exploit payloads, brute-force tools, or malware loaders.
2. Scrape third-party networks without authorisation.
3. Auto-contain production hosts on day one of learning — wrap dangerous actions behind dry-run flags and approvals.
4. Hard-code API tokens in .py files committed to git.

Educational warning: practise on synthetic logs or exports you own. Unauthorised access and credential misuse remain illegal even if “the script is just Python”.

Real incident: Target (2013) — response needs clear evidence packs

Public reporting on the Target 2013 breach stressed that detection without effective response still fails. For analysts, that translates to craft: clean timelines, clear IOCs and reproducible queries. Python will not replace judgment, but it helps you assemble evidence packs faster so humans can contain sooner.

Takeaways (vertical):

1. What happened — major retail breach with lasting lessons on detection-to-response gaps.
2. What went wrong (theme) — signals existed; business response and clarity suffered.
3. Care-take — automate formatting of facts, not silent irreversible actions.
4. Care-take — every script output should name time zone (use IST labels for this audience).
5. Care-take — peer review anything that calls disable-user / isolate-host APIs.
6. Bonus parallel — SolarWinds-era hunts also needed reproducible queries — scripts help there too.

Red Team vs Blue Team (awareness only)

Red Team — what attackers try

• Live off built-in admin tools so custom malware is unnecessary.
• Flood analysts with noise so manual triage collapses.
• Steal automation tokens from SOC jump boxes or git.

Blue Team — defend, detect, respond

• Scripts that shrink noise and raise signal quality.
• Protected runners for automation; MFA on the accounts that own API keys.
• Dry-run defaults; audit logs of every containment call.
• Share reviewed notebooks/scripts in an internal repo with owners.

How do I learn SOC Python step by step?

Step 1 — Language floor

1. Variables, lists, dicts, for loops, functions, pathlib, csv, json, datetime.
2. Virtual environments (python -m venv) so lab packages stay contained.
3. Read errors calmly — stack traces are teachers.

Step 2 — Parse a lab CSV

Illustrative shape (defence sample — replace with your columns):

import csv
from pathlib import Path

path = Path("lab_auth_failures.csv")  # file you own
with path.open(newline="", encoding="utf-8") as f:
    rows = list(csv.DictReader(f))

users = {}
for row in rows:
    u = row.get("user", "unknown")
    users[u] = users.get(u, 0) + 1

for user, count in sorted(users.items(), key=lambda x: -x[1])[:10]:
    print(f"{user}: {count} failures")

Step 3 — Build a triage note printer

1. Inputs: alert name, user, host, src IP, decision, next action.
2. Output: markdown or plain text pasted into the ticket.
3. Always include time with an IST label when reporting for this class.

Step 4 — Enrich carefully

1. Local CSV of corporate VPN egress IPs you maintain.
2. Approved threat-intel API only with keys in environment variables.
3. Cache results; respect rate limits; log what you queried.

Step 5 — Safety rails before “actions”

1. --dry-run default for anything that changes state.
2. Explicit allow-list of hosts/users the script may touch.
3. Structured audit log line: who ran it, when (IST), what targets.

Step 6 — Lab only practice

1. Create a fake lab_auth_failures.csv on your laptop.
2. Rank top failing users; write a five-line L1 note.
3. Optional: parse a JSON EDR export stub you invented.
4. Never point enrichment scrapers at random internet targets.

Mini project ideas (safe)

1. Deduplicate phishing URL lists from your mailbox export (personal mail you own).
2. Convert a SIEM CSV export into an IR timeline template.
3. Check a list of process names against a local “suspicious in our org” text file (your policy, not a public malware kit).
4. Format hash lists for your ticket fields without uploading customer data to public paste sites.

Care-take — automation ethics for analysts

1. Written approval for scripts that call production APIs.
2. No customer PII in personal GitHub gists.
3. Pin package versions; review dependencies (supply-chain mindset).
4. Rotate tokens when a teammate leaves.
5. Prefer read-only SIEM API tokens for learning scripts.
6. Document assumptions in the script header comment.

How do I fix common SOC Python mistakes?

Ghabru naka 😅 — these are the usual ones: