Why This Matters#

Prevention eventually fails. When it does, the speed and quality of your detection and response determines whether an incident is a minor event or a catastrophic breach. Security operations is the 24/7 function that watches, detects, and responds.


Security Operations Center (SOC)#

SOC Tiers#

TierRoleResponsibilities
Tier 1Alert AnalystTriage alerts, initial classification, escalate or close
Tier 2Incident ResponderDeep investigation, containment, evidence collection
Tier 3Threat Hunter / Senior AnalystProactive hunting, advanced forensics, malware analysis
EngineeringDetection EngineerBuild detection rules, tune alerts, automate playbooks

SOC Metrics#

MetricMeasuresTarget
Mean Time to Detect (MTTD)Discovery speedMinutes–hours
Mean Time to Respond (MTTR)Response speedHours
Alert volumeWorkloadManageable (not drowning)
False positive rateAlert quality< 30%
Escalation rateTier 1 → Tier 210–20%
Coverage% of ATT&CK techniques detectedIncreasing

SIEM (Security Information and Event Management)#

Centralized log aggregation, correlation, and alerting:

flowchart LR
    subgraph Sources["Log Sources"]
        FW["Firewalls"]
        EP["Endpoints (EDR)"]
        Cloud["Cloud (CloudTrail)"]
        App["Applications"]
        Auth["Auth Systems"]
        Net["Network (NDR)"]
    end
    
    Sources --> SIEM["SIEM<br/>(normalize, correlate, alert)"]
    SIEM --> Alerts["Alerts"]
    SIEM --> Dashboards["Dashboards"]
    SIEM --> Hunt["Threat Hunting"]
    SIEM --> SOAR["SOAR<br/>(automated response)"]

Detection Rule Types#

TypeHow It WorksExample
ThresholdCount exceeds limit> 10 failed logins in 5 minutes
CorrelationMultiple events togetherFailed login + successful login + data download
AnomalyDeviation from baselineUser accessing systems they never access
Indicator matchKnown-bad IOC detectedConnection to known C2 IP
BehavioralSequence of suspicious actionsCredential dump → lateral movement → exfiltration

SIGMA Rules#

Vendor-agnostic detection rule format (like Snort rules for logs):

title: Suspicious PowerShell Download
status: stable
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        CommandLine|contains|all:
            - 'powershell'
            - 'downloadstring'
    condition: selection
level: high

SOAR (Security Orchestration, Automation, and Response)#

Automates repetitive SOC tasks:

Use CaseAutomation
Phishing email reportedExtract URLs/attachments → scan → block → notify user
Malware alertIsolate host → collect forensics → create ticket
Suspicious loginCheck geo-location → verify with user → block if unconfirmed
Vulnerability foundEnrich with context → assign to team → track SLA

Playbook Example: Phishing Response#

flowchart TD
    Alert["Phishing Alert"] --> Extract["Extract IOCs<br/>(URLs, hashes, sender)"]
    Extract --> Check["Check Threat Intel<br/>(VirusTotal, reputation)"]
    Check --> Malicious{"Malicious?"}
    Malicious -->|Yes| Block["Block sender + URLs"]
    Block --> Search["Search for other recipients"]
    Search --> Remove["Remove from all mailboxes"]
    Remove --> Notify["Notify affected users"]
    Malicious -->|No| Close["Close as false positive"]
    Notify --> Ticket["Create incident ticket"]

Incident Response Lifecycle#

NIST SP 800-61 Framework#

flowchart LR
    Prep["1: Preparation"] --> Detect["2: Detection<br/>& Analysis"]
    Detect --> Contain["3: Containment<br/>Eradication<br/>Recovery"]
    Contain --> Post["4: Post-Incident<br/>Activity"]
    Post --> Prep

Phase 1: Preparation#

ActivityPurpose
IR plan documentedEveryone knows their role
Playbooks for common scenariosConsistent, fast response
Communication planWho to notify, when, how
Tools readyForensic tools, isolation capabilities
Training and exercisesTabletop exercises, red team drills
Legal/compliance contactsKnow who to call for breach notification

Phase 2: Detection & Analysis#

ActivityPurpose
Alert triageDetermine if alert is real
Scope assessmentHow many systems affected?
Evidence preservationForensic images, log snapshots
Timeline constructionWhat happened, in what order
ClassificationType and severity of incident

Phase 3: Containment, Eradication, Recovery#

StepActions
Short-term containmentIsolate affected systems (network, disable accounts)
Evidence collectionMemory dumps, disk images, logs
EradicationRemove malware, close access, patch vulnerability
RecoveryRestore from clean backups, rebuild systems
ValidationVerify threat is eliminated, monitor for recurrence

Phase 4: Post-Incident#

ActivityOutput
Lessons learned meetingWhat worked, what didn’t
Root cause analysisWhy it happened, how to prevent
Detection improvementsNew rules, better coverage
Process updatesUpdated playbooks, procedures
MetricsTime to detect, contain, resolve

Incident Severity Classification#

SeverityDefinitionResponseExamples
SEV-1 (Critical)Active breach, data exfiltration, business downAll hands, war roomRansomware, active APT, mass data theft
SEV-2 (High)Confirmed compromise, containedIR team engagedCompromised server, stolen credentials in use
SEV-3 (Medium)Suspicious activity, unconfirmedInvestigationUnusual login patterns, malware detection
SEV-4 (Low)Policy violation, minor anomalyStandard processFailed login attempts, minor misconfiguration

Digital Forensics#

Evidence Handling#

PrincipleImplementation
Chain of custodyDocument who handled evidence, when, how
IntegrityHash everything (SHA-256) before and after analysis
PreservationWork on copies, never originals
Volatility orderCollect most volatile first (memory → disk → network → logs)

Forensic Data Sources#

SourceContainsVolatility
RAM (memory dump)Running processes, encryption keys, network connectionsVery high (lost on reboot)
Disk imageFiles, deleted files, logs, artifactsLow
Network captureTraffic content, connectionsMedium (if not captured, lost)
Cloud logsAPI calls, access patternsLow (if retained)
Endpoint telemetryProcess trees, file changesLow (if EDR deployed)

Memory Forensics#

What you can find in a memory dump:

  • Running and recently terminated processes
  • Network connections (including encrypted)
  • Encryption keys (BitLocker, TLS session keys)
  • Injected code and rootkits
  • Command history
  • Credentials in memory

Threat Hunting#

Proactive search for threats that evade automated detection:

Hunting Approaches#

ApproachMethodExample
Hypothesis-driven“What if APT29 is in our network?”Search for known APT29 TTPs
IOC-drivenSearch for known indicatorsQuery logs for suspicious domains
Anomaly-drivenFind statistical outliersUnusual data volumes, rare processes
TTP-drivenSearch for technique patternsPowerShell downloading + executing

Hunting Loop#

flowchart LR
    Hypothesis["Form<br/>Hypothesis"] --> Collect["Collect<br/>Data"]
    Collect --> Analyze["Analyze<br/>& Search"]
    Analyze --> Finding{"Finding?"}
    Finding -->|Yes| Investigate["Investigate<br/>& Respond"]
    Finding -->|No| Refine["Refine<br/>Hypothesis"]
    Investigate --> Detect["Create<br/>Detection Rule"]
    Refine --> Hypothesis
    Detect --> Hypothesis

Breach Notification#

Regulatory Requirements#

RegulationNotification DeadlineWho to Notify
GDPR (EU)72 hoursSupervisory authority + affected individuals
NIS2 (EU)24h early warning, 72h fullNational CSIRT
HIPAA (US)60 daysHHS + affected individuals
PCI DSSImmediatelyCard brands + acquiring bank
SEC (US public companies)4 business daysSEC filing (8-K)

Key Takeaways#

  1. Detection speed matters most — MTTD determines breach impact
  2. Automate the repetitive — SOAR handles Tier 1 tasks, humans handle judgment
  3. Preparation is everything — playbooks, training, and tools BEFORE the incident
  4. Preserve evidence first — you can’t investigate what you didn’t collect
  5. Post-incident reviews improve everything — every incident is a learning opportunity
  6. Threat hunting finds what automation misses — proactive > reactive
  7. Know your notification obligations — GDPR 72h clock starts at awareness