Windows Server 2012 und der SQL-Server 2012 werden supportseitig von Microsoft bald eingestellt. Ein Grund für uns, genauer hinzusehen, wie sich Software ohne Hersteller-Support auf das Sicherheits-Niveau im Unternehmen auswirkt.
Kurzer Abriss zum IST-Zustand
Der Einsatz von aktueller (Betriebssystem)-Software gehört zum quasi Standard für alle Unternehmen, weshalb große Anstrengung unternommen wird, diese aktuell zu halten. Das ist eine Aussage, die glücklicherweise “eher” zutrifft, nur eben nicht überall.
Der Einsatzfall, oft branchenspezifisch, entscheidet unter anderem, wie mit der Aktualität von Software umgegangen wird. IT-affine Unternehmen ziehen die Software-Version schneller hoch als andere. Kommt man in Unternehmen, die nicht nur IT einsetzen, sondern beispielsweise auch Software und Systeme, die wir zur operationalen Technik (OT) zählen, sieht das anders aus. Hiermit sind Automatisierungs- und Industrieanlagen gemeint. Also Systeme, die anders agieren als wir das aus der “klassischen IT” kennen. Diese Systeme können sich teilweise nicht selbst verteidigen und werden auch nicht in den gewohnten Release-Zyklen mit Updates versorgt.
Für den Bereich der kritischen Infrastruktur beobachten wir, dass hier ein Umdenken stattfindet. Hersteller haben bereits Informations-Sicherheits-Systeme eingeführt bzw. sind ggfs. mitten in der Einführung. Diese Systeme werden in der Regel nach ISO 27001 zertifiziert und sorgen dafür, dass der Hersteller einen genauen Blick auf Software und Schwachstellen hat. Diesen Blick gab es früher auch schon, doch durch die Einführung eines solchen ISM-Systems gibt es einen Dokumentations-Zustand, der an die Kunden weitergegeben wird. Oftmals mit der klaren Empfehlung, Updates zeitnah einzuspielen, um dem evaluierten Risiko gerecht zu werden.
Wirft man einen Blick in Richtung des Gesundheitswesens, stellt man fest, dass es nicht nur die Betreiber-Perspektive ist, die darüber entscheidet, ob ein Software-Update eingespielt wird. Medizintechnische Geräte dürfen beispielsweise nur dann eingesetzt werden, wenn sie eine entsprechende Zertifizierung aufweisen. Bestandteil der Zertifizierung ist unter anderem auch die Definition der Software- und Patch-Stände. Damit einher geht, dass eine Aktualisierung ohne weiteres nicht möglich ist, denn die Zertifizierung des Geräts würde dadurch ungültig. Gängige Praxis ist deshalb Geräte, die nicht ohne weiteres aktualisiert werden können, innerhalb der Gesamtinfrastruktur abzuschotten. Die Lösung sieht hier in der Regel Segmentierung und ein Firewall-Konzept vor, das aktuelle von “nicht gepatchten” Systemen trennt. Ggfs. werden über die Segmentierung und die inneren Firewalls auch verschiedene Netzwerk-Zonen erstellt. Solche, in denen Prozess-Daten verarbeitet werden und solche, in denen die Daten aus unsicheren in sichere Netzwerk-Bereiche transferiert werden.
Auswirkungen von veralteter Software im Netzwerk
Begeben wir uns in die Vogelperspektive und betrachten unsere Gesamtnetzwerk, dann lässt sich bestenfalls erahnen, dass der Einsatz von veralteter Software negative Auswirkungen auf unser Gesamtrisiko haben kann. Diese Behauptung können wir auf dieser Flughöhe wahrscheinlich nicht direkt beweisen, aber sie ist immerhin einleuchtend.
Die Annahme, dass veraltete Software unweigerlich zu einem höheren Risiko führt, geht mit der Tatsache einher, dass der Hersteller aktuelle Software bei neu identifizierten Sicherheits-Lücken mit Updates versorgt. Eine ältere Software einzusetzen ist deshalb nicht per se gefährlich. Vielmehr kommt es darauf an, an welcher Stelle sie eingesetzt wird (siehe Gesundheitswesen) und welche Schnittstellen dieses System in unser Gesamtnetzwerk hat.
Ein veraltetes System an einer ISDN-Leitung, übersät mit Schwachstellen ohne eine einzige Integration in unser Netzwerk, ist in der Theorie erstmal kein Problem. Spannend ist also, wie die Integration dieser Systeme aussieht und welche Auswirkungen etwaige Schwachstellen auf unser Netzwerk und die Informations-Sicherheit haben.
Lageplan
Bei der Betrachtung von Software, bekannten bzw. nicht bekannten Schwachstellen und der Tatsache, dass sich der Hersteller, mehr oder weniger liebevoll, um die Aktualität der Software bemüht, hilft ein Lageplan.
Wo stehen welche Systeme, wie sind sie integriert, welche Schwachstellen haben sie. Klar ist auch, dass sich das Risiko durch Nichts tun über die Zeit erhöht. Oder anders formuliert: Software, die vor einer Woche seitens des Herstellers abgekündigt wurde, hat ein anderes Risiko als Software, die seit 2 Jahren nicht mehr mit Sicherheits-Updates versehen wurde.
Sicherheitsbewertung
Am Beispiel securiCAD betrachten wir den Angriffsweg aus dem Internet in Richtung Web-Server und verschiedene Datenbank-Server, die mit unterschiedlichen Patch-Ständen versehen sind.
securiCAD erlaubt uns mit dem Wert time to compromise abzuleiten, wie viele Tage ein Angreifer statistisch gesehen benötigt, um einen Angriff durchzuführen. Gleichzeitig zeigt uns der Angriffsweg, auf welche Verbesserungsmaßnahmen wir uns fokussieren sollten.
Nachfolgende Grafik illustriert, welche Angriffs-Exposition (%) die Systeme haben. Es gilt: Je höher der Wert, desto schlechter.
Über die Angriffswege lässt sich erkennen, welche technischen Wege der Angreifer gehen kann, um seine Ziele zu korrumpieren, also zu übernehmen. Als Ziele sind die Server mit unterschiedlichem Patch-Stand sowie der Web-Server ausgewählt.
Wir sehen, dass der Angreifer aus dem Internet kommt, das ist die Annahme für die Angriffs-Simulation. Und wir sehen, dass die Systeme mit unterschiedlichem Patch-Stand nicht Teil des Angriffsweges sind.
Diese Tatsache erklärt, warum es für die aktuelle Risikoableitung unerheblich ist, welchen Patch-Stand die Systeme haben. Wir erkennen wieder einmal, dass e auf die Perspektive ankommt, durch die wir die Dinge betrachten.
Der Beitrag ist keinesfalls ein Aufruf zum Auslassen von Sicherheitsupdates. Doch er soll anregen, dass nicht jedes Sicherheits-Update an jeder Stelle die gleichen Auswirkungen hat. Prioritäten zu setzen schafft auch hier die Sicherheit an wichtiger Stelle zuerst.