# CVE Tracking & Response: Souveräner Umgang mit Schwachstellen

TL;DR / Management Summary Ein Vulnerability Scan (Artikel 343) ist nur der Anfang. Die wahre Herausforderung ist der Management-Prozess danach: Welche Lücke ist in unserer spezifischen Umgebung wirklich gefährlich? Wir lernen, wie wir CVSS-Scores (Common Vulnerability Scoring System) interpretieren, wie wir Sicherheits-Feeds abonnieren und wie wir Mitigations (Zwischenlösungen) implementieren, wenn noch kein offizieller Patch verfügbar ist.

# 1. Einführung & Architektur

Der Schwachstellen-Lebenszyklus.

Sicherheit ist ein Wettlauf gegen die Zeit. Vom Entdecken einer Lücke bis zum Exploit vergehen oft nur Stunden.

# Der Response-Workflow (Mermaid)

graph TD
    A[New CVE Discovery] --> B[Advisory: vendor / mailing list]
    B --> C{Triage: Affects us?}
    C -->|No| D[Record & Ignore]
    C -->|Yes| E[Impact Assessment: CVSS Score]
    E --> F{Patch available?}
    F -->|Yes| G[Deploy Update]
    F -->|No| H[Apply Mitigation: Config / Firewall]
    G --> I[Verification: Re-Scan]
    H --> I

# 2. Die Bewertung: CVSS verstehen

Nicht jede 10 ist eine Katastrophe.

Der CVSS-Score (0.0 - 10.0) bewertet das Risiko. Aber:

• Base Score: Theoretisches Risiko.
• Environmental Score: Risiko in Ihrer Umgebung. (Beispiel: Eine Lücke in Apache ist auf einem Server ohne Apache irrelevant).

# 3. Informationsquellen

Wissen, bevor die Presse schreibt.

Abonnieren Sie die Security-Listen Ihrer Distribution:

• Debian: debian-security-announce
• Red Hat: Red Hat Security Advisories
• SUSE: SUSE Security Announcements

# Abfrage via CLI (RHEL/Rocky)

# Zeigt alle kritischen Sicherheitsmeldungen
sudo dnf updateinfo list security --severity critical

# 4. Day-2 Operations: Virtual Patching

Zeit gewinnen.

Wenn für eine Lücke (z.B. Log4Shell) noch kein Patch da ist, müssen wir den Angriffsvektor blockieren.

• WAF (Web Application Firewall): Blockiert spezifische Muster im HTTP-Traffic.
• SELinux/AppArmor: Entzieht dem Prozess die Rechte, die er für den Exploit bräuchte.
• Firewall: Blockiert den Zugriff auf den betroffenen Port komplett.

# 5. Troubleshooting & “War Stories”

Wenn der Patch die App bricht.

# Story 1: “Der voreilige Hotfix”

Symptom: Ein kritischer Patch für OpenSSL wird sofort ausgerollt. Danach stürzen alle VPN-Server ab. Ursache: Der Patch hat eine veraltete Verschlüsselungsmethode deaktiviert, die das Firmen-VPN noch zwingend benötigte. Lösung: Führen Sie immer eine kurze Risiko-Abwägung durch. Ist der Exploit wahrscheinlicher als der Produktions-Ausfall? Testen Sie Patches auf einem “Canary”-System vor dem globalen Rollout.

# Story 2: “Die vergessene Bibliothek”

Symptom: Alle OS-Pakete sind aktuell, aber ein Audit findet eine uralte, verwundbare libssl in einem Docker-Container. Ursache: Statische Verlinkung oder unkontrollierte Third-Party Images. Lösung: Etablieren Sie eine Software Bill of Materials (SBOM) (siehe Artikel 343). Scannen Sie nicht nur den Host, sondern auch alle Artefakte in der Registry.

# 6. Fazit & Empfehlung

• Zentralisierung: Nutzen Sie den SUSE Manager (Artikel 175) oder Red Hat Insights (Artikel 119), um den CVE-Status Ihrer gesamten Flotte auf einem Dashboard zu sehen.
• Schnelligkeit: Definieren Sie feste Zeiträume für Patching (z.B. “Critical” innerhalb von 24h).
• Wartung: Dokumentieren Sie jede Entscheidung, eine Lücke nicht zu schließen (Risk Acceptance).

# Anhang: Cheatsheet für Triage