Firewalls blockieren Verbindungen. EDR-Systeme überwachen Endgeräte. Server werden gehärtet, Sicherheitsupdates installiert und Backups unveränderbar gespeichert.

Doch eine entscheidende Frage bleibt:

Woran erkennen wir eigentlich, dass gerade etwas passiert?

Ein fehlgeschlagener Login ist zunächst kein Sicherheitsvorfall. Tausend fehlgeschlagene Anmeldungen innerhalb weniger Minuten können dagegen auf einen Angriff hindeuten.

Ein Administrator, der sich um 10 Uhr an einem Server anmeldet, ist wahrscheinlich normal.

Meldet sich dasselbe Konto plötzlich um 3:17 Uhr von einem ungewöhnlichen System an und versucht anschließend, mehrere Sicherheitsdienste zu deaktivieren, sieht die Situation anders aus.

Genau hier kommen Logging, Monitoring, SIEM und Alarmierung ins Spiel.

Im Zusammenhang mit NIS-2 sind diese Mechanismen besonders wichtig. Sicherheitsmaßnahmen sollen nicht nur vorhanden sein. Organisationen müssen auch in der Lage sein, Sicherheitsereignisse zu erkennen, zu bewerten und angemessen darauf zu reagieren.

Die grundlegende Kette lautet:

Ereignis → Protokollierung → Sammlung → Analyse → Erkennung → Alarmierung → Reaktion

Logging und Monitoring sind nicht dasselbe

Die beiden Begriffe werden häufig gemeinsam verwendet, beschreiben jedoch unterschiedliche Aufgaben.

Logging

Logging bedeutet zunächst, dass Systeme Ereignisse protokollieren.

Beispiele:

• Benutzeranmeldungen,
• fehlgeschlagene Anmeldungen,
• gestartete Dienste,
• Firewallverbindungen,
• Änderungen an Benutzerkonten,
• Systemfehler,
• Softwareinstallationen,
• administrative Aktionen.

Logs beantworten damit vor allem die Frage:

Was ist auf einem System passiert?

Monitoring

Monitoring überwacht dagegen fortlaufend Zustände und Messwerte.

Beispiele:

• CPU-Auslastung,
• Arbeitsspeicher,
• Festplattenkapazität,
• Netzwerkverkehr,
• Antwortzeiten,
• Verfügbarkeit von Diensten,
• Zertifikatslaufzeiten,
• Backupstatus.

Monitoring beantwortet beispielsweise:

Funktioniert das System noch ordnungsgemäß?

Beide Bereiche überschneiden sich zunehmend.

Ein plötzlich ausgefallener Dienst kann ein technischer Defekt sein – oder die Folge eines Cyberangriffs.

1. Welche Ereignisse sollten protokolliert werden?

Nicht jedes Ereignis ist gleich wichtig.

Eine Organisation sollte deshalb definieren, welche Protokolldaten für Betrieb und Informationssicherheit benötigt werden.

Besonders relevant sind beispielsweise:

Authentifizierung

• erfolgreiche Anmeldungen,
• fehlgeschlagene Anmeldungen,
• Konto-Sperrungen,
• MFA-Ereignisse,
• Passwortänderungen.

Benutzerverwaltung

• neue Benutzerkonten,
• gelöschte Benutzerkonten,
• Änderungen an Gruppen,
• Vergabe administrativer Rechte,
• Änderungen von Rollen.

Systeme

• Start und Herunterfahren,
• Dienststarts,
• Dienstabbrüche,
• Softwareinstallationen,
• Konfigurationsänderungen,
• Systemfehler.

Netzwerk

• erlaubte Verbindungen,
• blockierte Verbindungen,
• VPN-Verbindungen,
• ungewöhnliche Datenströme,
• Firewalländerungen.

Sicherheitslösungen

• Malware-Erkennung,
• EDR-Alarme,
• blockierte Dateien,
• Quarantäne-Ereignisse,
• deaktivierte Schutzfunktionen.

Der Grundsatz sollte dabei nicht lauten:

„Wir loggen einfach alles.“

Sondern:

„Wir protokollieren die Ereignisse, die wir für Betrieb, Sicherheit, Nachweis und Analyse benötigen.“

2. Linux-Protokolle mit Syslog

In Linux- und Unix-Umgebungen gehört Syslog zu den wichtigsten Grundlagen der zentralen Protokollierung.

Das Grundprinzip ist einfach:

Linux-Server
     │
     ▼
Syslog
     │
     ▼
zentraler Logserver

Statt Protokolle ausschließlich lokal zu speichern, können sie an einen zentralen Server übertragen werden.

Typische Implementierungen sind beispielsweise:

• rsyslog,
• syslog-ng,
• systemd-journald in Verbindung mit entsprechenden Weiterleitungsmechanismen.

Unter modernen Linux-Systemen spielt außerdem das systemd-Journal eine wichtige Rolle.

Mit:

journalctl

lassen sich protokollierte Ereignisse anzeigen.

Nur Meldungen seit dem letzten Systemstart:

journalctl -b

Ereignisse eines bestimmten Dienstes:

journalctl -u ssh

Je nach Distribution kann der SSH-Dienst beispielsweise auch sshd heißen.

Ein Zeitraum lässt sich ebenfalls eingrenzen:

journalctl --since "today"

Damit steht bereits ein mächtiges Werkzeug für lokale Analysen zur Verfügung.

Für größere Umgebungen reicht lokale Protokollierung jedoch nicht aus.

3. Warum Logs zentral gespeichert werden sollten

Stellen wir uns einen kompromittierten Server vor.

Der Angreifer erhält Root- beziehungsweise Administratorrechte.

Damit könnte er möglicherweise versuchen:

• lokale Logs zu löschen,
• Protokolldateien zu verändern,
• Logging zu deaktivieren,
• Spuren seiner Aktivitäten zu beseitigen.

Werden relevante Ereignisse dagegen unmittelbar an einen zentralen Logserver übertragen, wird eine nachträgliche Manipulation deutlich schwieriger.

Eine einfache Architektur könnte folgendermaßen aussehen:

Linux ─────────┐
               │
Windows ───────┤
               │
Firewall ──────┼──► zentraler Logserver
               │
VPN ───────────┤
               │
Switches ──────┤
               │
Anwendungen ───┘

Damit entsteht eine zentrale Sicht auf die Infrastruktur.

4. Syslog allein ist noch kein SIEM

Ein zentraler Logserver sammelt Ereignisse.

Ein Security Information and Event Management, kurz SIEM, geht darüber hinaus.

Ein SIEM kann Daten aus unterschiedlichen Quellen sammeln, normalisieren, durchsuchen, korrelieren und auf verdächtige Kombinationen von Ereignissen reagieren.

Beispielsweise:

Firewall ──────┐
Windows ───────┤
Linux ─────────┤
VPN ───────────┼──► SIEM ──► Analyse ──► Alarm
EDR ───────────┤
Cloud ─────────┤
Anwendungen ───┘

Der entscheidende Mehrwert entsteht durch die Korrelation.

5. Aus einzelnen Logs wird ein Sicherheitsereignis

Betrachten wir folgende Ereignisse:

03:14:01  Login fehlgeschlagen
03:14:03  Login fehlgeschlagen
03:14:05  Login fehlgeschlagen
03:14:08  Login erfolgreich
03:14:21  Benutzer zu Administratoren hinzugefügt
03:14:35  Sicherheitsdienst beendet

Jede einzelne Meldung könnte isoliert betrachtet möglicherweise erklärbar sein.

Zusammen ergeben sie jedoch ein auffälliges Muster.

Ein SIEM kann solche Zusammenhänge erkennen und daraus einen Alarm erzeugen:

KRITISCH

Verdächtige Kontoübernahme

Benutzer: admin4711
System: srv-app-04
Zeit: 03:14 Uhr

Mehrere fehlgeschlagene Anmeldungen
→ erfolgreiche Anmeldung
→ Privilegienänderung
→ Sicherheitsdienst beendet

Genau diese Korrelation unterscheidet ein SIEM von einem einfachen Logarchiv.

6. Typische SIEM-Plattformen

Für zentrale Sicherheitsüberwachung existieren sowohl kommerzielle als auch Open-Source-Lösungen.

Beispiele sind:

• Microsoft Sentinel,
• Splunk Enterprise Security,
• IBM QRadar,
• Elastic Security,
• Wazuh,
• Graylog Security.

Welche Lösung geeignet ist, hängt stark von Größe, Infrastruktur, Budget, vorhandenen Kompetenzen und Integrationsanforderungen ab.

Ein SIEM ist außerdem kein Produkt, das man einfach installiert und anschließend vergessen kann.

Der eigentliche Aufwand beginnt häufig erst danach.

7. Monitoring der Infrastruktur

Neben Sicherheitsereignissen müssen auch technische Zustände überwacht werden.

Typische Monitoring-Werte sind:

CPU
RAM
Storage
Netzwerk
Dienste
Prozesse
Temperaturen
Zertifikate
Backups
Antwortzeiten

Werkzeuge dafür können beispielsweise sein:

• Zabbix,
• Checkmk,
• Icinga,
• Nagios,
• Prometheus,
• Grafana,
• PRTG.

Ein klassischer Monitoring-Alarm könnte lauten:

WARNUNG

Server: srv-db-02
Filesystem: /var
Belegung: 92 %

Das ist zunächst kein Cybersecurity-Alarm.

Aber auch Betriebsmonitoring kann sicherheitsrelevante Hinweise liefern.

8. Wenn Monitoring und Security zusammenkommen

Stellen wir uns einen Dateiserver vor.

Normalerweise verändert sich dessen Datenbestand täglich um wenige Gigabyte.

Plötzlich registriert das Monitoring:

Dateiänderungen: extrem erhöht
CPU: 98 %
Storage-I/O: 100 %
Backup-Datenmenge: +850 %

Gleichzeitig meldet die Sicherheitsüberwachung:

zahlreiche Dateien umbenannt
ungewöhnlicher Prozess gestartet
EDR-Warnung ausgelöst

Zusammen könnte dies auf einen Ransomware-Angriff hindeuten.

Deshalb sollten Betriebsmonitoring und Security Monitoring nicht vollständig isoliert voneinander betrachtet werden.

9. Alarmierung richtig gestalten

Logs zu sammeln reicht nicht.

Ein SIEM zu betreiben reicht ebenfalls nicht.

Wenn niemand auf einen kritischen Alarm reagiert, wurde zwar technisch etwas erkannt – organisatorisch jedoch nicht darauf reagiert.

Deshalb benötigt jede Alarmierung mindestens:

Ereignis
   │
   ▼
Priorität
   │
   ▼
Verantwortlicher
   │
   ▼
Benachrichtigung
   │
   ▼
Reaktion
   │
   ▼
Eskalation

Dabei sollte definiert werden:

• Wer erhält welchen Alarm?
• Wie schnell muss reagiert werden?
• Wann wird eskaliert?
• Wer übernimmt außerhalb der Geschäftszeiten?
• Wie wird die Bearbeitung dokumentiert?

10. Nicht jeder Alarm ist kritisch

Ein SIEM, das jeden fehlgeschlagenen Login als kritischen Sicherheitsvorfall meldet, wird schnell unbrauchbar.

Deshalb benötigen Alarme unterschiedliche Prioritäten.

Beispielsweise:

Information

Ungewöhnliches, aber nicht unmittelbar gefährliches Ereignis.

Niedrig

Geringfügige Abweichung ohne akute Bedrohung.

Mittel

Sicherheitsrelevantes Ereignis, das untersucht werden sollte.

Hoch

Wahrscheinlicher Sicherheitsvorfall.

Kritisch

Akute Gefährdung mit sofortigem Handlungsbedarf.

Prioritäten sollten nicht ausschließlich technisch bestimmt werden.

Auch der Schutzbedarf des betroffenen Systems spielt eine Rolle.

11. Alarm Fatigue vermeiden

Eine der größten Gefahren moderner Security-Systeme ist nicht zu wenig Alarmierung.

Es ist zu viel Alarmierung.

Wenn ein Security-Team jeden Tag 2.000 Warnungen erhält, kann der wirklich gefährliche Alarm zwischen hunderten irrelevanten Meldungen verschwinden.

Dieses Phänomen wird als Alert Fatigue bezeichnet.

Deshalb müssen Regeln regelmäßig optimiert werden:

Alarm
  │
  ▼
Analyse
  │
  ├── echter Vorfall
  │
  └── False Positive
           │
           ▼
      Regel verbessern

Ein gutes SIEM entwickelt sich kontinuierlich weiter.

12. Use Cases statt Log-Sammelwut

Vor der Integration einer Logquelle sollte idealerweise gefragt werden:

Was wollen wir damit erkennen?

Beispiele für Security Use Cases:

• Brute-Force-Angriffe,
• kompromittierte Benutzerkonten,
• neue Administratoren,
• verdächtige PowerShell-Ausführung,
• deaktivierte Sicherheitssoftware,
• ungewöhnliche VPN-Anmeldungen,
• Malware-Erkennung,
• Änderungen kritischer Dateien,
• ungewöhnliche Netzwerkverbindungen,
• Manipulation von Backup-Systemen.

Für jeden Use Case können anschließend die benötigten Datenquellen bestimmt werden.

Beispiel:

Use Case:
Verdächtige Administratorrechte erkennen

Benötigte Logs:
- Active Directory
- Windows Security Log
- IAM-System

Regel:
Neues Mitglied in privilegierter Gruppe

Alarm:
Priorität Hoch

Damit entsteht ein zielgerichtetes Security Monitoring.

13. Zeitstempel müssen stimmen

Ein unscheinbares, aber enorm wichtiges Thema ist die Zeitsynchronisation.

Stellen wir uns vor:

Firewall:      14:03 Uhr
Server:        14:08 Uhr
Domaincontroller: 13:59 Uhr
VPN-Gateway:   14:11 Uhr

Nun soll rekonstruiert werden, welcher Benutzer wann welche Verbindung aufgebaut hat.

Das wird schwierig.

Deshalb sollten Systeme ihre Zeit zuverlässig synchronisieren.

Typischerweise kommen dafür NTP beziehungsweise abgesicherte Zeitquellen zum Einsatz.

Eine konsistente Zeitbasis ist besonders wichtig für:

• Incident Response,
• Forensik,
• SIEM-Korrelation,
• Auditierung,
• Nachweisführung.

14. Log-Aufbewahrung definieren

Logs benötigen Speicherplatz.

Bei hunderten oder tausenden Systemen können sehr große Datenmengen entstehen.

Deshalb sollte nicht einfach festgelegt werden:

„Wir speichern alles für immer.“

Stattdessen benötigt die Organisation ein Aufbewahrungskonzept.

Dabei spielen unter anderem eine Rolle:

• Sicherheitsanforderungen,
• gesetzliche Anforderungen,
• Datenschutz,
• Speicherbedarf,
• forensische Anforderungen,
• interne Richtlinien,
• technische Notwendigkeit.

Unterschiedliche Logtypen können unterschiedliche Aufbewahrungszeiten besitzen.

Beispielsweise:

Security Logs      → definierte längere Aufbewahrung
System Logs        → mittlere Aufbewahrung
Debug Logs         → kurze Aufbewahrung

Die konkreten Fristen sollten aus den Anforderungen der jeweiligen Organisation abgeleitet und dokumentiert werden.

15. Datenschutz bei Logs beachten

Protokolldaten können personenbezogene Daten enthalten.

Beispielsweise:

• Benutzernamen,
• IP-Adressen,
• Geräteinformationen,
• Zugriffszeiten,
• Aktivitäten.

Deshalb bedeutet NIS-2 nicht:

„Alles unbegrenzt speichern.“

Logging muss auch mit Datenschutzanforderungen in Einklang gebracht werden.

Dazu gehören beispielsweise:

• Zweckbindung,
• angemessene Aufbewahrungsfristen,
• Zugriffsbeschränkungen,
• Löschkonzepte,
• Schutz der Protokolldaten.

Security Logging und Datenschutz sind keine Gegensätze.

Beides muss gemeinsam konzipiert werden.

16. Integrität der Logs schützen

Protokolldaten sind besonders wertvoll, wenn ein Sicherheitsvorfall untersucht werden muss.

Genau deshalb können sie für Angreifer interessant sein.

Wer seine Spuren verwischen möchte, könnte versuchen:

• Logs zu löschen,
• Einträge zu verändern,
• Logging abzuschalten,
• Zeitstempel zu manipulieren.

Deshalb sollten zentrale Logs gegen Manipulation geschützt werden.

Mögliche Maßnahmen sind:

• zentrale Speicherung,
• restriktive Berechtigungen,
• getrennte Administrationskonten,
• verschlüsselte Übertragung,
• manipulationsgeschützte Speicherung,
• Immutable Storage,
• Integritätsprüfungen.

Ein Administrator eines Produktivservers sollte idealerweise nicht gleichzeitig beliebig die zentral gespeicherten Sicherheitsprotokolle verändern können.

17. Ausfall des Logservers berücksichtigen

Auch das zentrale Logging selbst ist ein kritischer Dienst.

Was passiert, wenn der SIEM-Server ausfällt?

Mögliche Maßnahmen sind:

• lokale Zwischenspeicherung,
• redundante Systeme,
• Warteschlangen,
• Monitoring des Logsystems,
• Kapazitätsüberwachung.

Besonders gefährlich wäre:

SIEM ausgefallen
      │
      ▼
keine Logs
      │
      ▼
niemand bemerkt den Ausfall

Deshalb muss das Monitoring-System ebenfalls überwacht werden.

Oder vereinfacht:

Wer überwacht eigentlich die Überwachung?

18. Dashboards schaffen Übersicht

Dashboards können komplexe Sicherheitsinformationen verständlich darstellen.

Ein Security-Dashboard könnte beispielsweise zeigen:

──────────────────────────────
 SECURITY OVERVIEW
──────────────────────────────

Kritische Alarme          3

Hohe Alarme              11

Fehlgeschlagene Logins  742

EDR-Erkennungen           17

Neue Administratoren      2

Systeme ohne Logs          4

Letztes Update        12:42
──────────────────────────────

Dashboards sollten jedoch nicht nur möglichst beeindruckend aussehen.

Sie müssen konkrete Fragen beantworten.

Beispielsweise:

SOC

Welche Alarme müssen aktuell untersucht werden?

IT-Betrieb

Welche Systeme liefern keine Logs?

Informationssicherheit

Wie entwickelt sich die Sicherheitslage?

Management

Welche wesentlichen Risiken und Trends bestehen?

Unterschiedliche Zielgruppen benötigen deshalb unterschiedliche Dashboards.

19. Dashboard ist nicht gleich Alarmierung

Ein häufiger Fehler besteht darin, wichtige Sicherheitsinformationen ausschließlich auf einem Dashboard anzuzeigen.

Ein kritischer Angriff sollte jedoch nicht davon abhängen, dass zufällig jemand auf einen Bildschirm schaut.

Deshalb gilt:

Dashboard = Übersicht

Alarmierung = aktive Benachrichtigung

Kritische Ereignisse müssen aktiv an zuständige Personen oder Systeme weitergegeben werden.

20. Logquellen regelmäßig kontrollieren

Ein SIEM kann hervorragend funktionieren und trotzdem blind werden.

Beispielsweise wenn ein wichtiger Server plötzlich keine Logs mehr sendet.

Deshalb sollte überwacht werden:

Letztes Log von srv-web-01:
vor 30 Sekunden → OK

Letztes Log von srv-db-01:
vor 45 Sekunden → OK

Letztes Log von firewall-01:
vor 7 Stunden → WARNUNG

Das Fehlen von Logs ist selbst ein sicherheitsrelevantes Ereignis.

Denn vielleicht liegt nur ein Konfigurationsfehler vor.

Vielleicht wurde aber auch die Protokollierung deaktiviert.

21. Detection Engineering als kontinuierlicher Prozess

Eine moderne Sicherheitsüberwachung sollte nicht statisch bleiben.

Angriffsmethoden verändern sich.

Neue Systeme kommen hinzu.

Neue Schwachstellen entstehen.

Cloud-Dienste werden eingeführt.

Deshalb müssen Detection Rules kontinuierlich weiterentwickelt werden.

Ein sinnvoller Kreislauf lautet:

Bedrohung
   ↓
Use Case
   ↓
Datenquelle
   ↓
Detection Rule
   ↓
Alarm
   ↓
Analyse
   ↓
Optimierung

Damit entwickelt sich das SIEM gemeinsam mit der Infrastruktur und der Bedrohungslage weiter.

22. Dokumentation für NIS-2

Auch Logging und Monitoring müssen nachvollziehbar dokumentiert werden.

Dazu können beispielsweise gehören:

• Logging-Richtlinie,
• angebundene Systeme,
• relevante Logquellen,
• Aufbewahrungsfristen,
• Security Use Cases,
• Alarmierungsregeln,
• Eskalationswege,
• Verantwortlichkeiten,
• Dashboard-Konzepte,
• Ausnahmen,
• regelmäßige Überprüfungen.

Eine einfache Logquellen-Matrix könnte beispielsweise enthalten:

System:
Logquelle:
SIEM-Anbindung:
Aufbewahrung:
Verantwortlicher:
Security Use Cases:
Letzter Funktionstest:

Damit lässt sich auch erkennen, welche Systeme noch nicht ausreichend überwacht werden.

Praktische NIS-2-Checkliste für Logging und Monitoring

Logging

☐ Sind sicherheitsrelevante Ereignisse definiert?

☐ Werden erfolgreiche und fehlgeschlagene Anmeldungen protokolliert?

☐ Werden Änderungen administrativer Berechtigungen erfasst?

☐ Werden wichtige System- und Sicherheitsereignisse aufgezeichnet?

☐ Sind Zeitstempel systemübergreifend synchronisiert?

Zentrale Protokollierung

☐ Werden wichtige Logs zentral gesammelt?

☐ Sind Linux-, Windows-, Netzwerk- und Security-Systeme angebunden?

☐ Wird überwacht, ob Logquellen plötzlich ausfallen?

☐ Ist die Übertragung angemessen geschützt?

SIEM

☐ Existieren konkrete Security Use Cases?

☐ Werden Ereignisse verschiedener Quellen korreliert?

☐ Werden Detection Rules regelmäßig überprüft?

☐ Werden False Positives ausgewertet und Regeln optimiert?

Alarmierung

☐ Sind Alarmprioritäten definiert?

☐ Gibt es eindeutige Verantwortlichkeiten?

☐ Sind Eskalationswege dokumentiert?

☐ Existieren Verfahren für kritische Alarme außerhalb der regulären Betriebszeiten?

☐ Wird Alert Fatigue berücksichtigt?

Aufbewahrung

☐ Existiert ein dokumentiertes Aufbewahrungskonzept?

☐ Werden Datenschutzanforderungen berücksichtigt?

☐ Sind Löschfristen definiert?

☐ Ist ausreichende Speicherkapazität vorhanden?

Integrität

☐ Sind zentrale Logs vor Manipulation geschützt?

☐ Können Produktivadministratoren Sicherheitslogs nicht beliebig verändern?

☐ Werden administrative Zugriffe auf die Logging-Infrastruktur protokolliert?

☐ Existieren Backup- beziehungsweise Recovery-Konzepte für zentrale Logging-Systeme?

Dashboards

☐ Gibt es zielgruppengerechte Dashboards?

☐ Werden kritische Sicherheitsereignisse übersichtlich dargestellt?

☐ Sind fehlende Logquellen sichtbar?

☐ Werden Trends und Entwicklungen dargestellt?

☐ Werden kritische Ereignisse zusätzlich aktiv alarmiert?

Logging und Monitoring bilden die Augen und Ohren einer modernen IT-Sicherheitsarchitektur.

Firewalls, EDR, MFA, Netzwerksegmentierung und gehärtete Server können Angriffe erschweren. Doch keine einzelne Sicherheitsmaßnahme garantiert, dass ein Angreifer niemals erfolgreich sein wird.

Deshalb muss eine Organisation erkennen können, wenn etwas Ungewöhnliches passiert.

Syslog und zentrale Logging-Systeme schaffen zunächst Transparenz. SIEM-Plattformen führen Informationen aus unterschiedlichen Quellen zusammen und ermöglichen die Korrelation von Ereignissen. Monitoring überwacht zusätzlich den technischen Zustand der Infrastruktur.

Doch Technik allein reicht nicht.

Ein Alarm benötigt einen Verantwortlichen.

Ein Verantwortlicher benötigt einen Eskalationsweg.

Und eine Erkennung benötigt einen definierten Reaktionsprozess.

Ebenso wichtig sind angemessene Aufbewahrungsfristen, Datenschutz, Manipulationsschutz und die Überwachung der Logging-Infrastruktur selbst.

Der entscheidende Prozess lautet deshalb:

Protokollieren → Sammeln → Korrelieren → Erkennen → Alarmieren → Analysieren → Reagieren → Verbessern

Oder noch kürzer:

Was nicht protokolliert wird, lässt sich kaum analysieren. Was nicht überwacht wird, wird möglicherweise zu spät erkannt. Und ein Alarm, auf den niemand reagiert, schützt niemanden.

Genau deshalb sind Protokollierung und Monitoring keine Ergänzung einer NIS-2-Sicherheitsstrategie.

Sie sind eine ihrer grundlegenden Voraussetzungen.