119 lines
5.3 KiB
Markdown
119 lines
5.3 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.
|
|
|
|
## 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.
|