IT-Sicherheit

Schwachstellenmanagement: finden, bewerten, schließen

Schwachstellenmanagement ist der Kreislauf, der dafür sorgt, dass bekannte Sicherheitslücken in der eigenen Infrastruktur geschlossen werden – bevor sie ausgenutzt werden. Der schwierige Teil ist nicht das Finden, sondern das Schließen.

\n

Der Kreislauf

\n
1) ERFASSEN     Was laeuft bei uns? (Inventar!)\n                Ohne Inventar kein Schwachstellenmanagement.\n                Unbekannte Systeme koennen nicht gehaertet werden.\n\n2) PRUEFEN      Abgleich gegen bekannte Luecken\n                (Schwachstellenscanner, Paketquellen,\n                 Herstellermeldungen)\n\n3) BEWERTEN     Wie gefaehrlich? Ausnutzbar? Erreichbar?\n                Nicht jede Luecke ist ein Notfall - aber\n                jede muss eingeordnet werden.\n\n4) PRIORISIEREN Nach Risiko, nicht nach Punktzahl.\n                Ein einfacher Wert allein reicht nicht.\n\n5) SCHLIESSEN   Aktualisieren, umgehen, abschalten,\n                Netzsegmentierung. Es MUSS eine Handlung\n                geben - "wird beobachtet" ist keine.\n\n6) PRUEFEN      Wirklich geschlossen? Nachmessen!\n                Ein abgebrochenes Update hinterlaesst ein\n                System, das als erledigt gilt und es nicht ist.\n\nDer Kreislauf ist STETIG, nicht jaehrlich. Ein\nEinmal-Jahres-Projekt ist ein Sicherheitsloch mit\nGeschaeftsplan.
\n

Bewertung: nicht nur die Punktzahl

\n
Verbreitete Kennzahlen:\n  CVSS (Basiswert 0-10)    Schwere der Luecke AN SICH\n  EPSS (0-1)               Wahrscheinlichkeit der Ausnutzung\n                           in den naechsten 30 Tagen\n  KEV-Liste                Nachweislich ausgenutzt (CISA)\n  Exploit verfuegbar?      Oeffentlicher Angriffscode da?\n\nDie wichtigste Erkenntnis: CVSS allein fuehrt in die Irre.\n  Beispiel: Eine Luecke mit CVSS 9,8 in einer Bibliothek,\n  die nur eine Testschnittstelle betrifft, die nicht\n  erreichbar ist, hat ein VIEL geringeres Risiko als\n  eine mit 6,5, die uebers Internet erreichbar ist und\n  bereits ausgenutzt wird.\n\nBewertung IMMER mit dem eigenen Kontext:\n  1) Ist die betroffene Komponente ueberhaupt installiert?\n  2) Ist sie aus dem Internet erreichbar?\n  3) Ist die anfaellige Funktion erreichbar (nicht nur\n     vorhanden)?\n  4) Braucht man dafuer Rechte?\n  5) Gibt es bereits Angriffscode?\n  6) Wie viele Systeme sind betroffen?\n  7) Was waere der Schaden (Daten, Ausfall, Reputation)?\n  8) Schwierigkeit der Behebung (mit und ohne Ausfallzeit)\n\nRisikoklassen mit Fristen (Beispiel, an eigene Umgebung anpassen):\n  KRITISCH   ausnutzbar, aus dem Internet erreichbar,\n             Ausnutzung bekannt ODER EPSS hoch\n             -> 24-48 Stunden\n  HOCH       ausnutzbar, aber nur intern\n             -> 7 Tage\n  MITTEL     erreichbar mit Einschraenkungen\n             -> 30 Tage\n  NIEDRIG    nicht erreichbar oder nur mit hohen Rechten\n             -> naechster Regelzyklus (90 Tage)\n  INFO       keine Auswirkung\n             -> zur Kenntnis, dokumentiert\n\nWICHTIG: Die Klassifizierung muss NACHVOLLZIEHBAR sein.\n  Bei einem Vorfall fragt jemand, warum eine Luecke\n  nicht geschlossen wurde. Dann braucht es eine\n  dokumentierte Begruendung.
\n

Prüfen: Werkzeuge und Grenzen

\n
# Paketquellen der Systeme (die wichtigste Quelle ueberhaupt)\napt list --upgradable\ndnf check-update\n#   Der schnellste Weg: Die Distribution liefert\n#   Sicherheitsinformationen mit.\n\n# Nur Sicherheitsaktualisierungen\napt-get -s install --only-upgrade $(apt list --upgradable 2>/dev/null | ...)\ndnf updateinfo list security\n\n# Verwaiste Pakete (wird nicht mehr gepflegt = keine Korrekturen!)\napt list --installed 2>/dev/null | grep -i '^.*deinstall'\ndebsums -c | head\n\n# Container-Abbilder\ntrivy image --severity HIGH,CRITICAL app:1.0.0\ntrivy fs --scanners vuln,secret,misconfig .\ndocker scout cves app:1.0.0\n\n# Abhaengigkeiten der Anwendung\nnpm audit --omit=dev\npip-audit\ngovulncheck ./...\ncargo audit\n\n# Schwachstellenscanner (Netzebene)\n#   OpenVAS/Greenbone, Nessus, Nuclei\n#   WICHTIG: Nur mit Erlaubnis und im vereinbarten Fenster!\n#   Ein Scanner kann Dienste zum Absturz bringen - und\n#   ohne Auftrag ist es ein Angriff.\n\n# Was Scanner NICHT finden:\n#   - Fehlkonfigurationen ohne CVE (offene Speicher,\n#     Standardpasswoerter, freigegebene Verzeichnisse)\n#   - Fehler in eigener Software\n#   - Berechtigungsprobleme (IDOR)\n#   - Fehlende Protokollierung\n#   -> Deshalb braucht es zusaetzlich Konfigurationspruefung\n#      und Handpruefung. Ein Scanner ist kein Sicherheitstest.
\n

Schließen: der harte Teil

\n
Es gibt vier Wege mit einer Luecke umzugehen.\nNur "aktualisieren" ist oft nicht moeglich - dann\nmuss trotzdem eine Handlung die Folge sein:\n\n1) BEHEBEN\n   Paket aktualisieren, Abhaengigkeit anheben, Code korrigieren.\n   # Regelzyklus einplanen! Sonst bleiben Aktualisierungen\n   # Monate liegen. Offene Fenster sind billiger als\n   # vierstuendige Nachtschichten.\n\n2) UMGEHEN (wenn kein Update verfuegbar ist)\n   - Anfaellige Funktion abschalten\n   - Zugriff auf vertrauenswuerdige Netze begrenzen\n   - Nachfragefilter (Web Application Firewall): eine Regel\n     gegen das bekannte Angriffsmuster\n   - Werkzeug/Parameter nicht verwenden\n   # UMGEHUNGEN HABEN EIN ABLAUFDATUM! Sonst bleiben sie\n   # fuer immer und werden selbst zum Risiko.\n\n3) ABSCHALTEN\n   Wenn die Komponente nicht gebraucht wird: entfernen.\n   Die einzige vollstaendige Behebung. Die billigste\n   Sicherheitsmassnahme ueberhaupt: weniger installieren.\n\n4) AKZEPTIEREN (dokumentiert!)\n   Mit Begruendung, Bewertung, Verantwortlichem und\n   Ueberpruefungstermin.\n   # Nicht "wird beobachtet" ohne Termin und Namen!\n\nGehoert ins Ticket:\n  Komponente, Version, Lueckenkennung, Bewertung,\n  gewaehlter Weg, Verantwortlicher, Frist, Status\n  # Und: der Nachweis der Schliessung (Version nach\n  # dem Update gemessen!)
\n

Prüfliste

\n
    \n
  1. Existiert ein Inventar der Systeme, Dienste und Abhängigkeiten?
    2. \n
  2. Läuft die Prüfung automatisch (nicht manuell angestoßen)?
    3. \n
  3. Sind Fristen nach Risikoklasse definiert und bekannt?
    4. \n
  4. Werden Priorisierungen dokumentiert (nicht nur „getan“)?
    5. \n
  5. Gibt es einen festen Regelzyklus für Aktualisierungen?
    6. \n
  6. Haben Umgehungen ein Ablaufdatum?
    7. \n
  7. Wird die Schließung nachgemessen (Version, Prüfung erneut)?
    8. \n
  8. Sind die Ergebnisse für Nicht-Fachleute berichtbar (Kennzahlen, Verlauf)?
    9. \n
  9. Sind verwaiste Pakete und ungepflegte Bibliotheken im Blick?
    10. \n
  10. Wird der Umgang mit einer Schwachstelle einmal geübt?
    11. \n
\n

Häufige Fehler

\n
    \n
  1. Kein Inventar. Man kann nicht schützen, was man nicht kennt. Der häufigste Grund, warum eine Lücke lange offen bleibt.
    2. \n
  2. Nur nach Punktzahl priorisieren. Die unerreichbare Lücke mit 9,8 vor der ausgenutzten mit 6,5 zu bearbeiten kostet Zeit und bringt nichts.
    3. \n
  3. Kein Regelzyklus. Sicherheitsaktualisierungen sammeln sich an; irgendwann ist es ein Projekt mit Ausfallzeit.
    4. \n
  4. Umgehung ohne Ablaufdatum. Die Nachfragefilterregel bleibt für immer – und niemand weiß mehr, wofür sie da ist.
    5. \n
  5. Ticket geschlossen, System nicht aktualisiert. Ohne erneute Messung ist der Status eine Behauptung.
    6. \n
  6. Nur Betriebssystem, nicht Anwendung. Die Hälfte der Vorfälle kommt über Anwendungsabhängigkeiten und Container-Abbilder.
    7. \n
  7. Scanner als vollständige Prüfung. Fehlkonfigurationen und Berechtigungsfehler findet kein Schwachstellenscanner.
    8. \n
  8. Aktualisierung ohne Test. Ein Sicherheitsupdate kann die Anwendung brechen. Tests, dann ausrollen – aber zügig.
    9. \n
  9. Keine Rückfallebene. Bei kritischen Systemen vor dem Update eine Momentaufnahme. Sonst wird aus einem Sicherheitsereignis ein Ausfall.
    10. \n
\n

Verwandte Grundlagen: Patch-Management, Threat Modeling, Vorfallbehandlung, Zero-Day.