Infrastruktur sehen, wie sie wirklich war.
Mirror baut aus defensiven Beobachtungen ein lokales, zeitbewusstes Modell der Infrastruktur. Es rekonstruiert Zustände, erklärt Veränderungen, probt Kandidatenkontrollen auf isolierten Kopien und hält Integrität, Authentizität, Autorisierung, Frische und historische Vollständigkeit als getrennte Aussagen sichtbar.
Der geprüfte Stand implementiert den zeitbewussten Graphen, Chronicle, Diff, Exposure, Rehearsal, Evidence- und Assurance-Layer sowie eine lokale read-only Operator-Oberfläche. Produktion, Remote-/Multi-User-Betrieb und reale Deployment-Qualifikation sind ausdrücklich noch nicht freigegeben.
Ein Sicherheitsmodell, das seine Vergangenheit nicht vergisst.
Der aktuelle Graph ist nur eine materialisierte Sicht. Die Chronicle-Ledger bewahrt kanonische Beobachtungen als append-only, SHA-256-verkettete Historie; Snapshots und Event-Time-Rekonstruktion machen nachvollziehbar, was zu einem bestimmten Zeitpunkt bekannt war und welche Evidenz die Sicht trägt.
Mirror ist bewusst kein Vulnerability Scanner, kein Exploitation Framework, kein autonomes Remediation-System und kein Ersatz für SIEM oder EDR. Es modelliert, verifiziert und probt defensiv – und vermeidet dabei universelle Risiko- oder Sicherheitswerte, die die vorhandene Evidenz nicht hergibt.
Was die aktuelle Produktlinie tatsächlich trägt.
Temporaler Infrastrukturgraph
Kanonische Assets, Beziehungen, Trust Zones, Identitäten, Rollen und Datenflüsse werden deterministisch modelliert. Der aktuelle Graph bleibt von der historischen Quelle getrennt.
Chronicle, Snapshots und Time Travel
Append-only Historie, verankerte Snapshots, Event-Time-Rekonstruktion und strukturelle Diffs beantworten nicht nur, was existiert, sondern auch was wann anders war.
Defensive Exposure und Rehearsal
Defensive Pfade, Blast Radius und Service Impact werden aus expliziten Beziehungen abgeleitet. Kandidatenkontrollen laufen ausschließlich auf isolierten Zustandskopien und bleiben hinter Freigabegrenzen.
Evidence-backed Assurance
Security Claims werden an konkrete Evidenz, Checkpoints und Gültigkeitsregeln gebunden. Integrität, Signaturauthentizität, Key Trust, Frische und Vollständigkeit bleiben maschinenlesbar getrennt.
Offline-Verifikation und Federation
Versionierte Dokumente, Bundles, Verification Receipts, Deployment-Profile und Federation-Snapshots können ohne Cloud-Abhängigkeit geprüft und zwischen getrennten Mirror-Instanzen abgeglichen werden.
Operator Time-Travel UI
Die lokale read-only Oberfläche korreliert T1/T2-Graph, Chronicle-Timeline, Zustandsänderungen, Exposure-Gründe, Evidenz, Entities, Rehearsal und Assurance in einem Navigationspfad.
Beobachtung wird Zustand. Zustand wird belegbare Geschichte.
Die Schichten verhindern, dass eine bequemere Aussage eine stärkere Evidenzform imitiert. Beobachtung, Materialisierung, Ableitung, Signatur, Key Trust, Transfer und Empfang bleiben eigene Vertrauensentscheidungen.
Collectors und Imports
Read-only Host-, Docker-, Git- und Network-Adapter normalisieren Beobachtungen mit Provenienz, Redaction, Frische und Confidence.
Graph und Chronicle
Der Graph materialisiert aktuellen Zustand; Chronicle bewahrt kanonische Beobachtungen samt verketteter Integrität und Event Time.
Diff, Exposure und Rehearsal
Zeitpunktvergleiche und defensive Simulation leiten Veränderungen ab, ohne daraus automatisch Severity oder Remediation zu machen.
Proof, Assurance und Exchange
Claims, Checkpoints, Offline-Bundles, Federation, Release-Provenance und authentifizierte History-Segmente halten ihre Beweisgrenzen explizit.
Vom beobachteten Zustand zur überprüfbaren Erklärung.
- 01
Beobachtungen aufnehmen
Autorisierte, defensive Quellen liefern normalisierte Fakten. Provenienz und Redaction werden bereits an der Collection-Grenze festgehalten.
- 02
T1 und T2 rekonstruieren
Mirror verifiziert Chronicle und Snapshot-Anker, materialisiert beide Event-Time-Zustände und berechnet einen deterministischen strukturellen Diff.
- 03
Änderung erklären und proben
Exposure-Gründe werden auf konkrete Graphkanten und Beobachtungen zurückgeführt; Kandidatenkontrollen verändern nur eine isolierte Simulation.
- 04
Evidenz exportieren und prüfen
Versionierte Artefakte bewahren exakte Digests, Policies und unbewiesene Präfixe. Ein Empfänger kann sie offline prüfen, ohne stärkere Historie zu unterstellen.
Beweisgrenzen sind Teil des Produkts – nicht Kleingedrucktes.
Mirror hält bewusst auseinander, was ein Hash, eine Signatur, eine zugelassene Identität, eine frische Beobachtung und eine vollständige Historie jeweils tatsächlich beweisen. Dieselbe Disziplin gilt für den Produktstatus.
Noch keine Produktionsfreigabe
Advanced Engineering Pre-Alpha bedeutet substanzielle Implementierung, aber keine Production-, Enterprise- oder SLA-Freigabe.
Loopback statt Remote-Betrieb
Die aktuelle Operator-API bindet ausschließlich an 127.0.0.1. HTTP Basic/RBAC ist eine lokale Pre-Exposure-Grenze und keine Erlaubnis für unverschlüsselten Multi-User-Betrieb.
Keine autonome Remediation
Simulation bleibt defensiv und isoliert. Produktionsänderungen benötigen explizite Freigabe, einen Deployment-Adapter und eine anschließende evidenzbasierte Verifikation.
Kein universeller Sicherheitswert
Risk, Policy Severity, Business Impact und Freshness-Grenzen gehören zur konkreten Organisation und bleiben ohne Deployment-Policy bewusst unbewertet.
Weit in der Engineering-Tiefe. Bewusst noch vor Produktion.
Der geprüfte Branch implementiert die Architektur bis M89 und konsolidiert sie in M90 hinter stabilen Vertrauensgrenzen. Die lokale Operator-Strecke ist end-to-end navigierbar; grüne exact-SHA CI, reale Deployments und Remote-Härtung bleiben offene Produktgates.
- Graph, Chronicle, Snapshots, Event-Time und Diff
- Exposure, Rehearsal, Blast Radius und Service Impact
- Evidence, Assurance, Offline-Bundles und Federation
- Lokale read-only Operator UI/API mit RBAC-Basis
- M90 Trust-Layer-Konsolidierung mit Golden Equivalence
- Ausführbare exact-SHA CI für Python 3.12 und 3.13
- Dauerhafter Dienstbetrieb und reale Collector-Integrationen
- Remote Identity, TLS, Rate Limits und Security Audit Logs
- Multi-User- und Deployment-Credential-Modell
- Sustained operational qualification
- Production-, Enterprise- und SLA-Freigabe
Ein lokaler Verifikationskern mit expliziten Vertrauensgrenzen.
VX / MIRROR / M90- Produktmodell
- Security Digital Twin und Continuous Assurance
- Entwicklungsstufe
- Advanced Engineering Pre-Alpha · M90
- Runtime
- Python 3.12+ · local-first · deterministischer Kern
- Persistenz und Integrität
- JSONL Chronicle · SHA-256 Hash Chains · kanonische Artefakte
- Operator Surface
- Read-only Loopback UI/API · optionale lokale Auth/RBAC
- Verifikationsmodell
- Offline-Bundles, signierte Checkpoints, Policies und historische Replay-Grenzen
- Nicht-Ziele
- Kein Scanner, Exploitation Framework, SIEM/EDR oder autonomer Remediator
- Produktfreigabe
- Keine Production-, Remote-, Enterprise- oder SLA-Freigabe
Fragen zu VENTEX Mirror
Kurze Antworten mit derselben Status- und Claim-Grenze wie der technische Produktstand.
Mirror rekonstruiert Infrastrukturzustände als temporalen Graphen, vergleicht Zeitpunkte, erklärt Exposure-Veränderungen, probt defensive Kandidatenkontrollen und bindet Security Claims an überprüfbare Evidenz. Offline-Verifikation, Federation, Release-Provenance sowie Case-, Custody- und Evidence-Delivery-Artefakte sind ebenfalls im Engineering-Stand implementiert.
Nein. Advanced Engineering Pre-Alpha beschreibt die erhebliche technische Tiefe, aber keine Production-, Enterprise- oder SLA-Freigabe. Exact-SHA CI, reale Deployment-Integration, dauerhafter Betrieb sowie Remote-Identity/TLS/Rate-Limit/Audit-Härtung bleiben offene Gates.
Sentinel normalisiert Security Events und koordiniert Incidents, Hunting, Evidence und SOC-Workflows. Mirror modelliert Infrastrukturzustand über Zeit, rekonstruiert Veränderungen und prüft, welche Evidenz eine technische Aussage tatsächlich trägt. Beide Produktgrenzen bleiben getrennt.
Nicht autonom. Candidate Controls werden auf einer isolierten Zustandskopie simuliert. Eine reale Produktionsänderung benötigt explizite Freigabe, einen vom Deployment bereitgestellten Adapter und eine nachgelagerte Verifikation am tatsächlich beobachteten Zustand.
Weil technische Struktur allein keine organisationsspezifische Business Severity beweist. Mirror kann Pfade, Veränderungen, Blast Radius und Service Impact ableiten; Gewichtung, Policy und Risikoentscheidungen bleiben bewusst beim jeweiligen Deployment.
