Systeme zur Angriffserkennung: Warum installierte Technik noch keine Detektion ist

Viele Unternehmen verfügen bereits über ein SIEM, ein EDR oder zumindest ein zentrales Log-Management. Trotzdem bestehen die wenigsten davon eine Prüfung nach BSI Orientierungshilfe SzA auf Anhieb. Der Grund liegt fast nie in fehlender Technik. Er liegt darin, dass Systeme Daten sammeln, ohne dass daraus eine belastbare Erkennung wird. Was die Orientierungshilfe wirklich verlangt, wo Umgebungen in der Praxis scheitern und wie sich echte Detektionsfähigkeit aufbauen lässt.

Was Systeme zur Angriffserkennung laut BSI leisten müssen

Die BSI Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung (SzA) gliedert die Anforderungen in drei Funktionsbereiche: Protokollierung, Detektion und Reaktion. Auf den ersten Blick klingt das nach reiner Technik. Tatsächlich steckt in jedem der drei Bereiche eine eigene Disziplin, die selten gleich gut ausgeprägt ist.

Protokollierung bedeutet zuerst Vollständigkeit, nicht Menge. Ein System kann nur erkennen, was es sieht. In klassischer Büro-IT ist zentrales Logging heute meist etabliert, in Produktions- und OT-Umgebungen dagegen selten. Komponenten, die aus Ressourcengründen nicht selbst protokollieren können, benötigen eine Überwachung ihres Netzwerksegments von außen, deren Ergebnisse ebenfalls in die zentrale Auswertung einfließen müssen.

Detektion verlangt ausdrücklich, dass Protokolldaten nicht rein automatisiert ausgewertet werden. Technische Systeme erkennen Abweichungen von gelernten Mustern zuverlässig, können aber kaum einschätzen, ob eine Abweichung harmlos, ein Betriebsproblem oder ein tatsächlicher Angriff ist. Diese Bewertung bleibt explizit Aufgabe von Fachpersonal.

Reaktion heißt benannte Verantwortliche, standardisierte Abläufe und eine klare Abwägung zwischen Eindämmung und der Aufrechterhaltung des eigentlichen Betriebs. Gerade bei kritischen Anlagen kann zu aggressives automatisches Blockieren selbst zur Störung werden.

Wo die meisten Umgebungen tatsächlich scheitern

In der Praxis liegt die Lücke selten bei der Technik selbst, sondern bei der Konfiguration und Pflege:

• Generische Regelbasis: Korrelationsregeln werden aus Standard-Vorlagen übernommen, statt auf die eigene Infrastruktur und die eigenen kritischen Assets zugeschnitten zu sein.
• Blinde Flecken in OT und Cloud: Produktionsanlagen und Cloud-Dienste werden bei der Log-Quellen-Planung regelmäßig vergessen, obwohl sie zu den relevantesten Angriffsflächen zählen.
• Fehlende Asset-Transparenz: Ohne Klarheit darüber, welche Geräte im Netzwerk existieren und wer mit wem kommuniziert, bleibt jede nachgelagerte Detektion Stückwerk.
• Ungeübte statt nur dokumentierte Eskalation: Ein Reaktionsplan auf Papier hilft wenig, wenn die Meldewege im Ernstfall zum ersten Mal getestet werden.

Warum das im Ernstfall zum Problem wird

Ein System, das Daten sammelt, aber nicht wirksam auswertet, verschafft eine trügerische Sicherheit. Auf dem Papier ist eine Lösung vorhanden, im Ernstfall bleibt der entscheidende Alarm jedoch aus oder geht in irrelevanten Meldungen unter. Genau diese Lücke zwischen „installiert“ und „wirksam“ ist es, die eine Nachweisprüfung nach OH SzA und RUN-Methodik offenlegt: Bewertet wird nicht, ob ein SIEM existiert, sondern ob es in den drei Bereichen Protokollierung, Detektion und Reaktion tatsächlich einen belastbaren Reifegrad erreicht. Offiziell mindestens UG3, mit UG4 als eigentlichem Regelziel.

Wie sich echte Erkennungsfähigkeit aufbauen lässt

• Asset- und Log-Quellen-Inventur zuerst, bevor über neue Regeln oder neue Tools gesprochen wird , insbesondere OT- und Cloud-Umgebungen werden häufig übersehen.
• MITRE-ATT&CK-Mapping der bestehenden Regelbasis, um Blindstellen sichtbar zu machen statt sie zu erahnen. Typisches Ergebnis: gute Abdeckung bei initialem Zugriff, große Lücken bei Lateral Movement oder Exfiltration.
• Priorisierung nach realistischem Angriffspfad, nicht nach der Menge verfügbarer Regelvorlagen im Marktplatz des SIEM-Herstellers.
• Eskalationswege real durchspielen, nicht nur dokumentieren. Der Unterschied zeigt sich erst unter Zeitdruck.
• Purple Teaming als Validierung einplanen: Angreifer- und Verteidigerseite arbeiten zusammen, während beobachtet wird, ob Regeln tatsächlich anschlagen und Eskalation in der dokumentierten Zeit ankommt.

Warnzeichen, dass Ihre SzA nur auf dem Papier funktioniert

1. Niemand kann auf Anhieb sagen, wie viele der eingehenden Logs tatsächlich in eine aktive Korrelationsregel einfließen.
2. Die Regelbasis wurde seit der Ersteinrichtung nicht mehr überarbeitet.
3. OT-, Cloud- oder Homeoffice-Umgebungen sind nicht oder nur teilweise an die zentrale Auswertung angebunden.
4. Der letzte Test der Eskalationskette liegt länger als zwölf Monate zurück oder hat nie stattgefunden.
5. Niemand im Haus könnte spontan sagen, welchen Umsetzungsgrad (UG0–UG5) die eigene SzA nach OH SzA aktuell erreicht.

Fazit

Ein SIEM oder EDR ist die Voraussetzung für Angriffserkennung, nicht das Ergebnis. Ob daraus eine belastbare Detektionsfähigkeit wird, entscheidet sich an der Qualität der Log-Abdeckung, an sauber zugeschnittenen Korrelationsregeln und an geübten statt nur dokumentierten Reaktionswegen. Genau das prüft eine Nachweisprüfung nach OH SzA und genau da lohnt es sich, vorher selbst genau hinzuschauen.

Sie möchten wissen, welchen Umsetzungsgrad Ihre eigene SzA-Landschaft heute tatsächlich erreicht?

Vereinbaren Sie ein kostenfreies Erstgespräch mit unseren Cyber-Security-Experten.

FAQ