Liebe Schutzhelmfreunde, wir haben schon Oktober und sind damit im letzten Quartal 2021. Das ging flugs, oder?

Noch etwas ging flugs: Hier wird es in den nächsten Wochen etwas ruhiger werden, da ich im Mutterschutz einen Mini-Schutzhelmträger in der Welt willkommen heißen werde. Anfang 2022 geht's dann wie gewohnt weiter. 

Damit Ihnen in den kommenden Wochen dennoch nicht langweilig wird, haben wir dieses Mal allerdings noch eine prall gefüllte Liste mit Lesestoff "aus aller Welt" dabei. Die Texte sind manchmal lang, lohnen sich aber - und sind größtenteils zeitlos.

Passend zur Bundestagswahl beginnen wir mit der deutschen Cybersicherheitsstrategie, schauen dann auf "Zukunftstechnologien" (Cloud und KI) und auf die Zukunft älterer Technologien (HART und R&I-Fließbilder) und widmen uns zum Schluss in zwei Themen der Frage, wie man IT-Security eigentlich am besten organisiert (sollten wir uns da etwa was von Buchhaltern abschauen?).

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

1. Cybersicherheitsstrategie der (scheidenden) Bundesregierung für die kommenden 5 Jahre
2. Cloud und KI in der Industrie - geht das auch in sicher?
3. Wie man sich gegen Angriffe auf via HART-Protokoll schützt
4. Dumme und kluge R&I-Fließbilder oder warum wir Datenmodelle in der Industrie brauchen
5. Wer macht IT für Automatisierung? Und wer Security?
6. Wenn wir Häuser so bauen würden, wie wir IT bauen...
7. Das ist los in der Automation-Security-Community

1. Cybersicherheitsstrategie der (scheidenden) Bundesregierung für die kommenden 5 Jahre

Kurz vor der Bundestagswahl hat die scheidende Bundesregierung noch die Cybersicherheitsstratgie für die nächsten fünf Jahre verabschiedet (Lesestoff-Link siehe unten). Das stand 2021 noch an, denn das letzte Strategiepapier, das ebenfalls fünf Jahre abdeckte, erschien 2016. Verantwortlich für die Erarbeitung war das Innenministerium unter Horst Seehofer.

Die Strategie beinhaltet Leitlinien und Handlungsfelder. Picken wir uns die Details heraus, die zumindest potenziell eine Relevanz für Automation Security haben:

• Europäisch einheitliche Sicherheitsanforderungen / Cybersicherheitszertifizierungen: EU-weit soll es einheitliche und verbindliche IT-SIcherheitsanforderungen geben. Das ist natürlich auch eine Referenz auf den europäischen Cybersecurity Act, der einheitliche Zertifizierungsschemata einführen soll. Als maßgebliche Behörde für die Erarbeitung der Zertifizierungsschemata und auch als Zertifizierungsstelle wird das BSI benannt.
  Diese angestrebte EU-weite Einheitlichkeit ist übrigens auch der Grund, warum das nationale IT-Sicherheitskennzeichen im IT-SiG 2.0 nur ein freiwilliges ist. Das Papier lässt dazu allerdings verlauten: "Die Bundesregierung hat das nationale, freiwillige IT-Sicherheitskennzeichen als möglichen Ansatz in die Diskussion eingebracht."
  Die Verbindlichkeit lässt sowohl Betreiber als auch Hersteller von Automatisierungskomponenten hoffen: Betreiber, weil sie dann endlich einen Pack-an hätten, um ihre Lieferanten auf Security-Anforderungen zu verpflichten, Hersteller, weil Betreiber dann hoffentlich auch für Security zahlen (müssen), statt sie nur einzufordern - und beide Gruppen, weil dann endlich mal eine Basis dafür da wäre, um missverständnisfrei über Securityanforderungen zu sprechen.
  Das Strategiepapier wird hier sehr konkret; es enthält nämlich eine Liste von Zertifizierungsschemata und zu zertifizierenden Technologien, die seitens Deutschland auch international vorangetrieben werden sollen: Common Criteria (EUCC), Cloud Services (EUCS), IoT, 5G, die beschleunigte Sicherheitszertifizierung sowie der IT-Grundschutz.
• Kooperative Kommunikationsplattform (Information Sharing Portal) für Cyberangriffe: Eine solche staatlich organisierte Informationsplattform wie etwa das ICS-CERT in den USA gibt es in Deutschland bislang nicht.
  Unternehmen, die Angriffe erlebt haben, sind mit dem Teilen dieser Informationen in der Regel eher zurückhaltend. Das ist verständlich: Es gibt Datenschutz, Firmengeheimnisse - und nicht zuletzt sieht man in der Presse als Angriffsopfer nie gut aus. Wer als kritische Infrastruktur (KRITIS) gilt, hat eine Meldepflicht - alle anderen melden, wenn überhaupt, freiwillig.
  Aber je mehr Informationen über Angriffe geteilt werden, desto besser können natürlich andere Firmen gewarnt und alle gemeinsam besser auf zukünftige Angriffe vorbereitet werden. Ein Unternehmen allein kann unmöglich genug Informationen über die gesamt Bedrohungslage sammeln. Diese Informationen lassen sich als "Threat Intelligence" teuer einkaufen, wenn man sich das leisten will und kann - eine offizielle und gemeinnützige Stelle ist eine willkommene Alternative.
• Unternehmen (gemeint: vor allem KMU) in Deutschland schützen: Hinter diesem Ziel verbirgt sich ein Sammelsurium von Angeboten, etwa Förderprogramme, Kontaktstellen und Angebote für KMU von Behörden, Zusammenschlüsse wie die Allianz für Cybersicherheit. Nichts bahnbrechend Neues.
• Die deutsche digitale Wirtschaft stärken: Dabei geht es um digitale Souveränität - in den meisten Fällen bedeutet das, sich nicht von US- oder asiatischen Technologiekonzernen abhängig zu machen, was natürlich zumindest indirekt auch Security-Relevanz hat.
  Aus Automatisierungssicht sind hier mindestens fünf genannte Bereiche interessant, in denen die Bundesregierung die Entwicklung eigener, d.h. deutscher Technologien (mit eigenen Sicherheitsanforderungen) fördern möchte: In der Automobilbranche die Datenübertragung in (autonomen) Autos, in der Energiebranche Smart Metering und Smart Grid, in der Städteplanung der Einsatz von IoT-Komponenten in sogenannten Smart Cities, in der Industrie "Vertrauensinfrastrukturen" für Industrie 4.0 und für das Gesundheits- und Rettungswesen allgemein die Definition von IT-Sicherheitsanforderungen.
• Einen einheitlichen europäischen Regulierungsrahmen für Unternehmen schaffen: IT-Sicherheitsgesetz, Störfallverordnung, Maschinenrichtlinie: Nur drei Beispiele für Regularien, die alle haben Ursprünge in EU-Richtlinien haben und alle (auch) Security-Anforderungen beinahlten. Klar, dass Unternehmen da stöhnen. Und ein lobenswertes Ziel, diese Last zu erleichtern.
• Schutz kritischer Infrastrukturen weiter verbessern: Das dürfte Ihnen nicht neu sein.
  Es stehen drei Schwerpunktziele im Papier, nämlich den "Rahmen zur Durchführung von Vor-Ort-Prüfungen" zu erweitern, den Stand der Technik für weitere KRITIS-Branchen zu konkretisieren (lies: mehr branchenspezifische Sicherheitsstandards (B3S) und - siehe oben - einen nationalen Informationsaustausch zu Cyberangriffen zu etablieren.

Darüber hinaus beinhaltet die Strategie natürlich auch Ziele zur Sicherheitspolitik, lies: Wie gehen wir mit Cyberangriffen aus dem Ausland um und was dürfen deutsche Sicherheitsbehörden? Selbst aktiv angreifen, mit Angriffen aktiv verteidigen ("Hackback") oder nur passiv verteidigen?
Falls Sie etwas zur Entscheidungshistorie unter anderem zum ewigen Streitpunkt "Hackback oder nicht" lesen wollen: Dazu hat heise einen kurzen Artikel.

2. Cloud und KI in der Industrie - geht das auch in sicher?

Idealerweise jammert Security nicht lange über neue Technologien (und versucht erst recht nicht, sie zu verhindern), sondern passt ihre Konzepte an und hält Schritt.
Zwei heiße Kandidaten für diese berühmt-berüchtigten neuen Technologien: Cloud und künstliche Intelligenz (KI).

Dazu haben wir heute drei Lesetipps:

1. Das unscheinbare Wort "Cloud" kommt oft mit einem Rattenschwanz bis dato unbekannter Technologien. Wie zur Hölle sichert man eigentlich Kubernetes und Container ab?
   Zu beiden gibt es nun IT-Grundschutz-Bausteine. Sie sind noch im Community-Draft-Status (Lesestoff 1+2).
2. Beim Einsatz von KI in der Industrie steht man vor dem Problem, nicht nachvollziehen zu können, was die "Black Box" KI denn genau tut. Aus Security-Sicht natürlich ein Albtraum. In einem kurzen neuen Paper hat Leonie Beinig von der Stiftung Neue Verantwortung zusammengefasst, ob und wie sogenannte "Assurance Cases" dieses Problem lösen können (Lesestoff 3).
3. Wäre ja zu schön, wenn wir hier nur über Lösungen reden - zwei Problemchen habe ich Ihnen auch mitgebracht: In Microsofts Cloud-Lösung Azure wurden in den letzten Wochen zwei größere Sicherheitslücken gefunden (Lesestoff 4+5).
   Die erste heißt "Chaos DB", betrifft die zentrale Azure-Datenbank "Cosmos" und wurde als "worst cloud vulnerability you can imagine" beschrieben - denn sie ermöglichte beim Ausnutzen Externen kompletten Lese- und Schreibzugriff auf die Datenbankinhalte.
   Die zweite trägt den Titel "Azurescape", betrifft den Azure Container-Service ACI und ist deswegen beunruhigend, weil sie einen Zugriff auf die Containerinhalte anderer Nutzer ermöglicht. Crashkurs Container: Die sind dafür da, um genau das zu verhindern.

3. Wie man sich gegen Angriffe via HART-Protokoll schützt

Im April hat das LOGIIC-Projekt (Linking the Oil and Gas Industry to Improve Cybersecurity) seinen Bericht zu Security-Problemen und Lösungen für Safety-Systeme veröffentlicht (Lesestoff 1).

Ein Ergebnis des Berichts sind die möglichen Angriffsvektoren auf das (nicht nur für Safety-Systeme) weit verbreitete HART-Protokoll, das die Nutzung existierender 4-20mA-Verkabelung für die Übertragung zusätzlicher Informationen ermöglicht.

HART bietet, wie die meisten feldnahen Protokolle, weder Authentifizierung noch Verschlüsselung an. Es ist daher grundsätzlich möglich, HART-Befehle mittels manipulierter IP-Pakete oder über eine serielle Verbindung einzuschleusen.
Wir reden hier über die Kommunikation zwischen Steuerungen und Feldgeräten - man muss sich also schon gut überlegen, welche Befehle man dort einschleust.
Zwei Vorschläge des LOGIIC-Reports: Die Feldgeräte in den "fixed current"-Modus oder den "loop current"-Modus setzen. Beides führt dazu, dass Sensoren nicht mehr die eigentlich gemessenen Werte anzeigen, sondern willkürlich festgesetzte Werte - einen vom Nutzer/Angreifer definierten Wert für "fixed current" oder einfach 4mA für "loop current". Das sind sinnvolle Funktionen, wenn man Sensoren kalibrieren möchte oder nicht analog, sondern binär verwenden möchte - nämlich so, dass nur "0" oder "1" (d.h. 4 oder 20mA) angezeigt werden.

Leider sind es auch sinnvolle - und sehr effiziente - Funktionen, wenn ein Angreifer Sensorwerte mittels des HART-Protokolls manipulieren möchte.

Reid Wightman hat in seinem detaillierten Blogpost (Lesestoff 2) beschrieben, wie man eine Steuerung dazu bringen kann, so einen Angriff erkennen. Long story short: Der Knackpunkt ist eine I/O-Karte in der Steuerung, die HART-Befehle versteht und nicht nur die resultierenden Sensorwerte anzeigt. So kann die Steuerung dann "sehen", ob der empfangene Sensorwert ein gemessener oder ein willkürlich gesetzter ist.

Randnotiz: Reid Wightman ist Mitstreiter in unserem Top 20 Secure PLC Coding Practices-Projekt - die Chancen stehen also gut, dass seine Erkenntnisse zur HART-Absicherung sich dort in einer der zukünftigen Versionen wiederfinden...

4. Dumme und kluge R&I-Fließbilder oder warum wir Datenmodelle in der Industrie brauchen

Datenmodelle sind ja zugegebenermaßen ein staubtrockenes Thema. Umso lieber teile ich daher einen kleinen, aber feinen Text von Thomas Tauchnitz mit Ihnen, der am Beispiel "dummer" R&I-Fließbilder anschaulich erklärt, warum wir Datenmodelle so dringend brauchen, wenn wir Digitalisierung wollen (Lesestoff 1).

Wenn Ihnen beim Lesen Parallelen zu Ihrem Wunsch auffallen, Ihr Assetregister endlich in einer zentralen Datenbank unterzubringen statt in leidigen Excel-Tabellen oder verstreuten Tools, haben Sie natürlich recht damit.

Aber Achtung: Bauen Sie mit Ihrer aus Ihrer Sicht "zentralen" Datenbank kein Silo, dass nur für Ihre Abteilung, Ihr Gewerk oder Ihre Domäne "zentral" ist. Das R&I-Beispiel zeigt: Im Rahmen von Industrie 4.0 basteln eigentlich alle Gewerke daran, ihre Daten in "zentrale" Datenbanken zu bekommen, denn das ist das Fundament für Industrie 4.0. Wenn hinterher drei "zentrale" Assetregister bestehen, weil die Secuirty, die IT und die Automatisierung die gleichen hehren Ziele hatten, stehen Sie schon bald wieder vor der Aufgabe der Datenbankvereinheitlichung.

Also: Wenn schon "zentral", dann richtig, also "zentral" für alle Abteilungen und Gewerke nutzbar. Und jetzt zurück zum Staubtrockenen: Damit man sich dafür nicht mühsam zwischen drei Abteilungen (und dann noch mit Lieferanten) auf ein gemeinsames Datenmodell für die "zentral-zentrale Datenbank" einigen muss, gibt es nutzbare Konventionen.
Deswegen reden gerade auch alle über die Verwaltungsschale ("Asset Adminstration Shell") als Industrie-4.0-Enabler - denn die ist genau so eine Konvention.
Eine andere ist AutomationML. Die Modellierungssprache ist gerade 15 Jahre alt geworden - ein kurzes Erklärvideo zum Geburtstag finden Sie im Videolink.

5. Wer macht IT für die Automatisierung? Und wer Security?

Automatisierer sind meistens keine IT- und Netzwerkprofis. Es war meist schlicht nicht Teil ihrer Ausbildung und sie haben auch genug andere Themen, in denen sie Profis sein müssen.

Aber sollte das eigentlich so bleiben? Finden wir uns damit ab, dass die IT für die Automatisierung jemand anders macht? Wenn ja: Wer?

Und wenn das so ist - wer ist dann eigentlich für die Security des Ganzen zuständig?

Fragen über Fragen. Eng verwandten Themen gehen wir gerade auch in unserem BMBF-Projekt IDEAS gemeinsam mit unseren Anwendungspartnern INEOS und HIMA auf den Grund, deswegen hatte ein Blogpost von Dale Peterson aus dem September sofort meine Aufmerksamkeit (s. Lesestoff 1).
Und nicht nur meine: Mindestens so spannend wie der Blogpost ist die Diskussion, die dazu bei LinkedIn entstanden ist (siehe Lesestoff 2).

Es wäre spannend zu hören, wie das eigentlich bei Ihnen ist - und wie es wäre, wenn Sie einen Wunsch frei hätten?

Randnotiz:
Das Wort "OT" haben ich übrigens in all diesen Fragen vermieden, denn der Begriff ist bei den Antworten auf die obenstehenden Fragen schon Teil der Kontroverse.
Es scheiden sich die Geister, ob "OT" eigentlich die eigentlich Automatisierungskomponenten mit einschließt oder nur die "IT in der Automatisierung". Ist der Sensor OT? Oder nur, wenn er eine IP-Adresse hat? Oder sind es nur Netzwerke und AD-Controller, die für Automatisierungssysteme genutzt werden? Oder gilt einfach "it doesn't matter if it's OT or IT - in the end, it's all T"?

6. Wenn wir Häuser so bauen würden, wie wir IT bauen...

...würden Sie sich dann noch mit gutem Gefühl unter ein Dach begeben?

An Systematik fehlt es oft in der IT. Zynisch könnte man sagen: Zum Glück, sonst hätten wir in der Security nur halb so viel zu tun.
Wenn wir anfangen, Security Engineering einzuführen, heißt das oft erst einmal: Systematik und Dokumentation schaffen für Themenfelder, die Security höchstens am Rande berühren. IT-Administration, Asset und Change Management sind da ganz heiße Kandidaten.

Eine ähnliche wie die obenstehende Hausmetapher hat Phil Venables mal durchexerziert in seinem lesenswerten Text "If Accounting were like Cybersecurity". Manchmal hilft ja der Blick eines Experten aus einer ganz anderen Disziplin, um die Schrullen, mit denen wir uns in der Security schon lange arrangiert haben, aufzudecken... "Accountants" sind übrigend Buchhalter, oder aber auch diejenigen, die die Buchhaltung prüfen, Wirtschafts- oder Rechnungsprüfer zum Beispiel.

Der Text ist nicht ganz ernst gemeint, aber zum Schmunzeln und als Denkanstoß allemal geeignet - vor allem, wenn Sie sich in Ihrem Alltag (auch) mit Security-Managementberichten und Security-Organisationen befassen dürfen.
Beispiele gefällig? Ich zitiere ein paar, den ganzen Text finden Sie im Lesestoff.

If accounting were like cybersecurity (and accountants were like cybersecurity experts):

• Every year 10,000’s of accountants wearing shorts and t-shirts gather in Las Vegas and come up with ways to defraud companies and misrepresent financial statements to auditors while manipulating their bar bills to charge things to other rooms.
• What’s an oversight body? Accountants can do what they want, decide what standards to promote, form multiple different associations to set minimum standards and methods while claiming each one’s perspective is the right one.
• There is constant debate over whether Boards need to have Board members with some familiarity with finance, let alone financial controls.
• There’s a regular debate about how the whole accounting situation could be improved if only the Chief Accounting Officer could report to the CEO.
• No one can agree what the essential metrics are that need to be regularly reported to the public. Nor can people agree what is a significant enough event that would cause a regulatory or other public disclosure filing. There’s a whole industry of legal opinion and advice on this topic.

7. Das ist los in der Automation-Security-Community

Zu guter Letzt kommt hier eine kleine Zusammenfassung dessen, was im September hinsichtlich Automation Security so los war (und man jetzt nachlesen kann) und was demnächst kommt:

• Das ICSJWG Fall meeting hat virtuell Ende September stattgefunden. Alle Vorträge können Sie hier kostenlos anschauen.
• Bosch CyberCompare hat mir Fragen zum Thema Automation Security gestellt - inklusive einiger härterer Nüsse. Das Interview mit dem Titel "Cybersecurity muss von innen kommen" können Sie hier nachlesen.
• Die ISA Cybersecurity Standards Implementation Conference (CSIC) findet am 19. Oktober statt. Ich bin beim Supply Chain Risk Panel mit an Bord. Die Registrierung ist für Early Birds kostenlos.
• Die Agenda für die S4x22, eine der wichtigsten ICS Security Konferenzen weltweit, ist seit dem 1. Oktober online.
• Wenn Sie aus der Wasserbranche kommen, ist für Sie vielleicht die 1. Digital Water Conference spannend. Sie findet virtuell am 20. Oktober statt.
• Bei den Top 20 Secure PLC Coding Practices geht es vorwärts. Unser Fokus liegt momentan darauf, die Practices möglichst niedrigschwellig möglichst vielen Ingenieuren bekannt zu machen (Sie haben eine Idee, wie das geht? Gern melden!).
  Es wird bei der S4x22 ein Training geben, ein erstes Einführungsvideo für zwei Practices sind online, und Übersetzungen in etwa zehn verschiedene Sprachen sind in Arbeit (auch Deutsch) - Arabisch und Chinesisch sind sogar schon auf der Website.
  Auch gibt es neue Podcasts und einige geplante Vorträge zu den Top 20, international, aber auch in regionalen Anwendergruppen oder Ingenieurvereinigungen. Alle Neuigkeiten wie immer auf der Projekt-Website.
  Übrigens dürfen Sie sich doppelt gern melden, wenn Sie Hersteller sind. Von denen haben wir nämlich noch viel zu wenig Feedback zu den Secure Coding Practices, dabei sind sie diejenigen, die am allerwichtigsten sind, um die Top 20 in ihre Bibliotheken aufzunehmen (und ihren Kunden zu erzählen, dass sie das tun!).

Stay secure!
Sarah Fluchs