IoT Sicherheit ist ein Produktlebenszyklus: Lehren aus NIST IR 8259r1

Der moderne IoT-Wert wird durch ein System bereitgestellt: Geräte-Firmware, Mobil- oder Webanwendungen, Gateways, Cloud APIs, Identitätsdienste, Analysen und Betriebsunterstützung. Die Absicherung eines Geräts kann gemeinsame Anmeldeinformationen, nicht authentifiziertes APIs, unsichere Update-Zustellung oder eine aufgegebene Cloud-Abhängigkeit nicht kompensieren.

NIST IR 8259r1 betont Aktivitäten, die Hersteller während des gesamten Produktlebenszyklus durchführen sollten. Die praktische Implikation für Entwicklungsteams besteht darin, Bedrohungen und Verantwortlichkeiten für alle Komponenten und Organisationen zu modellieren, die an der Bereitstellung des vernetzten Erlebnisses beteiligt sind.

Sicherheitsaussagen wie „verschlüsselt“, „sicherer Start“ oder „Zero Trust“ sind zu weit gefasst, um als Leitfaden für die Implementierung oder Beschaffung zu dienen. Die Anforderungen sollten das geschützte Gut, den Akteur, den Betrieb, die Umgebung, die erwarteten Beweise und die Lebenszyklusverantwortung identifizieren.

Eine Anforderung könnte festlegen, dass jedes Gerät während der kontrollierten Bereitstellung eine eindeutige Identität erhält, Anmeldeinformationen ohne physischen Ersatz rotiert werden können, fehlgeschlagene Authentifizierungen ratenbegrenzt und beobachtbar sind und das Eigentum übertragen werden kann, ohne den Zugriff des vorherigen Mieters beizubehalten.

Kunden müssen wissen, womit das Produkt eine Verbindung herstellt, welche Daten es verarbeitet, wie es inventarisiert wird, wo Protokolle abgerufen werden können, wie Updates bereitgestellt werden und was zu tun ist, wenn Anmeldeinformationen oder Geräte kompromittiert werden.

Sicherheitsfunktionen, die nicht konfiguriert, überwacht oder erklärt werden können, stellen ein Betriebsrisiko dar. Produktteams sollten nach Möglichkeit maschinenlesbares Inventar, klare Ereignissemantik, rollenbewusste Verwaltung und Supportkanäle mit definierter Eskalation bereitstellen.

Ein koordinierter Prozess zur Offenlegung von Schwachstellen erfordert Besitz, Aufnahme, Triage, Reproduktion, Schweregradbewertung, Kundenkommunikation, Behebung und Freigabenachweise. Diese Verantwortlichkeiten erstrecken sich über die Entwicklungs-, Produkt-, Sicherheits-, Support- und Rechtsteams.

Die Update-Architektur bestimmt, ob eine Reaktion praktisch ist. Die Teams sollten den gestaffelten Rollout, unterbrochene Updates, Rollbacks, inkompatible Versionen, Offline-Geräte, widerrufenes Signaturmaterial und den Punkt testen, an dem nicht unterstützte Produkte isoliert oder außer Dienst gestellt werden müssen.

Fragen Sie für jede verbundene Komponente, wem sie gehört, wie sie identifiziert wird, worauf sie vertraut, wie sie sich ändert, welche Beweise sie ausgibt und wie sie den Dienst verlässt. Diese Fragen decken Lücken auf, die merkmalszentrierte Diagramme oft übersehen.

Das Ergebnis stellt keinen Zertifizierungsanspruch dar. Es handelt sich um ein sichereres Produkt: Kunden erhalten Funktionen und Informationen, die ihnen beim Risikomanagement während der gesamten Bereitstellung und des Betriebs helfen.