diff --git a/docs/roadmap.md b/docs/roadmap.md index 9678f98..2e42817 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -1,12 +1,27 @@ # OfficeCom Sentinel Roadmap -## Leitlinie +## Produktziel -OfficeCom Sentinel soll wenige, nachvollziehbare Sicherheitssignale liefern. -NinjaOne bleibt die Quelle fuer akute Alerts. Die zentrale Plattform sammelt -Telemetrie, erstellt Wochenberichte und macht Trends je Organisation sichtbar. +OfficeCom Sentinel erkennt nachvollziehbare Sicherheitsmuster auf Windows- +Endpunkten und Fileservern, ohne den Betrieb zu stoeren. NinjaOne ist fuer +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. -- 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. +**Lieferumfang** -### 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. -- Einheitliches Risiko-Scoring fuer Login-, Prozess- und Ransomware-Signale. -- Begruendung je Bewertung im JSON-Report, damit Alerts nachvollziehbar bleiben. +**Bewertung** -## 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 - vorhandene Installation diese verlaesslich bereitstellt. +- Optionaler Import von G DATA-/MXDR-relevanten lokalen Ereignissen, sofern + 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. -- Sicherheitsentscheidungen bleiben im Client lokal nachvollziehbar. -- Keine internen Zugangsdaten, Datenbankadressen oder Secrets im Clientpaket. +- Kein zweiter Antivirus- oder EDR-Agent. +- Keine Blockierung oder automatische Wiederherstellung durch OCSentinel ohne + 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.