oc-sentinel/docs/roadmap.md

OfficeCom Sentinel Roadmap

Produktziel

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.

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.
• Interne Uebersicht, Empfaengerverwaltung und woechentliche HTML-Berichte.
• 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 als Warnung oder kritisch bewertet.

Naechster Schwerpunkt: 1.5 Ransomware-Frueherkennung

1.5.0: Leichtgewichtiger Fileserver-Sensor

Lieferumfang

• 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.

Bewertung

• 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.

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.
• 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, sofern diese verlaesslich und ohne proprietaere Nebenlast verfuegbar sind.

Danach: 1.7 Betrieb und Auswertung

• Datenqualitaetspruefung fuer unbekannte Organisationen, fehlende Zuordnung und veraltete Clients.
• Sensor- und Client-Gesundheit in der internen Uebersicht.
• Berichtsvarianten je Empfaengergruppe und nachvollziehbare Versandhistorie.
• Betriebsmetriken fuer Upload-Fehler, Queue-Alter und Incident-Volumen.

Nicht Bestandteil

• 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, ueberfluessige Kommentare loeschen und Dokumentation aktualisieren.
• Release erst nach Build, Paket-Hash-Pruefung und einem Test der Update- und Upload-Strecke.