NIS-2 schreibt Unternehmen und Organisationen nicht vor, bestimmte Produkte eines bestimmten Herstellers einzusetzen. Gefordert wird vielmehr, dass geeignete technische, operative und organisatorische Maßnahmen umgesetzt werden, um Risiken für Netz- und Informationssysteme angemessen zu beherrschen.

Das ist eine gute Nachricht für Organisationen, die auf Open Source und selbst betriebene Infrastruktur setzen möchten.

Denn viele zentrale Aufgaben einer modernen Sicherheitsarchitektur lassen sich mit etablierten Open-Source-Lösungen abdecken: Endpunkte überwachen, Protokolldaten sammeln, Angriffe erkennen, Schwachstellen identifizieren, Infrastruktur dokumentieren, Passwörter verwalten und technische Systeme überwachen.

In diesem Teil unserer NIS-2-Serie betrachten wir neun interessante Werkzeuge:

• Wazuh
• Graylog
• Beszel
• CrowdSec
• OpenVAS
• NetBox
• Vaultwarden
• Grafana
• Prometheus

Dabei geht es nicht darum, möglichst viele Anwendungen zu installieren. Entscheidend ist vielmehr, die Werkzeuge sinnvoll miteinander zu kombinieren und damit nachvollziehbare Sicherheitsprozesse aufzubauen.

Open Source und NIS-2

Ein häufiges Missverständnis lautet:

Für NIS-2 benötigt man zertifizierte Enterprise-Sicherheitssoftware.

So pauschal ist das nicht richtig.

Entscheidend ist nicht allein der Produktname, sondern ob die eingesetzten Maßnahmen geeignet sind, Risiken angemessen zu reduzieren und ob ihre Wirksamkeit nachvollziehbar kontrolliert werden kann.

Eine Organisation muss daher beispielsweise zeigen können:

• Welche Systeme existieren?
• Welche Systeme sind besonders schützenswert?
• Werden sicherheitsrelevante Ereignisse protokolliert?
• Werden Auffälligkeiten erkannt?
• Werden Schwachstellen gesucht?
• Werden Sicherheitsupdates eingespielt?
• Werden Angriffe erkannt und behandelt?
• Werden technische Systeme überwacht?
• Existieren definierte Verantwortlichkeiten?
• Können Maßnahmen und Ergebnisse dokumentiert werden?

Open-Source-Systeme können dabei einen erheblichen Beitrag leisten.

Sie ersetzen allerdings weder Sicherheitskonzepte noch Prozesse, Verantwortlichkeiten oder ein funktionierendes ISMS.

Wazuh – SIEM und Endpoint Security

Wazuh gehört zu den interessantesten Open-Source-Plattformen für Organisationen, die Sicherheitsüberwachung selbst betreiben möchten.

Das Projekt beschreibt Wazuh als Open-Source-Sicherheitsplattform für XDR- und SIEM-Funktionen. Die Architektur besteht aus Agenten auf überwachten Systemen sowie zentralen Komponenten wie Wazuh Server, Indexer und Dashboard.

Agenten können beispielsweise auf Linux- und Windows-Systemen installiert werden.

Wazuh kann unter anderem für folgende Aufgaben eingesetzt werden:

• Log-Auswertung
• File Integrity Monitoring
• Erkennung verdächtiger Aktivitäten
• Überwachung von Sicherheitskonfigurationen
• Malware-Erkennung
• Schwachstellenerkennung
• Überwachung von Benutzeraktivitäten
• Compliance-Monitoring
• Alarmierung

Ein typisches Szenario:

Ein Administrator verändert auf einem Linux-Server die Datei

/etc/ssh/sshd_config

Wird diese Datei über File Integrity Monitoring überwacht, kann Wazuh die Änderung erkennen und protokollieren.

Damit lässt sich später nachvollziehen:

• wann die Datei verändert wurde,
• auf welchem Server dies geschah,
• welche sicherheitsrelevante Konfiguration betroffen war.

Bedeutung für NIS-2

Wazuh kann insbesondere bei folgenden Bereichen unterstützen:

• Erkennung von Sicherheitsereignissen
• Incident Detection
• Protokollierung
• Integritätsüberwachung
• Endpoint Security
• Schwachstellenmanagement
• Nachweis technischer Kontrollen

Für kleinere und mittlere Umgebungen kann Wazuh deshalb einen wesentlichen Baustein eines eigenen Security-Monitorings darstellen.

Graylog – Logs zentral sammeln

Neben Wazuh ist ein zweites Konzept für NIS-2 besonders wichtig:

zentrale Protokollierung.

Logs auf einzelnen Servern helfen nur begrenzt, wenn sie im Sicherheitsvorfall erst auf Dutzenden Systemen zusammengesucht werden müssen.

Graylog kann Logdaten unterschiedlicher Systeme zentral sammeln, durchsuchen und auswerten.

Typische Quellen sind beispielsweise:

Linux-Server
Windows-Server
Firewalls
Switches
Router
Webserver
Proxyserver
VPN-Gateways
Anwendungen
Authentifizierungssysteme

Aus vielen einzelnen Logquellen entsteht damit ein zentral durchsuchbarer Datenbestand.

Beispiel

Ein Benutzerkonto meldet sich innerhalb weniger Minuten an verschiedenen Servern an.

Auf jedem einzelnen System wäre dies möglicherweise unauffällig.

Werden die Ereignisse jedoch zentral gesammelt und miteinander korreliert, kann daraus ein verdächtiges Muster entstehen.

Graylog eignet sich deshalb besonders für:

• zentrale Logsammlung
• Ereignissuche
• Dashboards
• Alarmierung
• Analyse von Sicherheitsvorfällen
• langfristige Protokollierung

Graylog oder Wazuh?

Die Systeme überschneiden sich teilweise.

Graylog ist stark auf Log Management und Analyse ausgerichtet.

Wazuh ergänzt dies um stärker sicherheitsorientierte Funktionen wie Endpoint-Agenten, Integritätsüberwachung und Detection-Regeln.

Je nach Architektur können beide Lösungen deshalb sogar parallel eingesetzt werden.

Beszel – leichtgewichtiges Server-Monitoring

Nicht jedes Monitoring-System muss riesig sein.

Beszel verfolgt einen vergleichsweise schlanken Ansatz und eignet sich insbesondere für die schnelle Überwachung von Servern und kleineren Infrastrukturen.

Damit lassen sich beispielsweise Kennzahlen beobachten wie:

• CPU-Auslastung
• Arbeitsspeicher
• Speicherplatz
• Netzwerk
• Systemstatus
• Container

Gerade bei kleineren IT-Abteilungen kann eine solche Lösung hilfreich sein, weil der administrative Aufwand überschaubar bleibt.

Warum ist Server-Monitoring für NIS-2 relevant?

Informationssicherheit bedeutet nicht nur Angriffserkennung.

Auch die Verfügbarkeit von Diensten gehört zu den zentralen Sicherheitszielen.

Ein ausgefallener Datenträger, vollständig belegter Speicher oder permanent überlasteter Server kann genauso einen erheblichen Betriebsunterbruch verursachen wie ein Cyberangriff.

Beszel kann deshalb als leichtgewichtige Ergänzung zu umfangreicheren Security-Systemen eingesetzt werden.

CrowdSec – Angriffe erkennen und blockieren

CrowdSec verfolgt einen interessanten Ansatz zur automatisierten Angriffserkennung.

Die CrowdSec Security Engine analysiert Logs beziehungsweise HTTP-Anfragen anhand verhaltensbasierter Szenarien. Erkannte Angreifer können anschließend über sogenannte Remediation Components blockiert werden.

Typische Beispiele sind:

• SSH-Brute-Force
• Webserver-Angriffe
• Credential Stuffing
• Scanner
• Bots
• wiederholte fehlgeschlagene Anmeldungen

CrowdSec kann dabei beispielsweise Logs von

sshd
nginx
Apache
Traefik
Firewall

analysieren.

Wird ein Angreifer erkannt, kann dessen IP-Adresse anschließend beispielsweise über eine Firewall-Komponente blockiert werden.

Unterschied zu Fail2ban

Auf den ersten Blick erinnert CrowdSec stark an Fail2ban.

Der Ansatz ist jedoch umfangreicher.

CrowdSec arbeitet mit verhaltensbasierten Szenarien und kann zusätzlich Informationen über bekannte bösartige Quellen aus seiner Community-Infrastruktur beziehen.

NIS-2-Nutzen

CrowdSec kann insbesondere helfen bei:

• Angriffserkennung
• automatisierter Reaktion
• Schutz öffentlich erreichbarer Dienste
• SSH-Härtung
• Webserver-Schutz
• Reduzierung automatisierter Angriffe

Wichtig bleibt allerdings:

Automatische Blockierungen sollten überwacht und regelmäßig überprüft werden.

OpenVAS – Schwachstellen finden

Ein wesentlicher Bestandteil eines funktionierenden Sicherheitsmanagements ist die regelmäßige Suche nach Schwachstellen.

Hier kommt OpenVAS ins Spiel.

OpenVAS beziehungsweise die Greenbone-Technologie kann Netzwerke und Systeme auf bekannte Schwachstellen untersuchen.

Ein Scanner prüft beispielsweise:

192.168.10.0/24

und untersucht erreichbare Systeme auf bekannte Sicherheitsprobleme.

Mögliche Ergebnisse sind beispielsweise:

• veraltete Software
• bekannte CVEs
• unsichere Dienste
• fehlerhafte Konfigurationen
• veraltete Verschlüsselungsverfahren
• problematische Netzwerkdienste

Dabei entstehen typischerweise Bewertungen nach Risikoklassen.

Beispielsweise:

Critical
High
Medium
Low

Diese Ergebnisse bilden die Grundlage für einen strukturierten Schwachstellenprozess.

Aber Vorsicht

Ein Schwachstellenscanner alleine löst keine Schwachstellen.

Der eigentliche Prozess beginnt erst nach dem Scan:

Scan
   ↓
Bewertung
   ↓
Priorisierung
   ↓
Patch oder Gegenmaßnahme
   ↓
Dokumentation
   ↓
erneuter Scan

Genau dieser nachvollziehbare Prozess ist wesentlich wichtiger als eine einmalige hundertseitige Scan-Auswertung.

NetBox – wissen, was überhaupt vorhanden ist

Man kann keine Infrastruktur schützen, die niemand vollständig kennt.

Deshalb spielt Asset Management eine zentrale Rolle.

NetBox wurde speziell für die Modellierung und Dokumentation von Netzwerk-Infrastrukturen entwickelt und versteht sich als zentrale Source of Truth für Netzwerke. Das System verbindet unter anderem IP Address Management und Datacenter Infrastructure Management.

NetBox kann beispielsweise verwalten:

• Standorte
• Server
• Switches
• Router
• Racks
• virtuelle Maschinen
• Interfaces
• IP-Adressen
• VLANs
• Netzwerke
• Kabelverbindungen
• Gerätebeziehungen

Aus einem historisch gewachsenen Excel-Dokument kann damit eine strukturierte Infrastruktur-Datenbank werden.

Beispiel

Statt:

serverliste-final-neu-v3-wirklich-final.xlsx

existiert eine zentrale Datenbasis:

Server
 ├── Standort
 ├── Rack
 ├── Rolle
 ├── IP-Adresse
 ├── Interface
 └── Netzwerk

Ein entscheidender Punkt ist allerdings: NetBox soll primär den gewünschten beziehungsweise dokumentierten Zustand der Infrastruktur als Source of Truth abbilden. Es ersetzt deshalb kein Live-Monitoring.

Bedeutung für NIS-2

NetBox unterstützt insbesondere:

• Asset Management
• Netzwerkdokumentation
• Verantwortlichkeiten
• Abhängigkeiten
• Change Management
• Automatisierung

Eine aktuelle Asset-Datenbank ist gleichzeitig eine wichtige Grundlage für Risikoanalysen.

Vaultwarden – Passwörter zentral verwalten

Administratoren benötigen Zugangsdaten für zahlreiche Systeme:

• Server
• Firewalls
• Switches
• Anwendungen
• Datenbanken
• Backup-Systeme
• Cloud-Dienste

Diese Kennwörter gehören nicht in Excel-Dateien, Textdateien, Browsernotizen oder persönliche Passwortsammlungen.

Vaultwarden ist eine in Rust geschriebene, inoffizielle Serverimplementierung der Bitwarden Client API und kann mit offiziellen Bitwarden-Clients verwendet werden. Das Projekt ist unabhängig von Bitwarden.

Damit lässt sich ein Passwortmanagement-System selbst hosten.

Mögliche Funktionen sind beispielsweise:

• Passworttresore
• Organisationen
• Collections
• Passwortfreigaben
• Benutzerrollen
• Gruppen
• Event Logs
• Zwei-Faktor-Authentifizierung
• WebAuthn

Die Projekt-Dokumentation empfiehlt für den Web Vault HTTPS und weist auf regelmäßige Backups hin.

Beispiel

Statt:

Firewall Admin:
admin
Sommer2026!

existiert ein kontrollierter Passworttresor.

Idealerweise kombiniert mit:

langes Master-Passwort
+
MFA
+
rollenbasierter Zugriff
+
regelmäßige Backups

Wichtiger Hinweis

Vaultwarden ist nicht der offizielle Bitwarden-Server.

Bitwarden selbst weist darauf hin, dass die Funktion der offiziellen Clients mit inoffiziellen Servern wie Vaultwarden nicht vollständig garantiert werden kann.

Für Unternehmen und Behörden sollte deshalb bewusst geprüft werden:

• Supportanforderungen
• Betriebsverantwortung
• Backup
• Hochverfügbarkeit
• Updates
• Risiko
• organisatorische Vorgaben

Open Source bedeutet schließlich auch:

Der Betreiber übernimmt einen erheblichen Teil der Betriebsverantwortung selbst.

Prometheus – Metriken sammeln

Während Graylog und Wazuh primär Ereignisse und Logs betrachten, konzentriert sich Prometheus auf Metriken.

Prometheus ist ein Open-Source-System für Monitoring und Alerting. Es sammelt Messwerte als Zeitreihendaten und kann Metriken regelmäßig von überwachten Endpunkten abrufen.

Typische Metriken sind:

CPU-Auslastung
RAM-Auslastung
Festplattenbelegung
Netzwerktraffic
HTTP-Anfragen
Antwortzeiten
Fehlerraten
Datenbankverbindungen
Containerzustände

Viele Systeme stellen solche Werte über sogenannte Exporter zur Verfügung.

Ein typisches Beispiel ist der Node Exporter für Linux-Systeme.

Damit entsteht beispielsweise:

Linux Server
     │
     ▼
Node Exporter
     │
     ▼
Prometheus

Prometheus speichert diese Werte als Zeitreihen.

Dadurch kann beispielsweise festgestellt werden:

Der freie Speicherplatz eines Servers ist innerhalb von sieben Tagen von 40 auf 5 Prozent gefallen.

Solche Entwicklungen sind für die Verfügbarkeit der Infrastruktur enorm wichtig.

Grafana – Daten sichtbar machen

Prometheus sammelt Daten.

Grafana macht sie verständlich.

Grafana OSS kann Metriken, Logs und andere Telemetriedaten aus unterschiedlichen Datenquellen abfragen, visualisieren und für Alarmierungen verwenden. Unterstützt werden unter anderem Prometheus sowie zahlreiche weitere Datenquellen.

Ein Dashboard könnte beispielsweise anzeigen:

NIS-2 Infrastrukturübersicht

Server verfügbar             98 / 100
kritische Alarme              3
Speicher > 90 %               4
CPU > 80 %                    2
ungepatchte Systeme           8
fehlgeschlagene Logins       37
erkannte Angriffe            12

Damit bekommt das IT-Team eine zentrale Übersicht über den Zustand der Infrastruktur.

Grafana-Dashboards bestehen aus Panels, die Daten aus angebundenen Quellen abfragen, transformieren und visualisieren.

Prometheus und Grafana bilden deshalb eines der bekanntesten Gespanne:

Systeme
   │
   ▼
Exporter
   │
   ▼
Prometheus
   │
   ▼
Grafana

Die Werkzeuge sinnvoll kombinieren

Die Stärke entsteht weniger durch ein einzelnes Produkt als durch die Kombination der verschiedenen Aufgabenbereiche.

Eine mögliche Open-Source-Sicherheitsarchitektur könnte folgendermaßen aussehen:

                    ┌──────────────────┐
                    │      NetBox      │
                    │ Asset Management │
                    └─────────┬────────┘
                              │
                              │
          ┌───────────────────┴───────────────────┐
          │                                       │
          ▼                                       ▼

 ┌──────────────────┐                    ┌─────────────────┐
 │      Server      │                    │ Netzwerkgeräte  │
 │ Windows / Linux  │                    │ Firewall/Switch │
 └────────┬─────────┘                    └────────┬────────┘
          │                                       │
          ├────────── Logs ───────────────────────┤
          │                                       │
          ▼                                       ▼
 ┌──────────────────────────────────────────────────┐
 │               Wazuh / Graylog                    │
 │           Security & Log Management              │
 └────────────────────────┬─────────────────────────┘
                          │
                          ▼
                  Security Alerts

Parallel dazu:

Server
  │
  ├── CrowdSec
  │       │
  │       └── Angriffserkennung / Blockierung
  │
  ├── OpenVAS
  │       │
  │       └── Schwachstellenprüfung
  │
  └── Prometheus Exporter
          │
          ▼
      Prometheus
          │
          ▼
        Grafana

Und für administrative Zugangsdaten:

Administratoren
      │
      ▼
 Vaultwarden
      │
      ▼
Server / Firewall / Anwendungen

Beispiel für einen vollständigen Open-Source-Stack

Eine Organisation könnte beispielsweise folgende Aufgabenverteilung verwenden:

NetBox

Inventar und Netzwerkdokumentation.

Wazuh

Security Monitoring der Endpunkte.

Graylog

Zentrale Sammlung und Analyse von Logdaten.

CrowdSec

Erkennung und Blockierung automatisierter Angriffe.

OpenVAS

Regelmäßige Schwachstellenscans.

Vaultwarden

Zentrale Verwaltung administrativer Zugangsdaten.

Prometheus

Sammlung technischer Metriken.

Grafana

Visualisierung und Alerting.

Beszel

Zusätzliches einfaches Server- und Container-Monitoring.

Damit entsteht keine vollständige NIS-2-Compliance auf Knopfdruck.

Es entsteht aber eine leistungsfähige technische Grundlage.

Doppelungen sind nicht automatisch schlecht

Bei dieser Zusammenstellung fällt auf, dass sich Funktionen teilweise überschneiden.

Beispiele:

Wazuh ↔ Graylog
Wazuh ↔ OpenVAS
Beszel ↔ Prometheus
Grafana ↔ andere Dashboards
CrowdSec ↔ Firewall / Wazuh

Das bedeutet nicht automatisch, dass alle Systeme parallel betrieben werden sollten.

Im Gegenteil:

Jede zusätzliche Sicherheitsplattform muss selbst betrieben, aktualisiert, gesichert und überwacht werden.

Deshalb sollte immer zuerst die Frage gestellt werden:

Welches Problem wollen wir eigentlich lösen?

Wer bereits Wazuh intensiv verwendet, benötigt möglicherweise nicht zusätzlich eine umfangreiche Graylog-Installation.

Wer 20 überschaubare Server überwacht, kommt möglicherweise hervorragend mit Beszel zurecht.

Wer mehrere hundert Systeme, Containerplattformen und Anwendungen überwacht, wird wahrscheinlich eher auf Prometheus und Grafana setzen.

Open Source bedeutet nicht kostenlos

Bei Open Source fallen möglicherweise keine oder geringere Lizenzkosten an.

Kosten entstehen trotzdem.

Beispielsweise durch:

• Server
• Speicherplatz
• Backup
• Administration
• Updates
• Monitoring
• Schulungen
• Konfiguration
• Integration
• Dokumentation
• Incident Response

Besonders SIEM- und Logging-Systeme benötigen teilweise erhebliche Speicherkapazitäten.

Wenn beispielsweise täglich 50 GB Logdaten entstehen, werden daraus innerhalb eines Jahres theoretisch:

50 GB × 365
=
18.250 GB

also mehr als

18 TB

Rohdaten.

Deshalb müssen auch bei Open-Source-Systemen Aufbewahrungszeiten und Speicherarchitektur geplant werden.

Die Werkzeuge müssen selbst abgesichert werden

Ein weiterer entscheidender Punkt:

Sicherheitssoftware ist selbst ein besonders attraktives Angriffsziel.

Ein kompromittiertes Wazuh-, Graylog-, NetBox- oder Vaultwarden-System kann Angreifern wertvolle Informationen über die gesamte Infrastruktur liefern.

Deshalb gelten für diese Systeme besonders hohe Anforderungen.

Mindestens berücksichtigt werden sollten:

• regelmäßige Updates
• MFA
• rollenbasierte Berechtigungen
• Netzwerksegmentierung
• TLS
• sichere Backups
• restriktiver administrativer Zugriff
• Logging
• Monitoring
• Wiederherstellungstests

Besonders zentrale Passwort-, Monitoring- und SIEM-Systeme sollten nicht einfach offen aus dem Internet erreichbar sein.

Dokumentation bleibt entscheidend

NIS-2 ist keine Produktsammlung.

Es reicht deshalb nicht, in einer Prüfung zu sagen:

„Wir haben Wazuh, CrowdSec und OpenVAS installiert.“

Viel wichtiger sind Aussagen wie:

„Alle produktiven Server werden zentral überwacht.“

„Kritische Sicherheitsereignisse erzeugen automatisch einen Alarm.“

„Schwachstellenscans werden monatlich durchgeführt.“

„Kritische Schwachstellen werden innerhalb einer definierten Frist bewertet.“

„Administrationskennwörter werden ausschließlich über einen zentral verwalteten Passworttresor bereitgestellt.“

„Alle Netzwerkkomponenten werden in einer zentralen Asset-Datenbank dokumentiert.“

Damit wird aus Technik ein nachvollziehbarer Sicherheitsprozess.

Beispiel für einen Betriebsprozess

Ein technischer Kontrollprozess könnte beispielsweise folgendermaßen aussehen:

Montag
│
├── OpenVAS Scan
│
├── Prüfung kritischer Schwachstellen
│
└── Tickets für notwendige Maßnahmen

Täglich:

Wazuh
Graylog
CrowdSec
Prometheus
       │
       ▼
automatische Überwachung
       │
       ▼
Alarm
       │
       ▼
Bewertung
       │
       ▼
Incident / Ticket

Monatlich:

NetBox
  │
  ▼
Asset-Abgleich

Vaultwarden
  │
  ▼
Berechtigungsprüfung

Grafana
  │
  ▼
Verfügbarkeitsanalyse

Dadurch wird die Sicherheitsarchitektur zu einem kontinuierlichen Prozess.

Nicht alles auf einen Server

Technisch wäre es verlockend, alle Systeme auf einem leistungsfähigen Docker-Host zu installieren:

Wazuh
Graylog
NetBox
Vaultwarden
Grafana
Prometheus
CrowdSec

Für eine produktive Sicherheitsarchitektur wäre das jedoch problematisch.

Fällt dieser Host aus, wären möglicherweise gleichzeitig betroffen:

• Monitoring
• Passwortverwaltung
• Logging
• Security Detection
• Netzwerkdokumentation

Noch problematischer:

Wird der Server kompromittiert, könnten gleich mehrere zentrale Sicherheitskomponenten betroffen sein.

Deshalb sollte die Architektur nach Schutzbedarf getrennt werden.

Eine sinnvollere Architektur

Beispielsweise:

Management-Netz
│
├── NetBox
├── Vaultwarden
└── Management-Systeme
Security-Netz
│
├── Wazuh
├── Graylog
└── OpenVAS
Monitoring-Netz
│
├── Prometheus
├── Grafana
└── Beszel

Öffentlich erreichbare Server verwenden gegebenenfalls zusätzlich:

CrowdSec

Solche Netze müssen nicht zwingend physisch getrennt sein.

VLANs und Firewall-Regeln können ebenfalls eine sinnvolle Segmentierung ermöglichen.

Was dieser Stack nicht ersetzt

Auch neun gute Open-Source-Lösungen ersetzen keine vollständige Sicherheitsorganisation.

Weiterhin benötigt werden unter anderem:

• Risikoanalyse
• Informationssicherheitsrichtlinien
• Patchmanagement
• Backup
• Business Continuity
• Incident Response
• Schulungen
• Lieferantenmanagement
• Notfallplanung
• Verantwortlichkeiten
• Meldeprozesse

Die technische Plattform ist nur ein Baustein.

Ein durchaus wichtiger – aber eben nur einer.

NIS-2 muss nicht zwangsläufig bedeuten, eine Sammlung teurer proprietärer Security-Produkte einzukaufen.

Mit Open-Source-Werkzeugen lässt sich bereits eine beachtliche Sicherheitsarchitektur aufbauen.

Wazuh überwacht Sicherheitsereignisse und Endpunkte.

Graylog sammelt und analysiert Logs.

Beszel ermöglicht schlankes Server-Monitoring.

CrowdSec erkennt und blockiert Angreifer.

OpenVAS sucht nach Schwachstellen.

NetBox dokumentiert die Infrastruktur.

Vaultwarden schützt administrative Zugangsdaten.

Prometheus sammelt technische Messwerte.

Grafana verwandelt diese Daten in übersichtliche Dashboards und Alarme.

Zusammen können diese Werkzeuge wichtige technische Anforderungen eines modernen NIS-2-Sicherheitskonzepts unterstützen.

Der entscheidende Punkt lautet jedoch:

Nicht die Installation eines Tools macht eine Organisation sicher, sondern der dauerhaft funktionierende Prozess dahinter.

Wer weiß, welche Assets vorhanden sind, Schwachstellen regelmäßig sucht, Logdaten zentral auswertet, Angriffe erkennt, Systeme kontinuierlich überwacht und auf Warnmeldungen tatsächlich reagiert, ist dem Ziel einer belastbaren Sicherheitsorganisation bereits deutlich näher.