War es wirklich ein eher ruhiger August oder liegt es daran, dass ich zwei Augustwochen auf dem Rad statt am Schreibtisch verbracht habe? Wie dem auch sei: Die Septemberausgabe des Schutzhelmbriefings kommt dieses Mal mit nur fünf Themen. Dafür haben wir Zeit, in Ruhe ein paar Hintergründe zu beleuchten - zum Beispiel Grundlagen-Vokabeln für die Produktzertifizierung nach ISA/IEC 62443.

In die Sättel, Helme auf, wir radeln los!

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

1. Produktzertifizierung nach ISA/IEC 62443: Vokabeln und Zwischenstand
2. Zero-Trust-Architektur
3. BigData-News in der OT: Aveva kauft OSIsoft, Splunkt OT-Security Plugin
4. Schwachstellen-Karussell: Mitsubishi, DNP3, Siemens und Ampeln
5. Waterfall-Podcast zu R&I-Fließbildern für Security

1. Produktzertifizierung nach ISA/IEC 62443: Vokabeln und Zwischenstand

Es sind noch ungelegte Eier, aber da sich die Zertifizierung von Automatisierungsprodukten nach ISA/IEC 62443 in diesem Zustand schon eine Weile befindet, werfen wir diesen Monat mal einen Blick darauf, denn es gibt ein paar interessante Entwicklungen.

Wer lieber liest als hört: Eine Einführung in das Top 20 Secure Coding Practices-Projekt finden Sie in den Lesestoff-Links und meinem Blog, wahlweise auf Deutsch oder Englisch.

Dafür müssen wir aber erst ein paar Zertifizierungs- (oder genauer: Konformitätsbewertungs-) Vokabeln lernen.

Fangen wir bei Adam und Eva an. Warum soll überhaupt die Security von Produkten zertifiziert werden? In Kürze: Transparenz, Vergleichbarkeit und Vertrauen.
Zertifikate sollen durch unabhängige Prüfung durch einen Dritten transparent und vergleichbar machen und Vertrauen dafür schaffen, dass bestimmte Anforderungen erfüllt werden. Das funktioniert aber nur, wenn nachvollziehbar und vergleichbar ist, welche Kriterien für ein Zertifikat erfüllt werden müssen. Für die Definition solcher Kriterien eignen sich Standards.

Um Transparenz, Vergleichbarkeit und Vertrauen zu gewährleisten, müssen vor einer Zertifizierung also ein paar Fragen geklärt werden:

Erstens die, welche Standards überhaupt für ein bestimmtes Zertifikat zugrunde gelegt werden. Das wird in Prüfschemata festgelegt, z. B. von der bei der ISA angesiedelten ISAsecure, bei der IEC angesiedelten IECEE oder auch von der deutschen Akkreditierungsstelle DAkkS.
Zertifizierung nach ISA/IEC 62443 bedeutet Zertifizierung des Entwicklungsprozesses (ISA/IEC 62443-4-1), Zertifizierung konkreter Lösungen (ISA/IEC 62443-4-2 oder -3-3) oder beides.

Wenn die zu prüfenden Standards feststehen, bleibt die Frage, welche Anforderungen aus diesen Standards für die Zertifizierung verpflichtend erfüllt sein müssen. Wenn das Prüfschema und die prüfende Stelle dies zulässt, könnte im Extremfall ein Zertifikat über die Erfüllung nur einer einzigen Anforderung eines Standards ausgestellt werden.
Weil solche "Rosinenpickerzertifikate" der Glaubwürdigkeit solcher ISA/IEC62443-Zertifikate nicht gerade zuträglich wären, bemühen sich insbesondere die deutschen Spiegelgremien der IEC, sogenannte Profile zu etablieren. Profile definieren einen festes Mindest-Set von Anforderungen, die für ein Zertifikat nach einem bestimmten Profil erfüllt werden müssen.

Die dritte Frage zugunsten Transparenz, Vergleichbarkeit und Vertrauen in das Zertifikat ist die, wie die Erfüllung der Anforderung bewertet wird. Das wird in Prüfmethoden oder Evaluation Methods festgelegt.

Und dann gibt es noch eine Bonusfrage: Die Security einer Komponente lässt sich nur schwierig beantworten, in dem man die Komponente im luftleeren Raum prüft. Security hängt maßgeblich davon ab, in welcher Umgebung und zu welchem Zweck die Komponente verwendet wird. Um das besser zu definieren, müsste man diese Einsatzweisen modellieren.

Der Termin für das deutschsprachige Webinar ist am Donnerstag, 06. August, um 10 Uhr. Für die Anmeldung einfach auf diese Mail antworten. Einen deutschsprachigen Einstieg in die Secure PLC Coding Practices finden Sie im Lesestoff-Link.

Mit dieser länglichen Einführung ist der aktuelle Stand schnell erklärt:

• Für das IECEE-Prüfschema werden momentan bei der IEC Regeln für Profile erarbeitet
• Zwei Anträge für neue IEC-Projekte sind unterwegs: Konkrete Profile und konkrete Evaluation Methods - was daraus wird, entscheidet sich im Herbst
• An die Beantwortung der Bonusfrage macht sich momentan der TeleTrust und ZVEI: Die Einsatzweise der Komponenten soll in sogenannten Use Cases modelliert werden. Ergebnisse sind ebenfalls für den Herbst geplant.

Übrigens gilt bei allen ungelegten Eiern und verschachtelten Vokabeln: Wer langfristig Produkte zertifizieren möchte, muss nicht warten, bis die Haarspalterei um Prüfschemata und Anforderungen erledigt ist.
Die grundlegenden Anforderungen für Security in der Produktentwicklung sind in allen relevanten Standards dieselben, brauchen ein bisschen Zeit und Spucke, bis sie umgesetzt sind - und können, richtig angegangen, den Produktentwicklungsprozess sogar effizienter machen.
(Nicht, dass mir hier jemand nachsagt, ich hätte zum Abwarten und Teetrinken geraten! :) )

2. Zero-Trust-Architektur

Ich höre ja oft, Security sei ungefähr so erfreulich wie der Gang zum Steuerberater. Nachvollziehbar, wenn sie mit solchen Konzepten um die Ecke kommt: Zero Trust, oder: Grundsätzlich erstmal misstrauen! Allen!

Was unsympathisch und anstrengend klingt, kann als Designprinzip die Arbeit erleichtern - vor allem, wenn verschiedenen Organisationseinheiten und / oder Standorte miteinander kommunizieren, etwa durch Fernzugriffe, Cloud-Umgebungen oder Fremdgeräte im Netz.

Zero Trust bedeutet ein Umdenken weg von der Kategorisierung in "vertrauenswürdige" und "fremden" Netze. Statt vor allem den Perimeter zu schützen, also die äußerste Netzwerkgrenze zwischen fremdem und eigenem Netz, wird gewissermaßen jedes einzelne System als Perimeter gesehen.

Die US-amerikanische Behörde NIST hat nun ein Dokument veröffentlicht, das Zero Trust erklärt, systematisiert und Umsetzungsszenarien beschreibt (Link im Lesestoff).
Wertvoll: Das Kapitel 2, das Zero-Trust-Prinzipien definiert und das Kapitel 3, das funktional (nicht durch konkrete Produkte) die Komponenten einer Zero-Trust-Architektur erklärt.

Dabei wird zugleich auch die wohl größte Schwachstelle des Ansatzes deutlich (die das Dokument in einem weiteren Kapitel auch differenziert betrachtet): Auch Zero Trust muss einer zentralen Komponente vertrauen: Nämlich der "Policy Engine", die die Berechtigungen aller anderen Komponenten im Netz verwaltet und prüft.

3. BigData-News in der OT: Aveva kauft OSIsoft, Splunk OT-Security-Plugin

Daten sind das Gold des 21. Jahrhunderts - das ist mittlerweile eine Binsenweisheit.

Eines der offensichtlichen Anwendungsfelder für Big Data ist die Security: Welche Assets habe ich? Welche Protokolle sprechen diese Assets? Welche Schwachstellen haben diese Assets? Welche Patches gibt es? Gibt es Hinweise auf Schadcode? Was für Security Events habe ich? Zu welchen Anforderungslisten sind meine Assets konform?

Weil OT-Assets tendenziell andere Logformate und Protokolle haben als IT-Assets, sind sie nicht ohne weiteres in IT-Datensammellösungen mit abgedeckt. Kompetenz könnte also aus zwei verschiedenen Richtungen kommen:
Durch Firmen, die die vielen OT-Formate bereits einsammeln können und Input und Auswertungen für Security-Zwecke ergänzen und durch Firmen, die Security-relevanten Input und Auswertungen bereits für IT können, und nun zusätzlich die verschiedenen OT-Formate einsammeln ergänzen.
Zwei Firmen haben sich im vergangenen Monat dahingehend breiter aufgestellt - aus jeder Richtung eine: OSIsoft, seit Jahrzehnten ausschließlich in der OT beheimatet, gehört nun zu Aveva (Schneider Electric). Splunk, bislang eher in der IT(-Security) beheimatet, hat nun eine Plugin explizit für OT-Security.

1. Schneider-Electric-Tochter Aveva kauft OSIsoft

OSIsoft entwickelt Software, um Betriebsdatenverarbeitung an einer zentralen Stelle zu bündeln und zu analysieren. Das Problem der vielen heterogenen Assets und Protokolle hat man durch jahrzehntelange Entwicklung von Kollektoren gelöst.
OSIsofts Analysen dienen der Prozess- und Asset-Optimierung, nicht vordergründig der Security. Die große Basis an Kollektoren wäre für Security-Anwendungen aber durchaus auch interessant. Mit der Übernahme durch Aveva, eine Tochter von Schneider Electric, für 5 Milliarden USD (Lesestoff-Link 1a), darf man mindestens gespannt sein, ob es Entwicklungen in Security-Richtung geben wird.
Eine Prognose wagt Dale Peterson in seinem Artikel zur OSIsoft-Übernahme (Lesestoff-Link 1b): Bislang ist der herstellerneutrale OSI PI Historian von den Leitsystemherstellern toleriert worden - das könnte nun schwieriger werden und somit den Weg für Amazon AWS und Microsoft Azure Clouds für Betriebsdaten ebnen.

2. Splunk gibt OT-Security-AddOn bekannt

Splunk ist einer der bekanntesten Anbieter zur Sammlung, Indizierung und Verarbeitung großer Datenmengen (Big-Data) vor allem aus Logdaten.
Splunk Enterprise Security, vor allem als SIEM (Security Incident and Event Management) bekannt, war bislang nicht spezifisch auf OT ausgerichtet. Seit Mitte August gibt es nun ein offizielles Splunk-Plugin für OT - es setzt allerdings voraus, dass man Splunk Enterprise Security bereits hat.

4. Schwachstellen-Karussell: Mitsubishi, DNP3, Siemens und Ampeln

Ohne ein paar neue OT-Schwachstellen kommt so gut wie kein Monat aus, so auch dieser nicht. Hier der Überblick:

1. Mitsubishi

Es ist eine lange Liste betroffener Mitsubishi-Electric-Produkte, die im Mitsubishi-Advisory ICSA-20-245-01 des US CERT aufgezählt werden.
Die genannte Schwachstelle (CVE-2020-16226) ermöglicht TCP-Hijacking. Die TCP-Session-IDs sind vorhersehbar, was es einem Angreifer möglich macht, die Passwortauthentifizierung zu umgehen und unautorisiert mit den betroffenen Geräten zu kommunizieren (er muss dafür natürlich schon Zugriff aufs Netzwerk haben).
Es sieht bislang so aus, als gäbe es nicht wirklich ein Patch, sondern nur Vorschläge für mitigierende Maßnahmen ("lassen Sie halt nicht zu, dass jemand ins Netzwerk kommt und kontaktieren Sie Mitsubishi").
Das vollständige Advisory finden Sie im Lesestoff-Link.

2. DNP3

Wir erinnern uns noch an Ripple20? Die Entdecker tauften die Schwachstellensammlung "Ripple" nach dem "Ripple Effect": Ins Wasser geworfen zieht auch ein unscheinbarer kleiner Stein große Wellen. Bei Ripple20 war dies der Fall, weil die Schwachstelle einen Low-Level, also tief in der Kommunikation vieler Anwendungen verborgenen Protokoll-Stack betraf.
Ähnlich ist es bei den Triangle MicroWorks-Schwachstellen, die im Januar bei Pwn2Own am Rande der S4 in Miami vorgestellt und im April als CVEs und US-CERT-Advisory veröffentlicht wurden: Sie betreffen den DNP3-Protokollstack. Details hat die Zero Day Initiative nun in ihrem Blog veröffentlicht, der sich im Lesestoff-Link findet.

Als direkt betroffen wird im Advisory nur das SCADA DataGateway von Triangle MicroWorks (TMW) genannt (eingesetzt vor allem in der Energie- und Wasserbranche). Ähnlich wie Treck im Fall von Ripple 20 entwickelt Triangle MicroWorks aber nicht nur das genannte Gateway, sondern auch den Code für den DNP3-Protokollstack - der potenziell von vielen anderen Herstellern genutzt wird. Betreiber haben oft keine Information darüber, welcher zugelieferte Code sich in den Produkten ihrer Hersteller verbirgt, und TMW trifft bislang keine Aussage dazu.

3. Siemens

Mit 20 neuen Advisories des Siemens Product CERT war der August für Administratoren, die für das Patchen von Siemens-Produkten verantwortlich sind, ein eher arbeitsintensiver. Immerhin: Für die meisten der Schwachstellen gibt es ein Patch.

Eine gute Nachricht zu Siemens gibt es auch: Ein Student von Ali Abbasi an der Ruhr-Uni Bochum hat in einer Bachelorarbeit einen Fuzz-Tester für Siemens S7-Steuerungen entwickelt. Flächendeckendes Fuzz-Testing wäre ein großer Schritt in die richtige Richtung, um Schwachstellen schon im Entwicklungsprozess zu entdecken.

4. Ampeln

Ein Vortrag der Niederländer Wesley Neelen und Rik van Duijn bei der diesjährigen (Corona-bedingt virtuellen) Security-Konferenz DEFCON dreht sich um das Manipulieren von Ampeln. Die Forscher taten so, als wären Sie ein Fahrrad - und konnten damit mittels spezieller Apps, die den Verkehrsfluss für Fahrräder optimieren soll, verhindern, dass Ampeln auf Grün schalten. Das Besondere daran: Sie mussten dafür nicht einmal in der Nähe der Ampel sein.
Lesson learned: Vorsicht mit den neuen Kommunikationskanälen - normalerweise nehmen Ampeln nämlich nicht einfach Nutzereingaben entgegen, für die Fahrrad-Apps war das aber nötig.
Hier gehts zum Video des Vortrags, eine Zusammenfassung findet sich bei WIRED im Lesestoff-Link "Hacking Traffic Lights".

5. Waterfall-Podcast zu R&I-Fließbildern für Security

Abschließend ein Hinweis in eigener Sache: Schon im Januar, am Rande der S4x20 in Miami, haben Andrew Ginter und ich einen Podcast zum Thema R&I-Fließbilder für Security Engineering aufgezeichnet.
Das Thema ist kompliziert, das wurde schon während der Aufzeichnung und den umfangreichen Vorgesprächen klar. Die Überlegungen im Podcast-Gespräch sind noch frisch und unsortiert, und Andrew und ich sortieren gemeinsam. Später im Frühjahr habe ich meine Gedanken dazu noch einmal in einem Blogpost zusammengefasst, den Sie vielleicht schon kennen.
Nun ist auch der Podcast bei Waterfall verfügbar - Link hier:

Stay secure!
Sarah Fluchs