Refine Sentinel delivery roadmap

docs/roadmap.md

@@ -1,12 +1,27 @@
 # OfficeCom Sentinel Roadmap
 
-## Leitlinie
+## Produktziel
 
-OfficeCom Sentinel soll wenige, nachvollziehbare Sicherheitssignale liefern.
+OfficeCom Sentinel erkennt nachvollziehbare Sicherheitsmuster auf Windows-
-NinjaOne bleibt die Quelle fuer akute Alerts. Die zentrale Plattform sammelt
+Endpunkten und Fileservern, ohne den Betrieb zu stoeren. NinjaOne ist fuer
-Telemetrie, erstellt Wochenberichte und macht Trends je Organisation sichtbar.
+zeitnahe Alerts zustaendig. Die zentrale Plattform sammelt verdichtete
+Telemetrie, zeigt die Sicherheitslage je Organisation und erstellt Berichte.
 
-## Bereits geliefert
+Der Client ersetzt weder G DATA/MXDR noch ein EDR. Er ergaenzt diese Systeme mit
+lokaler Korrelation, organisationsuebergreifender Sicht und nachvollziehbaren
+Incident-Protokollen.
+
+## Leitplanken
+
+- Wenige aussagekraeftige Signale statt Alarmierung bei Einzelereignissen.
+- Die Bewertung muss im JSON-Report und in der Uebersicht nachvollziehbar sein.
+- Kein direkter Datenbankzugriff und keine internen Infrastrukturwerte im Client.
+- Standardmaessig minimale Last: keine Vollscans, kein globales Dateiauditing,
+  keine dauerhafte Uebertragung von Rohereignissen.
+- Datenminimierung: zentrale Speicherung nur von verdichteten Ereignissen und
+  Incident-Kontext, nicht von vollstaendigen Dateilisten.
+
+## Ausgangslage: geliefert
 
 - Endpoint-Client mit signiertem Upload und lokaler NinjaOne-Feldaktualisierung.
 - N8n- und PostgreSQL-Pipeline mit organisationsbezogener Zuordnung.
@@ -14,49 +29,90 @@ Telemetrie, erstellt Wochenberichte und macht Trends je Organisation sichtbar.
 - Gestaffelte taegliche Uploads sowie Burst-Pruefung.
 - Version 1.4.0: Fehlanmeldungen werden in 15-Minuten-Fenstern korreliert.
   Einzelne Tippfehler erzeugen keinen Alarm; Anmelde-Bursts und Password
-  Spraying werden weiterhin als Warnung oder kritisch bewertet.
+  Spraying werden als Warnung oder kritisch bewertet.
 
-## Naechste Minor-Version: 1.5
+## Naechster Schwerpunkt: 1.5 Ransomware-Frueherkennung
 
-### Ransomware-Frueherkennung
+### 1.5.0: Leichtgewichtiger Fileserver-Sensor
 
-- Beobachtung ungewoehnlicher Serien von Dateioperationen in kurzen Zeitfenstern.
+**Lieferumfang**
-- Erkennung von Schattenkopie- und Recovery-Manipulationen, soweit sie in
-  Windows-Ereignissen oder Prozessdaten sichtbar sind.
-- Erkennung typischer Verschluesselungs- und Loeschwerkzeuge ueber
-  Prozessnamen, Kommandozeilen und auffaellige Folgeereignisse.
-- Stufenmodell: Hinweis bei schwachen Einzelindikatoren, Warnung bei einer
-  Korrelation, kritisch nur bei mehreren voneinander unabhaengigen Indikatoren.
-- NinjaOne liefert die zeitnahe Alarmierung; die zentrale Plattform dokumentiert
-  Verlauf und Organisationstrend.
 
-### Erkennungsqualitaet
+- Inkrementelle Auswertung statt Dateiscan: Nur neue Prozess- und
+  Systemereignisse sowie Aenderungszaehler seit dem letzten Pruefpunkt.
+- Erkennung hochrelevanter Manipulationen wie Schattenkopie-, Recovery- und
+  Backup-Loeschbefehle sowie verdaechtiger Verschluesselungswerkzeuge.
+- Lokaler Ringpuffer mit aggregierten Datei-Churn-Signalen, etwa ungewoehnliche
+  Umbenennungen, Loeschungen und neue Erweiterungen.
+- Snapshot der SMB-Sitzungen und des Incident-Kontexts erst bei einer
+  Auffaelligkeit.
+- Verdichtetes Ransomware-Incident-Protokoll fuer n8n und die Uebersicht.
 
-- Konfigurierbare Ausnahmen fuer bekannte Servicekonten, Scanner und Monitoring.
+**Bewertung**
-- Einheitliches Risiko-Scoring fuer Login-, Prozess- und Ransomware-Signale.
-- Begruendung je Bewertung im JSON-Report, damit Alerts nachvollziehbar bleiben.
 
-## Folgende Minor-Versionen
+- Hinweis: Ein schwaches, isoliertes Signal. Es erscheint in Protokoll,
+  Uebersicht und Wochenbericht, aber nicht als NinjaOne-Alarm.
+- Warnung: Zwei unabhaengige Signale innerhalb eines kurzen Zeitfensters oder
+  eine veraenderte Canary-Datei.
+- Kritisch: Mehrere korrelierte Signale oder eine bestaetigte Schutzmeldung von
+  G DATA/MXDR zusammen mit auffaelligem Datei-Churn.
 
-### 1.6: Zusaetzliche Sensoren
+**Last- und Datenschutzgrenzen**
+
+- Sensorpruefung hoechstens einmal pro Minute, ausschliesslich inkrementell.
+- Kein globales Windows-Dateiauditing und keine globale Sysmon-Dateierstellung.
+- Keine Datei-Hashes und keine rekursiven Share-Scans im Normalbetrieb.
+- Maximal ein verdichteter Incident-Upload je Fileserver und fuenf Minuten;
+  gleiche Muster werden lokal zusammengefasst.
+- Keine Dateinamen im Standardprotokoll; optionale, begrenzte Detaildaten nur
+  fuer explizit konfigurierte kritische Freigaben.
+
+**Abnahme**
+
+- Test auf einem produktionsnahen Fileserver mit normaler Benutzerlast.
+- Vergleich der Sensorlast vor und nach Aktivierung.
+- Nachweis, dass normale Dateiaktivitaet von vielen Benutzern keinen Alert
+  erzeugt und ein simuliertes Mehrsignal-Szenario korrekt eskaliert.
+- Offline-Pufferung, Deduplizierung und Retry des Incident-Protokolls getestet.
+
+### 1.5.1: Tuning und kontrollierter Rollout
+
+- Baseline je Fileserver und Zeitfenster aus mindestens einer Arbeitswoche.
+- Konfigurierbare Ausnahmen fuer bekannte Backup-, Scan- und Servicekonten.
+- Pilotgruppe mit wenigen Fileservern, Auswertung der Hinweise und Anpassung
+  der Schwellenwerte vor breiter Verteilung.
+- Klare NinjaOne-Conditions fuer Warnung und kritisch; Hinweise bleiben ohne
+  Ticket- oder Alarmflut.
+
+## Danach: 1.6 Zusaetzliche Sensoren
 
 - Neue lokale Administratoren und auffaellige Gruppenmitgliedschaften.
-- Remote-Zugriffsmuster wie RDP- und SMB-Fehlanmeldungen mit Quellkorrelation.
+- RDP- und SMB-Fehlanmeldungen mit Quell- und Konto-Korrelation.
 - Sicherheitsrelevante Aenderungen an Diensten, geplanten Aufgaben und
   Autostart-Mechanismen.
-- Optionaler Import von G DATA-/MXDR-relevanten lokalen Ereignissen, wenn die
+- Optionaler Import von G DATA-/MXDR-relevanten lokalen Ereignissen, sofern
-  vorhandene Installation diese verlaesslich bereitstellt.
+  diese verlaesslich und ohne proprietaere Nebenlast verfuegbar sind.
 
-### 1.7: Betrieb und Auswertung
+## Danach: 1.7 Betrieb und Auswertung
 
-- Datenqualitaetspruefung fuer fehlende Organisationen und veraltete Clients.
+- Datenqualitaetspruefung fuer unbekannte Organisationen, fehlende Zuordnung
+  und veraltete Clients.
 - Sensor- und Client-Gesundheit in der internen Uebersicht.
-- Berichtsvorlagen je Empfaengergruppe und nachvollziehbare Versandhistorie.
+- Berichtsvarianten je Empfaengergruppe und nachvollziehbare Versandhistorie.
+- Betriebsmetriken fuer Upload-Fehler, Queue-Alter und Incident-Volumen.
 
-## Qualitaet In Jedem Release
+## Nicht Bestandteil
 
-- Keine neue Erkennung ohne Beispielereignisse und Regressionstest.
+- Kein zweiter Antivirus- oder EDR-Agent.
-- Sicherheitsentscheidungen bleiben im Client lokal nachvollziehbar.
+- Keine Blockierung oder automatische Wiederherstellung durch OCSentinel ohne
-- Keine internen Zugangsdaten, Datenbankadressen oder Secrets im Clientpaket.
+  explizite, separat freigegebene Schutzfunktion.
+- Kein zentraler Upload aller Dateioperationen oder kompletter Eventlogs.
+
+## Qualitaet in jedem Release
+
+- Keine neue Erkennung ohne Beispielereignisse, Regressionstest und dokumentierte
+  Bewertungslogik.
+- Jede neue Datenart benoetigt Zweck, Aufbewahrungsregel und Datenschutzpruefung.
 - Vor jeder Minor-Version: Code-Clean-up, Abhaengigkeiten pruefen, tote Pfade
-  entfernen und die Dokumentation aktualisieren.
+  entfernen, ueberfluessige Kommentare loeschen und Dokumentation aktualisieren.
+- Release erst nach Build, Paket-Hash-Pruefung und einem Test der Update- und
+  Upload-Strecke.