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
Trigger phrases:
"performing indicator lifecycle management"
"Indicator lifecycle management tracks IOCs from initial discovery through valida"
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
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
This section covers key concepts for performing indicator lifecycle management.
- Ensure all prerequisites are met before proceeding
- Follow the documented workflow steps in sequence
- Record results and any anomalies encountered during this phase
Indicator Lifecycle Phases
- Discovery: IOC first identified from threat intelligence, malware analysis, or incident response
- Validation: IOC verified against enrichment sources (VirusTotal, Shodan)
- Enrichment: Additional context added (WHOIS, passive DNS, threat actor attribution)
- Deployment: IOC pushed to detection systems (SIEM, IDS, firewall)
- Monitoring: Track hit rates, false positive rates, detection efficacy
- Review: Periodic assessment of IOC relevance and accuracy
- Retirement: IOC expired or removed based on aging policy
Confidence Decay
Indicator confidence decreases over time as adversaries rotate infrastructure. A time-based decay function reduces confidence scores automatically, ensuring old indicators do not generate excessive alerts. Typical half-life: IP addresses (30 days), domains (90 days), file hashes (365 days).
Quality Metrics
- Hit Rate: Percentage of deployed IOCs generating true positive alerts
- False Positive Rate: Percentage of IOC alerts that are benign
- Coverage: Percentage of known threat techniques with IOC coverage
- Freshness: Average age of active indicators in the database
Workflow
- Scope the task — define objectives, boundaries, and success criteria
- Gather information — collect all necessary data and context before proceeding
- Execute the core workflow — follow the domain-specific steps methodically
- Validate results — verify outputs against expected outcomes or baselines
- Document findings — record results, anomalies, and recommendations
Step 1: Implement IOC Lifecycle State Machine
from datetime import datetime, timedelta
from enum import Enum
class IOCState(Enum):
DISCOVERED = "discovered"
VALIDATED = "validated"
ENRICHED = "enriched"
DEPLOYED = "deployed"
MONITORING = "monitoring"
UNDER_REVIEW = "under_review"
RETIRED = "retired"
class IOCLifecycle:
def __init__(self, ioc_type, value, source, initial_confidence=50):
self.ioc_type = ioc_type
self.value = value
self.source = source
self.confidence = initial_confidence
self.state = IOCState.DISCOVERED
self.created = datetime.utcnow()
self.last_updated = datetime.utcnow()
self.last_seen = None
self.hit_count = 0
self.false_positive_count = 0
self.history = [{"state": "discovered", "timestamp": self.created.isoformat()}]
def transition(self, new_state: IOCState, reason=""):
self.state = new_state
self.last_updated = datetime.utcnow()
self.history.append({
"state": new_state.value,
"timestamp": self.last_updated.isoformat(),
"reason": reason,
})
def apply_decay(self):
"""Apply confidence decay based on IOC type half-life."""
half_lives = {"ip": 30, "domain": 90, "hash": 365, "url": 60}
half_life = half_lives.get(self.ioc_type, 90)
age_days = (datetime.utcnow() - self.created).days
decay_factor = 0.5 ** (age_days / half_life)
self.confidence = max(0, int(self.confidence * decay_factor))
def record_hit(self, is_true_positive=True):
self.hit_count += 1
self.last_seen = datetime.utcnow()
if not is_true_positive:
self.false_positive_count += 1
if self.false_positive_count > 3:
self.transition(IOCState.UNDER_REVIEW, "Excessive false positives")
def should_retire(self):
max_ages = {"ip": 90, "domain": 180, "hash": 730, "url": 120}
max_age = max_ages.get(self.ioc_type, 180)
age_days = (datetime.utcnow() - self.created).days
return age_days > max_age and self.hit_count == 0
Validation Criteria
- IOC lifecycle state machine transitions correctly between phases
- Confidence decay reduces scores based on IOC type half-life
- Hit rate and false positive tracking functional
- Aging policy automatically flags indicators for review/retirement
- Quality metrics dashboard shows IOC database health
When NOT to Use
- You don't have explicit written authorization to test
- Task is about defense/detection, not offense (use detection skills)
- You need to implement security controls (use implementing-* skills)
- Task requires compliance auditing (use auditing-* skills)
- You're investigating an incident (use incident response skills)
- Target is out of scope for your engagement
- Task is about vulnerability scanning only (use scanning tools)
Red Flags
- Performing actions without explicit written authorization from the asset owner
- Testing against production systems without a defined scope and rules of engagement
- Acting on threat intelligence without validating source reliability
- Sharing classified or sensitive indicators without proper handling procedures
- Alerting threat actors to detection capabilities through visible response actions
Verification
- All steps executed successfully against a test environment before production use
- Output documented with screenshots or logs demonstrating expected behavior
- Results validated against known-good baselines or reference implementations
- Documentation complete enough for another analyst to reproduce findings
References
Process
- Analyze the task requirements
- Apply domain expertise
- Verify output quality
Anti-Rationalization Table
| Rationalization |
Reality |
| "We are too small to be targeted" |
Automated attacks target everyone. Size does not matter. |
| "Security slows us down" |
A breach slows you down 100x more. Build security in from the start. |
| "We will fix it after launch" |
Vulnerabilities in production are exploited within hours. Fix before deploy. |
1---2name: performing-indicator-lifecycle-management3description: Use when indicator lifecycle management tracks IOCs from initial discovery through validation, enrichment, deployment, monitoring, and eventual retirement. This skill covers implementing systematic processes f4license: Apache-2.05---67# Performing Indicator Lifecycle Management89## Overview1011Indicator 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.121314## When to Use15**Trigger phrases:**16- "performing indicator lifecycle management"17- "Indicator lifecycle management tracks IOCs from initial discovery through valida"181920- When conducting security assessments that involve performing indicator lifecycle management21- When following incident response procedures for related security events22- When performing scheduled security testing or auditing activities23- When validating security controls through hands-on testing2425## Prerequisites2627- Python 3.9+ with `pymisp`, `requests`, `stix2` libraries28- MISP or OpenCTI instance for indicator storage29- SIEM with IOC watchlist capabilities (Splunk, Elastic)30- Understanding of IOC types, confidence scoring, and TLP classifications3132## Key Concepts3334This section covers key concepts for performing indicator lifecycle management.3536- Ensure all prerequisites are met before proceeding37- Follow the documented workflow steps in sequence38- Record results and any anomalies encountered during this phase39### Indicator Lifecycle Phases401. **Discovery**: IOC first identified from threat intelligence, malware analysis, or incident response412. **Validation**: IOC verified against enrichment sources (VirusTotal, Shodan)423. **Enrichment**: Additional context added (WHOIS, passive DNS, threat actor attribution)434. **Deployment**: IOC pushed to detection systems (SIEM, IDS, firewall)445. **Monitoring**: Track hit rates, false positive rates, detection efficacy456. **Review**: Periodic assessment of IOC relevance and accuracy467. **Retirement**: IOC expired or removed based on aging policy4748### Confidence Decay49Indicator confidence decreases over time as adversaries rotate infrastructure. A time-based decay function reduces confidence scores automatically, ensuring old indicators do not generate excessive alerts. Typical half-life: IP addresses (30 days), domains (90 days), file hashes (365 days).5051### Quality Metrics52- **Hit Rate**: Percentage of deployed IOCs generating true positive alerts53- **False Positive Rate**: Percentage of IOC alerts that are benign54- **Coverage**: Percentage of known threat techniques with IOC coverage55- **Freshness**: Average age of active indicators in the database5657## Workflow58591. **Scope the task** — define objectives, boundaries, and success criteria602. **Gather information** — collect all necessary data and context before proceeding613. **Execute the core workflow** — follow the domain-specific steps methodically624. **Validate results** — verify outputs against expected outcomes or baselines635. **Document findings** — record results, anomalies, and recommendations64### Step 1: Implement IOC Lifecycle State Machine6566```python67from datetime import datetime, timedelta68from enum import Enum6970class IOCState(Enum):71 DISCOVERED = "discovered"72 VALIDATED = "validated"73 ENRICHED = "enriched"74 DEPLOYED = "deployed"75 MONITORING = "monitoring"76 UNDER_REVIEW = "under_review"77 RETIRED = "retired"7879class IOCLifecycle:80 def __init__(self, ioc_type, value, source, initial_confidence=50):81 self.ioc_type = ioc_type82 self.value = value83 self.source = source84 self.confidence = initial_confidence85 self.state = IOCState.DISCOVERED86 self.created = datetime.utcnow()87 self.last_updated = datetime.utcnow()88 self.last_seen = None89 self.hit_count = 090 self.false_positive_count = 091 self.history = [{"state": "discovered", "timestamp": self.created.isoformat()}]9293 def transition(self, new_state: IOCState, reason=""):94 self.state = new_state95 self.last_updated = datetime.utcnow()96 self.history.append({97 "state": new_state.value,98 "timestamp": self.last_updated.isoformat(),99 "reason": reason,100 })101102 def apply_decay(self):103 """Apply confidence decay based on IOC type half-life."""104 half_lives = {"ip": 30, "domain": 90, "hash": 365, "url": 60}105 half_life = half_lives.get(self.ioc_type, 90)106 age_days = (datetime.utcnow() - self.created).days107 decay_factor = 0.5 ** (age_days / half_life)108 self.confidence = max(0, int(self.confidence * decay_factor))109110 def record_hit(self, is_true_positive=True):111 self.hit_count += 1112 self.last_seen = datetime.utcnow()113 if not is_true_positive:114 self.false_positive_count += 1115 if self.false_positive_count > 3:116 self.transition(IOCState.UNDER_REVIEW, "Excessive false positives")117118 def should_retire(self):119 max_ages = {"ip": 90, "domain": 180, "hash": 730, "url": 120}120 max_age = max_ages.get(self.ioc_type, 180)121 age_days = (datetime.utcnow() - self.created).days122 return age_days > max_age and self.hit_count == 0123```124125## Validation Criteria126127- IOC lifecycle state machine transitions correctly between phases128- Confidence decay reduces scores based on IOC type half-life129- Hit rate and false positive tracking functional130- Aging policy automatically flags indicators for review/retirement131- Quality metrics dashboard shows IOC database health132133## When NOT to Use134135- You don't have explicit written authorization to test136- Task is about defense/detection, not offense (use detection skills)137- You need to implement security controls (use implementing-* skills)138- Task requires compliance auditing (use auditing-* skills)139- You're investigating an incident (use incident response skills)140- Target is out of scope for your engagement141- Task is about vulnerability scanning only (use scanning tools)142143144## Red Flags145146- Performing actions without explicit written authorization from the asset owner147- Testing against production systems without a defined scope and rules of engagement148- Acting on threat intelligence without validating source reliability149- Sharing classified or sensitive indicators without proper handling procedures150- Alerting threat actors to detection capabilities through visible response actions151152## Verification153154- All steps executed successfully against a test environment before production use155- Output documented with screenshots or logs demonstrating expected behavior156- Results validated against known-good baselines or reference implementations157- Documentation complete enough for another analyst to reproduce findings158159## References160161- [MISP Indicator Lifecycle](https://www.misp-project.org/)162- [STIX Indicator Valid From/Until](https://docs.oasis-open.org/cti/stix/v2.1/stix-v2.1.html)163- [IOC Quality Framework](https://www.first.org/)164165## Process1661671. Analyze the task requirements1682. Apply domain expertise1693. Verify output quality170171## Anti-Rationalization Table172173| Rationalization | Reality |174|---|---|175| "We are too small to be targeted" | Automated attacks target everyone. Size does not matter. |176| "Security slows us down" | A breach slows you down 100x more. Build security in from the start. |177| "We will fix it after launch" | Vulnerabilities in production are exploited within hours. Fix before deploy. |