security-operations

# Security Operations Skill

Guide a complete SOC operating cycle from daily alert triage to compliance reporting.
Each phase includes entry criteria, required inputs, and measurable outputs.

## Phase Map

```
Phase 1 → Alert Triage              [read: references/alert-triage.md]
Phase 2 → Threat Intelligence       [read: references/threat-intelligence.md]
Phase 3 → Vulnerability Management  [read: references/vulnerability-management.md]
Phase 4 → Incident Detection        [read: references/incident-detection.md]
Phase 5 → Incident Response         [read: references/incident-response.md]
Phase 6 → Post-Incident Review      [read: references/post-incident-review.md]
Phase 7 → Security Metrics          [read: references/security-metrics.md]
Phase 8 → Compliance Reporting      [read: references/compliance-reporting.md]
Phase 9 → Detection Validation      [read: references/detection-validation.md]
```

## Output Format

Each phase produces structured outputs: alert disposition (Phase 1), intelligence report (Phase 2), patching plan (Phase 3), incident declaration (Phase 4), IR timeline (Phase 5), PIR action items (Phase 6), metrics dashboard (Phase 7), compliance evidence package (Phase 8).


## alert-triage

# Alert Triage — Reference

**Entry Criteria:** SIEM alert generated with severity Medium or above; or analyst-escalated ticket from Tier 1 queue.

**Required Inputs:** Alert details (source, rule, timestamp), asset inventory (CMDB), threat intel platform access.

## Enrichment Sources Table

| Enrichment Type | Source | Purpose |
|----------------|--------|---------|
| Asset context | CMDB / ServiceNow | Owner, tier, business function |
| Threat intel | VirusTotal, MISP, ThreatConnect | IOC reputation, known campaign |
| User context | Active Directory / IdP | Account type, recent activity, department |
| Vulnerability context | Tenable / Qualys | Is affected asset unpatched? |
| Previous incidents | SIEM / ticketing | Has this asset or user appeared in prior incidents? |
| Geo / IP reputation | MaxMind, AbuseIPDB | Is source IP from unexpected country or known malicious range? |

## Triage SLAs Table

| Priority | Trigger | Acknowledge | Initial Assessment | Escalation |
|----------|---------|-------------|-------------------|-----------|
| P1 — Critical | Active breach, ransomware, C2 comms | 5 minutes | 15 minutes | Immediate to IC + CISO |
| P2 — High | Confirmed compromise indicator on Tier 1/2 asset | 15 minutes | 30 minutes | Within 30 min to Security Manager |
| P3 — Medium | Suspicious activity requiring investigation | 30 minutes | 2 hours | Escalate if investigation confirms compromise |
| P4 — Low | Policy violation, informational | 4 hours | 8 hours | Self-service; no escalation unless scope expands |

## Triage Decision Tree

```
Alert received
    │
    ├─► Is this a known false-positive rule? (check exclusion list)
    │       YES → Close as FP; log suppression candidate
    │       NO  ↓
    │
    ├─► Enrich: asset tier + IOC reputation + user context
    │       ↓
    ├─► Is the asset a Tier 1/2 crown jewel?
    │       YES → Immediate P1/P2 declaration; notify IC
    │       NO  ↓
    │
    ├─► Does threat intel confirm malicious IOC?
    │       YES → Escalate to incident; create INC ticket
    │       NO  ↓
    │
    └─► Analyst judgment — investigate further or close with documentation
```

**Outputs:** Incident ticket (if escalated); FP report (if false positive); closed alert with justification (if benign).



## threat-intelligence

# Threat Intelligence — Reference

**Entry Criteria:** Daily intelligence cycle; new threat actor campaign reported; pre-hunt hypothesis generation; post-incident enrichment.

**Required Inputs:** Threat intel platform (MISP, ThreatConnect, or equivalent), ISAC membership, open-source feeds.

## Intelligence Cycle

```
1. Direction    — What questions does the SOC need answered?
2. Collection   — Gather raw data from all sources
3. Processing   — Normalise into structured format (STIX 2.1)
4. Analysis     — Assess relevance, confidence, and applicability
5. Dissemination — Share finished intel to consumers (SOC, IR, risk)
6. Feedback     — Consumers confirm usefulness; adjust direction
```

## Collection Sources Table

| Source | Type | Reliability Rating | Format |
|--------|------|--------------------|--------|
| FS-ISAC / H-ISAC (sector ISAC) | Sector-specific | High (vetted peers) | STIX, PDF, email |
| CISA Advisories | Government | High | PDF, STIX, YARA |
| MITRE ATT&CK STIX feed | Framework | High | STIX 2.1 |
| VirusTotal Intelligence | Commercial | Medium-High | JSON API |
| AlienVault OTX | Open source | Medium | STIX, CSV |
| Twitter / X threat intel community | Social | Low-Medium (verify before use) | Unstructured |
| Vendor threat intel reports (CrowdStrike, Mandiant) | Commercial | High | PDF, structured |
| Dark web monitoring service | Commercial | Medium | Alerts |

## IOC Confidence Scoring

| Confidence Level | Criteria | Action |
|-----------------|----------|--------|
| High (3) | Confirmed by ≥ 2 independent sources; directly observed in attack against org or close peer | Block immediately; alert on all activity |
| Medium (2) | Single trusted source; corroborated by behavioural indicators | Alert on activity; investigate within 24h |
| Low (1) | Single unverified source; no direct relevance | Watch list; do not block; review weekly |

## Intelligence Outputs

- **Threat intelligence bulletin** — weekly summary for security leadership
- **IOC blocklist** — IP/domain/hash feeds pushed to SIEM and EDR
- **ATT&CK technique coverage update** — new techniques observed → detection gap review
- **Hunt hypothesis** — new actor/campaign triggers proactive hunt (feed to threat-hunting skill)
- **Vulnerability prioritisation input** — CVEs being actively exploited by tracked actors → escalate priority



## vulnerability-management

# Vulnerability Management — Reference

**Entry Criteria:** Scheduled scan cycle; new CVE published with CVSS ≥ 7.0; CISA KEV update; post-change scan.

**Required Inputs:** Vulnerability scanner (Tenable/Qualys), asset inventory (CMDB), CISA KEV catalogue, patch management tooling.

## SSVC-Aligned Priority Table

Stakeholder-Specific Vulnerability Categorisation (SSVC) augments CVSS with exploitation evidence and mission impact.

| Priority | SSVC Decision | CVSS Range | CISA KEV | Action | SLA |
|----------|--------------|-----------|---------|--------|-----|
| Immediate | Act Now | Any | Yes | Emergency patch; out-of-band maintenance window | 24 hours |
| Out-of-Cycle | High urgency | ≥ 9.0 | No | Patch in next available window; do not wait for monthly cycle | 72 hours |
| Scheduled | Standard | 7.0–8.9 | No | Include in next monthly patch cycle | 14 days |
| Defer | Low urgency | < 7.0 | No | Accept risk until next quarterly cycle; document justification | 90 days |

## Vulnerability Workflow Decision Tree

```
Scan complete → CVE found
    │
    ├─► In CISA KEV?
    │       YES → Priority: Immediate → 24-hour SLA
    │       NO  ↓
    │
    ├─► CVSS ≥ 9.0 AND remotely exploitable?
    │       YES → Priority: Out-of-Cycle → 72-hour SLA
    │       NO  ↓
    │
    ├─► Asset is Tier 1/2 AND CVSS ≥ 7.0?
    │       YES → Priority: Scheduled accelerated → 7 days
    │       NO  ↓
    │
    └─► Standard scheduled patching → 14–90 days by severity
```

## Vulnerability ≠ Exposure ≠ Exploitability

CVSS and KEV prioritise *which* vulnerabilities to act on; they do not establish that a
given asset is actually exploitable. Keep these as separate claims, each with its own
evidence:

| Claim | Established by | Not established by |
|-------|---------------|-------------------|
| Vulnerability applies | Authenticated inventory (version/config) | Scanner banner inference alone |
| Asset is reachable | Network-path evidence from the relevant position | A CVSS "network" vector |
| Asset is exploitable | A completed authorized validation with evidence | Scanner "critical" rating |

A scanner reporting 4,000 criticals has measured the scanner. The question the business
asks is which handful are reachable and exploitable to something that matters — that is
`exposure-validation`, which this workflow feeds and consumes.

## Closure Requires Retest, Not a Ticket

A patch marked "applied" is not a closed exposure. Before an item is closed:

```
1. Re-scan / re-inventory the asset       — confirm the vulnerable version/config is gone
2. For items that were validated exploitable: re-run the original proof
   (via exposure-validation) and confirm it no longer succeeds
3. Record before/after evidence and the risk delta
4. Close as VERIFIED, or REOPEN with the reason (fix not applied, asset rebuilt, rollback)
```

A failed retest is `REOPENED`, never silently left closed. "Ticket says done" is the
failure mode this gate exists to catch — the detailed loop is in `exposure-validation`
remediation-verification.

## Monthly Metrics

| Metric | Target | Measurement |
|--------|--------|-------------|
| Immediate priority patch rate | 100% within 24h | Scan vs patch timestamp |
| Out-of-cycle patch rate | 100% within 72h | Scan vs patch timestamp |
| Scheduled patch compliance | ≥ 95% within 14 days | Vuln scanner report |
| Mean Time to Patch (Critical) | < 72 hours | Ticket lifecycle |
| Scanner coverage | ≥ 98% of in-scope assets | Scanner vs CMDB |
| CISA KEV open items | 0 beyond SLA | KEV cross-reference |

**Outputs:** Patch compliance dashboard; exception register; CISA KEV tracking; board-level metrics (open Critical/High count trend).



## incident-detection

# Incident Detection — Reference

**Entry Criteria:** SIEM alert escalated from triage as potential incident; analyst judgment during threat hunt; external notification (partner, vendor, regulator, law enforcement).

**Required Inputs:** Alert details, enrichment data, asset inventory, ATT&CK reference.

## Scope Questions Tree

When a potential incident is identified, answer these questions in order:

```
1. What systems are affected?
   → List hostnames/IPs; assign asset tiers
   
2. What is the attacker's current position?
   → Initial access only? Lateral movement detected? Persistence established?
   
3. What data may be at risk?
   → Map affected systems to data classifications (PII, PAN, trade secrets)
   
4. How long has the attacker been present?
   → MTTD: earliest indicator timestamp vs detection time
   
5. Is the attack ongoing or complete?
   → Active C2 comms? Ongoing encryption? Or historical artefacts only?
```

## ATT&CK Tactic Detection Table

| ATT&CK Tactic | What to Look for in Logs |
|--------------|--------------------------|
| Initial Access (TA0001) | Email gateway: phishing links/attachments opened; WAF: exploit payloads against public apps; VPN: unusual source IPs or off-hours logins |
| Execution (TA0002) | Sysmon EID 1: cmd.exe / PowerShell spawned by Office process; script engine invocations; encoded commands |
| Persistence (TA0003) | Security EID 4698: scheduled task created; EID 4697: service installed; registry run key modifications |
| Privilege Escalation (TA0004) | EID 4672: special privileges assigned; LSASS access (Sysmon EID 10); token manipulation |
| Defence Evasion (TA0005) | Security tool process terminated; event log cleared (EID 1102); LOLBin execution (certutil, mshta, regsvr32) |
| Credential Access (TA0006) | Sysmon EID 10 targeting lsass.exe; large volumes of Kerberos TGS requests (Kerberoasting); NTLM relay attempts |
| Discovery (TA0007) | EID 4661: AD object enumeration; nmap/ping sweep in NetFlow; net commands (net user, net group) |
| Lateral Movement (TA0008) | SMB connection to admin shares (EID 5140); WMI/PSExec execution; RDP logon from unusual source |
| Command and Control (TA0011) | Regular-interval outbound connections; DNS to DGA domains; HTTPS to newly registered/low-reputation domains |
| Exfiltration (TA0010) | Large outbound data volume spikes; archive file creation before exfil; cloud sync tool invocation |

## Severity Declaration Criteria

| Severity | Conditions | Declare Within |
|----------|-----------|---------------|
| P1 | Active data exfiltration; ransomware encryption; Tier 1 asset fully compromised | 15 minutes |
| P2 | Confirmed adversary in network; Tier 2 asset compromised; lateral movement detected | 30 minutes |
| P3 | Suspicious activity on single endpoint; unconfirmed compromise indicator | 2 hours |
| P4 | Policy violation; no confirmed compromise | 4 hours |

**Outputs:** Incident declaration (if criteria met); severity assignment; initial scope assessment; notification to Incident Commander.



## incident-response

# Incident Response — Reference

**Entry Criteria:** Incident declared at P1/P2/P3; Incident Commander assigned; initial scope completed.

**Required Inputs:** Incident ticket, scope assessment, EDR console access, network isolation capability, forensic tooling.

## PICERL Framework

### Preparation
Ongoing activities before any incident:
- IR plan documented, approved, and tested via tabletop exercise annually
- Incident Commander (IC) and backup IC identified and trained
- Contact list current: Legal, HR, DPO, PR, executive team, law enforcement liaison
- Out-of-band communications channel established (separate from potentially compromised email)
- EDR isolation capability tested; break-glass credentials in PAM vault
- Forensic collection kit pre-staged: KAPE, Velociraptor agent, FTK Imager

### Identification
- Confirm incident type (malware, insider, DDoS, data breach, ransomware)
- Assign severity (P1–P4) based on scope
- Activate appropriate IR playbook
- Open incident ticket; assign IC

### Containment

**Immediate containment (P1: within 1 hour; P2: within 4 hours):**

```
1. Network isolate compromised hosts via EDR console
2. If EDR unavailable: disable network port at switch level
3. Revoke active sessions for compromised accounts (force re-auth)
4. Block IOCs at perimeter (IP/domain/hash) in firewall and proxy
5. Preserve memory before isolation if forensically required
6. Do NOT reimage before evidence collection is complete
```

**Short-term containment:**
- Reset credentials for all accounts that authenticated on compromised hosts
- Disable affected service accounts
- Rotate secrets/API keys that may have been exposed

### Eradication
- Remove all attacker artefacts: malware files, persistence mechanisms, rogue accounts
- Patch exploited vulnerability or disable exploited feature
- Confirm no backdoors remain (golden ticket/skeleton key check for AD incidents)

### Recovery
- Reimage or restore from last-known-good snapshot
- Re-enrol in EDR with fresh policy
- Monitor for re-compromise for 72 hours post-recovery
- Restore service with enhanced monitoring in place

### Lessons Learned (See post-incident-review phase)

## Immediate Containment Steps by Incident Type

| Incident Type | Priority 1 Action | Priority 2 Action |
|--------------|------------------|------------------|
| Ransomware | Network isolate ALL infected hosts; disable admin shares | Contact cyber insurance; preserve encrypted files for recovery |
| Data exfiltration | Block exfil destination IPs/domains; quarantine source host | Determine scope of data accessed; prepare regulatory notification |
| Account compromise | Force password reset + revoke all sessions + disable account | Review all activity since compromise date |
| Insider threat | Preserve HR/legal privilege; do not alert user; collect evidence | Involve Legal/HR immediately |
| DDoS | Enable scrubbing service; activate CDN; notify ISP | Monitor for follow-on intrusion attempt during DDoS distraction |



## post-incident-review

# Post-Incident Review — Reference

**Entry Criteria:** Incident closed (all P1/P2 incidents); recommended for P3; optional for P4. Conduct PIR within 5 business days of incident closure.

**Required Inputs:** Incident ticket, timeline, metrics (MTTD/MTTC/MTTR), attending stakeholders.

## PIR Agenda

| Agenda Item | Duration | Purpose |
|-------------|----------|---------|
| Timeline review | 15 min | Walk through key events chronologically; confirm facts |
| Detection assessment | 10 min | When was the incident first detectable? When was it actually detected? |
| Response assessment | 10 min | Were containment, eradication, and recovery timely and effective? |
| Root cause analysis | 20 min | 5 Whys methodology (see below) |
| Action items | 15 min | Assign owners and due dates for improvements |
| Lessons learned summary | 10 min | What should we start, stop, and continue? |

**Ground rules:** Blameless culture. Focus on processes and systems, not individuals. PIR findings are used for improvement, not discipline (unless gross negligence is involved — handle separately via HR).

## 5 Whys Root Cause Example

**Incident:** Ransomware encrypted 40 servers before detection.

| Why # | Question | Answer |
|-------|----------|--------|
| Why 1 | Why were 40 servers encrypted? | Ransomware spread via SMB before containment |
| Why 2 | Why did it spread so quickly via SMB? | No internal segmentation between server VLAN and backup network |
| Why 3 | Why was there no segmentation? | Segmentation project deprioritised in last budget cycle |
| Why 4 | Why was it deprioritised? | No risk register entry quantifying the risk |
| Why 5 | Why was there no risk register entry? | No formal threat modelling process for infrastructure |

**Root Cause:** Absence of a threat modelling process led to an unquantified segmentation risk being deprioritised.

## Action Item Template

| ID | Finding | Action Required | Owner | Due Date | Priority | Status |
|----|---------|----------------|-------|----------|---------|--------|
| PIR-001 | No SMB segmentation between server and backup VLANs | Implement firewall rule blocking SMB between VLANs | Network Team | 2025-07-15 | P1 | Open |
| PIR-002 | Detection delayed by 6 hours due to SIEM rule gap | Create detection rule for lateral SMB movement | SOC | 2025-07-08 | P1 | Open |

## Metrics to Capture

| Metric | Definition | This Incident | Target |
|--------|-----------|--------------|--------|
| MTTD — Mean Time to Detect | Time from first evidence of attack to detection | [X hours] | < 1 hour for P1 |
| MTTC — Mean Time to Contain | Time from detection to containment | [X hours] | < 4 hours for P1 |
| MTTR — Mean Time to Recover | Time from containment to full service recovery | [X hours] | < 24 hours for P1 |
| Alert-to-Incident conversion rate | % of triaged alerts escalated to incidents | [X%] | Baseline and trend |
| Runbook adherence | Were all steps in the IR runbook followed? | Yes/No/Partial | 100% |



## security-metrics

# Security Metrics — Reference

**Entry Criteria:** Monthly/quarterly reporting cycle; board presentation preparation; programme health review; budget justification.

**Required Inputs:** SIEM data, ticketing system (MTTD/MTTC/MTTR), vulnerability scanner reports, EDR telemetry, patch management data.

## Tier 1 — Operational Metrics (SOC daily/weekly)

| Metric | Definition | Measurement Source | Target |
|--------|-----------|-------------------|--------|
| Mean Time to Detect (MTTD) | Average time from first malicious event to alert | SIEM: earliest event timestamp vs alert creation time | Trending down; < 1 hour for P1 |
| Mean Time to Contain (MTTC) | Average time from alert to containment action | Incident ticket: created vs contained timestamp | < 4 hours P1; < 24 hours P2 |
| Mean Time to Recover (MTTR) | Average time from containment to full service restoration | Incident ticket: contained vs resolved timestamp | < 24 hours P1 |
| Alert-to-Incident Ratio | % of SIEM alerts that become confirmed incidents | Tickets created vs alerts generated | Baseline; use to detect alert fatigue |
| False Positive Rate | % of alerts closed as false positive | FP tickets / total alerts | < 20% (high FP rate = rule quality issue) |
| Alert Volume per Analyst per Day | Total alerts / analyst headcount / working days | SIEM + headcount | Sustainable: < 30 quality alerts/day |

## Tier 2 — Programme Metrics (Monthly/Quarterly for management)

| Metric | Definition | Target |
|--------|-----------|--------|
| Critical/High Vulnerabilities Open | Count of unpatched Critical/High CVEs beyond SLA | Zero Critical beyond SLA |
| Patch Compliance Rate | % of in-scope assets patched within SLA | ≥ 95% |
| EDR Coverage | % of in-scope endpoints with active EDR | ≥ 98% |
| Security Awareness Training Completion | % of staff completing mandatory training | ≥ 95% |
| Phishing Simulation Click Rate | % of simulated phishing emails clicked | < 5% (trending down) |
| Incidents by Category | Count of incidents per type (malware/insider/DDoS etc.) | Baseline and trend |
| Mean Cost per Incident | Total IR cost / number of incidents | Baseline; demonstrate ROI of investments |

## RAG Status Explanation

Use RAG (Red/Amber/Green) status on all metric dashboards:

| Status | Colour | Meaning | Action |
|--------|--------|---------|--------|
| Green | Within target or better | No action required; continue monitoring | — |
| Amber | Within 20% of target threshold | Monitor closely; identify root cause; remediation plan within 2 weeks | Owner to present plan at next review |
| Red | Beyond target threshold; significant concern | Immediate escalation; executive awareness; remediation plan within 72 hours | CISO briefing; board notification if material |

## Executive Dashboard Template

Present four key metrics to board/exec monthly:
1. **Incident count and severity trend** — are incidents increasing or decreasing?
2. **MTTD/MTTR trend** — is the team detecting and responding faster?
3. **Critical vulnerability exposure** — how many critical CVEs are open beyond SLA?
4. **Programme maturity score** — overall security posture (CMMI/NIST CSF tier)



## compliance-reporting

# Compliance Reporting — Reference

**Entry Criteria:** Scheduled audit preparation; external audit notification received; certification renewal; regulatory inquiry; post-incident regulatory obligation.

**Required Inputs:** Evidence collection outputs, security metrics, incident log, policy register, vulnerability management data.

## Framework-Specific Evidence Table

| Control Domain | ISO 27001:2022 | SOC 2 Type II | PCI DSS v4.0 | Evidence to Collect |
|---------------|---------------|--------------|--------------|---------------------|
| Access control | A.8.5 Identity Management | CC6.1 | Req 7, 8 | IAM export, access review records, MFA logs |
| Vulnerability management | A.8.8 | CC7.1 | Req 6, 11 | Scanner reports, patch compliance data, exception register |
| Logging and monitoring | A.8.15 | CC7.2 | Req 10 | SIEM config, log retention policy, alert rules |
| Incident management | A.5.26 | CC7.4 | Req 12.10 | Incident register, PIR outputs, IR test records |
| Change management | A.8.32 | CC8.1 | Req 6.3 | Change tickets, approvals, CAB minutes |
| Encryption | A.8.24 | CC6.7 | Req 3, 4 | Encryption-at-rest proof, TLS scan results |
| Physical security | A.7.2 | CC6.4 | Req 9 | Visitor logs, CCTV policy, data centre access records |
| Business continuity | A.5.29 | A1.2 | Req 12.3 | BCP/DR plan, test results, RTO/RPO documentation |
| Third-party risk | A.5.19 | CC9.2 | Req 12.8 | Vendor assessment records, contracts, review schedule |
| Security awareness | A.6.3 | CC2.2 | Req 12.6 | Training completion records, phishing simulation results |

## Regulatory Notification Deadlines Table

| Regulation | Jurisdiction | Initial Notification Window | Notify Who | Trigger |
|------------|-------------|----------------------------|-----------|---------|
| GDPR Article 33 | EU / EEA | 72 hours from becoming aware | National supervisory authority (e.g., ICO) | Personal data breach with risk to individuals |
| GDPR Article 34 | EU / EEA | Without undue delay | Affected individuals | High risk to rights and freedoms |
| HIPAA Breach Notification | USA | 60 days from discovery | HHS OCR + affected individuals (media if >500 in state) | Breach of unsecured PHI |
| NIS2 Article 23 | EU | 24 hours (early warning); 72 hours (notification); 1 month (final) | National CSIRT / competent authority | Significant incident on essential/important entity |
| PCI DSS | Global | Immediately (24 hours) | Acquiring bank + card brands | Suspected or confirmed account data compromise |
| SEC Rule 13a-15 / 15d-15 | USA (public companies) | 4 business days (8-K) | SEC public filing | Material cybersecurity incident |
| FCA SYSC 8.1 | UK (financial services) | As soon as reasonably practicable | FCA (and PRA if dual-regulated) | Significant operational incident |

## Evidence Collection Workflow

1. Map audit scope to framework controls (use table above)
2. Identify evidence owner per control domain
3. Collect evidence with timestamps and digital signatures where possible
4. Review for gaps — generate remediation actions for any missing evidence
5. Package evidence with control cross-reference index for auditor
6. Retain all audit evidence for minimum 3 years (or regulatory minimum if longer)

**Outputs:** Evidence package per framework; control test results; exception register with risk acceptance; compliance dashboard (RAG status per domain).



## detection-validation

# Detection Validation — Reference

Use this phase to prove the SIEM/SOC detection pipeline works end to end: that a known
technique produces telemetry, the telemetry becomes an alert, the alert reaches an
analyst, and the analyst acts. Detection content that was written but never exercised is
a hypothesis. This phase converts hypotheses into evidence.

## 1. The Pipeline Has Stages — Validate Each

An endpoint agent blocking a technique (see `endpoint-security` control-effectiveness)
is one thing; the *SOC* seeing and responding is another. The detection pipeline can
break at any stage, and each break has a different owner and fix.

```
TECHNIQUE EXERCISED
      ↓
TELEMETRY GENERATED    — did the source emit the event?            (sensor / log source)
      ↓
TELEMETRY INGESTED     — did it reach the SIEM, parsed?            (pipeline / parsing)
      ↓
DETECTION FIRED        — did a rule match?                         (detection content)
      ↓
ALERT RAISED           — did it surface to a queue, de-duped?      (alerting / tuning)
      ↓
ANALYST RECEIVED       — did a human/playbook pick it up?          (routing / staffing)
      ↓
RESPONSE TAKEN         — was action taken within SLA?              (process)
```

| Stage result | Values |
|--------------|--------|
| Telemetry | `GENERATED` · `NOT_GENERATED` |
| Ingestion | `INGESTED` · `DROPPED` · `UNPARSED` |
| Detection | `FIRED` · `NO_RULE` · `RULE_ERROR` |
| Alert | `RAISED` · `SUPPRESSED` · `BURIED` |
| Analyst | `RECEIVED` · `MISSED` |
| Response | `ACTIONED` · `NO_ACTION` |

Report the stage that broke, not just "not detected." The fixes are entirely different:
a `DROPPED` at ingestion is a pipeline problem; `NO_RULE` is a content problem;
`BURIED` is an alert-tuning problem; `MISSED` at the analyst stage is routing or
staffing. A single pass/fail hides which team needs to act.

## 2. Validation Record

Per technique exercised:

| Technique | Telemetry | Ingestion | Detection | Alert | Analyst | Response | Breaking stage | MTTD |
|-----------|-----------|-----------|-----------|-------|---------|----------|---------------|------|
| T1110 Password Spray | GENERATED | INGESTED | FIRED | RAISED | RECEIVED | ACTIONED | — (full) | 4 min |
| T1071 C2 over HTTPS | GENERATED | INGESTED | NO_RULE | — | — | — | Detection content | — |
| T1048 DNS Exfil | GENERATED | DROPPED | — | — | — | — | Ingestion (DNS logs not shipped) | — |

MTTD (time from technique to alert) and MTTR (alert to response) are measured here, from
real exercised events rather than estimated.

## 3. Detection Gaps Have Types

| Gap type | Symptom | Owner | Fix |
|----------|---------|-------|-----|
| Visibility | Telemetry never generated | Engineering | Enable the log source / sensor |
| Pipeline | Generated but dropped or unparsed | SIEM engineering | Fix routing / parser |
| Content | Ingested but no rule matched | Detection engineering | Write/adjust the rule |
| Tuning | Rule fired but alert suppressed or buried | Detection engineering | Fix thresholds / de-dup |
| Routing | Alert raised but no analyst saw it | SOC ops | Fix queue routing / coverage |
| Process | Analyst saw it, no action in SLA | SOC management | Playbook / staffing |

A "detection gap" reported without its type sends the wrong team to fix the wrong layer.

## 4. Tie to Attack Attempt and Controls

Detection validation is most powerful correlated with the attack attempt and the
endpoint control outcome, so one exercised technique produces a complete picture:

```
attack attempt (exposure-validation)
   → endpoint control outcome (endpoint-security control-effectiveness)
   → SOC detection pipeline (this phase)
   → tripwire signal (deception-engineering validation campaign, if placed)
```

When a deception tripwire is in the path, its firing is a high-confidence detection data
point — correlate it here (see `deception-engineering` validation-campaign-tripwires).

## 5. Regression and Drift

Detection content rots. Log sources get decommissioned, parsers break after a vendor
format change, rules get disabled during noise events and never re-enabled. Re-run
detection validation:

```
after a SIEM / pipeline change          after a log-source or format change
after detection-rule changes            periodically as baseline regression
after an analyst reports "we should have caught that"
```

A rule that fired last quarter and is `NO_RULE` or `DROPPED` this quarter is a
regression — coverage silently decayed.

## 6. Honest Reporting

Report what was exercised and observed, scoped to the environment and time. "We
validated 40 techniques; 31 produced an actioned alert, 5 failed at ingestion (DNS logs
not shipped), 4 had no detection content" is useful and true. "Our detection coverage is
78%" without saying which techniques, against which log sources, at what time, is a
number that cannot be acted on or trusted.

## ATT&CK Mapping
Detection validation exercises techniques across the matrix — commonly T1110
Brute Force, T1071 Application Layer Protocol, T1048 Exfiltration Over Alternative
Protocol, T1021 Remote Services, T1003 OS Credential Dumping — recording the pipeline
outcome per technique rather than a coverage percentage.



## live-threat-intel

# Live Threat Intel — security-operations

<!-- BEGIN AEGIS-INTEL-SYNC — auto-generated, do not edit by hand -->

_Auto-generated by `scripts/intel-sync.js` on 2026-08-22 from the operator's threat-intel corpus (window: last 7 days). Regenerable — do not hand-edit inside these markers. Human-authored tradecraft lives in the other reference files and is never modified by this process._

## Current Observations (2026-08-22)

**Routed to this skill:** 32 feed item(s), 0 teardown(s).

| Date | Observation | CVEs | Actors | Source |
|------|-------------|------|--------|--------|
| 2026-08-13 | Halcyon: 'The Gentlemen' Ransomware Group Scaling Faster Than Any RaaS Operation on Record | — | Thegentlemen, Qilin | Halcyon |
| 2026-08-14 | ShinyHunters Leaks Carhartt Data After Blaming Company's "Incompetent" Ransom Negotiator | — | ShinyHunters | Cybernews |
| 2026-08-14 | ShinyHunters Claims Sharecare Breach, 3.4 Million Salesforce Records Stolen | — | ShinyHunters | ransomware.live |
| 2026-08-14 | Thegentlemen Ransomware Claims Italian Firm I.P.S. Srl | — | Thegentlemen | ransomware.live |
| 2026-08-14 | SilentRansomGroup Claims Ohio Law Firm Reminger | — | SilentRansomGroup | ransomware.live |
| 2026-08-16 | Qilin Ransomware Claims Canadian Tech Firm MOSAID Technologies | — | Qilin | RedPacket Security |
| 2026-08-15 | Xpl0itrs Ransomware Claims Software Supply-Chain Security Platform RapidFort | — | Xpl0itrs | ransomware.live |
| 2026-08-14 | Canadian Software Firm Portable Intelligence Breached by Blacknevas | — | Blacknevas | BrightDefense/ransomware.live |
| 2026-08-14 | Shell Investigates Clop Ransomware Claim of 89GB Stolen Data | — | Cl0p | BleepingComputer |
| 2026-08-17 | Ransomhub Claims Australian Caravan Manufacturer Regent Caravans | — | Ransomhub | Ransomware.live |
| 2026-08-15 | Direwolf Ransomware Claims Brazil's Largest ERP Vendor TOTVS | — | Direwolf | DeXpose |
| 2026-08-15 | Barracuda Ransomware Group Claims Brazilian Law Firm VR Advogados | — | Barracuda ransomware group | Ransomware.live |

### Actors named

Qilin (x5), Thegentlemen (x2), ShinyHunters (x2), Cl0p (x2), Gunra (x2), SilentRansomGroup, Xpl0itrs, Blacknevas, Ransomhub, Direwolf, Barracuda ransomware group, The Gentlemen, Storm-1175, Clop, Incransom

_Attribution is context, not conclusion — treat named actors as reported by the source, with the source's confidence, and prefer TTP-driven action over actor-driven action._

### Trending in the knowledge graph (relevant to this surface)

Qilin (seen 66x, last 2026-08-13) · Shinyhunters (seen 45x, last 2026-08-13) · Akira (seen 21x, last 2026-08-11) · Microsoft (seen 207x, last 2026-08-13) · Check Point (seen 29x, last 2026-08-13)

### Coverage questions raised by this period

- Dominant themes: ransomware (x30), leak-site (x9), extortion (x6) — confirm controls address the recurring mechanism, not just individual incidents

_These are prompts for verification, not confirmed gaps. Confirm against actual controls before treating any as covered or open — an unvalidated detection is partial coverage, not coverage._

<!-- END AEGIS-INTEL-SYNC -->