Die Kategorie der IoT-Produktsicherheitsplattformen ist relativ neu. Die Lösungen werden auch wie folgt bezeichnet: „Firmware-Analyse“, „Sicherheit der OT-/IoT-Software-Lieferkette“, „automatisierte Sicherheit für Embedded Systems“, „Bewertung von Schwachstellen von vernetzten Geräten“, „Reverse-Engineering/Digital Twin“ oder „automatisierte Sicherheit und Compliance für digitale Produkte“. Die Lösungen unterscheiden sich deutlich in dem, was sie aufnehmen, analysieren und ausgeben können.
Während einige Anbieter auch versuchen, den Markt für Betreiber von OT-Anlagen zu adressieren, zielen alle Anbieter auf Entwickler von IoT-Produkten ab, z.B. Hersteller von Sensoren und elektronischen Steuerungssystemen.
Welche nicht offensichtlichen Anforderungen könnten relevant sein?
- Was wird tatsächlich für einen sicheren Engineering-Prozess benötigt? Z. B.:
- Erstellung einer Software Bill of Materials (SBOM) für die Firmware?
- Softwarelizenzmanagement?
- Statische/dynamische Tests von nicht kompilierten Quellcodes?Überprüfung von Drittanbieter-/Open-Source-Software auf Sicherheitslücken mit Hilfe von SBOMs?
- Überprüfung von Binärdateien auf Sicherheitslücken?
- Ist eine On-Premise-Lösung möglich bzw. welche Daten werden wohin zur Analyse geschickt?
- Welche Standard-Integrationen gibt es, z. B. mit der aktuell verwendeten CI-/CD-Toolchain oder der Software für das Management des Anwendungslebenszyklus? Was kann über eine REST API implementiert werden, und wie hoch wäre der Aufwand für Umsetzung und Pflege der Schnittstelle?
- Werden falsch-positive Ergebnisse herausgefiltert, indem die Verwertbarkeit im Hinblick auf Prozessorarchitektur, Dateisysteme oder andere relevante Aspekte überprüft wird? Dies kann einen enormen Unterschied bei der Arbeitslast des Entwicklungsteams machen. Falls ja, welche Architekturen werden unterstützt?
- Welche Bedrohungsdaten-Feeds werden verwendet, um Sicherheitslücken aufzudecken? Nur CVE/NVD oder auch proprietäre bzw. kundenspezifische Datenbanken?
- Werden Fachdienstleistungen angeboten, z. B. bei Bedarf Sicherheitsbewertungen und Pentests? Das kann hilfreich sein, um Probleme schneller zu beheben oder die Kapazität des internen Engineering-Teams bei Engpässen zu erhöhen.
Wer sind die typischen Anbieter?
Abhängig von den tatsächlichen Anforderungen könnten die folgenden Anbieter geeignet sein: Aqua Security, aDolus, Cybellum, Finite State, Firmalyzer, JFrog, Moabi, Netrise, OneKey (ehemals IoT Inspector) oder Synopsys Black Duck etc.
Was sind die typischen Kosten, die budgetiert werden sollten?
Die Pricing-Modelle unterscheiden sich bei einigen Anbietern stark, je nach Anzahl Scans bzw. Anzahl Projekte/Produkte. Das führt typischerweise zu der Frage, wo die Grenze zwischen einem Produktderivat/-Update und einem neuen Produkt zu ziehen ist (nach unseren Informationen könnte als Faustregel 20 Prozent Änderungen im Quellcode bzw. teilweise sogar geänderte Compiler-Einstellungen gelten). Andere Anbieter berechnen jährliche Lizenzgebühren, die eine unbegrenzte Anzahl an Scans umfassen und so Good Practices in der Entwicklung unterstützen (d.h. regelmäßige Scans nach Sicherheitslücken).
Auf der einen Seite sind also realistische Szenarien für die tatsächliche Nutzung erforderlich. Auf der anderen Seite kann ein sorgfältiger Vergleich der Anbieteroptionen und -lösungen ein signifikantes Einsparpotenzial für ähnliche Funktionen bieten.
Sind Sie an Überlegungen zum Einkauf von OT Remote-Access-Lösungen interessiert? Wir haben zu diesem Thema ebenfalls einen Beitrag angefertigt. Zum Artikel hier entlang!
Übrigens: Der Artikel spiegelt unseren aktuellen Wissensstand wider – aber auch wir lernen jeden Tag dazu. Fehlen aus Ihrer Sicht wesentliche Aspekte, oder haben Sie eine andere Perspektive auf das Thema? Gerne diskutieren wir mit Ihnen und weiteren Experten in Ihrem Hause die gegenwärtigen Entwicklungen vertiefend und freuen uns über Ihr Feedback sowie Anfragen zu einem Austausch.
Und zuletzt noch: Nennungen (oder die fehlende Nennung) von Anbietern stellt keine Empfehlung seitens CyberCompare dar. Empfehlungen sind immer abhängig von der kundenindividuellen Situation.
