SIEM-Anbindung: Individualsoftware in die Angriffserkennung holen

Eine SIEM-Anbindung klingt nach einem Thema für die IT-Abteilung. Tatsächlich entscheidet sie darüber, ob sich nach einem Vorfall noch belegen lässt, wer welche Daten aus dem eigenen Fachverfahren geholt hat. Für zugekaufte Standardsysteme ist das geregelt. Ausgerechnet die selbst entwickelte Software, die den kritischen Prozess trägt, meldet nichts an die Systeme zur Angriffserkennung.
Mann am Stehschreibtisch in einem hellen Verwaltungsbüro, im Hintergrund unterhalten sich zwei Personen. Sinnbild für den störungsfreien Betrieb, den eine SIEM-Anbindung im Verborgenen absichert.
© KI-generiert (TenMedia)

Was eine SIEM-Anbindung leistet und wem sie fehlt

Ein SIEM sammelt die Meldungen aller IT-Systeme an einer Stelle und gleicht sie ab, damit Angriffe auffallen. Laut BSI erreichen dabei nur 48 Prozent der KRITIS-Betreiber einen Reifegrad von mindestens 3, beim Regelwerk dagegen rund 80 Prozent.

Eine SIEM-Anbindung übergibt sicherheitsrelevante Ereignisse einer Anwendung an ein Security Information and Event Management, also an die zentrale Sammelstelle für Sicherheitsmeldungen. Übergeben werden Anmeldungen, Rechteänderungen, Datenzugriffe und fachliche Ausnahmen, maschinenlesbar und über einen festen Weg wie Syslog, das Common Event Format oder eine Programmierschnittstelle.

Ordnung auf dem Papier ist damit häufiger vorhanden als die Fähigkeit, im Ernstfall zu belegen, was tatsächlich passiert ist.

Wofür Standardkonnektoren nicht gebaut sind

Für Firewalls, Verzeichnisdienste und Cloud-Plattformen liegen fertige Konnektoren bereit, weil diese Systeme in tausenden Organisationen gleich aussehen. Eine selbst entwickelte Fachanwendung gibt es genau einmal, und für Einzelstücke baut niemand einen Konnektor. Der Anschluss an das SIEM entsteht dort als eigenes kleines Projekt. Im IT-Sicherheitsmanagement tauchen solche Systeme oft nicht als eigene Position auf. Eine Bestandsaufnahme vor der SIEM-Anbindung findet regelmäßig dieselben Kandidaten:

Monitoring fragt anders als Angriffserkennung

Betriebsüberwachung und Angriffserkennungssysteme nutzen ähnliche Daten und beantworten verschiedene Fragen. Monitoring prüft, ob ein System funktioniert. Security Monitoring im Sinne eines SIEM prüft, ob jemand es missbraucht, und ob sich das später belegen lässt. Daraus folgen andere Aufbewahrungsfristen, andere Zugriffsrechte und eine andere Auswahl der Ereignisse. Eine tragfähige Cybersecurity-Strategie trennt beides sauber, statt das Betriebslog zum Sicherheitsnachweis zu erklären.

Systeme zur Angriffserkennung im BSIG

Die Pflicht steht in § 31 Absatz 2 BSIG. Betreiber kritischer Anlagen müssen dort Systeme zur Angriffserkennung einsetzen, und zwar für alle Systeme, Komponenten und Prozesse, die für die Funktionsfähigkeit der Anlage maßgeblich sind. Diese Erkennungssysteme müssen geeignete Parameter aus dem laufenden Betrieb fortlaufend und automatisch auswerten. Maßgeblich ist der kritische Prozess, nicht das einzelne Produkt. Erkennen ist nur der erste Schritt, danach folgen Melde- und Reaktionspflichten, die im Schwachstellenmanagement für KRITIS-Betreiber zusammenlaufen.

Warum die Herkunft der Software nichts ändert

Eine Eigenentwicklung fällt genauso unter die Pflicht wie ein Zukaufprodukt, sobald sie einen maßgeblichen Prozess trägt. In der Praxis fällt sie trotzdem heraus, weil die Prüfung entlang der Infrastruktur läuft, nicht entlang der Fachverfahren. Ein Genehmigungsverfahren, ein Abrechnungssystem oder ein Leitstellenwerkzeug erscheinen dann als Anwendung des Hauses und nicht als Logquelle. Die SIEM-Anbindung für Individualsoftware ist keine Sonderfrage, sondern der Teil des Nachweises, der zuletzt bearbeitet wird.

Wie oft der Nachweis fällig wird

§ 39 BSIG verlangt den Nachweis über Sicherheitsaudits, Prüfungen oder Zertifizierungen, alle drei Jahre. Drei Jahre klingen komfortabel, bis die Frage auftaucht, welche Fachanwendung eigentlich meldet. Eine revisionssichere Protokollierung lässt sich in wenigen Wochen nicht nachrüsten, wenn eine Anwendung ihre Meldungen bisher über hunderte Einzelstellen verstreut schreibt. Systeme zur Angriffserkennung scheitern in KRITIS-Betrieben selten am SIEM und oft am Zeitplan.

Welche Ereignisse gehören ins Protokoll?

Ins Protokoll gehören Vorgänge, aus denen sich Missbrauch ablesen lässt, nicht der Zustand des Servers. Ein Audit Log für die SIEM-Anbindung beschreibt deshalb Ereignisklassen statt einzelner Meldungen, damit die Auswahl ein Release später noch stimmt. Eine Prüfstelle erkennt an wenigen Zeilen, ob eine Anwendung Betriebsmeldungen oder auswertbare Sicherheitsereignisse schreibt. Ein Protokollierungskonzept nennt meist diese sieben Klassen:

❗ erfolgreiche und fehlgeschlagene Anmeldungen samt Kennung und Herkunft
❗ Änderungen an Rollen, Rechten und Gruppenzugehörigkeiten
❗ Zugriffe auf besonders schutzbedürftige Datenbestände
❗ Exporte, Massenabfragen und Druckvorgänge größeren Umfangs
❗ Änderungen an Konfiguration, Schnittstellen und Schwellenwerten
❗ fachliche Ausnahmen wie umgangene Vier-Augen-Freigaben
❗ administrative Eingriffe direkt auf Datenbank oder Dateisystem

Was nicht ins Protokoll gehört

Eine Protokollierung, die alles mitschreibt, erzeugt ein neues Risiko. Zugangsdaten, Sitzungsschlüssel und vollständige Inhalte schutzbedürftiger Datensätze sind im Logstrom schlechter geschützt als in der Anwendung selbst, weil mehr Personen darauf zugreifen. Protokolliert wird der Vorgang, nicht der Inhalt. Wo Personenbezug unvermeidbar ist, braucht es Löschfristen und ein begrenztes Auswertungsrecht, abgestimmt mit dem Berechtigungsmanagement der Organisation. Revisionssichere Protokollierung heißt unveränderbar und nachvollziehbar, nicht möglichst vollständig.

Ohne Struktur keine SIEM-Integration

Ein Satz wie „Fehler beim Speichern” ist für Menschen lesbar und für ein SIEM wertlos. Verwertbar wird ein Ereignis erst durch feste Felder für Zeitstempel, Ereignistyp, Kennung, Quelladresse, betroffenes Objekt und Ergebnis. Erst diese Felder erlauben Korrelation, also das Zusammenführen mehrerer Ereignisse zu einem Alarm. Darauf setzen die gängigen SIEM Use Cases auf, vom wiederholten Fehlversuch bis zum Massenexport außerhalb der Dienstzeit. Systeme zur Angriffserkennung werten Felder aus, keine Sätze. Aus unstrukturiertem Freitext entsteht kein belastbarer Alarm, nur Speicherverbrauch. Offene Schnittstellen sind dabei zugleich Angriffsfläche und aufschlussreichste Logquelle, weshalb API-Sicherheit und Protokollierung dieselben Ereignisse betreffen.

SIEM-Anbindung nachrüsten oder mitliefern

Der Aufwand hängt vor allem daran, wann die Frage nach der SIEM-Anbindung gestellt wird. In einer Neuentwicklung ist die SIEM-Anbindung eine Architekturentscheidung und kostet wenige Personentage. Im Bestand entscheidet, wie die Anwendung heute schreibt. Eine zentrale Logfunktion trägt das Sicherheitslog mit, hunderte verstreute Einzelstellen müssen erst zusammengeführt werden. Dieser Umbau ist der eigentliche Kostentreiber, nicht die Übergabe an das SIEM. Der Weg zur SIEM-Anbindung verläuft in fünf Etappen:

SIEM-Integration über Syslog, CEF oder API

Für die SIEM-Integration stehen drei Wege zur Verfügung, und die Wahl hängt an der Architektur der Anwendung, nicht am SIEM. Syslog ist der älteste und robusteste Weg und passt zu serverseitigen Anwendungen mit direktem Systemzugriff. Das Common Event Format, kurz CEF, ergänzt Syslog um eine feste Feldstruktur und wird von den meisten Plattformen ohne Zusatzarbeit gelesen. Eine SIEM-Integration über eine Programmierschnittstelle passt zu Cloud-Anwendungen und containerisierten Diensten, die kein Systemlog schreiben. Die Formatfrage entscheidet über den späteren Aufwand, weil ein nachträglicher Wechsel jede Korrelationsregel berührt. An sauber gebauten Schnittstellen bleibt die Einbindung ins SIEM einmalige Arbeit statt dauernder Nachpflege.

Wie lässt sich die Logmenge begrenzen?

Viele Plattformen rechnen nach Datenvolumen, deshalb wird eine ungefilterte SIEM-Anbindung schnell teuer. Gefiltert wird in der Anwendung, nicht erst auf der SIEM-Seite. Sonst wandert das Volumen trotzdem durch die Leitung und die Lizenz. Der Zuschnitt entsteht vor der SIEM-Integration, nicht im Betrieb. Vier Regeln reichen für die Trennung meist aus:

Was kostet die Nachrüstung im Bestand?

Pauschalpreise führen bei der SIEM-Anbindung in die Irre, weil vier Größen die Spanne bestimmen. Am schwersten wiegen Alter und Zustand der heutigen Protokollierung. Dazu kommen die Zahl der Ereignisklassen, das Zielformat und der Dokumentationsbedarf für Systeme zur Angriffserkennung. Der Aufwand für den Nachweis wird regelmäßig unterschätzt. TenMedia arbeitet bei der SIEM-Anbindung auf der Anwendungsseite und betreibt selbst kein SIEM. Zur Leistung gehören Protokollierungskonzept, Umbau auf strukturierte Ausgabe und Dokumentation für die Prüfstelle. Ob die Plattform im Haus läuft oder als Managed SIEM eingekauft wird, ändert daran nichts. Ein Beispiel dafür ist das Notfallhandbuch für die Berliner Feuerwehr, gebaut für eine Behörde mit KRITIS-Auftrag.

Hinweis: Dieser Beitrag dient der allgemeinen Information und stellt keine Rechtsberatung dar. Für verbindliche Auskünfte zu regulatorischen Anforderungen empfehlen wir die Konsultation einer spezialisierten Rechtsberatung.

FAQs

Reicht es, vorhandene Anwendungslogs an das SIEM weiterzuleiten? keyboard_arrow_down keyboard_arrow_up
Selten. Anwendungslogs bestehen meist aus Freitext für die Fehlersuche und enthalten weder feste Felder noch alle sicherheitsrelevanten Vorgänge. Eine SIEM-Anbindung verlangt strukturierte Ereignisse mit Zeitstempel, Kennung und Ergebnis. Ohne diesen Umbau entsteht Speicherverbrauch statt Erkennung. Der Aufwand dafür fällt einmalig an.
Gilt die Pflicht zu Systemen zur Angriffserkennung für alle NIS-2-Einrichtungen? keyboard_arrow_down keyboard_arrow_up
Nein. Die Pflicht, Systeme zur Angriffserkennung einzusetzen, trifft nach Paragraf 31 Absatz 2 BSIG die Betreiber kritischer Anlagen. Für andere besonders wichtige und wichtige Einrichtungen ergibt sich die Protokollierung mittelbar aus Paragraf 30 Absatz 2 BSIG, der die Bewältigung von Sicherheitsvorfällen verlangt. Der Umfang unterscheidet sich damit deutlich.
Wo endet die Zuständigkeit des Softwarehauses bei der SIEM-Anbindung? keyboard_arrow_down keyboard_arrow_up
Die Zuständigkeit endet an der Plattform. TenMedia arbeitet auf der Anwendungsseite und betreibt selbst kein SIEM. Zum Leistungsumfang gehören die Bestandsaufnahme der vorhandenen Protokollierung, ein Protokollierungskonzept mit den nötigen Ereignisklassen, der Umbau auf strukturierte Ausgabe in Syslog, im Common Event Format oder über eine Programmierschnittstelle, sowie die Dokumentation für Audit und Prüfstelle. Bei Neuentwicklungen entsteht die Protokollierung von Beginn an mit. Nicht dazu gehören die Auswahl und der Betrieb der Plattform, das Schreiben von Korrelationsregeln und die rechtliche Bewertung der Nachweispflicht. Diese Trennung hält die SIEM-Anbindung technisch sauber und die Verantwortung eindeutig.