/ioc-development

name: ioc-development
description: >-
  Extract and operationalize indicators (IOCs) and behaviors (IOAs) from an incident
  or sample — atomic, computed, and behavioral — and prepare them for detection,
  blocking, and intel sharing. Use after/within an investigation to turn findings
  into defensive value.

Goal

A structured, prioritized indicator set that drives detection and containment, with behaviors (not just atomic indicators) captured so the adversary pays to evade.

Indicator types (climb the Pyramid of Pain)

• **Atomic** — hashes, IPs, domains, URLs, email addresses (easy for the adversary

to change; useful for fast blocking).

• **Computed** — regexes, YARA conditions, certificate/JA3 hashes, registry/file

patterns.

• **Behavioral (IOAs / TTPs)** — the actions and techniques (ATT&CK) — the most

durable and the priority to capture.

Steps

1. **Extract** from forensic findings/sample: files, network, host, and behavioral indicators. Note context (where seen, confidence, observation time). 2. **Validate** — filter out benign/legitimate indicators (e.g. shared CDNs, common LOLBins) to avoid false-positive-heavy blocks. 3. **Prioritize** — emphasize behavioral/TTP indicators over fragile atomic ones; mark which are safe to block vs. monitor-only. 4. **Operationalize** —

• Detection: hand TTPs/patterns to `detection-engineering:detection-rule-development`.
• Blocking: provide atomic indicators for blocklists (with caveats).
• Intel: structure for sharing (`threat-intelligence`), ideally STIX-friendly.

Output

An indicator set: indicator · type · context · confidence · block/monitor · ATT&CK mapping. Feeds `detection-engineering` and `threat-intelligence`.

Notes

Atomic indicators are cheap to rotate — lead with **behavioral** indicators for durable defense. Always validate before blocking: a shared IP or common binary on a blocklist causes outages and alert fatigue. Record confidence so downstream consumers can weigh each indicator.