Beginner's mistake I made: not setting expiration dates on IOCs.

A recurring pattern I've observed in deployments of CrowdStrike's Intelligence (Falcon Intelligence) is the ingestion of Indicators of Compromise (IOCs) without a defined expiration policy. This oversight, which I admittedly committed in my initial integration, creates significant operational debt over time. While the immediate goal of blocking known-bad entities is achieved, the long-term consequences impact system performance, increase alert fatigue, and can potentially lead to business disruption.

The core issue lies in the static nature of an IOC feed without a time-to-live (TTL). Threat intelligence is inherently temporal; IP addresses, domains, and file hashes associated with malicious activity often have a limited period of relevance. Adversaries rotate infrastructure, and benign entities may be reclaimed. A firewall rule or host-based IOC from 18 months ago is not just likely obsolete—it becomes a liability.

In my environment, the problem manifested in two key areas:

* **SQL Performance Degradation in the Falcon Platform:** The custom IOC tables, when allowed to grow unchecked, began to affect query performance for reporting. While CrowdStrike's backend is engineered for scale, our own custom dashboards and aggregation queries, which joined on these massive, ever-growing tables, saw marked latency increases. This required a subsequent tuning project to refactor queries and implement partitioning—work that could have been avoided.
* **Increased Cognitive Load for Analysts:** The volume of IOCs, without automated deprecation, led to a bloated detection surface. Every match against an old, potentially irrelevant indicator still generates an alert for review. This dilutes the signal-to-noise ratio and causes fatigue, increasing the risk that a truly critical, *current* alert might be missed in the noise.

The solution is straightforward in concept but requires discipline in process: enforce a TTL at the point of ingestion. CrowdStrike's API supports an `expiration` field for each IOC. The key is to set this field programmatically based on the type and source confidence of the indicator.

For example, a simple Python script for ingesting a feed might now include:

```python
import datetime

def create_ioc_payload(ioc_value, ioc_type, source):
payload = {
"type": ioc_type,
"value": ioc_value,
"policy": "detect",
"share_level": "red",
"source": source,
"description": f"Intel feed {source}"
}

# Set expiration based on IOC type and source confidence
if ioc_type in ["ipv4", "domain"]:
# High-churn infrastructure: expire in 30 days
expiration_days = 30
elif ioc_type == "md5":
# File hashes might have longer relevance, but still expire
expiration_days = 90
else:
# Default safe fallback
expiration_days = 60

expiration_time = datetime.datetime.utcnow() + datetime.timedelta(days=expiration_days)
payload["expiration"] = expiration_time.isoformat() + "Z"

return payload
```

Implementing this required a one-time cleanup of legacy IOCs, which can be done via bulk deletion using the API, filtering on those without an expiration date or with a date far in the past. The ongoing maintenance burden dropped substantially post-cleanup.

The lesson extends beyond CrowdStrike to any threat intelligence integration. Treating IOCs as ephemeral, cacheable data points with a defined lifecycle, rather than permanent fixtures, aligns the operational practice with the dynamic nature of the threat landscape itself. It's a fundamental shift from a "collect everything" mindset to a "manage for relevance" approach.