Industrie Security ICS-Umgebungen und Patch-Management: Was tun, wenn Patchen nicht in Frage kommt?
Anbieter zum Thema
Das Portfolio der Cyberbedrohungen hat sich in den letzten Jahren rasant weiterentwickelt. Will man sich als Industrieunternehmen vor den teils verheerenden Folgen eines erfolgreichen Angriffs schützen, muss man Anlagen und Co regelmäßigen Sicherheitsupdates unterziehen. Doch was, wenn das nicht so einfach geht?

Unternehmen sollten angesichts der veränderten Situation die Gewichtung ihrer Sicherheitsmaßnahmen überdenken. Inzwischen kommt der Identifizierung, Analyse und Bewertung von Cyberrisiken ein deutlich höherer Stellenwert zu, wenn man Sicherheitsvorfälle vermeiden will. Dabei werden die Begriffe Patch-Management und Vulnerability-Management oft nahezu deckungsgleich verwendet. Zu Unrecht.
Nutzen und Risiken des Patchens (und des Patch-Managements)
Bevor man sich entscheidet, ob man einen Patch installiert oder nicht, sollte man verstehen, welcher Nutzen, aber auch welche möglichen Risiken damit verbunden sind. Lohnt sich der Aufwand?
Pro
Normalerweise denken Unternehmen ans Patchen, wenn es notwendig ist, Sicherheitsmängel in einem Betriebssystem oder einer Anwendung zu beheben. Darin liegt aber nicht der einzige Nutzen. Viele Hersteller veröffentlichen Patches, um die Stabilität der Anwendung zu verbessern. Diese Art von Verbesserungen ist ein starkes Argument für die Bereitstellung von Patches in einer ICS-Umgebung (Industrial Control Systems), denn hier sind Stabilität und Verfügbarkeit die kritischen Größen. Und schließlich helfen Patches bei der Behebung spezifischer Bugs oder Fehler in bestimmten Anwendungen, was wirtschaftlich von Vorteil ist.
Contra
Neben diesen augenfälligen Vorteilen gibt es aber auch eine Reihe von Gründen, die gegen das Patchen sprechen. Sie hängen vornehmlich damit zusammen, wie Risiken auf Seiten der IT gegenüber der OT wahrgenommen werden. Für die IT überwiegt der Nutzen des Patchens eindeutig die Nachteile. Der Verlust von Daten ist ganz klar das größere Problem verglichen mit Ausfallzeiten im Netzwerk. Auf der OT-Seite hat demgegenüber die Systemverfügbarkeit größere Bedeutung. Beide Seiten bewerten das Risiko im Verhältnis zum Nutzen also recht unterschiedlich.
Wenn man sich auf ICS-Umgebungen konzentriert, besteht ein Hauptrisiko darin, dass ein kritisches Netzwerk oder eine kritische Komponente aufgrund eines fehlerhaften oder beschädigten Patches ausfallen könnte. Patchen ist zudem extrem zeitaufwändig und wird in einigen Fällen zur Vollzeitbeschäftigung, wenn man bedenkt, dass durchschnittlich täglich über 15 neue Schwachstellen identifiziert werden.
Ein weiterer Faktor sind die mit dem Testen der veröffentlichten Patches verbundenen Kosten. Auch diese sind für IT und OT unterschiedlich hoch. Beide Seiten brauchen Entwicklungslabore für die zu testenden Patches, bevor diese auf Produktionssysteme übertragen werden können. In der OT-Welt muss man dazu Hardware anschaffen, die die realen Produktionssysteme nachahmt. Im Gegensatz zur IT-Welt, wo man die Produktionssysteme mit Hilfe virtueller Umgebungen nachstellen kann. Die Logistik und die mit der Replikation von OT-Produktionssystemen verbundenen Kosten überwiegen bei weitem die Größenordnungen von IT-Systemen. Darüber hinaus kann die IT-Abteilung automatisierte Patch-Management-Lösungen verwenden, mit denen sich die Zahl der erforderlichen Mitarbeiter und Arbeitsstunden erheblich verringern lässt. In der OT liegt der Fall leider anders. Patches müssen auf jedem einzelnen Gerät getestet werden, und höchstwahrscheinlich muss sich ein OT-Team darauf verlassen, dass der Hersteller die Updates selbst liefert. Die Kosten überwiegen gegenüber dem Nutzen, ganz anders als in der IT.
Dazu kommen die End-of-Life-Produktzyklen (EOL) der Hersteller.
Auf der IT-Seite ein geringeres Risiko. Testen und Upgraden eines Betriebssystems ist beispielsweise in virtuellen Umgebungen sehr viel einfacher. Kombiniert mit der geringeren Sorge um mögliche Ausfallzeiten, sind EOL-Probleme auf der IT-Seite leichter behebbar als in der OT. In OT-Umgebungen existieren Produktionssysteme nicht selten seit zwanzig oder mehr Jahren. In den meisten Fällen wurden diese Systeme vermutlich noch nie upgegradet oder gepatcht. Das Risiko eingehen, ein System, das seit Jahrzehnten fehlerfrei funktioniert, zu Patchen? Besser nicht.
Das Motto „Es geht nicht darum, ob man gehackt wird, sondern wann man gehackt wird“ verdeutlicht allerdings die Gefahr, die darin liegt, einfach gar nichts zu tun. Das damit verbundene Risiko sollte man sich auch in OT-Abteilungen und Unternehmen genauer ansehen und gegen die Wahrscheinlichkeit eines unerwarteten, unkontrollierten Herunterfahrens von Systemen abwägen - im Gegensatz zu einem kontrollierten, manuellen, segmentierten Patch-Prozess.
:quality(80)/images.vogel.de/vogelonline/bdb/1514600/1514608/original.jpg)
Industrial Security
IT vs. OT - Unterschiedliche Ziele, die Sie in der Industrial Security kennen sollten
IT versus OT
Um die Unterschiede in der Risikowahrnehmung und Priorisierung zwischen IT und OT besser zu verstehen, hilft es, aus beiden Perspektiven einen Blick auf die bekannte CIA-Triade (Confidentiality, Integrity, Availability) zu werfen.
Für die IT-Seite hat Vertraulichkeit (Confidentiality) oberste Priorität. Der Verlust von wertvollen personenbezogenen Daten wie Kunden- oder Mitarbeiterinformation hat für jedes Unternehmen schwerwiegende Folgen, wie zum Beispiel finanzielle Probleme, Rufschädigung sowie behördlich verhängte Strafen.
Integrität (Integrity) ist das zweitwichtigste Anliegen von IT-Unternehmen. Branding und Kundenbindung werden massiv beeinträchtigt, wenn ein Unternehmen einen Datenschutzvorfall oder den Diebstahl geistigen Eigentums einräumen muss. Ein Vorfall, der die Integrität beeinträchtigt, führt fast zwangsläufig zu finanziellen Verlusten - sei es durch Geldstrafen oder Umsatzverluste.
Die wirklich letzte Sorge gilt der Verfügbarkeit (Availability). Unternehmen bemühen sich darum, die Systemverfügbarkeit aufrechtzuerhalten, insbesondere bei Systemen, die kundenorientiert sind. Sollte ein System trotzdem ausfallen, sind die Auswirkungen auf die MTTR (Mean-Time-to-Repair) in IT-Umgebungen aber wesentlich geringer als bei OT-Unternehmen. Das Wiederherstellen eines Systems aus einem virtuellen Backup ist deutlich einfacher, als ein physisches Gerät aus der Produktion zu nehmen und durch ein neues zu ersetzen. Das führt normalerweise dazu, dass sich Kosten und Ausfallzeiten erhöhen.
Demgegenüber hat die Verfügbarkeit für OT-Abteilungen und Unternehmen oberste Priorität. Das ist völlig verständlich, denn die mit einem Systemausfall verbundenen Kosten betragen selbst bei kurzen Ausfallzeiten, Millionen von Dollar oder Euro. Ganz zu schweigen davon, dass sie erhebliche Auswirkungen auf die Gesellschaft als Ganzes haben; beispielsweise der Ausfall von Stromnetzen. Darüber hinaus behindern außer Betrieb gesetzte OT-Systeme andere Unternehmen oder Branchen, da die Vernetzung und gegenseitige Abhängigkeit zwischen Produkten und Dienstleistungen ausgesprochen stark ausgeprägt sind.
Integrität hat aus den gleichen Gründen - Branding, Einnahmeverluste und Bußgelder - wie in der IT die zweithöchste Priorität.
An letzter Stelle der Prioritätenliste steht die Vertraulichkeit (obwohl sie nicht als geringfügig betrachtet werden sollte). In der Tat kann der Verlust sensibler oder geheimer Daten aufgrund von Industriespionage noch schlimmere Folgen für ein Unternehmen haben als der Verlust personenbezogener Daten.
Trotz all dieser Unterschiede haben IT und OT eine gemeinsame Basis - die Sicherheit. Und in vielen Bereichen gibt es Überschneidungen wie zum Beispiel beim Asset Discovery, der Schwachstellenbewertung und Richtlinienverwaltung, der Change Detection, der Konfigurationsbewertung und der Protokollverwaltung.
Bei Unternehmen mit zunehmend konvergenten OT- und IT-Netzen, bei denen beide Einheiten im Wesentlichen unter einem technischen Dach arbeiten, ist es leicht zu verstehen, welche Vorteile SIEM-Tools (Security Information and Event Management) für die Analyse aller OT-Daten bieten. Die IT-Abteilung verfügt bereits über ein zentralisiertes Betriebsteam und die erforderlichen Werkzeuge, um schnell, potenziell bösartige Muster zu identifizieren und das OT-Team zu alarmieren. Das OT-Team muss sich dann nur mit einem einzelnen Ereignis befassen, anstatt sich mit dem sprichwörtlichen Grundrauschen auseinanderzusetzen.
:quality(80)/images.vogel.de/vogelonline/bdb/1700700/1700766/original.jpg)
Management Statement
„Ein einheitlicher Standard nimmt die Komplexität aus der Konstruktion“
Was tun, wenn man nicht Patchen kann?
Wir haben die Unterschiede zwischen IT und OT sowie die Risiken und Nutzen von Patches in ICS-Umgebungen beleuchtet. Auf dieser Basis lässt sich besser nachvollziehen, warum man das Einspielen von Patches unter bestimmten Umständen vermeiden sollte. Was kann man in einem solchen Fall aber sonst noch tun?
Man muss zunächst das Patch-Management als Teilmenge des Vulnerability-Managements betrachten. Das Vulnerability-Management ist keine eigenständige Scan-und-Patch-Funktion. Es ist ein ganzheitlicher Ansatz, um identifizierte Schwachstellen in der eingesetzten Hardware und Software proaktiv zu beheben. Beim Vulnerability Management geht es darum, fundierte Entscheidungen zu treffen und zu priorisieren, welche Schwachstellen wie zu beheben sind. Dazu bettet man interne Telemetrie-Hooks in alle betroffenen Systeme ein und nutzt zusätzlich externe Hooks für Bedrohungsinformationen aus anderen Quellen.
Wenn ICS-basierte Unternehmen nicht patchen können, sollten sie mindestens die folgenden Punkte abarbeiten:
- 1. Bei der Asset-Analyse oder -Discovery geht es zunächst um eine genau Bestandsaufnahme aller Systeme in einer Umgebung. Dieser Prozess wirft unter Umständen eine andere grundlegende Sicherheitsfrage auf: Brauchen wir tatsächlich all diese Systeme oder verschwenden wir unnötig Zeit damit, Assets zu sichern, die wir nicht zwingend benötigen?
- 2. Perimeterschutz dient dazu, ein Unternehmen vor physischen und digitalen Angreifern zu schützen. Dazu zählt alles von Firewalls bis hin zu Zugangskontrollen.
- 3. Eine anschließende Segmentierung bringt etliche Vorteile mit sich, wenn man die typischen Vorwärtsbewegungen eines Angreifers im Netzwerk und den Sicherheitsvorfall als Ganzes eindämmen will.
- 4. Die Protokollverwaltung wird hier nicht als IDS-Tool oder zur Erkennung von Veränderungen verwendet, sondern dient der Suche nach auffälligen Bewegungen innerhalb des Unternehmensnetzes, um potenzielle Angriffe zu erkennen.
- 5. Eine Schwachstellenbewertung dient der Ermittlung potenzieller Schwachstellen und zur Identifizierung der Risikosituation jedes einzelnen Systems. Nach Abschluss des Schwachstellen-Scans wird jeder Schwachstelle ein Score zugeordnet. Dieser Wert basiert auf der Korrelation zwischen dem Aufwand, den es mit sich bringt, die Schwachstelle auszunutzen und dem Risiko, das von den damit verbundenen Berechtigungen ausgeht. Je leichter man eine Schwachstelle ausnutzen kann und je höher die damit verbundenen Privilegien sind, desto höher ist der Risiko-Score.
- 6. File Integrity Monitoring (FIM) überwacht die tatsächlichen Veränderungen innerhalb eines ICS-Unternehmens. Während die zuvor genannten Schritte hauptsächlich externe Bedrohungen und die Überwachung abdecken, wirft FIM einen Blick in das Innere des Unternehmens. File Integrity Monitoring setzt Aktivitäten oder Bewegungen mit tatsächlichen Änderungen in Beziehung. Ziel ist es, das Grundrauschen weiter zu reduzieren und im Bedarfsfall Alarm auszulösen.
* Maximilian Gilg arbeitet als Systems Engineer bei Tripwire.
(ID:46576399)