Willkommen im September! Das Sommerloch, das es diesen Sommer eigentlich gar nicht gab, neigt sich dem Ende zu. Trotzdem gab es im August ausnahmsweise nicht das eine große, bestimmende Thema in der OT-Security-Welt - auch mal ganz schön.

Wir haben also Zeit, uns ein paar längere Texte anzuschauen, die es sonst nicht alle in die Themenliste geschafft hätten: Ein langes Paper zur Auswirkung von Security-Versicherungen auf die Incident-Reponse-Versorgung, ein Video zu LoRaWAN, eine Erklärung, wie man Bitlocker-Verschlüsselung umgehen kann, und zwei Überblicks-Analysen zu OT-Exploits und OT-Security-Tools.

Wir beginnen aber mit einem Blick auf die Regulierung kritischer Infrastrukturen. Erst in Deutschland, wo die KRITIS-Verordnung im August beschlossen wurde, dann in die USA, wo die Biden-Regierung den Colonial-Pipeline-Vorfall genutzt hat, um erste Pflöcke für ihre zukünftige OT-Security-Politik zu setzen. Wer weiß, vielleicht schwappt davon etwas über den großen Teich? Das erste Mal wäre es jedenfalls nicht.

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

1. Neue BSI-KritisV verabschiedet
2. Bidens ICS-Security-Initiative: Konkretere und einheitlichere Maßnahmen für kritische Infrastrukturen in den USA
3. Führen Security-Versicherungen zu einem verbesserten Incident-Response-Angebot?
4. Wofür eignet sich LoRaWAN - und wofür nicht?
5. Wie man Bitlocker-Festplattenverschlüsselung knackt
6. Zahlen und Fakten zu 10 Jahren öffentlicher OT-Exploits
7. Forrester-Überblicksstudie zu OT-Security-Tools
8. Termine im September

1. Neue BSI-KritisV verabschiedet

Es gibt mal wieder ein paar kleine Neuigkeiten zum IT-Sicherheitsgesetz 2.0. Sie erinnern sich: Das IT-Sicherheitsgesetz ist am 28.05.2021 in Kraft getreteten - und im Juni-Schutzhelmbriefing hatten wir uns die Änderungen angeschaut und festgestellt, dass einige ungelegte Eier doch noch übrig bleiben - weil Details erst in Verordnungen geregelt werden.

Im April 2021 gab es dann einen Entwurf für die aktualisierte BSI-KritisV, die Anlagentypen und Schwellwerte für kritische Infrastrukturen regelt. Dieser ist nun (am 18. August) beschlossen worden und wird am 1. Januar 2022 in Kraft treten.

Was sich ändert, ist je KRITIS-Sektor unterschiedlich.
Für die meisten Sektoren wurden nur Anlagenkategorien oder Bemessungskriterien genauer definiert - oft äußert sich das in einem Einbezug übergeordneter oder koordinierender Systeme, die bislang nicht explizit als kritische Infrastruktur galten.
Die flächendeckende Schwellwertsenkung, obwohl oft angekündigt, scheint auszubleiben: Nur in den Sektoren Stromversorgung und IT und Telekom sollen Schwellwerte gesenkt werden, ab denen Anlagen als kritische Infrastrukturen gelten.

Eine kleine Übersicht hat unser Peter Breidbach ausgearbeitet:

• Stromversorgung: Hier werden die Schwellwerte für Erzeugungsanlagen und Systeme für den Stromhandel gesenkt. Eine Einordnung gibt's beim BDEW.
• Gasversorgung: Hier werden zusätzliche Anlagenkategorien hinzukommen, zum Beispiel Gasgrenzübergabestellen, Gasspeicher und Gashandelssysteme.
• Kraftstoff- und Heizölversorgung: Hier werden Anlagenkategorien für die zentrale standortübergreifende und kommerzielle Steuerung sowie für den Mineralölhandel hinzukommen, zudem wurden für einige existierende Anlagenkategorien die Art der Schwellwertbemessung verändert. Zum Beispiel hat nun der erzeugte oder verteilte Flugkraftstoff eigene Bemessungsgrenzen.
• Wasserversorgung und -entsorgung: Auch im Sektor Wasser wird die Steuerung und Überwachung eine eigene Anlagenkategorie bekommen (umfasst die bereits in der letzten Verordnung existierende Leitzentrale), und die Gewinnungs- und Aufbereitungsanlagen heißen nun "Wasserwerke".
• Lebensmittelherstellung und -behandlung: Auch hier werden sich primär Begrifflichkeiten verändern. Hier ein System mehr, dort die Klarstellung, dass alkoholoische Getränke über 1,2 Volumenprozent nicht als Lebensmittel zählen - und wie überall anders werden sollen Anlagen zur Überwachung explizit mit aufgenommen.
• IT und Telekom: Hier sind Schwellwertsenkungen vorgesehen, und zwar für die Top-Level-Domain-Registries, Rechenzentren, sowie Serverfarmen.
• Gesundheit: Als neue Anlagenkategorie kommen Blut- und Plasmaspendensteuerungssysteme sowie Laborinformationsverbünde hinzu.
• Luftfahrt: Als neue Anlagenkategorien kommen Verkehrszentralen einer Fluggesellschaft sowie Flughafenleitungsorgane hinzu.
• Schienenverkehr: Als neue Anlagenkategorien kommen Hafenleitungsorgane, Anlagen für den übergreifenden Hafenbetrieb, sowie Umschlaganlagen in See- und Binnenhäfen hinzu.
• Straßenverkehr: Als neue Anlagenkategorie kommen intelligente Verkehrssysteme hinzu.
• Logistik: Die Bemessungskriterien für die Schwellwerte werden redefiniert - und als ganz neues Kriterium wird die Anzahl der Sendungen pro Jahr hinzukommen.

Die nähere Definition des KRITIS-Sektors Entsorgung und der Unternehmen im besonderen öffentlichen Interesse fehlt im aktuellen Entwurf der BSI-KritisV noch.

Alle Details der nun beschlossenen Verordnung können Sie im Originalentwurf aus dem April nachlesen (Lesestoff 1).
Da der Entwurf eine Änderungsverordnung ist und damit etwas mühsam zu lesen ("nach Buchstabe 1c wird folgender Satz eingefügt"), hat intrapol.org auch eine angenehmer lesbare (inoffizielle) Fassung bereitgestellt - die finden Sie in Lesestoff-Link 2.

Nebenbemerkung für den Sektor Verkehr: Die BSI-Eignungsfeststellung der zweiten Version des branchenspezifischen Sicherheitsstandards (B3S) - auch bekannt als DIN VDE V 0832-700 - war erfolgreich. Der neue B3S wird also bald erscheinen.

2. Joe Bidens ICS-Security-Initiative: Konkretere und einheitlichere Maßnahmen für kritische Infrastrukturen in den USA

Blick über den großen Teich: Auch dort gibt es Neuigkeiten für die Security-Regulierung von kritischen Infrastrukturen. Für uns ist das momentan nur am Rande relevant, aber oft schwappen ja KRITIS-Vorgaben aus den USA irgendwann in modifizierter Form zu uns hinüber. Daher schauen wir kurz in die Staaten:

Die Biden-Regierung hat ein National Security Memorandum veröffentlicht (Lesestoff 1), und - weniger verklausuliert und daher reicher an Hinweisen - auch ein Transkript der zugehörigen Pressekonferenz (Lesestoff 2).

Das Memorandum erklärt vor allem, dass Präsident Joe Biden eine "Industrial Control System Cybersecurity Initiative" ins Leben ruft. Das ist eine Initiative, in der Regierung und die "Critical Infrastructure Community" freiwillig zusammenarbeiten, um die Installation von Lösungen für "threat visibility, indicators, detections, and warnings" voranzubringen.

Die Regierung begründet das damit, dass diese Technologien den Colonial-Pipeline-Vorfall (siehe Schutzhelmbriefing aus dem Juni) verhindert hätten.

Das klingt danach, als hätten bestimmte Herstellergruppen sehr gute Lobbyarbeit geleistet - und es reflektiert die hier schon oft beleuchtete Tendenz der USA, OT-Security vor durch Angriffserkennungslösungen zu behandeln.
Mindestens das ist eine Tendenz, die bei uns schon angekommen ist - siehe die Anforderung zur Installation von "Systeme zur Angriffserkennung" im deutschen IT-Sicherheitsgesetz 2.0.

Insgesamt finden sich in der Ankündigung Hinweise auf spezifischere Vorgaben von Security-Lösungen und deren Vereinheitlichung, denn, Zitat: "So essentially today, you know, there’s no strategic, coordinated requirement for the cybersecurity of critical infrastructure. To the extent, as I noted, there are mandatory cybersecurity requirements. They’re either sector specific — finance and chemical; they’re mandated under state or local law, like electricity ones; or they’re limited and piecemeal."

Ein Flickenteppich an sektorspezifischen Vorgaben: Diese Beobachtung dürften viele deutsche Stadtwerke teilen, die für ihren Wasser- und Stromsektor völlig unterschiedliche Vorgaben haben.
Ebenso kennen wir in Deutschland das Problem der etwas weichen Definition des "Stands der Technik", die uns viele verschiedene branchenspezifische Sicherheitsstandards (B3S) beschert hat, um den Stand der Technik konkreter zu definiere.

Man darf also gespannt sein, wie "konkret und einheitlich" die US-Vorgaben werden - und wie viel davon sich deutsche Gesetzgeber abschauen.
Aufgrund des Colonial-Vorfalls im Fokus sind dabei momentan die Pipeline-Betreiber - für sie gibt es bereits eine eigene Security-Direktive, die konkrete Maßnahmen beinhaltet; ebenso für den Sektor Energie.
In der "Industrial Control Systems Security Initiative" des Präsidenten sind nun als weitere Fokus-Sektoren für dieses Jahr Wasser und Chemie explizit benannt.

3. Führen Security-Versicherungen zu einem verbesserten Incident-Response-Angebot?

Die Annahme basiert auf einer Analogie:
In London hatte im 19. Jahrhundert das Aufkommen von Brandversicherungen dazu geführt, dass sich Feuerwehren gründeten, die bald von der öffentlichen Hand übernommen wurden. Die Feuerwehren nutzten schließlich beiden Seiten: Den Versicherten, die weniger Brandschäden hatten, und den Versicherungen, die für weniger Brandschäden aufkommen mussten.
Oder, in Kurzform: Die Versicherungen haben zu einer Verbesserung der gesellschaftlichen Sicherheit geführt.

Dasselbe, so die Hoffnung, könnte ja auch für IT-Sicherheits-Versicherungen gelten: Sie verbessern langfristig das Angebot einer "Cyber-Feuerwehr", also von Incident-Response-Teams, die Versicherten im Falle eines Vorfalls helfen, Schäden zu begrenzen.
Ansätze dafür gibt es bereits: Versicherer arbeiten durchaus mit privaten Incident-Response-Dienstleistern zusammen, die ausrücken (und von der Versicherung bezahlt werden), wenn ein versicherter Kunde einen Security-Vorfall hat.
Die Annahme daher: Security-Versicherungen erleichtern - die Studie sagt: demokratisieren - den Zugang zu sonst teuren Incident-Response-Dienstleistungen.

Ob das stimmt, haben Daniel Woods und Rainer Böhme nun in einer Studie untersucht (35 Seiten starkes Original-Paper siehe Lesestoff 1, kürzere Zusammenfassung siehe Lesestoff 2).

Erste Beobachtung: Die meisten Versicherungen greifen auf einen kleinen, immer gleichen Pool von Incident-Response-Dienstleistern zurück. Warum genau diese? Häufig ist die Antwort: Weil die es besonders billig machen - zu Lasten der Qualität. Das würde bedeuten, dass der Zugang zu Incident-Response-Dienstleistungen vereinfacht wird - aber zu Lasten der Qualität.

Eine zweite Beobachtung ist wichtig. Incident Reponse im Security-Bereich unterscheidet sich in einem Aspekt wesentlich von der Feuerwehr: Sie benötigt, um wirklich effektiv zu sein, sehr viel mehr Vorwissen über die IT-Infrastruktur eines Unternehmens, das nicht immer dokumentiert ist. Firmen, die langfristige Security-Monitoring und Incident-Response-Verträge mit ihren Security-Dienstleistern haben, bekommen also naturgemäß eine bessere Incident-Response-Leistung als solche, die im Falle eines Vorfalls zum ersten Mal mit einem Incident Responder Kontakt aufnehmen - weil man gemeinsam Playbooks und Notfallpläne für bestimmte Szenarien erarbeiten konnte, Fernzugänge für den Fall der Fälle existieren und Kennwörter und Netzwerkstruktur nicht erst mühsam erfragt werden müssen.
Alles richtig, schreiben die Autoren - aber das muss man sich leisten können.

Die optimistische Interpretation, die die Autoren vorschlagen, ist, dass Versicherungen im Idealfall Ressourcen sinnvoll verteilen:
Für einfache und sehr häufige Fälle gibt es den Billig-Responder, für die schwierigeren den Spezialisten - oder auch für kleinere Unternehmen, die sich eben keine teurere Versicherung mit höherwertigen (auch längerfristigen) Services leisten können.
Immerhin, so die Argumentation, ermöglicht die Versicherung solchen Unternehmen dann überhaupt Incident-Response-Dienstleistungen, die sie sonst wohl nie in Anspruch genommen hätten.

Das bedeutet aber auch, dass der Art der Ressourcenverteilung (Incident Responder auf Schadensfälle) durch Versicherungen eine hohe Bedeutung zukommt. Dabei sehen die Autoren drei Problemfelder:

1. Nach welchen Kriterien Incident-Response-Dienstleister ins Portfolio aufgenommen und im speziellen Fall ausgewählt werden, ist für den Versicherungsnehmer und die Security-Dienstleister gleichermaßen meist intransparent.
2. Schadenshotlines, die Incident Responder zuweist, werden oft von Anwaltskanzleien betrieben. Diese haben aber vor allem Anreize, Rechtsstreitigkeiten zu minimieren - nicht unbedingt technische Risiken.
3. Wenn Versicherungen dazu führen, dass die langfristigen Vorbereitungen (s.o.: Playbooks, Notfallpläne, Dokumentationen) zugunsten der Incident Response vernachlässigt werden, verkehrt sich der Vorteil des Zugangs zu Incident Response insgesamt eher zu einem Nachteil.

Eine Nebenbemerkung aus dem betrieblichen Alltag, weil wir ja auch so ein Incident-Response-Dienstleister sind: Wenn die Versicherung zahlt und nicht derjenige, der den Security-Vorfall hat, steigen tendenziell die Dienstleistungsumfänge von Incident Respondern - nicht immer zugunsten sinnvoller Tätigkeiten.
Um zur Analogie zurückzukommen: Wenn ich die Feuerwehr nicht selbst bezahlen muss, kann sie ja, wenn sie schon einmal da ist, gleich noch die Katze aus dem Baum holen, die schon vor dem Brand dort hochgeklettert war...

4. Wofür eignet sich LoRaWAN - und wofür nicht?

Haben Sie schon mal von LoRaWAN gehört und sich gefragt, wofür das gut ist?
Eine sehenswerte Einführung gibt Daniel Rusch in seiner Keynote der diesjährigen OSNA HACK-Konferenz. Die Aufzeichnung ist nun bei YouTube verfügbar (siehe Video-Link).

Die Stärke des Videos ist die ehrliche Kommunikation darüber, wofür LoRaWAN geeignet ist - und wofür eher nicht - anhand konkreter Anwendungsfällen des Stromnetzes Hamburg. Daniel Rusch erzählt dabei pragmatisch - und nicht getrieben von übermäßigem Technologieenthusiasmus à la "LoRaWAN löst all Ihre Probleme!" - wie Hamburg zu LoRaWAN kam, wie eine LoRaWAN-Architektur aussieht, und wie die eigene Lernkurve dabei aussah.
Zitat: "Am Anfang war uns eigentlich egal, dass das genutzte Protokoll LoRaWAN ist - wir wollten nur unsere Messdaten [von E-Ladesäulen] übertragen. Dann haben wir realisiert, was es da noch für Möglichkeiten gibt."

Bevor die Keynote losgeht, gibt es eine Einführung inklusive Erklärfilm (bis etwa Minute 8:30) - wenn man die Stromnetz-Hamburg-Werbung ausblendet, ist es eine guter, niedrigschwelliger Einstieg inklusive konkreten Anwendungsfällen, für die LoRaWAN geeignet ist: etwa Beleuchtungssteuerung für Straßenlaternen oder Parkplatzsuch-Apps - Smart-City-Klassiker.

Wichtig für die Industrie außerhalb der Smart-City-Welt ist eine Nebenbemerkung, die so nicht im Erklärfilm vorkommt:
LoRaWAN hat Stärken: große Reichweiten, verbraucht wenig Energie, ist kostengünstig in Implementierung und Betrieb und implementiert Security-Basics wie Verschlüsselung (AES 128 Bit) und Datenintegrität und -authentizität (über 32 Bit Message Integrity Code, MIC).

Was LoRaWAN nicht hat (und auch nie zu haben behauptet hat) ist Determinismus und Echtzeitfähigkeit - weit entfernt davon, denn LoRaWAN basiert auf UDP-Datenpaketen, die in der Zuverlässigkeit noch unter der von TCP/IP liegen.
Zu Deutsch: So ein Datenpaket kann durchaus auch schon einmal verloren gehen.

LoRaWAN ist damit ein Ersatz für Bluetooth oder WLAN mit deutlich besserer Reichweite und weniger Energieverbrauch, aber kein Ersatz für zum Beispiel Feldbusprotokolle. LoRaWAN wird nicht das nächste Wireless HART.

Eine weitere Limitation: Über ein LoRaWAN-Datenpaket kann man 50 Byte Daten transportieren. Das ist wirklich wenig - für Bild und Ton ist die Technik damit nicht geeignet.

Also: LoRaWAN ist eine Anwendung für neue "smarte" Anwendungsfälle - etwa den neu installierten Sensor für die prädiktive Wartung - aber eher nicht geeignet für existierende oder neue Anwendungsfälle mit besonderen Anforderungen an Security, Vertraulichkeit oder Echtzeitfähigkeit.
In Deutschland mit seiner strengen Regulierung im Bereich Smart Meters wird es zum Beispiel schwierig, LoRaWAN für abrechnungsrelevante Daten im Smart Metering einzusetzen.

5. Wie man BitLocker-Festplattenverschlüsselung knackt

Wenn der Laptop geklaut wird, aber ausgeschaltet ist - was kann ein Angreifer damit anfangen?

Nicht viel, oder? Denn Sie verschlüsseln ja selbstverständlich Ihre Festplatten. Das ist auch mittlerweile kein Hexenwerk mehr. Microsoft zum Beispiel bietet die Funktionalität standardmäßig mittels BitLocker: Festplatten werden beim Herunterfahren verschlüsselt, und zur Entschlüsselung beim Hochfahren gibt es zwei Optionen: Entweder gibt der User vor dem Booten einen PIN ein, oder der Schlüssel wird aus Microsofts "Trusted Platform Module", einem eigenen, speziell gesicherten Chip auf dem Motherboard, gelesen. Letzteres ist natürlich angenehmer für den Nutzer, da er nicht noch einen weiteren PIN im Kopf behalten muss.

Um es kurz zu machen: Am TPM selbst zu rütteln, ist sehr schwierig. Aber den Schlüssel bei der Übertragung aus dem TPM zur CPU aus einem unverschlüsselten Protokoll auszulesen, ist Security-Experten der Firma Dolos gelungen, wie sie in einem anschaulichen Blogpost (siehe Lesestoff) beschreiben.

Moral von der Geschicht: Wenn BitLocker, dann lieber mit userseitiger PIN-Eingabe (und wie immer: ausreichend komplexer PIN).

6. Zahlen und Fakten zu 10 Jahren öffentlicher OT-Exploits

Die US-amerikanische ICS-Security-Firma Dragos, die ihren Schwerpunkt bei den Themen Threat Intelligence (samt Monitoring Tool) und Incident Response hat, hat ein Whitepaper veröffentlicht, das Fakten zu den öffentlichen OT-Exploits der letzten zehn Jahre analysiert (Link im Lesestoff).

Interessant, weil sehr aufgeräumt, ist dabei schon die Definition von "öffentlichen OT-Exploits":

• Exploit: Als "Exploit" zählt Dragos alles, was einem Angreifer ohne fortgeschrittene Fähigkeiten ermöglicht, bewusst und schnell eine Security-Hürde zu überwinden. Das kann Code sein (ist es auch meistens), aber auch ein einzelner Befehl oder eine gute Anleitung. Meistens wird dabei eine Schwachstelle ausgenutzt (daher auch der Terminus "exploit" - to exploit = ausnutzen).
  (Wichtig zu unterstreichen: Exploits gibt es nur für eine kleine Teilmenge der bekannten Schwachstellen, und sie sind eines der wichtigsten Kriterien für die Kritikalität einer Schwachstelle.)
• Öffentlich: Als öffentlich gilt, was ohne weitere Hürden (technische, lizenzrechtliche, finanzielle) erreichbar ist. Meist bedeutet das: Ein öffentlicher Link im Internet.
• OT-Exploit: Das ist der interessanteste Teil der Definition, weil viel Erfahrungswissen darin steckt. Ein OT-Exploit ist nämlich laut Dragos alles, wovon man vernünftigerweise annehmen kann, dass es ein System in einem OT-Netzwerk beeinträchtigt. Und hier wird's interessant: Welche Systeme nimmt man da mit auf? Steuerungen, Leitsysteme, Historians sowie die Produkte der großen Leitsystemhersteller - klar. Dragos argumentiert, dass Exploits für in der OT häufig verwendete Fernwartungslösungen sowie für Windows-Produkte ebenfalls "OT-Exploits" sein können - aber nur, wenn sie Services betreffen, die in der OT eingesetzt werden, und außerdem in einem OT-Netzwerk praktisch ausführbar wären - zum Beispiel, weil sie keine Authentifizierung brauchen oder von remote funktionieren.

Über all diese Definitionen kann man trefflich diskutieren - aber es ist ein Wert an sich, sich daran zu versuchen, und sie sind transparent und nachvollziehbar. Der schon lang geführten Debatte darum, was eigentlich ein "OT-Vorfall" oder eine "OT-Schwachstelle" ist, tun solche Definitionvorschläge jedenfalls gut. Butter bei die Fische ist immer schwieriger als Definitionen zu zerreden.

Auch über die Definitionen hinaus enthält das Whitepaper wissenswerte Analysen:

• die betroffenen Produkte der Exploits in Figure 5 (110 verschiedene Hersteller, wobei Siemens und Rockwell die Liste auch aufgrund ihrer Verbreitung anführen dürften)
• ein Mapping der Exploits auf Purdue Level in Figure 6 (Level 2, also die Leitsystemebene, liegt vorn)
• ein Ranking der Exploit-Arten in Figure 7 (dabei liegt die Remote Code Execution klar vorn, was aber auch eine Folge der obigen Exploit-Definition sein dürfte)
• ein Ranking der Exploit-Methoden, die zur Remote Code Execution führen in Figure 8 und 9 (interessant: obwohl das Injizieren von Befehlen ein Evergreen ist, haben sich die weiteren populären Methoden über die Jahre von Korrumpieren des Speichers zu Knacken oder Umgehen der Authentifizierung verschoben).
• ein Durchschnitt der Zeit von einer veröffentlichten Schwachstelle zum brauchbaren Exploit in Figure 15 (24 Tage - Achtung, im betrachteten Datensatz sind natürlich nur Schwachstellen, zu denen überhaupt ein Exploit existiert!)

Insgesamt kann man - und das ist durchaus erwähnenswert - dem Whitepaper nicht vorwerfen, dass es Panikmache betreibt - weder in der recht nüchternen Analyse der Daten, die auch explizit einige Exploits als "praktisch unbrauchbar" kennzeichnet, noch die Schlussfolgerungen, die der Autor, Jacob Baines, am Ende zieht.
Interessant sind vor allem diese beiden:

Erstens: Es gibt OT-Exploits, die als unpraktikabel und daher weniger relevant gelten dürfen - und zwar solche, die nicht jederzeit genutzt werden können, sondern "besondere Umstände" wie User-Interaktion, Man-in-the-Middle-Zugriff oder sehr unübliche Konfigurationen erfordern.

Zweitens: Es gibt durchaus relevante Exploits für Systeme auf Purdue Level 1 und 2 - also Steuerungen und Leitsysteme. Es fehlen - offenbar auch Dragos, die immerhin ein Tool für die Sammlung dieser Informationen anbieten - Daten über diese Systeme, um zu beurteilen, wie oft Exploits für Level 1/2-Systeme in der Praxis tatsächlich genutzt werden.

7. Forrester-Überblicksstudie zu ICS-Security-Lösungen

Ein paar Zahlen und bunte Bilder zum Schluss: Forrester hat einen Studie zu Marktanteilen bestimmter ICS-Security-Lösungen in verschiedenen Regionen veröffentlicht (Link siehe Lesestoff).

Die Lösungen sind in die drei Kategorien unterteilt:

1. Asset Inventory,
2. Vorfallsdetektion und -vermeidung sowie
3. (Achtung, Buzzword für ein Potpourri aus Fernwartungsplattformen, Datendioden, Segmentierung und überhaupt alles-was-sonst-nicht-in-die-oberen-Kategorien-passte).

Schnellverweise auf interessante Informationen:

1. Figure 1 enthält einen Überblick über den Gesamt-Marktanteil aller bewerteten Lösungen. Interessant vor allem, um seine "potenzielle Lösungsliste" in einem sich ständig verändernden Markt zu aktualisieren. Positiv: Es sind neben den üblichen Verdächtigen auch kleinere und auch europäische Lösungen gelistet, etwa Awen oder Rhebo.
2. Figure 2 bewertet für die Vorfallsdetektions- und -vermeidungslösungen, welche der Lösungen welchen Teil abdecken (Detektion vs Vermeidung). "Notiz für später" für alle, die laut IT-Sicherheitsgesetz Systeme zur Angriffserkennung implementieren müssen und noch auf die genaue Definition des BSI warten, was diese Lösungen denn nun genau können müssen.
3. Figures 3-5 geben für die größten Lösungen Referenzen an, also: In welchen Branchen ist eine Lösung üblich und welches andere große Unternehmen hat was implementiert? Letzteres ist wohl mit Vorsicht zu genießen - höchstwahrscheinlich ist das kein besonders vollständiges Bild (denn es gibt gute Gründe für Unternehmen, diese Information nicht öffentlich zu machen). Die Brancheninformation kann aber durchaus gute Hinweise liefern.

8. Termine im September

Zu guter Letzt zwei Terminankündigungen für den September:

Vom 14.-16.09. finden in Pforzheim und virtuell die CE-Praxistage statt. Mit im Programm: Unser CEO Heiko Rudolph mit einem Vortrag zu Security by Design für Maschinenhersteller.
Für die Konferenz kann man sich noch anmelden unter diesem Link.

Am 14.09. bin ich außerdem beim Verein Safety-On zum zweiten Mal zu Gast: Beim letzten Mal schon hatten wir nach meinem Impulsvortrag darüber diskutiert, wie Security Engineering geht - im zweiten Teil wird es nun um Security for Safety gehen.
Das Kolloquium ist online, öffentlich und kostenlos und die Diskussionsrunde äußerst angeregt - hier geht's zur Anmeldung.

Stay secure!
Sarah Fluchs