Das bestimmende Thema im Juli hatte nichts mit Automation Security zu tun - wohl aber mit kritischen Infrastrukturen. Ich hoffe, Sie sind alle halbwegs unversehrt durch die Flutkatastrophe gekommen.

Im Schutzhelmbriefing könnten wir uns nun natürlich mit fehlenden SMS-Warnsystemen und nicht-idealen Katastrophenwarnapps befassen - aber wir müssen ja auch nicht jeder Katastrophe mit der Brechstange einen IT- oder Security-Bezug andichten. Stattdessen schauen wir auf einen anderen Teil der Debatte - Resilienz als Ziel im Engineering von kritischen Infrastrukturen.

Außerdem diesen Monat dabei: Ein Crashkurs zu Security im Rahmen der Störfallverordnung (inklusive KAS-51 und LANUV-Orientierungspapier), eine Einführung in Micropatching, ein Kennenlernen mit unseren neuen Bekannten Kaseya und Pegasus, Schwachstellen in Druckern und Backup-Tools, kleine Updates zu OT-Monitoring Tools - und eine Einladung zur DefCon, die diese Woche startet.

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

1. Resilienz: Was können Ingenieure gegen Katastrophen tun?
2. Security im Rahmen der Störfallverordnung - ein Crashkurs
3. Kaseya: Die Pandemie unter den Lieferketten-Angriffen steht noch aus
4. Das IT-Sicherheitskennzeichen kommt
5. Security-Monitoring: Große Marketingerfolge, Assetinventar fehlt
6. Schwachstellen für Drucker und ein SPS-Backup-Tool
7. Was ist eigentlich Micropatching?
8. Top 20 Secure PLC Coding Practices bei der DEFCON und im Podcast

1. Resilienz: Was können Ingenieure gegen Katastrophen tun?

Die Welt hat auf Deutschland geschaut im Juli: Unsere Flutkatastrophe ist durchaus in den internationalen Nachrichten angekommen. Dort reiht sie sich freilich ein in die Berichterstattung über extreme Wetterereignisse - Hitze, Dürre, Starkregen, Stürme - in der ganzen Welt.

Es ist nur verständlich, dass Gesellschaften nach Gründen suchen, woher die Katastrophen kamen, warum sie uns so getroffen haben, und was wir in Zukunft tun können, um sie zu verhindern. Wir setzen hier die Ingenieurbrille auf - was sollen wir auch anderes tun im Schutzhelmbriefing? - und fragen uns, was wir uns eigentlich die ganze Zeit fragen: Wie können wir Infrastrukturen eigentlich resilienter machen?

Zur Erinnerung: Resilienz bedeutet, dass ein System weiter funktioniert, auch wenn es zu unvorhergesehenen Ereignissen kommt - egal ob mit böswilliger Intention (ein Hackerangriff) oder nicht (eine Naturkatastrophe). Damit kann "Resilience Engineering" als die übergeordnete Disziplin zu Safety und Security betrachtet werden, und diese Disziplin rückt "dank" Wetterkatastrophen momentan vermehrt in den Fokus, weshalb Sie hier nun ein bisschen Resilienz-Lesestoff mitbekommen.

Beginnen wir mit einem Zitat des Bauingenieurs Mikhail Chester aus Arizona, USA. Es eignet sich auch wunderbar, um Ihren Englisch-Wortschatz aufzubessern: "You’ve got this slow moving, what we call obdurate infrastructure, stubbornly refusing to change, ossified, locked in. There’s lots of good words for it [...]. Climate is changing faster than infrastructure can respond. That’s the crux of the problem."
Kleine Lesehilfe: obdurate = verstockt, stubborn = stur, ossified = verknöchert. Sie verstehen das Prinzip: Das sollen keine Komplimente für die Infrastruktur sein. Die Infrastruktur, führt Chester weiter aus, kann nicht schnell genug auf Änderungen und - da sind sie wieder - unvorhergesehene Ereignisse reagieren. Der Grund: Wir legen Infrastrukturen aus basierend auf zu starren Annahmen, die anhand der Beobachtung der Vergangenheit getroffen wurden.
Die Lösung: Nicht die alten starren Annahmen durch neue starre Annahmen ersetzen, sondern damit rechnen, das nicht alle Ereignisse, die die Infrastruktur aushalten muss, vorhergesagt werden können.
Das ist wiederum eine Denkweise, die uns in der Security bekannt vorkommt. Daher ist das kurze Interview mit Mikhail Chester lesenswert (Lesestoff 1), in dem er Beispiele dafür gibt, wie man das mit der Resilienz erreichen kann.
Er gehört übrigens auch einem Forschernetzwerk zu "Urban Resilience" an, das dieses Jahr ein OpenAccess-Buch veröffenlticht hat: Resilient Urban Futures. OpenAccess bedeutet, Sie können das digitale Buch kostenlos herunterladen. Sie finden es im Lesestoff-Link 2.

Eine 3min-Einführung in Resilience Engineering bekommen Sie übrigens auch zu Beginn meines Vortrags bei der ICS Cybersec Israel Anfang dieses Jahres. Das Video finden Sie mittlerweile bei YouTube (und als Video-Link 3).

Ein letztes Bisschen Lesestoff zum Thema Resilienz, dieses Mal mit sehr konkretem Automation-Security-Bezug: Andy Bochman erklärt im Blog zum Thema "Humans in the Loop" (Lesestoff 4), warum trotz aller Automatisierung ein Mensch im Prozess von unschätzbarem Wert ist. Auch das kann ein Aspekt von Resilienz sein...
Zitat: "Our older power plants were designed to be started manually, but we have often taken away this option or not maintained employees’ skills to do such a manual restart."

2. Security im Rahmen der Störfallverordnung - ein Crashkurs

Was Sie hinsichtlich Security machen müssen, wenn Sie unter die Störfallverordnung fallen, regelt schon seit 2019 der Leitfaden "KAS-51" der Kommission für Anlagensicherheit - mit vollem Titel: "Leitfaden des Arbeitskreises 'Eingriffe Unbefugter' ".
Seit diesem Jahr gibt es auch ein Orientierungspapier des NRW-Landesamt für Umweltschutz (LANUV NRW) mit dem Titel "Orientierungspapier Darstellung der IT-Sicherheit im Sicherheitsbericht und in den Genehmigungsunterlagen zur Anlagensicherheit". Das Papier sorgt für Diskussionen.

Ich hatte Ihnen das Orientierungspapier im letzten Monat schon verlinkt - und wollte es diesen Monat eigentlich nur mal kurz einordnen. Tja, das mit dem "mal kurz" hat nicht geklappt; es ist nun ein umfassender Text über Security im Rahmen der Störfallverordnung geworden, der neben einem Erklärbärexkurs zum KAS-51-Leitfaden nun auch einen Security-Engineering-Crashkurs beinhaltet... aber das LANUV-Papier wird am Ende auch noch eingeordnet, versprochen. Link im Lesestoff.

Spoiler für Lesefaule: Die KAS-51 fordert nichts Absurdes, aber eben auch nicht nur Compliance. Wenn Sie eine Security-Risikoanalyse haben, stehen die Chancen gut, dass die auch die KAS-51 zufriedenstellt (auch, wenn manche Begrifflichkeiten etwas ungewohnt gewählt sind). Wenn Sie keine Security-Risikoanlayse haben, können Sie jede Wette eingehen, dass ein KAS-51-Auditor mit Ihnen nicht so glücklich wäre.
Und das LANUV-Orientierunspapier? Das ist schon fast so etwas wie eine Musterlösung zur Erfüllung der KAS-51.

Zum Ende des Texts habe ich vier Wegweiser für Sie, wenn Sie sich im Rahmen der KAS-51 erstmals mit Security auseinandersetzen dürfen:

1. Lernen Sie Ihre Risikoanalyse lieben
2. Beim Geltungsbereich ist mehr manchmal mehr (also weniger Arbeit)
3. Wie immer: Denken Sie in Funktionen
4. Setzen Sie die Compliance-Brille ab, sonst fühlt sich die KAS-51 auch an wie Compliance: trocken, sinnbefreit, rundum ärgerlich. Sie müssen sie dann trotzdem erfüllen, es tut nur mehr weh.

3. Kaseya: Die Pandemie unter den Lieferketten-Angriffen steht noch aus

Vieles klingt altbekannt beim Kaseya-Vorfall. Es war Ransomware, natürlich.
Und es wurde ein Software-Updatemechanismus einer IT-Management-Software für die Verbreitung des Schadcodes genutzt - Solarwinds lässt grüßen (siehe Januar-Briefing).

Wie immer bei Lieferketten-Angriffen ist es nicht ganz einfach herauszufinden, wer nun alles betroffen ist. Schwierig in diesem Fall: Die IT-Management-Software Kaseya wird viel von Systemhäusern eingesetzt, die "Managed Services" anbieten, also den Betrieb der IT für ihre Kunden. In diesen Fällen wissen die Kunden nicht unbedingt, welche Software ihr IT-Systemhaus verwendet. Erschwerend kommt hinzu, dass die Systemhäuser Kaseya unter eigener Marke nutzen dürfen. Nicht überall, wo Kaseya drin ist, steht auch Kaseya drauf.

Das BSI hat dazu eine "Cybersicherheitswarnung" mit der zweithöchsten Bedrohungsstufe herausgegeben (Lesestoff 1).

Also: Wer sicher ist, dass bei ihm kein Kaseya im Einsatz ist, für den besteht keine Gefahr. Und in der OT ist die Software, und der Einsatz von IT-Systemhäusern im Allgemeinen, ohnehin weniger verbreitet. Das erinnert ein wenig an SolarWinds. Auch da war die OT fein raus - weil die nur die neueren Softwareversionen von SolarWinds betroffen waren. Und wer hat in der OT schon die neuesten Softwareversionen?

Also abheften und weitermachen (und hoffen, dass der Kelch auch zukünftig an uns vorübergeht)?
Nicht ganz, warnt Matt Tait in einem wirklich lesenswerten Artikel (Lesestoff 2). Er führt darin aus, warum Angriffe über die Lieferkette - auf Englisch: Supply Chain Attacks - ganz anderen Gesetzen folgen als "normale" Angriffe, und warum wir uns das bewusst machen müssen, um damit richtig umzugehen.

Der ganze Text lohnt sich, aber hier sind die wichtigsten Aspekte "in einer Nussschale", wie der Amerikaner sagen würde:

• Angriffe über die Lieferkette sind nicht selten, und sie haben große Auswirkungen. NotPetya? SolarWinds? Beide begannen über die Supply Chain.
• Angriffe über die Lieferkette sind nicht wählerisch, was ihre Opfer angeht. Es geht noch weiter: Das können sie auch gar nicht sein. Jeder, der ein Software-Update des angegriffenen Lieferanten installiert, bekommt den Schadcode. Für die Angreifer ist das nicht schlimm - sind halt vielleicht ein paar Unternehmen im Netz, die man gar nicht treffen wollte. Für Sie als potenzielles Opfer heißt das - wieder einmal: "Wer greift uns schon an?" zieht nicht mehr. Es muss Sie niemand angreifen wollen. Sie haben nicht weniger Schaden, wenn Sie ein Kollateralschaden sind.
• Der Super-GAU, die Pandemie unter den Virusinfektionen, steht noch aus. Und ähnlich wie es vor Corona auch der Fall war, befürchten Experten, dass diese Schadcode-Pandemie nur eine Frage der Zeit ist. Wie eine Pandemie über die Lieferkette aussähe? Stellen Sie sich einfach vor, nicht Kaseyas, sondern Microsofts Softwareverteilmechanismus würde für Schadsoftware genutzt. Oder Adobe. Oder Mozilla. Oder NVidia. Oder...
• Normale Verteidigungsmechanismen in der Security wären mit einer Lieferketten-"Pandemie" überfordert. Zwei Beispiele: Wenn eine bislang unbekannte Schwachstelle, ein "zero day" genutzt wird, verbreitet sich Schadcode eine Weile schnell. Aber auch nur eine Weile - sobald das Ganze entdeckt ist, gibt es Patches, Workarounds, Warnungen. Das gilft natürlich auch für Supply-Chain-Angriffe, nur: Hier wird eine einzige Schwachstelle im Zweifel sehr schnell und sehr effektiv sehr oft ausgenutzt. Bis die Warnungen kommen, sind schon sehr viele infiziert. Und dann kommt das zweite Problem: Irgendwann sind Incident-Reponse-Kapazitäten, die bei punktuellen Infektionen immer ausreichen, erschöpft. Die Analogie passt leider auch hier: Vor Corona wusste niemand, wie viele Intensivbetten es in seiner Stadt gibt...
• Für betroffene Hersteller reicht es bei Lieferketten-Angriffen nicht, einfach die Schwachstelle zu patchen.
  Über welchen Mechanismus denn auch? Dem Update-Mechanismus wird so schnell niemand vertrauen. Stattdessen müssen sie ihre eigene Infrastruktur herunterfahren (mit allen Konsequenzen für die Kunden) und das eigene System wieder sicher bekommen. Das schreit nach ganz neuen, ungewohnten Incident-Response-Playbooks auch für Hersteller.

Die Krux mit den Lieferketten-Angriffen ist, dass sie einen der wichtigsten Verteidigungsmechanismen der Security-Industrie missbrauchen: Schnelle, zentral verteilte Updates für alle Endgeräte. Klar, dass dieser Verteidigungsmechanismus aus zweierlei Perspektive ein interessantes Angriffsziel ist. Erstens, weil aufgrund der Zentralität effizient. Zweitens, weil damit direkt auch die Verteidigung gegen den Angriff lahm liegt. Es ist ein bisschen so, als würden Corona-Impfstoffe die Impflinge gleich mit dem nächsten Virus infizieren.

4. Das IT-Sicherheitskennzeichen kommt

Die ersten Auswirkungen des IT-Sicherheitsgesetz 2.0 (IT-SiG 2.0) werden sichtbar: Das Bundesamt für Sicherheit in der Informationstechnik (BSI), das im IT-SiG 2.0 den Auftrag bekommen hat, ein IT-Sicherheitskennzeichen einzuführen, hat dafür nun eine eigene Internetseite eingerichtet - mit Informationen für Hersteller und "Verbraucher" von IT-Produkten (siehe Lesestoff-Link).

Das IT-Sicherheitskennzeichen ist freiwillig. Das muss es auch sein, denn eine verpflichtende Kennzeichnung würde gegen EU-Recht verstoßen.

Für die Industrie sind die IT-Sicherheitskennzeichen bislang eher eine Randnotiz, denn die gekennzeichneten Geräte sind vornehmlich solche, die nicht-industrielle Verbraucher kaufen: Router, Smart-TVs, Überwachungskameras und "smarte" Heizungsthermostate nennt das BSI als Beispiele. Das Kennzeichen soll als QR-Code auf Produkten in Elektronikmärkten oder Online-Shops zu finden sein. Diese Codes können dann gescannt werden und führen auf eine Produktseite beim BSI, die IT-Sicherheitseigenschaften auflistet.
Die zu erfüllenden Sicherheitseigenschaften werden vom BSI in "BSI TRs", also technischen Reports, je Produktkategorie festgelegt. Man kann also nur IT-Sicherheitskennzeichen für eine vom BSI vorbereitete Produktkategorie beantragen. Sicherheitskennzeichen laufen nach einer vorgegebenen (bislang aber nicht näher definierten) Zeitspanne ab.
Werden Sicherheitslücken für das Produkt bekannt, informiert das BSI auch darüber.

Das ist besser als der Status quo, keine Frage. Aber es gibt einen großen Wermutstropfen:
Das BSI prüft die angegebenen IT-SIcherheitseigenschaften nicht, sondern der Hersteller gibt eine Selbstauskunft.
Eine "nachgelagerte Marktaufsicht" (?) soll diese Lücke füllen, indem "regelmäßige, systematische Prüfungen" und "anlassbezogene Prüfungen" bei Zweifeln an der Herstellererklärung durchgeführt werden. Wer diese Prüfung nach welcher Methodik und wann durchführt, dazu schweigen sich die Infoseiten des BSI aus. Offenbar gilt: Erst das Kennzeichen, dann die Prüfung. Gewöhnungsbedürftige Reihenfolge.

Dafür geht es nun schnell voran: Schon Ende 2021 sollen IT-Sicherheitskennzeichen für die ersten Produktkategorien (Breitbandrouter, E-Mail-Dienste) von Herstellern beantragbar sein.

5. Security-Monitoring: große Marketing-Erfolge, Assetinventar fehlt

Wer sich mit dem Thema Security Monitoring Tool für OT befasst, für den gibt es ein paar kleinere Updates.

Dale Peterson, der den Markt kontinuierlich beobachtet, hat bereits im Mai ein Update herausgebracht (Lesestoff 1).
Die Botschaft am Anfang ist wichtig, genau zu lesen: Der "ICS Detection"-Markt boomt - und das hat vor allem mit gutem Marketing und viel Geld in diesem Markt zu tun. Mittlerweile findet die Empfehlung, solche Tools einzusetzen, sogar in Regierungspublikationen Platz. Auch in Deutschland haben wir das im IT-Sicherheitsgesetz 2.0 gesehen - was umso skurriler war, da das IT-SiG abgesehen von dieser einen eigentlich überhaupt keine speziellen Technologien empfiehlt.

Zumindest in Deutschland kann man zusammenfassen, dass dieser Fokus auf Monitoring-Technologien eigentlich an den drängendsten Problemen vieler Betreiber vorbeischießt. Worüber die sich wirklich freuen würden, wäre eine funktionierende Asset-Inventory-Lösung. Die bieten aber die vielen Monitoring-Tools eher als Abfallprodukt denn als wirklich strategische Komponente, was man auch daran sieht, dass die Asset Inventory-Lösung in der Regel nicht unabhängig von der Monitoring-Lösung zu erwerben ist.

Der neueste Schrei, der eher in Richtung Asset Inventory geht, sind "SBOM"-Lösungen. SBOM steht für "Software Bill of Materials" - Software-Stücklisten, wörtlich übersetzt. Das ist nichts anderes, als man von einem durchdachten Assetinventar erwarten würde. Das klingt gut, weil es schon eher die echten Schmerzen vieler Betreiber adressiert.

Was spannend wird: Ein Assetinventar ist eigentlich nicht nur ein Security-Tool, und es wäre fatal, wenn es ein Datensilo baut, das nur für Security genutzt wird. Denn eigentlich wäre so ein Assetinventar der Grundstein für Digitalisierung und Industrie 4.0 - und zwar für alle Engineering-Domänen.
Das würde aber bedeuten, dass sich SBOM-Hersteller mit Datenmodellen befassen müssen, die auch außerhalb der Security-Blase Relevanz haben. Bislang war da wenig zu sehen.

Kleinere Infohäppchen zur Monitoring-Tool-Landschaft:

• Die drei Platzhirsche bleiben Dragos, Nozomi und Claroty, und sie werden weiterhin mit großen Finanzierungsrunden von Investoren gestützt. "Groß" bedeutet hier wirklich groß, und damit lassen Sie sich auch noch einmal Dale's Aussagen zu Marketingbudgets auf der Zunge zergehen: Dragos hat Ende 2020 110 Mio US-Dollar eingesammelt, Claroty im Juni diesen Jahres 140 Mio US-Dollar.
• Der Rest wird Stück für Stück akquiriert - was aber nicht schlecht sein muss, weil es auch die Integration in eine größere Lösung (in die Cloud wie bei Microsoft / CyberX oder in eine gemeinsame Lösung für IT und OT wie bei Tenable und Indegy) bedeuten kann.
• Neueste Akquisition, frisch aus dem Juli 2021: OPSWAT hat Bayshore gekauft.
• Bei Github gibt es einen (privat gepflegten) Überblick über verschiedene Tools (Lesestoff 2).
• Bei Monitoring-Tools immer eine interessante Frage: "Hätte das Tool *Angriff XY* erkannt? Die US-Organisation MITRE simuliert auf Basis ihres ATT&CK-Frameworks bekannte Vorfälle, um Tools darauf zu testen. Im ersten Durchlauf wurden fünf Tools auf den Triton-Angriff angesetzt: Armis, Claroty, Dragos, the Insitute for Information Industry, and Microsoft. Beschreibungen des Vorgehens und "Ergebnisse" gibt es im Lesestoff 3. (Von den Ergebnissen dürfen Sie nicht zu viel erwarten - es gibt kein Ranking der fünf, und sie erfordern noch einiges an Interpretation).

6. Schwachstellen für Drucker und ein SPS-Backup-Tool

Was wäre so ein Monat ganz ohne Schwachstellen?
Also hier ein kurzer Überblick:

1. Microsoft Print Spooler:
"Drucker" ist hier ein bisschen vereinfacht; eigentlich geht es um zwei Schwachstellen in Microsofts Print Spooler Service.

Details und Links:
"PrintNightmare" / Print Spooler Remote Code Execution:
CVE-2021-34527, CVSS Base Score 8.8

PrintSpooler Evelation of Privilege:
CVE-2021-1675, CVSS Base Score 7.8

Der Print Spooler Service ist ein Microsoft-Dienst, der die beteiligten Systeme zu Druckservern oder -Clients macht, also bedingt, dass sie Druckaufträge versenden oder empfangen und ausführen können.
In diesem Dienst wurde nun eine neue Schwachstelle bekannt, die es möglich macht, willkürliche Dateien als Druckertreiber hochzuladen und vom Print Spooler Service ausführen zu lassen. Das funktioniert aus der Ferne - daher ist es eine Remote Code Execution-Schwachstelle. Die "Privilege Evelation" ist dadurch begründet, dass der Code im Service-Kontext, also mit dem Dienstkonto des Print Spooler Services, ausgeführt wird.

Der Print Spooler Service ist standardmäßig auf allen Windows Clients und Servern aktiviert. Microsoft empfiehlt nun, ihn zu deaktivieren, wenn er nicht benötigt wird. Außerdem gibt es ein Patch für die von Microsoft selbst gemeldeten Schwachstellen.

2. MDT Autosave Tool
MDT Autosave ist eine Software, mit der man Änderungen in SPS-Code sichtbar machen, verwalten, versionieren und rückgängig machen kann.

In der Software wurden mehrere Schwachstellen gefunden, die in der Kombination (und mit Kenntnis der Produktarchitektur, wie das Advisory der US-Behörde CISA klarstellt) im schlimmsten Fall zur vollständiger Übernahme des von der MDT-Software verwendeten Servers aus der Ferne führen könnte - ohne, dass eine Authentifizierung nötig ist.

Details und Link:
Benannt werden sechs CVEs, die kritischste mit dem CVSS Base Score 10.0

Die Schwachstellen wurden von Claroty, einem Hersteller eines OT-Asset Management und -Monitoring-Werkzeugs gemeldet (siehe auch Thema 5 des heutigen Briefings). Seitens MDT gibt es Updates für alle betroffenen Softwarekomponenten und -versionen.

7. Was ist eigentlich Micropatching?

Security-Lösungen verkleiden sich ja gern in fancy neuen Begriffen. Vielleicht sind Sie in letzter Zeit mal über den Begriff "Micropatching" gestolpert?

Mein Kollege Claudius Manthey hat für Sie zusammengefasst, was es damit auf sich hat.

Warum gibt es Micropatching?
Micropatching soll zwei Patching-Probleme lösen:
- Der Hersteller braucht zu lange, bis er Security-Patches zur Verfügung stellt
- Der Hersteller stellt gar keine Security-Patches (mehr) zur Verfügung

Ein Klassiker: End-of-Life-Betriebssysteme wie Windows 7 oder Windows XP.

Warum heißt das Micropatching?
Wichtig also: Micropatching stellt kleine Patches bereit, die nicht vom Hersteller kommen, und nur einzelne, ausgesuchte Sicherheitslücken patchen (daher auch das "micro"). Weil das aufwendig ist, wird dabei der Fokus oft auf häufig verbaute Systeme und auf besonders kritische Schwachstellen gelegt.

Die bekannteste Firma für Micropatches ist der kleine slowenische Anbieter Acros Security mit seiner Lösung "0patch".

Wie funktioniert das technisch?
Wenn man patchen möchte, aber nicht der Hersteller der Software ist, hat man zwei Hürden zu bewältigen:

1. Die neue ausführbare Datei muss vom Zielsystem akzeptiert werden, ohne die Herstellersignaturen verwenden zu können.
   Beim herkömmlichen Patchen werden die ausführbaren Dateien (üblicherweise *.exe, *.dll, *.ocx o.ä.) auf der Festplatte durch neue ausführbare Dateien ersetzt. Sowohl die alten wie auch die neuen Dateien wurden vom Hersteller aus dem Quellcode kompiliert und dann anschließend von diesem auch signiert.
   Da ja Micropatches aber von Drittanbietern kommen, haben diese natürlich weder Zugang zum Quellcode noch zu den privaten Schlüsseln der Hersteller und können diesen üblichen Weg deshalb nicht gehen. Stattdessen wird versucht, bei jedem Laden der ausführbaren Datei in den Hauptspeicher diese Datei mittels eines Agenten zu patchen, nachdem die Signatur überprüft wurde, aber bevor der Binärcode ausgeführt wird.
2. Das Micropatch muss die ausführbare Datei zielgerichtet verändern, ohne den Hersteller-Quellcode zu kennen.
   Das Micropatch muss natürlich Änderungen gegenüber dem Originalcode enthalten; der Binärcode muss ja verändert gepatcht werden.
   Auch hier bleibt einem Drittanbieter ohne Kenntnis des Quellcode nichts anderes übrig, als die notwendigen Änderungen aus der Analyse von Änderungen neuerer Programmversionen abzuleiten, oder entwickelt sie komplett selbst, z.B. durch Reverse Engineering.
   Ein Beispiel: Wenn sich in Office 2016 aufgrund eines Patches einige Bytes geändert haben, versuchen Micropatch-Anbieter, ob diese Änderung auch beim nicht mehr unterstützten Office 2010 funktioniert.

Wo liegen Probleme?
Das Kernproblem ist, dass ein Micropatch ein System zum Akzeptieren einer nicht vom Hersteller freigegebenen Änderung einer Software bringen muss.

Ein Virus hat nämlich dasselbe Ziel, weshalb sich zuerst die technische Frage stellt, was Anti-Schadcode-Lösungen zum Micropatching sagen (sie sollten so etwas eigentlich verhindern).

Darüber hinaus bedeutet Micropatching, dass Sie viel Vertrauen in den Anbieter des Micropatches (und seine Zulieferer, und sein Security-Konzept) legen. Denn Sie erlauben damit einer Drittfirma, für Sie nicht überprüfbare Änderungen in Programmcode eines anderen Herstellers einzuspielen - in der Hoffnung, dass diese Firma überblickt, was das für Auswirkungen und Seiteneffekte hat.

Ist Micropatching in der OT eine Option?
Kurz: Geht so bis eher nicht.
Vier Gründe über die obenstehenden Probleme hinaus:

1. Herstellerfreigaben
   Vor allem in der OT sind außerdem Hersteller extrem penibel, was die Freigabe von Systemänderungen und der Wahrung von Produktgarantien angeht - und das sogar bei "offiziellen" Patches. Dass Micropatches akzeptiert werden, ist unwahrscheinlich.
2. Produktabdeckung
   Micropatching konzentriert sich (noch) auf sehr populäre, in vielen Bereichen eingesetzte IT-Software - oft sind das Microsoft-Produkte. Viele in der OT eingesetzte Produkte dürften vorerst durch das Raster fallen.
3. Internetanbindung des Micropatching-Agenten
   Für Micropatching muss in der Regel ein Agent mit Internetanbindung auf dem Zielsystem installiert sein. Das bedeutet, dass Sie für viele OT-Systeme, die keine Internetanbindung haben, die Angriffsfläche vergrößern.
4. Risikoärmere Alternativen
   Für viele Produkte, die Micropatching abdeckt, stellt der Hersteller noch Updates zur Verfügung - nur eben kostenpflichtig. Und: In der OT ist "informiertes Nicht-Patchen" durchaus eine Option - man kann die sehr statischen OT-Systeme manchmal sinnvoller anderweitig schützen, etwa durch Segmentierung und strenge Zugriffsreglementierung.

8. Top 20 Secure PLC Coding Practices bei der DEFCON und im Podcast

Diese Woche startet die DEFCON - eine internationale Security-Konferenz. Beim ICS Village im Rahmen der DEFCON geht es nur um Automation Security. Mein Co-Organisator Vivek Ponnada und ich stellen dort die Top 20 Secure PLC Coding Practices vor.

Agenda für das DefCon ICS Village finden Sie in Link 1. Wir sind am Sonntag, 8. August, dran; wahrscheinlich von 21-22 Uhr mitteleuropäischer Sommerzeit.

Da die DefCon ein Hybrid-Event ist (teilweise in Las Vegas, teilweise online), gibt es unseren Vortrag aber auch aufgezeichnet. Virtuelle Teilnahme ist kostenlos und funktioniert über den Discord-Channel des ICS Village (siehe Link 2) vom 6. bis 8. August - die Vorträge werden aber später auch via YouTube veröffentlicht (siehe Link 3).

Außerdem waren Vivek und ich zu Gast in Andrew Ginters Waterfall ICS Security Podcast. Die Aufzeichnung können Sie unter Link 4 anhören (auch bei YouTube, Apple Podcasts, Google Podcast und Spotify verfügbar).

Stay secure!
Sarah Fluchs