Building a SOC and a SIEM
From the data sources through a common schema to detection rules whose coverage can be measured. Built with your team, run by your team.
Plenty of log data, few alerts anyone follows up
A SIEM can be introduced in a few weeks and filled for years. The question that decides whether it is any use is rarely asked: for which attack step is there a rule, and which source supplies the events for it.
Without that mapping the volume of data grows, the number of alerts rises, and the share of them anyone works on falls. We found exactly that state at an international group and rebuilt it from the detection logic outwards.
Sources, schema, rules, coverage
It starts with the question of what you want to detect, not with the question of which platform. From the detection goals it follows which sources are needed: directory service, endpoints, firewall, proxy, cloud logs.
The events run into one collection and get brought onto a common schema. Only on that can rules be written that work across several sources, and only then can it be said how much of MITRE ATT&CK is covered and where gaps remain.
Coverage is the number the build can be steered by. It shows which next source brings the greatest gain.
What a build covers
The scope follows what is already in place. For most, the platform exists and the logic is missing.
Needs and detection goals
Which attacks are evidenced for your sector, which systems are critical, which evidence duties apply. The list of use cases comes out of that, not the other way round.
Sources and schema
Connection, normalisation, retention. Plus the check of whether a source delivers what the rule on top of it expects.
Rules and playbooks
Detection rules with thresholds from your environment, and for every alert a procedure: who checks, what gets checked, when it escalates.
How a build begins
The first weeks decide the rest.
Take stock
Which sources are connected, which rules run, how many alerts arise and how many of them get worked on.
Fix the detection goals
Ten to twenty use cases that fit your threat picture. Fewer good ones beat many mediocre ones.
Close the gaps
Per use case, connect the missing source, write the rule, set the threshold to your environment, and check it against a reproduced attack.
Handover
Operation, maintenance and further development go to your team. We accompany the first months and stay reachable afterwards as a fallback.
Automation environments follow other rules
This page describes the build for IT environments. In automation the sources are different, active queries are out of the question, and the response has to know the process. If you need both, the order is usually IT first and OT on top.
Common questions about SOC and SIEM
Security information and event management: a system that collects events from many sources, brings them onto a common schema and applies rules to them. Individual lines in a log become an alert when several of them together make a pattern.
The SIEM is the platform. Whether it is any use is decided by the logic on top: which sources are connected and which rules run.
Because an attack rarely becomes visible in a single system. A login at an odd hour on the directory service, an outbound connection attempt on the firewall and a new service on a server are unremarkable individually and an incident together.
On top of that comes the duty to evidence: NIS2 and the German IT Security Act require operators of critical infrastructure to have systems for detecting attacks.
A shared view of events from systems that otherwise know nothing of each other. Retention for working through an incident afterwards, when the question comes of how long somebody has been on the network. And a measurable figure for your own detection: which attack step triggers a rule and which does not.
Classically in your own data centre, as a cloud service, or mixed, with collection staying local and analysis running outside. The systems also differ in whether they charge by event volume or by compute time, which affects operation more than the technology does.
Three come up regularly. The sources do not deliver what the rules on top of them expect. The thresholds come from a template and do not fit your environment, which produces alerts with no substance. And nobody is responsible for working on the alerts, which turns an alert into an entry that gets clicked away.
The most expensive mistake is starting with the platform rather than with the detection goals. Then the volume of data grows and the detection does not.
Coverage against MITRE ATT&CK as the steering figure rather than the number of connected sources. Detection rules as versioned code with tests, rather than as a sequence of clicks in an interface. And moving retention into cheaper storage, because otherwise the cost grows with the volume.
Splunk, Microsoft Sentinel, Elastic, IBM QRadar and Wazuh are widespread, plus dedicated sensors in the OT environment. We work with what you have: changing platform is rarely necessary in order to improve the detection.
A security operations centre is the organisation around the SIEM: people, procedures and responsibilities. Who reviews alerts, who decides on an escalation, who may take a system off the network, and when.
A SIEM without a SOC produces alerts nobody works on. So we build both together and hand operation over to your team.
We build and hand over. Your team runs it, because knowledge of your environment is the part that carries the detection. For the early period and for escalations we stay reachable.
By the coverage against ATT&CK, by the share of alerts worked on, and by an exercise in which we execute attack steps and record which of them arrived in your tools.
The range is wide, and these factors set it:
- Kind of system. On premise means a higher initial investment and lower running costs. Cloud-based is the other way round: little investment, but monthly costs and a stronger tie to the provider.
- Feature set. Correlation, threat intelligence and automation cost more than plain collection and search.
- Data volume and number of users. Both drive the licence, in the cloud model especially clearly.
- Consulting and operating effort. A SIEM without maintained use cases produces alerts nobody follows up.
Elasticsearch has been under a free licence again since August 2024, so basic operation costs nothing. Individual security features still sit behind a paid tier, and the effort is in the build and the running anyway. As a non-binding order of magnitude from our projects:
- Small companies: 10,000 to 50,000 euros
- Mid-sized companies: 50,000 to 100,000 euros
- Large companies: 100,000 to 250,000 euros
An exact figure comes only out of the needs analysis: sources, data volume, retention period and the question of who runs the system. With Elasticsearch, Kibana and Logstash a SIEM stays within reach for companies without a security department of their own. An introduction to the stack is in our article Von Logstash bis Kibana, which is in German.
The work divides into three phases:
- Prevention. Security controls such as firewalls, IDS and endpoint protection, patch management with fixed deadlines, hardening to a standard, and training for staff.
- Detection. Log data from the relevant sources, correlation in the SIEM, use cases with a defined threshold, and somebody who works on the alerts.
- Response. Playbooks for the recurring cases, defined escalation, forensics, and a recovery that has been practised.
The three hang together. Detection without response produces tickets; prevention without detection leaves you in the dark the moment it fails.
The terms often get mixed up. Briefly sorted:
- SIEM (security information and event management): collects and correlates events from firewalls, IDS, endpoints and applications and turns them into alerts. A tool.
- SOC (security operations centre): the organisation of people, processes and tools that works on those alerts. A SIEM without a SOC is an archive.
- SOAR (security orchestration, automation and response): automates recurring response steps through playbooks.
- EDR (endpoint detection and response): detection and response on the endpoint itself, with a process tree and the ability to isolate a system.
- XDR (extended detection and response): the same idea across endpoint, network, identity and cloud, usually from one vendor and therefore from one ecosystem.
- MDR (managed detection and response): a provider takes over detection and response. That is an operating model, not a technology.
Which model is economical depends on your size and on whether you can staff an on-call rota around the clock yourself. A comparison is in our article Internes SOC, Managed SOC oder Hybrid, which is in German.
Selected case studies on SIEM
Certifications and memberships.
Talk to us.
A first conversation usually takes 30 minutes. We look at where you stand and tell you frankly whether we are the right partner.