Die Anforderungen, die an ‚Security‘ – also das Sicherstellen der Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit – seitens der IT- und der Automatisierungs-Welt gestellt werden, unterscheiden sich deutlich: Während im Büroumfeld die Vertraulichkeit der Informationen höchste Priorität hat, steht im Produktionsbereich Verfügbarkeit und Integrität der Daten an oberster Stelle. Zum einen ist dies eine wesentliche Voraussetzung für reibungslose Fertigungsprozesse, zum anderen kann ein Angriff auf die Integrität eines Safety-Systems schwere Unfälle zur Folge haben. Daher wurde in der Edition 2.0 der Norm IEC 61508-1 im Kapitel 7.4 ‚Hazard and risk analysis‘ ein Zusatz aufgenommen. Dieser besagt, dass eine Bedrohungsanalyse durchgeführt werden soll, falls eine Security-Bedrohung in ‚angemessener Weise‘ als wahrscheinlich anzusehen ist. Somit müssen sich insbesondere Hersteller von Safety-Systemen dem Thema Security widmen. Doch auch Hersteller von Systemen, die keine sicherheitsbezogenen Funktionen implementieren, sollten sich mit Security beschäftigen, um Angriffe auf Produktionsprozesse zu verhindern. 

Schlanke Security gefragt

Aktuell wird die Security von Produktionsanlagen häufig durch Security-Komponenten wie Firewalls und VPN-Gateways realisiert. Durch Industrie 4.0 und IoT werden die Kommunikationsbeziehungen zwischen den Automatisierungskomponenten untereinander und mit externen Systemen zunehmen. Dies führt zu einem steigenden Aufwand bei der Verwaltung externer Security-Lösungen. Werden Funktechnologien verwendet, bieten Firewalls zudem nur bedingt Schutz, da ein Angriff direkt über die Funkschnittstelle und die niederen Protokollschichten erfolgen könnte. Um diesen Problemen entgegenzuwirken, müssen Security-Maßnahmen direkt in den Systemen umgesetzt werden.

Safety und Security besitzen deutliche Parallelen in der Standardisierung und der Vorgehensweise im Engineering-Prozess. Für die Umsetzung lassen sich viele Abläufe und Erfahrungen aus der Safety-Welt direkt auf die Security-Welt übertragen.

© Pilz

Hier kommt der Begriff ‚Security By Design‘ oder ‚Secure By Design‘ ins Spiel: Er beschreibt einen Ent­wicklungsansatz, bei dem bereits in der Entwurfsphase die Security-Eigenschaften eines Systems systematisch betrachtet werden. Es wird also nicht dem Zufall beziehungsweise 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 lässt sich ‚Security By Design‘ auch als Ansatz verstehen, 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‘-Prozess (SDL): Zu Beginn der 2000er-Jahre häuften sich die negativen Schlagzeilen bezüglich Security-Problemen in Produkten von Microsoft. Dies veranlasste das Unternehmen, sich systematisch mit dem Thema Security zu beschäftigen, was zur Entwicklung des SDL führte. Mittlerweile verfolgen viele weitere Software- und Geräte-Hersteller einen vergleichbaren Ansatz.

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

Ausgangspunkt Normen

Mit der IEC 62443 ‚Industrielle Kommunikationsnetze – IT-Sicherheit für Netze und Systeme‘ gibt es dagegen eine internationale Normenreihe, die in Teilen schon verabschiedet wurde und die IT-Sicherheit in der Automatisierung umfassend behandelt. Das Themenspektrum reicht von der Risikoanalyse über Best Practices bis zur sicheren Entwicklung von Produkten. Dadurch bietet die IEC 62443 die derzeit beste Orientierungshilfe für Anlagenbetreiber und Gerätehersteller, um Security effektiv umzusetzen. Die Norm wurde ursprünglich vom ISA99 Komitee ‚Industrial Automation and Control Systems Security‘ definiert und vom Normengremium IEC übernommen. Die einzelnen Normenteile gliedern sich in die vier Bereiche General, Policies & Procedures, System und Component/Product, wobei die konkreten Anforderungen in Gruppen – sogenannte ‚Practices‘ – unterteilt sind (Bild links oben).

Practice 1

Security management – stellt unterschiedliche Anforderungen an das Management des Entwicklungsprozesses. Hierzu gehört unter anderem, dass ein allgemeiner Produktlebenszyklus-Prozess vorhanden sein muss, dass Verantwortliche zu benennen sind und Mitarbeiter bezüglich ihrer Rolle im Prozess und ihres Security-Wissens trainiert werden müssen. Weitere Anforderungen gelten der Security der Entwicklungsumgebung und dem Umgang mit Teilkomponenten von Drittherstellern. 

Practice 2

Specification of security requirements – beschreibt Anforderungen an die Spezi­fikation von Security-Anforderungen. Beispielsweise legt ‚Product security context‘ fest, dass der Systemkontext aus Security-Sicht für das zu entwickelnde System definiert werden muss. Der Kontext beschreibt beispielsweise die physischen Security-Eigenschaften der Umgebung (zum Beispiel: Das System muss in einem abgeschlossenen Schaltschrank betrieben werden) und die Eigenschaften der Netzwerk-Umgebung (zum Beispiel: Das System muss durch eine Firewall gesichert werden). Der Security-Kontext ist eine wichtige Eingangsgröße für die Bedrohungsmodellierung, die ebenfalls durch eine Anforderung verlangt wird.

Practice 3

Secure by design – definiert Anforderungen an das Design des Systems. So sollen zum Beispiel anerkannte Security-Techniken und Entwurfsmuster wie ‚Security By Design‘ verwendet werden. Somit wird durch diese Anforderungen die erste Interpretation des Begriffs ‚Security By Design‘ umgesetzt.

Practice 4

Secure implementation – die Anforderungen hier sollen sicherstellen, dass keine Security-Schwachstellen durch Fehler in der Implementierung entstehen. Hierzu gehören das Einhalten anerkannter Codierungsrichtlinien, die Durchführung einer statischen Code-Analyse sowie das Durchführen eines Code-Reviews.

Practice 5

Security verification and validation testing – legt die Art der durchzuführenden Security-Tests fest. Zudem werden Anforderungen an die Unabhängigkeit der Tester gestellt.

Practice 6

Management of security-related issues – definiert Anforderungen an den Umgang mit Security-Problemen im Produkt. Dies umfasst neben der Analyse von Problemen auch das Empfangen von Meldungen (zum Beispiel von Kunden oder Security-Forschern) und die Benachrichtigung der Anwender über gefundene Security-Probleme.

Practice 7

Security update management – darin werden Anforderungen an das Management von Security-Updates gestellt. Dies betrifft unter anderem das Sicherstellen, dass ein Update tatsächlich wie beabsichtigt eine Schwachstelle beheben wird und keine neuen Probleme verursacht. Weiterhin wird gefordert, dass der Hersteller die Anwender darüber informieren muss, ob Security-Updates von abhängigen Komponenten (zum Beispiel dem Betriebssystem, auf dem das Produkt eingesetzt wird) rückwirkungsfrei installiert werden können.

Practice 8

Security guidelines – definiert Anforderungen an den Inhalt der Benutzerdo­kumentation. Beispielsweise wird gefordert, dass Hinweise zu den erforderlichen Maßnahmen für die Härtung des Systems gegeben werden sowie dazu, was bei der Außerbetriebnahme des Geräts zu beachten ist.