Wie aus SPSen Bodyguards werden

Top 20 Secure PLC Coding Practices sind nun veröffentlicht

An diese Schönheit können Sie sich schon einmal gewöhnen: Das Logo des PLC Security-Projekts

Wir versuchten, SPSen, die oft als Achillesferse automatisierter Anlagen angesehen werden, zu den überall präsenten und unerbittlichen Bodyguards der Anlagen zu machen — einen vor jeder (Hinter-)Tür.

Warum brauchen wir diese Liste?

Security-Experten —Sie wissen, dass SPSen oft von Haus aus unsicher sind. Man hat von mindestens einer Million SPS-Schwachstellen gelesen und gehört. Vielleicht haben Sie sich damit abgefunden, dass SPSen eben genau das sind: unsicher? ‘
Wie oft haben Sie schweren Herzens SPSen aus dem Geltungsbereich von Sicherheitsprogrammen herausgenommen mit der Bemerkung “die Umsetzung der Seucurity Requirements ist hier technisch nicht machbar”? Wie oft haben Sie abenteuerlichen Argumentationslinien zugestimmt (“SPS-Programmieren ist ja nicht wirklich Programmieren”), weil Sie letztlich wussten, dass Sie in Bezug auf Security für SPS-Programme auch nicht viel bieten könnten, so gern Sie auch würden?

Die Top 20 Secure PLC Coding Practices sollen ein gemeinsames Verständnis dafür schaffen, was SPS-Security überhaupt bedeutet; was wir von einer “sicher programmierten” SPS erwarten dürfen.

Was steht im Top 20-Dokument?

Die Top 20 Secure PLC Secure Coding Practices können auf zwei Arten gelesen werden: Die Kurzversion passt auf zwei Seiten und gibt einen Überblick über die 20 Prinzipien. Die ausführliche Version führt auf einer oder mehreren Seiten zusätzliche Informationen aus:

  • Examples: Implementierungsbeispiele (oder Beispiele dafür, was passieren kann, wenn man eine Practice nicht umsetzt)
  • “Why”: Das “Warum” zur Practice, d.h. eine Liste von Vorteilen, die die Implementierung mit sich bringt. Das sind natürlich immer Security-Vorteile, aber oft auch solche für Wartbarkeit und Zuverlässigkeit.
  • References: Verweise auf Standards und Frameworks wie MITRE ATT&CK for ICS, CWE, oder verschiedene Teile der ISA-62443-Reihe.

Inwiefern verbessert diese Liste denn die Security?

Die einzelnen Practices sind nach ihren Security-Zielen gruppiert. Wir haben diese Security-Ziel-Label erst sehr spät im Entstehungsprozess des Dokuments vergeben — nachdem einigen Stunden Diskussionen über die genauen Security-Vorteile bei der Implementierung der einzelnen Listeneinträge.

  • Härtung (hardening): Dazu gehört alles, was die Komplexität und damit die Angriffsfläche reduziert. Zwei Praktiken fallen in diese Kategorie.
  • Zuverlässigkeit (resilience): Das sind Praktiken, die sicherstellen, dass eine SPS im Falle von Fehlern robust läuft. Da wir bei Praktiken, die “nur” zu dieser Kategorie gehören, recht genau hingeschaut haben (s.o.), gibt es nur eine einzige mit dem primären Security-Ziel “resilience”.
  • Überwachung (monitoring): Dieses Label kennzeichnet alle Praktiken, die die Überwachung bestimmter Werte in der SPS empfehlen, die auf Security-Probleme hinweisen könnten.
    Das Interessante daran ist, dass die so gelabelten Practices kein klassisches Security-Monitoring mit einer zusätzlichen Software bedeuten. Alle können direkt in SPS und HMI umgesetzt werden. Mit fünf Praktiken ist dies die zweithäufigste Kategorie.

Wie wurden die Top 20 ausgewählt?

Das führt uns zu einem weiteren Aspekt dessen, was Sie nicht auf der Liste finden werden.
Nachdem wir Dutzende von guten Vorschlägen für Secure PLC Coding Practices erhalten hatten, war klar, dass es bei vielen von ihnen nicht mehr wirklich um das Programmieren ging, sondern um Architektur, Vernetzung, Best Practices für andere Geräte wie HMIs, oder Dokumentation.
All diese Punkte verbessern zweifelsohne die SPS-Sicherheit, aber sie sind eben nicht coding.
Dasher ist das hier die Definition, auf deren Basis wir entschieden haben, ob ein Vorschlag in den Geltungsbereich unserer Secure PLC Coding Practices fällt: “alles, was Änderungen an der SPS selbst erfordert”.

Manche der Practices sind so selbstverständlich…warum stehen sie auf der Liste?

Vorweg: Es gibt zwei Perspektiven, aus denen man die Secure PLC Coding Practices betrachten kann, und aus jeder dieser Perspektiven sieht ein anderer Teil “selbstverständlich” aus.

Fall 1: Zu selbstverständlich für Security-Experten

Aus der Security-Perspektive mögen Praktiken wie “unbenutzte Ports deaktivieren” einfach erscheinen. Wir haben sie dennoch aufgenommen, und zwar aus drei Gründen:

  • Zweitens: Nur weil die Anforderung einfach erscheint, ist ihre Umsetzung nicht immer so einfach. Ein großer Teil der Practices sind die Umsetzungshilfen (“Guidance”) und die Beispiele (“Examples”).
  • Drittens: Wir klarstellen, welche “selbstverständlichen” Security-Anforderungen SPS-Programme und SPS-Konfigurationen tatsächlich erfüllen können und vor allem (siehe zweitens): wie.
    Es gibt viele Mythen darüber, dass Security-Anforderungen im Allgemeinen für SPSen technisch nicht umsetzbar sind — und das trifft manchmal durchaus zu. Umso wichtiger ist es, deutlich zu machen, für welche es nicht zutrifft.

Fall 2: Zu selbstverständlich für SPS-Programmierer

Aus Sicht eines SPS-Programmierers mögen Praktiken wie “SPS-Zykluszeiten überwachen” selbstverständlich erscheinen.

Fall 2: Das setzt doch sowieso schon jeder um

Und selbst wenn die Gefahr besteht, dass einige Praktiken wirklich für jedermann in der Branche selbstverständlich sind, gibt es zwei weitere Gründe, warum wir sie aufgenommen haben:

  • Das Dokument ist auch als Leitfaden für Programmierer gedacht, die gerade mit der SPS-Programmierung oder der Security oder beidem beginnen. Wenn es bewährte Secure PLC Coding Practices gibt, an die sich in der Praxis jeder hält, sollten auch neue Programmiererinnen Zugang zu dieser Weisheit haben.

Wer sollte das Dokument lesen?

Während wir das Dokument geschrieben haben, hatten wir vor unserem inneren Auge stets Ingenieure, genauer gesagt Ingenieure, die SPSen programmieren.
Das bedeutet auch, dass wir das Dokument nicht explizit für eine Reihe anderer Personengruppen geschrieben haben: Security-Fachleute oder das Management etwa. Das heißt nicht, dass diese Gruppen die Top 20 Secure PLC Coding Practices nicht lesen sollten (im Gegenteil!), aber die Texte wurden mit dem Ziel geschrieben, dass vor allem SPS-Programmierer sie in ihrer täglichen Arbeit gebrauchen können.

Ich möchte etwas beitragen / ich habe einen Fehler gefunden!

Das Kommentieren des Top-20-Dokuments ist nicht nur ausdrücklich erwünscht, sondern auch ganz einfach: Laden Sie unser Kommentarformular von herunter, füllen Sie es aus, so weit Sie können, und senden es an die im Formular angegebene E-Mail-Adresse zurück. Sie können entweder den bestehenden Text kommentieren oder eine komplett neue Secure PLC Coding Practice vorschlagen, die Ihrer Meinung nach noch fehlt.

Wer ist eigentlich “wir”?

Ja, ich schreibe hier absätzelang von “wir” — und das aus gutem Grund: Alle Personen, die zum Projekt beigetragen haben, in jedem Satz zu nennen, hätte diesen Text ziemlich länglich gemacht.
Das Secure PLC Coding Practices Project ist ein Community-Projekt. Wir können mit Stolz sagen, dass wir mehr als 900 registrierte Benutzer auf der Plattform haben, die wir zur Strukturierung unserer Diskussionen während des Projekts verwendet haben (top20.isa.org ; wird bald abgeschaltet).
Das Kernteam, das sich jede zweite Woche getroffen hat, um jedes einzelne Wort in jeder einzelnen Practice auseinanderzunehmen, wird am Ende des Dokuments genannt, und es gibt eine vollständige Liste der Unterstützern von der Plattform, die zugestimmt haben, auf der letzten Seite genannt zu werden.
Niemand im Projekt wurde für die Arbeit an den Top 20 bezahlt, und da wir rund um den Globus verteilt sind, beinhaltete die Arbeit für viele Treffen zu unorthodoxen Zeiten.

Und nun?

Unser wichtigstes Ziel ist es, die Top 20 Secure PLC Coding Practices fest in das Grundwissen eines jeden SPS-Programmierers und einer jeden Automatisierungsingenieurin einzubetonieren. Wir werden über unsere Liste sprechen, sie teilen, diskutieren, erklären und verbessern.
Es gibt bereits einen großen Pool an Ideen für Verbesserungen, Erweiterungen und Kollaborationen: Code-Beispiele hinzufügen, mehr Beispiele für verschiedene SPS-Marken hinzufügen, die zusätzliche Liste Top 20 Secure PLC Environment Practices fertigstellen — um nur einige zu nennen.

Laden Sie die aktuelle Version der Top 20 Secure PLC coding practices herunter: plc-security.com

Folgen Sie unserem Projekt auf Twitter: @secureplc.

Friction generates heat — true for writing and engineering. Fluchsfriction generates writings on security engineering. Heated debates welcome! CTO@admeritia

Friction generates heat — true for writing and engineering. Fluchsfriction generates writings on security engineering. Heated debates welcome! CTO@admeritia