What is SIEM in cyber security?

What SIEM stands for, and what it does

Security information and event management is a category of security software. It is worth saying that plainly, because the spelling sits close enough to Siemens, the industrial group, that the two are routinely confused in search — they have nothing to do with each other. A SIEM sits downstream of everything in your estate that writes a log. It takes events produced in dozens of incompatible formats, gives them a common shape, and makes the whole set queryable as one body of evidence. The value is rarely in any single log line; it is in the joins. A failed authentication on a VPN concentrator, a successful one twelve minutes later from a different country, and a privileged group change on a domain controller are three unremarkable events until something reads them as one sequence. Five jobs make up the core of the category, and a product that does only the first two is a log manager wearing a SIEM label.

• Aggregation — pulling logs and events from every system that emits them
• Normalisation — mapping vendor-specific fields onto a common schema
• Correlation — matching events across sources and across time against detection logic
• Alerting — raising, scoring, and routing whatever that logic matches
• Retention and search — keeping records long enough to investigate and to satisfy an audit

How a SIEM is put together

Architecturally, a SIEM is a pipeline with a database at the end of it. Collectors gather data, either agentlessly — listening for syslog, receiving SNMP traps, polling cloud APIs — or through agents installed on hosts where the operating system will not forward what you need on its own. Parsers then decompose each raw message into fields: source address, user, process, action, outcome. This is the least glamorous part of the system and the part that breaks most often, because a firmware or agent update can change a log format and silently orphan a parser, at which point a source is still arriving but is no longer being understood. The correlation engine evaluates normalised events against rules and behavioural baselines, both in the stream as data arrives and in scheduled searches over history. Storage is almost always tiered: a hot tier holding recent data for fast queries, then warm, cold, or archival tiers that cost less per gigabyte and take longer to search. On top sits the search and investigation interface, which is where analysts spend their day and where a SIEM is won or lost.

The log sources that matter

You cannot detect what you never collected, and most disappointing SIEM deployments disappoint because of what was left out rather than what was configured wrong. Perimeter and network data tells you about movement across the estate; endpoint and identity data tells you about intent, and in practice you need both before you can build a timeline that anyone will believe. The sources below carry detection value out of proportion to their volume. Windows telemetry deserves particular attention: default Windows event logging on its own is rarely enough to reconstruct an intrusion, which is why Sysmon and script-block logging appear in almost every serious detection engineering conversation.

• Firewall, proxy, and VPN logs — perimeter traffic, both allowed and denied
• Windows Sysmon, ETW, and PowerShell script-block logging — process creation, command lines, script contents
• DNS query logs — command-and-control and exfiltration frequently surface here first
• NetFlow or IPFIX — who talked to whom, and how much, where full packet capture is impractical
• Cloud audit trails — control-plane activity across your public cloud accounts
• Identity providers and directory services — authentication, MFA events, privilege changes
• SaaS admin and audit logs — mailbox rules, sharing changes, OAuth grants

Use cases, and what detection engineering actually means

The generic list of SIEM use cases — insider threat, compromised credentials, lateral movement, data exfiltration, privilege abuse — is accurate but not very useful, because none of it happens unless somebody writes and maintains the logic. Detection engineering is the discipline of turning a described attacker behaviour into a query that fires on it in your environment, then keeping that query honest as the environment changes underneath it. MITRE ATT&CK is the shared vocabulary for the work: a catalogue of tactics and techniques observed in real intrusions, which lets a team describe its coverage in terms of behaviours rather than a count of enabled rules. Mapping detections to technique IDs is uncomfortable precisely because it shows how much of the matrix a default rule pack leaves untouched, and that discomfort is the value. Treat rules as code — version them, test them against replayed data or an adversary emulation exercise, and judge them on the quality of what they produce. A rule that has never fired and a rule that fires two hundred times a day are both broken, in opposite directions.

What SIEM integration means

The phrase gets used for two different things, and separating them helps. Inbound integration is the connector work of getting a source in: credentials, a transport, a parser, and field mappings that place the new data on the same schema as everything else. Ask a vendor how many sources ship supported out of the box, and what building a parser for one that does not actually costs in effort — that figure governs how long your rollout takes far more than any feature comparison will. Outbound integration is what happens after a detection fires: passing the alert into a ticketing or ITSM system, enriching it from threat intelligence, updating an asset record, or handing it to response automation that can isolate a host or disable an account. The second kind is chronically undervalued, because a detection that a person has to retype into another console has already surrendered most of its time advantage. That division of labour between detection and response is the subject of a separate explainer, SIEM vs SOAR, linked below.

Where SIEM deployments go wrong

Three failure modes account for most of the disappointment with this category, and all three are predictable enough to plan around. The first is the expensive log warehouse: data lands, retention is satisfied, dashboards exist, and nobody reads any of it because no one owns detection content. The tool survives as a compliance artefact with a licence fee attached. The second is alert fatigue. A badly tuned SIEM produces thousands of low-confidence alerts a day, analysts learn which ones can be closed without being read, and the day a real detection arrives it is closed with the same reflex — the queue has quietly trained the team to ignore it. The third is structural, and buyers underestimate it consistently: when pricing is based on ingest volume, every decision to collect a source becomes a budget decision. Teams respond rationally by dropping the noisy, high-volume sources — DNS, proxy, endpoint process telemetry, flow data — which are exactly the sources with the highest detection value. The commercial model ends up shaping detection coverage, and that gap shows up on no dashboard anywhere.

Retention, audit evidence, and Indian jurisdiction

Detection is the reason organisations buy a SIEM; evidence is often the reason it stays funded. When something goes wrong, the question is never only what the alert said — it is what the logs show for the weeks before it, and that answer exists only if retention was set correctly in advance. Indian organisations carry a further consideration. CERT-In's directions expect security logging to be enabled and the resulting logs to be retained and maintained so they can be produced when an incident is investigated, held within Indian jurisdiction. Read the current text of the directions and take advice on how they apply to your entity rather than working from a summary, including any sector obligations from the RBI or SEBI that sit on top. Practically, this shapes three architectural decisions: where each storage tier physically lives, how long it holds data, and whether the export you can hand an investigator is complete and time-consistent. Settle those before selection, because retro-fitting data residency to a deployed SIEM is painful and expensive.

How to evaluate a SIEM tool

Most evaluations are decided by a demonstration on curated data, which predicts almost nothing about how the tool will feel in eighteen months. The questions that do predict it are about unglamorous things: parser coverage, what happens when a log format changes, how the pricing model behaves as the business grows, and whether the people who will actually operate the platform can write and test their own detections in it without raising a vendor ticket. Run any proof of concept against your own messiest source rather than the vendor's sample dataset, and insist on seeing a rule authored, tested, and fired in front of you.

• How is it priced — by ingest volume, by node, by user — and how does that behave as you grow?
• How many sources are supported out of the box, and what does a custom parser cost in effort?
• Can your team author, version, and test detections, or does every rule go through the vendor?
• Are detections mapped to MITRE ATT&CK, so coverage can be discussed as behaviours?
• What are the storage tiers, where do they reside, and how slow is search across cold data?
• Does a confirmed detection trigger a response action, or only produce a ticket?
• Can it correlate beyond IT telemetry — network operations centre and physical security signals included?