Herzlich willkommen im Juli!
Diesen Monat ist das Security-Briefing etwas IEC-62443-lastig, gleich zwei große Themen haben wir uns vorgenommen: Den nach acht Jahren fertigen Standard IEC 62443-3-2:2020 zum Risikomanagement und die Restrukturierung der gesamten Standardreihe. Beides sind Meilensteine, ein genauerer Blick lohnt sich.
Es gibt aber auch sieben weitere Themen, die nichts mit der IEC 62443 zu tun haben - versprochen.

Also, Schutzhelme auf und los geht's.

Diesen Monat gibt es Neuigkeiten und Lesestoff zu folgenden Themen:

1. IEC 62443-3-2:2020 (Risikomanagement) nach acht Jahren Arbeit veröffentlicht
2. Fluchsfriction-Blog: In Funktionen denken, nicht in Systemen!
3. UN entwickelt Regulierungsvorschlag für Security bei Fahrzeugzulassungen
4. BSI-/Wirtschaftsprüfer-Dokument "§ 8a (1) - Konkretisierung der KRITIS-Anforderungen"
5. Harmonisierung der IEC 62443: Bye bye, Foundational Requirements
6. Joel Langills Linkliste zu OT-Security
7. Aktualisierter Marktüberblick über Security-Monitoring-Produkte
8. Ripple-20-Schwachstellen in TCP/IP-Softwarebibliothek für OT & IoT
9. Noch mehr Schwachstellen: Siemens Netzwerkkomponenten, SWARCO Verkehrssteuerungen

1. IEC 62443-3-2 (Risikomanagement) nach acht Jahren Arbeit veröffentlicht

Diese Nachricht verdeutlicht, wie viel Arbeit hinter einem konsensbasierten Standard steht: Acht Jahre lang hat die Arbeitsgruppe 4, Task Force 3 der ISA99 unter Leitung von John Cusimano an der IEC 62443-3-2 gearbeitet, die den Risikomanagementprozess beschreibt. Sie ist jetzt als internationaler Standard IEC 62443-3-2:2020 veröffentlicht und im IEC Webstore erhältlich.

Der Standard hat nun den Titel "Security risk assessment for system design". Wer noch aus der 2010er-Version der IEC 62443-2-1 die Unterteilung in "High level risk assessment" und "Detailed risk assessment" kennt, muss sich nur leicht umgewöhnen: Aus dem "High level" wird ein "Initial" risk assessment.
Das Konzept der "Zones and Conduits", eines der 62443-Kernkonzepte, spielt im Risikomanagement eine wichtige Rolle.
"Zones and Conduits" lässt sich in etwa mit "Zonen und Zonenübergänge" übersetzen, wobei ein Zonenübergang als ein Bündel an Kommunikationskanälen zwischen zwei Zonen zu verstehen ist.

Die neue IEC 62443-3-2 definiert sieben Anforderungen an die Risikoanalyse, die ZCRs - "Zone, conduit and risk assessment requirements".
Der Prozess in Kürze:

• Initiale Abschätzung des Worst-Case-Risikos
• Unterteilung des Systems in "Zones and Conduits" basierend auf dieser initialen Abschätzung
• Detaillierte Risikoeinschätzung für jede Zone und jeden Zonenübergang (Conduit) inklusive Definition von SL-T (Target Security Level) und Security-Anforderungen.

Zwei Punkte sind besonders beachtenswert, weil sie Weiterentwicklungen der bisherigen Vorstellung einer Risikoanalyse gemäß IEC 62443 darstellen:

Erstens: Risiko für Zonen und Conduits, nicht für Einzelsysteme
Die detaillierte Risikoanalyse (das ist die, die dem gängigen Verständnis einer Risikoanalyse mit Bedrohungen, Schwachstellen und Risikomatrix entspricht) wird nicht für jedes einzelne System, sondern nur für jede Zone und jeden Zonenübergänge (Conduit) gefordert.

Zweitens: Flexibilisierung der Security-Level
Auch die Security Level sind nicht mehr zwangsläufig pro System, sondern auch je Zone und Conduit gedacht: "[SL is the] measure of confidence that the SUC, security zone or conduit is free from vulnerabilities and functions in the intended manner".
Wie ein Security Level zu definieren ist, lässt der Standard bewusst offen und nennt die bislang häufig zitierte Definition nach Angreiferfähigkeiten als eine Methode von vielen. Andere Vorschläge sind die Definition des SL-T als Unterschied zwischen dem Brutto-Risiko und dem tolerierbaren Risiko oder ein iterativer, qualitativer Ansatz, der SL-T an die umzusetzenden Maßnahmen koppelt und basierend auf einem initialen geschätzten Wert schrittweise erhöht, wenn das Risiko unter Berücksichtigung der bisherigen Maßnahmen nicht akzeptabel ist.

Beides erleichtert Aspekte, die Anwendern (und ihren Beratern :) ) bislang Kopfschmerzen bei der Umsetzung der Risikoanalyse gemäß IEC 62443 gemacht haben.

Den vollständigen Standard im IEC-Webstore finden Sie im Lesestoff-Link:

2. Fluchsfriction-Blog: In Funktionen denken, nicht in Systemen!

Wenn Sie dieses Jahr nur eine einzige Änderung in Ihrer Herangehensweise an Security vornehmen wollen, schlage ich vor, Sie nehmen diese: Fangen Sie an, in Funktionen zu denken, nicht in Einzelsystemen. Hören Sie mit der "Klötzchendenke" auf!
Ich kenne nichts, was das Denken besser ordnet und Security systematischer macht als Funktionen. Wirklich nicht.
Und weil ich mich damit ständig wiederhole, finden Sie die wichtigsten Gründe pro Funktionen nun in meinem Blog im Lesestoff-Link. Langversion (auf Englisch) gibt's zusätzlich hier.

3. UN entwickelt Regulierungsvorschlag für Security bei Fahrzeugzulassungen

Noch druckfrisch: Die UNECE (United Nations Economic Commission for Europe) hat am 23. Juni einen Vorschlag vorgelegt, wie Security bei der Fahrzeugzulassung berücksichtigt werden soll.
Der Vorschlag sieht zwei Kernforderungen an Fahrzeughersteller vor: Der Nachweis eines Managementsystems (CSMS, Cyber Security Management System) und der Nachweis seiner Anwendung auf einen bestimmten Fahrzeugtypen.
Das CSMS wird im parallel entwickelten Standard ISO/SAE 21434 beschrieben, für den Ende 2020 die finale Fassung erwartet wird. Momentan liegt der Standard in der DIS-Version (Draft International Standard) vor.

Die Forderungen entsprechen im Prinzip dem Ansatz, der auch die IEC 62443 für die Zertifizierung von Produkten vorsieht: Einerseits der sichere Produktentwicklungsprozess (IEC 62443-4-1), andererseits technische Anforderungen für konkrete Produkte oder Produkttypen (IEC 62443-4-2).
Die Regulierungsbemühungen für Produkte in der industriellen Automatisierung sehen wir uns in einem der kommenden HardHats-Briefings an.

Die offizielle Pressemitteilung der UNECE zur Veröffentlichung des Regulierungsentwurfs finden Sie hier.
Für eine schnelle Übersichtsgrafik über die Anforderungen sei dieser Blogbeitrag empfohlen.
Und einen Blick in die Originalforderung der UNECE können Sie im Lesestoff-Link werfen.

4. BSI-/Wirtschaftsprüfer-Dokument "§ 8a (1) - Konkretisierung der KRITIS-Anforderungen"

Ohne großen Wirbel wurde es bereits Ende März veröffentlicht: Ein Papier zur "Konkretisierung der Anforderungen an die gemäß § 8a Absatz 1 BSIG umzusetzenden Maßnahmen".

Wir erinnern uns: § 8a Absatz 1 BSIG, das war der mit dem Stand der Technik: KRITIS-Betreiber sollen "angemessene organisatorische und technische Vorkehrungen zur Vermeidung von Störungen der Verfügbarkeit, Integrität, Authentizität und Vertraulichkeit ihrer informationstechnischen Systeme, Komponenten oder Prozesse" treffen und dabei den Stand der Technik einhalten.
Was angemessene Vorkehrungen sind, ist nicht so einfach definierbar und außerdem höchst unterschiedlich für verschiedene KRITIS-Sektoren. Die ISO/IEC 27001 reicht dafür explizit nicht, sondern muss branchenspezifisch ergänzt werden - so ist es unter anderem in der "Orientierungshilfe zu Nachweisen gemäß § 8a Absatz 3 BSIG" zu lesen.
Mehrere Sektoren haben branchenspezifische Sicherheitsstandards (B3S) erarbeitet, um den schwer fassbaren § 8a (1) zu konkretisieren - für ihren eigenen Sektor, wohlgemerkt.

Wie schafft es nun ein Ausschuss des Instituts der Wirtschaftsprüfer in Deutschland e.V. (IDW), die Anforderungen nach § 8a (1) mal eben sektorübergreifend zu konkretisieren?

Dafür müssen wir mindestens ins Jahr 2016 zurückschauen. Damals hat das BSI den "Cloud Computing Compliance Criteria Catalogue", kurz C5, erstmals veröffentlicht, ebenfalls in Zusammenarbeit mit dem IDW. Die Prüfung der Cloud-Security-Kriterien soll gemäß dem Wirtschaftsprüfer-Standard ISAE 3000 "Assurance Engagements Other than Audits or Reviews of Historical Financial Information" erfolgen und mindestens die Hälfte des Prüfteams muss über "mehr als 3 Jahre Berufserfahrung in der Wirtschaftsprüfung" verfügen.
Die Cloud-Security-Kriterien selbst enthalten keine großen Überraschungen, wenn man übliche Informationssicherheitsstandards kennt.

Schon 2018 ist mir bei einem Nachweisaudit im KRITIS-Sektor "Ernährung" mal eine Version des "IDW PH 9.860.2" untergekommen. Das Dokument soll als Prüfgrundlage dienen für Wirtschaftsprüfer, die § 8a (3)-Audits durchführen müssen. Es bestand damals in einer mehr oder minder wörtlichen Übernahme des C5-Katalogs.
Nun, wenn man Cloud-Security-Kriterien hat, hat man auch KRITIS-Kriterien, richtig? Fängt ja beides mit "K" an...

Der IDW PH 9.860.2 ist Ende April 2020, einen Monat nach den BSI-"Konkretisierungen" veröffentlicht worden. Das aktuelle IDW-Dokument ist nicht öffentlich zugänglich, aber die BSI-Konkretisierungen entsprechen bis auf kleinere Anpassungen der IDW PH 9.860.2-Version von 2018.

Was wir nun als "Konkretisierungen der § 8a (1)-Anforderungen" sehen, sind also eigentlich Cloud-Security-Kriterien aus der Feder eines Vereins, der seine Expertise in Bilanzprüfungen hat. Das BSI dankt dem IDW und verweist auf den IDW PH 9.860.2 als weiterführende Information, der IDW seinerseits hebt hervor: "Wirksamkeitsprüfungen nach IDW PH 9.860.2 eignen sich aus der Sicht des BSI im besonderen Maße, um die geforderten Prüfungsnachweise gemäß § 8a Abs. 3 BSIG erbringen zu können."

Das neue BSI-/IDW-Dokument soll laut Begleittext "den prüfenden Stellen geeignete Kriterien für eine sachgerechte Prüfung der eingesetzten Sicherheitsvorkehrungen" vorstellen.
So ein Prüfleitfaden wäre in der Tat wünschenswert, um die § 8a (3)-Prüfungen vergleichbarer und transparenter zu machen.
Warum für dieses Vorhaben gerade ein Wirtschaftsprüferleitfaden und Sicherheitsanforderungen an die Cloud dem BSI als geeignete Grundlage scheinen, wird wohl ein Geheimnis des BSI bleiben.

Bis dahin rettet uns: Die "Konkretisierung der Anforderungen" ist nicht verbindlich.
Und es manifestiert sich einmal mehr: Der § 8a-(3)-Prüfer sei sorgsam gewählt. Während bislang der Großteil der Prüfer sich an der DIN ISO/IEC 27001 orientierten, können Sie in dem nun vorliegenden "Konkretisierungen der Anforderungen" nachlesen, was Sie erwartet, wenn Ihr Prüfer sonst Wirtschaftsprüfer ist.

5. Harmonisierung der IEC 62443: Bye bye, Foundational Requirements

Im letzten Briefing haben wir uns die Umsortierung der ISO/IEC 27002 angesehen, heute geht es um die Umstrukturierung - man muss eigentlich sagen: Harmonisierung - der Standardreihe IEC 62443.
Das ist eine große, wichtige Nachricht, daher holen wir ein wenig aus.

Es gibt in der Standardreihe ein paar Grundkonzepte, auf denen alles aufbaut - beschrieben im Teil -1-1. Eines dieser Grundkonzepte sind die sieben Foundational Requirements (FRs), in denen die Anforderungen kategorisiert sind:

1. Identification and authentication control
2. Use control
3. System integrity
4. Data confidentiality
5. Restricted data flow
6. Timely response to events
7. Resource availability

Seit einiger Zeit wird an einem neuen Teil (ISA 62443-2-2) gearbeitet, der schon viele Arbeitstitel hatte - der momentane ist "Security Program Rating". Der Teil verfolgt zwei grundlegende Ziele: Messbarkeit für den Security-Status zu schaffen und die Anforderungen der verschiedenen Teile der IEC 62443 zu harmonisieren.
Beides wird durch das "Security Program Rating" erreicht. Es ist eine Weiterentwicklung der bisherigen Protection Level, berücksichtigt die beiden Dimensionen der technischen und organisatorischen Umsetzung und kann außerdem statt eines einzelnen Wertes auch eine Vektorform annehmen, um verschiedene Ratings für verschiedene Kriterien abbilden zu können.

Bislang waren die sieben Kriterien des Vektors die obenstehenden Foundational Requirements. Im aktuellen CD (Committee Draft) des Teils -2-2 sind es die folgenden neun sogenannten Security Objectives:

1. Security Management
2. Security Life Cycle
3. Risk Management
4. Access Control
5. System Integrity
6. System Availability
7. Data Confidentiality
8. Asset Management
9. Incident Management

Langfristig sollen alle Teile der IEC 62443 gemäß der Security Objectives strukturiert sein oder zumindest ein Mapping zu ihnen bieten. Damit lösen die neuen Security Objectives de facto die Foundational Requirements ab und ermöglichen eine einheitliche Reifegradbestimmung über Anforderungen aller 62443-Standardteile hinweg.

Weil es ziemlich blöd wäre, so eine Harmonisierung zu beschließen und dann einen elementaren Standardteil noch nach einer anderen Struktur neu zu veröffentlichen, soll auch die fast fertige Edition 2 der IEC 62443-2-1 noch einmal überarbeitet werden, um den neuen Security Objectives zu entsprechen.
Das aktuelle -2-1-Dokument im CDV-Status ("Committee Draft for Vote" - die letzte Stufe, bei der noch technische Kommentare abgegeben werden können) hatten wir im Juni-HardHats-Briefing erst beleuchtet, mitsamt neuer Struktur in "Security Program Elements". Das ist nun zwar die mindestens dritte Umstrukturierung während der Erarbeitung der zweiten Edition der -2-1), aber das klingt schlimmer, als es ist, denn:

• Erstens sind die Security Program Elements, die in der schon fast fertigen Version der -2-1 strukturgebend waren, den Security Objectives sehr ähnlich, sodass es nun eine milde Überarbeitung werden dürfte
• Zweitens sollen die Requirements des aktuellen IEC 62443-2-1 CDV bestehen bleiben und nur "umgelabelt" werden.

Eine einheitliche Struktur über die gesamte IEC 62443 hinweg ist ein Meilenstein für die bessere Nutzerfreundlichkeit eines Standards, von dem große Teile der OT-Security-Community behaupten, er sei überkomplex und würde nie fertig.

6. Joel Langills Linkliste zu OT-Security

Joel Langill kennen Sie vielleicht als Co-Autor des Buchs "Industrial Network Security" (Leseempfehlung!). Ansonsten mögen Sie ihm unter dem Nickname "Scadahacker" begegnet sein - wenn nicht, lohnt es sich nun.
Er hat jüngst seine Linkliste zum Themenfeld OT-Security aktualisiert. Die Linkliste ist ein Feuerwerk an Referenzen, sortiert nach Vulnerabilities, Standards, Best Practices, Frameworks, Case Studies, Basics, Cheat Sheets, Hersteller-Manuals.... eine wahre Goldgrube.
Reinschauen können Sie hier:

7. Aktualisierter Marktüberblick über Security-Monitoring-Produkte

ICS Detection Tools sind das Produktfeld von Security Monitoring mit automatischer Anomalie-/Schwachstellen-/Bedrohungserkennung, spezialisiert auf OT-Umgebungen und -Protokolle. Die Tools unterscheiden sich in ihren Schwerpunkten; im Kern sammeln sie aber alle (zentral oder dezentral) Informationen über Assets mittels aktiver Abfragen oder passivem Zuhören und wollen mithilfe dieser Daten Security-Probleme erkennen: Schwachstellen, Anomalien in der Kommunikation oder Indikatoren für die Präsenz bestimmter Schadsoftware.

Da die Herausforderung beim Betrieb solcher Tools darin liegt, mit den Meldungen auch etwas anzufangen, bieten viele Hersteller Dienstleistungen, die die Behandlung der Meldungen direkt mit abdecken: als Managed Service, mittels Threat Intelligence oder Incident Response Teams.
Eine Nebenbemerkung, bevor wir in die Marktveränderungen einsteigen: Wer ein reines Inventarisierungswerkzeug sucht, wird mit dieser Art von Tools nicht immer glücklich. Eine Inventarisierungsfunktion bieten zwar die meisten dieser Werkzeuge als "Nebenprodukt", sie dient aber vor allem der Schwachstellenerkennung und ist nicht immer auch brauchbar für die echte Administration der Assets.

Aufgrund vieler neuer Unternehmen war der Markt der ICS Detection-Werkzeuge in den letzten Jahren unübersichtlich geworden.
Mittlerweile ist er durch einige Akquisitionen etwas aufgeräumt, die neueste wurde nach längerer Gerüchtephase am 22. Juni offiziell verkündet: Microsoft kauft CyberX.

Ähnliche Meldungen gab es einige in letzter Zeit:
Cisco hat Sentryo gekauft, Forescout hat SecurityMatters gekauft, Tenable hat Indegy gekauft.
Die verbleibenden großen Player sind die Tools von Claroty, Nozomi und Dragos.

Die komplette Marktübersicht finden Sie im Lesestoff in Dale Petersons Analyse:

8. Ripple-20-Schwachstellen in TCP/IP-Softwarebibliothek für OT und IoT

Es sind 19 Schwachstellen, die die israelische Security-Firma JSOF gefunden und als "Ripple 20" veröffentlicht hat. Der Name ist in Anlehnung an den "Ripple-Effect" gewählt, der die Auswirkungen eines kleinen Steinchens in einer glatten Wasseroberfläche beschreibt: Er verursacht sich weit ausbreitende konzentrische Wellen, die viel größer sind als das kleine Steinchen.
Ähnlich, so beschreibt JSOF auf der Firmenwebsite zu Ripple20, ist es mit den Auswirkungen der Ripple-20-Schwachstellen. Sie wurden in der TCP/IP-Bibliothek "Treck TCP/IP" bzw. "Kasago TCP/IP" der US-amerikanischen Firma Treck gefunden - einer relativ kleinen Softwarekomponente, die aber in vielen verschiedenen Produkten verwendet wird, vor allem in eingebetteten Systemen und Echtzeitbetriebssystemen (RTOS, Real-Time Operating Systems), die in OT und IoT Anwendung finden.

Weil die Lieferkette für Softwarebibliotheken kompliziert werden kann, steht für viele Hersteller die Bestätigung, ob sie betroffen sind oder nicht, noch aus.
Eine aktuelle Liste wird in diesem GitHub-Repository gepflegt - oder auch auf der offiziellen JSOF-Website zu Ripple20, die Sie im Lesestoff-Link finden.

Der Wired-Artikel zu Ripple 20 beleuchtet die Auswirkungen für die Softwareindustrie und endet mit dem Schluss, standardisierte Schwachstellenanalysen und Secure Coding Guidelines hätten diese Schwachstellenserie verhindern können.

9. Noch mehr Schwachstellen: Siemens Netzwerkkomponenten, SWARCO Verkehrssteuerungen

Zwei weitere Schwachstellenmeldungen haben wir auch im Gepäck.

Das US-amerikanische CERT hat sein ICS-Advisory zu Siemens-Produkten aktualisiert. Das "Update G" enthält zusätzlich die Schwachstelle CVE-2019-8460, die potenziell Denial-of-Service-Angriffe zulässt. Betroffen sind Siemens SIMATIC-NET-CP-Netzwerkkomponenten.
Es steht ein Patch zur Verfügung.

Das deutsche CERT@VDE (wir erinnern uns an das letzte Briefing: Das CERT darf nun als CNA offizielle CVE-Nummern vergeben) hat ein Security Advisory zur SWARCO-CPU LS4000 herausgegeben. Da die Schwachstelle CVE-2020-12493 Root-Zugang zu den Steuerungen erlaubt, die in Verkehrsleitsystemen verwendet werden, bekommt sie in der Kritikalitätsbewertung den CVSS-Höchstwert 10.
Der Lesestoff-Link enthält die Meldung von Security Week (auf Englisch).

Stay secure!
Sarah Fluchs