KRITIS security monitoring case study: how a large group protects its network with a SOC
Building a security operations centre for an operator of critical infrastructure, with data sources from several sites in shared analysis and a shift staffed around the clock.
An operator of critical infrastructure needed detection that brings several sites into one picture and is staffed around the clock.
Brief and scope
Several sites, one analysis, continuous staffing.
Environment
An operator of critical infrastructure with distributed sites, its own operational technology, and a landscape grown over years.
Brief
Build a security operations centre that brings together events from all sites, assesses them, and is able to act on the day.
What made it particular
IT and OT data sources were to sit in the same analysis, not in separate systems with separate teams.
Separate views of connected systems
Every site brought its own systems, its own responsibilities and its own view. An attack moving across site boundaries would have been fully visible in none of those views.
The separation between IT and operational technology made it harder still. Both areas had data but no shared analysis, and on the day nobody could have determined the reach.
From the site to a shared view
The effort lay not in the platform but in making things uniform.
Open up the sources
An inventory per site, connection of the relevant systems, and normalisation onto a common schema.
Bring in the OT sources
Passive capture at the transitions and in selected operational networks, with no return channel into the processes.
Develop use cases
Detection logic for the routes that run across site and area boundaries, versioned and measured against its coverage.
Shift and processes
Building the staffing, triage criteria, escalation and reporting paths, plus playbooks for the most common scenarios.
What the operator had at the end
A continuous view across the sites in which IT and OT events are assessed together, a shift staffed around the clock with defined procedures, and the ability to determine the reach of an incident on the day.
For producing evidence to the regulator, what mattered was that detection and response can be documented, not only described.
What you can take from this
A SOC across several sites rarely fails on technology. It fails because every site names its sources differently. Normalisation is the work nobody wants to see and without which nothing works.
OT sources belong in from the start. Added later, they produce a second system beside the first, and the question of reach stays unanswered.
And staffing is part of the build, not an appendix. Detection with nobody to respond is a log file.
Related to this case study.
A similar project?
Referenzdetails nennen wir nach Freigabe und im persönlichen Gespräch.