Assessor_2.0/docs/TIMESLOT_COMPARISON_AUDIT.md

Timeslot comparison capability audit

Stand: 2026-09-11. Phase 8, Paket P0/P1. Code- und synthetisches Fixture-Audit; ergänzend wurde der vom Nutzer ausdrücklich vollständig freigegebene Mandant Dummy ausschließlich lesend geprüft. Es gab keine Datenmutation.

Ergebnis

Die aktuelle kanonische Persistenz bewahrt Tool-/Regel-ID, optional ein generisch gemapptes affectedAsset, Originalfelder und Provenienz. Sie bewahrt außerdem scannergebundene Ziel-/Benchmarkbeobachtungen für die Scoreprojektion. Diese Angaben reichen nicht pauschal für eine objektgenaue Gegenprüfung: Der Assetwert besitzt keinen deklarierten Typ oder Namensraum, Score-Scope und Finding-Vorkommen sind nicht allgemein über einen versionierten Vergleichsvertrag verbunden, und kein Profil deklariert derzeit eine vollständige Negativnachweissemantik je Regel/Objekt.

Quelle	Unterstützte Formate/Pfade	Erhaltener übergeordneter Scope	Ergebnispopulation	Objektgenaue Behebung aus heutigem Bestand
Purple Knight	CSV/Excel/HTML über generische Tabellen plus native Summary-/HTML-Extraktion	forest.name; AD-native Scorequelle	complete für Scoreberechnung	Nicht allgemein belegt. asset ist heuristisch gemappt; Typ/Namensraum und vollständige Objektpopulation fehlen
PingCastle	XML/HTML über Healthcheck-Extractor	domain.fqdn	findings-only	Abwesenheit beweist keine Behebung. Native Regel-ID ist erforderlich, aber Ergebnislisten enthalten nur ausgelöste Regeln
CIS-CAT	HTML sowie generische Tabellen/Objektpfade	host.name und benchmark.name	complete für Scoreberechnung	Scopevergleich grundsätzlich möglich; regel-/objektbezogener Negativnachweis und Namespaceregel noch nicht deklariert
Maester	Excel/CSV/HTML über generische Tabellen bzw. HTML-Extractor	entra.tenant_id	complete für Scoreberechnung	Tenant-/Regelvergleich grundsätzlich möglich; asset ist keine verpflichtende, typisierte Zielidentität und vollständige Negativsemantik fehlt
Generisch	CSV/Excel/JSON/XML/HTML über registrierte Formatadapter und generischen Extractor	kein verifizierter Zielscope	unknown	Nicht automatisch vergleichbar; Titel, Position oder untypisierter Assettext dürfen keine Behebung beweisen
GPO/Baseline	Eigener versionierter Ingestion-, Identity-, Snapshot-, Evaluation- und Finding-Pfad	Projekt, Environment Profile, Kontext/Baseline/Setting und Backupreferenzen	explizite Complete/Partial/Blocked- und Evidencezustände	Fachlich reichere Identitäten vorhanden, aber ohne RSoP/GP Results keine allgemeine Aussage über effektive Anwendung; eigener Policyvertrag bleibt maßgeblich

Die älteren comparisonKeys bleiben vorerst als Legacydeklaration vorhanden. Zusätzlich muss jetzt jedes Scannerprofil einen versionierten timeslotComparison-Vertrag besitzen. Purple Knight, PingCastle, CIS-CAT und Maester sind zunächst ausschließlich scopeweit freigegeben; das generische Profil ist nicht automatisch vergleichbar. Kein aktuelles Profil erlaubt Behebung durch bloße Abwesenheit. Die neue sichere Engine konsumiert diese Verträge; die bisherige Produktprojektion konsumiert sie noch nicht.

Ergänzende Bestandsvalidierung mit Dummy

• Purple Knight besitzt im aktiven Bestand Regel-IDs und für jedes Ergebnis einen affectedAsset-Wert. Die Werte sind jedoch nur die Ergebnisbereiche AD beziehungsweise Hybrid (AD), keine stabilen Host-/Objektidentitäten. Der Vertrag bleibt deshalb korrekt auf forest.name und Scopegranularität begrenzt.
• CIS-CAT besitzt host.name, benchmark.name und report.generated_at; PingCastle besitzt domain.fqdn und report.generated_at; Purple Knight besitzt forest.name und report.generated_at. Der aktive Maester-Excel-Lauf besitzt keinen gespeicherten entra.tenant_id- oder Reportzeitnachweis und ist nach dem neuen Vertrag aktuell nicht vergleichbar.
• Dummy enthält mehrere supersedierte Reimporte derselben Scannerquellen. Die Läufe besitzen weder startedAt noch completedAt; ihre Importzeiten unterscheiden sich. Diese Importzeiten dürfen und werden nicht als neue Sicherheitsbeobachtung verwendet.
• Die derzeit aktiven Dummy-Quellen liegen nicht als zwei vollständig vergleichbare A/B-Timeslots desselben Scanners vor. Dummy kann daher aktuell keinen realen Fortschrittswert abnehmen; er bestätigt stattdessen die Fail-closed-Grenzen für Scope, Reportzeit und Reimport.

Versionierungsentscheidung für den ersten Schnitt

Der neue Domänenvertrag in src/domain/timeslot-comparison.ts ist additiv und wird noch nicht von Import, Persistenz, bestehender Vergleichsengine oder UI verwendet. Er verändert keine gespeicherten Fakten und benötigt deshalb für diesen ersten Schnitt weder Processing-Manifest noch Reimport.

Sobald ein Profil Objekt-/Scopefelder neu extrahiert, anders mappt oder eine neue Vollständigkeits-/Negativnachweisaussage aus dem Quellformat ableitet, gilt REIMPORT_POLICY.md: append-only Parser-/Extractor-/Profil-/Mappingversion und Reimportmarkierung nur für die betroffenen historischen Verträge. Bereits vollständig gespeicherte, verifizierbare Fakten dürfen später über eine getrennt versionierte Vergleichsprojektion neu ausgewertet werden; fehlende Evidenz darf nicht rekonstruiert werden.

P1-Profilstand und offene Entscheidungen

• Scopegranularität, notwendige Scopeeigenschaften, Reportzeitquellen, Ergebnisart und Diagnosepolitik sind für alle registrierten Profile deklariert und synthetisch validiert. Objektgranularität bleibt für alle aktuellen Scannerprofile gesperrt.
• complete trägt bei keinem aktuellen Profil automatisch eine negative Regel-/Objektaussage. Abwesenheit bleibt unverified-absent, bis ein formatspezifischer vollständiger Negativnachweis synthetisch belegt und versioniert ist.
• Scannerdiagnosen nach Einfluss auf Identität, Einzelresultat, Abdeckung und Gesamtscore klassifizieren.
• GPO-Vergleichsvertrag getrennt auf vorhandene Policy-Identitäten und Wirksamkeitsgrenzen abbilden; keine Scanner-Sonderlogik in React.