| name | performing-indicator-lifecycle-management |
| description | Indicator lifecycle management tracks IOCs from initial discovery through validation, enrichment, deployment, monitoring, and eventual retirement. This skill covers implementing systematic processes f |
| domain | cybersecurity |
| subdomain | threat-intelligence |
| tags | ["threat-intelligence","cti","ioc","mitre-attack","stix","indicator-lifecycle","ioc-management"] |
| version | 1.0 |
| author | mahipal |
| license | Apache-2.0 |
| nist_csf | ["ID.RA-01","ID.RA-05","DE.CM-01","DE.AE-02"] |
Performing Indicator Lifecycle Management
Overview
Indicator lifecycle management tracks IOCs from initial discovery through validation, enrichment, deployment, monitoring, and eventual retirement. This skill covers implementing systematic processes for IOC quality assessment, aging policies, confidence scoring decay, false positive tracking, hit-rate monitoring, and automated expiration to maintain a high-quality, actionable indicator database that minimizes analyst fatigue and maximizes detection efficacy.
When to Use
- When conducting security assessments that involve performing indicator lifecycle management
- When following incident response procedures for related security events
- When performing scheduled security testing or auditing activities
- When validating security controls through hands-on testing
Detection Gaps & Validation
- Quality gaps before deployment: IOCs ingested from feeds without validation poison detection - a domain on a CDN, a shared-hosting IP, or a sinkholed C2 generates endless false positives. Validate every indicator against enrichment (VirusTotal detection ratio, Shodan/passive DNS, WHOIS age) and tag shared-infrastructure indicators as low-confidence or context-only, never block.
- Decay is an assumption, not truth: the half-life model (IP 30d, domain 90d, hash 365d) is a heuristic; a long-lived bulletproof-hosted C2 or a still-circulating malware hash can outlive its window. Override decay with observed
last_seen and hit data rather than trusting the curve blindly.
- Hit-rate blind spots: an IOC with zero hits may be stale or the data source feeding the detection may have no visibility (no DNS logs, no TLS inspection). Distinguish "no hits because retired threat" from "no hits because no telemetry" before retiring.
- How to confirm before retiring: cross-reference a retirement candidate against current feeds and passive DNS; if the infrastructure still resolves/responds, extend rather than expire. Track false-positive provenance so one noisy analyst report does not retire a valid indicator.
Prerequisites
- Python 3.9+ with
pymisp, requests, stix2 libraries
- MISP or OpenCTI instance for indicator storage
- SIEM with IOC watchlist capabilities (Splunk, Elastic)
- Understanding of IOC types, confidence scoring, and TLP classifications
Key Concepts
Indicator Lifecycle Phases
- Discovery: IOC first identified from threat intelligence, malware analysis, or incident response
