Incident-Response-Grundlagen: Der erste Ernstfall

1. Der Incident-Response-Lebenszyklus im Überblick

Ein Incident-Response-Prozess folgt in der Praxis fünf Phasen: Identify, Contain, Eradicate, Recover und Lessons Learned. In der Identify-Phase wird bestätigt, dass es sich tatsächlich um einen Sicherheitsvorfall handelt und nicht um einen harmlosen Fehlalarm. Contain stoppt die weitere Ausbreitung, Eradicate entfernt die eigentliche Ursache, etwa eine Backdoor oder eine kompromittierte Zugangsdaten. Recover bringt Systeme kontrolliert zurück in den Normalbetrieb, und Lessons Learned schließt den Kreis, indem die Erkenntnisse aus dem Vorfall in Prozesse, Monitoring und Schulungen zurückfließen. Die meisten kleinen Entwicklerteams haben diesen Ablauf nie schriftlich festgehalten und improvisieren beim ersten echten Vorfall, was wertvolle Zeit kostet und Fehler begünstigt.

Wichtig ist, dass diese Phasen nicht strikt linear ablaufen. Containment beginnt oft, bevor die Identify-Phase vollständig abgeschlossen ist, weil man nicht warten kann, bis jedes Detail geklärt ist. Eradicate und Recover können sich mehrfach abwechseln, etwa wenn nach der ersten Bereinigung ein zweiter Persistenzmechanismus auffällt. Lessons Learned ist kein optionaler Abschlusspunkt, sondern speist direkt wieder in die Vorbereitung für den nächsten Vorfall ein, etwa durch neue Monitoring-Regeln oder aktualisierte Kontaktlisten.

2. Containment zuerst: Warum Eindämmung vor der vollständigen Untersuchung kommt

Ein weit verbreiteter Reflex im ersten Schreck ist, sofort tief in die Analyse einzusteigen: Logs durchsuchen, Ursache verstehen, jedes Detail rekonstruieren, bevor irgendetwas verändert wird. Genau das ist gefährlich, denn während die vollständige Untersuchung läuft, bleibt ein Angreifer im System aktiv. Daten werden weiter exfiltriert, ein Angreifer bewegt sich lateral zu weiteren Systemen, oder ein Ransomware-Prozess verschlüsselt zusätzliche Verzeichnisse. Containment hat deshalb immer Vorrang vor vollständiger forensischer Analyse, auch wenn dadurch nicht sofort jedes Detail geklärt ist.

In der Praxis unterscheidet man kurzfristiges und langfristiges Containment. Kurzfristiges Containment bedeutet: kompromittierten Host vom Netzwerk isolieren, betroffene Zugangsdaten sofort sperren, verdächtige Prozesse pausieren statt zu beenden, damit forensische Spuren erhalten bleiben. Langfristiges Containment folgt danach mit sauberen, getesteten Patches und einer überwachten Wiederinbetriebnahme. Der Trick ist, mit minimalem Eingriff maximale Wirkung zu erzielen und dabei den Zustand des Systems für die spätere Analyse so wenig wie möglich zu verändern.

#!/usr/bin/env bash
# containment.sh - Short-term containment actions during an active security incident
# Run this BEFORE full investigation starts. Goal: stop the bleeding, preserve state.
set -euo pipefail

INCIDENT_ID="${1:?Usage: containment.sh INCIDENT-2026-07-12-01}"
EVIDENCE_DIR="/var/incident-response/${INCIDENT_ID}"
mkdir -p "$EVIDENCE_DIR"

echo "[containment] Snapshotting volatile state before anything else changes"
ps auxww > "${EVIDENCE_DIR}/processes.txt"
ss -tunap > "${EVIDENCE_DIR}/network-connections.txt"
who -a > "${EVIDENCE_DIR}/active-sessions.txt"
last -n 50 > "${EVIDENCE_DIR}/recent-logins.txt"

echo "[containment] Copying application and auth logs (read-only, not moved)"
cp -a /var/log/auth.log "${EVIDENCE_DIR}/"
cp -a /var/www/html/var/log/*.log "${EVIDENCE_DIR}/" 2>/dev/null || true

echo "[containment] Revoking all active admin sessions"
mysql magento -e "TRUNCATE admin_user_session;" 2>/dev/null || true

echo "[containment] Blocking outbound traffic to known-bad IP if provided"
if [[ -n "${2:-}" ]]; then
  iptables -I OUTPUT -d "$2" -j DROP
  echo "Blocked outbound to $2" >> "${EVIDENCE_DIR}/actions-taken.log"
fi

echo "[containment] Enabling Magento maintenance mode, allow only responder IP"
php /var/www/html/bin/magento maintenance:enable --ip="${RESPONDER_IP:?}"

echo "[containment] Done. Evidence saved to ${EVIDENCE_DIR}"

3. Beweise sichern: Logs, Snapshots und Chain of Custody

Unter dem Zeitdruck eines aktiven Vorfalls werden Beweise leicht zerstört, meist ohne böse Absicht. Ein Server-Neustart löscht flüchtige Daten wie den Arbeitsspeicherinhalt und aktive Netzwerkverbindungen unwiderruflich. Ein automatischer Log-Rotation-Job überschreibt genau die Datei, die den Angriffszeitpunkt dokumentiert. Ein voreiliger Patch verändert den Systemzustand, bevor jemand ihn dokumentiert hat. Die Reihenfolge ist deshalb entscheidend: zuerst flüchtige Daten sichern, also Prozessliste, Netzwerkverbindungen und Sessions, danach persistente Daten wie Log-Dateien und Datenbank-Snapshots, erst danach Änderungen am System vornehmen.

Chain of Custody bezeichnet die lückenlose, dokumentierte Historie jeder Beweisdatei: wer hat wann worauf zugegriffen, und wie wurde die Integrität nachgewiesen. Ein Prüfsummenvergleich mit SHA-256 direkt nach dem Kopieren belegt, dass die Kopie unverändert ist und im weiteren Verlauf nicht manipuliert wurde. Diese Dokumentation ist nicht nur für eine mögliche spätere Strafanzeige relevant, sondern auch für Cyber-Versicherungen, externe Forensik-Dienstleister und die eigene interne Nachvollziehbarkeit, wenn Monate später Fragen zum Vorfall auftauchen.

#!/usr/bin/env bash
# evidence-preserve.sh - Chain-of-custody log preservation with integrity hashes
# Every access to the evidence directory after this point must be logged manually.
set -euo pipefail

INCIDENT_ID="${1:?Usage: evidence-preserve.sh INCIDENT-2026-07-12-01}"
SOURCE_LOGS=("/var/log/nginx/access.log" "/var/log/nginx/error.log" "/var/www/html/var/log/system.log" "/var/www/html/var/log/exception.log")
EVIDENCE_DIR="/var/incident-response/${INCIDENT_ID}/logs"
CUSTODY_LOG="/var/incident-response/${INCIDENT_ID}/chain-of-custody.log"

mkdir -p "$EVIDENCE_DIR"

log_custody() {
  printf '%s | %s | %s | %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$(whoami)" "$1" "$2" >> "$CUSTODY_LOG"
}

for src in "${SOURCE_LOGS[@]}"; do
  [[ -f "$src" ]] || continue
  dest="${EVIDENCE_DIR}/$(basename "$src").$(date -u +%Y%m%d%H%M%S)"
  cp -a "$src" "$dest"
  chmod 440 "$dest"
  sha256sum "$dest" >> "${EVIDENCE_DIR}/checksums.sha256"
  log_custody "COPY" "$src -> $dest"
done

echo "[evidence] Verifying checksums immediately after copy"
sha256sum -c "${EVIDENCE_DIR}/checksums.sha256"
log_custody "VERIFY" "checksums.sha256 validated"

echo "[evidence] Evidence sealed. Any further access must call log_custody manually."

4. Schweregrad-Klassifizierung und Eskalationspfade

Ohne feste Schweregradstufen diskutiert ein Team im Ernstfall zunächst darüber, wie ernst die Lage überhaupt ist, statt zu handeln. Eine einfache vierstufige Klassifizierung von SEV1 bis SEV4 reicht für die meisten kleinen Teams aus: SEV1 für bestätigten Datenverlust oder kompletten Produktionsausfall, SEV2 für aktive Ausnutzungsversuche ohne bestätigten Datenverlust, SEV3 für automatisch abgewehrte, aber prüfungswürdige Auffälligkeiten, und SEV4 für Findings ohne unmittelbare Auswirkung. Jede Stufe bekommt eine feste Reaktionszeit und eine feste Eskalationsliste, damit im Ernstfall niemand erst überlegen muss, wen er informieren darf.

Ein definierter Eskalationspfad mit On-Call-Rotation ist besonders wichtig, weil die meisten ernsten Vorfälle außerhalb der Kernarbeitszeit auffallen, oft nachts oder am Wochenende. Ohne klaren Pfad geht wertvolle Zeit verloren, weil niemand weiß, wer die Befugnis hat, produktive Systeme abzuschalten oder externe Dienstleister zu beauftragen. Eine feste Eskalationskette mit Timeout, etwa automatische Weiterleitung an die nächste Ebene nach 30 Minuten ohne Reaktion, verhindert, dass ein Vorfall unbemerkt liegen bleibt.

{
  "severity_levels": {
    "SEV1": {
      "definition": "Confirmed data breach or full production outage",
      "response_time_minutes": 15,
      "notify": ["on_call_engineer", "cto", "dpo", "legal_counsel"],
      "escalation_after_minutes": 30
    },
    "SEV2": {
      "definition": "Active exploitation attempt, no confirmed data loss yet",
      "response_time_minutes": 30,
      "notify": ["on_call_engineer", "tech_lead"],
      "escalation_after_minutes": 60
    },
    "SEV3": {
      "definition": "Suspicious activity, contained automatically, needs review",
      "response_time_minutes": 240,
      "notify": ["tech_lead"],
      "escalation_after_minutes": 480
    },
    "SEV4": {
      "definition": "Low-risk finding, no immediate customer impact",
      "response_time_minutes": 1440,
      "notify": ["security_backlog"],
      "escalation_after_minutes": null
    }
  },
  "contacts": {
    "on_call_engineer": { "channel": "pagerduty", "rotation": "weekly" },
    "cto": { "channel": "phone", "backup": "deputy_cto" },
    "dpo": { "channel": "email", "sla_minutes": 60 },
    "legal_counsel": { "channel": "email", "sla_minutes": 120 }
  }
}

5. Kommunikationsplan: Wer muss wann informiert werden

Interne Kommunikation braucht während eines Vorfalls einen einzigen definierten Kanal als verlässliche Informationsquelle, etwa einen dedizierten Incident-Channel. Parallele Diskussionen in privaten Chats oder E-Mail-Threads führen dazu, dass wichtige Entscheidungen an verschiedenen Stellen getroffen werden und niemand mehr den vollständigen Überblick hat. Der Incident Commander entscheidet über Maßnahmen, der Tech Lead setzt sie um, und ein Comms Lead sammelt alle Fakten für spätere externe Kommunikation. Diese Rollentrennung verhindert, dass technische Personen gleichzeitig Statusupdates schreiben und Systeme reparieren müssen.

Externe Kommunikation, besonders gegenüber Kunden, sollte ehrlich, zeitnah und durch eine einzige benannte Person erfolgen, nicht durch mehrere Teammitglieder mit unterschiedlichen Formulierungen. Spekulationen über Ursache oder Umfang gehören nicht in eine erste Kundenmitteilung, solange sie nicht bestätigt sind. Rechtsberatung sollte öffentliche Statements idealerweise vor der Veröffentlichung prüfen, gerade wenn personenbezogene Daten betroffen sein könnten, weil unpräzise Formulierungen später zu zusätzlichen Haftungsrisiken führen können.

6. Rechtliche Meldepflichten: DSGVO Art. 33/34 und die 72-Stunden-Frist

Nach Art. 33 DSGVO muss eine Verletzung des Schutzes personenbezogener Daten der zuständigen Aufsichtsbehörde grundsätzlich innerhalb von 72 Stunden gemeldet werden, nachdem der Verantwortliche davon Kenntnis erlangt hat, es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten betroffener Personen. Entscheidend ist der Moment des "Kenntniserlangens", nicht der Moment, in dem alle Details geklärt sind. Die Uhr läuft also bereits, während Containment und erste Beweissicherung noch laufen, und eine unvollständige, aber fristgerechte Meldung ist besser als eine vollständige, aber verspätete.

Art. 34 DSGVO verlangt zusätzlich die Benachrichtigung der betroffenen Personen selbst, wenn ein hohes Risiko für ihre Rechte und Freiheiten besteht, etwa bei kompromittierten Passwörtern oder Zahlungsdaten. Die Meldung an die Behörde darf explizit stufenweise erfolgen: eine erste Meldung mit den zu diesem Zeitpunkt bekannten Informationen, gefolgt von Ergänzungen, sobald weitere Fakten vorliegen. Wichtig ist außerdem die Dokumentationspflicht nach Art. 33 Abs. 5: Auch Vorfälle, die nicht gemeldet werden, weil kein Risiko besteht, müssen intern dokumentiert werden, inklusive der Begründung für diese Einschätzung.

7. Sofortmaßnahmen im Magento-Kontext: Admin-Lockdown

Bei einem Verdacht auf kompromittierte Admin-Zugänge in einem Magento-Shop gehören mehrere Schritte in die ersten Minuten: Wartungsmodus mit IP-Allowlist aktivieren, damit nur das Response-Team Zugriff behält, alle aktiven Admin-Sessions in admin_user_session invalidieren, sämtliche Admin-Passwörter zurücksetzen und alle API-Integrationstoken rotieren. Parallel sollte geprüft werden, ob unbekannte Admin-Benutzer angelegt wurden, ob geplante Cronjobs verändert wurden, und ob unerwartete Observer, Plugins oder Module im System registriert sind, die als Persistenzmechanismus dienen könnten.

Nach der ersten Sperrung folgt ein Abgleich des Codestands gegen eine bekannte, saubere Referenz, etwa per git diff gegen den letzten vertrauenswürdigen Deployment-Commit oder ein Composer-Lockfile-Vergleich. Erst wenn dieser Abgleich abgeschlossen und die Ursache identifiziert ist, sollte der Wartungsmodus wieder deaktiviert werden. Ein zu früh aufgehobener Lockdown ist einer der häufigsten Gründe, warum ein Angreifer über einen zweiten, unentdeckten Zugang zurückkehrt.

<?php

declare(strict_types=1);

namespace Mironsoft\IncidentResponse\Console\Command;

use Magento\Framework\App\MaintenanceMode;
use Magento\Security\Model\AdminSessionsManager;
use Magento\User\Model\ResourceModel\User\CollectionFactory;
use Symfony\Component\Console\Command\Command;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Output\OutputInterface;

/**
 * CLI command to lock down the Magento admin area during an active incident.
 * Enables maintenance mode, kills all active admin sessions and disables
 * every admin user except the responder account passed via --keep-user.
 */
class LockdownCommand extends Command
{
    /**
     * @param MaintenanceMode $maintenanceMode Toggles storefront maintenance mode.
     * @param AdminSessionsManager $sessionsManager Manages active admin sessions.
     * @param CollectionFactory $userCollectionFactory Loads admin user records.
     */
    public function __construct(
        private readonly MaintenanceMode $maintenanceMode,
        private readonly AdminSessionsManager $sessionsManager,
        private readonly CollectionFactory $userCollectionFactory
    ) {
        parent::__construct('incident:lockdown');
    }

    /**
     * Executes the lockdown: maintenance mode, session kill, admin disable.
     *
     * @param InputInterface $input CLI input, expects --keep-user option.
     * @param OutputInterface $output CLI output for status messages.
     * @return int Exit code, 0 on success.
     */
    protected function execute(InputInterface $input, OutputInterface $output): int
    {
        $keepUser = (string) $input->getOption('keep-user');

        $this->maintenanceMode->set(true, ['127.0.0.1']);
        $output->writeln('<info>Maintenance mode enabled.</info>');

        $collection = $this->userCollectionFactory->create();
        foreach ($collection as $user) {
            if ($user->getUserName() === $keepUser) {
                continue;
            }
            $user->setIsActive(0);
            $user->save();
            $output->writeln(sprintf('<comment>Disabled admin user: %s</comment>', $user->getUserName()));
        }

        // Invalidate every active admin session, including the ones we just disabled
        $this->sessionsManager->processLogout();
        $output->writeln('<info>All admin sessions invalidated.</info>');

        return Command::SUCCESS;
    }
}

8. Ein leichtgewichtiges Incident-Response-Plan-Template für kleine Teams

Ein Incident-Response-Plan muss nicht hundert Seiten umfassen, um wirksam zu sein. Für ein kleines Entwicklerteam reicht ein einseitiges Dokument mit vier Elementen: klar benannte Rollen (Incident Commander, Tech Lead, Comms Lead, Datenschutzbeauftragter), die Schweregrad-Matrix aus Abschnitt 4, eine aktuelle Kontaktliste inklusive Vertretungsregelung, und eine Checkliste für die ersten 30 Minuten. Entscheidend ist, dass dieses Dokument im Ernstfall tatsächlich auffindbar ist, auch wenn Chat-Tools oder das interne Wiki gerade nicht erreichbar sind, etwa weil der Vorfall genau diese Systeme betrifft.

Der Plan gehört idealerweise als Markdown-Datei ins Repository, zum Beispiel als SECURITY_INCIDENT_RESPONSE.md, versioniert wie jeder andere Code, und zusätzlich als ausgedrucktes Exemplar griffbereit. Eine quartalsweise Überprüfung stellt sicher, dass Kontaktdaten aktuell bleiben und neue Teammitglieder ihre Rolle kennen. Der Plan sollte zudem direkt auf die Skripte aus den vorherigen Abschnitten verweisen, damit im Ernstfall niemand erst nach dem richtigen Befehl suchen muss.

{
  "plan_name": "Lightweight Incident Response Plan",
  "last_reviewed": "2026-07-12",
  "roles": {
    "incident_commander": "Decides on containment actions, owns the timeline",
    "tech_lead": "Executes technical containment and eradication steps",
    "comms_lead": "Owns internal and external communication, drafts customer notice",
    "dpo": "Assesses GDPR notification duty, owns authority reporting"
  },
  "first_30_minutes": [
    "Confirm the incident is real, assign an incident commander",
    "Open a dedicated incident channel, stop discussing it elsewhere",
    "Classify severity using severity-communication-matrix.json",
    "Start short-term containment, do not begin deep investigation yet",
    "Start the evidence-preserve.sh log preservation script"
  ],
  "escalation_contacts": [
    { "role": "on_call_engineer", "method": "pagerduty" },
    { "role": "cto", "method": "phone" },
    { "role": "dpo", "method": "email" },
    { "role": "hosting_provider", "method": "support_ticket" }
  ],
  "post_incident": [
    "Schedule blameless post-mortem within 5 business days",
    "Document root cause and timeline",
    "File action items with owner and due date",
    "Update this plan if gaps were found"
  ]
}

9. Tabletop-Übungen und Post-Mortems: Aus dem Vorfall lernen

Eine Tabletop-Übung ist ein simuliertes Szenario, das am Konferenztisch durchgespielt wird, ohne dass reale Systeme angefasst werden: "Ein Angreifer hat gültige Admin-Zugangsdaten erbeutet, was tut ihr in den ersten 15 Minuten." Solche Übungen decken zuverlässig Lücken auf, etwa veraltete Telefonnummern in der Eskalationsliste, unklare Zuständigkeiten oder fehlendes Wissen über den Speicherort der Skripte aus Abschnitt 2 und 3. Zwei bis vier Übungen pro Jahr reichen für ein kleines Team aus, sollten aber realistische, auf die eigene Infrastruktur zugeschnittene Szenarien nutzen statt generischer Beispiele.

Nach einem echten Vorfall gehört ein blameless Post-Mortem zum festen Ablauf, idealerweise innerhalb von fünf Werktagen, solange Details noch frisch sind. Blameless bedeutet ausdrücklich, dass die Frage "wer hat den Fehler gemacht" durch "was im System oder Prozess hat den Fehler ermöglicht" ersetzt wird, weil das Team sonst beim nächsten Vorfall eher verschweigt als meldet. Ein sauberes Post-Mortem enthält eine minutengenaue Timeline, die Grunddursache, und konkrete Maßnahmen mit Verantwortlichem und Termin, die anschließend tatsächlich nachverfolgt werden.

Jede der neun Phasen greift ineinander: Ohne klaren Lebenszyklus gibt es keine Grundlage für Containment-Entscheidungen, ohne gesicherte Beweise keine belastbare Ursachenanalyse, und ohne dokumentierten Post-Mortem wiederholt sich derselbe Fehler beim nächsten Vorfall. Die folgende Tabelle stellt typische Reflexe im Ernstfall den empfohlenen Reaktionen gegenüber.

10. Zusammenfassung

Die Incident-Response-Grundlagen lösen ein Kernproblem: Ohne vorbereiteten Prozess wird der erste echte Sicherheitsvorfall zur improvisierten Krise mit vermeidbaren Fehlern. Der Lebenszyklus aus Identify, Contain, Eradicate, Recover und Lessons Learned gibt eine klare Reihenfolge vor, wobei Containment bewusst vor der vollständigen Untersuchung steht, um weiteren Schaden zu verhindern. Chain of Custody und sauber dokumentierte Log-Preservation sichern die Grundlage für spätere Analyse, Versicherungsfragen und mögliche rechtliche Schritte.

Eine feste Schweregrad-Klassifizierung mit klaren Eskalationspfaden verhindert, dass im Ernstfall wertvolle Zeit mit Zuständigkeitsfragen verloren geht. Die DSGVO-Meldefrist von 72 Stunden nach Art. 33 verlangt frühzeitiges Handeln statt Perfektionismus, und ein leichtgewichtiges, versioniertes Plan-Template macht all das für kleine Teams tatsächlich umsetzbar. Regelmäßige Tabletop-Übungen und blameless Post-Mortems schließen den Kreis und sorgen dafür, dass jeder Vorfall das Team ein Stück widerstandsfähiger macht.

11. FAQ: Incident-Response-Grundlagen: Der erste Ernstfall