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.

Beta- und Rollback-Modell

Jede neue Erkennung, Datenart und UI-Aenderung durchlaeuft denselben reversiblen Lieferweg. Eine Funktion wird nie erstmals auf dem gesamten Bestand aktiv geschaltet.

Stufe 0: Spezifikation und lokale Tests

• Zweck, Datenfelder, Bewertung und erwartete Last werden vor dem Coding dokumentiert.
• Beispielereignisse decken Normalfall, Hinweis, Warnung, kritisch und Fehler ab.
• Der Client muss bei fehlender neuer Konfiguration das bisherige Verhalten unveraendert beibehalten.

Stufe 1: Interne Beta

• Das Paket wird als separater Beta-Release veroeffentlicht; stable bleibt unveraendert.
• Eine neue Funktion ist per Feature-Schalter standardmaessig deaktiviert.
• Die Beta wird nur auf Testgeraeten bzw. einer internen Organisation verteilt.
• Zentrale Auswertung prueft Laufzeit, Upload-Volumen, Fehler und Datenformate.

Stufe 2: Passiver Kunden-Pilot

• Ausgewaehlte Geraete erhalten die Beta mit aktivierter Funktion im Beobachtungsmodus.
• Signale erscheinen in Protokoll und Dashboard, loesen aber keine NinjaOne- Alarmbedingung aus.
• Der Pilot laeuft mindestens eine realistische Arbeitswoche, bei Fileservern inklusive der normalen Spitzenzeiten.

Stufe 3: Kontrollierte Alarmierung

• Erst nach Auswertung werden Warnungen fuer eine kleine, benannte Pilotgruppe an NinjaOne uebergeben.
• Hinweise bleiben weiterhin rein informativ.
• Schwellenwerte, Ausnahmen und Empfaenger werden pro Pilot dokumentiert.

Stufe 4: Stable-Rollout

• Rollout zuerst je Organisation oder Richtlinie, nicht an alle Kunden zugleich.
• Der Stable-Kanal wird erst nach erfolgreichem Pilot, Review der Datenqualitaet und Freigabe der Alarmbedingungen aktualisiert.
• Die vorherige Stable-Version bleibt als signiertes Release verfuegbar.

Rueckfall

• Sofort: Feature-Schalter in der Richtlinie deaktivieren. Der Client bleibt installiert, sammelt fuer diese Funktion aber nichts mehr.
• Kurzfristig: Pilotgeraete ueber NinjaOne auf die vorherige Stable-Version zuruecksetzen.
• Zentral: Die Auswertung kann das neue Feld ignorieren; neue JSON-Felder sind immer optional und muessen abwaertskompatibel bleiben.
• Datenbankaenderungen werden nur additiv eingefuehrt. Loeschende oder nicht rueckgaengig zu machende Migrationen gehoeren nicht in eine Beta.

Abbruchkriterien

Ein Pilot wird pausiert und zurueckgesetzt, wenn eines dieser Kriterien eintritt:

• spuerbare Last oder Beeintraechtigung auf einem Kundenserver,
• unkontrolliertes Upload- oder Queue-Wachstum,
• fehlerhafte Organisationszuordnung oder unerwartete personenbezogene Daten,
• mehr als ein unbegruendeter NinjaOne-Alarm im Pilot ohne klare Korrektur,
• fehlende oder nicht nachvollziehbare Incident-Protokolle.

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.

Voraussetzung: 1.4.1 Beta-Auslieferung

• Eigener Beta-Manifest-Pfad neben release/stable/version.json.
• Eigene NinjaOne-Aufgabe fuer Pilotgeraete, die ausschliesslich den Beta-Manifest-Pfad verwendet.
• Stable-Aufgabe bleibt unveraendert und ist zugleich der schnelle Rollback auf die letzte freigegebene Version.
• Beta-Releases werden in Gitea als Vorabversion markiert und erhalten dieselbe Paket-Hash-Pruefung wie Stable-Releases.
• Jeder Pilot dokumentiert Geraete, Organisation, aktivierte Feature-Schalter, Startzeitpunkt und verantwortliche Person.

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 aus vorhandenen Datei-Audit-Ereignissen. Die erste Beta wertet Loesch- und Schreibzugriffe ohne Datei- oder Freigabenamen aus.
• 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.
• Start als interne Beta gemaess dem Beta- und Rollback-Modell; der Sensor wird erst nach dem passiven Fileserver-Pilot als NinjaOne-Alarm aktiviert.

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 Modernes Web GUI und Visualisierung

Das interne Web GUI wird von einer Debug-Ansicht zu einer schnellen, arbeitsfaehigen Sicherheitsuebersicht weiterentwickelt. Es bleibt intern und benoetigt keine eigene Anmeldung, solange der Zugriff ueber das bestehende interne Netz und den Reverse Proxy abgesichert ist.

Informationsarchitektur

• Startseite mit Sicherheitslage ueber alle Organisationen, aktiven Incidents, Datenabdeckung und Upload-Gesundheit.
• Organisationsansicht mit Trend, betroffenen Geraeten, offenen Hinweisen und letzter erfolgreicher Datenerfassung.
• Geraeteansicht mit klarer Risikozusammenfassung, Ereignis-Timeline, Ransomware-Incident-Protokollen und aufgeklapptem Rohdatenexport fuer die technische Analyse.
• Berichtsbereich mit Vorschau, Versandstatus, Empfaengerregeln und erneutem Versand einer Organisation.

Visualisierung

• Zeitreihe fuer Hinweise, Warnungen und kritische Signale je Organisation.
• Gestapelte Tagesansicht fuer Login-, CVE-, Ransomware- und Sensor-Signale.
• Heatmap fuer auffaellige Zeitfenster statt einer langen, schwer lesbaren Ereignisliste.
• Abdeckungsansicht: aktive Clients, veraltete Scans, Upload-Fehler und Geraete ohne Organisationszuordnung.
• Jede Grafik verweist auf die zugrundeliegenden Geraete und Ereignisse; es gibt keine rein dekorativen Kennzahlen ohne Drill-down.

Technische Leitplanken

• Responsive fuer Notebook, Tablet und Mobilansicht; barrierearme Kontraste und klare Statusfarben.
• Datenbankabfragen liefern aggregierte Zeitreihen. Rohdaten werden nur beim Oeffnen einer Geraete- oder Incident-Ansicht nachgeladen.
• Begrenzte Zeitraeume und serverseitige Pagination verhindern langsame Seiten bei wachsendem Datenbestand.
• HTML-E-Mails und Weboberflaeche teilen einen konsistenten visuellen Standard, aber keine fragilen, kopierten CSS-Regeln.

Beta und Abnahme

• Neue GUI zunaechst unter separatem internen Beta-Pfad neben der bestehenden Uebersicht bereitstellen.
• Vergleich der neuen Kennzahlen mit den bekannten Rohdaten und Wochenberichten.
• Pilot mit realen Organisationen, insbesondere einer groesseren Fileserver- Umgebung, vor Umschalten der Standardansicht.
• Zuruecksetzen erfolgt ueber den Reverse Proxy auf die bestehende GUI; Daten und Empfaengerregeln bleiben dabei unveraendert.

Danach: 1.8 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.