Configuring SIEM with Wazuh for threat detection

Wazuh setup: why events don't turn into signals

Log collection and threat detection are two different tasks, and Wazuh setup most often stumbles precisely at the junction.

Agents are installed, events from servers, applications, and network equipment flow reliably into the index, but correlation rules are written for standard scenarios and don't know your infrastructure.

As a result, log parsing happens, but there's no signal: the console shows thousands of events, with zero alerts for a real attack.

The cost of such a configuration becomes apparent at the moment of an incident. Credential stuffing against a service, an anomalous login outside working hours, a series of authorization failures from a single address — all of this sits in the logs but doesn't raise an alarm.

The incident is discovered after the fact, when a user or contractor reports it, and the investigation begins with a manual search through raw events instead of a ready-made timeline.

The second common cause is noise. When rules trigger on any deviation, the stream of false positives grows faster than the team can triage it.

The on-call engineer stops opening notifications, critical alerts get lost among routine ones, and the system formally works but in practice doesn't protect anything.

Wazuh setup begins not with editing the configuration, but with an inventory of sources: which logs are already being collected, which events can even indicate a threat in your environment, and where the boundary between normal and anomalous lies.

Then correlation rules are tied to real scenarios — chains of events rather than single records — and thresholds and exclusions are set so as to remove background noise without losing sensitivity.

Let's break down how this gets closed out: from auditing sources and configuring rules to testing on training scenarios, where we deliberately reproduce an attack and make sure the signal was raised, reached the on-call engineer, and contains enough context for a response.

What a well-built threat detection system delivers

A threat detection system is measured not by the number of agents installed, but by the time from the first suspicious event to a clear response.

As long as server, network device, and cloud service logs sit in different places, and incident triage begins with manually collecting logs, any attack gains hours and days over the defenders.

That is exactly the window a well-built system based on Wazuh closes: events flow into a single repository, correlation rules fire on a chain of actions, and the on-duty analyst receives not a stream of raw lines but a ready-made picture with context.

The first measurable effect is a reduction in time to detection. Instead of learning about a problem from users or from an end-of-week report, the team sees the anomaly as it develops: a suspicious login, a privilege change, a connection to a non-standard port.

In practice, the window between an attacker's action and the signal shrinks from hours to minutes, and this directly determines whether the team manages to contain the threat before data is exfiltrated.

The second effect is a manageable false positive rate. Rules are tuned to the real infrastructure: known administrative scripts, scheduled tasks, and legitimate scanners are moved into exceptions, while priorities are set by asset criticality.

The on-duty analyst stops drowning in noise and responds to what genuinely requires attention — otherwise, within a couple of weeks, the signals simply stop being read.

The third is attack class coverage and infrastructure visibility. Scenarios are tested for credential brute-forcing, privilege escalation, suspicious activity on hosts and in containers, and file integrity changes.

Each rule is tied to an event source, so it is clear which nodes and services are actually under monitoring and which remain a blind spot.

Incident response becomes reproducible: there is an escalation path, standard actions by threat class, and material for a post-incident review.

The result is not "yet another tool" but a predictable loop: a clear time to detection, controlled noise, known coverage, and a proven procedure for acting during an incident.

Deployment and event collection methods

Wazuh setup begins with choosing a deployment architecture, and that choice determines which events will even reach correlation.

There are three basic schemes: local agents on hosts, collection via network flows, and a hybrid option where some sources deliver telemetry directly and others through an agent.

There is no universal answer: the scheme is dictated by what systems are in the environment and how deeply you need to see what is happening inside them.

An agent provides maximum depth — it reads application logs, monitors file integrity, intercepts process calls, and sees what is fundamentally not reflected in a network flow.

Network collection, on the contrary, requires nothing to be installed on nodes: traffic is captured from a mirror port or aggregation point and parsed on the collector side.

This is convenient for segments where an agent cannot be installed — network equipment, industrial controllers, third-party subnets.

The hybrid covers mixed environments but requires careful normalization: events from different sources must fit into a common field schema, otherwise correlation rules run idle.

In practice, the scheme is chosen for each segment separately, not for the entire infrastructure as a whole. We start with an inventory of event sources: what already emits logs, what is available only over the network, where there is no telemetry at all.

Then we determine which sources are critical for detection and select a collection method for them — this way the deployment architecture grows out of real data, not out of a template.

Implementation stages: from audit to handover to operation

We start implementation with a survey: we compile a list of event sources — servers, network devices, applications, cloud services — and record which logs are already being written and in what format, and where they are lost on restart.

The output is a coverage map: which nodes are visible, which are not, and what will deliver the greatest gain in detecting incidents first.

1. Infrastructure audit. Inventory of nodes and sources, assessment of the load on event collection, verification that critical logs are not disabled and are retained long enough for incident investigation.
2. Schema design. We define the topology: where collectors are located, how events reach the analytics node, how we separate streams by criticality. We plan fault tolerance in advance — the loss of a node must not leave us without visibility.
3. Rule configuration. We write and adapt correlation rules for real scenarios: suspicious login, privilege escalation, changes to critical configurations. We test each rule for false positives — noise in alerts devalues the system faster than a missed detection.
4. Scenario validation. We run controlled simulations of attacks and anomalies, check whether the rule fired, whether the alert reached the on-duty operator, and whether there is enough context to make a decision. We iteratively fine-tune the thresholds.
5. Handover to operation. We formalize response procedures, train the on-duty shift, and configure alert routing. We hand over the documentation and stay in touch during the support period.

This sequence delivers a predictable result: by the time of launch, the team understands what the system sees, how to respond to it, and where to look during investigation. Let's discuss your task — we will come back with an estimate and a stage-by-stage plan.

Correlation rules and signal prioritization

Correlation rules in Wazuh are the layer that turns a stream of raw events into a limited set of incidents.

The base engine parses logs by decoders, matches them against signatures, and assigns a severity level; the engineer's job is to configure the rules so that triggers reflect a real threat rather than the activity of scanners and routine tasks. Without this work, the alert queue grows faster than an analyst can process it.

Cutting noise before prioritization

As a first step, we remove false positives at the source: we exclude trusted subnets, service accounts, scheduled jobs, and known vulnerability scanners.

Next, we group related events into a single rule — for example, a series of failed logins followed by a successful login from the same address yields one incident instead of dozens of lines. This reduces the queue severalfold, and significant events do not drown in the background.

Levels and signal routing

Prioritization is built on severity levels and thresholds: low levels go to the archive for retrospective review, medium levels go to the triage queue, and high levels go to immediate notification of the on-call responder.

We select thresholds based on trigger frequency on real traffic, not "by eye": a rule that fires hundreds of times a day is useless regardless of its level. For each scenario, we fix the escalation condition and the owner.

Testing rules on a live stream

We run the configured rules against historical logs and controlled scenarios — we simulate a suspicious login, a privilege change, access to a sensitive resource. We check whether the rule fired, at what level, and whether it produced duplicates.

The outcome of the configuration is a predictable queue where every event has a clear trigger reason and an owner.

What the customer receives after implementation

Implementation ends not with a running server, but with a set of deliverables that allow the system to be operated, handed over to another team, and pass an audit.

Everything we configure is captured in artifacts: configurations, diagrams, access policies, response procedures, and documentation.

• Configurations — rule and decoder files, log collection settings for servers, network equipment, and applications, event storage and rotation parameters. Everything is in version control so that rule changes go through review rather than being edited by hand in production.
• Infrastructure diagrams — the data flow from source to event storage: where agents are deployed, what is collected directly, how segments and points of failure are structured. The diagram eliminates half the questions when connecting a new node.
• Access policies — roles and permissions for analysts, the on-call shift, and contractors, separation of responsibility zones, and the procedure for granting and revoking access. We separately document who sees sensitive events and on what basis.
• Response procedures — for each class of alert: what counts as an incident, who receives the notification, within what timeframe, who makes the decision, and how the record is closed. The rules are agreed with your team, not written "for a checkmark."
• Documentation — operating instructions, the procedure for updating rules, a checklist for connecting a new source, and a description of typical failures and on-call actions.
• Acceptance report — which attack scenarios were tested, how the system responded to them, which rules produce false positives, and what was done about it.

The deliverable set stays with you: the team can develop the system independently or hand it over to another contractor without reconstructing the logic from memory. Describe your task — we will come back with an estimate and a plan.

How Wazuh configuration differs from a typical SIEM deployment

Wazuh is an open platform for threat detection, file integrity monitoring, and security control, built around agents on endpoints.

Unlike classic SIEMs, which primarily collect and correlate events from network devices and applications, Wazuh initially places an agent on the host itself — a server, workstation, or container — and from there collects telemetry: file changes, suspicious processes, privilege escalation attempts, and configuration state.

This changes the deployment logic: you are not just setting up log ingestion, but deploying a managed agent network with centralized policies.

A classic SIEM is strong at correlating events from heterogeneous sources and building analytics on a large data stream, but it requires a separate agent for each type of source and often leaves the host level out of scope.

Wazuh covers exactly this layer: built-in modules for integrity checking, vulnerability scanning, and intrusion detection work out of the box, without purchasing additional licenses for each node.

Therefore, the choice between approaches is a question of what is more critical for you: depth of visibility on endpoints or breadth of coverage across the network infrastructure.

The specifics of Wazuh configuration manifest in several things. Detection rules are described declaratively and inherited between agent groups, so a single policy applies to a hundred servers without manual editing on each one.

Thresholds and exceptions are configured at the rule level rather than spread across each node's configuration.

Finally, Wazuh pairs well with a classic SIEM: agents collect host events, and the platform forwards them into the overall correlation loop — so you get both depth and breadth.

This matters when the infrastructure is distributed, some nodes are outside the perimeter, and the security staff is limited. Then the agent model with centralized policies provides predictable coverage without inflating the team.

If, however, the main task is correlating network events and meeting regulatory logging requirements, a classic SIEM remains the foundation, and Wazuh complements it with a host layer.

Case: Reducing detection time in a distributed network

What it was before

A distributed network: several sites, dozens of services, some traffic flowing between segments. Logs were collected per server — each into its own file, with its own time format.

Incident investigation began with the question "where do we even look." A suspected account compromise was verified by manually correlating logins across three sources: half a day of an engineer's work, and only if they knew what to look for.

The average time from event to confirmed hypothesis held at 6-8 hours. Some attacks — password brute-forcing of service accounts, lateral movement between nodes — were not detected at all: individual events did not look suspicious, and no one correlated them.

What was changed

Wazuh was deployed as a unified collection and correlation layer: agents on nodes, a centralized index, normalization of time and fields from heterogeneous sources. Then — detection rules tailored to our topology, rather than a typical out-of-the-box set.

• Correlation across multiple events: a series of failed logins, then a successful one — triggers as a single incident, not as ten log entries.
• Separate rules for lateral movement: anomalous connections between segments that normally do not communicate directly.
• File integrity monitoring on critical nodes — a configuration change or binary substitution raises a signal immediately.
• Prioritization by node criticality: an alert from the perimeter and an alert from a test bench do not get mixed into the same queue.

What it became

Detection time dropped from 6-8 hours to 15-40 minutes — mainly because correlation happens on the system side, not in the duty operator's head.

Attack classes that previously went unnoticed now generate an alert: credential brute-forcing, movement between nodes, changes to critical files.

False positives are a separate effort. In the first weeks the rules had to be tweaked: some signals were noise from legitimate scripts. After tuning, the share of false alerts fell by roughly threefold, and the duty operator stopped ignoring the queue.

Common technical concerns when setting up Wazuh

The concerns are usually the same: whether the agent will take hold on existing servers, whether it will eat up production resources, whether the team will drown in alerts, and what will happen with updates.

Below is how these questions are resolved in practice, without promises of "we'll install it and it'll just work."

What will the load on servers and network be?

The agent keeps a buffer on disk and sends events in batches, so peaks don't hit the processor. On a typical node, consumption is a few percent, but only measurement on your load profile gives the exact figure: we take metrics before and after on a pilot group.

We limit network usage with compression and a send schedule, and on weak channels we place an intermediate aggregator node.

Won't we drown in false positives?

The base rule set is noisy — that's normal for a start. The first weeks go into tuning: we disable irrelevant rules, add exclusion lists for your services, and lower the priority of known administrative actions.

The goal is not "zero alerts" but a predictable stream where every event requires action. We select the sensitivity threshold based on your environment, not the default.

What about updates and rollback?

Rules and configuration are stored in a version control system, so any change can be rolled back. We deploy updates first to a test environment, verify on a copy of traffic, then roll out to production.

We keep agent and server versions compatible, and before a major update we take a state snapshot — reverting takes minutes, not hours of troubleshooting.

If any of this raises questions about your environment — describe the task, and we'll come back with an assessment and a plan.

Let's discuss your threat detection task

To come back with an assessment and a plan, rather than generalities, we need a minimum of input about your infrastructure. We gather it in a single conversation: what event sources already exist, where they are stored, who is responsible for access.

Based on this data, we build a work plan and give timelines — without a preliminary "eyeball" audit.

What helps us quickly estimate the scope and avoid reinventing the wheel:

• List of event sources: servers and workstations, network equipment, cloud services, applications — which of these already emit logs and which do not yet.
• Current state: whether log collection exists, where logs are written, how long they are retained, who looks at them today and how.
• Network diagram and segmentation: where the boundaries are, which nodes are critical, whether there are isolated enclaves.
• Detection requirements: which threat classes are the priority — logins from suspicious accounts, privilege changes, anomalies on servers, data leaks.
• Access and policy constraints: what can be installed on nodes, which security policies are in effect, who approves changes.
• Points of contact on your side: who will accept the system, who will triage alerts after launch.

The approach to the project is simple: first we close the visibility gap — connect sources and set up collection, then detection rules for your scenarios, then we verify that alerts arrive and are triaged.

Wazuh setup here is not done "by the manual," but for your threat picture: the rule set and priorities depend on what is truly critical for you.

Describe the task in free form — which systems need to be covered and what is concerning you right now. We will come back with a timeline estimate, scope of work, and a phased plan.