Keine Frage des Budgets:Patch-Lücken bergen umfangreiche Risiken

Wir alle sind uns der unbequemen Wahrheit bewusst, dass IT-Umgebungen löchrig sind und folglich von einem ausreichend ambitionierten Angreifer kompromittiert werden können. Dies gilt so gut wie unabhängig von der jeweiligen Unternehmensgröße oder dem aufgewendeten IT-Budget.

Daher sollten sich IT-Verantwortliche die Fragen stellen: Warum ist das so? Was macht es letzten Endes so schwierig, eine sichere Umgebung zu schaffen? Ein wichtiger Einflussfaktor ist die „Patch-Lücke“ (beziehungsweise Mehrzahl – die Patch-Lücken)

Für eine sichere Umgebung müssten die IT-Verantwortlichen „nur“ Folgendes tun:

• Software schreiben, die völlig frei von ausnutzbaren Fehlern ist.
• Diese Software fehlerfrei installieren und konfigurieren.
• Ein weiterer Punkt ist, sicherzustellen, dass ein Softwarehersteller alle Fehler findet (oder darüber informiert wird), bevor das Angreifer tut.
• Der Anbieter muss zudem ausreichend Zeit haben, einen Patch zu erstellen, zu testen und zu veröffentlichen, bevor ein Angreifer die Lücke findet und ausnutzt.
• Sobald ein Patch verfügbar ist, installiert ihn der Kunde.

Ist das machbar? Dazu gilt es die einzelnen Punktedetailliert zu betrachten.

Fehlerfreie Software

Inzwischen wissen wir: Fehlerfreie Software existiert nicht. Selbst die besten Software-Teams und Entwickler können keine durchgehend fehlerfreie Software produzieren. Es gibt allerdings reichlich Möglichkeiten, Fehler zu reduzieren: die statische Codeanalyse, Pair Programming, das Überprüfen von Code usw.

Es gibt sogar Techniken zur formalen Zertifizierung, die, theoretisch jedenfalls, nahezu fehlerfreie Software hervorbringen. Bisher kommen sie aber nur im akademischen Bereich zum Einsatz. Wirft man einen Blick auf die zahlreichen Sicherheitslücken in Produktionssoftware, erkennt man schnell, dass sich wenig zum Besseren verändert hat. Gewiss ist lediglich, dass es keine fehlerfreie Software gibt – also ohne Fehler, die sich ausnutzen lassen. Wir brauchen also zwingend Lösungen für die unter Punkt 2 bis 5 angesprochenen Einflussfaktoren.

Perfekte Konfiguration

Viele Analysten benennen Fehlkonfigurationen als eine der Hauptursachen für Kompromittierungen: Hier ist ein Beispiel. Softwarehersteller machen es mit verwirrenden Optionen, ungünstig gewählten Standardeinstellungen und unzureichender Dokumentation nicht unbedingt besser.

Selbst wenn es gelingt, eine wenigstens größtenteils fehlerfreie Software zu entwickeln, treten spätestens in diesem Stadium weitere Herausforderungen auf den Plan. Hilfreich ist es, wenn Softwareanbieter ihre Richtlinieneinstellungen im Sinne der Sicherheit aufbauen und beschreiben – und die Standardeinstellungen diesen Vorgaben folgen.

Die Guten finden die Fehler zuerst – hoffentlich

Jedes (seriöse) Unternehmen investiert nicht unerheblich in die Suche nach Sicherheitslücken: Codeüberprüfungen, Schwachstellen-Scans, Red-Team-Tests usw. Das treibt zwar den Preis einer Software in die Höhe, wird aber in die ursprüngliche Kostenkalkulation einbezogen.

Dieser Prozess wird allerdings dadurch erschwert, dass in den meisten modernen Softwarelösungen in großem Umfang Open-Source-Bibliotheken von Drittanbietern genutzt werden (die wiederum andere Bibliotheken einbetten). Und die haben ihre eigenen Schwachstellen. Ein Beispiel dafür ist die Log4J-Sicherheitslücke.

Zum Glück gibt es eine große Community von White Hat Hackern, die sich ebenfalls auf die Suche machen und Anbieter informieren. Nichtsdestotrotz gelingt es Angreifern immer wieder, Lücken zu finden, die sich vielfältig und mit teils schwerwiegenden Folgen ausnutzen lassen.

Entwickeln Sie einen Patch

Wenn ein Sicherheitsexperte einen Fehler findet und ihn dem Hersteller meldet, ist das noch nicht das Ende der Geschichte: In der Regel warten Experten etwa 90 Tage, bevor sie ihre Ergebnisse veröffentlichen. Das bedeutet im Klartext, dass der betreffende Anbieter das Problem reproduzieren, eine Lösung finden, den Patch erstellen, testen und dann innerhalb von 90 Tagen bereitstellen muss.

Bei simplen Problemen mag das keine große Sache sein. Bei komplexen Fehlern, die mehrere miteinander interagierende Komponenten betreffen, während gerade andere, wichtige Projekte im Gange sind… kann es knapp werden. Laut Infosec liegt „die durchschnittliche Zeit, die für das Patchen einer Schwachstelle benötigt wird, zwischen 60 und 150 Tagen“. Oder anders ausgedrückt, einige Patches stehen mit an Sicherheit grenzender Wahrscheinlichkeit nicht rechtzeitig bereit.

Aber müssen Angreifer nicht zunächst selbst einen Exploit-Code entwickeln? Das stimmt, aber sie brauchen dafür nachweislich immer weniger Zeit. Es gibt viele Fälle, in denen ein Patch veröffentlicht wurde und Angreifer diesen vermutlich zurückentwickelt haben. Von den darauf basierenden Exploits waren viele innerhalb von nur 30 Tagen fertig, manche sogar innerhalb weniger Stunden.

Patchen Sie Ihre Software – schnell!

Das Dumme ist, dass man nichts von all dem kontrollieren kann. Was sich jedoch kontrollieren lässt, ist, wie schnell Sie selbst die Software in Ihrer Umgebung patchen. Angesichts dessen wie rasant Angriffe sich ausbreiten, haben Sie dafür eventuell nur Stunden oder höchstens ein paar Wochen Zeit. Und selbst wenn der Hersteller einen Fehler behebt, bevor ein Angreifer ihn findet, geht der Trend dahin, dass Angreifer Patches zurückentwickeln, sobald sie veröffentlicht werden. Dann stehen entsprechende Exploits oft innerhalb von Stunden oder Tagen zur Verfügung.

Glücklicherweise patchen sich die meisten Betriebssysteme und Browser selbst recht zuverlässig. Das eigentliche Risiko liegt eher bei den Anwendungen und Erweiterungen von Drittanbietern, die auf diesen Plattformen laufen. Bevor Sie Patches einspielen, sollten Sie auf jeden Fall einige Tests durchführen, um sicherzustellen, dass die Patches keinen Schaden anrichten. In einer idealen Welt würden alle Patches automatisch eingespielt, und zwar ohne das Risiko von Inkompatibilitäten mit einer älteren Software.

Davon sind wir aber noch weit entfernt, und man sollte zumindest einige Anwendungen manuell überprüfen. Dieser Prozess sollte so einfach wie möglich vonstatten gehen. Denn selbst dann klafft eine große Lücke zwischen der Bereitstellung von Patches und ihrer tatsächlicher Nutzung.
Eine aktuelle Analyse der Patching-Gewohnheiten der eigenen VIPRE-Nutzerbasis hat ergeben, dass nur 17 Prozent der aufgedeckten Sicherheitslücken innerhalb einer Woche gepatcht wurden. Und das selbst mit einer automatisierten Management-Lösung. Laut Branchenstudien lassen Unternehmen durchschnittlich 47,6 Tage bis zum Patchen selbst kritischer Sicherheitslücken vergehen. Bei weniger kritischen dauert es noch deutlich länger.

Es gibt nicht uneingeschränkt viele Möglichkeiten, wie man den Lebenszyklus der Softwareentwicklung und -bereitstellung kontrollieren kann. Die Bereitstellung von Patches für installierte Software gehört aber definitiv dazu. Deshalb ist es so wichtig, den Patching-Prozess so schnell und schmerzlos wie möglich zu gestalten, etwa über entsprechende Patch- und Vulnerability Management-Lösungen.

David Corlette ist Vice President Of Product Management bei der VIPRE Security Group.

VIPRE Security Group