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

Es begann mit einem Konferenzvortrag, Gesprächen bei Getränken nach dem Konferenzvortrag und langen Stunden am Telefon in einer Welt, die gerade zu verstehen begann, dass COVID-19 bedeutete: jetzt erst mal keine Konferenzen mehr. In dieser Hinsicht ist die Liste der Top 20 Secure PLC Coding Practices ein Beispiel dafür, wie eine Community, die sich nicht mehr in Präsenz treffen konnte, Wege gefunden hat, trotzdem an gemeinsamen Projekten zu arbeiten.

Aber dies ist nicht der Text, um zu erklären, warum und wie das Projekt begann — dazu gibt es bereits einen anderen.
Dies, meine Damen und Herren, ist der Text, der das erste greifbare, herunterladbare, kommentierbare Ergebnis unseres SPS-Security-Projekts zu präsentieren: die erste Liste von Secure Coding Practices für speicherprogrammierbare Steuerungen (SPS).

Während ich den Inhalt des Dokuments für sich selbst stehen lassen möchte, gibt es hier ein paar Erläuterungen zum Projekt, die über die Inhalte des Dokuments hinausgehen.

Das Dokument “Top 20 Secure PLC Coding Practices” steht auf unserer Projekt-Website plc-security.com zum Download bereit. Die neuesten Informationen gibt es auch auf unserem Twitter-Account @secureplc.

Die Top 20 Secure PLC Coding Practices sind, kurz gesagt, eine Liste von Programmierprinzipien für SPS-Programmierer, die zu besserer IT-Sicherheit von speicherprogrammierbaren Steuerungen (SPS) führen — und damit natürlich auch zu besserer IT-Sicherheit der Anlagen, die von diesen SPS gesteuert werden.

Während die Liste durchaus von ähnlichen Listen für “normale” IT-Software inspiriert ist, die z. B. von OWASP, der Carnegie Mellon University, CWE oder Microsoft veröffentlicht wurden, sind die Secure PLC Coding Practices kein Versuch, die bekannten Practices nun einfach auf eine andere Art von Geräten (SPSen) anzuwenden.
Anstatt die bestehenden Prinzipien so lange zu verbiegen, bis sie auf eine SPS passen (und dann möglicherweise nicht mehr viel Sinn ergeben), haben wir versucht, bei einem leeren Blatt anzufangen und die Eigenschaften und Features zu nutzen, die SPSen zu SPSen macht.

Wir haben also versucht, die Charakteristika von SPSen — Echtzeitfähigkeit, begrenzte Rechenleistung, eingeschränkte Flexibilität, die Tatsache, dass sie physikalische Prozesse steuern — als Security-Features zu nutzen, stat als Bugs, die der Security im Wege stehen.

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?

Automatisierungsingenieure —Sie haben sicher schon gehört, dass SPSen und Security nicht besonders gut zueinander passen. Zunehmend gehen Ihnen Leute auf die Nerven, die fragen: “Haben Sie schon an die Security gedacht”? Sie würden ja wirklich gerne an die Security denken, am liebsten sogar an die SPS-Security, wenn Ihnen nur jemand sagte, wie genau?

Also: Wenn wir nichts anderes mit den Top 20 Secure PLC Coding Practices erreichen, dann immerhin, dass wir nach langen Jahren des Jammerns über unsichere SPSen den konstruktiven Teil des Gesprächs beginnen, das wir Ausreden verumöglichen, in denen Menschen ja wirklich gern Security auch für SPSen umsetzen würden, aber es ist halt technisch einfach nicht machbar, “sehen Sie, es gibt nirgendwo in der ganzen Branche Informationen über Security für die SPS-Programmierung!”.
(Sollten Sie sich jetzt angegriffen fühlen: keine Sorge, Sie sind nicht allein. Ich habe diese Worte auch schon gesagt.)

Nun, die Zeiten der Ausreden liegen hinter uns. Wenn Sie das nächste Mal eine Ausrede hören, schicken Sie ihrem Urheber den Link zu den Top 20.

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:

• Guidance: Anleitungen, Theorie, Hintergrundinformationen und Erkärungen,
• 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.

Außerdem haben die Prinzipien Labels, die eine kurze Zusammenfassung ihrer Security-Ziele und ihrer Zielgruppe darstellen.

Sie können das Dokument übrigens völlig frei teilen und weiterverwenden, da wir eine der freigiebigsten Lizenzen gewählt haben, die wir finden konnten (siehe Lizenzerklärung).

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.

Klar, all die Vorteile in Bezug auf Zuverlässigkeit und Wartbarkeit sind sehr geschätzt, aber am Ende mussten die Practices auch einen starken Nutzen für die Security haben, um ihre Existenz auf einer Liste für Secure Coding Practices zu rechtfertigen. Es gab inhaltlich solide Vorschläge, die aber leider nicht mehr Security-Nutzen hergaben als “der Code wird besser lesbar”, was man mit “die Reaktion auf Vorfälle wird einfacher” übersetzen kann. Solche Practices haben es nicht auf die Liste geschafft.

Gewissermaßen ist das Label “Security-Ziel” also die kondensierte, vereinfachte Form des “Why”-Abschnitts. Wenn man sich nur diese Labels ansieht, bekommt man einen guten Eindruck davon, zu welchen Security-Zielen SPS-Logik und -Konfigurationen gut beitragen kann (und zu welchen eher nicht):

• Integrität (integrity): Dies ist das beliebteste Security-Ziel der Practices in unserer Liste.
  Von 20 Praktiken zielen ganze 12 auf die Integrität ab. Man kann sie weiter unterteilen in solche, die die Integrität der SPS-Logik, die Integrität der SPS-Variablen (einschließlich Timer und Counter) oder die Integrität der I/O-Werte verbessern.
• 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.

Zugegebenermaßen sind nicht alle der oben genannten Punkte glasklare Security-Ziele im engeren Sinne des Wortes. Man könnte mit Recht argumentieren, dass etwa Monitoring meist ein anderes Ziel verfolgt, zum Beispiel die Identifizierung von Integritätsverletzungen. Aber diese Security-Ziele sind die häufigsten Antworten, die uns auf die Frage “was verbessert sich für die Security, wenn ich das umsetze?” begegnet sind.

Da ist etwas, das viele Practices gemeinsam haben, und das ist auch der Grund, warum “Integrität” und “Überwachung” die beliebtesten Sicherheitsziele auf unserer Liste sind:
Viele Einträge auf unserer Liste nutzen die große Stärke von SPSen, nämlich die Tatsache, dass eine SPS einen Prozess besser “versteht” als die meisten anderen Geräte in einem Anlagennetzwerk — genau dafür wurden sie ja programmiert.
Wenn eine Variable einen unüblichen Wert annimmt, ist die SPS das beste Gerät, um dies zu erkennen, weil sie den Prozesskontext der Variable “kennt”. Wenn ein Ventil länger als erwartet braucht, um zu schließen, kann die SPS dies bemerken, da sie die direkte Rückmeldung vom Ventil erhält.
Wenn eine Berechnung plötzlich dazu führt, dass ein Abtastzyklus länger dauert als die letzte Million Zyklen, kann eine SPS “wissen”, dass etwas in der Berechnung jetzt anders ist.

Auch die Grenzen dessen, was Secure PLC Coding Practices (momentan) erreichen können, können Sie aus der Liste der Sicherheitsziele herauslesen. Denn etliche denkbare Sicherheitsziele sind nicht vertreten: Authentifizierung zum Beispiel oder andere Mechanismen, die Vertraulichkeit gewährleisten, wie Verschlüsselung.
Während SPSen also zu den sachkundigsten Bodyguards Ihrer Anlage werden können, weil sie Ihren Prozess auf eine Weise “verstehen”, wie es die meisten anderen Geräte nicht können, ist es wichtig zu erkennen, dass sie hochspezialisierte Bodyguards sind. Es ist sicher keine gute Idee, sich bei jedem Sicherheitsproblem auf die SPS-Logik zu verlassen, egal wie sicher sie programmiert ist. Manche Probleme lassen sich einfach besser außerhalb von SPSen lösen.

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”.

Natürlich haben wir nicht alle Praktiken weggeworfen, die nicht in diese Definition passen. Es gibt vielmehr eine zweite Liste, die darauf wartet, bearbeitet und aussortiert zu werden. Sie trägt den Arbeitstitel “Secure PLC Environment Practices”.

Selbst nach der Eingrenzung der Definition gab es weit mehr als 20 Kandidaten für die Top-20-Liste. Die Zusammenstellung der endgültigen Liste war eine echte Gemeinschaftsleistung, denn die Community konnte für Practices abstimmen. Die Top 20-Liste kann man sich also vorstellen wie die Bundesliga: Practices können dahin aufsteigen (und daraus wieder absteigen).
Es gab einige Zusammenlegungen, Gruppierungen, Bearbeitungen und Umformulierungen nach der Abstimmung, aber die Entscheidung, welche Praxen auf der Liste stehen, basiert auf den Stimmen, die die Nutzer auf unserer Top-20-Plattform abgegeben hatten.

Letzter wichtiger Hinweis zur Kompilation der Liste: Es ist nicht von Bedeutung, wo in der Liste eine Praxis zu finden ist. Nummer 1 ist nicht wichtiger als Nummer 20. Sie sind nach Security-Zielen gruppiert, das ist alles.

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:

• Erstens: Dass sie für Security-Experten selbstverständlich erscheinen, bedeutet noch lange nicht, dass sie es für SPS-Programmierer auch tun.
• 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.

Wir haben sie trotzdem aufgenommen, weil sie zwar aus vielen guten Gründen etablierte Best Practices für SPS-Programmierer sein können und vielleicht sogar auf anderen Best-Practices-Listen für die SPS-Programmierung stehen — aber unser Ziel ist es, deutlich zu machen, dass sie auch einen Security-Nutzen haben (und, auf der anderen Seite, ihre Nichtbeachtung auch ein Security-Problem werden kann).

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:

• Um den Zweck der Top 20 von weiter oben zu wiederholen: Als Mindestanforderung soll diese Liste ein gemeinsames Verständnis davon schaffen, was SPS-Security überhaupt bedeutet; was wir von einer “sicher programmierten” SPS erwarten können.
  Wenn es also Dinge gibt, bei denen sich alle einig sind, dass sie für eine Security im SPS-Programmieren wichtig sind, gehören sie auf jeden Fall in die Liste, egal wie selbstverständlich sie sind.
• 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.

Außerdem wurden die Texte nicht nur für SPS-Programmierer geschrieben, sondern zum großen Teil auch von SPS-Programmierern. Das Schreiben von Secure Coding Practices für SPSen hätte ohne diejenigen, die SPS-Programme täglich schreiben, nicht funktioniert. Wir hatten — und haben immer noch — die besten Diskussionen, wenn ein SPS-Programmierer die Stirn runzelte und sagte: “Keine Ahnung, wie der Quatsch hier umsetzbar sein soll, aber schaut mal, so machen wir das hier schon seit Jahren: … ”.

Dennoch kann auch “SPS-Programmierer” eine zu breite Zielgruppe sein. Denn es macht einen großen Unterschied, für was für ein Unternehmen diese Programmierer arbeiten — deswegen gibt es neben dem Security-Ziel ein zweites Label, das jede Practice hat: ein Zielgruppen-Label. Wir haben die ISA-62443 Rollendefinitionen “product supplier”, “integration /maintenance service provider” und “asset owner” verwendet, um deutlich zu machen, in welcher Phase des SPS-Lebenszyklus und von welcher dieser Rollen eine Practice wahrscheinlich am ehesten implementiert wird.

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.

Reicht Ihnen nicht? Wenn Sie sich noch intensiver beteiligen möchten an der inhaltlichen Arbeit, der Kommentarbearbeitung und an der Entscheidung, wohin sich das Top 20-Projekt in Zukunft entwickeln soll, beteiligt sein möchte: Nehmen Sie bitte Kontakt mit uns auf. Wir sind immer auf der Suche nach leidenschaftlichen SPS-Kennern und Kennerinnen, die unser kleines Kernteam ergänzen können!

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.

Thank you, dream team!

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.

Was wir nun hoffen, dass Sie es tun: die frohe Kunde verbreiten, dass es jetzt so etwas wie Secure Coding Practices für SPSen gibt. Teilen Sie das Dokument mit jedem Automatisierungsingenieur und jeder SPS-Programmiererin, die Sie kennen.
Und noch besser: Probieren Sie die Practices selbst aus und geben Sie uns Feedback, wie sie verständlicher, vollständiger, genauer oder einfacher zu implementieren werden können. Wir freuen uns auf jedes Fitzelchen Feedback.

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

Folgen Sie unserem Projekt auf Twitter: @secureplc.