msolarczek/craftvia
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
6f3f5a5947ccf9a492f6de239f3a56e6a3c675d4
craftvia/docs/KONZEPT-incidents.md
T
msolarczekandClaude Opus 5 c8e6f30a27
CI / build-and-check (push) Canceled after 0s
Details
CI / audit (push) Canceled after 0s
Details
CI / sbom (push) Canceled after 0s
Details
Basis: Certvia dev@a48c5fb als Fundament für Craftvia 
Unveränderter Stand von certvia/dev (a48c5fb) plus Craftvia-Spezifikation
und Brandbook unter docs/craftvia/. ISMS-Module werden im Folgecommit entfernt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-14 11:05:39 +02:00

13 KiB
Raw Blame History

Incident-Management — Fachkonzept (Certvia)

Modul „Vorfälle" (Placeholder im Bestand). Umfang: Standard — erfassen → kategorisieren/bewerten → bearbeiten (Verantwortliche, Aufgaben, Maßnahmen) → abschließen + Lessons Learned. Rahmen: ISO 27001 (A.5.24–5.28), NIS2 (Meldepflicht-Bewusstsein + Fristen), TISAX/VDA-ISA (1.6.x). Kanäle: intern manuell + E-Mail-to-Ticket. Keine Behörden-API — NIS2-/DSGVO-Meldung wird vorbereitet (Fristen-Timer + Meldevorlage/Export), Übermittlung erfolgt manuell.

1. Rollen (RACI-Kurz)

Rolle Aufgabe
Melder (intern / E-Mail) Meldet den Verdacht/Vorfall (Titel, Beschreibung, was/wann).
ISB / Incident-Manager Triage, Kategorisierung, Bewertung, Steuerung, Meldepflicht-Entscheidung, Abschluss.
IT / Bearbeiter Sofort-/Behebungsmaßnahmen umsetzen (als Aufgaben).
Geschäftsführung Eskalation, Freigabe externer Meldungen.
DSB (optional) Bei Personenbezug (DSGVO Art. 33/34).

2. Kanäle (Intake)

  • Intern manuell: berechtigte Rollen legen Vorfall über die UI an (Popup wie bei Assets/Aufgaben).
  • E-Mail-to-Ticket: Zustellung an ein Certvia-seitiges Eingangspostfach (nicht an ein Kundenpostfach). Certvia betreibt eine Inbound-Domain und vergibt je Mandant eine eindeutige, nicht erratbare Adresse (z. B. vorfall-<token>@in.certvia.de); der Kunde nutzt sie direkt oder leitet von seiner eigenen Adresse (vorfall@kunde.de) dorthin weiter. Über die Zieladresse erfolgt die Mandantenzuordnung. Eingehende Mail → Vorfall im Status Neu/Triage (Betreff→Titel, Text→Beschreibung, Absender→Melder). Dedupe über Message-Header; Absender-Allowlist (nur interne Kundendomänen erzeugen Tickets) + SPF/DKIM/DMARC-Prüfung + Spam-Filter; externe/unbekannte Absender werden „extern" markiert (Triage). Anhänge später (Storage-Paket).
    • Inbound ist ein eigener Kanal: SEC1 deckte nur den Ausgang (SMTP) ab; für den Empfang braucht es einen Empfangsweg. Warum kein Kundenpostfach: kein Speichern/Pollen von Kunden-IMAP/OAuth-Credentials → weniger Aufwand, robuster, DSGVO-/sicherheitsseitig sauberer.
    • Konkrete Umsetzung (All-inkl · einfachster Weg, gewählt): Subdomain in.certvia.de bei All-inkl mit Catch-all-Postfach — alle vorfall-<token>@in.certvia.de landen in einem Postfach. (Catch-all in All-inkl KAS: E-Mail → E-Mail-Postfach → „Neues Postfach anlegen", das Adressfeld leer lassen. Catch-all ist spam-anfällig → eigene, nirgends veröffentlichte Intake-Subdomain hält die Spam-Fläche klein; zusätzlich Allowlist/DKIM/Review-Pfad.) Certvia holt die Mails per IMAP (kurzes Polling/IDLE, BullMQ-Job), parst sie (mailparser), ermittelt den Token aus dem Empfänger-Header (Delivered-To/X-Envelope-To — nicht To, da dort bei Weiterleitung die Kundenadresse steht), ordnet dem Mandanten zu, legt den Vorfall an und verschiebt die Mail nach „Verarbeitet"/„Fehler". Idempotenz über Message-ID; unbekannter/kein Token → Betreiber-Review statt Drop. Kein Postfach je Kunde (Catch-all + Auto-Token), keine KAS-API nötig; einmaliger globaler Setup (Subdomain + Catch-all + IMAP-Zugang als Plattform-Secret).
    • Weiterleitungs-Fallstricke: Weiterleitung bricht i. d. R. SPF (DKIM bleibt meist gültig) → nicht hart auf SPF-Fail ablehnen; Vertrauen über Absender-Allowlist + DKIM, SPF nur als Signal. Auto-Reply/Bounce-Schleifen über Auto-Submitted/Precedence-Header erkennen und ignorieren. Größenlimit/Spam-Filter beachten.
  • Mail-Einstellungen: die mandantenspezifischen Einstellungen (Intake-Adresse/Routing, Benachrichtigungspräferenzen, Absender-Anzeige) werden im Einstellungs-Modul gepflegt. Die SMTP-Zugangsdaten/der Transport bleiben aus Sicherheitsgründen auf Plattform-/Secret-Store-Ebene (SEC1) — kein Mandant legt Server-Credentials selbst an.

3. Lebenszyklus / Statusmodell

Primärfluss: Neu/Eingegangen → Triage → In Bearbeitung → Eingedämmt (contained) → Behoben → Abgeschlossen · (+ Wiedereröffnet)

  • Jeder Übergang: Pflichtfelder-Check, Zeitstempel, Akteur, Audit-Eintrag.
  • Parallel-Track „Meldung" (nur wenn meldepflichtig): Meldepflicht geprüft → Erstmeldung (24 h) → Folgemeldung (72 h) → Abschlussbericht (1 Monat) — als Status + Timer, Übermittlung manuell.

4. Datenmodell (Incident-Objekt)

  • Kennung: refNo (z. B. INC-2026-0042), tenantId (RLS).
  • Basis: Titel, Beschreibung, Kanal/Quelle (manuell/E-Mail), Melder (+Kontakt).
  • Zeiten: occurredAt (Eintritt), detectedAt (Entdeckung), reportedAt (interne Meldung), Timeline.
  • Kategorie (Taxonomie): Schadsoftware · Phishing/Social Engineering · Unbefugter Zugriff · Datenabfluss/-verlust · Systemausfall/Verfügbarkeit · Physisch (Zutritt/Diebstahl) · Fehlbedienung/Konfiguration · Lieferant/Drittpartei · Prototyp/Kundendaten (TISAX) · Sonstiges.
  • Betroffenheit: verknüpfte Assets/Prozesse (BIA), Schutzziel-Impact C/I/A, Datenkategorien, Personenbezug (→ DSGVO-Flag), Prototyp/Kundendaten (→ TISAX-Flag).
  • Bewertung: Schweregrad/Priorität (siehe §5).
  • Steuerung: owner (Incident-Manager), Bearbeiter, Status.
  • Meldepflicht: nis2Relevant, dsgvoRelevant (bool) + Meldestatus + Fristen (§6).
  • Behebung: Sofortmaßnahmen, Ursache (Root Cause), Lösung/Resolution.
  • Abschluss: Abschlussnotiz, Lessons Learned, verknüpfte CAPA-Aufgaben.
  • Verknüpfungen: Maßnahmen (im zentralen Maßnahmen-Modul, §9), Risiken (bestätigt/neu), Controls (welche versagten/betroffen), Nachweise.
  • Kommentare/Notizen: Kommentar-Thread am Vorfall (Autor, Zeitstempel, editierbar nach Regel) für die Zusammenarbeit — getrennt von der automatischen, manipulationssicheren Audit-Timeline (§8/§9). Interne vs. sichtbare Kommentare optional.
  • Anhänge: Belege (Screenshots/Logs) — Modell vorbereiten, Datei-Persistenz mit Storage-Paket.

5. Schweregrad / Priorisierung

  • Schweregrad aus Auswirkung (C/I/A-Verletzung × Umfang: einzelnes System … unternehmensweit … Kunde/Lieferkette) und Dringlichkeit → Klassen niedrig · mittel · hoch · kritisch.
  • Treibt interne SLA (Reaktion/Behebung), Eskalation und Benachrichtigungen. Matrix mandantenkonfigurierbar (Default vorgegeben).

6. Fristen & Timer (vorbereitet, ohne Behörden-API)

Auslöser Frist Umsetzung im Tool
NIS2 – Früh-/Erstmeldung 24 h ab Kenntnis Timer/Countdown + Erinnerung (SEC1) + Meldevorlage
NIS2 – Meldung 72 h Timer + Vorlage (Aktualisierung)
NIS2 – Abschlussbericht 1 Monat Timer + Abschluss-Vorlage/Export
DSGVO Art. 33 (bei Personenbezug) 72 h Timer + Datenschutz-Meldevorlage
Interne SLA (je Severity) konfigurierbar Reaktions-/Behebungs-Timer
  • Timer nur, wenn Meldepflicht = ja (NIS2-Betroffenheit des Mandanten aus den Einstellungen). Countdown im Vorfall + Dashboard-Kachel; Eskalation bei drohender/verpasster Frist. Übermittlung an die Behörde erfolgt manuell (Vorlage/Export bereitgestellt).

7. Benachrichtigungen (SEC1)

Neuer Vorfall → ISB/Incident-Manager; Zuweisung → Bearbeiter; Statuswechsel → Beteiligte; Fristen-Erinnerung/Eskalation; Abschluss → Melder/GF. Respektiert Benachrichtigungspräferenzen + Mandantenisolation.

8. Abschluss & Lessons Learned

  • Pflicht beim Abschluss: Ursache, Lösung, Wirksamkeit der Maßnahmen, Lessons Learned.
  • CAPA: korrigierende/präventive Maßnahmen als Aufgaben anlegen; Risikoregister aktualisieren (Risiko bestätigt/neu); Bezug zu betroffenen Controls.
  • Optionaler Post-Incident-Review (Kurzbericht) → speist Management-Review.

9. Verknüpfung zu bestehenden Modulen

  • Maßnahmen-Modul (vorhanden): Sofort- und CAPA-Maßnahmen werden im zentralen Maßnahmen-Modul angelegt/gepflegt (nicht doppelt im Vorfall) und mit dem Vorfall verknüpft; im Vorfall erscheinen sie als verknüpfte Liste mit „Maßnahme direkt aus dem Vorfall anlegen". Verantwortliche/Fristen/Status kommen aus dem Maßnahmen-Modul; Bezug zu Risiken/Controls möglich. (Hinweis: falls „Maßnahmen"/„Aufgaben" heute getrennt sind, an eine zentrale Maßnahmen-/Aufgaben-Backbone andocken.)
  • Kommentare dagegen liegen am Vorfall (Thread, §4) — sie sind Zusammenarbeit, keine trackbare Maßnahme.
  • Assets/BIA · Risiken · Controls: Betroffenheit und Wirkung verknüpfen; Vorfall kann Risiko bestätigen/erzeugen.
  • Audit-Log: Vorfall-Timeline (wer/wann/was) manipulationssicher (getrennt von den Kommentaren).
  • Nachweise/Export: Vorfallregister + Einzelbericht (DOCX/PDF über Export-Layer), NIS2-/DSGVO-Meldevorlagen (vorbefüllt) für die manuelle Übermittlung.

10. Framework-Mapping

Rahmen Bezug
ISO 27001:2022 A.5.24 Planung/Vorbereitung · A.5.25 Bewertung/Entscheidung · A.5.26 Reaktion · A.5.27 Lernen · A.5.28 Beweissicherung
TISAX / VDA-ISA 1.6.x Incident-/Ereignismanagement; Prototyp-/Kundendaten-Bezug
NIS2 (Art. 23) Meldekette 24 h/72 h/1 Monat — im Tool als Timer/Vorlage vorbereitet
DSGVO Art. 33/34 Datenpanne (72 h) — Timer/Vorlage

11. Rechte / Sicherheit

  • Strikt mandantengebunden (RLS); rollenbasierte Rechte (melden vs. bearbeiten vs. abschließen/melden).
  • Vertraulichkeit: sensible Vorfälle optional auf einen eingeschränkten Personenkreis begrenzbar.
  • Meldevorlagen/Exports datensparsam; jede Aktion auditiert.

12. Technische Einordnung

  • Eigenes Modul „Vorfälle" (incidents), modul-gated (Superadmin-Toggle); Maßnahmen über das zentrale Maßnahmen-Modul (verknüpft); Kommentare als eigener Thread am Vorfall; Mail über SEC1; Timeline über Audit; Verknüpfungen zu Assets/Risiken/Controls.
  • Mail-Einstellungen: mandantenseitig im Einstellungs-Modul (Intake-Adresse, Benachrichtigungen); SMTP-Transport plattformseitig (SEC1).
  • Popups/Bedienung im etablierten Muster (wie Assets/Maßnahmen).

12a. Provisionierung des Intake-Postfachs (Betreiberportal & Onboarding)

Das Anlegen der Inbound-Route (vorfall-<token>@in.certvia.de) ist zunächst ein manueller Betreiber-Schritt — dafür braucht es die richtigen Infos beim Onboarding und einen sichtbaren Status.

Beim Kunden-Onboarding erfassen (Admin-Konsole „Kunde anlegen", nur wenn Modul „Vorfälle" + E-Mail-to-Ticket aktiv):

  • Absender-/Weiterleitungs-Domäne(n) des Kunden (z. B. kunde.de) → Allowlist.
  • optional konkrete Quelladresse (vorfall@kunde.de), von der weitergeleitet wird.
  • Intake-Adresse wird von Certvia automatisch generiert (vorfall-<token>@in.certvia.de) und angezeigt (der Kunde richtet die Weiterleitung darauf ein).
  • optional Benachrichtigungsempfänger/Sprache.

Provisionierungs-Status je Kunde (Betreiberportal): Postfach anzulegen → angelegt → verifiziert.

  • Solange „anzulegen": Hinweis-Badge am Kundendatensatz („⚠ Intake-Postfach anlegen") und eine Sammelliste offener Provisionierungen auf dem Betreiber-Dashboard.
  • Betreiber-Schritt: Inbound-Route/Alias im Inbound-Dienst anlegen (manuell oder per Provider-API) → Status „angelegt". Verifizierung per Test-Mail (analog SEC1-Testversand) → „verifiziert".
  • Ausbau: bei Inbound-Providern mit API kann die Route beim Modul-Aktivieren automatisch angelegt werden → Status springt direkt auf „angelegt"; bis dahin bleibt es der manuelle Hinweis-Schritt.
  • Alle Provisionierungs-Aktionen im Plattform-Audit (scope=platform).

Mit der gewählten Variante (All-inkl Catch-all + Auto-Token): Es muss kein Postfach je Kunde angelegt werden; der Token wird automatisch generiert. Der einmalige Setup (Subdomain in.certvia.de + Catch-all-Postfach + IMAP-Zugang) ist ein globaler Betreiber-Schritt, nicht je Kunde. Der per-Kunde-Schritt reduziert sich darauf, die Weiterleitung des Kunden per Test-Mail zu verifizieren → vereinfachter Status je Kunde: Weiterleitung ausstehend → verifiziert. Der Onboarding-Datenbedarf bleibt (Allowlist-Domänen, Quelladresse); die Intake-Adresse wird automatisch erzeugt/angezeigt.

13. Abgrenzung / spätere Ausbaustufen

  • Direkte Behörden-Übermittlung (BSI-Meldeportal/-API) — jetzt bewusst nicht (nur Vorlage/Export).
  • Automatische Erkennung/SIEM-Integration, externe/anonyme Meldung, SLA-Automationen, KI-gestützte Klassif/Zusammenfassung — spätere Stufen.

14. Offene Entscheidungen

  1. NIS2-Betroffenheit je Mandant — woher (Mandanten-Einstellungen: „wichtige/wesentliche Einrichtung"?), steuert die Timer.
  2. Severity-Matrix — fester Default oder mandantenkonfigurierbar?
  3. Inbound (entschieden): All-inkl Catch-all-Postfach auf in.certvia.de + IMAP-Abholung, Auto-Token, kein Postfach je Kunde. Rest-Details: Polling-Intervall vs. IMAP-IDLE, welcher Header trägt den Token (Delivered-To/X-Envelope-To — beim ersten Test verifizieren), Ordner-/Fehler-Handling.
  4. Anhänge — abhängig vom Storage-Paket (bis dahin nur Referenz/Text).
  5. Vertraulichkeits-Stufen für sensible Vorfälle — jetzt oder später?

Nächster Schritt auf Wunsch: Entwickler-Task-Paket (Branches, Stories, DoD) — Maßnahmen auf das Task-Modul aufsetzend, Mail über SEC1, Timer/Meldevorlagen NIS2/DSGVO.

Reference in New Issue View Git Blame Copy Permalink