TL;DR
Modern security platforms now do natively what organisations once needed a SIEM to build. For years, a SIEM was the only way to correlate signals across endpoint, identity, and cloud.
That is no longer the case.
Duplication isn’t an abstract idea. It looks like paying to ingest logs nobody ever queries. It looks like writing correlation rules for behaviour your endpoint agent already flags out of the box. It looks like the same alert landing in two different queues and getting properly triaged in neither. That’s the cost this article is actually about.
Background
The SIEM has been the centrepiece of security operations for many years. At first glance, the approach is straightforward: aggregate everything in one place, write detection logic, correlate events, and let the security team work from a single pane of glass. For a good SOC (security operations centre) team there was clear logic here, security endpoint tools were immature and required a lot of work to extract meaningful data (if it was possible at all).
In practice today, a lot of organisations are paying high ingestion bills for platforms that are largely re-processing alerts their security tools already produce, ingesting logs that are rarely (if ever) used in correlation <cough> firewall hits <cough>, writing detection rules they could have had out of the box, and building alert logic that modern endpoint, identity, and email platforms now do natively.
This is not an argument that SIEMs are dead. It is an argument that a lot of organisations are funding infrastructure when they should be funding outcomes.
What you're actually paying for
The licence price of a SIEM is not the cost of a SIEM. Licensing models based on data ingestion create a system where doing the right thing (logging broadly, retaining longer, correlating more sources) is directly represented in your bill.
Recent research puts numbers against what most Australian SOC teams already feel.
Stats
Illumio’s 2025 research, surveying 150 Australian security leaders, found:
- The average Australian team faces 2,061 alerts a day, roughly one every 42 seconds.
- 83% said they receive more alerts than they can adequately investigate, against 67% globally.
ASD’s Annual Cyber Threat Report 2024–25 reported notifying Australian entities of potential malicious activity more than 1,700 times, an 83% increase on the year before.
Stats
The SANS 2025 SOC Survey found that:
- 42% of SOCs ingest data into their SIEM without a plan for retrieval or analysis.
- 85% of respondents say endpoint security alerts are their primary trigger for response.
Before you’ve built a single detection rule, you are paying to ingest, parse, normalise, and index data from every source in your environment. For organisations with cloud workloads, that volume can sprawl quickly.
Beyond licensing, the operational cost is the piece that surprises a lot of people. A SIEM does not detect threats. It is infrastructure on which detection can be built. That building requires detection engineers who understand both the platform query language and the underlying threats, ongoing tuning as the environment changes, and a feedback loop between false positives and rule refinement. None of that is included in the licence.
Security Tools Grew Up
Five years ago, the case for a SIEM was stronger because the security platforms themselves were relatively limited detectors. Your endpoint protection might alert on a known hash. Your email gateway might block a known domain. Your identity platform might log a failed login. But connecting those signals (understanding that the same user failed to log in from an unusual country, then received a phishing email, then ran an unusual binary) required a centralised log aggregation layer with correlation rules on top.
That is no longer the only way to achieve correlation.
Microsoft Defender XDR, CrowdStrike Falcon, SentinelOne, and similar platforms now do signal correlation natively. They ingest telemetry from endpoint, identity, cloud, email, and network, and they apply detection logic across all of those simultaneously.
What To Do Instead
Before you go shopping for anything new, it’s worth checking what you’ve already got switched on. Are your endpoint policies actually set to block, or just to detect? Is your identity platform’s risk policy enforced, or sitting in report-only mode? And when one of those platforms does fire an alert, whose queue does it land in, and how long does it sit there before a human looks at it? A lot of the “we need better visibility” conversation disappears once those three questions get honest answers.
This is not "One-Size-Fits-All"
There are environments where a SIEM continues to make clear sense, though they’re narrower than most vendors will tell you. Organisations with genuine regulatory or sector obligations to centrally retain and query logs, heavy custom-built or legacy technology without native detection support, or real complexity across multiple identity providers and business units, may still find a SIEM is the practical answer.
Sovereign data and audit trail requirements
Government and critical infrastructure organisations often have requirements around log custody, chain of evidence, and auditability that are best met by a controlled on-premises or sovereign-cloud log repository. If that’s your organisation, this article isn’t arguing against a SIEM. It’s arguing against buying one by default.
Questions Worth Asking
Whether you are evaluating a new SIEM or coming up to renewal on an existing one, these are questions worth working through.
- What percentage of your current alerts come from platform detection versus SIEM correlation rules you wrote?
- How many active, maintained detection rules do you have in your SIEM? When were they last reviewed?
- What is your total cost of ownership (licence, ingestion overage, engineering time, analyst time) not just the platform fee?
- If your SIEM went offline tomorrow, which threats would you genuinely miss that your XDR or endpoint platform would not catch?
- Are you retaining logs in the SIEM for compliance or for detection? Could those functions be separated?
- Could your detection engineering hours be better spent tuning and building coverage in the platforms you actually use?
- What would it cost to get equivalent 24/7 coverage in MDR versus maintaining the SIEM model?
The Division 5 Approach
Division 5 sells MDR, and this piece should be read with that in mind.
We don’t sell SIEM licensing or ingestion, so we’ve got no reason to talk you into a bigger platform, or out of one that’s actually working. Our MDR service connects directly to the platforms your organisation already operates, and we work with whatever gives the best detection coverage in your environment.
Closing Notes
In practice, many of the Australian mid-market organisations are better served by direct-to-platform MDR than by adding a SIEM layer. The coverage is comparable and the cost is lower.
For organisations with genuine compliance mandates, OT environments, or high complexity, we take a different position. In some cases that means helping a client ingest existing SIEM alerting more effectively rather than replacing it.
What we do not do is recommend a platform because it is convenient for us or because it was the right answer five years ago. Security operations changed significantly when the major platforms matured their native detection capabilities, and that change is still working its way through how most organisations think about their stack.
Whether you’re approaching a SIEM renewal, weighing up a managed SOC, or just want an honest read on whether your current alerts are actually being watched, our team is happy to work through it with you.