Zum Hauptinhalt springen
§ 31 BSIG

Angriffserkennung nach § 31 BSIG

Ein SIEM allein ist noch keine Angriffserkennung. Wir bauen die Kette aus Protokollierung, Detektion, Reaktion und Nachweis — und prüfen, ob sie hält.

Ihre Vorteile

Was ein tragfähiges SzA ausmacht

Vom Anwendungsfall her gedacht, nicht vom Produkt

Herstellerneutral konzipiert
Wir verkaufen keine Lizenzen. Die Architektur richtet sich nach Ihren Anforderungen, nicht nach einem Produktportfolio.
Anwendungsfälle vor Produkt
Erst die Frage, welche Angriffe erkannt werden müssen — dann die Frage, welche Datenquellen und Werkzeuge das leisten.
Abdeckung statt Datensammlung
Mehr Protokolle bedeuten nicht mehr Erkennung. Wir bewerten, welche Quelle welchen Anwendungsfall tatsächlich abdeckt.
OT wird mitgedacht
Leittechnik lässt sich nicht wie ein Büronetz überwachen. Passive Verfahren, Zonenmodell und Rückwirkungsfreiheit gehören ins Konzept.
Reaktion als Teil des Systems
Alarmierung, Bereitschaft, Eskalation und die Verbindung zum Melde­prozess — sonst endet die Erkennung in einem ungelesenen Postfach.
Nachweis, dass es greift
Testfälle, mit denen die Erkennung nachweislich auslöst — dokumentiert als Beleg gegenüber Prüfern und Aufsicht.
Die Ausgangslage

Warum Angriffserkennung selten am Werkzeug scheitert

Systeme zur Angriffserkennung werden häufig als Produktentscheidung behandelt: Werkzeug beschaffen, Protokolle anschließen, Haken setzen. Was dabei ungeklärt bleibt, sind die entscheidenden Fragen — welche Angriffe damit tatsächlich erkennbar sind, wer die Meldung um drei Uhr nachts sieht und was danach passiert.

Genau das prüft eine Aufsicht. Der Nachweis besteht nicht aus einer Rechnung über eine SIEM-Lizenz, sondern aus dem Beleg, dass definierte Szenarien erkannt werden, dass eine Reaktionskette existiert und dass beides getestet wurde. Ohne diesen Beleg ist die Anforderung formal beschafft, aber nicht erfüllt.

Der zweite blinde Fleck ist die Produktion. Wer Erkennungswerkzeuge aus der Büro-IT unverändert in die Leittechnik trägt, riskiert Rückwirkungen auf Anlagen, die nicht dafür gebaut sind. OT braucht ein eigenes Konzept — passiv, segmentiert und mit klaren Übergängen.

Leistungsbereiche

Was wir liefern

Konzeption, Einführungsbegleitung und Wirksamkeitsnachweis

Bedrohungs- und Anwendungsfallkatalog

Priorisierte Szenarien, abgeleitet aus Ihren kritischen Assets und der realen Bedrohungslage Ihrer Branche.

Datenquellen und Abdeckung

Welche Protokolle welchen Anwendungsfall abdecken, wo Lücken bestehen und welche Aufbewahrungsfristen gelten.

Architektur

Erfassung, Normalisierung, Korrelation, Speicherung und Alarmierung — inklusive der Anbindung von OT-Segmenten.

Betriebsmodell

Wer wertet aus, in welchen Zeiten, mit welcher Eskalation: intern, mit Dienstleister oder in Kombination.

Anbindung an den Incident-Prozess

Vom Alarm zur Bewertung zur Meldeentscheidung — mit den Fristen des BSIG im Blick.

Wirksamkeitstests

Kontrollierte Testfälle je Anwendungsfall, dokumentiert mit Zeitstempel und Ergebnis.

Leistungsumfang

Was wir liefern

  • Anwendungsfallkatalog mit Priorisierung
  • Datenquellen- und Abdeckungsanalyse mit Lückenliste
  • Architektur- und Betriebskonzept
  • Konzept für Alarmierung, Bereitschaft und Eskalation
  • Anbindung an Incident-Response- und Meldeprozess
  • Dokumentierte Wirksamkeitstests je Anwendungsfall
  • Aufbewahrungs- und Löschkonzept für Protokolldaten
Der Ablauf

So arbeiten wir

01

Anforderungen & Szenarien

Kritische Assets, Bedrohungsszenarien und die Anwendungsfälle, die erkannt werden müssen — priorisiert nach Risiko.

02

Datenquellen bewerten

Abgleich, welche vorhandenen Protokolle die Anwendungsfälle abdecken und wo nachgerüstet werden muss.

03

Architektur

Konzept für Erfassung, Korrelation, Speicherung und Alarmierung, abgestimmt auf Ihre IT- und OT-Landschaft.

04

Betrieb festlegen

Zuständigkeiten, Servicezeiten und Eskalationswege verbindlich klären — auch für nachts und Wochenende.

05

Verifizieren

Testfälle durchspielen, Erkennung nachweisen, Fehlalarme reduzieren und das Ergebnis dokumentieren.

FAQ

Häufige Fragen

Für wen gilt § 31 BSIG?

Die Pflicht zum Einsatz von Systemen zur Angriffserkennung richtet sich an Betreiber kritischer Anlagen. Für andere Einrichtungen ergibt sich die Anforderung mittelbar aus § 30 BSIG, der unter anderem Konzepte zur Erkennung und Bewältigung von Sicherheitsvorfällen verlangt — ohne die Technik dafür festzulegen.

Brauchen wir dafür ein SIEM?

Nicht zwingend. Ein SIEM ist ein Werkzeug, keine Anforderung. Entscheidend ist, ob die priorisierten Anwendungsfälle erkannt werden, ob jemand den Alarm sieht und ob eine Reaktion folgt. In kleineren Umgebungen lässt sich das auch mit schlankeren Mitteln erreichen.

Können Sie unsere Produktionsanlagen überwachen?

Leittechnik erfordert ein anderes Vorgehen als Büro-IT: passive Verfahren statt aktiver Scans, Rückwirkungsfreiheit als harte Bedingung und ein Zonenmodell, das die Übergänge definiert. Genau diese Trennung planen wir mit ein, statt IT-Werkzeuge unverändert in die OT zu tragen.

Betreiben Sie die Angriffserkennung auch?

Wir konzipieren, führen ein und weisen die Wirksamkeit nach. Den 24/7-Betrieb übernimmt entweder Ihr eigenes Team oder ein spezialisierter Dienstleister — die Auswahl begleiten wir herstellerneutral.

Lesetipp: Wie Erkennung und Meldepflicht zusammenhängen, erklärt unser Glossareintrag zum BSI-Meldewesen.

Erkennen, bevor die Aufsicht fragt

Sagen Sie uns, welche Protokolle Sie heute erheben. Wir bewerten, welche Angriffe damit erkennbar wären.

Konzept anfragen