Konformität dauerhaft nachweisen, nicht nur einmal

Ein Techniker aktiviert MFA für das Microsoft-365-Konto eines Kunden, macht einen Screenshot und legt ihn in der Nachweismappe ab. Acht Monate später verlangt der Cyberversicherer des Kunden — oder sein ISO-27001-Auditor — den Nachweis, dass MFA seit der letzten Verlängerung durchgehend aktiv war. Der Screenshot belegt das nicht. Er belegt nur, dass die Einstellung in dem Moment aktiviert war, in dem er entstand.

Das ist die häufigste Lücke zwischen dem, was ein Techniker einen Nachweis nennt, und dem, was ein Auditor einen Nachweis nennt — und sie wird genau in dem Moment teuer, in dem man sie entdeckt: während des Audits.

Was nennt ein Auditor einen Nachweis?#

Eine datierte, über die Zeit wiederholte Beobachtung, die zeigt, dass eine Maßnahme über den gesamten betrachteten Zeitraum gehalten hat — keine punktuelle Erklärung, die zeigt, dass sie zu einem bestimmten Zeitpunkt funktionierte. Die Norm ISO/IEC 27001:2022 hält das in Abschnitt 9.1 fest: Die Organisation muss die Wirksamkeit ihrer Maßnahmen überwachen und messen und dokumentierte Informationen als Nachweis der Ergebnisse aufbewahren — nicht als Nachweis dafür, dass ein Techniker die Einstellung irgendwann einmal geprüft hat.

Für einen Techniker beantwortet der Nachweis die Frage „ist es aktiviert“. Für einen Auditor beantwortet er die Frage „war es während des gesamten Prüfzeitraums aktiviert, und woher wissen Sie das, ohne es jeden Tag nachgesehen zu haben“.

Der Berufsstand der Prüfer trennt diese beiden Fragen seit Langem, und das Vokabular ist auch dann nützlich, wenn Sie nie eine Zertifizierung durchlaufen. Auf der einen Seite steht der Nachweis der Ausgestaltung: Die Maßnahme existiert, sie ist so konfiguriert, wie es die Richtlinie vorsieht, jemand kann sie am Bildschirm zeigen. Auf der anderen Seite steht der Nachweis der operativen Wirksamkeit: Die Maßnahme hat die erwartete Wirkung entfaltet, ohne unerklärte Unterbrechung, über den gesamten Prüfzeitraum hinweg. Ein Screenshot beantwortet die erste Frage und lässt die zweite vollständig offen. Genau das ist der Unterschied zwischen einer Bestätigung, die sich auf einen Zeitpunkt bezieht, und einer, die sich auf einen Zeitraum bezieht — und es ist die zweite, nach der ein Versicherer oder ein regulierter Kunde am Ende immer fragt.

Warum reicht eine punktuelle Bestätigung nie aus?#

Weil sie nichts darüber sagt, was vor oder nach dem Tag ihrer Ausstellung geschehen ist. Ein ISO-27001-Zertifizierungsaudit oder eine Prüfung durch eine Aufsichtsbehörde bezieht sich auf einen Zeitraum — in der Regel das vergangene Jahr — und nicht auf den Zeitpunkt des Audits. Eine einzelne Bestätigung, so aufrichtig sie im Moment der Unterschrift auch sein mag, deckt buchstäblich einen einzigen von dreihundertfünfundsechzig Tagen ab.

Das Risiko ist dabei nicht einmal Unehrlichkeit. Es ist, dass eine kurz vor dem Audit eingeholte Bestätigung genau den unrepräsentativsten Zeitraum des Jahres beschreibt: den, in dem gerade alle geprüft und nachgebessert haben, was nicht in Ordnung war.

Es gibt einen noch handfesteren Grund, und er überrascht viele Dienstleister beim ersten Mal. Ein Auditor liest den gesamten Zeitraum nicht durch: Er zieht Stichproben. Er wählt Stichtage innerhalb des Prüfzeitraums — oft ohne Ihnen vorher zu sagen, welche — und verlangt den Nachweis über den Zustand der Maßnahme an genau diesen Tagen. Enthält Ihre Mappe nur einen Screenshot vom Vortag des Audits, ist jeder gezogene Stichtag eine Lücke. Sie können sie nachträglich nicht schließen: Eine Verwaltungskonsole zeigt den Zustand von heute, nicht den vom 14. März. Der Messwert vom 14. März existierte an jenem Tag, oder er existiert nicht.

Wie gerät eine Sicherheitseinstellung aus dem Tritt, ohne dass es jemand absichtlich tut?#

Durch den normalen Betrieb des Systems, nicht durch ein Verschulden. Ein Benutzer sperrt sich aus seinem Konto aus, ein Techniker deaktiviert an einem Freitagabend vorübergehend das MFA, um ihn zu entsperren, und am Montag denkt niemand daran, es wieder einzuschalten. Ein Update der Verwaltungskonsole setzt eine Gruppenrichtlinie auf ihren Standardwert zurück. Ein neues Gerät kommt in den Bestand, bevor die Konformitätsrichtlinie darauf angewendet wird. Eine Sicherheitsregel adressiert eine Benutzergruppe, deren Zusammensetzung sich mit Einstellungen und Abgängen verändert, ohne dass jemand den Geltungsbereich nachzieht.

Jedes dieser Ereignisse ist für sich genommen harmlos. Über zwölf Monate summiert, über Dutzende Konten und mehrere Werkzeuge hinweg, ergeben sie genau das, was ein Auditor fürchtet: eine Maßnahme, die an dem Tag zutraf, an dem sie geprüft wurde, und die seit drei Monaten nicht mehr zutrifft, ohne dass es jemand bemerkt hätte.

Teuer werden diese Abweichungen nicht durch ihre Schwere, sondern durch ihre Unauffälligkeit. Keine von ihnen löst einen Alarm aus, weil keine von ihnen eine Störung ist: Das System arbeitet exakt so, wie man es konfiguriert hat. Nebeneinandergestellt haben sie alle dieselbe Signatur.

Nur die rechte Spalte beantwortet die Frage des Auditors. Die drei anderen beschreiben den Zustand von heute — nützlich für den Betrieb, wertlos für den Nachweis.

Was muss ein Nachweis mitbringen, um einem Audit standzuhalten?#

Fünf Eigenschaften, und keine davon ist optional: Fehlt eine, fällt die Mappe bei der nächsten Rückfrage in sich zusammen. Die Regel, die alle fünf zusammenfasst, passt in einen Satz — ein fehlender Messwert ist ein fehlender Nachweis, kein Nachweis zu Ihren Gunsten.

Ein undatierter Nachweis beweist über einen Zeitraum nichts. Ein Nachweis, den der nächste überschreibt — ein Dashboard, das nur den letzten Messwert anzeigt —, verliert die Spur des Moments, in dem die Maßnahme aufgehört hat zu greifen. Und ein Tag ohne Messung darf nie standardmäßig als konformer Tag zählen, denn der erste Auditor, dem das auffällt, wird den gesamten Rest der Mappe infrage stellen — auch die Teile, die korrekt waren.

Wie sieht ein Nachweis-Messwert konkret aus?#

Wie eine Zeile pro Messung, nicht wie ein Dokument. Hier die Mindestform einer belastbaren Reihe für eine einzige Maßnahme — die Durchsetzung von MFA auf den Microsoft-365-Konten eines Kunden — über eine Handvoll Tage.

Sechs Zeilen, und die ganze Geschichte ist bereits lesbar. Am 14. März ist ein Konto aus dem Geltungsbereich des MFA herausgefallen. Am 15. lief die Erhebung nicht — und die Zeile sagt das, statt stillschweigend den Wert des Vortags fortzuschreiben. Am 16. wurde ein Konto angelegt, was erklärt, warum der Nenner von 52 auf 53 steigt und die Abdeckung weiter fällt, obwohl kein zusätzliches Konto ausgenommen wurde. Am 17. ist die Abweichung behoben.

Ein Screenshot vom 17. März hätte 100 % gezeigt und wäre vollkommen aufrichtig gewesen. Er hätte auch die drei vorangegangenen Tage getilgt, darunter den, an dem die Erhebung nicht lief — den einzigen Punkt der Mappe, den ein gewissenhafter Auditor Sie erklären lassen wird.

Was macht ein Auditor mit einer Reihe datierter Messwerte?#

Drei Dinge, in dieser Reihenfolge, und man ist gut beraten, sie vorwegzunehmen. Zuerst prüft er den Nenner: Woher kommt die Zahl 52, wie ist der Geltungsbereich gebildet, und was passiert mit einem Endgerät, das in keinem Inventar steht. Eine Konformitätsquote, berechnet auf einer Grundgesamtheit, die Sie selbst festlegen, hat keine Beweiskraft — und das ist das Erste, was ein erfahrener Auditor testet.

Dann zieht er Stichproben. Er greift sich zwei oder drei Stichtage aus dem Zeitraum heraus und bittet Sie, den Zustand, den Ihr Messwert behauptet, an der Quelle wiederzufinden. Wenn die Zeile vom 14. März 51 von 52 ausweist, will er wissen, welches Konto fehlte und warum. Eine Messreihe, die kein Absteigen ins Detail erlaubt, übersteht diesen Schritt nicht.

Zuletzt sieht er sich die Lücken und die Einbrüche an — und hier liegt die Intuition vieler Dienstleister genau verkehrt herum. Eine Kurve, die dreihundertfünfundsechzig Tage lang auf 100 % steht, ohne eine einzige Delle, schafft kein Vertrauen: Sie legt nahe, dass die Messung nicht viel misst. Eine Reihe, die am 14. März einen Einbruch zeigt, seine Ursache und seine Behebung am 17., beschreibt ein funktionierendes Kontrollsystem. Die Norm ISO/IEC 27001 sieht diesen Fall in Abschnitt 10.2 ausdrücklich vor: Eine festgestellte Nichtkonformität muss behandelt, ihre Ursachen müssen untersucht und die Korrekturmaßnahme als dokumentierte Information aufbewahrt werden. Eine dokumentierte und behobene Abweichung ist ein Konformitätsbeleg, kein Geständnis.

Das Problem ist nie die Abweichung. Das Problem ist die Abweichung, die während des Audits entdeckt wird, weil niemand gemessen hat.

Welche Maßnahmen lassen sich automatisch erheben, und welche nie?#

Nur ein Teil, und man sollte das offen sagen, statt den Eindruck zu erwecken, ein Werkzeug ersetze Governance. Maßnahmen, deren Zustand in einer abfragbaren Konsole lebt, lassen sich laufend erheben; solche, die auf einer menschlichen Handlung oder einem Dokument beruhen, werden anders nachgewiesen, und es gibt für sie keine ehrliche Automatisierung.

Die rechte Spalte ist kein Notbehelf: Sie ist dieselbe Anforderung, angewendet auf Nachweise anderer Art. Ein undatierter Bericht über eine Zugriffsüberprüfung hat exakt denselben Mangel wie ein undatierter Screenshot einer Konsole.

Was sollten Sie laufend erheben, statt es zum Audit zu rekonstruieren?#

Regelmäßige technische Messwerte zu jeder automatisch prüfbaren Maßnahme — MFA erzwungen, Sicherung erfolgreich durchgelaufen, Endpoint-Schutzagent vorhanden, Patches aktuell — einzeln aufbewahrt statt zu einer einzigen Kennzahl aggregiert, die die Historie überschreibt. Der praktische Unterschied ist einfach zu formulieren: Statt einmal im Jahr „ja, MFA ist aktiv“ zu antworten, können Sie antworten „MFA war an 91 der letzten 92 Tage auf mindestens 95 % der Endgeräte erzwungen“ — mit dem Datum des Tages, an dem es abgerissen ist, und dem, was an diesem Tag geschehen ist.

Die zweite Antwort ist überprüfbar. Die erste ist es nicht — sie verlangt vom Auditor, Ihnen aufs Wort zu glauben, was weder seine Aufgabe ist noch Ihre, es von ihm zu verlangen.

Dieselbe Überlegung gilt für Entscheidungen, nicht nur für Messungen. Ein Konformitätsregister, das ausschließlich seinen aktuellen Stand anzeigt, hat den Mangel des Dashboards: Es sagt nicht, wann ein Eintrag von „nicht konform“ auf „konform“ gewechselt ist. Eine Historie, die den alten Status, den neuen Status und das Datum des Wechsels bewahrt, beantwortet eine Frage, die ein Auditor immer stellt — seit wann ist diese Abweichung offen, und was ist in der Zwischenzeit geschehen.

Wie lange müssen diese Messwerte aufbewahrt werden?#

Mindestens über den Zeitraum, den das Audit abdeckt, und in der Praxis länger. Der Prüfzeitraum eines ISO-27001-Audits ist in der Regel das vergangene Jahr, aber die Dauer eines Zertifizierungszyklus und der genaue Inhalt der Überwachungsaudits hängen vom Schema ab, das die Zertifizierungsstelle anwendet: Nach dem abzudeckenden Zeitraum fragt man dort, nicht in einem Blogartikel. Auf der Versicherungsseite stellt sich die Frage bei jeder Verlängerung, also jährlich, für die vorangegangenen zwölf Monate.

Die praktische Regel, die vor Fehlern schützt: Bewahren Sie einen vollständigen Zeitraum mehr auf, als heute von Ihnen verlangt wird. Eine Mappe, die genau an dem Tag beginnt, an dem das Audit beginnt, erweckt — oft zu Unrecht — den Eindruck, eigens für den Anlass zusammengestellt worden zu sein. Und bewahren Sie die Messwerte in der Form auf, in der sie entstanden sind, mit ihrem ursprünglichen Zeitstempel: Ein Export, der zum Audit nachbearbeitet, neu berechnet oder umformatiert wird, verliert genau die Eigenschaft, die ihn zum Nachweis machte.

Das ist das Prinzip hinter dem Modul für kontinuierliche Drift-Erkennung von Vigicap: Jeder Messwert eines Konnektors wird aufbewahrt und nie überschrieben, sodass sich eine datierte Abdeckung wie die oben zitierte darstellen lässt statt eines isolierten Screenshots. Das Konformitätsregister folgt derselben Regel: Jeder Statuswechsel eines Ziels bewahrt den alten Status, den neuen und dessen Datum, statt den vorherigen Wert zu ersetzen.