Lösung

Firmware-Sicherheit für OT Assets

Von der Analyse bis zum kontinuierlichen Monitoring: herstellerunabhängig, ohne Quellcode, ohne Agenten auf dem Zielgerät.

Produktansicht, Geräte-Übersicht

Das Ergebnis einer abgeschlossenen Firmware-Analyse: Risikoscore, priorisierte Maßnahmen und erkannte Komponenten.

BeispielanalyseDemo-Firmware OpenWrt x86-64 mit bekannten Schwachstellen, keine Kundendaten

Risikoscore

74 handlungsrelevante Schwachstellen

6 davon aktiv ausgenutzt (CISA KEV) · analysiert vor 2 Tagen

  • 5Kritisch
  • 21Hoch
  • 36Mittel
  • 12Niedrig

Score deterministisch aus den Befunden gerechnet, nicht geschätzt.

6
Aktiv ausgenutzt (KEV)
CISA-KEV-Katalog
2
Anmeldedaten offengelegt
3
Schlüssel und Zertifikate
128
Komponenten erkannt
Prioritäre Maßnahmen3
Beispielanalyse aus der Plattform

Leistungsbausteine

Einmal analysieren. Risiken dauerhaft im Blick.

01

Firmware-Analyse

Analyse von Firmware-Dateien oder extrahierten Ständen: automatisch, herstellerunabhängig und ohne Zugriff auf Quellcode. Erfasst werden Komponenten, Kryptomaterial, Zugangsdaten und Binär-Härtung.

02

SBOM-Transparenz

Strukturierte Sicht auf enthaltene Komponenten, Bibliotheken und Abhängigkeiten. CycloneDX-Export als Grundlage für CRA-Dokumentation und Vulnerability Management. Krypto-Inventar mit BSI TR-02102-1 Bewertung.

03

Schwachstellen-Bewertung

Identifikation bekannter CVEs je Komponente, gruppiert statt als flache Liste. Das Ausnutzungssignal kommt aus zwei behördlich geführten Katalogen: CISA KEV und EUVD. Was dort nicht steht, führt der Bericht nicht als ausgenutzt.

04

Kontinuierliches Monitoring

Laufende Zuordnung neuer Schwachstellen zu bereits analysierten Firmware-Assets. Zweistündlicher Abgleich gegen KEV und EUVD, tägliche CVE-Prüfung, automatische Alerts und Risikoscore-Updates.

Methode

Derselbe Stand, dasselbe Image, derselbe Befund

Jedes Ergebnis muss sich gegenüber Prüfern begründen lassen. Deshalb ist die Analyse als reproduzierbare Pipeline aufgebaut, und die Herkunft jeder Zuordnung steht unten in der Tabelle. Weil die Quellen laufend nachgezogen werden, arbeitet ein späterer Lauf gegen einen neueren Stand und kann zu anderen Befunden kommen.

  1. 01

    Upload

    Firmware-Image, oder ein Stand, den der Extractor gesichert hat (geschlossene Beta).

  2. 02

    Extraktion

    Dateisysteme und Binärdaten werden entpackt.

  3. 03

    Identifikation

    Komponenten, Versionen, Kryptomaterial, Zugangsdaten.

  4. 04

    CVE-Abgleich

    Bekannte Schwachstellen, angereichert mit KEV und EUVD.

  5. 05

    Bewertung

    Risikoscore und Priorisierung aus den Befunden.

  6. 06

    Monitoring

    Neue CVEs werden laufend bestehenden Analysen zugeordnet.

Die 18 CVE-Quellen der Engine mit Rang, Herausgeber, Abfrageart und Datenform
Distributionen05Die Distribution kennt ihre eigenen Backports. Deshalb steht sie in der Rangfolge vor dem Hersteller.RangQuelle · HerausgeberName · AbfrageRang: Position in der Prioritätsliste, bei Widerspruch gilt die kleinere Ziffer.
01Debian Security Tracker · Debiandebian-tracker · Snapshot des gesamten Trackers, Fixed-Version je Release
02Ubuntu CVE Tracker · Canonicalubuntu-tracker · Abfrage je Paket, ESM-Pocket wird ausgewiesen
03Red Hat CSAF-VEX · Red Hatredhat-vex · Offline-Spiegel, NEVRA mit Backport-Release
04Red Hat Security Data API · Red Hatredhat-tracker · Abfrage je Paket, Online-Fallback, standardmäßig aus
05Alpine secdb · Alpine Linuxalpine-secdb · Snapshot je Branch, main und community
Hersteller-CSAF05Der Hersteller spricht für sein eigenes Produkt. Seine Angabe schlägt den Aggregator.RangQuelle · HerausgeberName · AbfrageRang: Position in der Prioritätsliste, bei Widerspruch gilt die kleinere Ziffer.
07Siemens ProductCERT · Siemenscsaf-siemens · Spiegel über provider-metadata.json
08CERT@VDE, Phoenix Contact · CERT@VDEcsaf-certvde-phoenixcontact · Spiegel über provider-metadata.json
10SICK PSIRT · SICKcsaf-sick · Spiegel über provider-metadata.json
11KUNBUS PSIRT · KUNBUScsaf-kunbus · Spiegel über provider-metadata.json
12Red Hat Product Security · Red Hatcsaf-redhat · Spiegel über provider-metadata.json
Behörden05Behördliche Advisories und Kataloge. KEV und EUVD entscheiden keinen Konflikt, sie markieren belegte Ausnutzung.RangQuelle · HerausgeberName · AbfrageRang: Position in der Prioritätsliste, bei Widerspruch gilt die kleinere Ziffer. Plus: Anreicherung, ohne Rang.
06CERT-Bund · BSIcsaf-bsi · Spiegel über provider-metadata.json
09CISA CSAF · CISAcsaf-cisa · Spiegel über provider-metadata.json
16National Vulnerability Database · NISTnvd · Lokale Datenbank, Abfrage je CPE
+Known Exploited Vulnerabilities · CISAkev · Katalog, alle 2 Stunden synchronisiert
+EU Vulnerability Database · ENISAeuvd · Katalog, alle 2 Stunden synchronisiert, EUVD-Kennung je Befund
Ökosystem03Kernel-CNA und Aggregatoren. Sie füllen, was Distribution und Hersteller nicht abdecken, und stehen deshalb hinten.RangQuelle · HerausgeberName · AbfrageRang: Position in der Prioritätsliste, bei Widerspruch gilt die kleinere Ziffer.
13kernel.org vulns.git · Linux-Kernel-CNAkernel-vulns-git · Snapshot aus dem Git-Mirror, nur linux-kernel, Dateipfade je CVE
14GitHub Advisory Database · GitHubghsa · Abfrage je Paket und Ökosystem
15OSV.dev · OpenSSFosv · Abfrage je Paket und Ökosystem, etwa Debian:11 oder Alpine:v3.19

Die Quellen liefern die Zuordnung von Komponente zu CVE. Ob die Lücke auf dem Gerät erreichbar ist, entscheidet keine von ihnen; das steht im Bericht unter Abdeckung und Prüfumfang.

Die erste Frage

„Woher kommt eine Zuordnung, und was beweist sie?"

Eine Zuordnung entsteht aus zwei Dingen: der erkannten Komponente mit Version aus dem Image, und der Angabe einer der 18 Quellen, welche Versionen betroffen sind. Trifft die Version den Bereich, entsteht eine Zeile im Katalog, mit Quelle und Rang.

Was sie beweist: dass diese Komponente in dieser Version in diesem Image liegt und in der genannten Quelle als betroffen geführt wird. Was sie nicht beweist: dass der verwundbare Code auf dem Gerät erreichbar ist. Auf zwei ausgelieferten Releases einer Steuerung trägt der Versionsabgleich auf 98,5 bis 99,1 % der Zeilen die Markierung assumed. Der Bericht druckt diese Markierung an jede Zeile, damit ein Prüfer sieht, welche Aussage er in der Hand hält.

EU-gehostet

Analyse und Datenhaltung laufen auf Infrastruktur in der EU. Firmware verlässt Ihre Umgebung nur für die Analyse. Der CLI-Extractor (geschlossene Beta) sichert Stände direkt im eigenen Netz.

CRA Anhang I und § 30 BSIG, ein Bericht

Zu jedem Punkt aus Anhang I der CRA-Verordnung und § 30 BSIG eine Feststellung mit ihrer Grundlage. Sie entsteht aus den tatsächlichen Befunden der Analyse, nicht aus Selbstauskünften.

Der Bericht

Was ein Prüfer im Bericht findet

Der technische Bericht ist das Dokument, das Sie weitergeben. Die meisten Abschnitte stehen in jedem Bericht. Angriffsfläche, Kernel-Härtung und Normbezug werden nur gedruckt, wenn das Image die Eingabe dafür hergibt.

Abschnitte des technischen Berichts

  • Geltungsbereich und PrüfgegenstandUntersuchungsgegenstand, Firmware-SHA-256, Analyse-Zeitpunkt, und was nicht im Geltungsbereich liegt.
  • Management-KurzfassungRisikoscore, aktiv ausgenutzte CVEs, die ersten Maßnahmen.
  • Technische EinordnungArchitektur und Aufbau des Images vor den Befunden.
  • Methodik und PrüfgrundlageDie Stufen der Analyse und die Quellen der Zuordnung.
  • Priorisierung, vom Rohbefund zur HandlungWarum eine Zuordnung oben steht und eine andere unten.
  • Angriffsfläche und ExpositionNetzdienste und ihre Protokoll-Rolle, soweit sie aus dem Image hervorgehen.Steht im Bericht, wenn netzfähige Komponenten im Image erkannt wurden.
  • Vorrangig zu behandelnde BefundeDie Befunde, die zuerst dran sind, jeder mit Komponente, Kennung und Fundstelle.
  • Komponenten-SchwachstellenkatalogJe Komponente: Version, CVEs, Quelle, Ausnutzungs-Markierung.
  • Anmeldedaten und GeheimnisseKlartext-Passwörter, private Schlüssel, Zertifikate im Image.
  • Speicherschutz und Exploit-SchutzmaßnahmenRELRO, PIE, Stack Canary, NX je Binärdatei.
  • Kernel-Härtung und Kernel-ExpositionKernel-Konfiguration gegen die KSPP-Härtungsoptionen, Kernel-CVEs mit Dateipfaden.Steht im Bericht, wenn ein Kernel im Image liegt.
  • Weitere statische PrüfungenUnsichere Funktionsaufrufe, CWE-Schwachstellenmuster.
  • Software-Stückliste (SBOM), angelehnt an BSI TR-03183-2Das Komponenteninventar in der Form, die Behörden erwarten.
  • Abdeckung, Grenzen und Erklärung zum PrüfumfangWas geprüft wurde, was nicht, und woran man es erkennt.
  • Berichtsnachweis und DokumentenlenkungDokumentkennung, Firmware-SHA-256, Klassifizierung.

Dazu Befundliste, Maßnahmenplan, Normbezug, Glossar, Referenzen und der Komponenteninventar-Anhang. Ein zweiter Bericht fasst dieselben Befunde für die Leitung zusammen.

Was das Verfahren nicht prüft

  • Erreichbarkeit einer Lücke

    Eine Zuordnung sagt: diese Komponente in dieser Version ist von dieser CVE betroffen. Ob der verwundbare Code auf dem Gerät erreichbar ist, entscheidet die statische Analyse nicht. Deshalb steht neben jeder Zuordnung, ob die Version bestätigt oder angenommen ist.

  • Verschlüsselte Images

    Ein vom Hersteller verschlüsseltes Image wird nicht entschlüsselt. Die Extraktion weist es als Lücke aus, und jede Stufe dahinter bleibt ohne Eingabe.

  • Quellcode

    Die Analyse braucht keinen Quellcode und liest keinen. Was nur im Quellcode sichtbar wäre, etwa eine Logikschwäche ohne CVE, findet sie nicht.

  • Laufzeitverhalten

    Kein Gerät wird gestartet, kein Dienst angesprochen. Konfigurationen, die erst zur Laufzeit entstehen, liegen außerhalb des Prüfumfangs.

Jede dieser Grenzen steht im Bericht unter „Abdeckung, Grenzen und Erklärung zum Prüfumfang", mit der Zahl der untersuchten Wurzelverzeichnisse und den Stufen, die ohne Eingabe blieben. Ein Schätzwert tritt an keiner Stelle an ihre Stelle.

Warum einmalig nicht reicht

Ein Scan zeigt nur den Stand von heute

01

Neue CVEs werden täglich veröffentlicht

Ein Firmware-Stand, der heute sicher erscheint, kann morgen kritische Schwachstellen aufweisen, weil neue CVEs bekannt werden.

02

CISA KEV und EUVD listen aktiv ausgenutzte Schwachstellen

Wenn eine Schwachstelle aktiv ausgenutzt wird, zählt Reaktionszeit. Ohne Monitoring erfahren Sie davon zu spät.

03

Geräte bleiben jahrelang im Feld

Industrielle Assets haben Lebenszyklen von 10 bis 20 Jahren. Die Risikolage verändert sich laufend. Ihr Überblick muss mithalten.

Produktansicht, Flottenübersicht

Die aktuelle Lage je Gerät: Risikoscore, offene Schwachstellen und aktiv ausgenutzte CVEs.

Echte AnalysenÖffentlich verfügbare Firmware, mit dem Produkt analysiert. Keine Kundendaten.
Sicherheitsübersicht
Öffentliche Firmware
Flotten-Übersicht

5 Geräte · 5 Firmware-Stände · deterministisch

KEVvor 5 Std.EUVDvor 8 Std.NVDvor 1 Tag
Aktiv ausgenutzt (KEV)
72in 5 von 5 Geräten
Geräte
5
CVE-Zuordnungen
26.232
Kritische CVEs
673

CVE-Zuordnungen aus erkannter Komponente und Version. Kein Nachweis, dass die Schwachstelle auf dem Gerät erreichbar ist.

Zuerst prüfen
GerätRisiko
FW30 v04.08.09
Steuerung18 KEV99 kritisch5234 CVE-Zuordnungen
87
00.01.14.5
Industrie-Router7 KEV105 kritisch3383 CVE-Zuordnungen
96
00.07.x
Industrie-Router8 KEV64 kritisch4732 CVE-Zuordnungen
83
5 von 5 Geräten, vollständige Flotte auf der Plattform-Seite
Beispielanalyse aus der Plattform

Starten Sie mit einer ersten Firmware-Analyse

Sprechen Sie mit uns über ein Pilotprojekt oder sehen Sie sich die Plattform direkt in der interaktiven Demo an.