Protokollierung und Monitoring

Protokollierung erfasst sicherheitsrelevante Ereignisse in Systemen und Anwendungen, Monitoring wertet sie aus. Beides zusammen macht Zugriffe nachvollziehbar und Vorfälle erkennbar. Der Konflikt liegt im Detail: Protokolle enthalten regelmäßig personenbezogene Daten, deshalb müssen Zweck, Umfang, Zugriff und Löschung ebenso geregelt sein wie die Erfassung selbst.

ISMSZuletzt geprüft:

In Audits führt kaum eine Maßnahme so zuverlässig zu zwei gegenläufigen Feststellungen wie die Protokollierung. Aus Sicht der Informationssicherheit wird zu wenig protokolliert und fast nie ausgewertet. Aus Sicht des Datenschutzes wird zu viel protokolliert, zu lange aufbewahrt und ohne klare Zweckbindung genutzt. Beides trifft in derselben Organisation regelmäßig gleichzeitig zu.

Welche Ereignisse sind sicherheitsrelevant und zu protokollieren?

Die Auswahl folgt dem Schutzbedarf, nicht der technischen Möglichkeit. Als sicherheitsrelevant gelten üblicherweise: An- und Abmeldungen sowie fehlgeschlagene Anmeldeversuche, Änderungen an Berechtigungen und Gruppenzugehörigkeiten, sämtliche Tätigkeiten privilegierter Konten, Änderungen an Sicherheitskonfigurationen, Zugriffe auf besonders schutzbedürftige Datenbestände, Start und Stopp der Protokollierung selbst sowie Änderungen an den Protokolldaten.

Am wichtigsten und am ehesten vergessen sind Änderungen an den Protokolldaten selbst. Protokolle, die von denjenigen verändert werden können, deren Handeln sie dokumentieren, taugen weder als Sicherheitsmaßnahme noch als Beweismittel. Deshalb gehören Protokolldaten in einen Speicherort, auf den die protokollierten Administratoren keinen schreibenden Zugriff haben.

Warum genügt Protokollierung ohne Auswertung nicht?

Protokollierung ohne Auswertung ist eine Datenhaltung, keine Kontrolle. Wirksam wird sie erst durch drei Festlegungen: welche Ereignisse eine automatische Meldung auslösen, wer diese Meldungen in welcher Zeit bearbeitet und in welchem Turnus eine anlassunabhängige Durchsicht stattfindet. Diese Festlegungen gehören in ein Protokollierungskonzept, nicht in die Konfiguration eines Werkzeugs. Die Konfiguration setzt sie um, ohne sie zu begründen.

Sind Protokolldaten personenbezogene Daten?

Protokolldaten sind in aller Regel personenbezogen: Sie verknüpfen eine Kennung mit einem Zeitpunkt und einer Handlung. Damit unterliegen sie den allgemeinen Anforderungen an eine Verarbeitung, einschließlich Zweckbindung und Datenminimierung. Da sie Verhalten von Beschäftigten abbilden, kann ihre Einführung und Ausgestaltung der Mitbestimmung unterliegen. Betriebsrat, Datenschutzbeauftragter und Rechtsberatung sollten deshalb vor der Einführung eingebunden werden, nicht nach der ersten Auswertung.

Drei Festlegungen entschärfen den Konflikt:

  • Zweckbindung. Der Zweck der Protokollierung wird schriftlich festgelegt, und die Nutzung zu anderen Zwecken – insbesondere zur Leistungs- und Verhaltenskontrolle – wird ausdrücklich ausgeschlossen oder geregelt.
  • Zugriffsbeschränkung. Nur ein benannter, kleiner Personenkreis darf Protokolldaten einsehen; die Einsichtnahme wird ihrerseits protokolliert. Für anlassbezogene Auswertungen empfiehlt sich ein Vier-Augen-Prinzip unter Beteiligung des Datenschutzbeauftragten.
  • Löschung. Für jede Protokollart wird eine Aufbewahrungsdauer festgelegt und technisch durchgesetzt. Allgemeingültige Fristen gibt es nicht; die Dauer ergibt sich aus dem Zweck, den einschlägigen Aufbewahrungspflichten und dem Risiko. Eine Festlegung muss aber existieren, und sie muss eingehalten werden.

Was verlangen DSGVO und BSIG zur Protokollierung?

Art. 32 Abs. 1 Buchst. b DSGVO stellt auf die Fähigkeit ab, Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme und Dienste auf Dauer sicherzustellen; die Nachvollziehbarkeit von Zugriffen dient allen vier Zielen. Buchstabe d desselben Absatzes verlangt zusätzlich ein Verfahren zur regelmäßigen Überprüfung und Bewertung der Wirksamkeit der Maßnahmen – für die Protokollierung heißt das, dass die Auswertung selbst überprüfbar sein muss, nicht nur die Erfassung. Im Maßnahmenkatalog des § 30 Abs. 2 Satz 2 BSIG steht die Bewältigung von Sicherheitsvorfällen in Nr. 2; die Zugriffskontrolle und die Verwaltung von IKT-Systemen, -Produkten und -Prozessen stehen in Nr. 9. Beides setzt eine Nachvollziehbarkeit voraus, die ohne Protokollierung nicht herzustellen ist. Zugleich ist die Protokollierung selbst eine Verarbeitung, die im Verzeichnis der Verarbeitungstätigkeiten zu führen ist.

Welche Fragen stellt ein Auditor zur Protokollierung?

Gefragt wird nach Umfang, Unveränderbarkeit und Auswertung. Welche Ereignisse werden erfasst, und wer hat den Umfang festgelegt? Wie ist sichergestellt, dass Protokolle nachträglich nicht verändert werden können? Wer darf sie einsehen, und wird die Einsichtnahme dokumentiert? Wie lange werden sie aufbewahrt, und wodurch wird die Löschung durchgesetzt? Wann fand die letzte anlassunabhängige Durchsicht statt, und was war ihr Ergebnis? Gibt es eine Vereinbarung mit der Arbeitnehmervertretung, und deckt sie die tatsächliche Nutzung ab?

Welche Nachweise belegen eine wirksame Protokollierung?

Tragfähig sind das Protokollierungskonzept mit Zweck, Umfang, Rollen und Aufbewahrung, der Eintrag im Verzeichnis der Verarbeitungstätigkeiten, die Berechtigungsliste für den Zugriff auf Protokolldaten, Belege für die Unveränderbarkeit oder die getrennte Speicherung, Nachweise durchgeführter Auswertungen mit Datum und Ergebnis, Löschprotokolle sowie, sofern einschlägig, die Vereinbarung mit der Arbeitnehmervertretung. Ein Zeitsynchronisationsnachweis gehört ebenfalls dazu: Ohne gemeinsame Zeitbasis lassen sich Ereignisse aus mehreren Systemen weder korrelieren noch als Beweismittel verwenden.

Die Frage vor dem Werkzeug: Was muss protokollieren

Die Frage vor dem Werkzeug ist die teurere: Welche Systeme müssen überhaupt protokollieren, und in welcher Tiefe.

Diese Antwort ist eine Ableitung aus dem Bestand. Ein System erbt den Schutzbedarf der primären Werte, die es trägt, insbesondere den Anspruch an Vertraulichkeit und Integrität, auch über mehrere Stufen. Wo dieser Anspruch hoch ist, ist die Protokollierungsanforderung entsprechend begründet, und sie erscheint als Anforderung an diesem Objekt, mit Verantwortlichem und Beleg. Umgekehrt fällt auf, wenn ein System mit hohem geerbtem Anspruch in keiner Protokollierung auftaucht, denn die Anforderung bleibt dort offen stehen.

Alle Einträge ansehenNach oben

Häufige Fragen

Compliance auf Ihren echten Assets

Rizzqo macht aus Framework-Anforderungen verantwortete Aufgaben auf Ihren vorhandenen Assets – und beziffert das Risiko in echtem Geld.

Made in GermanyGehostet in Ihrem LandMulti-Framework