BSI-Richtlinien zur Protokollierung: Vollständige Log-Datenwege nachweisen

Unternehmen sammeln heute große Mengen an Protokolldaten. Trotzdem bleibt im Audit oft eine einfache Frage unbeantwortet: Kommt ein sicherheitsrelevantes Ereignis tatsächlich vollständig von der Quelle über Collector und SIEM bis in das vorgesehene Archiv? Genau an dieser Stelle verbinden sich BSI-Richtlinien zur Protokollierung mit einem sehr praktischen Prüfproblem.

Ein installierter Agent, ein konfigurierter Collector oder ein gefülltes SIEM-Dashboard ist noch kein Nachweis für einen funktionierenden Datenweg. Entscheidend ist, ob relevante Ereignisse im richtigen Format, mit belastbarem Zeitstempel und innerhalb einer akzeptablen Zeit ankommen und später wiedergefunden werden können.

Was die BSI-Richtlinien zur Protokollierung verlangen

Der BSI-Mindeststandard zur Protokollierung und Detektion von Cyber-Angriffen, Version 2.0 fordert eine geplante und dokumentierte Erschließung der relevanten Datenquellen. Nach der Umsetzung ist zu prüfen, ob die vorgesehenen Quellen tatsächlich angebunden wurden und ob Datenformat, Informationsgehalt und Zeitsynchronisation stimmen.

Der IT-Grundschutz-Baustein OPS.1.1.5 Protokollierung ergänzt diese Sicht. Er behandelt unter anderem die Planung der Protokollierung, die Konfiguration von Protokollierungsfunktionen und die zentrale Bereitstellung und Auswertung von Protokollierungsdaten.

Wichtig ist die Claim-Grenze: Das BSI schreibt kein Produkt namens „LogPathProof“ und auch nicht zwingend ein synthetisches Testereignis vor. Ein solches Verfahren ist eine technische Operationalisierung der Anforderungen. Es kann einen belastbaren Nachweis liefern, ersetzt aber weder Sicherheitskonzept noch Schutzbedarfsfeststellung und garantiert für sich allein keine BSI-Konformität.

Das typische Problem: Konfiguration wird mit Funktion verwechselt

In vielen Organisationen wird die erfolgreiche Konfiguration einzelner Komponenten dokumentiert. Der Server schreibt Logs, der Collector ist erreichbar und im SIEM erscheinen regelmäßig Daten. Zwischen diesen Einzelbeobachtungen können dennoch Lücken entstehen:

• Ein Filter verwirft genau den Ereignistyp, der für einen Sicherheitsfall wichtig wäre.
• Felder werden beim Parsen falsch zugeordnet oder abgeschnitten.
• Die Zeit auf Quelle und Ziel weicht voneinander ab.
• Die Weiterleitung in das Langzeitarchiv funktioniert nur für einen Teil der Daten.
• Das Ereignis ist zwar gespeichert, lässt sich mit den vorgesehenen Suchkriterien aber nicht mehr finden.

Ein Audit benötigt deshalb mehr als Screenshots von Einstellungen. Es braucht einen Ende-zu-Ende-Nachweis, der den realen Datenweg prüft.

Eine direkte Lösung: Ein eindeutig markiertes Testereignis

Ein praxistauglicher Ansatz besteht darin, an einer ausgewählten Quelle ein ungefährliches, eindeutig markiertes Testereignis zu erzeugen. Die Markierung sollte einmalig sein, beispielsweise durch eine zufällige Test-ID. Danach wird der Weg des Ereignisses automatisiert oder manuell über alle vorgesehenen Stationen verfolgt.

1. Prüfziel festlegen: Quelle, Ereignistyp, erwartete Felder, Zielsystem, maximale Latenz und Aufbewahrungsziel werden vor dem Test dokumentiert.
2. Testereignis erzeugen: Das Ereignis muss sicher, reversibel und klar von produktiven Sicherheitsvorfällen unterscheidbar sein.
3. Transport prüfen: An jeder Station wird kontrolliert, ob die Test-ID vorhanden ist und ob das Ereignis unverändert oder nachvollziehbar normalisiert wurde.
4. Zeit und Inhalt vergleichen: Quellzeit, Empfangszeit, Verarbeitungszeit und Archivzeit werden gegenübergestellt. Pflichtfelder und Identitätsbezug werden kontrolliert.
5. Wiederauffindbarkeit testen: Eine zweite Person oder ein definierter Suchprozess muss das Ereignis anhand der vorgesehenen Kriterien finden können.
6. Ergebnis dokumentieren: Abweichungen erhalten Verantwortliche, Frist und Wiederholungstermin.

Drei konkrete Testfälle

Testfall 1: Administrativer Anmeldeversuch

Ein kontrollierter Anmeldeversuch mit einem Testkonto erzeugt ein klar definiertes Ereignis. Geprüft werden Benutzerkennung, Quellsystem, Ergebnis des Anmeldeversuchs, Zeitstempel und Zielsystem. Der Test ist besonders geeignet, um Identitätsbezug und Parsing zu kontrollieren.

Testfall 2: Geplante Konfigurationsänderung

Eine harmlose und sofort rückgängig zu machende Änderung wird mit einer Change-ID verknüpft. Anschließend wird geprüft, ob die technische Protokollierung mit dem organisatorischen Änderungsvorgang verbunden werden kann. So wird sichtbar, ob Audit-Trail und Betriebsprozess zusammenpassen.

Testfall 3: Wiederauffindbarkeit im Archiv

Nach Ablauf der normalen SIEM-Speicherphase wird ein zuvor erzeugtes Testereignis im vorgesehenen Archiv gesucht. Neben Integrität und Lesbarkeit zählen Suchdauer, Berechtigung, Dokumentation des Abrufs und die Frage, ob alle benötigten Felder erhalten geblieben sind.

Welche Kennzahlen helfen?

Für eine wiederholbare Prüfung sollten wenige, aber klare Kennzahlen verwendet werden:

• Anteil erfolgreich durchlaufener Testereignisse
• Latenz von der Quelle bis zum SIEM und bis zum Archiv
• Anzahl fehlender oder veränderter Pflichtfelder
• Zeit für die Wiederauffindbarkeit
• Anzahl offener Abweichungen und deren Alter

Diese Werte sind keine universellen BSI-Grenzwerte. Die Organisation muss sie aus Schutzbedarf, Architektur, Erkennungszielen und betrieblichen Anforderungen ableiten.

So entsteht ein auditfähiger Nachweis

Ein Prüfbericht sollte mindestens Test-ID, Datum, Verantwortliche, geprüfte Quelle, beteiligte Systeme, erwartetes Ergebnis, tatsächliches Ergebnis, Zeitabweichungen, Feldvergleich und gefundene Abweichungen enthalten. Screenshots können ergänzen, sollten aber nicht der einzige Beleg sein. Aussagekräftiger sind exportierbare Suchergebnisse, technische Zeitstempel und ein nachvollziehbarer Freigabeprozess.

Der Test sollte nach relevanten Änderungen erneut ausgeführt werden, zum Beispiel nach einem Collector-Update, einer Parser-Anpassung, dem Austausch einer Quelle oder einer Änderung der Archivierung. Zusätzlich ist ein risikobasierter regelmäßiger Turnus sinnvoll.

Fazit

BSI-gerechte Protokollierung wird nicht dadurch belastbar, dass überall Logs aktiviert sind. Der entscheidende Schritt ist der Nachweis, dass relevante Ereignisse vollständig, zeitlich plausibel und wiederauffindbar durch die gesamte Kette laufen. Ein eindeutig markiertes Testereignis macht diesen Nachweis wiederholbar und zeigt konkrete Lücken, bevor sie im Sicherheitsvorfall oder Audit auffallen.

Offizielle BSI-Quellen

• BSI-Mindeststandard Protokollierung und Detektion von Cyber-Angriffen, Version 2.0
• IT-Grundschutz OPS.1.1.5 Protokollierung

AI Governance Freelancer

Unterstützung bei AI Governance, KI-Code-Prüfung und sicherer Automatisierung

Ich unterstütze Unternehmen bei der sicheren Einführung von ChatGPT, Copilot, KI-Agenten und moderner Enterprise-Automatisierung. Mein Fokus liegt auf AI Governance, Compliance, sicherer KI-Nutzung und der strukturierten Kontrolle von KI-generiertem Code.

Zusätzlich verfüge ich über eigene Softwarelösungen zur automatisierten Analyse von Code, Skripten und KI-generierten Automatisierungen, um Risiken, unsichere Muster und Governance-Themen frühzeitig sichtbar zu machen.

Gerne tausche ich mich mit Ihnen in einem unverbindlichen virtuellen Kaffee über AI Governance, sichere KI-Einführung und Governance-Strategien im Enterprise-Umfeld aus.

Virtuellen Kaffee vereinbaren

Bildquelle: OpenAI