Protokollierung, die Kontrolle, die leise stirbt.
ISO 27001:2022 A.8.15 (Protokollierung) verlangt, dass sicherheitsrelevante Ereignisse (Logins, Fehler, Störungen, Zugriff auf sensible Daten) aufgezeichnet, für einen definierten Zeitraum gespeichert und vor Manipulationen geschützt werden. Sie ist tragend für A.8.16 (Überwachung) und für spätere Untersuchungen: Was nie aufgezeichnet wurde, kann nicht erkannt oder rekonstruiert werden. Und sie lässt sich leicht schwächen, ohne dass es auffällt, denn eine Protokollzeile ist genau die Art von Zeile, die bei der Bereinigung entfernt wird.
The shapes the same control failure takes.
A.8.15 bricht selten durch eine dramatische Änderung. Es bricht, wenn ein sicherheitsrelevantes Ereignis nicht mehr aufgezeichnet wird. Die wiederkehrenden Muster:
Ein Sicherheitsprotokoll wird entfernt
Ein Protokollaufruf für ein Authentifizierungsereignis, eine Berechtigungsänderung oder den Zugriff auf sensible Daten wird bei einer Bereinigung gelöscht, weil er als störend empfunden wurde.
Die Protokollstufe fällt unter das Produktionslevel
Ein sicherheitsrelevantes Ereignis wird auf eine Stufe (Debug) verschoben, die in der Produktion nicht ausgegeben wird, sodass es an der entscheidenden Stelle stillschweigend nicht mehr aufgezeichnet wird.
Der Akteur wird aus dem Protokoll entfernt
Ein Protokoll wird weiterhin ausgelöst, enthält aber nicht mehr, wer die Aktion durchgeführt hat, sodass das Ereignis bei einer Untersuchung nicht mehr zuordenbar ist.
Eine neue privilegierte Aktion wird ohne Protokollierung bereitgestellt
Eine neue Admin- oder zerstörerische Operation wird ohne Protokollaufzeichnung hinzugefügt, sodass später keine Stichprobe möglich ist.
Die Aufbewahrungsfrist wird verkürzt
Die Aufbewahrungsdauer oder Rotation eines Protokolls wird unter das von der Kontrolle geforderte Maß reduziert, sodass die Aufzeichnung verschwunden ist, bevor sie benötigt wird.
Authentifizierungsfehler fallen unter das Produktions-Protokolllevel.
Authentifizierungsfehler-Protokolle sind in der Entwicklung lästig, daher wird in einer Änderung die Stufe von Warnung auf Debug verschoben. In der Produktion ist das Protokolllevel auf Info eingestellt, sodass diese Fehler nun vollständig aus den Aufzeichnungen verschwinden - genau die Ereignisse, die man bei der Untersuchung eines Einbruchs am dringendsten benötigt.
if (!valid) {- logger.warn("auth.failed", { userId, ip })+ logger.debug("auth.failed", { userId, ip }) return unauthorized()}Bei einem Produktionslevel von Info bedeutet die Verschiebung von Authentifizierungsfehlern auf Debug, dass sie in der Produktion nicht mehr aufgezeichnet werden. A.8.15 verlangt, dass sicherheitsrelevante Ereignisse, einschließlich fehlgeschlagener Authentifizierungen, protokolliert und aufbewahrt werden, und A.8.16 (Überwachung) ist darauf angewiesen. Behalten Sie sie auf Warnstufe oder leiten Sie sie an das Sicherheitsprotokoll weiter, anstatt sie in der Produktion zu unterdrücken.
Protokollierung wird anhand realer Ereignisse geprüft.
Ein Prüfer überprüft, ob sicherheitsrelevante Ereignisse tatsächlich protokolliert, für den in Ihrer Richtlinie festgelegten Zeitraum aufbewahrt und vor Manipulationen geschützt werden. Dabei wird er bestimmte Ereignistypen (Logins, Berechtigungsänderungen, Zugriff auf sensible Daten) stichprobenartig prüfen. Eine Änderung, die stillschweigend die Aufzeichnung eines dieser Ereignisse stoppt - sei es durch Löschung oder durch Verschiebung unter das Produktionslevel -, ist die Lücke, die er findet. Die Änderung, die dies verursacht hat, war in der Regel ein ganz normaler Pull Request, der wie eine Lärmreduzierung aussah.
Eine Überprüfung, nicht Ihr SIEM.
heygrc markiert Änderungen, die A.8.15 betreffen, und verweist auf die Kontrolle, sodass die Korrektur im Pull Request erfolgt. Es führt nicht Ihre Protokollierungspipeline oder Ihr Monitoring aus. Es erkennt den Moment, in dem ein sicherheitsrelevantes Ereignis nicht mehr aufgezeichnet wird - direkt im Diff.