Typischerweise kommen dem Linux-System in der Automatisierungstechnik Aufgaben im Bereich Datenaggregation und -prozessierung, Kommunikation und Visualisierung zu. Für safetykritische Steuerungen sind häufig ein weiterer Mikroprozessor, ein FPGA oder auch ein dedizierter Kern einer Mehrkern-CPU (AMP-Ansatz) zuständig. Gegenüber der ‚Außenwelt‘ liegen diese safetykritischen Kom­ponenten häufig ‚hinter‘ dem Linux-System und werden in Hinblick auf ­Security-Anforderungen durch das Linux-System abgeschirmt.

Security meint dabei weitaus mehr als nur Datensicherheit. Viel bedeutsamer sind häufig Know-how- und insbesondere Manipulationsschutz. Das TÜV-Projekt ‚Security4Safety‘ macht das ebenso deutlich, wie – wenn auch branchenfremd – eine FDA-Entscheidung aus dem Jahr 2016 im Bereich Medizintechnik, bei der erstmals eine bereits zugelassene Infusionspumpe aufgrund von Security-Mängeln auch als funktional unsicher eingestuft wurde. Mit der Novelle des IT-Sicherheitsgesetzes schlagen sich die erweiterten Anforderungen in rechtlichen Rahmenbedingungen nieder.

Während des Secure-Boot-Prozesses wird die Authentizität jedes einzelnen Software-Layers geprüft.

© Emlix

Grundsätzlich gilt, dass zwar viel über Netzwerk-Attacken zu lesen ist, die direkten Manipulationsversuche am Gerät aber mindestens ebenso gefährlich sind. Es muss daher unterbunden werden, nicht authentifizierte Software auf dem Gerät auszuführen. Damit jedoch die Verifikation sicher erfolgen kann, müssen die ‚zuständigen Instanzen‘ des Software-Systems ihrerseits authentifizierbar sein. Damit erklärt sich der Bedarf nach einem abgesicherten Boot-Prozess (Secure Boot), also der Absicherung des gesamten Software-Initialisierungsprozesses von Anfang an. Er startet bei der so genannten root-of-trust und überprüft die Authentizität jedes einzelnen Software-Layers, bevor dessen Ausführung zugelassen wird.

Die gute Nachricht ist, dass auf nahezu allen modernen 32- oder 64-Bit-Prozessoren Komponenten vorhanden sind, die einen Secure Boot unterstützen. Wie diese aussehen, ist CPU-spezifisch. Leider ist die – wiederum spezifische – Firmware, mit der Krypto-Einheiten und geschützte Speicherbereiche genutzt werden können, allzu häufig nicht öffentlich, was die konkrete Inbetriebnahme und Nutzung der Module erschweren kann. Mit einem einfachen Einschalten der Security-Funktionalität ist es kaum getan. Dabei dient die Geheimhaltung weniger der Sicherheit, sondern soll eher Reverse Engineering verhindern. Auch die Portabilität der Security-Lösungen ist damit häufig eingeschränkt.

Wie schon erwähnt, muss frühzeitig definiert werden, wann der Root Key und abgeleitete Schlüssel zu generieren sind und zu welchem Zeitpunkt die Aktivierung der Security-Funktionalität erfolgt. Manch einer hat sich schon aus seinem eigenen System ausgesperrt. Gegebenenfalls werden nachgeordnete Keys erst bei der Installation generiert, so dass es neben dem Root Key des Herstellers einen Key gibt, der nur dem Kunden bekannt ist. Dabei gilt, dass Schlüssel für die Verschlüsselung und Authentifizierung geschützt und separat von sonstiger Software in einem nichtflüchtigen Speicher verschlüsselt abgelegt werden sollten.

Wer hat welche Rechte?

Für die spätere Integration und Inbetriebnahme ist schließlich die Frage zu klären, wer welche Rechte auf dem System hat. Bei der Erstinbetriebnahme muss in der Regel die gegenseitige Authentifizierung aller End-Punkte erstmalig erfolgen. Hier stehen im Linux-Kontext verschiedene Technologien zum Generieren und Austausch von Zertifikaten zur Verfügung, die über Jahre und in unterschiedlichen Anwendungskontexten etabliert sind. Für die Authentifizierung des Backend-Servers beim Verbindungsaufbau wird heute meist TLS, die Weiterentwicklung von SSL, genutzt.

Geht der Verbindungsaufbau vom Embedded-Gerät aus, kann man auf von außen erreichbare Dienste verzichten. Erst wenn der verschlüsselte Kanal etabliert ist, lassen sich Daten sicher übertragen – unabhängig davon, ob es sich um Anlagendaten in Richtung Server oder Updates beziehungsweise Steuerdaten in Richtung Device handelt. Um wiederum die Authentizität des einzelnen Datums prüfen zu können, sollte in beiden Richtungen mit Signaturen gearbeitet werden. Hierfür stehen beispielsweise GnuPG oder OpenSSL zur Ver­fügung. In jedem Fall muss Update-Software signiert sein, damit ihre Authentizität sowie auch Integrität überprüft werden kann.

Bei hohen Security-Anforderungen kann die bereits erwähnte Authentifizierung innerhalb des Gerätes vorgesehen werden, etwa zwischen dem Linux-System und der safetykritischen Applikation auf einem Mikrocontroller. Dies sichert auch ein Update der Mikrocontroller-Firmware über das Linux-System ab. Außerdem sind eventuell genutzte mobile HMIs in das Sicherheitskonzept zu integrieren; insbesondere dann, wenn über diese nicht nur visualisiert, sondern auch gesteuert wird. Inwieweit BYOD-Ansätze bei hohen Security-Anforderungen sinnvoll und möglich sind, sollte sorgfältig geprüft werden.

Die Systemsoftware härten

Neben diesen Maßnahmen in Richtung sicherer Kommunikation gilt es, das Linux-System beziehungsweise die gesamte Systemsoftware aus sich heraus ‚sicherer‘ zu machen. Diese so genannte Härtung hat mehrere Aspekte: Zunächst sollte man beim Zusammenstellen von Kernel, Bibliotheken, Systemdiensten und auch Applikationen einen minimalistischen Ansatz wählen. Das heißt: Es werden konsequent nur diejenigen Software-Komponenten aus dokumentierten Quellen genutzt, die tatsächlich erforderlich sind. Das senkt nicht nur die Zahl möglicher Security-Schwachstellen, sondern auch den Wartungsaufwand.

Diese Anforderung ist in vielen Projekten ausschlaggebend dafür, dass nicht eine beliebige Linux-Distribution, das mitgelieferte oder das in Yocto verfügbare Linux-System des Herstellers verwendet, sondern in einem Bottom-up-Ansatz eine möglichst Mainline-nahe Linux-Plattform nachvollziehbar zusammen gestellt wird. Das kann initial Mehraufwand bedeuten, rechnet sich aber zuverlässig über den Lebenszyklus. Je Mainline-konformer das Linux-System ist, desto einfacher und schneller ist es später möglich, Security-Patches anzuwenden. Auch der Dokumentationsaufwand bei zertifizierungspflichtigen Systemen reduziert sich signifikant.

Ein weiterer Aspekt ist ein komponentenbasierter Ansatz, den Linux-Systeme jedoch per se mitbringen. Idealerweise sollte jede Einzelkomponente übersichtlich genug bleiben, um unter Security-Aspekten verständlich und wartbar zu sein. Schließlich sollte das ‚Least Privilege‘-Prinzip befolgt werden: Jede Komponente hat idealerweise nur Zugriff auf diejenigen Ressourcen, die sie tatsächlich benötigt. Damit geht auch die korrekte Konfiguration des Linux-Systems einher, die sich möglichst standardisiert testen lassen sollte.

Und nicht zuletzt erfordert ein sicheres System einen sicheren Entwicklungs- und Build-Prozess, um die Implementierung und Konfiguration der Sicherheitsmaßnahmen nachvollziehbar zu machen. Dies gilt später ebenso für jedes Release innerhalb des Lebenszyklus.

Hersteller und Inverkehr­bringer in der Pflicht

Die bisher genannten Punkte stehen beispielhaft für ein mögliches Sicherheitskonzept. Der Einsatz von Open-Source-Technologien ermöglicht es, die Security-Maßnahmen äußerst flexibel an die jeweiligen Anforderungen und die Prozesse in der Fertigung, bei der Installation, im Betrieb und bei der Wartung anzupassen. Konkretes Design und Umsetzung liegen jedoch letztlich in der Verantwortung der Hersteller und Inverkehrbringer. Diese sind bei einem Open-Source-System ebenso verantwortlich für die Lifecycle Maintenance. In relevanten Zertifizierungsanforderungen sowie in der einen oder anderen Lieferanten-Erklärung findet sich schon heute die Verpflichtung, nicht nur einen bestimmten Level an Sicherheit nachweisbar zu gewährleisten, sondern diesen auch über den Lebenszyklus aufrechtzuerhalten. Werden also Sicherheitslücken bekannt, muss reagiert und ein Patch, eine aktualisierte Paketversion oder ein neues Release ausgerollt werden.

Der entsprechende Prozess muss zuvor definiert sein. Wird ein Fehler bekannt, reagiert die ‚Linux-Community‘ in der Regel sehr schnell und stellt Patches oder Updates zur Verfügung. Allerdings gilt es sicherzustellen, dass man solche Meldungen und Neuigkeiten umgehend erfährt. Hierzu sind unterschiedliche Informationsquellen regelmäßig zu scannen. Das ‚Format‘, unter dem Sicherheitslücken gemeldet werden können und nachlesbar sind, sind so genannte CVEs (Common Vulnerabilities and Exposures).

Nicht alle aufgeführten Sicherheitslücken sind für das eigene System relevant. Daher muss eine entsprechende Bewertung erfolgen. Ist überhaupt die aktuell verwendete Paketversion betroffen? Hat es bei gegebenem Applikations-Kontext Relevanz? Wenn ja, wie kritisch ist die Sicherheitslücke und wie schnell muss sie geschlossen werden? Hier kann es durchaus sinnvoll sein, entsprechend aufgestellte Dienstleister mit Monitoring und Bewertung zu beauftragen. Gerade in der Automatisierungstechnik bedeutet ein Update nicht selten Produktionsausfälle, weil Anlagenteile heruntergefahren werden müssen. Wöchentliche, vorsorgliche ‚Zwangs-Updates‘ können hier nicht die Lösung sein.

Erfahrungsgemäß haben viele Updates und Patches durchaus Zeit bis zum nächsten, ohnehin geplanten Release. Sollte es sich aber um einen kritischen Fehler handeln, macht es sich bezahlt, den Release-Prozess bereits mit den potenziell betroffenen Kunden abgestimmt und zuverlässige Update-Mechanismen zur Verfügung zu haben.

Ein willkommenes Nebenprodukt des Security-Monitorings ist übrigens, dass dabei auch sonstige Updates und Patches ‚entdeckt‘ werden, die für andere Funktionalitäten des Linux-Systems relevant sind oder einen ‚hässlichen‘ Workaround obsolet werden lassen. Die Verantwortung für die Security-Lifecycle-Maintenance ermöglicht es darüber hinaus, all diese Prozesse optimal und gemäß den Kundenanforderungen zu steuern. Eine bewusste Update-Strategie sorgt ganz nebenbei für eine Kundenbindung, die mancher Wettbewerber (noch) nicht bieten kann

Autorin:
Heike Jordan ist Geschäftsführerin von Emlix.