Von isolierten Embedded-Geräten zu internetfähigen Systemen: Warum PSIRT heute unverzichtbar ist

Wichtiges im Überblick

  • Konnektivität verändert alles: Sobald Embedded-Geräte mit Unternehmensnetzwerken, Cloud-Diensten oder dem Internet verbunden sind, werden sie Teil der größeren Angriffsfläche und nicht mehr isolierte Systeme.
  • Sicherheit ist technisch und menschlich: Reale Sicherheitsvorfälle entstehen oft durch Fehlkonfigurationen, Standardpasswörter oder Social Engineering – nicht nur durch Softwarefehler.
  • PSIRT ist ein kontinuierlicher Prozess, kein einmaliger Fix: Effektives PSIRT bedeutet fortlaufendes Schwachstellen-Monitoring (CVE/NVD), SBOM-Verwaltung, Bewertung von Auswirkungen und Anwendbarkeit, Patch-Management sowie klare Kommunikation.
  • Regulierung stärkt PSIRT-Praktiken: Anforderungen wie der EU Cyber Resilience Act und Industriestandards (IEC 62443) machen Lifecycle-Sicherheit und strukturiertes Schwachstellenmanagement von „nice to have“ zu unverzichtbar.

Dieser Artikel erklärt, warum moderne vernetzte Embedded-Systeme einen strukturierten PSIRT-Prozess benötigen, um Schwachstellen zu verwalten, die Sicherheit über den gesamten Lebenszyklus zu gewährleisten und Vorschriften wie den Cyber Resilience Act und IEC 62443 einzuhalten.

Historisch wurden Embedded-Systeme als isolierte Lösungen konzipiert, die streng definierte Funktionen innerhalb einer geschlossenen Infrastruktur erfüllten. In den Anfangstagen beschränkte sich das Bedrohungsmodell meist auf physischen Zugriff und interne Konfigurationsfehler.

Mit der Weiterentwicklung der Vernetzung und der Anbindung von Geräten an Unternehmensnetzwerke und das Internet hat sich die Risikolandschaft jedoch dramatisch erweitert. Remote-Zugriff, Cloud-Dienste und Integration mit externen Systemen machen Embedded-Geräte zu vollwertigen Teilnehmern der gesamten Cyber-Umgebung.

Sicherheit in dieser neuen Realität umfasst sowohl eine technische Ebene (Gerät, Netzwerk, Infrastruktur) als auch eine menschliche Ebene (Prozesse, Verhalten, Vertrauen und Fehler).

Der menschliche Faktor begann nicht mit IoT

Lange bevor es „smarte Wasserkocher“, intelligente Lampen und modernes IoT gab, nutzten Hacker Social Engineering, um die Informationen zu erhalten, die sie für unbefugten Zugriff benötigten.

Verbinden Sie Ihre Welt mit smarten IoT-Lösungen – powered by SaM Solutions.

Ein bekanntes Beispiel ist Kevin Mitnick, ein amerikanischer Computersicherheitsberater und verurteilter Hacker, der zeigte, dass Schwachstellen nicht immer in der Software, sondern in organisatorischen Prozessen und dem Vertrauen der Menschen liegen können. Damals war es nicht immer das System selbst, das verwundbar war – die Menschen vertrauten ihm (und dem Angreifer). Mitnick rief Administratoren an, gab sich als legitimer Benutzer aus und erhielt so den benötigten Zugriff.

Seine Arbeit veranschaulichte eine zentrale Erkenntnis, die bis heute gilt: Systemschutz ist nicht nur ein Stück Hardware zwischen externen und internen Netzwerken, sondern ein fortlaufender Prozess.

Das Problem der Internetanbindung: größer als es scheint

Heute haben viele Geräte entweder direkten Internetzugang (manchmal sogar mit statischer öffentlicher IP-Adresse) oder sind über Zwischenservices verbunden, die über vordefinierte Workflows mit ihnen interagieren.

Die Praxis zeigt, dass einige Geräte, die kritische Infrastrukturen unterstützen:

  • Keine effektiven Zugangsbeschränkungen haben,
  • Sicherheitsvorgaben auf Standardwerte belassen (z. B. admin/admin).

Praktisches Beispiel: öffentliche Warnungen als Routine

Dienste wie Shodan machen das Ausmaß des Problems sichtbar, indem sie internetexponierte industrielle Automatisierungsgeräte indexieren.

In Deutschland veröffentlicht das Bundesamt für Sicherheit in der Informationstechnik (BSI) regelmäßig Warnungen zu solchen Vorfällen und zeigt damit, dass dieses Thema nicht theoretisch ist. Heute ist es relevanter denn je.

Internetexponierte SCADA- und Energiesysteme (HMI-Panels, Webinterfaces für kritische Infrastruktur, Leitstellensysteme u. v. m.) stellen seit langem eine ernsthafte Bedrohung für öffentliche Sicherheit dar und werden dies weiterhin tun. Ein Beispiel, das dieses Risiko untersucht, ist die Studie „Investigation of risks for Critical Infrastructures due to the exposure of SCADA systems and industrial controls on the Internet based on the search engine Shodan“ der Technischen Hochschule Brandenburg.

Schwachstellen existieren sowohl auf physischer als auch auf Software-Ebene

Um Bedrohungen zu verhindern und zu mindern, nutzen Organisationen Mechanismen, die Schwachstellen über mehrere Ebenen analysieren, darunter:

  • Physische Zugriffspfade (z. B. über USB-Schnittstellen, CAN-Bus),
  • Software-Zugriffspfade (z. B. öffentlich zugängliche Ein-/Ausgangsports, offene Services, falsch konfigurierte Schnittstellen).

In diesem Umfeld reicht es für ein Produktionsunternehmen nicht aus, „ein sicheres System einmal zu bauen“. Sicherheit erfordert kontinuierliche Überwachung und Reaktion – genau hier kommt PSIRT ins Spiel.

Was ist PSIRT und warum es nicht „nur ein Team“ ist

PSIRT steht für Product Security Incident Response Team. Trotz des Namens ist PSIRT nicht einfach eine Gruppe von Personen, die für ein einzelnes Produkt (oder eine Produktlinie) verantwortlich ist. In reifen Organisationen wird PSIRT am besten als wiederholbarer Prozess verstanden, der Folgendes umfasst:

  • Überwachung öffentlich verfügbarer und abonnierter Sicherheitsbulletins, z. B. der National Vulnerability Database (NVD) und Common Vulnerabilities and Exposures (CVEs).
  • Bewertung, wie veröffentlichte Schwachstellen das Produkt beeinflussen.
  • Regelmäßige Bereitstellung von Sicherheitsupdates für eingesetzte Systeme, die das Team unterstützt.
    Koordination der Kommunikation mit Kunden, Klienten und externen Forschern.
  • Veröffentlichung von Sicherheitshinweisen und zugehöriger Dokumentation.

In der Praxis reagiert PSIRT nicht nur auf CVEs. Es umfasst kontinuierliche Überwachung, Risikobewertung, Behebung, Kommunikation, Dokumentation und Verbesserungen des Entwicklungsprozesses.

PSIRT gehört in den Secure Development Lifecycle

Ein wichtiger Punkt: PSIRT sollte in den Produktlebenszyklus integriert werden – oft als Secure SDLC / SSDLC diskutiert – und nicht als isolierte Funktion bestehen. Eine zugängliche Übersicht zu Grundlagen sicherer Entwicklung bietet die OWASP-Leitlinie Secure Development.

Externe Tests sind ebenfalls wichtig

Bewährt hat sich zudem die Zusammenarbeit mit unabhängigen Spezialisten, die Systeme von außen auf Schwachstellen testen, sogenannte Penetration Tester.

Warum Embedded-Produkte besonders schwer zu sichern sind

Embedded-Systeme enthalten fast immer einen komplexen Stack, zum Beispiel:

  • RTOS oder ein Betriebssystem auf Basis des Linux-/BSD-Kernels,
  • Drittanbieter-Bibliotheken (OpenSSL, mbedTLS, zlib usw.),
  • Gerätetreiber,
  • Proprietäre Softwarekomponenten,
  • Schnittstellen für Benutzerinteraktion (UI und/oder APIs).

Ja, es gibt wichtige Technologien, die unterstützen, wie:

  • Trusted Platform Module (TPM),
  • Robust Auto-Update Controller (RAUC),
  • Firmware-/Code-Signierung,
  • Rollback-Mechanismen für eine Rückkehr zu einer früheren Firmware-Version.

Aber das sind nur Teile des gesamten Sicherheitskonzepts. Ohne einen funktionierenden Prozess darum herum entfalten sie nicht ihren vollen Wert.

Was ein gut aufgebauter PSIRT-Prozess leisten sollte

Ein starker PSIRT-Prozess sollte mindestens Folgendes tun:

SBOM pflegen

Die Software Bill of Materials (SBOM) bedeutet, jede im System verwendete Softwarekomponente zu verfolgen und zu versionieren.

CVE-Tracking über alle Komponenten und Risikobewertung

Schwachstellen im gesamten Stack kontinuierlich überwachen und die Auswirkungen bewerten, üblicherweise mit dem Common Vulnerability Scoring System (CVSS).

Anwendbarkeit bewerten, nicht nur Schwere

Nicht jede Schwachstelle betrifft jedes Produkt gleichermaßen. Eine Schwachstelle könnte beispielsweise eine Funktion betreffen, die in Ihrem System nicht genutzt, deaktiviert oder nicht mit der betroffenen Funktionalität kompiliert wird.

Patches und Updates bereitstellen (inklusive Backports)

PSIRT initiiert typischerweise:

  • Komponentenuptdates,
  • Backport vorhandener Patches (wenn möglich),
  • Tests,
  • Veröffentlichung von Update-Paketen.

In besonders kritischen Fällen kann die Behebung sogar eine verpflichtende Produktrezertifizierung auslösen.

Lange Lebenszyklen von Geräten bedeuten lange Sicherheitsverpflichtungen

Da Embedded-Geräte (insbesondere in der industriellen Automatisierung) oft lange Lebenszyklen haben, wird von Herstellern erwartet, dass sie über längere Zeit Sicherheitsunterstützung und Updates bereitstellen.

Gleichzeitig hängt Sicherheit selbst bei einem ausgereiften PSIRT-Prozess nicht allein vom Hersteller ab. Die endgültige Sicherheitslage wird auch geprägt durch:

  • Systemkonfiguration,
  • Operative Disziplin,
  • Rechtzeitige Patch-Bereitstellung,
  • Organisatorische Kontrollen und Verfahren.

PSIRT, Regulierung und Standards: Es wird Pflicht

PSIRT wird zunehmend Teil einer umfassenderen Governance für Produktsicherheit.

Cyber Resilience Act in der EU

In der Europäischen Union verlangt der Cyber Resilience Act (CRA) von Herstellern digitaler Produkte, die Cybersicherheit über den gesamten Produktlebenszyklus sicherzustellen. Effektiv formalisiert der CRA Schwachstellenmanagement-Praktiken, die PSIRT-Prozesse traditionell implementiert haben.

Industrielle Automatisierung: IEC 62443

In der industriellen Automatisierung spiegeln sich ähnliche Erwartungen in der IEC-62443-Normenfamilie wider. Insbesondere IEC 62443-4-1 beschreibt Anforderungen an einen sicheren Entwicklungs-Lifecycle, einschließlich Schwachstellenmanagementprozessen.

Fazit

Moderne Embedded-Systeme sind keine isolierten Geräte mehr, die in geschlossenen Umgebungen arbeiten. Sobald sie direkt oder indirekt mit dem Internet und externen Diensten verbunden sind, übernehmen sie die Realität der modernen Bedrohungslandschaft.

Ein gut gestalteter PSIRT-Prozess ist nicht nur ein Compliance-Häkchen. Er ist ein praktischer Mechanismus, der Cyberrisiken reduziert, indem er kontinuierliches Schwachstellen-Monitoring, Anwendbarkeitsanalyse, Patching, Kommunikation und Verbesserungen der Sicherheit über den gesamten Lebenszyklus ermöglicht.

Wenn Ihre Organisation Embedded- oder IoT-Produkte entwickelt oder betreibt, kann SaM Solutions Sie dabei unterstützen, eine PSIRT-Funktion zu entwerfen, zu implementieren und zu optimieren – von der Einrichtung der Prozesse bis hin zum täglichen Schwachstellenmanagement.

Redaktionsrichtlinien
Einen Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Sie können diese HTML-Tags und Attribute verwenden Noch keine Stimmen : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>