Every SIEM project starts with the same question: what do we connect? And nearly always with the same answer: everything for now, we can filter later.
That’s understandable and still the most expensive mistake of the rollout phase. SIEM licences bill almost universally by ingested data volume. Collect everything and you pay for everything, including the ninety-nine percent of lines nobody ever looks at when it matters.
The useful yardstick isn’t completeness. It’s detection value per gigabyte.
The sources a deployment starts with
These five groups are what we typically onboard. They cover the paths real attacks actually take.
1. Server systems: Windows event logs
The baseline. Logons, privilege changes, service and scheduled task creation, process starts, share access.
What becomes visible: privilege escalation, lateral movement, persistence mechanisms. Most of what an attacker does after initial access leaves a trace here, provided auditing is switched on at all. That’s regularly a deployment’s first finding: the logs you want to collect are never produced on the system in the first place.
2. EDR solutions
Endpoint detection and response sees what happens on the endpoint at a depth operating system logs don’t provide: process trees, suspicious parent processes, memory access, blocked executions.
In the SIEM that becomes more than a second console. Only correlated with identity and network data does an individual endpoint finding form a picture: same user, same hour, three systems.
3. Syslog: firewalls, network and security devices
Connection data, blocked and permitted sessions, VPN logins, changes to rule sets.
What becomes visible: command-and-control communication, data exfiltration, access from unexpected networks and geographies and configuration changes to exactly the devices meant to enforce the perimeter.
4. Microsoft 365
Sign-ins and their conditions, MFA events, role and permission changes, mailbox rules, sharing, administrative actions.
No source has gained importance like this one in recent years: more on that in a moment.
5. Other cloud services
Anything business-critical with an audit interface. Backup systems explicitly belong here: if you take ransomware seriously, you need to see when someone shortens retention, disables jobs or deletes restore points. Those actions aren’t a side show: they’re typically the preparation for the actual damage.
Why identity comes first today
If you prioritize by effect rather than by effort, identity goes to the front.
The classic attack placed malicious code on an endpoint. The more common attack today simply logs in. Compromised credentials, a bypassed or fatigued second factor, then access to mailboxes, file stores and connected services: without code ever landing on an endpoint.
An EDR sees none of it, because there is nothing to see. A sequence like that becomes visible exclusively in sign-in and activity data: a logon from an unexpected country, a newly created mailbox forwarding rule, a permission jump, a bulk share.
That’s precisely why a purely endpoint-centric detection setup is incomplete, however good the EDR in use.
The decisive question: can you even write a rule against it?
There are always sources you can only write meaningful detection rules against with difficulty. Either the format is too unstructured, or the event carries no attacker context, or normal simply cannot be separated from anomalous.
Our yardstick for this is simple: if no defensible rule can be written against a source, it doesn’t necessarily belong in the detection tier, unless it needs retaining over a longer period for compliance reasons. In that case it belongs in the archive, not in correlation.
That distinction matters more than it sounds. It separates two entirely different purposes that regularly get conflated:
| Detection tier | Archive | |
|---|---|---|
| Purpose | Detect attacks | Evidence and reconstruction |
| Selection criterion | Can a rule be written? | Is there a retention obligation? |
| Cost | high, volume-driven | low |
| Access | correlated in real time | searchable on demand |
Typical candidates for the archive rather than for correlation:
- Verbose application and debug logs. Valuable for troubleshooting and for reconstruction after an incident, almost never the basis of a detection rule.
- Health checks and load balancer lines every second. High volume, constant content, no attacker context.
- Redundant forwarding. The same events twice because two systems report them.
So the answer isn’t “leave them out” but file them correctly. Both are necessary. Both do not have to cost the same.
Getting it wrong costs in either direction: push everything into the detection tier and you pay for correlation that never happens. Drop a source entirely because no rule fits it, and you may find those were exactly the records an investigation (or a regulator) needed.
Detection tier
Into correlation. Real-time evaluation, alerting, tuning. Expensive, because it bills by volume and that cost is justified, because it produces detection.
On to question 2
Not an exclusion but a second check. The absence of a workable rule doesn't make the data worthless: only means it will never raise an alert.
Archive
Cheap storage, searchable on demand. The purpose is evidence and reconstruction, not detection. Retention follows the obligation, not the detection need.
Do not onboard
Neither detection value nor a retention obligation. This source generates cost and noise but no benefit. It deliberately stays out of scope.
↻The decision isn't permanent. New attack patterns make sources rule-able that weren't before, and changed obligations move the second question. Both belong in the regular review of scope.
Retention: 90 days as a starting point
In our engagements, standard retention is 90 days, with considerably more available where needed.
90 days isn’t an arbitrary number. The decisive quantity is the time between initial access and discovery and in practice that is regularly measured in weeks, not hours. If an investigation starts in December and initial access was in October, retention decides whether you can reconstruct the sequence or have to guess. Nobody can supply log data that was already deleted when the investigation began.
More than 90 days makes sense when:
- regulatory evidentiary obligations require longer periods,
- you want to analyse attack patterns across longer timeframes,
- or your sector has to reckon with long-running, quiet campaigns.
For regulated organizations, a time factor arrives from the other direction: NIS2 requires an early warning within 24 hours and an incident notification within 72 hours and both have to hold up substantively. Holding up means evidence from log data that still exists. Which NIS2 and DORA requirements are covered by which service is set out on our NIS2 & DORA page.
Which platform
Sumo Logic is our primary platform. We’re not locked to it, though, and work on other stacks as well (CrowdStrike among them) where a customer already has an investment or there are other good reasons.
That openness isn’t a footnote. Replacing a working platform purely because the provider can only operate one means paying for a migration whose benefit accrues to the provider, not to you.
The most dangerous source is the one nobody mentioned
Finally, the point that does more operational damage than any badly tuned rule.
A SIEM detects nothing on systems it doesn’t know about. A server that has been running in production for three months and appears in no ingestion configuration produces no alerts and no error either. It’s simply invisible. The same goes for a new network segment, an additional cloud service or a migrated workload.
That’s why ongoing reporting of scope changes isn’t a formality but a genuine operational obligation on the customer side. How we divide that up in practice is described in Co-Managed SIEM: Who Does What.
Bottom line
The question isn’t how many sources you connect, but which and in what order. Server logs, EDR, network and security devices, Microsoft 365 and business-critical cloud services cover the paths real attacks take. Identity belongs at the front, because modern attackers log in more often than they break in.
And the best source selection is worthless if retention is too short to reconstruct the sequence, or if entire systems were never reported to the SIEM at all. Detection is an operational discipline, not a procurement exercise.