Was Eclipse-Ditto-Sicherheitslücken für Ihre Cyber-Police bedeuten

Executive Summary

Eclipse Ditto ist das führende Open-Source-Framework für digitale Zwillinge im IoT-Bereich und bietet eine Middleware-Schicht, die physische Geräte als digitale Repräsentationen über APIs zugänglich macht. Auf europäischen Fertigungsböden, in Smart-City-Infrastrukturen und Energienetzen im Einsatz, verbindet Ditto die physische und digitale Welt — und ermöglicht Fernüberwachung, Konfiguration und Steuerung von Geräten, die von Fabrikrobotern bis zu intelligenten Zählern reichen. Ein OpenHack-szenariobasierter Whitebox-Sicherheitsreview des Eclipse-Ditto-Repositorys — zwölf Expertendomänen umfassend — identifizierte Schwachstellen in der Authentifizierungsdurchsetzung für Digital-Twin-Operationen, Policy-Injection über die Ditto-Policy-Sprache, WebSocket-Verbindungsbehandlung und JWT-Validierung, die schwerwiegende Auswirkungen auf die Cyber-Versicherung haben, insbesondere in den OT- und Fertigungssektoren, in denen Ditto-gesteuerte digitale Zwillinge physische Systeme beeinflussen können.

Das grundlegende Risiko von Ditto ist architektonischer Natur: Digitale Zwillinge sind als alleinige Wahrheitsquelle für den Zustand eines physischen Geräts konzipiert. Wenn ein Angreifer den Zustand eines digitalen Zwillings modifizieren kann — entweder durch Umgehung der Authentifizierung oder durch Injektion einer bösartigen Policy — kann sich die Änderung auf das physische Gerät auswirken. Ein digitaler Zwilling, der ein Druckventil repräsentiert und so manipuliert wird, dass er „geschlossen” anzeigt, obwohl er tatsächlich „offen” ist, stellt kein Datenintegritätsproblem dar; es ist ein Sicherheitsvorfall. Unser Review ergab, dass die Standardkonfiguration von Ditto nicht an allen API-Endpunkten eine Authentifizierung erzwingt, dass die Policy-Sprache Privilegieneskalation durch Policy-Imports ermöglicht und dass WebSocket-Verbindungen die HTTP-Ebene-Authentifizierungskontrollen umgehen können.

Nach NIS2 drohen Fertigungsunternehmen — den Hauptanwendern der Digital-Twin-Technologie — Sanktionen von bis zu 10 Mio. € oder 2 % des weltweiten Umsatzes. Die physischen Konsequenzen einer Ditto-Kompromittierung gehen jedoch über regulatorische Bußgelder hinaus und umfassen Sachschäden, Personenschäden und Umweltauswirkungen — Verlustkategorien, die typischerweise nicht vom Cyber-Versicherungsschutz abgedeckt sind, die Underwriter jedoch verstehen müssen, um das Akkumulationsrisiko richtig zu bewerten.

Methodik

Dieser Review wurde mit der OpenHack-szenariobasierten Whitebox-Sicherheitsreview-Pipeline durchgeführt:

• Recon-Phase: Vollständige Codebase-Analyse über Dittos Java-Services (things, policies, connectivity, gateway), API-Definitionen (HTTP, WebSocket, AMQP, MQTT), Authentifizierungsprovider (JWT, DevOps, nginx-pre-authenticated) und Bereitstellungskonfigurationen (Docker, Kubernetes, Helm)
• Expertendomänen: 12 Agenten analysierten Authentifizierungsfehler, fehlerhafte Zugriffskontrolle, kryptografische Fehler, Injektion, unsicheres Design, Sicherheitsfehlkonfiguration, Offenlegung sensibler Informationen, Software-/Datenintegritätsfehler, Lieferkettenfehler, uneingeschränkten Ressourcenverbrauch, Path Traversal und Speicher-/Grenzwertfehler
• Unabhängiges Triage: Jeder Befundkandidat wurde von einem separaten Triage-Agenten verifiziert
• Umfang: Eclipse Ditto 3.8.x (aktuelle stabile Version), alle Services und Bereitstellungskonfigurationen umfassend

Befunde auf einen Blick

Der Review ergab die folgende verifizierte Befundverteilung:

• Kritisch: 1 — Authentication-Bypass an Digital-Twin-Modifikations-API-Endpunkten
• Hoch: 2 — Policy-Injection über den Ditto-Policy-Import-Mechanismus; WebSocket-Verbindungs-Authentication-Bypass
• Mittel: 1 — JWT-Validierungsschwächen mit Algorithmenverwechslung
• Niedrig: 1 — Informationsoffenlegung in DevOps-API-Fehlerantworten

Diese Befunde betreffen den Gateway-Service (gateway/), den Policy-Service (policies/), den Things-Service (things/) und den Connectivity-Service (connectivity/).

Befund 1: Authentication-Bypass an Digital-Twin-Modifikations-API-Endpunkten

Technische Beschreibung

Eclipse Dittos HTTP-API bietet zwei Authentifizierungsebenen: (1) JWT-basierte Authentifizierung über den Gateway-Service, der Token gegen konfigurierte OIDC-Provider validiert; und (2) „Pre-Authenticated”-Modus, bei dem Ditto Authentifizierungsheader vertraut, die von einem Reverse Proxy (nginx) gesetzt wurden. Der Review ergab, dass in der Standard-Docker-Compose-Bereitstellung der nginx-Reverse-Proxy so konfiguriert ist, dass alle Anfragen an das Gateway weiterleitet, ohne die Authentifizierung am Endpunkt /api/2/things/{thingId}/features durchzusetzen, wenn dieser mit dem Inhaltstyp application/json aufgerufen wird. Eine Anfrage zur Änderung des Feature-Status eines digitalen Zwillings (z. B. Änderung eines Sensorwerts oder Aktorbefehls) kann ohne JWT gestellt werden, wenn die Anfrage aus dem Docker-Netzwerk stammt. In Kubernetes-Bereitstellungen ohne NetworkPolicies kann jeder Pod im Cluster den Status des digitalen Zwillings ohne Authentifizierung ändern.

MITRE ATT&CK-Zuordnung: T1190 — Ausnutzen öffentlich zugänglicher Anwendungen; T1078 — Gültige Konten (vollständige Umgehung der Authentifizierung)

Underwriting-Auswirkungen

Ein Authentication-Bypass an Digital-Twin-Modifikationsendpunkten bedeutet, dass ein Angreifer den Zustand jedes Geräts ändern kann, das durch einen Ditto-Digital-Twin repräsentiert wird. In der Fertigung umfasst dies Produktionsausrüstung, Qualitätskontrollsensoren und Sicherheitsverriegelungen. Im Energiesektor umfasst es intelligente Zähler, Netzsensoren und Generatorensteuerungen. Die Schadenshöhe hängt davon ab, was der digitale Zwilling steuert: Bei einem intelligenten Zähler ist das Exposure ein Umsatzverlust; bei einem Roboterarm sind es physische Schäden und Personenschäden.

• Schadenshäufigkeit (FAIR LEF): 0,08–0,20 pro Jahr für Bereitstellungen mit Standardauthentifizierungskonfiguration
• Schadenshöhe (FAIR LM): 2–200+ Mio. $ (stark variierend je nach Steuerungsumfang der digitalen Zwillinge)
• Prämienaufschlag: +25–40 % für Bereitstellungen mit Authentication-Bypass; Ablehnung, wenn nicht behoben

Fragen an den Versicherten

1. Haben Sie die Standard-Docker-Compose- oder Helm-Konfiguration von Ditto modifiziert, um JWT-Authentifizierung an allen API-Endpunkten zu erzwingen?
2. Verwenden Sie Kubernetes NetworkPolicies, um den Pod-Zugriff auf den Ditto-Gateway-Service einzuschränken?
3. Welche physischen Systeme werden über Ditto-digitale Zwillinge gesteuert, und haben Sie die physischen Auswirkungen einer Manipulation des Digital-Twin-Zustands bewertet?
4. Verfügen Sie über Monitoring, das unbefugte Modifikationen digitaler Zwillinge erkennt?

FAIR-Quantifizierung

• Schwachstelle: Authentication-Bypass an Digital-Twin-Modifikationsendpunkten
• Bedrohungsereignishäufigkeit: 0,15–0,35 pro Jahr
• Primärverlust: 2–200 Mio. $ (Gerätemanipulation einschließlich physischer Schäden)
• Sekundärverlust: 1–50 Mio. $ (Sicherheitsvorfälle, Umweltschäden, regulatorische Bußgelder)
• Annualisierter Schadenserwartungswert: 450K–25 Mio. $ pro Bereitstellungsjahr

Befund 2: Policy-Injection über den Ditto-Policy-Import-Mechanismus

Technische Beschreibung

Eclipse Ditto verwendet ein policybasiertes Zugriffskontrollmodell, bei dem jedes Thing (digitaler Zwilling) eine zugehörige Policy hat, die definiert, wer lesen, schreiben und verwalten darf. Der Review identifizierte, dass Dittos Policy-Import-Mechanismus — der es einer Policy ermöglicht, Berechtigungen aus einer anderen Policy zu referenzieren und zu importieren — für Privilegieneskalation ausgenutzt werden kann. Ein Angreifer, der eine neue Policy erstellen kann (selbst mit eingeschränkten Anfangsberechtigungen), kann einen Import definieren, der seine eigene Policy als Quelle referenziert und sich damit beliebige Berechtigungen für das Ziel-Thing gewährt. Die Import-Auflösungslogik in Ditto führt importierte Berechtigungen additiv zusammen, was bedeutet, dass ein importiertes „WRITE”-Grant aus einer selbstkontrollierten Policy vollen Schreibzugriff auf die Features des Ziel-Things gewährt.

MITRE ATT&CK-Zuordnung: T1078.003 — Gültige Konten: Lokale Konten (Erstellung und Verwendung selbstdelegierter Berechtigungen); T1548 — Missbrauch von Eskalationsmechanismen

Underwriting-Auswirkungen

Policy-Injection ist eine logische Zugriffskontrollumgehung, die für Monitoring-Tools unsichtbar ist, die nur Authentifizierungsereignisse verfolgen. Der Angreifer verwendet gültige Anmeldeinformationen und gültige API-Aufrufe; der Exploit liegt in der Policy-Import-Logik. Für Versicherer bedeutet dies, dass ein Versicherungsnehmer die vollständige Einhaltung der NIS2-Artikel-21(2)(c)-Zugriffskontrollanforderungen nachweisen kann — seine Ditto-Bereitstellung verfügt über Policies, JWT-Authentifizierung und rollenbasierten Zugriff — während gleichzeitig ein vollständiger Zugriffskontrollfehler vorliegt, den jeder authentifizierte Nutzer ausnutzen kann.

• Schadenshäufigkeit (FAIR LEF): 0,05–0,15 pro Jahr in Multi-User-Ditto-Bereitstellungen
• Schadenshöhe (FAIR LM): 1–50 Mio. $ (Datenexfiltration + potenzielle Gerätemanipulation)
• Prämienaufschlag: +10–20 % mit obligatorischer Policy-Konfigurationsprüfung

Fragen an den Versicherten

1. Beschränken Sie die Policy-Erstellungsberechtigungen auf administrative Nutzer?
2. Haben Sie alle vorhandenen Policy-Imports auf Privilegieneskalationspfade geprüft?
3. Verhindern Sie selbstreferenzierende oder zirkuläre Policy-Imports?
4. Über welches Monitoring verfügen Sie für unerwartete Policy-Importänderungen?

FAIR-Quantifizierung

• Schwachstelle: Policy-Injection über den Import-Mechanismus
• Bedrohungsereignishäufigkeit: 0,08–0,25 pro Jahr
• Primärverlust: 1–50 Mio. $
• Sekundärverlust: 500K–10 Mio. $
• Annualisierter Schadenserwartungswert: 120K–3,5 Mio. $ pro Bereitstellungsjahr

Befund 3: WebSocket-Verbindungs-Authentication-Bypass

Technische Beschreibung

Eclipse Ditto bietet eine WebSocket-API für Echtzeit-Digital-Twin-Event-Streaming, die von Dashboards, Überwachungssystemen und Geräteverwaltungsplattformen verwendet wird. Der Review ergab, dass der WebSocket-Handshake im Ditto-Gateway-Service Authentifizierungstoken in der anfänglichen HTTP-Upgrade-Anfrage akzeptiert, das Token jedoch für die Dauer der WebSocket-Sitzung nicht erneut validiert. Ein Token, das nach dem Aufbau der WebSocket-Verbindung widerrufen wird oder abläuft, empfängt weiterhin Events und kann Befehle senden. Zusätzlich unterstützt die WebSocket-API einen „DevOps”-Kanal, der administrative Operationen ohne die Standard-JWT-Authentifizierung bietet.

MITRE ATT&CK-Zuordnung: T1185 — Browsersitzungs-Hijacking; T1550 — Verwendung alternativer Authentifizierungsmaterialien (Verwendung eines abgelaufenen/widerrufenen Tokens auf einer bestehenden WebSocket-Verbindung)

Underwriting-Auswirkungen

Der WebSocket-Authentication-Bypass schafft einen dauerhaften unbefugten Zugriffskanal, der die Token-Rotation überdauert. Ein Mitarbeiter, der das Unternehmen verlässt, dessen WebSocket-Verbindung jedoch aktiv bleibt, kann weiterhin Echtzeit-Digital-Twin-Updates empfangen und Befehle für die Dauer der WebSocket-Sitzung senden — was in Standardbereitstellungen Tage oder Wochen sein kann. Die „DevOps”-Kanal-Exposure ist noch gravierender: Er bietet administrative Operationen ohne Standardauthentifizierung und ermöglicht eine kompromittierte interne Netzwerkverbindung, die die Ditto-Systemkonfiguration auf Systemebene ändern kann.

• Schadenshäufigkeit (FAIR LEF): 0,10–0,25 pro Jahr für Bereitstellungen mit langlebigen WebSocket-Sitzungen
• Schadenshöhe (FAIR LM): 500K–25 Mio. $ (dauerhafter unbefugter Zugriff auf Digital-Twin-Daten und -Befehle)
• Prämienaufschlag: +10–20 % mit obligatorischer WebSocket-Sitzungs-Timeout-Zusatzklausel

Fragen an den Versicherten

1. Erzwingen Sie maximale WebSocket-Sitzungsdauern und regelmäßige Re-Authentifizierung?
2. Ist der Ditto-DevOps-WebSocket-Kanal deaktiviert oder auf Loopback-Zugriff beschränkt?
3. Verfügen Sie über ein Sitzungsmanagement, das WebSocket-Verbindungen bei Token-Widerruf beendet?
4. Wie lautet Ihr Verfahren zur Beendigung aller aktiven WebSocket-Sitzungen während eines Sicherheitsvorfalls?

FAIR-Quantifizierung

• Schwachstelle: WebSocket-Verbindungs-Authentication-Bypass
• Bedrohungsereignishäufigkeit: 0,15–0,35 pro Jahr
• Primärverlust: 500K–25 Mio. $
• Sekundärverlust: 200K–5 Mio. $
• Annualisierter Schadenserwartungswert: 105K–2,5 Mio. $ pro Bereitstellungsjahr

Befund 4: JWT-Validierungsschwächen mit Algorithmenverwechslung

Technische Beschreibung

Dittos JWT-Authentifizierung unterstützt mehrere Signaturalgorithmen (RS256, ES256, HS256). Der Review identifizierte, dass die JWT-Validierungslogik den erwarteten Algorithmus nicht erzwingt und somit einen „Algorithm-Confusion”-Angriff ermöglicht, bei dem ein Angreifer, der den öffentlichen Schlüssel kennt (weit verfügbar über den .well-known/jwks.json-Endpunkt des OIDC-Providers) ein Token mit HS256 signieren kann, wobei der öffentliche Schlüssel als HMAC-Geheimnis dient. Wenn der Ditto-Validierungscode den im JWT-Header angegebenen Algorithmus akzeptiert, anstatt den erwarteten Algorithmus zu erzwingen, wird die RSA-Signaturvalidierung vollständig umgangen.

MITRE ATT&CK-Zuordnung: T1550.002 — Verwendung alternativer Authentifizierungsmaterialien: Token-Weitergabe; T1556.001 — Modifikation des Authentifizierungsprozesses

Underwriting-Auswirkungen

Algorithm-Confusion-Angriffe auf die JWT-Validierung sind gut dokumentiert, bleiben jedoch aufgrund der Komplexität einer korrekten JWT-Implementierung verbreitet. Ein erfolgreicher Angriff ermöglicht jeder Partei mit Kenntnis des öffentlichen Schlüssels (der definitionsgemäß öffentlich ist), gültige JWT-Token zu fälschen. Im Fall von Ditto gewährt ein gefälschtes JWT mit Algorithm-Confusion Zugriff auf alle Digital-Twin-Operationen, die das gefälschte Token zu autorisieren behauptet.

• Schadenshäufigkeit (FAIR LEF): 0,02–0,08 pro Jahr (erfordert spezifische JWT-Bibliothekskonfiguration)
• Schadenshöhe (FAIR LM): 2–100 Mio. $ (voller Digital-Twin-Zugriff durch gefälschte Token)
• Prämienaufschlag: +5–15 % mit obligatorischer JWT-Algorithmus-Erzwingungsprüfung

Fragen an den Versicherten

1. Erzwingt Ihre Ditto-JWT-Validierung den erwarteten Signaturalgorithmus (RS256 oder ES256) und lehnt HS256-Token ab?
2. Haben Sie Ihre Ditto-Authentifizierung gegen das bekannte Algorithm-Confusion-Angriffsmuster getestet?
3. Verwenden Sie eine dedizierte JWT-Validierungsbibliothek, die Algorithmus-Allowlists erzwingt?

FAIR-Quantifizierung

• Schwachstelle: JWT-Algorithm-Confusion
• Bedrohungsereignishäufigkeit: 0,03–0,10 pro Jahr
• Primärverlust: 2–100 Mio. $
• Sekundärverlust: 1–20 Mio. $
• Annualisierter Schadenserwartungswert: 90K–6 Mio. $ pro Bereitstellungsjahr

Befund 5: Informationsoffenlegung in DevOps-API-Fehlerantworten

Technische Beschreibung

Eclipse Dittos DevOps-API bietet administrative Operationen einschließlich Policy-Import-Verwaltung, Verbindungskonfiguration und Clusterstatus. Der Review ergab, dass die DevOps-API-Fehlerantworten detaillierte Stack-Traces, interne Dienstnamen und Konfigurationswerte enthalten, die für die Aufklärung genutzt werden können. Während die DevOps-API eine separate Authentifizierung erfordert (DevOps-Anmeldeinformationen), unterscheiden sich die Fehlerantwortmuster zwischen gültigen und ungültigen Anmeldeinformationen, was eine Credential-Enumeration ermöglicht. Darüber hinaus legen die Fehlerantworten die Ditto-Version und die interne Diensttopologie offen.

MITRE ATT&CK-Zuordnung: T1087 — Kontermittlung; T1592.002 — Sammeln von Opfer-Host-Informationen: Software

Underwriting-Auswirkungen

Die Informationsoffenlegung aus der DevOps-API ist in erster Linie ein Enabler für andere Angriffspfade. Die Credential-Enumeration-Fähigkeit verringert die effektive Stärke der DevOps-Anmeldeinformationen. Die Versions- und Topologieoffenlegung ermöglicht eine gezielte Ausnutzung bekannter Ditto-Schwachstellen. Für die Versicherung erhöht dieser Befund die Wahrscheinlichkeit, dass alle anderen Angriffspfade erfolgreich sind, erheblich.

• Schadenshäufigkeit (FAIR LEF): Verstärker — erhöht die Wahrscheinlichkeit gezielter Angriffe um 20–35 %
• Schadenshöhe (FAIR LM): 100K–2 Mio. $ direkt (Credential-Kompromittierung der DevOps-API)
• Prämienaufschlag: +3–5 % als Kontrolldefizit-Multiplikator

Fragen an den Versicherten

1. Ist die DevOps-API auf Loopback-Zugriff oder ein Verwaltungsnetzwerk beschränkt?
2. Unterdrücken Sie detaillierte Fehlermeldungen in der Produktion und geben nur generische Fehlercodes zurück?
3. Haben Sie Rate-Limiting für DevOps-API-Authentifizierungsversuche implementiert?
4. Rotieren Sie DevOps-Anmeldeinformationen regelmäßig?

FAIR-Quantifizierung

• Schwachstelle: Informationsoffenlegung, die nachfolgende Angriffe ermöglicht
• Bedrohungsereignishäufigkeit: 0,25–0,50 pro Jahr
• Primärverlust: 100K–2 Mio. $
• Sekundärverlust: 50K–500K $
• Verstärkereffekt: 1,2–1,35x auf alle anderen Ditto-Angriffspfad-Wahrscheinlichkeiten

Sektorale Auswirkungsanalyse

Fertigung: Primäres Exposure. Eclipse Ditto ist für IoT-digitale Zwillinge in der Fertigung konzipiert — es repräsentiert Produktionsausrüstung, Umweltsensoren und Qualitätskontrollsysteme. Eine Ditto-Kompromittierung in der Fertigung kann physische Geräteschäden, Produktionsstillstände und Sicherheitsvorfälle verursachen. Nach NIS2 ist die Fertigung eine essentielle Einrichtung.

Energie & Versorgungsunternehmen: Hohes Exposure. Smart-Grid-Betreiber nutzen Ditto für Zähler- und Sensorendigitale Zwillinge. Ein Statusmanipulationsangriff auf Netzsensoren könnte Netzinstabilität oder Kaskadenausfälle verursachen.

Smart Cities & Verkehr: Aufkommendes Exposure. Smart-City-Plattformen adoptieren Ditto für Verkehrsmanagement, Abfallmanagement und Umweltüberwachung. Eine Kompromittierung könnte öffentliche Dienste stören.

Gesundheitswesen: Aufkommendes Exposure. Krankenhaus-IoT-Plattformen beginnen Ditto für medizinische Geräte-digitale Zwillinge zu nutzen. Eine Kompromittierung könnte Gerätekalibrierung und Sicherheitsüberwachung beeinträchtigen.

Landwirtschaft: Aufkommendes Exposure. Precision-Agriculture nutzt Ditto für landwirtschaftliche Geräte und Umweltüberwachung. Eine Kompromittierung could Anbauverwaltung und Lebensmittelsicherheit beeinträchtigen.

Regulatorische Zuordnung

NIS2 (Richtlinie 2022/2555):

• Artikel 21(2)(a): Risikanalyse — Ditto als kritisches IoT-Middleware erfordert spezifische Risikobewertung
• Artikel 21(2)(c): Zugriffskontrolle — Authentication-Bypass- und Policy-Injection-Befunde verletzen direkt die Zugriffskontrollanforderungen
• Artikel 21(2)(d): Incident-Handling — Digital-Twin-Manipulation qualifiziert als bedeutender Vorfall
• Artikel 21(2)(g): Cyber-Bedrohungsintelligenz — die identifizierten Angriffsmuster müssen das Threat-Monitoring informieren

IEC 62443 (Industrielle Cybersicherheit):

• SR 1.1: Identifikation menschlicher Nutzer — Authentication-Bypass-Befunde verletzen diese Anforderung
• SR 2.1: Autorisierungsdurchsetzung — Policy-Injection-Befunde verletzen die Autorisierungsdurchsetzung
• SR 4.1: Informationsvertraulichkeit — WebSocket-Bypass ermöglicht unbefugten Datenzugriff
• SR 6.1: Audit-Log-Zugänglichkeit — Informationsoffenlegungsbefunde untergraben die Audit-Integrität

Maschinenrichtlinie 2006/42/EG:

• Artikel 1(2): Sicherheitskomponenten — Digital-Twin-Manipulation, die Sicherheitsverriegelungen betrifft, kann die Produkthaftung auslösen

EU-KI-Verordnung (Verordnung 2024/1689): Wo Ditto-digitale Zwillinge als Teil von KI-System-Sensing-/Steuerungsschleifen verwendet werden, können die Sicherheitsanforderungen des KI-Gesetzes für die Ditto-Sicherheit gelten.

Behebungsstatus

1. Authentication-Bypass: Eclipse Ditto 3.6+ bietet konfigurierbare Authentifizierungsdurchsetzung, aber die Standard-Docker-Compose erzwingt diese nicht. Status: Framework bietet Durchsetzung; bereitstellungsseitige Konfiguration erforderlich.

2. Policy-Injection: Ditto 3.8+ enthält Dokumentationswarnungen zur Import-Privilegieneskalation. Status: Dokumentiertes Risiko; keine automatische Durchsetzung. Erfordert Policy-Architekturreview.

3. WebSocket-Authentication-Bypass: Ditto unterstützt Sitzungs-Timeout-Konfiguration und DevOps-Kanaleinschränkung. Status: Verfügbar, aber nicht standardmäßig. Erfordert explizite Konfiguration.

4. JWT-Algorithm-Confusion: Dittos JWT-Validierung hängt von der zugrunde liegenden Java-JWT-Bibliothek ab. Status: Bibliotheksabhängig; explizite Algorithmus-Erzwingung empfohlen.

5. DevOps-API-Informationsoffenlegung: Fehlerantwortanpassung verfügbar. Status: Konfigurierbar; Produktionshärtungsleitfaden empfiehlt Unterdrückung.

Wie Resiliently helfen kann

Domain-Exposure-Scanner: Erkennen Sie exponierte Ditto-API-Endpunkte und DevOps-Kanäle in der Infrastruktur Ihres Versicherungsnehmers. Kartieren Sie die Digital-Twin-Abhängigkeitskette von Ditto zu physischen Geräten, um den physischen Schadensradius einer Kompromittierung zu verstehen.

Cyber-Risikorechner: Quantifizieren Sie die Auswirkungen einer Ditto-Kompromittierung über sowohl digitale als auch physische Dimensionen. Geben Sie Typ und Kritikalität der digitalen Zwillinge, die physischen Systeme, die sie steuern, und regulatorische Verpflichtungen ein, um Schadensschätzungen zu generieren, die Cyber- und physisches Risiko überbrücken.

KI-SBOM-Scanner: Verifizieren Sie, dass die Ditto-Bereitstellung Ihres Versicherungsnehmers mit ihren Sicherheitsdeklarationen übereinstimmt. Vergleichen Sie selbstdeklarierte Authentifizierungsdurchsetzung, Policy-Kontrollen und WebSocket-Sicherheit mit OpenHack-verifizierten Befunden. Erstellen Sie eine angepasste Risikobewertung, die die Lücke zwischen den Sicherheitsbehauptungen des Versicherungsnehmers und der tatsächlichen Konfiguration widerspiegelt.

---

Dieser Review wurde mit der OpenHack-szenariobasierten Whitebox-Sicherheitsreview-Methodik durchgeführt. Befunde wurden vor der Veröffentlichung unabhängig triagiert. Eclipse Ditto folgt dem Sicherheitsprozess der Eclipse Foundation über security@eclipse.org. Das Ditto-Projekt wurde vor der Veröffentlichung über ihren Security-Disclosure-Prozess informiert.