MISP and Splunk integration

misp42splunk works by pulling. The Splunk side initiates requests to the MISP API, MISP returns the indicators and attributes that match the request, and the app makes that data available to Splunk searches and correlation. Nothing is pushed from MISP into Splunk. That design means the Splunk environment controls when fetches happen and how much data each one requests, while MISP controls what the caller is allowed to see. For a Splunk administrator, the app configuration is the place where freshness is set. For a MISP administrator, the important point is that every pull is an authenticated API call made under a specific MISP user account, so the results depend on that account's role and sharing permissions.

MISP's API is described in OpenAPI form, which gives both teams a formal description of the endpoints and parameters. The query interface the MISP features page documents for retrieving data is restSearch. Before deployment, the MISP administrator should ask which restSearch parameters the app sends, including attribute types, tags, distribution levels, publication or time windows, and whether it requests events, attributes or both. Each of these choices changes the volume and content of what reaches Splunk. The Splunk administrator should confirm the MISP version the app was built and tested against, since MISP 2.5 is the version the project recommends for new deployments and the app's compatibility should be checked against the MISP version in use.

The app documentation defines where retrieved data is stored in Splunk: in lookups, in indexed events, or in both. Lookups are suited to matching field values during searches, while indexed events keep each record with its timestamps and context so it can be searched over time. Confirm which of these the installed version uses, what lookup and index names it creates, which roles can read them, and how much storage the retained data will consume. Do not assume the behavior of a previous release. If both mechanisms are used, decide which one the correlation searches and alerts depend on, because that choice determines what happens when one of them is stale or empty.

Schedule options and pull behavior must be checked against the app version in use. Ask whether each run fetches a full set or only changes since the last run, whether new data overwrites or appends to what is already stored, how expired or removed indicators are dropped, and what happens when a run fails partway through. Test with a small, bounded query first, then compare the counts returned by MISP for that query with the counts that land in Splunk. Stale data leads to missed matches, and duplicated data can inflate alert volumes, so these checks should pass before the schedule is extended to production scope.

Before go-live, record the MISP user account and role behind the API key, the restSearch parameters the app sends, the place where data lands in Splunk, the pull schedule, and the owner responsible for rotating the key. Keep this record with the Splunk app configuration so that a change in MISP permissions or a MISP upgrade can be traced to its effect on Splunk results. Each item should be confirmed against the app's own documentation for the version you deploy, not against this page.

Retrieval scope is the main design decision in a MISP and Splunk integration, because it determines what Splunk searches can match and how much data each lookup carries. Pulling every event a MISP instance holds is the simplest configuration and usually the wrong one. A broad lookup grows with the instance, slows the searches that reference it, and places low-confidence indicators in the same table as indicators that analysts have already validated. Each filter narrows the lookup in a different way and trades detection coverage against false positives. Decide them together, write them down, and test them against recent alerts before any correlation search depends on them.

Tags and threat level are the filters most teams configure first. Tags let you select events by taxonomy or galaxy labels, such as a label for a campaign or a confidence classification, but only if contributors apply them consistently. Threat level, which MISP records on each event, lets you keep low-severity material out of high-fidelity alerts. A tag filter that is too narrow misses indicators from contributors who use other labels, which lowers coverage without any visible error. A threat level filter that is too strict removes early warnings that were never upgraded. Ask the MISP event owners which tags and levels they actually maintain, and confirm whether the connector you use can filter on both or only on the event level.

Event age and attribute type control volume and noise. Limiting retrieval to events published or modified within a time window keeps the lookup smaller and more current, but some indicators, such as infrastructure that remains malicious for long periods, would drop out early. Set the window for each indicator type according to how long it stays useful. Attribute type matters more than many teams expect: domains, IP addresses and file hashes produce different false positive rates, and broad types can match legitimate traffic. Distribution settings decide which events your instance may receive. Events limited to another organization or a specific sharing group may be unavailable to the Splunk account, and an empty lookup is easy to mistake for a clean environment.

Agree these choices in writing with two groups before building correlation searches. The SOC owns the detections, so it should state which alert types the lookup feeds, how much false positive load it can absorb, and what coverage it expects. The MISP event owners publish and maintain the events, so they should confirm the tags, threat levels, distribution levels and attribute types they will provide and how often those change. Record each filter value, its owner and a review date. Then treat any later change to a filter as a change to detections that goes through the same review.

Verify the scope against known data before relying on it. Compare the number of indicators the lookup returns with what the MISP interface shows for the same filters, and send a sample of recent events through the lookup to confirm they arrive. Over a fixed period, review which alerts fire for each attribute type and look for types that produce mostly benign matches. Keep these results so the next review has a baseline. Scope decisions are far cheaper to change before a SOC depends on a search, so schedule the first review early and repeat it whenever the event owners change their tagging or distribution practices.

Indicators in a Splunk lookup are only as useful as their last refresh. The point of this section is that expiry, edits and removals in MISP have to reach Splunk on a schedule you chose on purpose, and that a lookup which silently keeps old values will keep producing alerts after the underlying intelligence has changed. Before scheduling anything, decide which of three conditions you are protecting against: an indicator that has expired in MISP still matching in Splunk, an indicator that was revised or removed in MISP still firing, and a new indicator that never arrives because the pull failed.

Each of these failure modes looks different in practice. A stale indicator tends to produce false positives that analysts learn to ignore, which is worse than an obvious error because it erodes trust in the alert. A missed removal can keep a lookup hit alive for a domain or address that has since been cleaned up by its owner. A failed pull is the quietest case, since the lookup still returns results and nothing in the search output shows that its contents stopped moving. Whatever you build should make the age of the data visible to the people who rely on it, for example by recording the time of the last successful refresh alongside the lookup.

Refresh frequency is a trade-off between currency and load on both systems. Pulling more often narrows the window in which Splunk disagrees with MISP, but each run queries the MISP API, transfers attribute data, and rewrites the lookup file or KV store collection that searches depend on. Pulling less often reduces that load but widens the gap for time-sensitive indicators. The right interval depends on how quickly your sources change, how many attributes your scope pulls, and how much headroom your MISP server and Splunk search head have during business hours. Test the job against your real scope before you pick a number, and watch both sides for timeouts and long-running searches.

Set up a review routine for stale indicators that does not depend on the refresh job working. At a fixed interval, sample lookup entries, compare their age and status against the MISP source, and check whether expired or deleted attributes are still present. Record the count of entries removed and retained at each review. Assign an owner for this check, and decide who can override a retained indicator and under what justification.

Confirm how your version of the misp42splunk app handles deleted and expired attributes before you rely on it for alerting. The app's documentation and release notes should state whether removals are propagated, whether expiry is honored, and whether an update replaces or appends to existing lookup content. Do not assume these behaviors. Create a sample event in a test MISP instance with one attribute that you will later expire, one that you will edit, and one that you will delete. Run the refresh, then check each attribute in Splunk. Only after that result matches what you expect should a detection depend on the lookup.