251 lines
11 KiB
Markdown
251 lines
11 KiB
Markdown
# 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, 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.
|
|
- 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.
|