Um dem wachsenden Druck durch Malware und Hacker entgegenzuwirken, müssen bereits bei der Entwicklung von Automatisierungslösungen und programmierbaren elektronischen Geräten Angriffs-Szenarien, welche die Informations- und Datensicherheit eines Fertigungsunternehmens gefährden könnten, mit einfließen: Hierbei handelt es sich um proaktive, das heißt, vorausschauende Maßnahmen.

Netzwerke im industriellen Umfeld lassen sich durch Firewalls schützen, die in Switches integriert sind.

© Siemens

Normen für Security

Die Philosophie der proaktiven Instandhaltung von Maschinen und Anlagen kennt heutzutage fast jeder Anlagenbauer. Was bei der Hardware seit langem Bestätigung findet, hält nun Einzug in die Soft- und Firmware industrieller Automatisierungsprodukte. Auch hierbei geht es darum, Maschinen und Anlagen zu schützen – allerdings nicht vor Verschleiß, sondern vor Manipulation über Datennetzwerke. Dieser Schutz von Automatisierungslösungen – kurz Industrial Security – muss durch entsprechende Vorkehrungen, Tools und Programme erreicht werden. Hierzu sind neue Wege erforderlich.

Während die Personen- und Maschinensicherheit (Safety) seit langem über entsprechende Normen wie IEC 61508 beziehungsweise IEC 62061 oder DIN EN ISO 13849 geregelt sind, arbeiten Experten weltweit noch daran, die daten- und kommunikationstechnische Sicherheit (Security) weiter zu optimieren und auch zu normieren. Beispielsweise nimmt derzeit die Norm IEC 62443 Teil 4-1 Gestalt an, die eine wichtige Grundlage für den notwendigen Manipulationsschutz bei der Entwicklung elektronischer Steuerungen und dem Aufbau von industriell genutzten Datennetzwerken darstellt. Teil 4-1 spezifiziert die Anforderungen an den Entwicklungsprozess von Geräten und Systemen. Das Dokument lehnt sich stark an die DIN EN 61508-3 und an die Spezifikation „Software Development Assessment Specification“, des ISA Security Compliance Institute, an. Auch hier ist wegen der umfangreichen Vorarbeiten zu erwarten, dass der Inhalt sich nicht wesentlich ändern wird, so dass Hersteller ihren Entwicklungsprozess auf Basis dieses Dokuments durchaus schon frühzeitig gestalten können.

Maßnahmen im Entwicklungsprozess

Industrial Security Process Impro­ve­ment: Siemens geht aktiv die Verbesserung seiner Produkte bezüglich Industrial Security an und hat nach der Evaluierung die entsprechenden Maßnahmen erfolgreich eingeführt.

© Siemens

Die Division Industry Automation von Siemens versucht, mit proaktiven Maßnahmen im Entwicklungsprozess Hacking-Angriffe zu erschweren. Ein Beispiel hierfür ist das „Industrial Security Process Improvement“ (ISPI), ein Projekt, das der Elektrokonzern Ende 2011 lancierte, um die Sicherheit von Automatisierungsprodukten und deren Software zu verbessern. Auslöser dieses Vorhabens waren mehrere Schwachstellen bei den Steuerungen und der Software, die es bereits im Entwicklungsstatus zu verhindern gilt. Ein wesentlicher Teil der Aktivitäten betrifft nicht nur die Entwicklungsbereiche im eigenen Haus, sondern ebenso die der Zulieferer. Hier geht es darum, das Verständnis zu schärfen, dass Sicherheitsmaßnahmen systematisch, durchgängig und nachhaltig vorhanden sein und stetig überprüft werden müssen. Wer diesen Prozess aktiv mitgestaltet – also Zulieferer und die eigenen Entwicklungsabteilungen – schafft unter anderem die Grundlage für eine Zertifizierung nach ISA-Secure (International Society of Automation). Die von Siemens definierten Prozesse zur Erhöhung der Daten- beziehungsweise Kommunikationssicherheit sind nach eigener Darstellung, je nach Gewichtung, dafür geeignet, die ISA-Zertifizierung in einem entsprechenden Level zu erreichen.

Die Evaluierungsphase für das ISPI-Projekt startete bereits 2011. Dieses wurde basierend auf dem +Secure Improvement Catalyst, dem ISA-SDSA(Software Development Security Assessment)-Secure-Fragebogen Level 1 und dem WIB-Fragebogen der International Instrument Users Association für Industrial Security erstellt. Dabei untersuchten die Experten in der Eva­luierungsphase die Prozesse des Produkt-Lebenszyklus-Managements (PLM), des Supply-Change-Managements (SCM) und des Customer-Relationship-Managements (CRM) sowie die Siemens-interne Organisation. In der Folge wurden diese Prozesse nach Security-Gesichtspunkten bewertet.

Die Ergebnisse: Verbesserungsmaßnahmen in den relevanten Prozessen wurden ausfindig gemacht und durchgeführt sowie neue Rollen innerhalb der Organisation eingeführt.

Schutzmechanismen in der Software

Im gesamten Prozess, beginnend bei der Entwicklung von Geräten, müssen Schutzmaßnahmen getroffen werden, um später im industriellen Betrieb kein Angriffsziel von Hackern zu werden.

© Siemens

Um Schwachstellen grundsätzlich zu vermeiden, legen „Coding Guidelines & Tools“ Regeln fest. Diese Regeln betreffen den Quellcode von Programmen, aber auch typische Schwachstellen wie Standard-Passwörter von Geräten, SQL-Injections oder Cross-site-scriptings. Die Coding Guidelines und die statische Code-Analyse wird den Entwicklern zur Verfügung gestellt, um einen Sourcecode auch unter den Aspekten der Datensicherheit zu optimieren. So stellen beispielsweise nicht deklarierte Variablen im Quellcode ein potenzielles Risiko dar. Um das Einhalten der Coding Guidelines zu überprüfen, werden Tools zur statischen Code-Analyse eingesetzt. Diese Tools unterziehen den Quellcode einer Reihe formaler Prüfungen während der Compiler-Laufzeit. Noch vor dem Ausführen des eigentlichen Programms wird dadurch nach Fehlern gesucht. Die Tools suchen dabei nach möglichen Angriffsstellen wie etwa Speicherlecks, Puffer­überläufen oder Formatstring-Angriffen.

Neben der Sicherheit steht hier die Nachhaltigkeit im Mittelpunkt. Denn alles, was nicht bekannt ist, ist poten­ziell risikobehaftet. Verboten sind etwa sogenannte Easter-eggs (Ostereier), also vermeintlich lustige Überraschungen, die Entwickler in der Vergangenheit im Programmcode versteckt hatten. Funktionen, die zur Belustigung führen sollen, haben jedoch in Automatisierungslösungen nichts zu suchen. Nachdem die Sicherheitsexperten publik gewordene Funktionen entfernt hatten, wurde während der Übergangsphase von der Projekt-Evaluierung zum Roll-out für Entwickler eine Karenzzeit geschaffen, in der solche versteckten Programme gemeldet werden konnten. Durch entsprechende Entwicklungsrichtlinien kann sichergestellt werden, dass bereits enthaltene Easter Eggs entfernt werden und per Prozess keine neuen unentdeckten Funktionen im Programmcode versteckt werden können.

Im Zuge des ISPI-Projekts wurden noch viele weitere Punkte definiert, die Entwicklern dabei helfen, Industrial Security von Anfang an im Auge zu behalten und dadurch sichere System­lösungen zu schaffen. Produkt-Sich­erheits-Risiko-Management (Product Security Risk Management) ist ein solcher Punkt, der das zentrale Instrument für ein Tailoring bildet – also das Anpassen eines Prozesses an die Sicherheitsanforderungen. Ein weiterer Aspekt der Risikobewertung ist, dass kritische Dinge nicht über Outsourcing erledigt werden sollten. Wichtig ist in diesem Zusammenhang auch, zu definieren, was geschützt werden muss, wie die interne Architektur aufgebaut ist und welchen Weg bestimmte Datenflüsse nehmen müssen.

Beschaffungswege genau beobachten

Bei den Beschaffungsprozessen sollten Sicherheitsexperten zusammen mit dem zentralen Einkauf einen prüfenden Blick auf Zulieferer werfen. Und zwar dahingehend, ob diese ihre Sicherheitsprozesse bereits stringent verfolgen. Neue Zulieferer sollten demnach gleich mit den eigenen Leitlinien rund um Indus­trial Security vertraut gemacht werden. Dabei muss sichergestellt sein, dass die Zulieferer in den Prozess miteinbezogen werden. Wichtig für einen bewussten Umgang mit Industrial Security ist auch ein Awareness Program (Bewusstseinsprogramm). Denn während im Bürobereich die Risiken und Auswirkungen von Schadprogrammen und gezielten IT-Angriffen von Hackern längst einen hohen Aufmerksamkeitsgrad besitzen, stecken diese Themen im industriellen Automatisierungsumfeld noch in den Kinderschuhen. Erst seit der breiten Berichterstattung über Stuxnet wird Industrial Security als eigenständiges Thema in voller Breite bearbeitet und nicht nur durch die Sicherheitsexperten. Ein verstärktes Bewusstsein gilt beispielsweise auch dem Hardening oder Härten von elektronischen Produkten und Lösungen.

Ein Beispiel für ein solches Hardening ist die gezielte Deaktivierung von Schnittstellen, die in einer Automatisierungslösung nicht gebraucht werden. Damit stehen potenzielle Zugänge für Angriffe von außen oder innen gar nicht erst zur Verfügung. Auch hierzu liefert Siemens Unterstützung und gibt Anwendern beim Einsatz von Produkten und Lösungen entsprechende Dokumentationen an die Hand. Denn für eine durchgängige Systemsicherheit gilt es einiges zu beachten, weshalb die Benutzerdokumentation ebenfalls ein zentraler Aspekt der Industrial Security ist.

Einen weiteren wichtigen Baustein stellt die Sicherheitsbeurteilung (Security Verification & Security Validation) dar. Das bedeutet, dass fertige Komponenten nach definierten Vorgaben geprüft werden. Bei Siemens erfolgen die Tests entweder im zentralen Security Lab in Karlsruhe oder beim Cyber Emergency Readiness Team (CERT) in München. Regelmäßige Statusberichte sollen manifestieren, dass sämtliche Punkte einer nachhaltigen Sicherheitsstrategie präzise und detailliert umgesetzt werden.

Da auch Standard-Betriebssysteme eine zentrale Bedeutung für Security in industriellen Systemen haben, ist es unbedingt erforderlich, verfügbare Sicherheits-Updates und -patches der Betriebssystemhersteller für den Einsatz in industriellen Systemen zu qualifizieren.

Schließlich geht es darum, effizient und dauerhaft die Industrial Security von Automatisierungskomponenten zu verbessern. Mit proaktiven Maßnahmen lässt sich die Sicherheit einer immer enger vernetzten Automatisierungslandschaft effizienter umsetzen, als über reaktive Trouble-Shooting-Szenarien.

Autor: David Heinze ist Marketing Manager Industrial Security bei Siemens, Industrial Sector, in Nürnberg.