Eine der praktischsten NIS2-Fragen lautet: Was genau sollten wir loggen? Viele Organisationen beantworten sie auf zwei schwache Arten. Entweder sammeln sie fast alles ohne klare Prioritäten, oder sie lassen Logging in lokalen Defaults laufen und hoffen, dass es bei Audit oder Vorfall schon reichen wird. Beides funktioniert schlecht.
Das Ziel ist nicht, möglichst viele Daten zu erzeugen. Das Ziel ist, nützliche Nachweise aus den Systemen zu behalten, die für Audit-Nachvollziehbarkeit, Vorfall-Timelines und verteidigbare Entscheidungen am wichtigsten sind. Deshalb ist Priorisierung wichtiger als Volumen.
Dieser Inhalt stellt keine Rechtsberatung und keine abschließende Pflichtliste dar. Er dient als praktischer Rahmen für ein sinnvolles Logging-Minimum in KMU- und Mittelstandsumgebungen.
Für wen diese Seite gedacht ist
Diese Seite richtet sich an:
- IT-Leitungen und Infrastrukturverantwortliche,
- externe Administratoren und MSPs,
- Geschäftsleitungen, die die Priorität von Logs verstehen müssen,
- Sicherheitsverantwortliche, die ein Mindestniveau für Audit und Vorfallsbereitschaft aufbauen.
Was Sie mitnehmen sollten
Nach dem Lesen sollten Sie klarer sehen:
- warum priorisiertes Logging wertvoller ist als wahlloses Sammeln,
- welche Infrastruktur-Layer für Audits und Vorfälle meist zuerst zählen,
- wie sich Mindestschicht und erweiterte Abdeckung unterscheiden,
- wie Priorisierung bei knappem Budget und knapper Kapazität gelingt,
- warum kritische Nachweise außerhalb der Quellsysteme liegen müssen.
Warum "alles sammeln" nicht die Lösung ist
Wenn Organisationen Logs ohne Priorisierung sammeln, treten meist drei Probleme auf:
- sie verlieren in der Datenmenge den Überblick,
- sie verbrauchen Budget für Daten mit geringer Evidenzkraft,
- ihnen fehlen trotzdem die Nachweise, die für Identität, privilegierte Änderungen oder Fernzugriffe wirklich zählen.
Für KMU und mittelständische Organisationen ist es meist wirksamer, mit einer einfachen Frage zu beginnen: Welche Systeme und Ereignisse werden im Audit, im Incident oder in einer internen Untersuchung am wichtigsten sein?
Wie Sie über kritische Systeme nachdenken sollten
Die wichtigsten Systeme sind nicht immer die lautesten. Priorität haben meist Systeme, die über folgende Fragen Auskunft geben:
- Wer hat was getan?
- Wer hatte oder erhielt privilegierten Zugriff?
- Woher kam Remote-Zugriff?
- Was geschah unmittelbar vor Ausfall oder verdächtiger Aktivität?
- Welche Systeme helfen, eine Incident-Hypothese zu bestätigen oder zu widerlegen?
In der Praxis hilft ein Zwei-Schichten-Modell:
- eine Mindestschicht, ohne die Audit- und Incident-Bild schwach bleiben,
- eine erweiterte Schicht, die mehr Kontext und analytischen Mehrwert liefert.
Wenn eine Quelle keine dieser Kernfragen unterstützt, gehört sie oft eher in Phase zwei als in die erste Logging-Welle.
Mindestschicht: Identität und Active Directory
Wenn Ihre Organisation Active Directory oder eine andere zentrale Identitätsplattform nutzt, ist das fast immer Priorität eins. Identitätsdaten bilden oft das Rückgrat der Beweisspur.
Wichtige Nachweise sind typischerweise:
- erfolgreiche und fehlgeschlagene Anmeldungen,
- Passwortänderungen und Resets,
- Erstellung und Löschung von Konten,
- Gruppen- und Rechteänderungen,
- Änderungen an Administrationskonten,
- MFA- und Conditional-Access-Ereignisse, soweit vorhanden.
Warum das wichtig ist:
- Identität zeigt, wer was getan hat,
- viele Angriffswege laufen über Identitätsmissbrauch,
- ohne Identitätsdaten sind Rechteeskalation und administrative Änderungen deutlich schwerer rekonstruierbar.
Mindestschicht: Windows-Server und ausgewählte Endpunkte
Nicht jeder Endpunkt muss sofort Teil der ersten Welle sein. Bestimmte Systeme aber meist schon:
- Domain Controller,
- Jump Hosts,
- Administrationsarbeitsplätze,
- zentrale Applikationsserver,
- Server mit sensiblen Daten oder kritischen Diensten.
Wichtige Nachweise sind oft:
- Anmeldungen,
- privilegierte Aktionen,
- Änderungen an Diensten und Scheduled Tasks,
- Deaktivierung von Sicherheitskontrollen,
- Systemereignisse im Zusammenhang mit Anomalien.
Gerade aus diesen Quellen entsteht häufig die Incident-Timeline.
Mindestschicht: Firewalls, VPN und Netzwerkgeräte
Die Netzwerkschicht ist essenziell, weil sie zeigt:
- woher Zugriffe kamen,
- welche Remote-Verbindungen existierten,
- wie administrative Zugriffe durchgeführt wurden,
- ob Kommunikationsmuster ungewöhnlich waren,
- wann Regeln oder Konfigurationen verändert wurden.
Typische Prioritätsquellen sind:
- Firewalls,
- VPN-Gateways,
- Reverse Proxies und Edge-Gateways,
- ausgewählte Switches und Router,
- Segmentierungskontrollen rund um kritische Systeme.
Ohne diese Schicht wird es deutlich schwerer, Ausbreitung, Angriffsweg und Umfang eines Vorfalls zu verstehen. Gerade bei Vorfällen mit Fernzugriff oder missbrauchten Administrationskonten entscheidet die Netzwerksicht oft darüber, ob die Organisation nur Symptome sieht oder den tatsächlichen Ablauf nachvollziehen kann.
Mindestschicht: Hypervisor, NAS und Infrastruktur-Appliances
Virtualisierung, Storage und Infrastruktur-Appliances werden in vielen Umgebungen zu spät oder gar nicht geloggt. Dabei enthalten sie oft hochrelevante Spuren.
Nützlich sind insbesondere:
- Admin-Logins,
- Konfigurationsänderungen,
- Erstellen, Löschen und Verschieben virtueller Maschinen,
- Snapshot- und Datastore-Aktivität,
- Sicherheits- und Systemereignisse der Appliances selbst.
Das ist besonders wichtig, wenn Virtualisierung und Storage kritische Geschäftsservices tragen.
Mindestschicht: Cloud- und SaaS-Systeme
Viele Organisationen betreiben geschäftskritische Prozesse nicht mehr nur on-premises. Ohne Cloud- und SaaS-Nachweise bleibt das Audit- und Incident-Bild unvollständig.
Priorität haben häufig:
- Identitäts- und Login-Nachweise aus Microsoft 365 oder Google Workspace,
- administrative Änderungen auf Mandantenebene,
- Audit- und Sicherheitsnachweise aus Cloud-Plattformen,
- privilegierte Aktivitäten in geschäftskritischen SaaS-Diensten,
- zentrale Steuerungsereignisse in IaaS- und PaaS-Umgebungen.
Wer diese Ebene ignoriert, baut eine ernsthafte blinde Stelle auf.
Was Organisationen am häufigsten unterschätzen
Oft werden nicht die offensichtlichen Business-Server übersehen, sondern die Kontrollpunkte um sie herum:
- Management-Interfaces von Firewalls und Appliances,
- Administrationskonten in Cloud-Mandanten,
- Änderungen in VPN-Konfiguration und -Zugriff,
- Hypervisor- und Storage-Ereignisse,
- Nachweise aus Fernwartungswerkzeugen interner Teams oder externer Dienstleister.
Gerade diese Ebenen erklären in der Praxis oft, wie sich ein Angriff oder ein administrativer Fehler tatsächlich ausgebreitet hat. Ohne sie kann eine Organisation große Datenmengen sammeln und trotzdem die entscheidende Evidenz verpassen.
Erweiterte Schicht: wo breitere Abdeckung sinnvoll ist
Wenn die Mindestschicht stabil läuft, kann die Abdeckung risikobasiert erweitert werden. Typische Beispiele sind:
- breitere Endpoint-Abdeckung,
- Applikationslogs wichtiger interner Systeme,
- reichhaltigere Netzwerk-Telemetrie,
- spezialisierte Sicherheits-Appliances,
- Korrelation und Analyse mit längerem historischen Kontext.
Diese erweiterte Schicht sollte aus realen Risiken und Use Cases entstehen, nicht aus dem abstrakten Wunsch, "vorsichtshalber alles" zu sammeln.
Wie Sie bei knappem Budget priorisieren
Wenn das Budget begrenzt ist, hilft ein einfacher Filter.
1. Hilft diese Quelle zu erklären, wer was getan hat?
Wenn ja, hohe Priorität.
2. Hilft diese Quelle beim Aufbau einer Incident-Timeline?
Wenn ja, hohe Priorität.
3. Hilft diese Quelle, eine Audit-Aussage zu stützen?
Wenn ja, hohe Priorität.
4. Ist diese Quelle besonders riskant, weil die Nachweise aktuell nur lokal existieren?
Wenn ja, sollte sie auf der Zentralisierungs-Liste nach oben rücken.
Diese Logik führt bei vielen Organisationen zur gleichen ersten Welle: Identität, Firewalls, VPN, zentrale Server und Cloud-Identitäten.
Gute Priorisierung bedeutet auch bewusstes Weglassen. Ein häufiger Fehler ist, schon in Phase eins sehr breite Endpoint-Telemetrie, ausführliche Debug-Logs oder große Netzwerkdatenmengen einzusammeln, bevor grundlegende Fragen zu Identität, privilegierten Änderungen und Zugriffshistorie zuverlässig beantwortet werden können.
Warum Logs außerhalb der Quellsysteme zentralisiert werden müssen
Selbst die richtigen Quellen helfen nur begrenzt, wenn ihre Nachweise ausschließlich lokal bleiben. Bei einer Kompromittierung versuchen Angreifer oft, lokale Spuren zu verändern, zu löschen oder unzugänglich zu machen. Deshalb müssen kritische Logs an einen Ort gesendet und dort gehalten werden, der nicht mit dem kompromittierten System zusammenfällt.
Zentrale Sammlung außerhalb der Quellsysteme reduziert deutlich das Risiko:
- kritische Nachweise zu verlieren,
- manipulierte Historie zu akzeptieren,
- wichtige Ereignisse zu überschreiben,
- im Vorfall keinen Zugriff auf die Beweisspur zu haben.
Die Audit- und Verteidigungsperspektive ist ausführlicher beschrieben in Audit, Nachvollziehbarkeit und Nachweise.
Wie ein praktisches Minimum für KMU und den Mittelstand aussieht
Wenn Sie pragmatisch starten wollen, bedeutet ein brauchbares Minimum häufig:
- Identitäts-, Firewall-, VPN- und Kernserver-Logs zentralisieren,
- Cloud-Identitäten und wichtige SaaS-Admin-Logs ergänzen,
- verifizieren, dass die Quellen tatsächlich liefern,
- die Evidenz außerhalb der Quellsysteme aufbewahren,
- schnell nach Zeit, System und Identität suchen können.
Das ist oft weit wertvoller als ein breites Projekt ohne klare Prioritäten.
Ebenso wichtig ist die praktische Verifikation. Eine Quelle ist nicht wirklich abgedeckt, nur weil sie in einer Konfiguration eingetragen wurde. Sie sollten wissen:
- dass Nachweise konsistent ankommen,
- dass sie auch später noch lesbar sind,
- dass konkrete Logins, Änderungen oder Alarme gefunden werden können,
- dass Ausfälle der Sammlung schnell auffallen,
- dass kritische Evidenz nicht nur in lokalen Dateien auf betroffenen Systemen liegt.
Genau diese operative Prüfung macht aus einem Logging-Plan ein belastbares Minimum.
Ein weiterer häufiger Fehler ist, Priorisierung nur technisch zu verstehen. In der Praxis sollten Sie auch fragen, welche Quellen in einem Audit oder in einer Management-Eskalation den höchsten Erklärwert haben. Ein Domain Controller, eine Firewall oder ein VPN-Gateway liefert oft weniger Datenvolumen als breite Endpunkt-Telemetrie, aber erheblich mehr Aussagekraft für die Fragen, die unter Druck tatsächlich gestellt werden. Gute Priorisierung bedeutet deshalb immer auch: Welche Quelle verbessert unsere Verteidigbarkeit am stärksten?
Ebenso wichtig ist die Abstimmung zwischen IT und Leitungsebene. Wenn Management ein belastbares Mindestniveau erwartet, sollte klar dokumentiert sein, welche Quellen bereits zentralisiert sind, welche noch fehlen und welches Risiko daraus entsteht. So wird aus einer technischen Sammelaufgabe ein nachvollziehbarer Fahrplan für Auditierbarkeit, Vorfallanalyse und spätere Erweiterungen.
Praktische Empfehlungen
Wenn Sie das Thema schnell strukturieren wollen:
- Listen Sie Ihre kritischen Services und Systeme auf.
- Bestimmen Sie pro Layer die Nachweise mit höchster Audit- und Incident-Relevanz.
- Definieren Sie das Minimum für Phase eins.
- Sorgen Sie für zentrale Aufbewahrung außerhalb der Quellsysteme.
- Prüfen Sie, dass sich aus den Daten ein konkretes Szenario rekonstruieren lässt und nicht nur, dass "irgendwo Logs ankommen".
Wenn Sie den strategischen Rahmen brauchen, gehen Sie zurück zu NIS2 und Log-Aufbewahrung.
FAQ
Sollten wir jedes Windows-Event sammeln?
Meist nicht. Beginnen Sie mit Events, die für Identität, Privilegien, Änderungen und sicherheitsrelevante Anomalien den größten Wert haben.
Was ist bei begrenztem Budget die erste Priorität?
Für die meisten Organisationen: Identität, Firewalls, VPN und zentrale Server. Diese Quellen bestimmen sehr häufig sowohl Audit-Qualität als auch Incident-Nachvollziehbarkeit.
Reicht es, wenn wir Logs bei Bedarf aus einzelnen Geräten ziehen können?
Das bleibt ein schwaches Modell. Bei Kompromittierung oder Ausfall sind die Nachweise womöglich zu spät erreichbar, unvollständig oder bereits verändert.
Interne Links
- Zurück zur NIS2-Übersicht
- Fällt Ihre Organisation unter NIS2?
- NIS2 für die Geschäftsleitung
- Audit, Nachvollziehbarkeit und Nachweise
Nächster Schritt
- Minimalen Logging-Standard erhalten für KMU und den Mittelstand.
- Bereitschaftseinschätzung anfordern zu priorisierten Quellen und Retention.
- Erste Orientierungskonsultation anfragen zur Definition der ersten Logging-Welle für Audit und Vorfälle.