Anatomie eines erfolgreichen Cyber-Angriffs

1. Angreifer findet oder erfährt von einer ausnutzbaren Schwachstelle
2. Angreifer entwickelt und testet einen Angriff (Exploit)
3. Angreifer identifiziert verwundbare Ziele und greift diese an

Anatomie eines erfolgreich verhinderten Angriffs

1. Person findet eine oder erfährt von einer ausnutzbaren Schwachstelle
2. Person meldet das Problem beim Hersteller/Entwickler
3. Bei Responsible Disclosure sind jetzt 90 Tage Zeit, um das Problem zu beheben und einen Patch zu verteilen
4. Dienstbetreiber erfährt von Schwachstelle
5. Falls zunächst nur effektive Mitigation verfügbar ⇨ Mitigation implementieren und testen
6. Sobald ein Patch verfügbar ist, wird dieser umgesetzt
7. Mitigation wird zurückgenommen oder beibehalten

Kernpunkt für Dienstbetreiber: Wissen über Schwachstellen & maximale Automation

• Fast jede Software-Quelle hat einen Informationskanal zu Updates und Schwachstellen
  • Diese müssen von Dienstbetreibern überwacht werden
• Manche Software und alle großen Betriebssysteme haben einen automatischen Update-Mechanismus
  • Wir empfehlen dringend, diese zu nutzen
  • Bei den allermeisten Diensten gilt "Besser kaputt als gehackt"

Warum ging das bis jetzt einigermaßen gut?

Brave New World

• Seit ca. Ende 2024 (siehe ZeroDayClock) sind KI-Modelle gut genug, um massenhaft funktionierende Schwachstellen & Exploits zu generieren
• Rasanter Anstieg der Zero-Day-Exploits bei gleichzeitiger Reduzierung der Time to Exploit (TTE)
• Finder von Sicherheitslücken mit KI halten sich seltener an Responsible Disclosure oder verkürzen das Non-Disclosure Zeitfenster stark

Was tun bei TTE < 1 Tag (oder < 5min)?

• Automatisch updaten und, wenn nötig, rebooten
• Software-Deployments komplett automatisieren, dann sind Kompromittierungen weniger aufwändig zu beheben
• Angriffsfläche verkleinern und Software + Systeme aktiv überwachen
  • Nur das konfigurieren, was man braucht
  • Sicherheitsfeatures von Software und Betriebssystem umsetzen, auch wenn es Aufwand ist
  • Alerting bei Abweichungen von der Erwartung

Warnungen vom KIT-CERT (1)

• Wir (KIT-CERT) warnen per Mail vor bestimmten Lücken, die wir für besonders gefährlich und relevant für das KIT halten
• Nur, wenn wir es auch mitbekommen
  • keine aktive Überwachung von Kanälen (außer natürlich das, was wir selbst betreiben!)
  • kennen nicht alle eingesetzte Software am KIT
• Formulieren von Warnmails ist sehr zeitaufwändig
  • Bei früher Warnung wenig Informationen ⇨ viel tiefe Recherche nötig
  • Alle Aussagen fact-checken
  • Wenn möglich, Mitigations testen
  • erst dann eine gehaltvolle Mail schreiben

Warnungen vom KIT-CERT (2)

• Bisher: Warnung bei
  • RCE in (wahrscheinlich) am KIT verwendeter Software
  • LPE mit öffentlich bekanntem Exploit
• Bei aktueller Frequenz können und sollten wir das nicht beibehalten (Alert Fatigue)
  • Keine Warnmails mehr bei LPEs, sonst liest das keiner mehr
  • Advisorydienste von Software, die man verwendet, selbst monitoren!

Warnungen vom KIT-CERT (3)

• Angebot: Dem IT-EK-Matrix-Chat beitreten
  • wir posten Sicherheitslücken
    • die vermutlich relevant am KIT sind
    • von denen wir erfahren
  • rein informativ ohne Garantie für
    • Einordnung
    • weitere Recherche
• IT-EK-Chat Beitrittslink für Desktop-Client
• IT-EK-Chat Beitrittslink Browser-Client

Warnungen vom DFN

• security-l: Alle Meldungen des DFN-CERT

Zukunft?