SIEM Deployment: What to Collect and When

SIEM belongs to that class of systems many organisations buy, few deploy well, and fewer still genuinely operate. The most common end state: it collects every log, produces thousands of alerts a day, and nobody looks at them.

This article covers how to avoid that.

When it makes sense

SIEM is not the first security investment. If any of these is missing, address it first:

• MFA on externally reachable services,
• isolated, tested backups,
• basic network segmentation,
• endpoint protection on workstations.

SIEM builds on these rather than replacing them. Its time comes when:

• somebody is available to respond to alerts (an internal team or a contracted provider),
• a compliance obligation requires log collection and effectiveness measurement (NIS2 measure 6, ISO 27001 A.8.15-8.16),
• correlations must be seen across multiple sources that no single tool shows.

What to collect, and in what order

"Let us collect everything" is the most common and most expensive mistake. Licensing is typically volume-based, so unnecessary logs cost real money while obscuring what matters.

This order delivers the most value for the least volume:

The first three sources cover the overwhelming majority of real incidents. Start with them, tune them into working order, and expand afterwards.

Avoiding alert flooding

A freshly deployed SIEM with a default rule set produces thousands of alerts a day. This reliably leads to nobody looking at them.

Start with few use cases. Five to ten well-tuned rules are worth more than two hundred factory ones. Some good starting points:

• impossible travel (two sign-ins from locations physically incompatible),
• changes to privileged group membership (domain admin additions),
• successful sign-in after many failures,
• log deletion or logging being disabled,
• creation of a new service or scheduled task on a server,
• backup job failure or deletion,
• unusually large outbound data transfer.

Tune for at least four weeks. Every false positive requires a decision: exception, rule refinement or acceptance. This work is not optional; it is the deployment itself.

Measure the real alert count. A realistic target: 5 to 15 alerts a day, of which 1 to 3 warrant substantive investigation. Materially more than that means tuning is unfinished.

What to settle in advance

Retention. Two numbers: how long data is immediately searchable (typically 30 to 90 days) and how long it is archived (1 to 2 years). Compliance expectation and cost collide here. In an incident investigation logs older than 90 days are often decisive, because the attacker entered weeks earlier.

Time synchronisation. If device clocks differ, correlation is useless. NTP everywhere, a consistent time zone, ideally logging in UTC.

Log source integrity. An attacker's first act is erasing traces. A log copied into the SIEM is therefore more valuable than one left on the device, and log deletion should itself be an alert.

Data protection. Logs contain personal data (who did what and when). This must appear in the privacy notice, and access must be restricted.

Cost: what to budget for

Licensing is only one item, and typically not the largest.

• Licence: by data volume or event count. Predictable if you prioritise sources.
• Infrastructure: storage, compute (or the cloud service fee).
• Deployment: source integration, rule tuning. Typically 4 to 12 weeks.
• Operation: the largest and most frequently underestimated item. Daily alert review, rule maintenance, onboarding new sources.

Because of the fourth point, a managed service (MDR/SOC) is a better choice than self-operation for many organisations. Standing up a 24/7 internal team requires at least five or six people, which is not rational for most mid-sized companies.

What it satisfies in compliance

The last row matters practically: to issue a 24-hour early warning you must know an incident occurred. Without log collection and alerting, organisations frequently learn weeks later from an external notification.

A realistic expectation

SIEM does not prevent attacks. It makes them detectable, and allows you to reconstruct afterwards what happened. Those two capabilities determine whether an incident becomes a few days or several months of work.

If you want to assess where you stand, our IT security services include SIEM design and use case development. We covered the incident response process in our first 24 hours article.