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.