A SIEM (Security Information and Event Management) is the system that collects in one place the logs from servers, PCs, firewalls, cloud services and applications, makes them comparable, links them through correlation rules and raises an alert when a sequence of events points to a possible attack. It also keeps the history, which you need to reconstruct an incident and to demonstrate your controls in an audit.
SIEM: meaning and definition
The acronym combines two functions that started out separately. SIM (Security Information Management) dealt with collecting and retaining logs for analysis and compliance. SEM (Security Event Management) watched events in near real time and flagged suspicious ones. A SIEM does both: it is at once the archive and the alarm system of information security.
The principle is simple. Every system keeps a diary of what happens: successful and failed logins, services started, firewall rules applied, files modified. Read one at a time, these diaries say little. Put together and read in time order, they can tell the story of an attack: ten failed logins from abroad, then a successful one, then a new administrator account created at three in the morning.
How a SIEM works, from collection to alert
1. Log collection
Data comes from agents installed on PCs and servers, from the log forwarding protocols of network devices (such as syslog) and from the interfaces of cloud services. This is where the most important decision is made: which sources to connect. A SIEM only sees what it receives.
2. Normalisation
Every vendor writes logs its own way. Normalisation translates different formats into common fields (date and time, user, source address, system, outcome) so that a Windows login and a firewall login can be compared. For the sequence of events to make sense, the systems' clocks must be synchronised.
3. Correlation and rules
Correlation rules look for patterns: thresholds (too many failed attempts in a few minutes), sequences (a successful login straight after a burst of failures), anomalies (a user connecting from a country never seen before). Many SIEMs map detections to the tactics and techniques of the MITRE ATT&CK framework, so you can see which stage of an attack an event belongs to, and compare the data with threat intelligence sources and known indicators of compromise.
4. Alerts
When a rule fires, the SIEM raises an alert with a severity. This is where the system proves its worth: an alert has to reach someone who understands it and knows what to do.
5. Retention and search
Logs remain available for a defined period, protected from modification. They are used for forensic analysis after an incident, for threat hunting (looking for traces of compromise that no alert has flagged) and to show an auditor that the controls exist.
SIEM and log management: what is the difference?
A log management system collects, indexes and retains logs, and lets you search them. It is useful, and already a great deal for anyone who has nothing today: for example, it lets you keep the record of system administrator logins. But it is an archive: it answers when you ask a question.
A SIEM adds the active part: correlation across different sources, detection rules, alerts, security context. In short, log management lets you reconstruct what happened; a SIEM tries to tell you while it is happening.
SIEM vs XDR, EDR and SOAR
The acronyms overlap, not least because many products today combine more than one. Here are the basic differences.
| Acronym | What it does | Where it looks | Strength |
|---|---|---|---|
| SIEM | Collects, correlates and retains logs, raises alerts | All connected sources: endpoints, network, cloud, applications | Overall view, history, compliance |
| EDR | Detects malicious behaviour on endpoints and can isolate them or block processes | PCs and servers | Depth on the individual device, immediate response |
| XDR | Extends detection and response across several layers, correlating endpoints, network, identity and email | Several sources, often from the same ecosystem | Integrated detection and response |
| SOAR | Automates and orchestrates response with predefined procedures (playbooks) | The alerts produced by SIEM, EDR or XDR | Faster, repeatable reaction times |
So the question "SIEM or XDR?" has a practical answer: a SIEM is stronger at broad collection and retention, an XDR at detection and response on endpoints. In an SME the two functions increasingly live in the same sensor, and the real difference is made by whoever reads the alerts. For retention and audit obligations, a centralised history is still necessary.
Why a SIEM on its own generates noise
The most common problem with SIEM projects is not technical: it is that nobody reads the alerts. The default rules are designed to be cautious, so they flag a lot. The nightly backup looks like exfiltration, the system administrator's script looks like lateral movement, the update to the management software modifies system files. After a few weeks the alerts number in the hundreds and end up in a folder nobody opens.
To work, a SIEM needs continuous effort:
- rule tuning, to exclude recurring noise that has already been assessed;
- alert triage, meaning someone who reads them, classifies them and decides;
- response, with procedures and responsibilities defined before the incident;
- maintenance: new sources, new systems, new attack techniques.
This is the work of a SOC (Security Operation Center). Few SMEs can keep one in-house, which is why MDR (Managed Detection and Response) exists: detection and response are entrusted to a managed service. We cover it on the SOC and MDR page.
Which logs an SME should collect
You do not need to collect everything: you need to collect what lets you answer the right questions. A reasonable starting point for a small or medium-sized business:
- logins to PCs, servers and the domain, successful and failed, with particular attention to administrative accounts;
- cloud identity: Microsoft 365 or Google Workspace sign-ins and alerts;
- firewall and VPN: allowed and blocked connections, remote access;
- operating system security events: user creation, group changes, services installed, registry changes;
- integrity of critical files, with file integrity monitoring;
- antivirus or EDR: detections and protection status;
- email: suspicious forwarding rules, unusual mailbox access;
- critical applications, such as the management software, when they record logins and operations.
Decide in advance how long to keep them, too: the period depends on your obligations and on how far back you might need to look to reconstruct an incident discovered late.
What the rules require: Garante, NIS2, ISO 27001
The Garante's order on system administrators
The order issued on 27 November 2008 by the Garante per la protezione dei dati personali, the Italian Data Protection Authority (Gazzetta Ufficiale no. 300 of 24 December 2008), requires the logical access of system administrators to systems and electronic archives to be recorded. The records must be complete, unalterable and verifiable in their integrity, include time references and a description of the event, and be kept for an appropriate period, no shorter than six months. The administrators' work must also be checked at least once a year. Find out more in the guide on system administrator logs.
NIS2
D.Lgs. 138/2024, the Italian law transposing NIS2, requires incident handling measures and notification to CSIRT Italia within 24 hours, 72 hours and one month. The baseline specifications issued by ACN, Italy's National Cybersecurity Agency, include monitoring and incident handling requirements. Without logs that are collected and retained, it is hard to notice an incident in time and describe it accurately in the notifications. For digital and managed service providers, Implementing Regulation (EU) 2024/2690 has a specific section on monitoring and logging. See the guide NIS2: who must comply and what they must do.
ISO/IEC 27001:2022
In Annex A, control 8.15 (logging) requires logs of activities, exceptions, faults and other relevant events to be produced, stored, protected and analysed; control 8.16 (monitoring activities) requires networks, systems and applications to be monitored for anomalous behaviour and potential incidents to be evaluated; control 8.17 covers clock synchronisation. A SIEM, with its rules and alerts, is the most common way to provide evidence for these controls. See ISO/IEC 27001.
How to choose a SIEM
Before comparing products, it pays to answer a few questions:
- Who will read the alerts? If the answer is "nobody in particular", you need a managed service more than a tool.
- Which sources do you need to connect? Check that they are supported without custom development: Windows, Linux, firewalls, Microsoft 365 or Google Workspace.
- How long do you need to keep logs, and with what integrity assurances, under the rules that apply to you?
- How is noise handled? Exclusions, thresholds, custom rules: ask to see them in action.
- What happens when a critical alert fires? Who is notified, in what language, with which possible response actions, and who authorises them.
- How do you demonstrate it in an audit? Exports, reports, searchable history.
- How does the cost grow? Many SIEMs are charged by data volume, others by monitored device: estimate the growth before you sign.
How Dottor Box helps
In Dottor Box the SIEM function is performed by the Cyber Agent, the agent installed on PCs and servers: detection of suspicious activity, event correlation, file integrity monitoring, HIDS with alerts, detections mapped to MITRE ATT&CK and log centralisation for up to 6 months to support forensic analysis. Critical events arrive by email with the title translated into your language (Italian or English), and you can silence recurring noise with exclusion rules.
Logins feed the access logs register, which can be exported as evidence for the Italian order on system administrators. On top of the tools there is the work of people: at the Security Monitor level, false positive management and threat hunting; at the MDR + SOC levels, alerts reach Dottor Marc's SOC, with support via 8/5 tickets or a dedicated number 24 hours a day. You will find the details on the Managed SIEM and XDR and SOC and MDR pages.