Security operations playbooks

Repeatable workflows for triage, evidence, escalation, and response.

This page turns my portfolio into an operations knowledge base: how I think through common SOC problems, what I document, and how I keep investigations consistent.

Phishing triageBrute-force investigationLinux access hardeningEvidence handlingAI-assisted guardrails

Playbook 01

Phishing triage and escalation

Capture sender, recipient, subject, timestamps, message headers, URLs, attachments, and user action.
Separate business-context review from technical indicator review so urgency does not override evidence.
Escalate when credential theft, malware delivery, impersonation, or widespread delivery is suspected.
Document final disposition, containment action, and user-facing communication.

View related case study →

Playbook 02

SSH brute-force investigation

Confirm alert source, authentication result, event volume, account targeted, and source IP pattern.
Review related endpoint, Windows, Linux, firewall, and SIEM telemetry before declaring impact.
Tune detection logic around repeated failures, success-after-failure behavior, and known test activity.
Preserve screenshots, rule logic, search terms, and timeline notes for repeatable analyst handoff.

View related case study →

Playbook 03

Linux secure access baseline

Establish a known-good baseline before enforcing firewall or SSH restrictions.
Validate key-based login, root-login policy, password authentication state, and trusted-source access.
Use rollback steps before and after control enforcement so hardening does not become self-inflicted downtime.
Document what changed, why it changed, how it was tested, and how to reverse it safely.

View related case study →

Playbook 04

AI-assisted SOC workflow guardrails

Keep sensitive notes local when possible and separate retrieval from final analyst judgment.
Use AI to summarize procedures, compare notes, and accelerate documentation - not to invent facts.
Validate answers against source notes, timestamps, screenshots, logs, and analyst-owned conclusions.
Document model limits, retrieval sources, and human review requirements in the workflow.

View related case study →

Analyst documentation standard

Every investigation should answer the same core questions.

QuestionWhat I document

What triggered the review?Alert name, source, timestamp, severity, user or asset, and initial detection logic.

What evidence supports the finding?Logs, screenshots, SIEM queries, rule matches, endpoint context, and related events.

What changed?Configuration edits, containment actions, firewall rules, escalation decisions, or detection tuning.

How was it validated?Before/after tests, controlled simulation, successful query results, and rollback confirmation.

What happens next?Disposition, owner, escalation path, user communication, and recommended follow-up.

Recruiter takeaway

This is how I reduce analyst guesswork.

My value is not just tools. It is the ability to turn alerts, system changes, lab telemetry, and AI-assisted notes into repeatable workflows a team can review and trust.

Download hiring brief