Eine Incident-Meldung ist die Übersicht, die Sie führen über das, was passiert ist, wann, in welchem System und wer beteiligt war, vom Moment, in dem Sie etwas Ungewöhnliches feststellen, bis zur Behebung. Für einen ICT-Dienstleister bedeutet dies konkret: der Zeitpunkt der ersten Meldung, welche Systeme des Kunden betroffen sind, welcher Mitarbeiter oder Subunternehmer zu diesem Zeitpunkt Zugriff hatte, welche Schritte unternommen wurden und wann die Situation wieder normal war.
Diese Dokumentation ist keine gesetzliche Meldepflicht an sich — diese gilt für Organisationen, die selbst unter das Gesetz zur Cybersicherheit fallen, nicht automatisch für ihre Lieferanten. Aber ein Kunde, der selbst verpflichtet ist, muss seine eigene Lieferkette beurteilen können, und das tut er, indem er Sie fragt, wie Sie Incidents dokumentieren und nachweisbar machen. Ohne eine geordnete Antwort auf diese Frage kommt ein Vertrag oft nicht über die Auftragsannahme hinaus.
Warum dies gerade bei ICT-Dienstleistern eine Rolle spielt
Ein Installationsbetrieb oder ein Beratungsbüro hat normalerweise eine Umgebung zu überwachen: die eigene. Ein ICT-Dienstleister arbeitet strukturell in den Systemen anderer, oft von außen, manchmal mit Administratorrechten, die sehr weitreichend sind. Wenn dort etwas schiefgeht, ist die Frage nicht nur, was bei Ihnen passiert ist, sondern auch, was beim Kunden betroffen ist und ob das auf eine Sitzung, ein Konto oder einen Zugriffszeitpunkt zurückzuführen ist. Kunden, die selbst unter die Sorgfaltspflicht fallen, erwarten, dass Sie diese Rückverfolgbarkeit nachweisen können, auch wenn der Incident Monate zurückliegt.
Fernverwaltung: Was Sie dokumentieren
Bei der Fernverwaltung geht es um drei Dinge, die separat ermittelt werden müssen: wer die Sitzung gestartet hat, von welchem Konto oder welchem Arbeitsplatz aus, und was in dieser Sitzung getan wurde. Viele Remote-Verwaltungstools dokumentieren dies automatisch, aber die entscheidende Frage ist nicht, ob das Tool es dokumentiert, sondern ob Sie diese Dokumentation vorweisen können, wenn ein Kunde oder eine Aufsichtsbehörde danach fragt. Eine separate Liste zu führen, welche Kundenumgebungen von außen zugänglich sind und durch wen, ist oft schon ausreichend, um diese Frage zu beantworten, ohne in die Technik gehen zu müssen.
Zugriff auf Kundensysteme: erteilt, genutzt, widerrufen
Zugriff auf ein Kundensystem ist normalerweise kein Dauerzustand, sondern ein Moment: jemand erhält ein Konto, nutzt es für eine Aufgabe, und der Zugriff wird wieder entzogen. Bei einem Incident ist die erste Frage oft, wer zu diesem Zeitpunkt Zugriff hàtte, nicht, wer jemals Zugriff hatte. Ein Register, in dem verzeichnet ist, wann Zugriff erteilt wurde und wann dieser wieder entzogen wurde, macht es möglich, diese Frage schnell und konkret zu beantworten. Fehlt diese Übersicht, müssen Sie diese später rekonstruieren, wenn es bereits eilig ist, und genau das ist der Moment, in dem es am schwierigsten ist.
Unterauftragnehmer: Die Lieferkette endet nicht bei Ihnen
Arbeiten Sie selbst mit einem Subunternehmer für einen Teil der Verwaltung zusammen, verschiebt sich die Frage nicht, sie verlängert sich. Ein Kunde, der Ihre Arbeit beurteilt, möchte wissen, ob ein Incident, das bei Ihrem Subunternehmer entsteht, auch bei Ihnen sichtbar wird, und nicht erst später durch einen Anruf. Praktisch bedeutet dies, dass Vereinbarungen mit Subunternehmern etwas über gegenseitige Meldungsfristen aussagen, und dass Ihre eigene Incident-Dokumentation Platz lässt, um anzugeben, welcher Teil eines Incidents bei einer dritten Partei lag. pro Thema geklärt, was für Ihre Situation relevant ist bietet einen guten Ausgangspunkt, um zu sehen, welche Ketenfragen zu Ihrer Art von Dienstverleisung gehören.
Was eine Dokumentation ist und was nicht
Eine Incident-Dokumentation ist eine Aufzeichnung, keine Reaktion. Es geht darum, was Sie nachweisen können, nachdem etwas gelöst wurde, nicht darum, wie schnell Sie reagieren oder welche technischen Maßnahmen Sie während eines Incidents einsetzen — letzteres ist die Aufgabe von Incident-Response-Teams, SOCs und forensischen Ermittlern, und das ist ausdrücklich nicht Gegenstand dieses Artikels oder von secria.eu. Was wir tun, ist die Übersicht zu klären: welche Maßnahme gehört zu welchem Nachweis, und wer in Ihrer Organisation ist dafür verantwortlich. Antworten auf Fragen, die KMU-Lieferanten häufig stellen zeigt, wo die Grenze zwischen Dokumentation und tatsächlicher Reaktion liegt.
Wo Sie dies ansiedeln
Ob Sie selbst unter das Cybersecurity-Gesetz fallen oder über einen Kunden betroffen sind, die Frage zur Incident-Dokumentation kommt bei nahezu jedem Security-Fragebogen vor. Eine geordnete Antwort beginnt damit, genau zu wissen, wo Sie stehen: in wenigen Fragen sehen, ob und wie Sie betroffen sind macht das in wenigen Minuten deutlich, ohne dass Sie dafür ein Konto benötigen.
Möchten Sie erfahren, wie so eine Dokumentation in der Praxis zu einer lebenden Akte wird, mit Status, Nachweis und Verantwortlichem pro Maßnahme? Führen Sie die kostenlose NIS2-Überprüfung durch oder lesen Sie die Wissensdatenbank auf secria.eu; beide sind ohne Konto einsehbar.