Ein Logkonzept legt fest, welche Sicherheitsereignisse aufgezeichnet werden, wie sie zur Auswertung gelangen und wer bei einem Hinweis handelt. Die Menge der gespeicherten Ereignisse sagt wenig darüber aus, ob ein Angriff erkannt oder ein Vorfall aufgeklärt werden kann. Entscheidend ist die Verbindung zwischen einem konkreten Risiko, einer geeigneten Quelle und einer funktionierenden Reaktion.
Dieser Leitfaden führt durch Ereignisauswahl, Datenbegrenzung, Architektur, Aufbewahrung und Alarmbearbeitung. Ein ausgefülltes Beispiel zeigt, wie eine auffällige Änderung von Administratorrechten vom Quellsystem bis zum Bearbeitungsnachweis verfolgt wird. Die vorgeschlagenen Kontrollen sind anhand Ihrer tatsächlichen Umgebung und der anwendbaren Anforderungen auszuwählen.
Sicherheitsprotokollierung ist selbst eine Datenverarbeitung
Benutzernamen, Gerätekennungen, IP-Adressen und Zeitpunkte können personenbezogene Daten sein. Deshalb müssen Zweck, Rechtsgrundlage, Datenumfang, Empfänger und Speicherfristen der Protokollierung bestimmt werden. Eine Sicherheitsmaßnahme ist nicht allein wegen ihres nützlichen Zwecks von den übrigen Datenschutzanforderungen ausgenommen.
Artikel 32 der DSGVO verlangt ein dem Risiko angemessenes Schutzniveau und die Überprüfung der Maßnahmen. Daraus folgt keine pauschale Pflicht, jedes Ereignis ein Jahr zu speichern oder ein Produkt namens SIEM zu kaufen. Spezifische gesetzliche, vertragliche oder sektorale Anforderungen müssen zusätzlich identifiziert und ihrem jeweiligen Geltungsbereich zugeordnet werden.
Bei Beschäftigten sind außerdem der konkrete arbeitsbezogene Zweck und gegebenenfalls Beteiligungsrechte zu prüfen. § 87 Abs. 1 Nr. 6 BetrVG betrifft technische Einrichtungen zur Verhaltens- oder Leistungsüberwachung. Technische Qualität der Logs beantwortet weder diese Beteiligungsfrage noch die Zulässigkeit einer späteren Auswertung für andere Zwecke.
1. Die zu erkennenden Situationen festlegen
Beginnen Sie mit wenigen relevanten Szenarien: Ein privilegiertes Konto wird ohne Freigabe angelegt, eine Schutzfunktion wird abgeschaltet oder ein ungewöhnlich großer Datenexport findet statt. Benennen Sie jeweils, welche Entscheidung die Organisation auf Grundlage eines Hinweises treffen können muss. So lässt sich prüfen, welche Ereignisse wirklich benötigt werden.
Für jedes Szenario gehören Quelle, Ereignistyp, erforderliche Datenfelder und zuständige Auswertung in den Logkatalog. Verknüpfen Sie die Quellen mit der IT-Systemlandschaft. Berücksichtigen Sie dabei Cloud-Dienste, Identitätsplattformen und Schnittstellen, die außerhalb der eigenen Serverumgebung liegen.
Die internationale Behördenempfehlung zu Ereignisprotokollierung und Bedrohungserkennung vom August 2024 verbindet eine freigegebene Protokollierungspolitik mit zentraler Auswertung, geschützter Speicherung und einer Erkennungsstrategie. Sie ist eine technische Orientierung. Ihre Empfehlungen und enthaltene Verweise auf ausländische Vorgaben sind keine allgemeinen deutschen Aufbewahrungspflichten.
2. Ereignisse und Felder gezielt auswählen
Prüfen Sie insbesondere Anmeldungen, Rechteänderungen, administrative Eingriffe, sicherheitsrelevante Konfigurationsänderungen und Zugriffe auf besonders schutzbedürftige Daten. Nicht jede Anwendung kann alle Ereignisse gleichermaßen liefern. Halten Sie deshalb fest, welche Auditfunktion aktiviert werden muss und ob die verwendete Produktversion sie tatsächlich bereitstellt.
Als Ausgangspunkt für einen Ereignisdatensatz eignen sich Zeitangabe, Quelle, handelndes Konto, Aktion, betroffenes Objekt und Ergebnis. Ob zusätzliche Felder nötig sind, hängt vom Szenario ab. Die Kontokennung kann etwa für eine Rechteänderung erforderlich sein, während der Inhalt einer geöffneten Personalakte für die Zugriffskontrolle regelmäßig keinen zusätzlichen Erkenntnisgewinn bringt.
| Szenario | Geeignete Ereignisinformation | Nicht automatisch erforderlich |
|---|---|---|
| Neues Administratorkonto | Auslösendes Konto, neue Rolle, Zielkonto und Zeitpunkt | Vollständige Stammdaten der Person |
| Fehlgeschlagene Anmeldung | Konto- oder Vorgangskennung, Quelle, Zeitpunkt und Ergebnis | Eingegebenes Passwort |
| Datenexport | Berechtigtes Konto, Datenbereich, Umfang und Exportzeit | Kopie der exportierten Datensätze im Log |
| Schutzfunktion abgeschaltet | System, Einstellung, handelndes Konto und Änderung | Vollständiger Bildschirmmitschnitt |
| Zugriff auf geschützten Datensatz | Berechtigungsbezug, Datensatzreferenz und Aktion | Fachlicher Inhalt des Datensatzes |
Überprüfen Sie die Auswahl mit der Feldmatrix zur Datenminimierung. Weniger Daten bedeuten nicht automatisch schlechtere Erkennung. Häufig lässt sich ein Sicherheitsereignis mit einer stabilen technischen Referenz nachvollziehen, ohne vertrauliche Inhalte erneut abzulegen.
3. Geheimnisse und unnötige Inhalte ausschließen
Passwörter, Sitzungstoken und geheime API-Schlüssel gehören nicht in gewöhnliche Betriebs- oder Sicherheitslogs. Sie können Angreifern nach einem Zugriff auf die Protokolle zusätzliche Berechtigungen verschaffen. Prüfen Sie insbesondere Fehlermeldungen, Debugfunktionen und vollständige HTTP-Anfragen, weil dort unbemerkt Zugangsdaten oder Formulareingaben landen können. Bei der Umsetzung auf Betriebssystemebene verbindet der Arbeitsplan zur Windows- und Linux-Härtung Protokolleinstellungen mit Dienstekonfiguration, Berechtigungen und kontrollierten Ausnahmen.
Ein bloßer Feldname garantiert keinen Schutz. Ein Nutzer kann versehentlich ein Passwort in das Namensfeld eintragen; ein technischer Fehler kann eine komplette Anfrage in eine Fehlerspur kopieren. Begrenzen Sie deshalb Eingaben und Protokollausgaben an geeigneten Stellen und prüfen Sie repräsentative Fehlersituationen mit synthetischen Daten.
Auch maskierte oder gekürzte Werte müssen bewertet werden. Ein teilweise sichtbares Token kann je nach Aufbau noch zu viel verraten. Eine gehashte Kennung kann weiterhin einer Person zugeordnet werden. Dokumentieren Sie, welchen Zweck eine solche Referenz erfüllt und wer die Zuordnung herstellen kann, statt sie pauschal als anonym zu behandeln.
4. Sammlung und Zeitbezug zuverlässig gestalten
Legen Sie fest, wie Ereignisse vom Quellsystem zur geschützten Auswertung gelangen und was bei einer Unterbrechung passiert. Prüfen Sie Puffer, Kapazität, Übertragungsfehler und Wiederanlauf. Ein Dienst kann lokal weiterlaufen, obwohl seine Sicherheitsereignisse seit Tagen nicht mehr in der zentralen Suche erscheinen.
Synchronisieren Sie die Zeitquellen und berücksichtigen Sie Zeitzonen sowie die Darstellung im Analysewerkzeug. Vergleichen Sie bei einer Prüfung den Zeitpunkt an der Quelle, beim Eingang und in der Auswertung. Eine Verzögerung der Übertragung ist etwas anderes als eine falsch gehende Uhr und braucht eine andere Korrektur.
Beschreiben Sie auch die Grenzen der Architektur. Falls ein älteres Gerät nur wenige Ereignisse liefern kann, kann eine ergänzende Quelle hilfreich sein. Deren Aussagekraft muss aber zum konkreten Vorgang passen. Ein Netzfluss allein beweist nicht, welche Person innerhalb einer Anwendung einen bestimmten Datensatz gelesen hat.
5. Zugriffe und Integrität der Logs schützen
Trennen Sie nach Möglichkeit den Betrieb der überwachten Systeme von der Verwaltung ihrer Sicherheitsnachweise. Ein kompromittiertes Administratorkonto sollte nicht ohne weitere Hürde gleichzeitig die relevanten zentralen Spuren löschen können. Beschränken Sie Lese-, Export-, Änderungs- und Löschrechte auf die jeweiligen Aufgaben.
Dokumentieren Sie, wie Zugriffe auf die Logplattform selbst nachvollzogen werden. Bei kleinen Teams kann eine vollständige personelle Trennung schwierig sein; dann sind geeignete zusätzliche Kontrollen und nachvollziehbare Freigaben zu bestimmen. Die reine Benennung verschiedener Rollen auf dem Papier schafft keine technische Trennung.
Schützen Sie Übertragung und Speicherung entsprechend dem Risiko und prüfen Sie die Wiederherstellung. Eine Integritätsprüfung oder ein unveränderbarer Speicher kann einzelne Gefährdungen reduzieren. Daraus folgt keine automatische gerichtliche Beweiskraft sämtlicher Einträge. Auch Herkunft, Vollständigkeit, zulässige Erhebung und die dokumentierte Behandlung des Materials spielen eine Rolle.
6. Aufbewahrung nach Zweck und Pflicht begründen
Definieren Sie Fristen je Ereignisgruppe und Verwendungszweck. Berücksichtigen Sie, wie Hinweise entdeckt und untersucht werden, welche Informationen dafür benötigt werden und welche besonderen Vorgaben tatsächlich gelten. Eine Speichervoreinstellung des Herstellers ist weder eine rechtliche Obergrenze noch eine ausreichende Begründung für die Aufbewahrung.
Unterscheiden Sie die reguläre Protokollierung von einem abgegrenzten Untersuchungsauszug. Wenn ein Vorfall untersucht wird, kann ein bestimmter Zeitraum aus ausgewählten Quellen gesichert werden müssen. Das rechtfertigt nicht automatisch eine unbegrenzte Aufbewahrung aller Logs. Halten Sie Anlass, Umfang, Zugriff und erneute Prüfung der gesicherten Kopie fest.
Nehmen Sie die Regeln in das Löschkonzept auf. Prüfen Sie anschließend, ob die ältesten zugänglichen Ereignisse tatsächlich der Regel entsprechen und ob Exporte, Sicherungen oder zweite Analyseplattformen unbeachtete Kopien enthalten. Eine automatisch gestartete Löschaufgabe genügt nicht als Nachweis, wenn sie regelmäßig fehlschlägt.
7. Ausgefüllter Alarmfall: neue Administratorrolle
Das fiktive Unternehmen Nordbogen betreibt eine Kundenanwendung mit zentraler Benutzerverwaltung. Es möchte erkennen, wenn außerhalb des freigegebenen Änderungswegs eine Administratorrolle vergeben wird. Das Beispiel beschreibt einen abgestimmten Kontrollversuch mit Testkonten, keinen Angriff auf ein reales System.
Quelle und Ereignis: Die Benutzerverwaltung erzeugt bei der Rollenvergabe einen Datensatz mit Zeit, auslösendem Testkonto, Zielkonto und neuer Rolle. Kundendaten und Zugangsdaten werden nicht mitgespeichert. Die Administration bestätigt zunächst, dass das Ereignis an der Quelle vorhanden ist.
Erkennung: Die Auswertung gleicht die Rollenänderung mit dem definierten Freigabeverfahren ab. Eine fehlende Zuordnung löst eine Prüfung aus. Der Hinweis bedeutet zunächst „Änderung überprüfen“ und nicht automatisch „Angriff bestätigt“. Eine verspätet dokumentierte berechtigte Änderung muss von einem unberechtigten Eingriff unterschieden werden können.
Bearbeitung: Der zuständige Sicherheitskontakt erhält die Meldung, bestätigt die Übernahme und prüft die Herkunft mit dem Systemverantwortlichen. Bei Abwesenheit übernimmt die benannte Vertretung. Eine berechtigte Person kann die Rolle begrenzen, wenn sich der Verdacht erhärtet und die vorgesehenen Voraussetzungen für eine Sofortmaßnahme erfüllt sind.
Ergebnis: Im ersten Durchlauf trifft das Ereignis ein, der Hinweis landet jedoch in einem unbetreuten Postfach. Die Sammlung funktioniert, die Bearbeitung nicht. Nordbogen korrigiert die Empfängerregel und wiederholt denselben begrenzten Versuch. Der Nachweis enthält Ereignisreferenz, beobachtete Zeitpunkte, verantwortliche Rollen und Korrektur, ohne die fachlichen Inhalte der Kundenanwendung zu kopieren.
8. Information und laufende Überprüfung verankern
Beschreiben Sie die Protokollierung in den erforderlichen Datenschutzinformationen und im Verarbeitungsverzeichnis. Für Beschäftigte müssen die Informationen den tatsächlichen Umfang und Zweck wiedergeben. Eine allgemeine Formulierung „Wir nutzen Daten zur Sicherheit“ erklärt keine umfassende Auswertung individueller Aktivitäten.
Die Informationssicherheitsrichtlinie gibt den organisatorischen Rahmen. Die IT-Nutzungsrichtlinie erläutert die für Nutzer relevanten Regeln. Änderungen an Quellen, Datenfeldern und Auswertungszwecken müssen in diesen Dokumenten und in der praktischen Konfiguration zusammenpassen.
Überprüfen Sie regelmäßig die Erkennung und nicht nur das Datenvolumen. Werden neue Systeme berücksichtigt, fallen Quellen aus und führen zu viele Fehlalarme dazu, dass Hinweise ignoriert werden? Halten Sie für relevante Abweichungen eine konkrete Maßnahme fest. Ein wirksames Logkonzept endet erst bei einer nachvollziehbaren Bearbeitung und einer überprüften Verbesserung des Verfahrens.