Sicherheits-Problemlösung — InfraGuard-Handbuch

Überblick — was dieser Bildschirm leistet

Sicherheit ▸ Problemlösung steuert die Reaktion auf Sicherheitsvorfälle und Kompromittierungen als ein einziges Fall-Board mit einer fünfstufigen Pipeline:

open → investigating → cause_identified → resolved → closed

Jeder Fall trägt eine 500-Berichtsstruktur (direkte Ursache / Grundursache / Lösung / Präventivmaßnahme) sowie eine auditierbare Zeitleiste. Dieser Bildschirm spiegelt den Controller von Service ▸ Problemlösung: Er nutzt dieselbe Tabelle infr_incident, filtert aber auf area='security', damit Sicherheitsfälle von Service-Vorfällen getrennt bleiben.

Fälle gelangen auf zwei Wegen auf dieses Board:

Manuelle Erfassung — eine Betreiberin oder ein Betreiber legt den Fall an. Wählbare Quellen: manual · agency · quarantine.
Hochstufung aus der Diagnose — Befunde mit fail + crit aus der Sicherheitsdiagnose werden automatisch zu Fällen hochgestuft (source=detection). Dies ist eine reine Systemquelle, die sich nicht von Hand auswählen lässt.

Diese Konsole greift weder auf entfernte crontabs noch auf Firewalls direkt zu. Sie ist ein Workflow-Werkzeug, das den menschlichen Reaktionsprozess dokumentiert und nachverfolgt. Die tatsächlichen Sperr- und Quarantäneaktionen finden Sie unter Sperrliste und Automatische Sperre.

Wann Sie ihn verwenden

Um einen bestätigten Kompromittierungsverdacht aus der IDS-/KI-Erkennung (Bedrohungen, Erkennungen · JA3) in einen formalen Fall mit Untersuchungs- und Lösungsspur hochzustufen.
Um Amtshilfeersuchen oder Vorfallmeldungen einer agency (CERT, Strafverfolgung) nachzuverfolgen.
Um einen Host von der quarantine über die Wiederherstellung bis zur erneuten Inbetriebnahme zu begleiten.
Um Härtungs- und Rootkit-Risiken, die die Sicherheitsdiagnose mit fail+crit markiert hat, als automatisch angelegte Fälle entgegenzunehmen und die weitere Bearbeitung zuzuweisen.
Um im Nachgang MTTR und kumulierte Ausfallzeit zu berechnen und direkte Ursachen, Grundursachen sowie Präventivmaßnahmen zu dokumentieren.

Aufbau

KPI-Leiste

KPI	Definition
total	Gesamtzahl der Fälle mit `area='security'`
active	Summe aus `open + investigating + cause_identified`
resolved	Summe aus `resolved + closed`
MTTR	Durchschnittliche Minuten der Fälle, die sowohl `occurred_at` als auch `resolved_at` besitzen
downtime	Summe von `downtime_min` über alle Fälle
uptime target	`OpsPolicy::slaDefaults()['uptime_target']`

Fall-Board

Die Fälle werden sortiert nach:

Statusrang — open → investigating → cause_identified → resolved → closed
Schweregradrang — crit → warn → info
Neueste zuerst — id absteigend

Jede Karte zeigt Titel, Schweregrad, Status, Quellen-Badge, verknüpftes Projekt bzw. verknüpften Dienst, Eintrittszeitpunkt, Ausfallzeit und Ereignisanzahl.

Detail-Dialog

Beim Öffnen eines Falls teilt sich die Ansicht in zwei Bereiche:

Bericht — Felder für Zusammenfassung, direkte Ursache, Grundursache, Lösung und Präventivmaßnahme.
Zeitleiste — Verlauf aus infr_incident_event (angelegt, Notiz, Statuswechsel, …) in chronologischer Reihenfolge.

Ein Klick auf die Status-Pipeline am oberen Rand öffnet einen Schritt-Übergangsdialog: Er zeigt den Hinweis „Was in dieser Stufe zu tun ist“ und lässt Sie die Berichtsfelder dieser Stufe direkt dort aktualisieren.

Bedienung

Einen Fall anlegen (manuell)

Klicken Sie oben auf [Fall anlegen].
Geben Sie Titel (Pflichtfeld), Schweregrad und Quelle (manual / agency / quarantine) ein.
Optional setzen Sie Projekt, Dienst, URL, Eintrittszeitpunkt, Auswirkung und Ausfallzeit (Minuten).
[Speichern] — es entsteht ein neuer Fall mit status=open, area=security und detected_at=now(), und in die Zeitleiste wird ein Ereignis created geschrieben.

detection wird in der Quellenliste nicht angeboten — es ist eine reine Systemquelle, die die Sicherheitsdiagnose automatisch erzeugt.

Statusübergänge (Pipeline)

Klicken Sie in der Pipeline des Detail-Dialogs auf den Zielstatus. Empfohlene Arbeit je Stufe:

Stufe	Was in dieser Stufe zu tun ist
open	Auf den Eingang zurücksetzen (vor der Analyse)
investigating	Symptome bestätigen, Auswirkung eingrenzen, Zusammenfassung schreiben
cause_identified	Direkte Ursache und Hintergrund- bzw. Grundursache bestimmen und festhalten
resolved	Wiederherstellungsverfahren und Präventivmaßnahme festhalten
closed	Prüfen, dass Maßnahmen und Prävention umgesetzt sind, dann den Fall abschließen

Übergangsregeln auf Serverseite:

Beim Wechsel auf resolved wird resolved_at mit now() gefüllt, sofern es leer war.
Beim Wechsel auf closed wird der im Dialog angegebene Abschlusszeitpunkt verwendet, sofern vorhanden; andernfalls gilt now() als Vorgabe, wenn noch kein Wert existiert.
Ändert sich der Status tatsächlich, wird ein Ereignis status_change (from→to) in die Zeitleiste geschrieben; wird zusätzlich eine Notiz übergeben, entsteht auch ein Ereignis note.

Kollaborationsnotizen

Eine Notiz im Detail-Dialog erzeugt ein Ereignis kind=note auf der Zeitleiste. Es gibt keine eigene Notiztabelle — Notizen sind in infr_incident_event zusammengeführt.

Löschen

Das Löschen eines Falls entfernt auch dessen Zeilen in infr_incident_event und wird ins Audit-Protokoll geschrieben. (Der ursprüngliche Diagnose-Scan hinter einem hochgestuften Fall ist davon unabhängig und wird nicht gelöscht.)

Automatische Lösung hochgestufter Fälle

Wenn die Sicherheitsdiagnose ein Sondenergebnis aufnimmt, gleicht DiagnosticsService::reconcileCases() die Fälle je Host ab:

Ein Befund fail + crit → legt per Upsert einen offenen Fall an, adressiert über fingerprint als Schlüssel (ein erneutes Auftreten erhöht occurrence_count).
Besteht ein späterer Scan diesen Punkt bzw. entfällt er → wird der offene Fall automatisch gelöst (status=resolved, resolved_at, resolution=auto-resolved text) und ein status_change-Ereignis in die Zeitleiste geschrieben.

Die automatische Lösung greift nur, wenn die Diagnoseprüfung erneut besteht. Manuell angelegte Fälle (manual/agency/quarantine) werden nie automatisch gelöst — hier muss eine Betreiberin oder ein Betreiber sie durch die Pipeline führen.

Datenquellen

Tabellen

Tabelle	Rolle
`infr_incident`	Fallkörper (gefiltert auf `area='security'`). Status, Schweregrad, Quelle, Felder des 500-Berichts, Zeitpunkte für Eintritt/Lösung/Abschluss, `fingerprint`, `occurrence_count`
`infr_incident_event`	Zeitleiste des Falls (angelegt, Notiz, Statuswechsel, …)
`infr_project`	Projektliste für die Verknüpfung
`infr_service`	Dienstliste für die Verknüpfung

Aufzählungen

STATUSES   = [open, investigating, cause_identified, resolved, closed]
SEVERITIES = [info, warn, crit]
SOURCES    = [manual, pulse, alert, agency, quarantine, detection]   # alle
manual-selectable sources = [manual, agency, quarantine]
OPEN_STATUSES (dedup targets) = [open, investigating, cause_identified]
AREAS = [service, security]   # Trennachse der gemeinsam genutzten Tabelle

Berichtsfelder (500-Struktur)

Feld	Bedeutung
`summary`	Zusammenfassung von Symptom und Auswirkung
`direct_cause`	Unmittelbare Ursache (z. B. MySQL Too many connections)
`root_cause`	Hintergrund- bzw. Grundursache (z. B. Verbindungsleck eines Skripts)
`resolution`	Während des Vorfalls durchgeführte Wiederherstellung
`action_taken`	Präventivmaßnahme für die Zukunft
`downtime_min`	Ausfallzeit (Minuten) — Quelle des KPI downtime
`impact`	Betroffener Umfang

API-Endpunkte

Methode · Pfad	Zweck
`GET /security/resolution`	Erstes Rendern des Boards
`GET /security/resolution/live`	Aktualisierung per Polling (Fälle, KPI, Zeitstempel)
`POST /security/resolution/save`	Fall anlegen / aktualisieren
`POST /security/resolution/transition`	Statusübergang (+ optionale Notiz / Berichtsaktualisierung)
`POST /security/resolution/note`	Kollaborationsnotiz hinzufügen
`POST /security/resolution/delete`	Fall löschen

Zugriff

Lesen: Die gesamte Sicherheitsgruppe ist durch die Middleware infr.level:2 geschützt. Nur Stufe 2 und höher (staff=5 · admin=10) gelangt hinein; die Demo (1) wird blockiert.
Schreiben (Speichern/Übergang/Notiz/Löschen): canWrite() im Controller prüft das infr_user_level >= 2 der Sitzung erneut. Darunter kommt 403 zurück (resolution.err.forbidden).
Audit: Jeder Schreibvorgang wird in infr_audit_log festgehalten — sec.incident_create · sec.incident_update · sec.incident_transition · sec.incident_delete. Übergänge speichern {from,to}, Speichervorgänge {title,severity} in den Metadaten. Siehe Audit-Protokoll.

Fehlersuche & FAQ

F. Ein Fall, den ich auf dem Service-Board sehe, fehlt hier. Beide Boards teilen sich dieselbe Tabelle infr_incident, trennen sich aber über area. Dieser Bildschirm zeigt ausschließlich area='security'. Service-Vorfälle finden Sie unter Service ▸ Problemlösung.

F. Ich kann keinen Fall mit der Quelle detection anlegen. Das ist so vorgesehen. detection ist eine reine Systemquelle, die die Sicherheitsdiagnose automatisch aus fail+crit-Befunden erzeugt. Die manuelle Erfassung bietet nur manual, agency und quarantine.

F. Ein automatisch hochgestufter Fall hat sich selbst auf gelöst gesetzt. Besteht die zugrunde liegende Diagnoseprüfung bei einem späteren Scan, löst reconcileCases() den offenen Fall automatisch: resolution wird mit dem Text der automatischen Lösung gefüllt und ein Statuswechsel-Ereignis ergänzt.

F. MTTR bleibt leer. MTTR wird nur für Fälle berechnet, die sowohl occurred_at als auch resolved_at besitzen. Fälle ohne Eintrittszeitpunkt oder noch ungelöste Fälle bleiben ausgeschlossen.

F. Kann ich einen zurückliegenden Abschlusszeitpunkt setzen? Ja. Tragen Sie im Feld Abschlusszeitpunkt des Abschlussdialogs einen Wert ein (dieselbe Oberfläche wie beim Eintrittszeitpunkt); er wird unverändert gespeichert. Lassen Sie das Feld leer, füllt der Server now() nur dann ein, wenn noch kein Wert vorhanden ist.

F. Löscht das Entfernen eines Falls auch dessen Diagnose-Scan? Nein. Ein hochgestufter Fall und der zugehörige Diagnose-Scan sind unabhängig voneinander. Beim Löschen eines Falls verschwinden nur die mit ihm verknüpften Zeitleisten-Ereignisse.