Patch Management

00:00:00: Herzlich Willkommen!

00:00:01: Björn Marmann, Teamleiter und Account Manager Industrial IT Solutions bei Spiratec.

00:00:07: Björnn bitte stelle Dich und auch die Firma Spirotec unseren Hörerinnen und Hörern kurz vor.

00:00:13: Vielen Dank.

00:00:14: ich freue mich sehr bei Euch Gast sein zu dürfen.

00:00:16: Mein Name ist Bjorn Marmann und Ich bin seit dem Jahr zwei Tausend neunzehmal der Spiritec Momentan in der Rolle als Team und Account manager Und ich bin für den Fachbereich Industrial IT Solution Für die Standorte Köln und Dortmund verantwortlich.

00:00:29: Mein Team und ich sind hauptsächlich auf die Themengebiete Historian-Systeme, Infrastruktur & Security fokussiert.

00:00:36: Worunter eben auch das Patchmanagement fällt.

00:00:39: The Spiratec ist ein unabhängiger Automations- und IT-Dienstleister mit den Fachbereichen Engineering, Automatisierung und einen Industrial IT.

00:00:50: Und wir unterstützen Unternehmen aus der Farmer und Prozessindustrie bei der Planung, bei der Umsetzung und Optimierung ihrer Systeme Und das von eben der Feldebene und Leittechnik bis hin zu übergeordneten IT-Systemen immer mit einem klaren Fokus auf praxisgerecht und regelkonforme Lösungen.

00:01:11: Ja, Regelkonform passt ja zu unserem heutigen Gespräch.

00:01:15: Björn, du bist Mitglied in einem ad hoc Arbeitskreis des Namurarbeitskreises vier Punkt achtzehn Automation Security.

00:01:24: Ihr habt euch mit dem Thema Patch Management befasst und im Dezember ein Namor-AK-Praxispapier zu diesem Thema veröffentlicht.

00:01:33: Was genau versteht ihr unter Patchen?

00:01:36: Und warum muss man eigentlich patchen?

00:01:39: Der Hintergrund ist, dass klassische Automatisierungs- und OT-Systeme – Operational Technology – zunehmend auf Standardbetriebssystems und ITNAR Komponenten basiert Aber gängige Methoden aus klassischen Office IT-Umgebungen nicht eins zu eins übertragbar sind.

00:02:00: Für die Prozessindustrie heißt es, da natürlich Besonderheiten zu beachten.

00:02:06: Einerseits haben wir sehr hohe Anforderungen an Verfügbarkeiten und Betriebskontinuitäten und auf der anderen Seite muss natürlich beachtet werden dass das Patchen eben auch Systeme destabilisieren kann im schlimmsten Falle Produktionsausfälle verursachen kann, wenn eben nicht so fältig geplant und im Anschluss gepatched wird.

00:02:31: Damit erklärt sich auch warum Patchmanagement besonders wichtig ist.

00:02:35: Es braucht einen strukturierten risikobasierten Ansatz der Sicherheit berücksichtigt um den Schutz vor Angriffen oder Manipulation zur Gewährleistung aber auch die Verfügbarkeit berücksichtigst sodass Produktionsprozesse stabil und zuverlässig laufen.

00:02:55: So ohne strukturierte Vorgehensweise könnten eben Schwachstellen unentdeckt bleiben oder auch Patch-Prozesse unbeabsichtigte Störungen verursachen.

00:03:07: Vielen Dank, das ist eine super solide Einordnung des Themas!

00:03:13: Jetzt kommt natürlich die Frage warum ihr als Arbeitskreis und Dynamo euch entschieden habt.

00:03:19: Das Patchmanagement soll es so wichtig anzusehen, dass ihr es noch mal explizit für die Automatisierung in der Prozessindustrie

00:03:26: behandelt.

00:03:28: Ja das Dokument gibt es ja schon relativ lange und ist zurzeit wieder mehr als aktuell mit der Einführung von NIST II.

00:03:36: NISTII ist eine EU-weite Rechtsvorschrift zu Stärkung der Cybersicherheit und wir haben uns die Aufgabe gesetzt diesen Leitfaden praxisgerecht zu bearbeiten.

00:03:48: Zunächst wichtig zu unterscheiden, dass mit dem Patchen nicht der Funktionsumfang eines Betriebssystems oder einer Applikation erweitert wird.

00:03:56: Sondern das es sich um eine Korrektur bestehender Fehler- oder Schwachstellen handelt und der Geltungsbereich reicht vom Betrieb System über die Applikations bis hin zur Hardware Nahes Software.

00:04:11: Die Installation von Patchen dient dazu Cyber-Sicherheitsschwachstellen zu beheben, Fehlfunktionen zu korrigieren und die Betriebsfähigkeit und Zuverlässigkeiten der Systeme sicherzustellen.

00:04:27: Das klare Ziel des Patchmanagement ist es das Zeitfenster der Gefährdung möglichst kleinzuhalten, denn ohne ein aktives Patch besteht immer die Gefahr der Kompromittierung des Systems womit wiederum Verfügbarkeit und Integrität beeinträchtigt werden kann, weil eben Angreifer durch nicht behobene Schwachstellen Zugriff auf Systeme erlangen und damit auch Produktionsprozesse beeinflussen können.

00:04:54: So dass das heißt erst die erfolgreiche Installation eines Patches schließt die Schwachstelle und beendet genau diese Zeitfenster der

00:05:02: Gefährdung.".

00:05:03: Jetzt kommt natürlich eine spannende Frage vor dem aktuellen politischen Hintergrund.

00:05:08: Wir haben ja in Deutschland kein Erkenntnisproblem, sondern offensichtlich ein Umsetzungsproblem.

00:05:14: Gilt das auch fürs Patchen?

00:05:15: Das heißt wie ist euer Eindruck?

00:05:17: Wird in der Industrie schon fleißig und zeitnah gepatched oder wird das Thema eher stiefmütterlich behandelt und auch gerne mal ein bisschen von sich geschoben?

00:05:27: Ja, der allgemeine Eindruck ist dass das Bild in der industrie noch sehr heterogen ist.

00:05:33: Sofern im klassischen Office-IT Umgebungen häufig und strukturiert, auch regelmäßig gepatched wird ist die Umsetzung in der OT oft noch deutlich zurückhaltender.

00:05:49: Die Gründe für Zurückhaltung sind natürlich von Kunde zu Kunde ganz unterschiedlich.

00:05:55: Der Eindruck den wir aber in den vergangenen Jahren bekommen haben spiegelt ganz ähnliche Punkte wieder.

00:06:02: das ist zum einen dass sehr, sehr hohe Verfügbarkeitsanforderungen vorhanden sind.

00:06:09: Aber gleichzeitig auch die Angst vor Produktionsausfällen durch zum Beispiel inkompatible Patches besteht und es bestehen halt immer Abhängigkeiten zu Herstellern mit ihren Freigaben und darüber hinaus auch sehr aufwendige Kompatibilitätstests.

00:06:28: Und daraus ergibt sich so eine sehr typische Praxis, nämlich dass Patches häufig auf geplante Wartungsfenster verschoben werden oder sie erst bei akuter Bedrohung zeitnah umgesetzt werden.

00:06:43: Unser Eindruck ist damit das zwar eine positive Entwicklung spürbar ist und das Bewusstsein für Security und das Patchmanagement deutlich steigt ja?

00:06:55: Und auch durch eine Einführung von zum Beispiel einer NIS-Zweirichtlinie dass Patch Management für sehr viele Unternehmen faktisch verpflichtend wird oder auch schon ist, was den Handlungsdruck deutlich erhöht und das nicht nur für die Fachabteilung sondern auch für das Management.

00:07:18: Als Fazit würde ich sagen, dass das Patch Management in der Industrie angekommen ist jedoch die Umsetzung noch nicht flächendeckend ausgereift ist und ja es auch noch sehr, sehr große Unterschiede zwischen den Unternehmen gibt.

00:07:34: Danke Björn das bestätigt meinen Eindruck.

00:07:37: ich hatte mal ein Gespräch mit einem Betrieb der dann sagt wenn ich das jetzt tue wie viel Ampullen kann ich dann mehr verkaufen?

00:07:44: Und meine Antwort war dass es die Voraussetzung dafür dass du auch in Zukunft Ampulen verkaufen kannst.

00:07:50: aber das war nicht die Antwort die er hören wollte.

00:07:55: Björn, lass uns mal zur inhaltlichen Diskussion gehen.

00:07:58: Du hast ja schon von so einem Zeitraum gesprochen, in dem Systeme gefährdet sind.

00:08:03: Fenster der Gefährdung glaube ich.

00:08:06: Was versteht ihr darunter?

00:08:08: Ja hier sind wir wieder bei den eben schon angesprochenen Zeitfenster der gefährdungen.

00:08:13: Das beginnt eben nicht erst mit der Veröffentlichung einer Schwachstelle sondern häufig schon deutlich früher nämlich zu einem Zeitpunkt, an dem noch niemand offiziell von der Schwachstelle weiß.

00:08:29: Grundsätzlich kann man diese Gefährdung in vier Abschnitte unterteilen.

00:08:35: Das ist die erste Phase, die Existenz einer Schwachsstelle.

00:08:39: Die zweite Phase das bekannt werden dieser Schwachställe.

00:08:43: Dann gibt es eine Übergangsphase, die dritte und erst mit der vierten Phase wird die Schwachstelle geschlossen.

00:08:53: In Phase eins existieren schwachstellen oft schon lange unentdeckt in Firmenwehr oder Software, dabei ist sie gleichzeitig aber auch schon intern entdeckt oder auch schon bekannt und damit kann sie aber auch aktiv von Angreifern ausgenutzt werden.

00:09:14: Aber es gibt eben noch keine öffentliche Information über die Schwachtstelle.

00:09:20: Das passiert erst mit dem Bekanntwerden, also Phase II.

00:09:24: Die Hersteller oder auch dritte Erkennenschwachstellen.

00:09:30: Die Schwachstellen werden im Anschluss öffentlich gemeldet über einheitliche Kataloge von Schwachsstellen zum Beispiel oder über das Bundesamt für Sicherheit in der Informatik abgekürzt BSI und auch mit dieser Veröffentlichung steigt in der Regel Das Interesse weiterer potentieller Angreifer, was sehr gefährlich wird.

00:09:53: Damit kommen wir in die Übergangsphase, Phase drei.

00:09:58: Es greifen erste Schutzmechanismen wie z.B.

00:10:01: von Antivierensystemen oder auch Intrusion Detection Systeme, die den Netzwerkverkehr oder gewisse Systemaktivitäten überwachen um verdächtige Muster- oder Anomalien zu erkennen.

00:10:16: Und parallel arbeitet der Hersteller auch schon an der Entwicklung und Freigabe eines Patches.

00:10:21: Aber

00:10:24: hier ist wichtig zu verstehen, dass die betroffenen Systeme in dieser Phase eben weiterhin verwundbar bleiben und erst in Phase vier.

00:10:36: Der Patch wird veröffentlicht, der Patch wird auf dem entsprechenden System installiert die Schwachstelle technisch geschlossen.

00:10:48: Das heißt, erst die erfolgreiche Installation des Patches schließt die Schwachtstelle und beendet das Zeitfenster der Gefährdung.

00:10:58: Björn ist es international standardisiert?

00:11:01: Die Listen gibt es!

00:11:02: Die Patches werden katalogisiert, sie sind zu finden.

00:11:06: Das ist das eine.

00:11:07: Jetzt schauen wir auf den betrieblichen Alltag.

00:11:11: wie erfahrt denn ihr oder die Fachleute in den Betrieben ganz konkret von den Schwachstellen, die in ihren installierten Systemen vorhanden sind?

00:11:20: Von den vorhandenen Patches?

00:11:22: und wie organisiert ihr diese

00:11:23: Informationen?".

00:11:25: Grundsätzlich sind viele verschiedene Quellen verfügbar.

00:11:28: Das sind zum einen Informationen, die wir in erster Linie über Hersteller der Software- oder des Automatisierungssystems erhalten.

00:11:38: Es gibt eben schon angesprochenen einheitlichen Kataloge von Schwachstellen.

00:11:44: Hier sprechen wir in diesem Rahmen von Common Vulnerabilities and Exposures, abgekürzt CVAs.

00:11:52: Die bilden aber nur eine kurze Beschreibung der Schwachstelle und als Erweiterung dieser Katalobe und zur Behebung von Schwachtstellen gibt es sogenannte Security Advisories wie das CSAF Das ist das Common Security Advisory Framework.

00:12:15: Das ist kein zusätzlicher Informationskanal, sondern ein offener Standard mit dem eben Sicherheitswarnungen zu schwachstellen in einem einheitlichen und maschinenlesbaren Format veröffentlichten.

00:12:34: Diese Informationen aus dem CSAF können automatisiert bezogen und eben verarbeitet werden.

00:12:42: Als Ergänzung zum CESAF können noch weitere Quellen näher angezogen werden, wie internationale Datenbanken.

00:12:54: Zum Beispiel die National Vulnerability Database, die NVD als Ergänsung eben zum CECAF.

00:13:02: Die NVD erweitert die CVE-Einträge Wiederum um detaillierte Metadaten, wie schwere Grad betroffene Software-Versionen und Schwachstellentypen.

00:13:14: Und eben auch um Referenzen zu Patches.

00:13:20: Darüber hinaus gibt es zum Beispiel vom BSI den Warn-und Informationsdienst mit einem Blick auf die nationale Bedrohungslage.

00:13:34: oder es stellen auch sogenannte Computer Emergency Response Teams, SERT abgekürzt.

00:13:41: Handlungsempfehlungen speziell für OT-Umgebungen zur Verfügung und hier kann man zum Beispiel das SERT des Verbandes der Elektrotechnik und Informationstechnik nennen.

00:13:58: So wir sehen Es gibt viele Quellen die auch miteinander verknüpft werden können.

00:14:04: Aber entscheidend ist nicht die Anzahl der Quellen, die ich nutze sondern deren strukturierte Auswertung und deshalb sollten die gesammelten Informationen immer systematisch mit meinen Essetsystemen und den tatsächlich eingesetzten Software-Ständen abgeglichen werden.

00:14:32: Genau, erst dieser Abgleich erzielt eine gezielte Bewertung ob und wo Handlungsbedarf

00:14:40: besteht.

00:14:42: Björn du hast ja vorhin die vier Phasen erklärt und so als Laie habe ich verstanden wenn die Veröffentlichung war wird es erst richtig gefährlich weil dann natürlich nicht nur die Freunde sondern auch die Feinde diese Schwachstellen erkennen.

00:14:59: das würde dann heißen Wenn ich etwas von einer Schwachstelle und einem Patch erfahre, sofort patchen.

00:15:07: Aber das wird in der Praxis ja so auch nicht

00:15:09: gemacht!

00:15:10: Wie sollte man denn dann vorgehen wenn man von einer Schachsteller und einem Patch erfährt?

00:15:16: Also zunächst sollte geprüft werden ob der Patch für das eigene System überhaupt relevant ist.

00:15:22: Dann müssen gewisse Rahmenbedingungen berücksichtigt werden nämlich sollten Hersteller Freigaben vorliegen um eben Kompatibilitäten und Stabilitäten sicherzustellen.

00:15:33: Und es sollte die Kritikalität der Schwachstelle bewertet werden, um Prioritäten zu setzen.

00:15:41: Dabei sollten eben produktionskritische Systeme besonders priorisiert werden, woin gegen nichtproduktionskritiche Systeme gegebenenfalls etwas länger warten können.

00:15:54: Und anschließend müssen vor der Umsetzung bzw.

00:15:59: vor der Installation weitere Prüfungen erfolgen, das ist zum einen dass die Verträglichkeit eines Patches getestet werden muss auf zb Testsystem und sollten immer Freigabelisten und Herstellerinformationen aktiv genutzt werden um eben Konflikte mit Hardware, Firmware oder Applikation zu vermeiden.

00:16:29: Und mit diesen Informationen kann erst eine Entscheidung über das weitere Vorgehen getroffen werden.

00:16:36: Muss ich sofort patchen, wenn die Risiken eben hoch sind und auch die Tests erfolgreich waren und eine Freigabe besteht vom Hersteller.

00:16:47: Patche ich im nächsten Wartungsfenster, wenn kurzfristige Installationen gewisse Risiken birgt

00:16:56: oder

00:16:57: muss ich eben vorübergehende Ersatzmaßnahmen treffen, wie zum Beispiel eine Netzabschottung falls ein Patch nicht sofort installierbar ist.

00:17:11: Wenn die Entscheidung für das Patchen getroffen wurde sollte strikt nach Plan gepatcht werden.

00:17:18: Das heißt immer beginnen mit weniger kritischen System und eben auch mit vorab durchgeführten Backups.

00:17:29: so Im Anschluss der Installationen der Patches müssen die Systeme immer auf Funktion und Integrität überprüft werden.

00:17:39: Und als letzten Punkt sollten die Ergebnisse eben in der Asset-Inventarisierung aktualisiert werden.

00:17:49: Björn, jetzt sind die Zeiten extrem homogener Prozessleitsysteme bei denen einen Hersteller für alles verantwortlich machen konnte so seit etwa dreißig Jahren vorbei?

00:18:00: Wenn wir drauf schauen, dann ist die Realität in der Prozessleitechnik das verschiedene, um nicht zu sagen verschiedenste Systeme zusammenarbeiten müssen.

00:18:10: Hardware Betriebssystem, Applikation des Herstellers gegebenenfalls auch nochmal ein betreiberspezifisches Software, die oben drauf

00:18:18: kommt.

00:18:20: Jetzt hast du uns beschrieben wie man bei einem Patch sinnvollerweise umgeht?

00:18:25: Wie kann man das denn in dieser Komplexität jetzt noch gemeinsam beherrschbar machen und trotzdem hinterher von einem verfügbaren System ausgehen.

00:18:35: Also die Komplexität entsteht dadurch, dass in Prozessleitsystemen mehrere Ebenen eng voneinander abhängen.

00:18:44: Das sind Betriebssysteme, das sind entsprechende Applikationen der Hersteller und Änderungen auf einer Ebene können unerwartete Ausführungen auf andere Ebenen haben.

00:19:00: Zusätzlich kommt eben auch, dass in Systemen immer unterschiedliche oder sehr häufig unterschiedliche Hersteller damit auch unterschiedliche Patchzyklen und unterschiedliche Freigaben existieren.

00:19:15: Um diese Komplexität beherrschbar zu machen braucht es Struktur, Transparenz und auch klare Regeln.

00:19:23: Und zu Beginn sollten damit Rollen und Verantwortlichkeiten klar definiert werden.

00:19:29: Damit jeder weiß, wer prüft, wer gibt frei und wer installiert den Patch im Anschluss?

00:19:39: Und dann ist eben eine durchgängige Inventarisierung mit Inventarverzeichnissen sogenannten S-Bombs entscheidend.

00:19:52: ist die Abkürzung für Software Bill of Material.

00:19:58: Das sind strukturierte, maschinenlesbare Inventarverzeichnisse aller Komponenten im System und erst dieses Verzeichnis bildet die Basis um Software-Versionen, Abhängigkeiten und Patchrelevanz zu bestimmen.

00:20:18: Und ergänzend dazu ermöglichen strukturierte Sicherheitsinformationen, zum Beispiel über das CSAF einen automatisierten Abgleich von Schwachstellen und Patch-Meldungen mit dem eigenen Inventar.

00:20:37: Darauf aufbauend muss eben die Patch-Kompatibilität sichergestellt werden.

00:20:42: Es dürfen nur freigegebene Kombinationen eingespielt werden Und diese Herstellerfreigaben sollten eben verbindlich berücksichtigt werden.

00:20:52: So bevor Patches dann produktiv ausgerollt werden, sollten Sicherheitsmaßnahmen getroffen werden was wiederum auch einen integralen Bestandteil darstellt.

00:21:05: Patches sollten immer vorab getestet werden und im besten Falle auch in Offline-Tests Umgebungen.

00:21:12: Dann sollten Backups mit nachgewiesenem Restore durchgeführt werden und darüber hinaus, sollte auch im Falle eines Misserfolges definierte Rollbackpläne existieren.

00:21:26: Und dann können eben auch noch so Dinge wie Ride Filter genutzt werden um zum Beispiel Änderungen eines Systems jederzeit rückgängig machen zu können.

00:21:44: Und wenn ein Patch eben noch nicht verfügbar oder freigegeben ist, die Gefahr aber dennoch bekannt ist sollten temporäre Ersatzmaßnahmen eingesetzt werden.

00:21:54: Wie zum Beispiel eine Abschottung des Systems bis eben der Patch verfügbaist.

00:22:02: Pjan das klingt ja alles richtig komplex sehr logisch Aber auch sehr komplex.

00:22:07: Das ist ein großes Aufgabenpaket.

00:22:11: Wir reden jetzt allgemein über patchen.

00:22:15: gilt das auch für Feldgeräte oder beschränkt sich das nur auf Automatisierungssysteme, computergestützte Systeme?

00:22:25: Nein.

00:22:27: Wenn wir beides Patchen nennen sprechen wir über sehr unterschiedliche Prozesse.

00:22:34: der Unterschied liegt vor allem in der Systemebene und in der Nähe zum laufenden Prozess.

00:22:41: Ein Light-System befindet sich typischerweise auf Level II des Purdue Models, das schließt SCADA Systeme PLS Systeme oder auch HMI Systeme ein.

00:22:56: Diese Systeme sind in der Regel Software und Betriebssystemen basiert meist auf Windows oder auf Linux Basis.

00:23:06: Patchen auf Level zwei ist deshalb zwar IT ähnlich, aber unter klaren OT-Bedingungen.

00:23:14: die unterliegen meistens OT Change und Freigabe Verfahren.

00:23:23: Aber in den meisten Fällen handelt es sich um Betriebssystem Updates, Applikationspatches oder auch Security Updats der Light System Software.

00:23:36: Der entscheidende Vorteil ist hier, dass oft Test- oder Stagingumgebungen vorhanden sind.

00:23:44: So das Patches vor dem Einspielen eben geprüft und dann im Anschluss erst gestuft ausgerollt werden können.

00:23:54: Ganz anders sieht das bei Feldgeräten aus.

00:24:00: Level II des Purdue Models.

00:24:02: So hier sprechen wir über Sensoren, Akteuren und Geräte die direkt im Prozess wirken.

00:24:08: Und diese Geräten nutzen häufig auch Embedded-Firmware mit begrenzten Updatemechanismen und kaum Rollbackmöglichkeiten.

00:24:19: Deshalb ist das Patch in diesem Bereich geplanten Stillständen möglich.

00:24:28: Aber das Problem dabei ist, dass es in den seltensten Fällen eins zu eins Testsysteme gibt.

00:24:35: Was das Risiko natürlich zusätzlich erhöht, da potentielle Auswirkungen auf zum Beispiel Regelkreise oder auch Echtzeitfunktionen schwer vorhersehbar sind.

00:24:49: So kann man unter dem Strich sagen, dass Leitsysteme mit guter Planung entsprechenden Wartungsfenstern auch teilweise sogar im laufenden Betrieb ganz gut patchbar sind, aber Feldgeräte hoch risikobehaftet sind.

00:25:08: Neuer Papier spricht sehr ehrlich aus dass das Management von Patchen mit Aufwand verbunden ist.

00:25:16: und welche Möglichkeiten seht ihr denn jetzt nachdem ich euch so intensiv damit beschäftigt habe?

00:25:23: diesen Aufwand nach unten zu bringen und das Management der Patches zu erleichtern.

00:25:29: Da gibt es mehrere zusammenspielende Faktoren, die eine Rolle spielen.

00:25:34: Zunächst sollte eine nicht so große Systemvielfalt herrschen also standardisierte Hardware, standardisierte Betriebssysteme und Light System Stacks aufgebaut sein sodass ich vielleicht einmal testen kann und das dann mehrfach nutzen.

00:25:52: Dann benötigen wir eine sehr frühe Einbindung der Hersteller.

00:25:56: Die Idee ist hier, dass klare Patch- und Freigabestrategien bereits bei der Beschaffung und gegebenenfalls auch schon bei der Vertragsgestaltung eingefordert werden beim Hersteler.

00:26:14: Dann sollte auf Kundenseite eine automatisierte Informationsverarbeitung vorhanden sein Das heißt, ein Abgleich von Schwachstellenmeldungen mit dem eigenen Inventar sollte automatisiert laufen.

00:26:31: Das reduziert den manuellen Analyserauffand erheblich und es sollten auch Sicherheitsinformationen sehr strukturiert genutzt werden wie zum Beispiel über das CSAF.

00:26:47: Dann müssen klare Priorisierungen herrschen darf nicht einfach alles gepatched werden, es sollten risikobasierte Bewertungen durchgeführt werden nach Kritikalität und auch mit dem Fokus auf Prozessauswirkungen.

00:27:09: Mit den Blick auf relevante Systeme.

00:27:13: um die Arbeit dann zu vereinheitlichen sollte es wiederverwendbare Tests und Rollout Konzepte geben.

00:27:21: Und dann muss eben auch noch auf organisatorischer Seite Klarheit herrschen, mit klaren Rollenverteilungen.

00:27:27: Also wer macht was?

00:27:29: Verantwortlichkeiten und Entscheidungswegen.

00:27:32: Und erst durch diese definierten Prozesse wird auch eine Entlastung der Fachabteilungen

00:27:38: entstehen

00:27:39: können.".

00:27:40: Damit kommen wir zu einer persönlichen Frage, Björn.

00:27:44: Was motiviert dich denn als Person sich so intensiv mit Patches und dem Petschen auseinanderzusetzen.

00:27:54: Gerade auch noch vor dem Hintergrund, dass du ja bei dem Engineering-Dienstleister tätig bist und nicht beim Anlagenbetreiber den das ja gemäß EU Gesetzeslage direkt betrifft?

00:28:06: Da ist zum einen natürlich die Motivation aus der Rolle des Dienstleisters.

00:28:11: Wir sind als Dienstleister immer sehr nah am Kunden und deren Anlagen Und damit erleben wir die realen Entscheidungszwänge im Alltag der Unternehmen beziehungsweise auch der Mitarbeiter.

00:28:27: Und da zeigt sich, dass das Patchmanagement mehrere Ebenen gleichzeitig betrifft.

00:28:36: oder das kann die IT sein, das ist in vielen Fällen die OT und auch Automatisierungsabteilungen.

00:28:45: Dann betriffe das die Hersteller uns als Dienstleister.

00:28:51: Und damit entstehen eben Herausforderungen, wo Verantwortlichkeiten und Freigaben und auch Zuständigkeiten aufeinandertreffen.

00:29:03: Ich bin überzeugt dass genau an diesen Übergängen sich durch klare Regelungen und Zusammenarbeit große Verbesserung erzielen lassen durch zum Beispiel eindeutige Rollen und Entscheidungswege oder abgestimmte Freigabe- und Testprozesse, aber auch vor allem durch eine gemeinsame Sicht eben auf Risiken, auf Abhängigkeiten und auch auf Prioritäten.

00:29:36: Weitere Motivatoren sind dann natürlich dass das Patchen einen sehr hohen Effekt auf die reale Risikoreduzierung hat Aber gleichzeitig das Patchmanagement oder mit einem Patchmanagement, der Mitteleinsatz oft überschaubar bleibt.

00:30:00: Eigentlich ist das euer Paper und auch dieses Gespräch ein wichtiges Argument.

00:30:07: Leute kommt in die Namur.

00:30:09: denn also ich stelle mir vor ein kleines Chemiefarmaunternehmen dass drei Betriebsingenieure und drei Betriebe hat,

00:30:18: hat nicht

00:30:18: die Chance ein eigenes Patchmanagement aufzubauen was diese Anforderung erfüllt.

00:30:25: Also da muss man einfach mit anderen nach vernünftigen Wegen suchen und die auch finden.

00:30:32: Björn ihr habt das Papier fertig?

00:30:36: Und eine nette Fee fragt dich hast du drei Wünsche also einen Ar?

00:30:41: nicht schon?

00:30:42: es sollen alle das Papiere lesen und sich dran halten aber da ist trotzdem noch dreifrei.

00:30:47: Was würdest du der Fee aufgeben?

00:30:52: Mein erster Wunsch wäre, dass das CISAF als verbindlicher Standard etabliert wäre und nicht als optionale Komponente geführt würde.

00:31:02: Sodass jeder im Betrieb oder auch Entscheider klare Aussagen zu betroffenen Patch-Versionen, Abhängigkeiten und Status hat.

00:31:19: Mein zweiter Wunsch wäre das in jedem Falle alle Patchprozesse die Sicherheit und die Verfügbarkeit gleichermaßen berücksichtigt also dass nicht um jeden Preis gepatcht wird sondern dass eben Risiko basiert und geplant gepatched wird.

00:31:38: So mein dritter Wunsch wären Automatisierungssysteme, die von vornherein patchfreundlich sind.

00:31:45: So dass die Gefährdung von Sicherheit, Prozessstabilität oder auch Verfügbarkeit deutlich minimiert wird.

00:31:56: Ja Björn vielen Dank!

00:31:57: Das sind eigentlich realistische Wünsche.

00:31:59: das müsste die Fee können.

00:32:01: es werden ja auch genügend Feen

00:32:03: und deren

00:32:04: männliche Bruder zu.

00:32:07: Damit sind wir am Ende unserer heutigen Folge angelangt.

00:32:11: Welche drei Schlüsselbotschaften möchtest du unseren Hörerinnen und Hörern zum Schluss mit auf den Weg geben?

00:32:18: Also meine erste Schlüssel-Botschaft ist, dass Patchen von Automatisierungssystemen kein IT Thema ist sondern ein OT Thema bzw.

00:32:30: sein Anlagenthema.

00:32:31: Patchen betrifft immer die Anlage dem Betrieb und die Produktion also auch Sicherheit verfügbarkeit und Qualität sondern entscheidet man nicht sorgfältig, kann sowohl ein fehlerhaftes Petschen als auch das Nicht-Petschen zu Sicherheitsvorfällen und damit auch zu Produktionsunterbrechungen führen.

00:32:57: Zweite Botschaft ist dass Nicht-petschen auch eine Entscheidung ist jedoch eine mit Konsequenzen.

00:33:05: Das heißt jede Verzögerung stellt ein bewusstes Risikomanagement dar und wenn nichts macht, übernimmt eben auch die Verantwortung für die möglichen Folgen.

00:33:19: Wichtig ist dabei das Bewusst entschieden dokumentiert bei Bedarf auf Alternativen geprüft werden.

00:33:34: Nicht patchen muss nicht zwingend ein Versäumnis sein, sondern das kann durchaus auch ein bewusstes Risikomanagement sein.

00:33:42: Wenn nämlich ein Patch verfügbar ist dass es Themen jedoch hochkritisch ist oder die Test- und Stillstandszeiten aktuell nicht ausreichen.

00:33:55: Dann kann das Risiko durch patchen deutlich größer sein als das aktuelle Sicherheitsrisiko.

00:34:03: Und der letzte Punkt ist, dass eben strukturierte Prozesse wichtiger sind als die maximale Geschwindigkeit beim Patchen.

00:34:16: Das heißt zu schnell eingespielte Patche können zu Inkompatibilitäten oder auch Ausfällen führen.

00:34:28: Es müssen klare Rollen und Verantwortlichkeiten existieren.

00:34:32: Patches müssen in definierten Abläufen geprüft werden.

00:34:36: Es sollten immer inventarbasierte Entscheidungen getroffen werden,

00:34:40: d.h.,

00:34:41: die Nutzung von S-Bombs im Abgleich mit ZISAF Informationen zur Einordnung von Risikodringlichkeit.

00:34:56: Aber ebenso wichtig sind auch Rückfallkonzepte.

00:34:59: Es sollte neben Backups mit geprüftem Restore sollten eben auch klare Rollbackpläne existieren.

00:35:11: Abschließend möchte ich noch sagen, dass nicht der schnellste Patch ist das der Beste ist sondern der der Sicherheit Verfügbarkeit und Qualität gleichermaßen berücksichtigt.

00:35:22: Vielen Dank Björn!

00:35:24: Gerne.