A user calls the help desk because their account is locked out. You reset the password, they get back to work, ticket closed. Now imagine the same lockout happened three times at 2 a.m. from an address in another country, on a service account that can read payroll. Nothing in that ticket would tell you. A SIEM is the tool that would.

The acronym stands for security information and event management, which explains very little. What it actually describes is a system that gathers logs from many places, stitches them together by time and identity, and shouts when the pattern looks wrong. If you support users, servers and a firewall, you already own most of the raw material. A SIEM is what turns that material into an answer.

What a SIEM actually does

Strip away the marketing and there are three jobs.

Collect

It pulls logs from everything that produces them: Windows Event Logs, Linux syslog, firewalls, VPN concentrators, switches, endpoint agents, cloud audit trails, identity providers. Collection is a plumbing problem, and like most plumbing, it is invisible until it leaks.

Correlate

It joins those logs on shared details — a username, a hostname, an IP address, a timestamp. One failed login is noise. One failed login followed by a success, followed by a new account being created and added to a privileged group, is a story.

Alert

It turns rules and baselines into notifications, so a human gets a chance to look before the story finishes.

Log collection is the unglamorous part that decides everything

Most disappointing SIEM projects fail here, long before correlation gets interesting. Three things matter more than the rule library.

• Coverage. A SIEM sees only what you send it. If your firewall logs stay on the firewall and your cloud audit logs expire after 90 days, no clever rule can recover them.
• Time. Correlation depends on clocks agreeing. Point every device at the same NTP source before you troubleshoot a single missed alert; otherwise you will spend an afternoon proving that two events three minutes apart were actually simultaneous.
• Parsing. A raw syslog line is a sentence in an unfamiliar dialect. The SIEM has to break it into fields — user, source IP, action, result — or your searches will be string matching forever.

Start with the sources you would check first during an incident: your identity provider, your endpoint protection console, your firewall and your main server estate. That set answers more real questions than a hundred half-configured appliances.

Correlation: finding the sentence inside the noise

Consider three events from an ordinary Tuesday. At 10:14 a user authenticates from the office. At 10:52 the same account authenticates from a VPN range nobody recognises. At 10:55 that account is added to the domain administrators group.

Each event alone is unremarkable. The 10:14 login is normal. The 10:52 login might be a travelling colleague. The group change might be a planned change ticket. Correlation is what lets you express the thing you actually care about: an account that authenticated from the office and then from an unexpected network within the hour, followed by a privilege change.

That is a rule you can write, test and tune. It is also a question you cannot answer with a dashboard of pretty charts, which is why correlation sits at the centre of the product and not at the edge.

Alerting people will actually read

An alert queue nobody opens is worse than no queue at all, because it creates the comfortable feeling that someone is watching. A few habits keep it useful:

1. Give every alert a named owner. Unassigned alerts are decoration.
2. Set a response time you can keep, even during a busy week, and be honest about it.
3. Track false positives. If a rule fires twenty times a week and is wrong every time, fix the rule or delete it.
4. Write down what "investigated" means — who was contacted, what was checked, what was concluded.
5. Review the noisiest rules monthly. Tuning is maintenance, not a one-off project.

A small team with thirty well-understood rules will outperform a large team drowning in four hundred default ones.

What a SIEM is not

It is not a firewall and it does not block traffic. It is not endpoint detection and response, though the two work well together. It is not a compliance checkbox on its own; auditors and regulators often expect you to retain and review logs, but buying a platform does not produce that review. And it is not a person. Someone still has to read the alerts, decide what they mean and act. Software can shorten the distance between an event and a decision; it cannot make the decision.

How to start evaluating one

Skip the feature matrix for the first meeting. Instead:

1. List the questions you cannot answer today. "Which accounts logged in from outside our country last month?" "Did anyone change firewall rules after hours?" Those questions are your requirements.
2. Inventory your log sources and note which ones are already centralised, which retain data, and which are on someone's forgotten appliance.
3. Check the retention and storage maths. Ask what your daily ingest volume looks like and what happens when you exceed the licensed amount.
4. Ask how much tuning is included. Deployment is the easy part; the first three months of parsing fixes and rule adjustments decide whether the tool gets used.
5. Insist on a trial with your own data. A demo with vendor sample logs tells you almost nothing about how their parser handles your ancient switch firmware.
6. Decide who owns it. If the answer is "whoever has time", reconsider the timeline.

Managed options exist and suit plenty of small teams, but the same rule applies: someone on your side still has to receive the escalations and know what to do with them.

Start with one question you cannot answer today

Pick a single scenario that matters to your organisation — suspicious sign-ins, privilege changes, outbound traffic to unexpected destinations — and build the smallest setup that can detect it end to end. Get the logs flowing, confirm the clocks agree, write one rule, watch it fire, and work out what you would do next. A SIEM earns its place one answered question at a time, and the first question is always more valuable than the hundredth dashboard.

Photo: Ludovic Delot / Pexels