Document Sentinel roadmap and code quality standard
All checks were successful
OfficeCom Sentinel Client / validate-client (push) Successful in 23s
OfficeCom Sentinel Client / build-client-windows (push) Successful in 48s

This commit is contained in:
OfficeCom Codex
2026-07-29 00:55:05 +02:00
parent a81d8b9830
commit e711dc7029
5 changed files with 96 additions and 2 deletions

View File

@@ -12,6 +12,8 @@ OfficeCom Sentinel is the hardened endpoint client for Windows event correlation
- setup EXE builder: `build/build-client-installer.ps1`
- update manifest builder: `build/build-release-manifest.ps1`
- release checklist: `docs/release-checklist.md`
- product roadmap: `docs/roadmap.md`
- code quality standard: `docs/code-quality.md`
- internal server-side target example: `infra/postgres-target.example.json`
## Build

32
docs/code-quality.md Normal file
View File

@@ -0,0 +1,32 @@
# Code-Qualitaetsstandard
## Ziel
Der Client soll klein, pruefbar und wartbar bleiben. Kommentare sind keine
zweite Dokumentation und keine Erklaerung fuer selbsterklaerenden Code.
## Kommentarregel
- Kommentare bleiben nur bei Sicherheitsgrenzen, externen API-Eigenheiten,
nicht offensichtlichen Entscheidungen und bewusstem Fehlertoleranz-Verhalten.
- Beschreibende Kommentare direkt neben selbsterklaerenden Anweisungen werden
entfernt.
- Veraltete Kommentare werden im selben Pull Request wie die Codeaenderung
geloescht oder aktualisiert.
- Architektur- und Betriebswissen gehoert in `docs`, nicht in lange
Quellcodekommentare.
## Wiederkehrender Clean-up
Bei jeder Minor-Version wird ein kurzer Wartungsdurchlauf eingeplant:
1. Tote Konfiguration, nicht erreichbare Pfade und doppelte Hilfsfunktionen entfernen.
2. Kommentare gegen den aktuellen Code pruefen und ueberfluessige entfernen.
3. Formatierung und Benennung vereinheitlichen.
4. Release-Build und die relevanten Scan-Szenarien erneut ausfuehren.
## Sicherheitsausnahme
Kommentare, die vor einer unsicheren Aenderung schuetzen, bleiben erhalten.
Beispiele sind TLS-Kompatibilitaet, Secret-Schutz, Upload-Signaturpruefung und
deterministische Lastverteilung.

62
docs/roadmap.md Normal file
View File

@@ -0,0 +1,62 @@
# OfficeCom Sentinel Roadmap
## Leitlinie
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.
## Bereits 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 weiterhin als Warnung oder kritisch bewertet.
## Naechste Minor-Version: 1.5
### Ransomware-Frueherkennung
- 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.
### Erkennungsqualitaet
- 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.
## Folgende Minor-Versionen
### 1.6: Zusaetzliche Sensoren
- Neue lokale Administratoren und auffaellige Gruppenmitgliedschaften.
- Remote-Zugriffsmuster wie RDP- und SMB-Fehlanmeldungen mit Quellkorrelation.
- 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.
### 1.7: Betrieb und Auswertung
- Datenqualitaetspruefung fuer fehlende Organisationen und veraltete Clients.
- Sensor- und Client-Gesundheit in der internen Uebersicht.
- Berichtsvorlagen je Empfaengergruppe und nachvollziehbare Versandhistorie.
## Qualitaet In Jedem Release
- Keine neue Erkennung ohne Beispielereignisse und Regressionstest.
- Sicherheitsentscheidungen bleiben im Client lokal nachvollziehbar.
- Keine internen Zugangsdaten, Datenbankadressen oder Secrets im Clientpaket.
- Vor jeder Minor-Version: Code-Clean-up, Abhaengigkeiten pruefen, tote Pfade
entfernen und die Dokumentation aktualisieren.

View File

@@ -15,7 +15,6 @@ table { width:100%; border-collapse:collapse; font-family:'Roboto',sans-serif; f
@media (max-width:850px) { .recipient-form { grid-template-columns:1fr; }.rule-actions { min-width:220px; } }
@media (max-width:850px) { .metrics { grid-template-columns:repeat(2,1fr); }.metrics article:last-child { grid-column:span 2; }.masthead { height:auto; min-height:70px; padding:14px 5vw; align-items:flex-start; }.header-links { justify-content:flex-end; flex-wrap:wrap; }.badge { display:none; } main { padding:38px 5vw; }.situation { align-items:flex-start; flex-direction:column; } }
/* Keep the administration screens visually aligned with the Sentinel reports. */
.panel { border-radius:8px; box-shadow:0 14px 34px rgba(31,68,99,.08); }
.panel > .table-wrap { border:1px solid #dce6ee; border-radius:6px; background:#fbfdff; }
.panel > .table-wrap table { margin:0; }

View File

@@ -80,7 +80,6 @@ internal sealed record ScanResult
public string MachineName { get; init; } = string.Empty;
// Populated only for runs launched by NinjaOne automation.
public NinjaOneContext NinjaOne { get; init; } = new();
public DateTimeOffset GeneratedAtLocal { get; init; }