Der Mai war frei von spektakulären OT-Schwachstellen und -Vorfällen, also bleibt im Juni-Briefing Zeit für etwas zeitlosere Themen. Was immer geht: Mit Buzzwords aufräumen. Dieses Mal knöpfen wir uns (I)IoT vor.
Außerdem gibt es neue, praktisch hilfreiche Veröffentlichungen aus den USA, von CISA und NIST. Und zum Abschluss den Hinweis auf zwei Kongresse hier in Deutschland, und zwar in Präsenz. Vielleicht treffe ich ja jemanden von Ihnen?

In dieser E-Mail gibt es Neuigkeiten und Lesestoff zu folgenden Themen:

1. Was ist eigentlich (I)IoT?
2. Was sind eigentlich Security-Probleme von (I)IoT?
3. Katalog ausgenutzter Schwachstellen
4. Neue Version des NIST OT-Security-Leitfadens NIST SP 800-82
5. Kongresse im Juni: EKA, AUTOMATION

1. Was ist eigentlich (I)IoT?

Das "Internet of Things" (IoT) ist schon lange zum Buzzword geworden, und wird meistens damit assoziiert, dass Geräte Kühlschränke und Waschmaschinen selbst ins Internet gehen und zum Beispiel Nachschub bestellen können. Um klar zu machen, dass es nicht um Produkte für den Endkonsumenten wie Kühlschränke und Waschmaschinen, sondern um industrielle Produkte wie Pumpen und Durchflusssensoren zum Beispiel in verfahrenstechnischen Anlagen geht, gibt es noch das "Industrial Internet of Things" (IIoT).

So weit sind wir uns noch einig. Aber ist "IIoT" dann einfach nur ein fancy neuer Begriff für Sensoren, Aktoren und Steuerungen, die wir schon lange kennen? Tatsächlich ist die allgemeine Definition von IoT, dass mindestens ein Wandler zwischen der physischen und der digitalen Welt existiert.
J-D Bamford dröselt in einem lesenswerten Blog-Artikel (Lesestoff 1), liebevoll mit Zeichnungen illustriert, die IoT-Definitionen von NIST, ENISA & Co auseinander und versucht eine Abgrenzung zu herkömmlichen "Industrial ControlSystems" (ICS). Er destilliert drei Unterscheidungsmöglichkeiten zwischen ICS und IIoT heraus:

1. IIoT-Komponenten können unabhängig von zusätzlichen Komponenten funktionieren.
   (Dies schließt den klassischen Sensor oder Aktor aus, der ohne eine SPS nichts steuern oder regeln kann).
2. IIoT-Komponenten verwenden Netzwerkprotokolle.
   (Dies schließt Geräte mit dem klassischen analogen Kommunikationsschnittstellen wie zum Beispiel über 4-20mA aus).
3. IIoT-Komponenten sind an ein öffentliches Netzwerk angeschlossen.
   (Dies schließt Geräte aus, die zwar 1. und 2. erfüllen, aber nur im privaten Netzwerk einer Anlage ohne Schnittstellen nach außen verwendet werden).

Mir persönlich würde für die Abgrenzung zu ICS Punkt 1 reichen.
Punkt 2 finde ich schwierig, weil die Definition den neutralen Boden des "was" verlässt und das "wie" (welche Protokolle) mit einbezieht - außerdem bräuchte man ohne Punkt 2 (Netzwerkprotokolle) auch die Präzisierung in Punkt 3 (aber nicht, wenn nur interne Netzwerke!) nicht.

Unabhängig davon: Mit Punkt 3 wird klar, dass es ohnehin keine "IIoT-Geräte" gibt, sondern nur solche, die für IIoT-Zwecke eingesetzt werden können (oder nicht). Es ist wie mit den "Security Capabilities" aus der ISA-62443: Ein Gerät bietet sie an oder nicht, aber ob es sicher ist oder nicht, hängt davon ab, ob die "Capabilities" auch genutzt werden.

In einem Nachfolgeartikel (Lesestoff 2) bietet J-D zusätzlich eine Grafik an, die die (I)IoT-Definition unabhängig von der Abgrenzung zu ICS aus meiner Sicht gut verallgemeinert, ohne technische Festlegungen zu treffen:

(I)IoT ist alles, was eine Verbindung zwischen der physischen und virtuellen Welt UND einer vertrauenswürdigen und einer nicht vertrauenswürdigen Zone herstellt.

Passt das zu dem, was Sie sich vorstellen, wenn Sie "IIoT" hören?

2. Was sind eigentlich Security-Probleme von (I)IoT?

Da wir zum Thema IoT nun schon einmal warmgelaufen sind, kommt nun noch etwas Security-Bezug hinterher. Sinclair Koelemij hat ein interessantes Paper von 2013 ausgegraben (siehe Lesestoff), das einen guten Überblick über mögliche Security-Gefährdungen für IoT-Geräte gibt. Wer möchte, kann danach auch eine Reise in die Bits und Bytes hinter den Gefährdungen antreten.

Wir begnügen uns erst einmal mit dem Überblick:
Warum gibt es überhaupt zusätzliche Bedrohungen, wenn Geräte für IoT-Zwecke eingesetzt werden?

Das hat laut Paper drei mögliche Ursachen:

1. IoT-Geräte sind typischerweise physisch im öffentlichen Raum verortet (oder zumindest leicht zugänglich).
2. IoT-Geräte können miteinander digital kommunizieren.
3. IoT-Geräte verarbeiten möglicherweise sensible (z.B. personenbezogene) Daten.

Sie merken schon: Das passt gut zur IoT-Definition, die wir uns soeben erarbeitet haben. IoT-Geräte verbinden die physische mit der virtuellen Welt - also können sie digital kommunizieren, mit allen üblichen Bedrohungen (Punkt 2).
IoT-Geräte verbinden vertrauenswürdige mit nicht vertrauenswürdigen Zonen - also können sie aus der nicht vertrauenswürdigen Zone angegriffen werden (Punkt 1) oder Daten aus der vertrauenswürdigen Zone preisgeben (Punkt 3).

Außer Punkt 1 sind die Gründe für die Security-Bedrohungen nicht besonders IoT-spezifisch. Digitale Kommmunikation und sensible Daten sind definitiv nicht IoT-Geräten vorbehalten. Allerdings kann man gegen die physischen Bedrohungen unter Punkt 1 auch nicht viel tun, außer die Geräte physisch wegzusperren.
Bei den Punkten 2 und 3 schon, und hier liegt der eigentliche Unterschied zwischen IoT-Geräten und Nicht-IoT-Geräten nicht in den möglichen Gefährdungen, sondern in den Unterschieden der verwendeten Protokolle - also in den Bits und Bytes. Hier steigen die Autoren tiefer ein, wobei sie IP-basierte Kommunikation annehmen - aber selbst da sind die Unterschiede schon groß. Das Paper zeigt den üblichen Protokoll-Stack für IoT-Geräte und diskutieren ausführlich, welche Security-Protokolle für diesen Protokoll-Stack vorhanden und geeignet sind:

Sicher, das Paper ist von 2013. Es deckt nicht alle heute für IoT verwendeten Protokolle ab und die kryptografischen Mechanismen haben sich weiterentwickelt. Aber in seiner klaren Strukturierung des Protokoll-Stacks und der Analyse von Security-Eigenschaften jeder Ebene ist es trotzdem lesenswert für alle, die sich mit der Absicherung von IoT-Kommunikation beschäftigen (müssen).

Man kann es auch als gute Checkliste für Security-Themen nutzen, über die man bei der IoT-Kommunikation zumindest mal kurz nachdenken sollte:

• Protokollkonfiguration: Welche Security-Eigenschaften kann man in IoT-Protokollen konfigurieren (und welche nicht, die man von "normaler" IP-basierter Kommunikation gewohnt ist)?
• Ressourcenschonende Kryptografie: Welche kryptografischen Algorithmen sind geeignet für die häufig ressourcenschwächeren IoT-Geräte?
• Geräteauthentifizierung: Wie funktioniert die Authentifizierung der IoT-Geräte, wenn sie untereinander kommunizieren sollen? Wenn kryptografisch: Wie können Schlüssel sicher ausgetauscht werden?
• Zugriffsschutz für Daten und Services: Wie funktioniert die Autorisierung für bestimmte Services oder bestimmte Daten? Gibt es Daten oder Services, auf die nicht jeder Zugriff haben sollte?

3. Katalog ausgenutzter Schwachstellen

Wer sich schon einmal mit Patch Management befasst hat, kennt das Problem: Einfach alles zu patchen, ist für die OT nicht machbar. Eine interessante Information für die Einschätzung der Relevanz einer Schwachstelle ist, ob sie schon einmal ausgenutzt wurde. Nur schade, dass es dazu keine Datenbasis gibt...

...oder doch? Die US-amerikanische CISA (Cybersecurity & Infrastructure Security Agency) hat vor etwa einem halben Jahr einen Katalog über ausgenutzte Schwachstellen begonnen. Dort finden sich mittlerweile hunderte Einträge. Sicher nichts, was man manuell auswerten kann, aber wer eine automatisiert ausnutzbare Quelle für sein Patchmanagement sucht, könnte hier fündig werden.

4. Neue Version des NIST OT-Security-Leitfadens NIST SP 800-82

Es ist der Wälzer unter den OT-Security-Leitfäden: Die Special Publication 800-82 des US-amerikanischen National Insitute for Standards and Technology (NIST). Die letzte Version (Revision 2) ist von Mai 2015.

Nun hat NIST den Entwurf (es kann noch kommentiert werden) der Revision 3 veröffentlicht. Außer 50 zusätzlichen Seiten fällt auf den ersten Blick auf: Schon im Titel geht der Report mit dem Zeitgeist. War es 2015 noch ein "Guide to Industrial Control Systems (ICS) Security", wurde das ICS nun durch OT ersetzt. "Security" ist gleichzeitig "Cybersecurity" geworden - den Kampf, nicht überall "Cyber" davorzuschreiben, können wir dann wohl als verloren verbuchen.

Auch sonst kann man am grundüberholten Aufbau des Leitfadens einiges an Zeitgeist und über die Jahre errungenen Konsens ablesen. Die vier Kapitel (zu Security-Managementsystem, Risikomanagement, grundlegenden Security-Prinzipien und Detailmaßnahmen) sind deutlich aufgeräumt und von Redundanzen befreit.

Am erfreulichsten: Es gibt kein wildes Sammelsurium von Maßnahmen mehr ("yet another security framework", sondern stattdessen gut strukturierte Erklärungen zu grundlegenden Security-Prinzipien und dann einen Leitfaden für die Anwendung des etablierten NIST Cybersecurity Framworks, beides spezifisch für OT.

Dreihundert Seiten sind viel Holz, aber tatsächlich ist hier ein gutes, umfassendes Werk geglückt, das sich gerade auch zum (tieferen) Einstieg in das Thema OT-Security gut eignet.
Einige Juwelchen:

• Das Kapitel "OT Overview" erklärt grundlegende Begriffe aus der OT mit übersichtlichen Architekturzeichnungen so, dass auch OT-Neulinge eine Vorstellung bekommen. Auch eine Beispielarchitektur für IIoT ist dabei. Wenn nun noch die Begriffe IIoT und ICS so schön abgegrenzt wären, wie wir das im heutigen Briefing gelernt haben....aber es muss ja noch Luft nach oben bleiben.
• Das Kapitel "Business Case for OT Cybersecurity Program" gibt jede Menge Argumentationsschützenhilfe für einen oft vernachlässigten Aspekt, wenn "Techies" Security machen: Wie gewinne ich mein Management dafür?
• Das Kapitel "Defense-in-Depth Architecture Capabilities" ist für ein Kapitel über "Defense in Depth" erstaunlich konkret und brauchbar. Es bleibt nicht beim flauschigen Hinweis, dass Security-Maßnahmen in mehreren Schichten sinnvollsind, sondern es werden fünf Schichten explizit benannt: Management, Physische Sicherheit, Netzwerk, Hardware, Software.
• Das Kapitel "Cybersecurity Architecture Models" greift die Architekturzeichnungen aus dem Kapitel "OT Overview" auf und zeigt "sichere" Varianten. Sehr konkret, sehr brauchbar.
• Das Kapitel "Applying the Cybersecurity Framework to OT" dekliniert sämtliche Maßnahmen des NIST Cybersecurity Frameworks durch und versieht sie mit OT-spezifischen Anmerkungen. Manchmal sind die Anmerkungen dann doch recht generisch, aber insgesamt ist das ein beeindruckender Wissensschatz - und hilft, wenn man behördliche Unterstützung für seine Argumente braucht, warum bestimmte Security-Maßnahmen in der OT nicht so einfach anwendbar sind.

5. Kongresse im Juni: EKA, AUTOMATION

Das glaube ich erst, wenn ich da bin: Kongresse in Präsenz sind zurück!
Ende Juni bin ich in Magdeburg bei der EKA (Entwurf komplexer Automatisierungssysteme) und dann in Baden-Baden bei der AUTOMATION.

Bei beiden Kongressen stelle ich Ergebnisse aus unserem IDEAS-Projekt vor. Es dreht sich alles darum, was eigentlich Security-by-Design-Entscheidungen für Automatisierungssysteme sind, wie man sie in seinen bestehenden Engineeringprozess integrieren kann, wie man sie trifft und wie man sie später noch nachvollziehen kann.
Zu beiden Vorträgen gibt es ein Paper im Tagungsband. Die Inhalte schauen wir uns in den HardHats-Briefings natürlich auch noch an.

Bis dahin: Sehe ich jemanden von Ihnen in Magdeburg oder Baden-Baden?
Sagen Sie Hallo, ich freue mich!

Stay secure!
Sarah Fluchs