Wazuh and Splunk integration

Choose the forwarding method before you configure either platform, because the method decides who owns parsing, how a broken pipeline becomes visible, and what your Splunk team has to keep running afterward. The Wazuh documentation describes more than one way to move data from Wazuh into Splunk. Confirm the current list of methods, their prerequisites and their steps against the Wazuh documentation for the release you run. The 4.14 line has received patches every one to two months, and setup details can change with them. Record the release you tested against in your design document.

For each candidate method, write down what it needs on the Wazuh server: the components to install or enable, the configuration files your team will own, any service account or credentials, the outbound network paths, and whether the change survives a Wazuh upgrade. Then write down what it needs on the Splunk side: the receiving input, the index and sourcetype the data lands in, how tokens or credentials are stored, and any add-on the Splunk team must install and update. Ask your implementation partner or the Wazuh documentation team to walk one sample event through each option, so the field names your searches depend on are checked rather than assumed.

Compare the options on four axes. Operational ownership asks who changes the configuration when a version moves: the Wazuh team, the Splunk team, or both. Parsing location asks whether Wazuh decodes and normalizes events before they reach Splunk, or whether Splunk receives lightly processed data and extracts fields itself. Failure detection asks how you learn that events have stopped: a Wazuh service alert, a Splunk input health view, a drop in the expected alert count, or no built-in signal at all. Maintenance asks what the Splunk team must keep current, such as add-ons, sourcetypes, index retention settings and token rotation.

This page does not name a winner, because the right choice depends on who responds when data stops arriving, how much parsing your Splunk team already owns, and whether Splunk should receive only Wazuh alerts or full archives. As a decision aid only, teams that want one owner for detection logic often test the option where Wazuh does the decoding first and Splunk stores and searches the results. Test that choice against the documented steps for your release and against your own ingest budget before you commit. Run a pilot on a non-production agent group and compare event counts in both platforms. Before sign-off, confirm in writing the method and release you tested, which team is responsible for each side after handover, and which alert fires when the Splunk input stops receiving data.

Give each HTTP Event Collector token one job. A token that sends Wazuh alerts should not also carry agent inventory, file integrity events or test data, because the token is the unit you rotate, revoke and audit. Name each token after the data it carries and the Splunk index it may write to, so someone reading the Splunk audit trail can tell which flow produced an event without opening the Wazuh configuration. Before you create anything, decide which Wazuh outputs will leave the platform and which will stay in the Wazuh indexer. That list sets the number of tokens and indexes. Confirm the HEC port, the token options that current Splunk documentation offers and the default settings for new tokens before you copy any example into a build ticket, since defaults can differ from what your team remembers.

Separate indexes by data class and sensitivity. Security alerts, endpoint inventory and vulnerability findings have different readers and different retention needs, so they belong in different indexes. Authentication events and any data that contains personal information deserve a tighter access list than system health telemetry. Map each index to the analyst groups that need it. A first-line queue may need alerts for a short window, an incident response group may need longer history, and a forensic group may need raw events. Index-level roles in Splunk control who can search each index and who can change its settings, so write the role matrix before the first index exists. Ask your Splunk administrator which role capabilities and index settings your license and edition support.

Put TLS in front of the collector endpoint from the first day. Traffic carries alert content and authentication tokens, so the connection from the Wazuh server to the HEC endpoint should be encrypted. The Wazuh side should validate the certificate chain against a certificate authority your team controls, and verification should stay on in test environments too. Confirm with Splunk documentation how the HEC endpoint is configured for TLS and which certificate formats it accepts. For rotation, issue the replacement token, add it to the Wazuh configuration, confirm that events arrive under the new token, and then revoke the old one. Store tokens in a secrets manager or in a file readable only by the service account that runs Wazuh. Keep them out of version control and shared runbooks, and record each rotation date and owner.

Model ingest for each index before you enable it. Every index that receives Wazuh data adds to the volume counted against your Splunk license, so ask which licensing terms apply to each data type you plan to send and whether they are metered the same way. Estimate volume from a sample taken from a test environment or from the Wazuh indexer, then multiply by the retention window assigned to that index. Those two figures show whether an index is worth its cost. Compare the first weeks of actual ingest with the forecast, and tell the migration team which high-volume sources can be filtered on the Wazuh server before they reach Splunk. Keep the forecast in the design record so that every change to an index or source is reviewed against the same numbers.

Every data source needs one of three outcomes before the migration plan is final: it stays in Splunk, it moves to Wazuh, or it runs in both platforms during a parallel period. Sort each source into one of those lists before any forwarding is changed. Sources that feed Splunk searches, saved alerts, dashboards or scheduled reports usually stay until those dependents have been rebuilt and tested. Endpoint telemetry that Wazuh already collects through its agents, such as file integrity monitoring events and the software inventory used for vulnerability detection, is a stronger candidate to move. Record the reason for each placement, the owner who agreed to it, and the date it will be reviewed. Measure current ingest before deciding anything. Pull ingest reports from Splunk by source, sourcetype and index over a window long enough to include month-end processing and any seasonal peaks. Ask your Splunk administrators to confirm which reports they use and whether licensing data is reported on the same basis. The estimate of what could be removed from Splunk should come from those reports, not from assumptions or vendor comparisons. For each high-volume source, also note which saved searches, alerts and dashboards read from its index, because volume alone does not show how much work depends on that data.

Turning off a Splunk source removes every correlation rule, alert and report that depends on it, and those dependencies are often undocumented. Map each Splunk alert to the source it reads, then identify the Wazuh decoders and rules that cover the same event types. Where a Wazuh equivalent exists, test it against known events, either replayed from a lab or generated by a controlled test, and confirm the alert reaches the same queue, ticketing integration or responder. Where no equivalent exists, keep the source in Splunk or build and test the Wazuh rule first. Treat any gap in this mapping as a blocker for turning off that source, and record who accepted any residual risk.

A parallel run sends the same events to both platforms, so Splunk ingest can increase during the overlap before it falls. Plan for that increase in the migration budget and in the license conversation with your Splunk account team. Set the length of the dual-run period from written validation criteria, such as a set number of days of matching alert outcomes that your team defines, rather than from a calendar date chosen in advance. Retention is a separate obligation. Check the retention period in your Splunk index settings and confirm with your compliance owner which logs must stay searchable, and for how long, under internal policy or external regulation. Moving a source to Wazuh does not end that obligation, so confirm the retention configuration in the Wazuh indexer before historical data is left behind.

Set approval steps before any forwarding is removed. A typical gate includes sign-off from the data owner, the security operations lead, the compliance owner and the team that manages the Splunk contract. Require documented evidence for each source: the detection mapping is complete, the coverage tests passed, dashboards and reports have been rebuilt, the retention requirement is confirmed, and the owner has accepted any residual risk. Stop forwarding in stages, not all at once, and keep the Splunk index readable for an agreed period after the last event arrives so that investigations can still reach historical data. Record each decision in a change ticket so that the reasoning is available to auditors and to the next person who reviews the placement.