MISP IOC Management and Wazuh Integration

Why Connect MISP to Wazuh

Most teams that adopt MISP do a good job of collecting threat intelligence and a poor job of using it. Indicators accumulate in the platform, analysts browse them during investigations, and that is where the value stops. The intelligence never reaches the detection layer where it could automatically flag a match against live traffic or endpoint activity.

Wazuh is the natural detection layer for an open source SOC. It already ingests endpoint telemetry, system logs, network device logs, cloud trails and application logs. If MISP indicators are loaded into Wazuh in a form its rule engine can match, every event flowing through the pipeline is checked against current threat intelligence with no analyst effort.

The outcome is detection that improves automatically as the intelligence improves. When a new campaign is shared through a MISP community feed and the relevant IOCs land in your instance, Wazuh starts matching them within the next sync cycle. That is the difference between intelligence as a reference library and intelligence as an active control.

The Data Flow: MISP to CDB List to Wazuh Rule

The cleanest integration pattern moves indicators from MISP into Wazuh Constant Database (CDB) lists. A CDB list is a simple key-value file Wazuh can look up at high speed during rule evaluation. You maintain one list per indicator type: malicious IP addresses, malicious domains, file hashes (MD5, SHA1, SHA256), and URLs.

An export job queries the MISP REST API for attributes that match your selection criteria, writes each indicator as a key in the appropriate CDB list, compiles the lists, and triggers a Wazuh manager reload. MISP exposes attributes by type, by tag, by event and by the to_ids flag, so the export query can be precise about what it pulls.

On the detection side, Wazuh rules use the list lookup to test fields in incoming events. A rule might check whether the source or destination IP of a firewall event appears in the malicious IP list, or whether a hash recorded by the file integrity monitoring module appears in the malicious hash list. A match raises a dedicated alert that carries the IOC and a reference back to the MISP event.

Teams that prefer not to manage CDB files directly can run an active response or integration script that calls the MISP API in near real time for a specific indicator. This is heavier on the MISP server and slower per event, so the CDB approach is the right default for high-volume pipelines. Reserve live API lookups for low-volume, high-value checks.

IOC Selection and Hygiene

The single biggest factor in whether this integration helps or hurts is which indicators you allow through. Pulling every attribute from every feed into Wazuh guarantees noise. MISP feeds vary enormously in quality, and many indicators are low-confidence, context-specific, or already expired by the time they reach you.

Filter before export. Honour the to_ids flag, which feed authors set to mark an attribute as suitable for automated detection; attributes without it are often context or enrichment rather than detection-grade. Filter by attribute type so only the types Wazuh can act on (IP, domain, hash, URL) are exported. Apply a confidence or tag filter so only trusted feeds and analyst-vetted events contribute.

Expiry matters as much as selection. An IP that was a command-and-control node six months ago may now be a reallocated cloud address serving a legitimate business. MISP supports decay models and first_seen and last_seen timestamps; use them to drop indicators past a sensible age window. A rolling window of recent, active indicators is far more valuable than an ever-growing list that never forgets.

Finally, deduplicate and normalise. The same IP can appear across many events with different tags. Wazuh CDB lookups are exact-match, so domains and hashes must be normalised to a consistent case and format before they become keys, or live events will silently fail to match.

Controlling False Positives

False positives are the reason most threat-intel-into-SIEM projects quietly die. Analysts lose trust after a week of chasing matches that turn out to be benign, and the IOC alerts get muted. Preventing that is a design problem, not a tuning afterthought.

Scope matching to the right log sources. A malicious-domain list should be evaluated against DNS and proxy logs, not against every log line in the environment. Matching the wrong indicator type against the wrong source is a common cause of nonsense alerts.

Maintain an allowlist of your own infrastructure and known-good third parties. Content delivery networks, popular SaaS endpoints, your own egress IPs and partner ranges will occasionally appear in feeds because they were briefly abused. Suppress matches against entities you have verified as legitimate, and review the allowlist periodically.

Enrich before you alert. A raw IOC hit tells an analyst little. Adding the MISP event title, the threat actor or campaign tag, the indicator confidence and the matching log context turns a bare match into a triage-ready alert. Enrichment can run in the automation layer that bridges MISP and Wazuh, so the analyst sees a complete picture rather than a hex hash and an IP.

Tier your response by confidence. A match on a high-confidence, recently shared indicator from a trusted feed warrants an immediate alert. A match on a lower-confidence indicator can be logged for correlation rather than paged. This stops the IOC channel from becoming an undifferentiated firehose.

Automating the Sync and Keeping It Fresh

Threat intelligence ages by the hour, so a manual export is worthless within a day. The sync between MISP and Wazuh must be automated and scheduled. A typical cadence pulls new and updated attributes every fifteen to sixty minutes, rebuilds the affected CDB lists, and reloads the Wazuh manager configuration.

Pull incrementally where possible. The MISP API supports filtering by timestamp, so each run can request only attributes changed since the last successful sync rather than re-downloading the entire dataset. This keeps the load on the MISP server low and the sync fast even as the indicator base grows.

Make the pipeline observable. Log every sync run with counts of indicators added, updated, expired and skipped. If a feed stops updating or the export job fails silently, you want to know before an incident reveals that detection was running on a frozen list. Alert on sync failure the same way you alert on any other control failure.

An orchestration layer such as n8n or a simple scheduled script can own this entire flow: query MISP, transform and filter, write CDB lists, reload Wazuh, and post a summary to the SOC channel. The same layer can run the reverse direction too, pushing observables from confirmed Wazuh incidents back into MISP so the organisation's own findings enrich future detection.

Operating the Integration Day to Day

Once the pipeline runs, the work shifts from building to curating. Review which feeds contribute the most useful detections and which only generate noise, and prune the noisy ones. A feed that has produced a hundred matches and zero confirmed incidents in a quarter is a candidate for removal or for downgrading to log-only.

Close the loop with incident response. When an IOC match leads to a confirmed incident, record that outcome so the value of the feeding intelligence is measurable. When a match turns out benign, capture the reason so the allowlist and filters improve. Over a few months this feedback turns a generic feed into a tuned, organisation-specific detection capability.

Treat the integration as part of the wider SOC rather than a bolt-on. The IOC alerts should flow into the same case management and response workflow as every other Wazuh alert, with the same triage, escalation and metrics. For teams running an open source stack, MISP feeding Wazuh sits naturally alongside TheHive for case management and Cortex for enrichment, forming a coherent detection and response loop.

Codesecure builds and tunes these pipelines for clients running open source SOC stacks, including the MISP filtering logic, Wazuh rule design, allowlisting strategy and the automation that keeps it all fresh. The goal is always the same: alerts that analysts trust enough to act on.