Security teams today rarely suffer from a lack of data. Firewalls, endpoints, cloud platforms, identity systems and applications can generate enormous volumes of security information every day. The challenge is turning that information into something useful.
A SIEM (Security Information and Event Management) platform brings logs and events together from multiple sources, normalises the data and applies correlation and detection rules to identify activity that may indicate a cyber attack.
In simple terms, the process looks like this: Collect → correlate → detect → alert → investigate
But that simplicity can be deceptive. Many SIEM deployments underperform not because organisations cannot ingest enough logs, but because they collect too much information without sufficiently defining what they actually want to detect.
The result is often alert fatigue: analysts receive huge numbers of low-value notifications, while genuinely important events risk becoming lost in the noise.
Good SIEM Starts with the Threat, Not the Log
A common starting point for a new SIEM deployment is to ask which systems can be connected. A better question is: Which threats do we most need to detect?
If ransomware, compromised administrator accounts, data exfiltration or suspicious cloud activity are priority risks, security teams can work backwards from those scenarios to identify the data required.
This creates a much clearer chain: Threat → detection requirement → required logs → alert → response
The distinction matters because more data does not automatically produce stronger security.
Some logs may be extremely useful for detection, while others add cost and complexity without materially helping analysts identify threats.
The National Cyber Security Centre emphasises proportionate logging and protective monitoring rather than indiscriminate data collection.
NCSC – Logging and Protective Monitoring – https://www.ncsc.gov.uk/collection/device-security-guidance/managing-deployed-devices/logging-and-protective-monitoring
Why SIEM Deployments Generate Too Many Alerts
Poorly tuned detection rules are one of the biggest causes of SIEM frustration. Imagine a rule that creates an alert whenever an administrator logs in outside normal working hours.
That sounds reasonable until the security team discovers that legitimate overnight maintenance happens every week. If analysts repeatedly investigate the same harmless event, the rule quickly loses value.
This is where alert tuning becomes critical.
Rather than simply asking whether something unusual happened, a better detection might combine several signals. For example:
Privileged login outside normal hours + unfamiliar device + unusual geographic location + sensitive server
…is much more meaningful than an out-of-hours login alone. Context improves detection quality.
That context might include the user’s role, the criticality of the asset, known vulnerabilities, identity risk or previous behaviour.
The objective should be fewer, higher-quality alerts rather than measuring SIEM success by how much activity it can surface.
As Splunk notes in its guidance on alert fatigue, excessive alerts can desensitise analysts, delay investigations and make it harder to distinguish genuinely important events.
Splunk – Preventing Alert Fatigue – https://www.splunk.com/en_us/blog/learn/alert-fatigue.html
Detection Quality Matters More Than Detection Quantity
A SIEM generating 10,000 alerts a day is not necessarily more effective than one generating 200. The better question is how many of those alerts lead to useful investigations.
Security teams should therefore look beyond alert volume and measure areas such as:
- False-positive rate
- Time to detect
- Time to investigate
- Coverage of priority threats
- Percentage of alerts requiring action
Risk-based approaches can also help.
Instead of opening an incident every time a minor anomaly occurs, modern SIEM tools can accumulate risk around users, devices or systems.
A single unusual login might not warrant investigation. But combine that login with privilege escalation and suspicious endpoint behaviour, and the accumulated risk becomes much more significant.
This shifts SIEM away from:
“Alert whenever anything interesting happens“
towards:
“Escalate when several relevant signals suggest meaningful risk.“
Cloud SIEM Changes the Infrastructure, Not the Detection Problem
Many organisations are moving towards cloud SIEM rather than operating large on-premises platforms.
Cloud-native services can make deployment and scaling easier, particularly for organisations already using SaaS and multi-cloud environments.
Microsoft Sentinel, for example, is designed to ingest and analyse security information across cloud, on-premises and third-party systems.
Microsoft Sentinel – https://learn.microsoft.com/en-us/azure/sentinel/overview
However, moving the SIEM into the cloud does not solve poor detection engineering.
Security teams still need to decide:
- Which logs matter
- Which alerts are useful
- How detections should be tuned
- What information should be retained
- How costs should be controlled
Ingestion pricing can make this particularly important.
Sending every available log into a cloud SIEM may become expensive without improving detection proportionately.
Some organisations may therefore retain lower-value data elsewhere and bring only the most useful security telemetry into the primary detection layer.
SIEM, XDR and the Changing SOC
The security operations landscape is also changing around SIEM.
Extended Detection and Response (XDR) platforms can correlate information across tightly integrated technologies such as endpoint, email, identity and cloud security.
A useful distinction is:
XDR provides deeper visibility across integrated security controls.
SIEM provides broader visibility across the wider enterprise.
The two increasingly work together.
Microsoft, for example, is combining Sentinel and Defender XDR within a more unified security-operations experience, reflecting a wider industry move towards reducing the number of disconnected tools analysts need to navigate.
Microsoft – SIEM and XDR – https://learn.microsoft.com/en-us/security/zero-trust/siem-xdr-overview
This does not necessarily mean SIEM is being replaced.
Instead, the role of the SIEM platform is evolving as richer telemetry and automated correlation become available through XDR.
SIEM as a Service and MDR
Technology is only part of the challenge. Even a well-configured SIEM solution requires people to tune detections, monitor alerts, investigate incidents and respond when something serious happens.
Organisations without sufficient internal security-operations resources may therefore consider SIEM as a Service.
These services can provide capabilities such as platform administration, log onboarding, rule tuning and ongoing monitoring.
Managed Detection and Response (MDR) goes further by combining security technology with specialist analysts who actively investigate and respond to threats.
The distinction is important: A SIEM collects and analyses information, an MDR service provides the people and operational processes required to act on it.
For some organisations, the most effective model may therefore be a combination of:
SIEM + XDR + MDR
…rather than trying to make a single platform perform every security-operations function.
The Measure of SIEM Success
The strongest SIEM deployments are rarely those collecting the greatest amount of data. They are the ones that help analysts identify real threats quickly enough to do something about them. That requires:
Good telemetry + relevant detection rules + continuous tuning + useful context + appropriate human expertise
Security teams should therefore avoid treating implementation as a finished project.
Applications change. Users change. Cloud environments evolve. Attack techniques shift.
Detection content needs to evolve with them.
The real measure of SIEM success is not:
“How many logs are we ingesting?”
or
“How many alerts did we generate?”
It is:
“Are we detecting the threats that matter, and can our analysts act on them?”
That is the difference between simply collecting security information and building an effective detection capability.
The the Elevate Tech Summit and Cyber Secure Forum bring senior IT and cybersecurity professionals together with specialist providers across SIEM, XDR, MDR and wider security operations, giving buyers the opportunity to compare solutions and discuss the challenges of building effective detection and response.
Sources
- National Cyber Security Centre – Logging and Protective Monitoring – https://www.ncsc.gov.uk/collection/device-security-guidance/managing-deployed-devices/logging-and-protective-monitoring
- Microsoft – Microsoft Sentinel – https://learn.microsoft.com/en-us/azure/sentinel/overview
- Microsoft – SIEM and XDR Overview – https://learn.microsoft.com/en-us/security/zero-trust/siem-xdr-overview
- Splunk – Preventing Alert Fatigue – https://www.splunk.com/en_us/blog/learn/alert-fatigue.html
- Splunk – Risk-Based Alerting – https://www.splunk.com/en_us/blog/security/risk-based-alerting-the-new-frontier-for-siem.html
Image credit: https://unsplash.com/photos/man-in-black-suit-jacket-S8vMGLKG2b0
