SIEM and log management
We set up real-time threat detection and dashboards so you can see what is happening across your entire environment.
When it makes sense
When it is time for a SIEM
A SIEM builds on baseline protection. If your externally reachable services have no MFA, or you have no isolated and tested backup, basic network segmentation, or endpoint protection, start with those.
Its job is to spot an attack and to make it possible to reconstruct what happened afterwards. A red team exercise shows whether detection actually works.
Someone to respond
Someone has to look at the alerts: an internal team or a contracted provider.
Compliance obligation
A law or standard requires log collection. The details are in the FAQ.
Connections across sources
You need to see connections across several sources that no single tool shows.
The process
How a SIEM rollout comes together
As our article on SIEM deployment explains, a few basic questions need settling first. After that, it pays to proceed in three steps and to connect log sources in the order that gives the most value for the least data volume. Source-by-source details are in our article on logging.
-
Preparation
Decide up front how long logs stay instantly searchable and how long they are archived. According to the article, an incident investigation often hinges on logs older than 90 days, because the attacker got in weeks earlier. Device clocks must be synchronized with NTP, ideally with logs recorded in UTC, or correlation becomes useless. Logs also contain personal data, so access to them has to be restricted, and this must be stated in the privacy notice as well.
-
Starting with three sources
Identity (domain controller, cloud authentication), endpoint protection, and the firewall together with the VPN cover the vast majority of real incidents. Logs have to be copied into the SIEM, because a log that stays on the device is in the attacker's hands.
-
Use cases and tuning
Start with a small number of rules. According to the article, five to ten well-tuned rules are worth more than two hundred default ones. False positives have to be dealt with one by one, through a narrow exception, a refined rule, or a deliberate decision to accept them. This work is the rollout itself.
-
Expansion
Once the first sources run reliably, add the critical servers (file server, database, backup system), email, and cloud applications, and finally the network devices and the proxy, as well as the logs that the EDR, the WAF, and the email filter produce themselves.
Starter rules
Use cases for the first rule set
Our article on SIEM deployment recommends these seven starting points. Which ones go in depends on the sources you have connected.
Impossible travel
Two sign-ins from places so far apart that the trip is physically impossible.
Change in privileged group membership
For example, a new member is added to the domain administrators.
Successful sign-in after many failures
May mean that password guessing has succeeded.
Log deletion or logging turned off
An attacker's first move is to cover their tracks. Nobody does this in normal operation.
New service or scheduled task
When created on a server, it often signals that an attacker is setting up persistence.
Failed or deleted backup job
Backups are the first target of ransomware attacks.
Unusually high outbound data traffic
May be a sign of data exfiltration.
References
Central logging in practice
In both projects, a FortiAnalyzer-VM collects the logs of the network and security devices in one place, with built-in SIEM and SOAR capabilities.
University and secondary school network
We configured log collection in the university's virtual environment, with real-time system monitoring and prebuilt reports, so that faults can be traced back.
Municipal network
Using Security Fabric, we integrated the firewalls of external institutions, kindergartens, and nurseries into the central firewall and FortiAnalyzer, so logging is centralized too. Logging and reporting for the email filter also run here.
Deliverables
What you get at the end
items handed over
- Logging concept
- SIEM use cases
- Correlation rules
- Alert handling procedure
- Operations manual
- Administrator training and knowledge transfer
- Follow-up: measuring how effective the deployed controls are
Frequently asked questions
The questions we hear most
Why not collect every log?
Because licensing is usually based on data volume, so unnecessary logs cost money and bury what matters. Our article on logging estimates that full collection for a 200-person organization comes to roughly 10–25 GB a day. Identity and endpoint sources provide most of the value, and storing raw network traffic is rarely worth it.
Who watches the alerts at night and on weekends?
This has to be settled before the rollout: who looks at the alerts at nine on a Monday morning, and who at three in the morning on a Sunday. If nobody can answer the second question, you either need a managed service (MDR/SOC), or you have to accept in advance that a weekend incident will wait until Monday. According to our article on SIEM deployment, a 24/7 internal team needs at least five or six people, which is not worth it for most mid-sized companies. Under a custom agreement, we also commit to after-hours availability and a fixed response time.
How is a SIEM different from EDR or XDR?
EDR looks for suspicious behavior on the endpoint and lets you intervene, for example by isolating the machine. XDR extends this to several data sources (endpoint, network, email, cloud), so that individual alerts add up to a connected attack chain. A SIEM is a log collection and correlation system that merges events from several sources and generates alerts from them. Automating the response to those alerts is the job of SOAR. We have also collected these terms in our glossary.
What does a SIEM cover under NIS2 and ISO 27001?
In ISO 27001, it covers the logging (A.8.15) and monitoring (A.8.16) controls. Among the NIS2 measures, it supports measuring the effectiveness of security measures (measure 6) and incident detection and handling (measure 2). It also matters for the reporting deadlines: to send the 24-hour early warning, you have to know that an incident happened. Without log collection and alerting, an organization often finds out weeks later, from an outside report. We covered what to do after an incident in our article on the first 24 hours.
