Die EU verschärft die Regeln für Cybersecurity. Jedoch gibt sie den zahllosen Herstellern der betroffenen Geräteklassen lediglich 13 Monate, um diese zu implementieren. Aus diesem Grund sind durchgängige Sicherheitskonzepte gefragt.
Seit 2014 regelt die Richtlinie 2014/53/EU, besser bekannt als Funkgeräterichtlinie oder »Radio Equipment Directive« – kurz: RED – Anforderungen an das Bereitstellen von Funkanlagen. Hierunter fallen auch Geräte, die Bluetooth, LoRaWAN, NFC, WiFi, ZigBee oder Z-Wave nutzen. In einem unlängst erschienenen Rechtsakt wurden nun Inhalte der Richtlinie speziell in Hinblick auf das Thema (Cyber-)Security und Datenschutz konkretisiert.
Ziel ist es, dass beispielsweise Maschinen, die mit dem Internet verbunden sind, keine »schädlichen Auswirkungen auf das Netz oder seinen Betrieb« ausüben dürfen sowie »Funktionen zum Schutz vor Betrug« und den Schutz personenbezogener Daten haben. Allerdings wurde bislang keine harmonisierte Regelung veröffentlicht, die in allen EU-Ländern gilt. Als Veröffentlichungsdatum ist der 30.6.2024 geplant. Bereits am 1.8.2025 müssen dann alle neu in den Verkehr gebrachten Geräte diese Vorgaben erfüllen.
Die beiden Richtlinien ETSI EN 303645 für Konsumgüter und IEC 62443 für Geräte der Industrieautomation und Steuerungssysteme geben Hinweise, wohin sich die Vorgaben entwickeln könnten; bis zur Veröffentlichung bleibt dieses Thema für die Entwicklungsabteilungen jedoch ein bewegliches Ziel. Bei einem technisch sehr tief in das System eingreifenden Aspekt wie Security ist der Zeitrahmen von 13 Monaten für ein vollständiges Redesign selten realistisch. Es sind also bereits heute Building Blocks gefordert, die mit großer Wahrscheinlichkeit die bürokratischen Vorstellungen erfüllen können und als Basis für die laufende Entwicklung nutzbar sind.
Prozessorarchitekturen wie Arm oder x86 (Intel) bieten mittlerweile eine durchgängige Kette an Sicherheitsfunktionen an, die den Standardangriffsmethoden einen hohen Widerstand liefern. Die zentralen Bestandteile sind:
Auch Betriebssystemhersteller drängen auf Schutzmaßnahmen in Hardware wie beispielsweise ein Trusted Platform Module (TPM) und machen dies teilweise zur Systemvoraussetzung. In Hardware ausgeführte TPM- und Secure-Element-Bausteine sind unabhängig von potenziellen Schwachstellen der CPU wie Side-Channel-Angriffe oder Speicherschutzverletzungen und belasten zudem nicht die System-Performance. Sie sind damit schwerer zu korrumpieren und liefern so ein höheres Sicherheitsniveau.
Verantwortungsvolle Modul- und Board-Hersteller bieten schon seit Jahren diese Bausteine als Bestückungsoption für ihre Baugruppen an. Anbieter wie TQ gehen noch einen Schritt weiter und verzahnen zusätzlich die ganze Sicherheitskette (s. o.) für ihre Board Support Packages (BSPs) und Linux-Adaptionen.
Entwickler sollten sich in Anbetracht der kommenden RED-Richtlinien Gedanken machen, bereits heute mehr in Security-Maßnahmen zu investieren – langfristig muss man mit einer Nachschärfung der Richtlinien rechnen, da heute noch als hochwertig geltende Schutzmaßnahmen für Software in wenigen Jahren schon ihre Wirkung verloren haben können. Hardware hat sich hier bislang als widerstandsfähiger erwiesen.
Bei sehr lange laufenden Projekten sollten Entwickler ebenfalls über die Möglichkeit eines vollständigen Wechsels der Security-Maßnahmen nachdenken, falls den Cyber-Kriminellen wieder ein fundamental neuer Angriffsvektor eingefallen ist und der alle bisherigen Schutzmethoden aushebelt. Hier hilft die Modultechnik, die im Bedarfsfall die neueste Prozessorgeneration mit der aktuellen Schutztechnologie zum Nachrüsten anbietet. Unter Umständen kann ebenso der Umstieg auf eine gänzlich neue CPU-Linie nötig sein, was größere Anpassungen nach sich zieht. Auch hier punktet die Modultechnik, da die Peripheriekomponenten des Carrier Boards häufig unverändert im Einsatz bleiben können.
Um dem Termindruck der kommenden EU-Vorgaben die Spitze zu nehmen, empfiehlt sich, bereits heute auf Modultechnik und Prozessorfamilien mit durchgängigen Security-Konzepten zu setzen. Zudem sollten alle Entwickler ihr Security-Know-how pflegen – man weiß nie, aus welcher Richtung die nächste Herausforderung kommt.