Rüdiger Kügler, Security Expert, WIBU-SYSTEMS AG
Mit Industrie 4.0 bieten sich Produzenten und Konsumenten Möglichkeiten, Dinge zu realisieren, die bisher entweder zu teuer oder zu komplex waren. Doch die Vernetzung des IoT birgt Gefahren wie Datendiebstahl, Manipulation oder Sabotage. Daher steht am Anfang eines wirksamen Schutzkonzepts für die Produktion immer eine dedizierte Bedrohungsanalyse – die ständig an die aktuelle Gefahrenlage angepasst werden muss.
Ein Beispiel: Ich hätte gerne mein Lieblingsgetränk in einer Flasche mit meinem Gesicht – als 3D-Relief. Um eine solche Leistung kosteneffizient zu erbringen, muss der komplette Prozess automatisiert sein: von der Erfassung des 3D-Scans über die Übertragung der Daten an die Produktionsanlage, die Produktion der Flasche und das Abfüllen bis zur Auslieferung. Doch was bedeutet dies aus dem Blickwinkel der Sicherheit?
Bedrohung durch Malware
Eine der größten Bedrohungen stellt nicht-autorisierte Schad-Software dar: Viren, Malware oder Spyware. Damit können drei Angriffsziele realisiert werden:
- Ausspähen von Daten: Dieser Aspekt beschreibt den Schutz von Daten wie Betriebsgeheimnisse und geistiges Eigentum – für das Beispiel etwa um die Formel für die Mixtur des Getränks und die Funktionsweise des Gerätes. Aber auch personenbezogene Daten können bei der intelligenten Produktion eine Rolle spielen.
- Sabotage: Dieser Begriff umfasst die mutwillige Zerstörung von Dingen. Stuxnet ist ein Beispiel, welches vor wenigen Jahren in aller Munde war. Dieser Virus hat sich über die Laptops der Servicetechniker auf Atomanlagen im Iran übertragen und dort die Produktion verändert. Glücklicherweise wurde die Produktion nur reduziert. Die Folgen einer Änderung über die Belastungsgrenze hinaus wären verheerend gewesen.
- Manipulation: Hier geht es in der Regel um eine unerlaubte Veränderung mit dem Ziel, sich einen Vorteil zu verschaffen. Nehmen wir Energieerzeugungsanlagen als Beispiel. Diese sind für eine entsprechende maximale Drehzahl konzipiert. Ein Betrieb jenseits dieser Drehzahl erzeugt mehr Energie, führt aber auch zu höherem Verschleiß und einem höheren Ausfallrisiko. Eine entsprechende Manipulation durch den Betreiber bringt mehr Profit und führt zu höheren Kosten des Lieferanten für die Wartung.
Nur eingeschränkt wirksam – Blacklisting
„Ich habe einen Virenscanner, ich bin sicher“, so ein weitverbreiteter Irrglaube. Ein Virenscanner auf einem PC sucht permanent im Hintergrund nach Schad-Software und erkennt diese anhand ihres Verhaltens. Dabei geht man vom Blacklisting-Ansatz aus. Alles, was nicht verboten ist, ist erlaubt. Die Entscheidung, ob eine Software böse oder gut ist, wird dabei durch einen hoch komplexen Algorithmus getroffen. Anzahl und Namen der Sektionen einer Software, verschlüsselte Anteile, selbstmodifizierenden Code und eine Überprüfung des Herausgebers sind nur einige Beispiele der komplexen Formel.
Aber immer wieder kommt es zu Fehleinschätzungen: Dies sind auf der einen Seite False Positives – wenn der Virenscanner eine Software fälschlich als Virus identifiziert. Auf der anderen Seite werden getarnte Viren, die die Funktionsweise der Virenscanner kennen, oft nicht gefunden. Manchmal funktioniert die Tarnung nur für wenige Stunden, die aber schon ausreichen, um einen Virus zu verbreiten; manchmal vergehen mehrere Monate, was eines der Erfolgsrezepte des oben erwähnten Stuxnet-Virus war. Eine Quintessenz lässt sich daraus ziehen: Regelmäßige Aktualisierungen sind unerlässlich.
Übertragen auf die Produktion bedeutet dies, dass jedes Gerät automatisch im Hintergrund Updates des Virenscanners laden müsste – und im Falle von False Positives würde die Produktion stehen. Weit bedrohlichere Auswirkungen hätte es, falls es einem Angreifer gelingen sollte, die Aktualisierung des Virenscanners mit einem Virus zu versehen, um Schad-Software auf das Gerät zu bekommen. Unmöglich? Nein, denn ein ähnlicher Ansatz hat zu den Viren im iTunes Store geführt. Zwar laden Entwickler die Entwicklungssoftware direkt von Apple herunter. Da dies aber oft langsam und umständlich ist, gibt es – meist nicht autorisierte – Server, die dies lokal anbieten. Einer von diesen war infiziert und daher hat die Software, die eigentlich für Sicherheit sorgen sollte, den Virus ermöglicht.
Virenscanner: Nur erkannte Schadsoftware wird nicht ausgeführt
Ansatz für die Produktion: Whitelisting
In der Produktion kommen Whitelisting-Ansätze zum Tragen. Dabei wird explizit erlaubt, was auf dem Gerät laufen darf; alles andere ist verboten. Technisch möglich wird dieser Ansatz, da die Produktionsgeräte vom Hersteller als komplette Einheit erstellt und verkauft werden und der Anwender auf diesen nicht einfach weitere Büro-Software installieren kann.
Beim Whitelisting gibt es verschiedene Spielarten: Eine einfache Lösung ist das Einfrieren eines Systems auf einen bestimmten Stand. Bei einem Update der Software muss das System aufgetaut, aktualisiert und der neue Stand erneut eingefroren werden.
Whitelisting: Nur Anwendungen mit gültigem und bekannten Zertifikat werden ausgeführt
Ein mehr generischer Ansatz ist die Verwendung von Signaturen und Secure Boot. Dieser Ansatz ist zum Beispiel im Betriebssystem VxWorks enthalten. Für die Umsetzung werden ein oder mehrere Schlüsselpaare und entsprechende Zertifikate erzeugt. Dabei besteht ein Schlüsselpaar aus einem privaten Schlüssel und einem öffentlichen Schlüssel. Der private Schlüssel ist ein Geheimnis; der öffentliche Schlüssel hingegen kann beliebig weitergegeben werden. Mathematisch gilt dabei, dass ein Angreifer aus dem öffentlichen Schlüssel den privaten Schlüssel nicht zurückberechnen kann. Bezeichnet wird diese Art der Verschlüsselung als „Asymmetrische Kryptographie“.
Nachrichtenaustausch nur über Verschlüsselung & Zertifikate
Um Nachrichten nun verschlüsselt auszutauschen, gibt der Empfänger der Nachricht vor dem Versenden den öffentlichen Schlüssel an den Sender. Dieser verschlüsselt damit die Nachricht und der Empfänger kann diese mithilfe des privaten Schlüssels lesen. Dieses Vorgehen lässt sich bildlich wie ein Tresor mit einem Schnappverschluss darstellen. Der Tresor geht offen an den Sender, dieser legt die Nachricht hinein und nur der Empfänger kann ihn wieder öffnen.
Konkret bedeutet dies, dass es wichtig ist, den tatsächlichen Eigentümer eines öffentlichen Schlüssels zu verifizieren, bevor man damit Nachrichten verschickt. Dazu gibt es entsprechende Zertifizierungsstellen, bei denen sich Eigentümer eines öffentlichen Schlüssels registrieren lassen können; das Zertifikat wird dann zusammen mit dem öffentlichen Schlüssel verschickt.
Ein alternatives Vorgehen gibt es beim VxWorks-Betriebssystem. Dort ist der Hersteller des Gerätes in der Regel selbst die Zertifizierungsstelle: der öffentliche Schlüssel ist in das Betriebssystem eingebettet; mit dem privaten Schlüssel erstellt und unterschreibt der Hersteller die Zertifikate. Oft sind dies nur ein privater Schlüssel und ein Zertifikat, der Hersteller kann jedoch auch mehrere Schlüsselpaare erzeugen. Auf diese Weise kann er dem Anwender ein Schlüsselpaar und Zertifikat aushändigen und somit dessen eigene Aktualisierung des Gerätes oder zumindest von Teilen erlauben.
Technisch gesehen lässt er den Anwender das Schlüsselpaar erzeugen und unterschreibt nur dessen öffentlichen Schlüssel. Mit diesem privaten Schlüssel kann der Anwender seine eigene Anwendung unterschreiben. Diese Unterschrift erledigt ein Post-Build-Prozess mit dem Namen ExProtector von Wibu-Systems und ist in der Entwicklungsumgebung von VxWorks bereits integriert. Das Betriebssystem überprüft dann die Signatur und die Zertifikate, bevor die Anwendung des Anwenders geladen und ausgeführt wird. Dieser Mechanismus verhindert Schad-Software auf dem Gerät und lässt dennoch Aktualisierungen und eigene Anwendungen auf einfache Art und Weise zu.
Routinen für Datenimporte: kein Einfalltor
Ein Whitelist-Mechanismus verhindert die Ausführung von Schad-Software auf Geräten in der Produktion und ist einer der aktuell stärksten Schutzmechanismen. Doch ist dieser Schutz bei weitem nicht ausreichend. Selbst wenn keine fremde Anwendung mehr ausgeführt werden kann, gibt es dennoch mögliche Schwachstellen, um fremden Code auszuführen.
Eine davon sind Speicherüberläufe. Dies sind Fehler der Entwickler, welche drastische Folgen haben können. Ein gutes Beispiel dafür ist der BKA-Virus. Eigentlich darf eine Java Anwendung auf einer Webseite nur „ein paar bunte Bildchen malen“, hat aber keinen Vollzugriff auf den PC des Anwenders. Durch einen Fehler im Programmcode von Java haben Daten des Angreifers den Speicherbereich des ausführbaren Codes überschrieben. Das heißt an dieser Stelle: Im Speicher stand dann nicht mehr der originale Code von Java, sondern der in den Daten versteckte Virus. Im Beispiel der Energieerzeugungsanlagen bedeutet dies, dass der Entwickler die Eingabe der Betriebsparameter wie zum Beispiel maximale Drehzahl absichern muss. Diese Einstellungen dürfen nur durch autorisiertes Servicepersonal vorgenommen werden.
Ausspähen von Daten: ein Ding der Unmöglichkeit
Ein weiteres Bedrohungsszenario ist das Ausspähen von Daten über offene Ports und Dienste. Neben Speicherüberläufen werden Angriffsmethoden wie SQL-Injection eingesetzt. Auch hier sind vielschichtige Maßnahmen erforderlich. Neben einer Firewall sollte der Zugriff über Zertifikate abgesichert sein. Der Betreiber der Anlage unterschreibt in diesem Fall den öffentlichen Schlüssel, damit mit anderen Geräten kommuniziert werden kann. Nur ein autorisiertes Gerät oder ein autorisierter Mitarbeiter dürfen „mitspielen“.
Die genannten Zertifikate sind zum Beispiel eine Option bei OPC UA, einem Standardprotokoll für die Kommunikation zwischen Maschinen. Zu jedem Zertifikat gibt es einen (geheimen) privaten Schlüssel. Der private Schlüssel sollte dabei sicher gespeichert werden. Das heißt, er muss zwar verwendet werden können, aber er darf nicht ausgelesen oder kopiert werden. Ein Beispiel sind SmartCard-Chips. Der private Schlüssel wird im Chip gespeichert und es gibt eine Funktion (SmartCard-API), mit dem er für eine kryptographische Operation verwendet werden kann. Wenn man sich die Kosten für einen extra Chip sparen möchte, beziehungsweise muss, dann sollte der Schlüssel so verschlüsselt auf dem Gerät abgespeichert werden, dass er nicht auf ein anderes Gerät übertragen werden kann. Zum Beispiel, indem Eigenschaften des Gerätes wie eine Seriennummer in die Verschlüsselung eingehen. Im Beispiel CodeMeter stehen beide Optionen, sicherer SmartCard-Chip und gerätegebundene Verschlüsselung, zur Verfügung.
Ausschließlich verschlüsselte Speicherung wichtiger Daten
Auch die Software selber und die Rezepte (für das Beispiel etwa die Getränkeformel) sind ein schützenwertes Gut. Hier sollte ebenfalls Verschlüsselung zum Einsatz kommen. Ein exzellentes Beispiel ist hierfür wieder VxWorks. Der in der Entwicklungsumgebung integrierte ExProtector kann die Software nicht nur signieren, sondern wahlweise auch verschlüsseln. Auch hier kommen Dongles oder gerätespezifisch verschlüsselte Lizenzdateien in Betracht. Tools wie den ExProtector gibt es natürlich nicht nur für VxWorks, sondern für eine Vielzahl von Betriebssystemen und Laufzeitumgebungen: Linux, Android, Java, CODESYS und .NET sind dabei nur Beispiele.
Résumé
Sicherheit ist ein essentielles Thema in der Produktion. Sowohl die Sicherheit des Betreibers gegen einen unbefugten Dritten als auch die Sicherheit des Herstellers der Anlage gegen ein schwarzes Schaf unter den Betreibern. Um dies zu erreichen, sollte die Sicherheit bereits bei der Konzeption der Systeme berücksichtigt werden, unabhängig davon ob man als Hersteller die Sicherheit selber implementiert oder schlüsselfertige Systeme verwendet.
WIBU-SYSTEMS AG (WIBU), 1989 von Oliver Winzenried und Marcellus Buchheit gegründet und eigentümergeführt, ist Technologieführer im Bereich Schutz und Lizenzierung von Software und Dokumenten. Sie bietet Kopier- und Know-how-Schutz, Lizenzierung und Security, also Manipulationsschutz, anwendbar bei Embedded- und SPS-Systemen über PCs bis in die Cloud.
Beitragsbild: Datenschutz in der Industrie (©Müller Martini Marketing AG)
