ISO 27001:2022 regelt Protokollierung und Überwachung hauptsächlich über drei Maßnahmen aus Annex A: 8.15 (Protokollierung), 8.16 (Überwachungsaktivitäten) und 8.17 (Zeitsynchronisation). Zusammen verlangen sie, sicherheitsrelevante Ereignisse aufzuzeichnen, diese Aufzeichnungen zu schützen, Systeme auf anomales Verhalten zu beobachten und Zeitstempel verlässlich zu halten. Auditoren wollen keinen Toolnamen. Sie wollen Nachweise, dass Sie entschieden haben, was protokolliert wird, dass jemand die Logs prüft und dass auf das Gesehene reagiert wird.
Dieser Leitfaden erklärt jede Maßnahme in verständlichen Worten, zeigt typische Auditoranforderungen an Belege und gibt eine Einführungsreihenfolge, die auch für ein kleines Sicherheitsteam funktioniert.
Kurzfassung
- Maßnahme 8.15 betrifft das Erstellen, Schützen und Auswerten von Logs. Maßnahme 8.16 betrifft das aktive Beobachten auf Anomalien. Wer eine besteht, besteht noch nicht die andere.
- Definieren Sie zuerst den Geltungsbereich: welche Systeme, welche Ereignisse, wer prüft, wie oft und wie lange Aufzeichnungen aufbewahrt werden. Halten Sie es schriftlich fest und zeigen Sie, dass es gelebt wird.
- Zentralisieren Sie Logs und halten Sie Uhrzeiten synchron (8.17), sonst können Sie einen Vorfall systemübergreifend nicht rekonstruieren.
- Trennen Sie Aufgaben, wo immer möglich: Personen, die ein System administrieren, sollten nicht die einzigen sein, die dessen Logs prüfen.
- Planen Sie den Aufwand frühzeitig ein. Protokollierungswerkzeuge und Prüfzeit sind reale Kostenpositionen in einem ISO-27001-Projekt.
Inhaltsverzeichnis
- Wie die drei Maßnahmen zusammenwirken
- Maßnahme 8.15: Protokollierung, die ein Audit besteht
- Maßnahme 8.16: Überwachung, die etwas erkennt
- Maßnahme 8.17: Die unscheinbare, die Untersuchungen zum Scheitern bringt
- Nachweise, die ein Auditor einsehen möchte
- Eine Einführungsreihenfolge, die funktioniert
- Branchenhinweise: Finanzen und Zahlungsdaten
- Häufige Fehler
- Unsere Einschätzung
- Aufwand schätzen, bevor Sie sich festlegen
- FAQ
- Quellen
Wie die drei Maßnahmen zusammenwirken
Stellen Sie sich eine Pipeline vor. Maßnahme 8.15 erzeugt und schützt das Rohmaterial. Maßnahme 8.17 macht die Zeitstempel dieses Materials vergleichbar. Maßnahme 8.16 verwandelt es in Erkennung.
| Maßnahme | Was sie verlangt | Typische Nachweise |
|---|---|---|
| 8.15 Protokollierung | Protokolle von Aktivitäten, Ausnahmen, Fehlern und anderen relevanten Ereignissen erstellen, speichern, schützen und auswerten | Protokollierungsstandard, Beispiel-Logs, Aufbewahrungseinstellungen, Zugangsbeschränkungen für Log-Speicher |
| 8.16 Überwachungsaktivitäten | Netzwerke, Systeme und Anwendungen auf anomales Verhalten überwachen und angemessen reagieren | Alarmregeln, Prüfaufzeichnungen, aus Alarmen eröffnete Tickets, Eskalationsweg |
| 8.17 Zeitsynchronisation | Uhrzeiten informationsverarbeitender Systeme auf anerkannte Zeitquellen abstimmen | NTP-Konfiguration, Screenshot oder Export mit konsistenter Zeit über alle Systeme hinweg |
Ein häufiger Auditbefund ist ein Unternehmen, das alles protokolliert, aber nichts auswertet. Logs, die in einem Speicher liegen, sind bestenfalls ein Nachweis für 8.15. Eine hilfreiche Eselsbrücke: Protokollierung beantwortet „Was ist passiert?", Überwachung beantwortet „Stimmt gerade etwas nicht?"
Maßnahme 8.15: Protokollierung, die ein Audit besteht
Beginnen Sie beim Risiko, nicht beim Werkzeug. Ihre Risikobeurteilung sollte aufzeigen, welche Systeme relevant sind, und Ihr Protokollierungsstandard sollte daraus folgen.
Was zu protokollieren ist
Eine vertretbare Mindestbasis umfasst:
- Authentifizierungsereignisse: erfolgreiche und fehlgeschlagene Anmeldungen, MFA-Änderungen, Passwortzurücksetzungen.
- Privilegierte Aktivitäten: Administrationshandlungen, Rollenänderungen, Nutzung von Break-Glass-Konten.
- Zugriff auf sensible Daten und Änderungen an Zugriffsrechten.
- Systemänderungen: Konfigurationsänderungen, neue Dienste, Deployments.
- Ausgaben von Sicherheitswerkzeugen: Endgeräteschutz, Firewall, Angriffserkennung, Ergebnisse von Schwachstellenscannern.
- Fehler und Ausnahmen: fehlgeschlagene Backups, Dienstabstürze, unerwartete Abschaltungen.
Sie müssen nicht jedes System gleich tief protokollieren. Eine Kundendatenbank und ein Drucker sollten nicht die gleiche Protokollierungslast tragen, und ein Auditor wird erwarten, diese Überlegung in Ihrer Risikobehandlung zu finden.
Die Logs selbst schützen
Logs sind nur dann Beweismittel, wenn niemand sie unbemerkt verändern kann. Praktische Schritte:
- Logs an einen zentralen Speicher außerhalb des erzeugenden Systems weiterleiten.
- Schreib- und Löschrechte auf eine kleine Gruppe beschränken und Zugriffe auf den Log-Speicher selbst protokollieren.
- Für hochwertige Logs unveränderlichen oder einmal-beschreibbaren Speicher nutzen, wo die Plattform das unterstützt.
- Eine Aufbewahrungsdauer festlegen, die gesetzlichen, vertraglichen und ermittlungstechnischen Anforderungen entspricht, und die Begründung dokumentieren.
- Logs mit personenbezogenen Daten als personenbezogene Daten behandeln: den Zugang begrenzen und nicht mehr als nötig erfassen.
Aufbewahrung: festlegen, begründen, anwenden
ISO 27001 gibt keine Tageszahl vor. Sie legen die Dauer fest – auf Basis Ihrer Verpflichtungen. In Europa können das gesetzliche Vorgaben oder Kundenverträge sein; prüfen Sie daher Ihre eigenen Vereinbarungen, bevor Sie sich auf eine Frist festlegen. Wenden Sie diese dann konsequent an. Ein Auditor wird Ihre schriftliche Richtlinie mit den tatsächlichen Einstellungen Ihrer Log-Plattform vergleichen, und eine Abweichung ist eine leicht vermeidbare Nichtkonformität.
Maßnahme 8.16: Überwachung, die etwas erkennt
Bei der Überwachung scheitern viele Erstimplementierungen. Die Maßnahme erwartet, dass Sie auf anomales Verhalten achten und potenzielle Vorfälle bewerten. Das erfordert definierte Anwendungsfälle, einen Verantwortlichen und einen Reaktionspfad.
Mit einer kurzen Alarmliste beginnen
Zehn gut abgestimmte Alarme schlagen zweihundert ignorierte. Gute erste Kandidaten:
- Wiederholte fehlgeschlagene Anmeldungen gefolgt von einer erfolgreichen.
- Ein neu zu einer Administratorgruppe hinzugefügtes Konto.
- Anmeldung aus einem ungewöhnlichen Land oder unmögliche Ortswechsel zwischen Standorten.
- Deaktivierung von Endgeräteschutz oder Protokollierungs-Agenten.
- Große ausgehende Datenübertragungen aus einem sensiblen System.
- Zugriff auf Produktivdaten außerhalb normaler Zeiten durch jemanden, der das üblicherweise nicht tut.
Halten Sie für jeden Alarm fest, wer ihn erhält, wie schnell reagiert werden soll und was als Vorfall gilt. Dieser letzte Punkt verbindet die Überwachung mit Ihrem Vorfallsprozess. Unser Leitfaden zu den fünf Vorfallsmaßnahmen, die Auditoren prüfen, zeigt, wie aus einem Alarm ein aufgezeichnetes Ereignis und ein bewerteter Vorfall wird.
Alarme für die Reaktion nutzbar machen
Die Lessons Learned einer CISA-Incident-Response-Untersuchung beschreiben Protokollierung als Test dafür, ob Einsatzkräfte sie nutzen können. Einen Alarm zu erzeugen reicht nicht: Das Team muss vom Alarm aus zu korrelierten Identitäts-, Endgeräte- und Cloud-Datensätzen gelangen, um Ereignisse zu rekonstruieren – hier hilft ein zentrales SIEM. Nutzen Sie diesen Test für Ihr eigenes Programm. Nehmen Sie einen aktuellen Alarm und prüfen Sie, ob jemand innerhalb einer Stunde das beteiligte Konto über Ihren Identity Provider, das betroffene Endgerät und Ihre Cloud-Konsole nachverfolgen könnte.
Für Teams, die eine tiefere Architekturansicht benötigen, beschreibt die CISA Logging Reference Architecture eine Protokollierung, die rechtzeitige Erkennung, Bedrohungssuche, Vorfallsreaktion und Forensik unterstützt – nicht nur Sammlung und Aufbewahrung. Sie ist für Bundesbehörden geschrieben, die Prinzipien lassen sich aber auf privatwirtschaftliche Unternehmen übertragen.
Wenn Sie eigene Anwendungen betreiben, ist Monitoring auf Anwendungsebene ebenfalls relevant. Diese Übersicht zu Best Practices im Application Monitoring ist eine nützliche Ergänzung für Entwickler, die Fehler- und Performance-Monitoring mit Sicherheitsalarmen verbinden müssen.
Unabhängigkeit bei der Prüfung
Die Aufgabentrennung gilt auch für die Überwachung. Das FFIEC IT Examination Handbook, verfasst für Finanzinstitute, stellt fest, dass Mitarbeitende, die Systeme oder die Sicherheit administrieren, nicht dieselben sein sollten, die die Aktivitätslogs dieser Systeme prüfen. ISO 27001 ist keine Bankenvorschrift, aber die Logik gilt für jedes Unternehmen: Wenn der Administrator sowohl handeln als auch prüfen kann, kann Missbrauch unentdeckt bleiben.
Kleine Teams können diese Rollen oft nicht vollständig trennen. Dokumentieren Sie in diesem Fall die kompensierende Maßnahme. Zum Beispiel: Eine zweite Person, eine Führungskraft oder ein externer Dienstleister erhält regelmäßig eine Zusammenfassung privilegierter Aktivitäten. Die FFIEC-Leitlinien zu Managed Security Service Providern beschreiben Event-Log-Management und Alarmierung als auslagerbare Dienstleistung – eine Option für schlanke Teams. Wenn Sie auslagern, denken Sie daran, dass die Maßnahmen des Lieferanten in Ihren Geltungsbereich fallen; lesen Sie dazu unsere Erläuterung zum ISO-27001-Lieferantenmanagement.
Maßnahme 8.17: Die unscheinbare, die Untersuchungen zum Scheitern bringt
Zeitsynchronisation wirkt trivial, bis Sie versuchen, ein Firewall-Log, ein Endgeräte-Log und ein Cloud-Audit-Trail, die um mehrere Minuten voneinander abweichen, in Einklang zu bringen. Richten Sie Systeme auf abgestimmte Zeitquellen aus (üblicherweise NTP), standardisieren Sie eine Zeitzone für Sicherheitslogs (viele Teams wählen UTC) und dokumentieren Sie die Konfiguration. Prüfen Sie auch auf Zeitabweichungen. Auditoren akzeptieren in der Regel einen Screenshot oder Konfigurationsexport aus einer Stichprobe von Systemen.
Nachweise, die ein Auditor einsehen möchte
Legen Sie vor dem Stage-2-Audit einen Ordner – physisch oder digital – mit diesen Unterlagen an:
- Protokollierungs- und Überwachungsrichtlinie oder -standard, von der Geschäftsleitung genehmigt.
- Eine Liste der Log-Quellen im Geltungsbereich mit Verantwortlichen.
- Aufbewahrungseinstellungen, abgeglichen mit der Richtlinie.
- Zugriffsliste für die Log-Plattform mit einer aktuellen Überprüfung.
- Alarmregeln und deren Begründung.
- Prüfnachweise: datierte Prüfaufzeichnungen, Ticket-Exporte oder ein Monitoring-Dashboard-Bericht.
- Mindestens ein Beispiel, bei dem ein Alarm zu einer Untersuchung geführt hat, und deren Ergebnis.
- Zeitsynchronisationskonfiguration für eine Stichprobe von Systemen.
- Management-Review-Protokolle, in denen Überwachungsergebnisse erwähnt werden.
Punkt 7 ist am wichtigsten. Wenn Sie keinen echten Vorfall hatten, führen Sie eine Tischübung oder einen Testalarm durch und dokumentieren Sie ihn. Eine Maßnahme, die noch nie ausgelöst wurde, ist schwer nachzuweisen.
Eine Einführungsreihenfolge, die funktioniert
Wochen 1 bis 2: Entscheiden und dokumentieren
Listen Sie Ihre kritischen Systeme aus dem Asset-Register und der Risikobeurteilung auf. Legen Sie Log-Quellen, Mindestzubegebisse, Aufbewahrung und Prüfende fest. Halten Sie die Richtlinie kurz genug, damit sie tatsächlich gelesen wird.
Wochen 3 bis 6: Sammeln und schützen
Aktivieren Sie die Auditprotokollierung in Ihrem Identity Provider, Cloud-Konten, Endgeräten und wichtigen SaaS-Tools. Leiten Sie sie an einen zentralen Ort weiter. Beschränken Sie den Zugang und korrigieren Sie die Uhrzeiteinstellungen.
Wochen 7 bis 10: Erkennen und reagieren
Erstellen Sie die ersten zehn Alarme, weisen Sie Verantwortliche zu und testen Sie sie. Verbinden Sie sie mit Ihrem Vorfalls-Ticket-Workflow.
Laufend: Überprüfen und verbessern
Planen Sie eine regelmäßige Überprüfung, fließen Sie Erkenntnisse in das Management-Review ein und passen Sie Alarmregeln nach jedem Vorfall oder Beinahe-Vorfall an. Den übergeordneten Zeitplan für diese Arbeit finden Sie in unserer ISO-27001-Implementierungszeitplanung. Die obige Reihenfolge ist ein Planungsbeispiel, keine feste Vorgabe. Ihr eigenes Tempo hängt von Werkzeugen, Personal und dem Reifegrad ab, mit dem Sie starten.
Branchenhinweise: Finanzen und Zahlungsdaten
Finanzunternehmen stehen unter erhöhten Erwartungen, weil Regulatoren und Prüfer Logs als Kontrollnachweis lesen. Wenn Sie zusätzlich Kartendaten verarbeiten, hat PCI DSS eigene Protokollierungsanforderungen, und häufig kann eine einzige Infrastruktur beiden Programmen dienen. Unser Artikel zur Gegenüberstellung von PCI DSS v4.0.1 und ISO 27001 zeigt, wie doppelter Auditaufwand vermieden werden kann. Für Datenpannensszenarien zeigen der Datenpannen-Reaktionsleitfaden für den Finanzsektor und der Leitfaden zur Vorfallsreaktion im Bankwesen, wo Logs in die Reaktion einfließen.
Häufige Fehler
- Alles protokollieren, nichts auswerten. Volumen ist keine Maßnahme. Begrenzen Sie den Umfang auf das, was tatsächlich geprüft werden kann.
- Logs auf demselben Host aufbewahren. Ein Angreifer mit Administratorrechten kann sie löschen.
- Keine schriftliche Aufbewahrungsregelung. Einstellungen, die von der Richtlinie abweichen, sind ein leicht vermeidbarer Befund.
- Kein namentlicher Alarmverantwortlicher. Ein Alarm, der an einen gemeinsamen Posteingang gesendet wird, ist oft ein Alarm, den niemand liest.
- Das SIEM als die Maßnahme betrachten. Das Werkzeug unterstützt die Maßnahme. Der Prozess des Prüfens und Reagierens ist die Maßnahme.
- SaaS und Cloud ignorieren. Viele Vorfälle beginnen in einem Identity Provider oder einer Cloud-Konsole, nicht auf einem Server.
Wenn Sie ein Muster suchen, wie ein Anbieter seine eigenen Sicherheitspraktiken dokumentiert, zeigt eine Seite wie WorldEyes Sicherheitsübersicht, wie ein Dienst seine Schutzmaßnahmen öffentlich darstellen kann. Nutzen Sie solche Seiten als Anregung dafür, was Ihre eigenen Kunden möglicherweise zu Ihrer Log-Handhabung fragen werden.
Unsere Einschätzung
Wir erstellen Kosten- und Aufwandsschätzungen für ISO-27001-Projekte, und Protokollierung und Überwachung ist die Position, die die meisten überrascht. Die Lizenz für eine Log-Plattform ist selten der große Kostenfaktor. Die Zeit ist es: Alarme abstimmen, die Prüfroutine ausarbeiten und jemanden, der es Monat für Monat verantwortet. Teams, die nur für das Werkzeug budgetieren, haben am Ende einen teuren Speicher ungelesener Logs.
Unser Rat: Bemessen Sie diese Maßnahme zuerst nach Personenstunden. Fragen Sie, wie viele Systeme Sie anbinden, wie viele Alarme jemand realistisch pro Woche bearbeiten kann, und ob Sie einen externen Anbieter für Nacht- und Wochenenddienst benötigen. Vergleichen Sie Ihre Zahlen dann mit Referenzwerten, um zu erkennen, ob Sie zu knapp oder zu großzügig planen. Ein erstmals implementierendes Team in einer regulierten Branche sollte hier mit mehr Aufwand rechnen als ein zehnköpfiges Software-Startup, weil die Beweisanforderungen und die Systemanzahl höher sind.
Wir glauben auch, dass Auditoren Ehrlichkeit belohnen. Ein kleines, funktionierendes Set von Alarmen mit datierten Prüfaufzeichnungen schlägt ein ambitioniertes Design, das nur in einer Präsentation existiert.
— Martin
Aufwand schätzen, bevor Sie sich festlegen
Wenn Sie ein Audit planen und sehen möchten, wie Protokollierung, Überwachung und die anderen Annex-A-Maßnahmen Kosten und Zeitplan beeinflussen, nutzen Sie den ISO-27001-Kostenkalkulator. Er liefert Schätzungen nach Unternehmensgröße, Branche und Sicherheitsreife, und Sie können starten, ohne sich anzumelden. Nicht sicher, wo Sie stehen? Der kostenlose 2-Minuten-Bereitschaftscheck gibt einen ersten Überblick, und das vollständige Bereitschafts-Assessment geht Bereich für Bereich vor. Wenn Sie Ihren Gesamtplan erstellen, hilft die 80-Schritte-Zertifizierungscheckliste, Protokollierungsaufgaben in den Gesamtplan einzuordnen.
FAQ
Ist Protokollierung für die ISO-27001-Zertifizierung verpflichtend?
In der Praxis ja. Annex-A-Maßnahme 8.15 behandelt die Protokollierung, und wenn Sie sie in Ihrer Erklärung zur Anwendbarkeit ausschließen, benötigen Sie eine stichhaltige Begründung – die für jede Organisation mit IT-Systemen schwer zu liefern ist. Auditoren erwarten Logs für die Systeme in Ihrem Geltungsbereich.
Was ist der Unterschied zwischen Maßnahme 8.15 und 8.16?
Maßnahme 8.15 betrifft das Erstellen, Schützen und Auswerten von Logs. Maßnahme 8.16 betrifft die Überwachung von Netzwerken, Systemen und Anwendungen auf anomales Verhalten und die entsprechende Reaktion. Sie brauchen beides: Die erste liefert die Aufzeichnung, die zweite liefert die Erkennung.
Brauche ich ein SIEM, um ISO 27001 zu erfüllen?
Der Standard nennt kein konkretes Werkzeug. Ein SIEM oder ein Managed Detection Service erleichtern Korrelation und Prüfung erheblich, und die CISA-Leitlinien bezeichnen zentrale Korrelation als hilfreich für die Reaktion. Kleinere Unternehmen können die Maßnahmen auch mit zentralisierten Logs, einigen zuverlässigen Alarmen und dokumentierten Prüfungen erfüllen.
Wie lange sollte ich Logs aufbewahren?
ISO 27001 legt keine feste Frist fest. Wählen Sie eine Aufbewahrungsdauer auf Basis gesetzlicher Pflichten, Kundenverträge und der Zeit, die Sie für Vorfallsuntersuchungen benötigen, halten Sie diese in Ihrer Richtlinie fest und stimmen Sie die Plattformeinstellungen darauf ab.
Kann eine Protokollierungsinfrastruktur sowohl ISO 27001 als auch PCI DSS erfüllen?
Oft ja, wenn sie von Anfang an mit Blick auf beide Standards gestaltet wird, da beide protokollierte und geprüfte Aktivitäten verlangen. Stellen Sie die Anforderungen nebeneinander auf und bestätigen Sie die Details mit Ihrem Assessor. Unser Artikel zur Gegenüberstellung von PCI DSS und ISO 27001 erklärt den Ansatz.
Quellen
- CISA: Lessons Learned aus einer Incident-Response-Untersuchung
- CISA: Logging Reference Architecture
- FFIEC IT Handbook: Computer- und Netzwerkbetrieb zur Unterstützung des Zahlungsverkehrs
- FFIEC IT Handbook: Managed Security Service Provider