Vorfallbehandlung: die erste Stunde entscheidet

Vorfallbehandlung (Incident Response) entscheidet darüber, ob aus einem Sicherheitsvorfall ein Schaden wird oder eine beherrschbare Störung. Die entscheidenden Schritte finden statt, bevor etwas passiert.

Die Phasen

1) VORBEREITUNG        (vor dem Vorfall!)
   Zustaendigkeiten, Kontaktwege, Werkzeuge, Zugriffsrechte,
   Sicherungen, Uebungen

2) ERKENNUNG
   Was ist passiert? Alarm, Meldung, Auffaelligkeit?
   Erste Einschaetzung: Echt oder Fehlalarm?

3) EINDAEMMUNG
   Ausbreitung stoppen. Zeitkritisch!
   Netz trennen, Konto sperren, Dienst stoppen.
   VORSICHT: Nicht die Beweise vernichten!

4) UNTERSUCHUNG
   Wie kam es dazu? Was ist betroffen? Was ist abgeflossen?
   Zeitraum bestimmen.

5) BEHEBUNG
   Luecke schliessen, Systeme neu aufsetzen (nicht "reinigen"),
   Kennwoerter wechseln

6) WIEDERHERSTELLUNG
   Dienste zurueck, ueberwacht, in Stufen

7) NACHBEREITUNG
   Was lernen wir? Massnahmen mit Verantwortlichen und Fristen.
   Ohne diesen Schritt passiert derselbe Vorfall wieder.

WICHTIG: Die Reihenfolge ist NICHT verhandelbar.
  Wer sofort "repariert" und neu startet, verliert
  die Beweise - und weiss danach nicht, ob der
  Angriff noch aktiv ist.

Die erste Stunde

Diese Schritte gehoeren auf ein Blatt, das jeder findet.
Nicht in ein Handbuch auf Seite 40.

1) RUHE BEWAHREN UND NICHT ABSCHALTEN
   # Ein abgeschaltetes System verliert den Inhalt des
   # Arbeitsspeichers - dort steckt oft der Schadcode.
   # Und die Angreifer merken, dass sie entdeckt sind.

2) MELDEN UND ENTSCHEIDEN
   Wer ist benachrichtigt? Wer entscheidet?
   # Eine Person muss die Leitung haben - nicht ein Gremium.
   # Bei personenbezogenen Daten: Datenschutzbeauftragter
   # und gegebenenfalls Meldepflicht (72 Stunden nach DSGVO!)

3) BEWEISE SICHERN, BEVOR SIE VERSCHWINDEN
   # Schnell und fluechtig (in dieser Reihenfolge!)
   # 1. Arbeitsspeicher
   # 2. Netzverbindungen (ss -tanp), ARP, Routing
   # 3. Prozessliste, geladene Module
   # 4. Angemeldete Nutzer (who, last)
   # 5. Zeitgeber, geplante Aufgaben
   # 6. Dateien mit Zeitstempeln
   # 7. Protokolle (insbesondere nach ausserhalb kopieren!)
   #
   # Alles mit Zeitstempel und Pruefsumme dokumentieren.
   # Wer ein Beweisstueck anfasst, vermerkt es.

4) EINDAEMMEN
   # Netz trennen (nicht abschalten!) oder Ports sperren
   # Konten sperren (Kennwoerter wechseln!)
   # Dienst stoppen, wenn noetig
   # VORSICHT: Ausbreitung auf weitere Systeme pruefen,
   # bevor man sich beruhigt.

5) BEFALLENE SYSTEME IDENTIFIZIEREN
   # Ein Angreifer hinterlaesst selten nur eine Spur.
   # Alle Systeme mit denselben Kennwoertern/Schluesseln
   # sind als betroffen zu behandeln.

6) DOKUMENTIEREN (von Anfang an!)
   # Zeit, Beobachtung, Massnahme, Person
   # Auch Fehler und Unsicherheiten. Die Dokumentation
   # wird spaeter gebraucht - fuer die Nachbereitung,
   # fuer Versicherungen, fuer Meldungen.

Beweissicherung: was zählt

# Der wichtigste Grundsatz: REIHENFOLGE nach Fluechtigkeit.
#   Was wenige Minuten ueberlebt, wird zuerst gesichert.

# 1. Arbeitsspeicher (verschwindet beim Neustart)
#    Werkzeuge: LiME, AVML, fmem (oder Hypervisor-Momentaufnahme)
#    WICHTIG: NICHT mit dem System selbst arbeiten - das
#    ueberschreibt den Speicher mit eigenen Werkzeugen.
#    Besser: Momentaufnahme der virtuellen Maschine, dann
#    die Kopie untersuchen.

# 2. Netzwerk und Verbindungen
ss -tanp > /sicherung/verbindungen.txt
ss -ulnp >> /sicherung/verbindungen.txt
arp -an >> /sicherung/arp.txt
ip route show >> /sicherung/routen.txt
#   Suche nach: ausgehenden Verbindungen zu unbekannten Zielen,
#   lauschenden Ports, die niemand kennt

# 3. Prozesse (kann nur Minuten alt sein)
ps auxwwf > /sicherung/prozesse.txt
ls -l /proc/*/exe > /sicherung/prozess_binaerdateien.txt
lsof -nP > /sicherung/offene_dateien.txt
cat /proc/*/cmdline | tr '\0' ' ' > /sicherung/prozess_argumente.txt

# 4. Angemeldete Nutzer und Sitzungen
who -a > /sicherung/nutzer.txt
last -F >> /sicherung/nutzer.txt
lastb -F >> /sicherung/nutzer.txt

# 5. Zeitgeber und automatische Aufgaben
crontab -l > /sicherung/cron_root.txt
ls -la /etc/cron.*/ >> /sicherung/cron_root.txt
systemctl list-timers --all > /sicherung/timer.txt
ls -la /etc/systemd/system/ >> /sicherung/systemd.txt

# 6. Dateien und Zeitstempel
find / -xdev -newermt '-7 days' -la > /sicherung/neu.txt 2>/dev/null
find / -xdev -mtime -7 -type f -printf '%T@ %p\n' | sort -rn | head -200

# 7. Protokolle - WICHTIG: nach AUSSEN kopieren!
#    Ein Angreifer loescht die Protokolle auf dem System.
journalctl --since '7 days ago' > /sicherung/journal.txt
cp /var/log/auth.log /sicherung/
#   Und: wenn eine zentrale Protokollablage existiert,
#   DORT suchen. Das ist der eigentliche Wert einer
#   zentralen Protokollierung.

# Pruefsummen, damit spaeter niemand die Echtheit anzweifelt
sha256sum /sicherung/* > /sicherung/pruefsummen.txt

# WICHTIG: Nur LESEN. Keine Updates, keine Bereinigung,
# keine neuen Werkzeuge installieren (ueberschreibt Beweise
# im Arbeitsspeicher und in Dateien!).

Neustart oder Neuaufsetzen?

Die klare Antwort: NEU AUFSETZEN aus einer geprueften
Sicherung. Nicht "reinigen".

Warum:
  - Man weiss nie, ob der Angreifer noch Zugangswege hat
    (zusaetzliche Schluessel, geplante Aufgaben, geaenderte
     Binaries, Hintertueren in Diensten)
  - Eine "gereinigte" Maschine ist eine Vermutung
  - Bei einer Neuinstallation mit geprueften Sicherungen
    ist der Zustand definiert

ABLAUF:
  1) Nachweis: War die Sicherung selbst betroffen?
     (Zeitpunkt! Lag der Kompromittierungsbeginn VOR der
      Sicherung, ist sie unbrauchbar)
  2) System neu aufsetzen (gleiche oder aktuelle Version)
  3) Zugangsdaten ZURUECKSETZEN - nicht mitnehmen!
     Alle Kennwoerter, Schluessel, Zertifikate, Token
     # Ein "sauberes" System mit alten Kennwoertern ist
     # weiter angreifbar.
  4) Aus der geprueften Sicherung Daten zurueckspielen
     (nicht das Betriebssystem, nur Daten)
  5) Dienste in Stufen hochfahren, ueberwacht
  6) Geaenderte Kennwoerter dokumentieren und verteilen
  7) Zwei Wochen verstaerkt beobachten

WAS NICHT ZURUECKGESPIELT WIRD:
  - Betriebssystem und Anwendungsdateien (Neuinstallation)
  - Zugangsdaten, Schluessel, Token (neu erzeugen!)
  - Konfiguration, die verdaechtig erscheint
  - Protokolle (nur als Beweis behalten)

Nachbereitung: der wertvollste Schritt

Innerhalb von zwei Wochen nach Abschluss:

1) Zeitstrahl
   Wann begann die Kompromittierung? Wann wurde sie
   erkannt? Wann eingedaemmt? Wann behoben?
   # Die Zeit von Kompromittierung bis Erkennung ist
   # die wichtigste Zahl. Sie liegt oft bei Monaten.

2) Ursache
   Wie kamen sie hinein? (Kennwort, Luecke, Phishing,
   ungeschuetzter Dienst, Abhaengigkeit, Lieferant)
   # Nicht: "Wer hat Schuld?" - das verhindert ehrliche
   # Antworten. Sondern: Welche Bedingung hat es ermoeglicht?

3) Was hat funktioniert, was nicht?
   - Hat der Alarm ausgeloest? Warum nicht?
   - War der Kontaktweg klar?
   - Gab es die noetigen Rechte/Werkzeuge?
   - War die Sicherung brauchbar? (Getestet?)

4) Massnahmen mit Verantwortlichen und Fristen
   Technisch: Luecke schliessen, Zugriffe entziehen,
   Protokollierung ergaenzen, Netzsegmentierung
   Organisatorisch: Kontaktweg, Uebung, Bereitschaft
   # Nur Massnahmen mit Namen und Datum werden umgesetzt.

5) Uebung
   Einmal halbjaehrlich einen Vorfall durchspielen.
   # Es ist deutlich guenstiger, im Frieden zu ueben.
   # Die Uebung deckt genau die Luecken auf, die im
   # Ernstfall Zeit kosten.

MELDEPFLICHTEN (nicht vergessen!):
  DSGVO:     72 Stunden nach Bekanntwerden bei personenbezogenen
             Daten -> Aufsichtsbehoerde; bei hohem Risiko
             zusaetzlich die Betroffenen
  BSI/BSIG:  bei betriebskritischen Anlagen
  Vertraege: Meldepflichten gegenueber Kunden und Lieferanten
  Versicherung: Schadensmeldung
  # Fristen sind HART. Die Meldung braucht keine vollstaendige
  # Aufklaerung - eine Erstmeldung mit dem bekannten Stand
  # genuegt und kann ergaenzt werden.

Prüfliste

Gibt es einen Notfallplan auf maximal zwei Seiten (nicht in einem Handbuch)?
Sind Zuständigkeiten und Kontaktwege klar (auch nachts, auch am Wochenende)?
Sind Werkzeuge und Zugriffsrechte für die Beweissicherung vorbereitet?
Werden Protokolle zentral gesammelt (nicht nur lokal)?
Ist die flüchtige Reihenfolge der Beweissicherung bekannt und dokumentiert?
Sind die Meldepflichten und Fristen bekannt (DSGVO 72 Stunden)?
Ist eine Wiederherstellung aus Sicherungen getestet?
Gibt es einen Plan für die Neuerstellung von Zugangsdaten?
Wurde in den letzten 12 Monaten geübt?
Werden Nachbereitungen mit Verantwortlichen und Fristen festgehalten?

Häufige Fehler

System abschalten. Der Arbeitsspeicher ist weg – und dort steckt bei modernen Angriffen der Schadcode, der auf der Platte nicht liegt. Netz trennen, nicht ausschalten.
Beweise vernichten durch „Säubern“. rm, Neustart, Installation von Werkzeugen überschreiben Spuren, die man zur Aufklärung braucht.
Zu früh „reparieren“. Erst eindämmen, dann untersuchen. Wer sofort wiederherstellt, weiß nie, ob der Angreifer noch da ist.
Nur das offensichtlich betroffene System behandeln. Ein Angreifer hinterlässt selten eine einzige Spur. Alle Systeme mit denselben Zugangsdaten gelten als betroffen.
Alte Kennwörter wiederverwenden. Ein neu aufgesetztes System mit alten Zugangsdaten ist genauso angreifbar.
Meldepflicht verpassen. 72 Stunden sind hart. Im Vorfallstress ist eine vorbereitete Vorlage Gold wert.
Keine Nachbereitung. Ohne sie wiederholt sich der gleiche Vorfall. Die Zeit von Erkennung bis Kompromittierung sinkt nicht.
Schuldige suchen. Dann berichten Beteiligte nicht mehr ehrlich – und die Ursache bleibt verborgen.
Ungeprüfte Sicherung zurückspielen. Lag der Kompromittierungsbeginn vor der Sicherung, ist der Schadcode wieder drin.

IT-Sicherheit