Ein Jahr Schutzhelme! Im Mai 2020 (erinnern Sie sich noch? Da dachten wir noch 2021 sind wir locker wieder im Büro und auf echten Konferenzen!) wurde das allererste HardHats-Briefing verschickt.

An Geburtstagen schmeißt man ja für gewöhnlich 'ne Runde. Tun wir natürlich auch: Wir haben ein HardHats-Archiv eingerichtet, in dem Sie stets alle bisherigen Ausgaben nachlesen können. Den Link finden Sie in jedem Briefing ganz unten und hier einmal als Extraservice.

Ich hatte ja Bedenken, dass uns irgendwann die Themen ausgehen. Sagen wir so: Mittlerweile habe ich eher Bedenken, dass Sie überhaupt bis unten kommen in unseren Endlosbriefings.
Und diese Geburtstagsausgabe ist dafür das Paradebeispiel, denn es war was los im April - wäre es auch schon gewesen, wenn dann nicht kurz vor Ende der Bundestag noch das IT-Sicherheitsgesetz 2.0 verabschiedet hätten. Also, meine Damen und Herren, Geburtstag oder nicht, wir haben eine volle Agenda. Fangen wir an.

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

1. IT-Sicherheitsgesetz 2.0 verabschiedet: Und plötzlich sind auch Zulieferer drin
2. IDEAS: Security in das Automation Engineering einpflanzen
3. B3S Verkehr bekommt ein Update
4. Ein Angeklagter und viel heiße Luft: ICS-Security-Vorfälle "revisited"
5. Wegweisend: ISA/IEC 62443-2-2 auf Deutsch erschienen
6. Warum wir Technik nicht vertrauen
7. Security für Sensoren und Aktoren
8. Drei Stunden Videomaterial zu Security im Energiesektor

1. IT-Sicherheitsgesetz verabschiedet: Und plötzlich sind auch Zulieferer drin

Mit dem IT-Sicherheitsgesetz ist es ja ein bisschen wie mit einem neuen Film, über den man so viele Rezensionen gelesen hat, dass der Film dann irgendwie schal ist: Wir haben wirklich viele Versionen durchgenudelt, am 23.04. ist nun eine davon (verlinkt im Lesestoff 1, es ist die Fassung, die am 21.04. vom Innenausschuss zur Abstimmung vorgelegt wurde) im Bundestag verabschiedet worden. Dafür war die große Koalition, die Opposition stimmte geschlossen dagegen.

Jmmerhin sprechen wir nun nicht mehr über ungelegte Eier, sondern können den Tatsachen ins Gesicht schauen. Erinnern wir uns, was da noch mal die großen Themen waren: Das BSI bekommt mehr Befugnisse, darf etwa Ports scannen. KRITIS-Betreiber müssen nun "Systeme zur Angriffserkennung" haben, eine absurd konkrete technische Anforderungen im sonst eher wolkigen "Stand-der-Technik"-Sprech. Es gibt "kritische Komponenten", die zertifiziert werden müssen. Es gibt neue KRITIS-Sektoren, etwa die Entsorgung. Wir haben auch eine ganz neue Vokabel gelernt, "Uniböfi" - das sind Unternehmen im besonderen öffentlichen Interesse, die gewissermaßen KRITIS-Anforderungen light erfüllen müssen. Eine gute Zusammenfassung der Neuerungen hat OpenKRITIS (Lesestoff 2).

Das alles kannten wir schon. Mein Kollege Peter Breidbach hat sich in einem LinkedIn-Artikel außerdem die Mühe gemacht, die Unterschiede der jetzt verabschiedeten IT-SiG-Fassung zur letzten bekannten aufzudröseln:

1. Zu den Unternehmen im besonderen öffentlichen Interesse („Uniböfi“) gehören nun auch die Zulieferer von Unternehmen, die nach ihrer Wertschöpfung zu den größten Unternehmen gehören, sofern sie wegen ihrer Alleinstellungsmerkmale von wesentlicher Bedeutung sind. (§ 2 Abs. 14 BSIG)
2. Das BSI hat bei der Bestimmung des „Stands der Technik“ nun auch bestehende Normen und Standards zu berücksichtigen und betroffene Wirtschaftsverbände mit einzubeziehen (§ 3 Nr. 20 BSIG)
3. Betreiber kritischer Infrastrukturen müssen den Nachweis über den Einsatz von Systemen zur Angriffserkennung nun erst 24 Monate nach Inkrafttreten des IT-SiG 2.0 erbringen und nicht wie in vorherigen Entwürfen nach 12 Monaten. (§ 8a Abs. 1a BSIG)
4. Die Anforderungen an Uniböfi sind nicht auf Kleinstunternehmen anzuwenden (§ 8d Abs. 1a BSIG)
5. Der Einsatz kritischer Komponenten ist nun immer dem BMI anzuzeigen und nicht wie in vorherigen Entwürfen, nur wenn es sich um zertifizierungspflichtige Komponenten handelt (§ 9b Abs. 1 BSIG)
6. Bei der Bewertung des BMI, ob eine kritische Komponente eingesetzt werden darf, werden nun zusätzliche konkrete Aspekte berücksichtigt (§ 9b Abs. 2 BSIG):
   • Kontrolle des Herstellers durch eine Regierung eines Drittlandes
   • Beteiligung des Herstellers an Aktivitäten, die Auswirkungen auf die öffentliche Ordnung oder Sicherheit hatten
   • Einsatz der Komponenten nicht im Einklang mit sicherheitspolitischen Zielen der BRD
7. Die für das IT-Sicherheitskennzeichen notwendige Herstellererklärung erhält ihre Anforderungen nun aus Normen, Standards oder branchenabgestimmten IT-Sicherheitsvorgaben, die dem BSI zur Eignungsfeststellung vorgelegt werden können. Das BSI regelt die Anforderungen nur noch selbst durch eine TR, sofern es keine Normen, Standards oder Branchenvorgaben zu einer Produktkategorie gibt. (§ 9c Abs. 3 BSIG)

Dass Zulieferer nun "Uniböfi" werden können, ist ohne Zweifel eine der dicksten Änderungen - und eine, die Betreiber gerne lesen werden (Hersteller wohl weniger). Ebenso wird Betreiber die längere Galgenfrist erfreuen, bevor Systeme zur Angriffserkennung implementiert sein müssen. Und die explizite Bindung sowohl des Stands der Technik als auch der Kriterien für Herstellererklärungen an existierende Normen und Standards birgt zumindest das Potenzial, den Wildwuchs der verschiedenen Anforderungskataloge etwas einzudämmen.

Nun heißt es: Nach dem Gesetz ist vor der Verordnung, denn mindestens zur Uniböfi-Definition und die Schwellwerte der neuen KRITIS-Sektoren steht noch eine aus. Hier können wir auch ein wenig über ungelegte Eier spekulieren: Die Entwurfsfassung für die neue KRITIS-Verordnung (BSI-KritisV) finden Sie im Lesestoff-Link 3. Dort gibt es auch eine Fassung mit gekennzeichneten Änderungen im Vergleich zur bisherigen KritisV.

In der Presse findet sich beim Schreiben dieses Briefings noch überraschend wenig zum IT-SiG 2.0, was aber auch an der Gleichzeitigkeit mit dem Inkrafttreten der Bundesnotbremse liegen könnte. Die Berichte, die es gibt, fühlen sich an wie "aus der Konserve": Sie tuten meist ins selbe Horn wie beim Berichten über die diversen Entwurfsstadien des IT-SiG 2.0. Aber vielleicht geht's der Presse ähnlich: Zu viele Rezensionen über den Film gesehen.

• Spiegel (mit Schwerpunkt auf Huawei und 5G)
• Heise (mit Schwerpunkt auf neue BSI-Befugnisse)
• Golem (mit Schwerpunkt auf die fehlende Berücksichtigung der Expertenmeinungen aus der Anhörung)

2. IDEAS: Security in das Automation Engineering einpflanzen

Vor mehr als anderthalb Jahren haben wir mit der Beantragung begonnen, nun ist es endlich gestartet: Unser vom Bundesministerium für Bildung und Forschung (BMBF) gefördertes Forschungsprojekt.
Gemeinsam mit Prof. Dr.-Ing. Rainer Drath und Emre Tastan von der Hochschule Pforzheim wollen wir Security endlich wirklich "by Design" in den Automation-Engineering-Prozess einpflanzen, und damit gleichzeitig Security Engineering in die Sprache von Automatisierungsingenieuren übersetzen. Das Problem ist: So eine automatisierte Anlage ist ein hochinterdisziplinäres Gebilde. Fragt man Automatisierer nach Ihrer Rolle im Gewusel der beteiligten Ingenieurgewerke, sagen sie, im Zweifel dürfen sie als allerletztes mitreden, wenn alle wichtigen Entscheidungen schon getroffen sind.... Nun, das kommt uns Security-Leuten bekannt vor, denn wenn Automatisierer die Letzten im Gewerke-Gewusel sind, sind wir die Allerletzten. Und dann hinkt Security-Engineering auch noch hinterher, wenn es um Systematik der Methoden und um Modellbildung geht. Oder könnten Sie Ihr Security-Problem verständlich auf ein Blatt Papier bringen (Sie erinnern sich vielleicht an diesen Blogpost, in dem ich die Frage schon einmal gestellt habe)?.

Im Detail ist das hier die Fragenliste, die IDEAS beantworten möchte:

1. Wie kann der Security-Engineering-Prozess frühestmöglich ("by Design") in den Automation-Engineering-Prozess integriert werden?
2. Wie sieht ein Informationsmodell für diesen "eingepflanzten" Security-Engineering-Prozess aus, das gemeinsam mit den anderen Gewerken genutzt werden kann?
3. Wie kann auf dieser Basis ein Security-Engineering-Werkzeug aussehen, das sich in die bestehenden Werkzeuge von Ingenieuren einfügt und sie effizient durch das Security Engineering führt?

IDEAS steht übrigens für "Integrated Data Models for the Engineering of Automation Security" - und jetzt wissen Sie auch, warum.
Das Projekt läuft bis Ende 2024 und wir freuen uns sehr darauf, was wir herausfinden und bauen. Und darauf, wie unsere Anwendungspartner, ein Betreiber (INEOS) und ein Hersteller (HIMA) die Ergebnisse so finden...

Im Lesestoff finden Sie den offiziellen Projektsteckbrief beim BMBF, der allerdings in Teilen der BMBF-Marketingabteilung zum Opfer gefallen ist - aber mindestens unser Projektlogo können Sie dort bewundern!

3. B3S Verkehr bekommt ein Update

Und nochmal KRITIS: Der branchenspezifische Sicherheitsstandard (B3S) für den Sektor kommunaler Straßenverkehr, auch bekannt als DIN VDE 0832-700, ist aktualisiert worden und befindet sich gerade beim BSI in der Eignungsprüfung.

Was sich ändern wird, kurz und knapp:

1. Büro-IT und Lieferanten müssen als Teil des Anwendungsbereichs mitbehandelt werden
2. Anforderungen an die Verfügbarkeit müssen bei der zuständigen Kommune ermittelt werden
3. Für zentrale und ortsveränderliche Signalanlagen muss ein Wartungs- und Backup-Plan erstellt werden
4. Komponenten müssen nachweisbar gehärtet werden (Sichere Konfiguration)
5. Anforderungen an sicherheitsrelevante Lieferanten und Dienstleister müssen vertraglich vereinbart werden
6. Ein Notfallplan bzw. –handbuch muss erstellt werden

4. Ein Angeklagter und viel heiße Luft: ICS-Security-Vorfälle "revisited"

Nein, wir widmen uns zur Abwechslung mal keinen neuen Vorfälle diesen Monat. Statdessen gibt es ein paar neue Anmerkungen zu alten Fällen:

Für den "Florida Water Hack", also den Angriff auf eine Trinkwasseranlage im US-amerikanischen Florida (siehe HardHats-Briefing aus dem März), gibt es nun tatsächlich einen Angeklagten. Das ist bei IT-Sicherheitsvorfällen eine Seltenheit. Wie in den USA üblich wird der Mann namentlich benannt, es handelt sich um einen 22-Jährigen aus dem US-Bundesstaat Kansas, der "bewusst und unauthorisiert" in das Leitsystem der Trinkwasseranlage eindrang und Werte veränderte.
Wie viel der Angeklagte tatsächlich über den zu steuernden Prozess wusste, geht aus der Pressemitteilung (Lesestoff-Link 1) nicht hervor, dafür aber die möglichen Strafen: Bis zu 20 Jahre Gefägnis und 250 000 $ Strafe für die Manipulation eines öffentlichen Wasserversorgungssystems, bis zu 5 Jahre Gefängnis und 250 000 $ für die fahrlässige Beschädigung eines geschützten Computers während unautorisierten Zugriffs.

Weniger Zählbares, aber viel Wirbel, brachten Neuigkeiten um die iranische Urananreicherungsanlage in Natanz. Wir erinnern uns: Die Anlage ist strategisch wichtig für das iranische Atomprogramm, und sie war zwischen 2007 und 2010 Ziel des Security-Angriffs "Stuxnet".
Die Urheber von Stuxnet wollten Zentrifugen sabotieren, und dasselbe Ziel scheinen Saboteure Anfang April verfolgt zu haben. Es gab eine Explosion und einen Stromausfall in der Urananreichungsanlage, und Zentrifugen wurden beschädigt.
Stuxnet wird dem israelischen Geheimdienst zugeschrieben (zusammen mit dem der USA und der Niederlande), und auch die jetzige Sabotageaktion soll angeblich auf das Konto der Israelis gehen, schreibt Kim Zetter, die Autorin des umfassendsten Buchs über Stuxnet, im Lesestoff-Link 2.
Bei so vielen Gemeinsamkeiten und dem üblichen Hype um Stuxnet kochten die Spekulationen hoch: War es ein Security-Angriff? Eher sieht es nach einem sehr gut geplanten, aber sehr physischen Angriff aus: Es wurde ein Gerät in die Anlage geschleust, das aus der Ferne eine Explosion auslösen konnte - und so geschickt platziert, dass es damit die Stromversorgung lahmlegte (Natanz hat sein eigenes Stromnetz). Merke: Nicht nur Security-Angriffe können weh tun.

5. Wegweisend: ISA/IEC 62443-2-2 nun auf Deutsch erschienen

Sie trägt den etwas sperrigen Titel "IT-Sicherheit für industrielle Automatisierungssysteme –
Teil 2-2: IACS-Sicherheitsprogramm-Einstufungen": Die deutsche Übersetzung der ISA/IEC 62443-2-2 ist nun erschienen. Im Übrigen auch als europäische Norm (EN), was bedeutet, das sie unverändert von nationalen Normungsgremien übernommen werden muss - und alle mit EN-Normen in Widerspruch stehenden nationalen Normen sind zurückzuziehen.

Die "two-dash-two", wie das erarbeitende Komittee ISA99 die Norm liebevoll nennt, ist ein Wegweiser für die gesamte Standardreihe ISA/IEC 62443. Sie legt nämlich nicht nur Einstufungen fest ("wie gut erfülle ich eine bestimmte Anforderung?"), sondern auch gleich die Kategorisierung der Anforderungen, und die soll nun über die gesamte Standardreihe harmonisiert werden.
Die unterschiedlichen, nicht immer gut zueinander passenden Anforderungskataloge in den verschiedenen Standardteilen waren ein häufiger Kritikpunkt an "der 62443", der nun hoffentlich für einige Zeit aus der Welt geräumt ist - wenn denn alle Teile an die neue Kategorisierung angepasst sind, was noch ein paar Jährchen dauern dürfte. Der erste "konforme" Teil wird wohl die ISA/IEC 62443-2-1 (das "ISMS für die Automatisierung"), denn seine Veröffentlichung wurde extra verschoben, um die neuen, harmonisierten Kategorien noch einbauen zu können.

Der nun erschienene Standard enthält also keine direkten Security-Anforderungen, ist aber elementar für das Verständnis der gesamten 62443-Reihe, weil er viele historisch gewachsene Strukturen aufräumt und begradigt.
Zwei Vokabeln können Sie schon einmal lernen: Ihnen werden zukünftig Sicherheitsziele begegnen, nach denen alle Anforderungen der 62443-Reihe kategorisiert sind, und deren Erreichung als "SPR" (Security Program Rating) bemessen wird. Das SPR bewertet, wie bislang die "Protection Levels" die Kombination aus technischer und organisatorischer Maßnahmenerfüllung.

Der Text ist zunächst als Normentwurf veröffentlicht - Einsprüche sind noch bis 9. Juni möglich. Die Entwurfsfassung ist jedoch bereits beim VDE-Verlag beziehbar (siehe Link).

6. Warum wir Technik nicht vertrauen

Ein kleiner Denkanstoß, der nicht direkt mit Security zu tun hat: In "Trust and Failure in Technology" macht sich Caro Williams-Pierce, eine Designering von Mathe-Lernspielen, sich Gedanken darüber, warum die vielen Schichten von Technik, die wir nicht durchschauen, so frustrierend sind (Lesestoff-Link).
Ihre These: Wenn sie ein Spiel designt und dort Misserfolgserlebnisse für den Nutzer einplant, dann nie ohne einen Hinweis darauf, warum er gescheitert ist. An der Technik, die täglich um uns herum ist (vor allem IT, wenn man ehrlich ist), scheitern wir als Nutzer ständig - meist ohne eine leise Ahnung, warum. Die Systeme sind zu komplex, und wir durchschauen die vielen Abhängigkeiten nicht mehr.

Tja, die blöden Nutzer, könnten wir aus unserer Techie-Perspektive jetzt sagen. Aber sind wir mal ehrlich: Steigen wir, die die Technik designen, eigentlich selbst durch unsere eigenen Kreationen noch durch? Verstehen wir, woher Fehler und Misserfolge kommen?
Und falls nein: Wenn wir schon die harmlosen, versehentlichen Misserfolgserlebnisse nicht verstehen - was bedeutet das für unsere Chancen, uns zielführend um Security, also um "absichtliche böswillige Misserfolgserlebnisse" kümmern müssen?

7. Security für Sensoren und Aktoren

Die Feldebene ist ein leidiges Thema in der Security. Oft ist sogar umstritten, ob die Geräte überhaupt in Security-Betrachtungen einbezogen werden sollten. Zumindest der populäre Scoping-Ansatz "alles, was eine IP-Adresse hat" schließt Sensoren und Aktoren oft aus, und der pragmatische Ansatz "alles, was im Assetregister vorkommt" meist sowieso.

Begeben wir uns also mal mitten ins schlechte Gewissen: Was kann man wirklich für Sensoren und Aktoren tun? Dale Peterson hat dem Thema eine Artikelserie gewidmet, den letzten Teil (mit Links zu den vorherigen Teilen) finden Sie im Lesestoff.
Das größte Problem mit Feldgeräten, so schreibt Dale, ist die fehlende Authentifizierung. Nehmen wir also an, Messwerte von Sensoren und Stellwerte von Aktoren können ohne großen Aufwand verändert werden und haben dann eine gute Chance, akzeptiert zu werden: Wie schlimm ist das? Und: Was kann man dagegen tun?

Der "was kann man dagegen tun"-Teil ist interessant.
Kurz: Bei Nicht-IP-basierten Feldgeräten so gut wie nichts, was die Kosten bei vergleichsweise geringem Risiko rechtfertigen würde (dazu gibt es in Teil 2 der Artikelserie auch einen Entscheidungsbaum).

Dales Hoffnung ist, dass langfristig die Sensoren und Aktoren Authentifizierung und Integritätsprüfungen inhärent leisten können (Voraussetzung: sie kommunizieren IP-basiert).
Bis dahin hat er drei sehr konkrete Tipps für jetzt schon IP-basierte Feldgeräte:

1. Signierte Firmware und Secure Boot: Hilft gegen korrumpierte Firmware-Uploads (es sei denn, die Signatur ist auch korrumpiert).
2. Nutzung von Admin-Accounts, falls Administration über das Netzwerk möglich ist.
3. Authentisierung von Aktor-Signalen. Das ist schon aufwendiger, da es meistens bedeutet, TLS-verschlüsselte Verbindungen zu verwenden - mit dem ganzen Rattenschwanz des Zertifikatsmanagements.

Und dann ist da noch Monitoring:
Eine elegante Lösung könnte sein, Sensor- und Aktorwerte mit Prozesskenntnissen zu validieren, also durch eine Art Anomalieerkennung für "übliche" Daten (process variable anomaly detection, PVAD). Das ginge zum Beispiel mit einem digitalen Zwilling, genutzt für die Simulation der echten Feldgeräte, der problematische Werte erkennen kann. Dagegen eher die Holzhammermethode (und zwar ein teurer Holzhammer!) ist das Aufbauen eines kompletten Monitoring-Netzwerks für die Feldebene, dass Werte der Feldgeräte mit denen im Leitsystem vergleichen kann.

8. Drei Stunden Videomaterial zu Security im Energiesektor

Diesen Monat gab es einen Workshop des Projekts EnergyShield, der sich um Security für den Energiesektor drehte. Der englischsprachige Workshop enthielt fünf Vorträge und zwei Diskussionspanels. Das Ganze fand - natürlich - virtuell statt, was einen entscheidenden Vorteil hat: Es gibt eine Aufzeichnung. Wenn Sie Interesse haben, können Sie also nun bei YouTube reinschauen (s. Link).

Im zweiten Panel zum Thema "Latest incidents targeting critical infrastructure and their impact on designing new technologies, business models and policies" durfte ich mitreden (ca. ab Stunde 02:07:00 im Video). Die Panel-Teilnehmer waren eine gute Mischung; ich habe viel aus der Diskussion mit Matthias Rohr des Automatisierungsherstellers PSI mitnehmen können, der das Thema Security-Zertifizierung aus Herstellersicht beleuchtet hat.

Auch interessant: Als ich gefragt wurde, ob Zulieferer als kritische Infrastrukturen definiert werden sollten, habe ich gesagt "ich verstehe die Frage nicht". Hintergrund: Sie werden dann kritisch, wenn sie einer kritischen Infrastruktur zuliefern, dann landen sie aber meist ohnehin als Lieferant im Scope ebendieser kritischen Infrastruktur.
Nun, wie wir am nun verabschiedeten IT-SiG 2.0 sehen, hat die Bundesregierung einen Mittelweg gefunden: Zulieferer sind kein KRITIS, aber "Unternehmen im besonderen öffentlichen Interesse". So schnell sind die eigenen Aussagen überholt...

Stay secure!
Sarah Fluchs