Betriebskonzept Schwachstellen-Überwachung (Trivy)

1. Zweck

Jeder Server wird jede Nacht auf bekannte Sicherheitslücken in seinen Anwendungen geprüft. Gemeldet wird nur, wo gehandelt werden kann: wenn der Hersteller eine korrigierte Fassung bereitstellt, oder wenn eine Lücke so lange offen ist, dass über die Anwendung selbst entschieden werden muss.

2. Was geprüft wird

3. Ablauf

1. Jede Nacht um 2:30 Uhr lädt Trivy die aktuelle Schwachstellen-Datenbank.
2. Container und Verzeichnisse werden ohne Netzverbindung und nur lesend geprüft.
3. Bei Containern mit kritischen Lücken prüft Trivy, ob das aktuelle Image des Herstellers unter derselben Bezeichnung die Lücken behebt.
4. Die Zahlen gehen an Zabbix (Alarme), die Einzelheiten an Wazuh (jede Lücke einzeln).

4. Alarmregel und Reaktion

Infrastruktur-Container (z. B. Datenbanken, Reverse Proxy), die nachts automatisch aktualisiert werden, lösen keine Alarme aus.

5. Absicherung des Scanners selbst

• Trivy läuft in einer festen Version: als Container per Digest, ohne Docker per Programm mit kontrollierter Prüfsumme. Ein Update von Trivy gibt es nur über eine Freigabe.
• Prüfungen laufen ohne Netz und nur lesend, der Scanner erhält keinen Zugriff auf Docker selbst.
• Keine Nutzungsdaten an den Hersteller (Telemetrie abgeschaltet), kein Durchsuchen nach Passwörtern oder Schlüsseln.

6. Änderungen und Freigabe

1. Verteilt wird ausschließlich per Ansible (playbooks/setup_security_monitoring.yml), nie von Hand auf einzelnen Servern.
2. Jede Änderung wird zuerst in einem Testzweig auf zwei Servern geprüft.
3. Erst nach bestandener Prüfung kommt sie in den freigegebenen Stand und wird gruppenweise verteilt.
4. Das Playbook bricht ab, wenn Voraussetzungen fehlen, und läuft nur mit gezielter Server-Auswahl.

7. Voraussetzungen je Server

• Wazuh-Agent installiert (auf dem Wazuh-Server: Manager)
• Docker oder Internetzugang zu GitHub für die Installation des Programms
• Mindestens 3 GB frei für die Datenbanken von Trivy
• Template „Template Security Trivy“ in Zabbix verknüpft

8. Grenzen

• Für Anwendungen ohne Docker, für selbst gebaute Images und für Images mit fest eingetragenem Digest kann Trivy nicht prüfen, ob der Hersteller einen Fix hat. Dort gibt es keinen HIGH-Alarm, nur die Warnung nach 30 Tagen.
• Anwendungen außerhalb von /opt und /var/www werden nicht geprüft. [Hier abweichende Installationsorte des Kunden eintragen]
• Öffentliche Registries begrenzen Abrufe ohne Anmeldung. Ist die Grenze erreicht, meldet der Scan einen Fehler, die Herstellerprüfung fehlt dann für diese Nacht.

9. Kurzreferenz auf dem Server

Scan von Hand starten, unabhängig von der SSH-Verbindung: systemd-run --unit=trivy-manual --collect /usr/local/bin/security-scan.sh