Das ICS-Computer Emergency Response Team (ICS-CERT) der US-Regierung gibt Warnungen hinsichtlich bekannter Sicherheitslücken in Industrieprodukten heraus. In dem Jahrzehnt vor der Entdeckung von Stuxnet veröffentlichte ICS-CERT fünf Sicherheitswarnungen, die drei Hersteller betrafen. 2011 wurden 215 Sicherheitslücken publik gemacht und es gab 104 Sicherheitswarnungen, von denen 39 Hersteller betroffen waren. Bis Ende 2012 wurden 569 Scada/ICS-Sicherheitslücken aufgedeckt. Diese Besorgnis erregende Tendenz wurde von Kevin Hemsley von ICS-CERT bestätigt: \“2011 erlebte ICS-CERT einen Anstieg der bekannt gewordenen Sicherheitslücken in ICS-Produkten (Industrial Control System) um 753%. Die koordinierte Aufdeckung solcher Lücken nimmt rasch zu, aber ebenso die Zahl der unerwarteten oder vollständigen Offenlegungen. Insgesamt nimmt die Geschwindigkeit, in der ICS-Sicherheitslücken aufgedeckt werden, dramatisch zu.\“ Der Umgang mit diesen Schwachstellen ist eine wichtige Frage.
Tretmühle: Patches für Industriesicherheit
In der IT-Welt werden Sicherheitslücken durch regelmäßige Softwarepatches behoben – typische Computer benötigen mindestens einmal pro Woche neue Sicherheitsupdates, die immer mit einem Neustart des Systems verbunden sind. Für die Nutzer von Steuerungssystemen sind so häufige Produktionsstillstände wohl kaum tolerierbar. Was aber, wenn der Patchzyklus verlängert und z.B. mit den jährlich anfallenden Wartungsaktivitäten verknüpft würde? 2008 war ich an der Analyse eines Prozesssteuerungsnetzwerks (PCN) einer Raffinerie beteiligt, zu dem 85 Rechner gehören. Wir konnten nur die Daten für 78 sammeln, stellten aber fest, dass insgesamt 272 separate Prozesse im Einsatz waren. Eine Recherche in der National Vulnerability Database (NVD) ergab, dass 48 dieser Prozesse eine oder mehrere schwerwiegende Sicherheitslücken aufwiesen. Über das gesamte Steuerungsnetzwerk der Raffinerie hinweg gab es 5.455 bekannte Sicherheitslücken, also durchschnittlich 70 pro Maschine.
Probleme beim Patchen
Eine Untersuchung von Patches für bereits freigegebene Betriebssystemsoftware deckte auf, dass zwischen 14,8 und 24,4% der Korrekturen fehlerhaft waren und negative Folgen für den Endbenutzer hatten. Davon führten 43% zu Abstürzen, Hängern, Datenverfälschungen oder Sicherheitsproblemen. Darüber hinaus behoben die Patches nicht immer die Sicherheitslücken, für die sie gedacht waren. 2011 stellte ICS-CERT fest, dass 60% der Patches die bekannten Sicherheitslücken in Steuerungssystemen nicht beheben konnten. Die meisten Patches erfordern eine Unterbrechung des Produktionsprozesses, aber einige beenden sogar die Funktionen, die für das Gesamtsystem unverzichtbar sind. So war z.B. eine Sicherheitslücke, die der Stuxnet-Wurm nutzte, ein festverdrahtetes Passwort in der WinCC SQL-Datenbank von Siemens. Das Unternehmen wurde dafür kritisiert, dass es nicht schnell genug ein Patch veröffentlichte, mit dem das Passwort entfernt werden konnte. Kunden, die das Passwort manuell änderten, fanden heraus, dass systemkritische Funktionen von diesem Passwort abhängig waren. Diese Lösung machte also alles noch schlimmer!
Wenn es keine Patches gibt
Nach Aussage von McBride7 wurden seit Januar 2012 für weniger als die Hälfte der bei ICS-CERT bekannten Sicherheitslücken Patches angeboten. Es gibt viele Faktoren, die einer schnellen Bereitstellung von Patches entgegenstehen. So berichtete mir ein großer ICS-Anbieter von Sicherheitslücken in einem embedded Betriebssystem, auf die man beim Test eines Produkts stieß. Dieses System war ein Third Party-Produkt, dessen Hersteller sich weigerte, die Schwachstellen zu beheben. Hier standen der ICS-Anbieter und seine Kunden vor einer Situation, in der Patchen nicht möglich war.
