Guide: Automating IOCs from Intel into our WAF.

As practitioners responsible for both security posture and operational efficiency, we often face the challenge of operationalizing threat intelligence. A recurring pain point in my own revenue operations environment—which handles sensitive customer data—is the latency between identifying a new threat indicator in a feed like CrowdStrike Intel and deploying a proactive block at the perimeter. Manual ingestion is not scalable.

This post details a methodical, automated workflow we built to parse CrowdStrike Intel for specific types of IOCs (primarily malicious IPs and domains associated with credential phishing and brute-force campaigns) and push them as deny rules into our cloud-based Web Application Firewall (WAF). The goal is to reduce the mean time to mitigation from hours to minutes, with full audit trails. I will focus on the architecture and integration points, rather than vendor-specific WAF syntax.

**Our Core Requirements & Platform Choices**
We needed a system that was:
* Trigger-based: reacting to new Intel alerts or daily digest reports.
* Parsing-capable: extracting structured data from CrowdStrike's JSON API output.
* Filtering-capable: applying our own risk logic (e.g., only IPs from certain ASNs, confidence scores above 80).
* Integration-ready: able to execute API calls to our WAF provider (in this case, AWS WAFv2 but the pattern applies to others like Cloudflare or Azure).
* Logging-centric: every automated action recorded in our SIEM.

We evaluated using native SOAR platforms, but for cost and control reasons, we built this using a combination of:
1. **CrowdStrike Falcon Fusion Workflows** (to act as the initial trigger and context enrichment).
2. **A dedicated, lightweight Python microservice** (hosted in a serverless environment) for the complex parsing and business logic.
3. **The WAF's native REST API** for the final rule insertion.

**The Step-by-Step Automation Flow**
Our current implementation follows this sequence:

* **Trigger:** A new Intel report is published matching our subscribed criteria (e.g., "Credential Phishing Infrastructure").
* **Initial Data Fetch:** A Fusion Workflow is triggered automatically. Its first action is to fetch the full IOC list from the Intel report via the `/intel/entities/indicators/v1` endpoint, requesting the JSON format.
* **Data Handoff:** The enriched JSON payload is sent via HTTPS POST to our microservice's ingestion endpoint.
* **Processing & Filtering:** The microservice performs several logical steps:
* Validates the IOC list, discarding any expired or low-confidence items.
* Applies our internal whitelist (e.g., known CDN IP ranges we cannot block).
* Transforms the remaining IOCs into the exact JSON structure required by our WAF's API for IP Set or URI Rule updates.
* **API Call & Verification:** The microservice then authenticates to the WAF API, updates the relevant IP Set or rule group, and fetches the change confirmation.
* **Audit Log Creation:** A final log event, containing the source report ID, the IOCs actioned, and the WAF change ID, is written to our central logging platform and also posted back as a note within the CrowdStrike Falcon platform for investigator visibility.

**Key Considerations and Pitfalls**
This process is not "set and forget." During our testing and rollout, we identified several critical points:

* Rate Limiting: Both CrowdStrike's APIs and your WAF provider's APIs have rate limits. Our microservice includes exponential backoff and retry logic.
* False Positives: Automating blocks carries risk. We initially only automated blocks for IOCs with CrowdStrike confidence scores of "high" and "critical," and we only apply them to specific host groups (e.g., our customer login portals, not our marketing site).
* Volume Management: IP Sets have size limits. We implemented a pruning routine that automatically removes IOCs from the WAF set 7 days after their CrowdStrike-reported "expire" date, unless re-detected.
* Error Handling: The workflow must gracefully handle partial failures. If one IOC in a batch is invalid, the rest should still proceed. Our logging captures every failure for daily review.

The result has been a measurable reduction in our attack surface. We've intercepted several automated attacks before any human analyst even opened the Intel alert. The next phase of this project is to integrate the same parsed IOCs into our Salesforce CRM as threat accounts for our sales team, but that's a topic for another thread. I'm interested to hear how others are bridging the gap between intelligence and automated action.