In einer vernetzten und digitalisierten Fabrik spielt die Security eine immer wichtigere Rolle. Dabei geht es nicht nur darum, aus wirt­schaftlichen Gründen Angriffe auf Produktionsprozesse zu verhindern. Es gilt auch: Security schützt Safety und Safety schützt den Menschen. Hersteller von Automatisierungskomponenten müssen daher geeignete Maßnahmen ergreifen, um ihre Geräte auch „secure“ zu machen. Der Ansatz „Security By Design“ wird in der Norm IEC 62443-4-1 „Security for industrial automation and control systems – Part 4-1: Secure product development lifecycle requirements“ aufgegriffen.

Die Security von Produktionsanlagen (Industrial Security) wird häufig durch Security-Komponenten wie Firewalls und VPN-Gateways realisiert. Die zunehmende Vernetzung und die Anforderung, auch „remote“ auf Anlagen zugreifen zu können, führen zu einem steigenden Aufwand bei der Verwaltung externer Security-Lösungen.

Bei der Verwendung von Funktechnologien bieten Firewalls zudem nur einen bedingten Schutz, da ein Angriff direkt über die Funkschnittstelle und die niederen Protokollschichten erfolgen könnte. Also ist es erforderlich, Security-Maßnahmen direkt in den Systemen zu implementieren. Dabei muss der gesamte Lebenszyklus des Systems betrachtet werden. Security beginnt also in der Entwicklung.

Was bedeutet „Security By Design“?

Der Begriff „Security By Design” oder „Secure By Design“ beschreibt einen Entwicklungsansatz, bei dem bereits in der Entwurfsphase die Security-Eigenschaften eines Systems systematisch betrachtet werden. Es wird also nicht dem Zufall bzw. den Einschätzungen einzelner Entwickler überlassen, ob und in welchem Umfang Security-Funktionen in einem System implementiert werden. Stattdessen wird durch eine Modellierung der Bedrohungen („Threat Modelling“) ermittelt, welchen Bedrohungen ein System ausgesetzt ist. Daraus lassen sich gezielt Maßnahmen ableiten, um das Security-Risiko zu minimieren.

Weiter gefasst kann „Security By Design“ auch als Ansatz verstanden werden, bei dem die Security eines Produkts ganzheitlich über den kompletten Produktlebenszyklus betrachtet wird. Ein vielfach zitiertes und gut dokumentiertes Beispiel für diesen Ansatz ist der von Microsoft entwickelte „Security Development Lifecycle (SDL)“-Prozess. Zu Beginn der 2000er Jahre häuften sich die negativen Schlagzeilen bezüglich Security-Problemen in Produkten von Microsoft. Dies veranlasste das Unternehmen dazu, sich systematisch mit dem Thema Security zu beschäftigen, was zur Entwicklung des SDL führte. Mittlerweile verfolgen viele weitere Software- und Gerätehersteller einen vergleichbaren Ansatz.

Internationale Normenreihe: von der Risikoanalyse bis Best Practice

Security spielt in der klassischen IT also schon seit langem eine zentrale Rolle. Die Anforderungen lassen sich jedoch aufgrund der unterschiedlichen Prioritäten mit Blick auf Vertraulichkeit und Verfügbarkeit nicht ohne Weiteres auf die Automatisierung übertragen.

Mit der IEC 62443 „Industrielle Kommunikationsnetze – IT-Sicherheit für Netze und Systeme“ gibt es inzwischen eine internationale Normenreihe, die IT-Sicherheit in der Automatisierung umfassend behandelt. Das Themenspektrum reicht von der Risikoanalyse über Best Practices bis hin zur sicheren Entwicklung von Produkten („Security by Design“). Dadurch bietet die IEC 62443 eine Orientierungshilfe für Anlagenbetreiber und Gerätehersteller, um Security effektiv umzusetzen.

IEC 62443-4-1 Synergien nutzen & Prozess ­anpassen

Betrachtet man die IEC 62443-4-1 mit ihren 47 einzelnen Anforderungen, so erscheint die Umsetzung äußerst aufwendig. Dies ist vor allem der Fall, wenn die Produktentwicklung bislang nach dem Ansatz „vom Kopf in die Tastatur“, also nicht auf Basis entsprechender Prozesse, erfolgt ist. In diesem Fall gilt es zunächst die Anforderung SM-1: „Development process“ umzusetzen. Diese besagt, dass ein allgemeiner Lebenszyklus-Prozess dokumentiert sein und angewendet werden muss.

Zu klären ist: Ist ein solcher Prozess bereits vorhanden und berücksichtigt dieser womöglich die Anforderungen aus dem Bereich der funktionalen Sicherheit nach IEC 61508 oder einer der abgeleiteten branchenspezifischen Normen? Falls ja, so lassen sich Anforderungen identifizieren, die ähnlich oder gleich sind und somit bereits umgesetzt werden. Weiterhin definiert die Anforderung SM-5: „Process scoping“, dass der Prozess anhand einer Security-Analyse auf das jeweilige Entwicklungsprojekt anzupassen ist. Somit brauchen einzelne Anforderungen oder Teilanforderungen nicht berücksichtigt werden, wenn ein System beispielsweise über keine externen Schnittstellen verfügt oder wenn im Rahmen eines Änderungsprojektes nur Sprachkataloge aktualisiert oder gar abgekündigte Bauelemente ersetzt werden.

Security ist Aufgabe im gesamten Produktlebenszyklus

Eine weitere Herausforderung ist, dass es sich bei Security um ein „bewegliches Ziel“ handelt: Eine Automatisierungskomponente wie etwa eine Steuerung kann zwar zum jetzigen Zeitpunkt als „secure“ eingestuft werden, doch morgen kann sich die Bedrohungslage ändern und damit auch die Angriffssicherheit des Geräts. Das bedeutet, dass die Maßnahmen gegen Cyberbedrohungen ständig aktualisiert werden müssen. Die Verantwortung dafür liegt in erster Linie bei den Anlagenbetreibern, für die Datensicherheit zugleich Investitionsschutz bedeutet. Umgekehrt sind Maschinenbauer und auch Komponentenhersteller in der Pflicht, die Betreiber sofort über neue Sicherheitsprobleme zu informieren und Updates für die Software ihrer Geräte bereitzustellen, mit denen Schwachstellen behoben werden können. Das erfordert jedoch, dass beide Seiten über den gesamten Lebenszyklus der Produkte hinweg eng zusammenarbeiten.

Pilz auf der SPS Smart Production Solutions 2022 (Halle 9, Stand 370): Unter dem Messemotto „Be safe and secure“ stellt Pilz auf der internationalen Fachmesse SPS Smart Production Solutions (Nürnberg, 08. – 10.11.2022) Automatisierungslösungen in den Fokus, die sowohl Safety als auch Industrial Security an Maschinen und Anlagen abdecken.

Pilz entwickelt safe und secure

Hersteller sollten sich mit dem Thema Security beschäftigen, wenn die eigenen Produkte Teil einer digitalisierten Welt sein sollen. Dies gilt speziell dann, wenn diese Produkte auch die Sicherheit im Sinne von Safety schützen müssen. Seit rund 20 Jahren lässt das Automatisierungsunternehmen Pilz sein Management für Funktionale Sicherheit (FSM), also die „Safety“, von TÜV Süd prüfen und zertifizieren. Und seit einigen Jahren richtet Pilz seine Entwicklungsprozesse auch an der IEC 62443-4-1 aus und entwickelt nachweislich „secure“. Auch das hat TÜV Süd in einem Audit jetzt zertifiziert. Eine Erkenntnis: Wer sich schon mit Safety auskennt, wird sich bei Security leichter tun, weil sich die Vorgehensweisen ähneln. Zudem ist der Entwicklungsprozess von Pilz durch die Anforderungen an die Safety bereits gut gestaltet und dokumentiert. Dann ist die Erweiterung um die Security-Anforderungen einfacher.