Patching Panorama 1

2011 hat zahlreiche Verletzlichkeiten ans Licht gespült und entsprechenden Handlungsbedarf in Sachen Patchen ausgelöst. Wir betrachten hier eine Gruppe von Verletzlichkeiten, die nicht durch die Windows Update-Mechanismen abgedeckt sind.

In einem hochschultypischen Szenario wird untersucht, welche Patchingnotwendigkeiten durch folgende vier Applikationen erzeugt werden: Flash Player 10.x, Adobe Reader 9.x, Sun Java JRE 1.6.x / 6.x und Firefox ausgehend von 3.6. Patchen im allgemeinen Sinn umfasst dabei Patchen als Komponentenersatz wie auch Produkteupgrades, die dem Schliessen von Verletzlichkeiten dienen.

Relevante Patches…

Wir betrachten hier nur eine Auswahl von Verletzlichkeiten und Patches, nämlich relevante Patches relevanter Applikationen. Bei Adobe Reader, Flash und Java haben wir die Patches für Verletzlichkeiten gezählt, die von secunia als „Highly critical“ oder „Extremely critical“ eingestuft worden sind. Bei Firefox sind wir davon ausgegangen, dass die Versions-Upgrades je mit einer oder mehreren kritischen Verletzlichkeiten korrelieren.

… relevanter Anwendungen

Die vier Anwendungen können aufgrund folgender Kriterien als besonders relevant gelten. 1) DriveBy Infektionen via Browser war 2011 der häufigste Kompromittierungskanal. 2) Browser und browsernahe Strukturen stehen unter besonderem Druck, weil sie häufig mit Objekten aus dem Internet in direkten Kontakt kommen 3) weite Verbreitung.

Zahl und zeitliches Muster

Aufgrund der genannten Kriterien konnten 27 Patchingnotwendigkeiten identifiziert werden. Die Zahl und das zeitliche Muster weisen auf die Probleme, die ein rasches konsistentes Patchen in gemanagten Umgebungen aufwirft.

 Applikationen

Das folgende Diagramm zeigt die Verteilung nach Produkten. Es macht deutlich, dass jede zusätzliche exponierte Applikation sowohl zurätzliches Risiko wie auch zusätzlichen Patch-Bedarf auslöst.

 * * * * *

Die Bulletins können bei Secunia produkteweise angesehen werden – unter dem Menupunkt Advisories / Advisories by Product.

Ein nicht enden wollender Strome von Verletzlichkeiten wird Tag für Tag publiziert. Das zeigt ein Blick auf die entsprechende Page von secunia, wo täglich zehn bis zwanzig aufgelistet werden. Wie sieht der Lebenslauf einer Verletzlichkeit aus?

Wir betrachten hier nur Verletzlichkeiten in Design und Implementierung von Betriebssystem und Programmen. Verletzlichkeiten werden beim Schreiben von Software in den Code eingebracht – im Normalfall ohne Absicht. Es ist durchaus möglich, mit einem LifeCycle Management die Zahl der Fehler pro Million Codezeilen substantiell zu reduzieren. Vollständig eliminieren lassen sich Fehler nicht. Nicht alle Verletzlichkeiten erleben die gleiche Geschichte.  Wir können vier Szenarien unterscheiden.

Latent. Eine Verletzlichkeit existiert – aber niemand weiss davon. In jedem der gängigen Betriebssysteme sind hunderte bis tausende von unbekannten Verletzlichkeiten versteckt. Für eine Sicherheitsstrategie sind sie trotzdem relevant. Sie können innerhalb von Stunden den Status ändern – sie können entdeckt und ausgenutzt werden.

Referenz. Im Normalfall wird eine Verletzlichkeit von einem wohlmeinenden Dritten entdeckt  und gemeldet, oder der Hersteller entdeckt die Verletzlichkeit gleich selbst. Sie bleibt vorerst der Malwareszene verborgen, der Hersteller entwickelt und publiziert einen Patch. Erst jetzt erscheint bei relevanten Verletzlichkeiten innerhalb kurzer Zeit Malware – durch Reverse Engineering konnte aufgrund des Patches die Verletzlichkeit identifiziert werden. Kritisch ist in diesem Szenario die Zeit von der Publikation zum Aufspielen des Patches. Bei hunderten von Millionen Maschinen auf der Welt ist diese Zeit in vielen Fällen unendlich lang, etwa bei vielen gecrackten XP Installationen in Emerging Markets.

Zero Day. Eine Malware erscheint, bevor der Hersteller einen Patch bereit hat. Aufgrund der Unberechenbarkeit der Situation und der misslichen Lage des Herstellers ist das Problem leicht emotionalisierbar, womit Publikationen und Publikum gerne spielen. Das Risikopotential wird häufig überschätzt für die Fälle, wo dämpfende Mechanismen auf den Maschinen intakt sind. Semispontane epidemische Verbreitungsmuster sind heutzutage nicht mehr möglich, wo Standardrechner eine Firewall hochgefahren haben. Bei Servern sieht das anders aus, Admins müssen sich sorgfältig um Verletzlichkeiten kümmern, die einen öffentlich zugänglichen Service betreffen. Es geht um Webserver, ftp-Server, Loginmechanismen und Vergleichbares.

Opak. Dabei wird eine Verletzlichkeit von BadGuys entdeckt und ausgenutzt – ohne dass Hersteller und Öffentlichkeit davon erfahren. Es darf angenommen werden, dass eine grössere Anzahl (mehrheitlich staatlich angestellte) SpezialistInnen an diesem Thema arbeiten. Für entsprechende stille Attacken rücken Umgebungen und exponierte Personen ins Zentrum, völlig unabhängig vom Betriebssystem. Hilfreich gegen solche Angriffe ist immer ein von Technologie und Konfiguration her maximal resilientes System in Kombination mit zurückhaltenden Verhaltensweisen.

Für Private und Kleinbetriebe ist eindeutig das Referenzszenario das wichtigste. Nicht oder nicht rechtzeitig eingespielte Patches ist für die grosse Mehrheit der Kompromittierungen verantwortlich. Zero Day Situation spielen in weit weniger als zehn Prozent der Zwischenfälle eine Rolle. Das Motto heisst patchen und überwachen. Das Betriebssystem automatisch patchen lassen – die Anwendungen überwachen, auf Windows Maschinen etwa mit Secunia PSI.

DIAGRAMM: Lebenslauf-Szenarien von Verletzlichkeiten:

Seit Monaten wird in der Fachcommunity eine neue Möglichkeit diskutiert, Schadsoftware auf einem modernen Betriebssystem zu platzieren: JIT Spraying. Beispielsweise kann mit dem Just In Time Compiler von Flash aus einem entsprechenden ActiveScript heraus Malware in den Speicher eingebracht werden. Ob sich „das Blatt wieder zu Gunsten der Angreifer“ wendet, wie heise.de voraussagt?

Auf aktuellen Windows Systemen scheitern konventionelle Versuche, etwa mit Buffer Overflows Malware zu starten. Das wird durch Markierung von Speicher als „nicht ausführbar“ (Data Execution Prevention DEP) und die zufällige Platzierung von Modulen (Address Space Layout Randomisation ASLR) bewirkt.

Auf der Suche nach Speicherplatz, der beschrieben und ausgeführt werden kann, fällt der Blick auf Scriptinterpreter wie Active Script. Um die Ausführungsgeschwindigkeit zu beschleunigen, werden Scripts on the run erst kompiliert und dann ausgeführt. Mit geeigneter Manipulation des Scriptcodes können so auch spezielle Muster erzeugt werden: Malwarestücke.

Teilautonom

Das Risiko entsteht nicht darum, weil DEP ausgetrickst wird, denn DEP funktioniert auf der Basiseben des Systems und seiner Prozesse konsistent. Das Problem entsteht, weil hier auf dem System relativ entkoppelte Teilsysteme – eigentlich Codefabriken – existieren. Es ist keine Lücke, sondern eine Funktion dieser Codefabriken, Lauffähigen Code zu erzeugen. Verschiedene Aspekte sind problematisch:

• Es gelangt unsignierter Programmcode auf das System, zB Scripts von einer Website.
• Die Scripts werden in reproduzierbarer Weise in direkt lauffähigen Code gewandelt.
• Der Compiler ist vom Betriebssystem entkoppelt, die entsprechenden Mechanismen greifen nicht.

Es grundsätzlich problematisch, lauffähigen Code auf einem System zuzulassen. Gegenüber dem Herunterladen und Laufenlassen beliebiger *.exe Files hat sich in den letzten Jahren eine angemessen kritische Haltung auch bei vielen Usern verbreitet. Gegenüber Scripts hat sich eine gewisse Sorglosigkeit gehalten, auch im professionellen Umfeld. Einerseits vertraut man auf die Zuverlässigkeit von Interpretern in einer Browser-Sandbox. Andererseits wird gar nicht kritisch diskutiert, weil die serverseitige Entwicklung zu immer mehr Scripts hin ging. Der Webserver versendet Objekte und Scripts – die Page wird dann durch den Browser beim User zusammengebaut. Viel sicherer wäre natürlich, dem User nur Objekte darzubieten.

Die massive Verbreitung von Scripts hat nun die Browser-Programmierer unter Druck gesetzt, aus Performancegründen zu kompilieren. Google war mit Chrome und beeindruckenden Performance-Vorteilen Vorreiter dieser Entwicklung.

Riskioabschätzung

Das Teilproblem, Malwarescripts zu erzeugen, die kompiliert lauffähige Malwareelemente ergeben, darf als gelöst angesehen werden. Auf einem aktuellen Windows-System müssen aber eine Reihe von weiteren Hürden überwunden werden, bis eine Kompromittierung des User-Kontexts gelingt. Härtung des Compilers: Die Browserproduzenten dürften einzelne Härtungsmechanismen einbauen, wenn das Problem praktisch relevant werden sollte. Sandboxing: Ein Malwarefragment im Browserkontext kann nur selektiv auf Funktionen des Systems zugreifen. Integrity Level: Ein Malwarefragment im Browserkontext kann keine höher eingestuften Prozesse ansprechen oder kreieren.

Leider schweigen sich die vorliegenden Publikationen darüber aus, wie das Potential in Bezug auf ein aktuelles System und in der realen Welt zu bewerten ist. Vorläufig ist noch nichts über lebensfähige Implementierungen im realen Ökosystem bekannt. Auf ein halbes Jahr hinaus betrachtet dürfte die praktische Relevanz äusserst bescheiden sein. Das mittelfristige Potential ist vorhanden, das Ausmass bleibt offen und hängt auch von den Gegenmassnahmen der Compilerbauer ab.

Für Maschinen mit Top Security Maschinen muss diskutiert werden, ob nicht ein absolutes Whitelisting angesagt ist, das auch Scripts umfasst. Unter 64 Bit Windows können die Nebenfolgen in der 64Bit Instanz von Internet Explorer schon mal getestet werden: Flash gibt da schon gar nicht, Java Script und Active Script kann im Browser weggeschaltet werde.

Wenige Meinungsverschiedenheiten gibt es über folgende These: Der Webbrowser gehört zur Topkategorie von Applikationen, wenn es um Sicherheit geht. Wie aber ist die Sicherheit der einzelnen Produkte zu bewerten? Gibt es ein besonders empfehlenswertes Produkt?

Leider gibt es weder wissenschaftliche Modelle noch technische Guidelines, welche die zentrale Frage seriös beantworten: Welches Risiko geht ein User in Realworld Szenarien mit verschiedenen Browsern ein? Es bleibt nur eine zurückhaltende Interpretation einzelner Indizien.

Verletzlichkeiten

Für Aufsehen hat kürzlich eine von Bit9 veröffentlichte “Dirty Dozen” Apps List gesorgt. Die Daten stammen aus der Datenbank des U.S. National Institute of Standards and Technology (NIST). Webbrowser sind in der Hitparade prominent platziert:

1. Google Chrome (76 reported vulnerabilities)
2. Apple Safari (60)
5. Mozilla Firefox (51)
8. Microsoft Internet Explorer (32)

Um eine Vergleichsmöglichkeiten zu gewinnen, habe ich die Verletzlichkeiten der 2009 aktuellen Browserversionen bei Secunia nachgeschlagen. Das ergibt für die drei am weitesten verbreiteten Produkte folgende Zahlen für die relevanten Verletzlichkeiten (moderately, highly und extremely critical):

Google Chrome (5.x 6.x 7.x):   12
Firefox 3.6:   9
IE 8.x:    8

Die publizierten Verletzlichkeiten bilden ein relevantes Indiz. Sie verweisen auf Probleme mit der Codequalität. Vermutlich ist bei Microsoft die Codequalität etwas höher, als die Zahlen auf den ersten Blick vermuten lassen, denn die Aufdeckungsrate von Verletzlichkeiten dürfte beim Marktführer erheblich höher sein. Google hat aus guten Gründen Security bei Features und Produktion von Anfang an hoch gewichtet, in der Praxis scheint aber die Qualität unter der hastigen Entwicklungspace zu leiden. Sollte sich der Aufwärtstrend fortsetzten und Chrome auch mal wie Firefox auf 20% Marktanteil kommen, entfällt der momentane Nischenschutz: Der Angriffsdruck dürfte die Rate der aufgedeckten Verletzlichkeiten steigen lassen.

Die Secunia Zahlen müssen mit Vorsicht interpretiert werden. Sie repräsentieren nicht einzelne Verletzlichkeiten, sondern jeweils ganze Bündel davon.

Patching und Security Features

Verschiedene Browser repräsentieren unterschiedliche Patchingphilosophien: Internet Explorer mit berechenbarem Monatsrhythmus, Firefox mit Hochfrequenz, Google verdeckt. Ganz generell kann nicht von der Überlegenheit eines Modells gesprochen werden. Das hängt vom Anwendungsfall ab. Generell kann den Herstellern attestiert werden, dass sie das Problem ernst nehmen und besser im Griff haben, als beispielsweise Adobe mit seinen Produkten.

Hier kann keine ausführliche Analyse der Security Features geleistet werden. Der Trend geht in die richtige Richtung. Die Infrastruktur des Betriebssystems wird besser genutzt (DEP, ASLR, Integrity Levels, Prozess per Tab). Der Browser wird vom System durch Sandboxing entkoppelt.
Zudem bringen die Browser Mechanismen mit, um üble Sites zu identifizieren, Downloads zu sichern und CrossSiteScripting zu erschweren.

Zusammenfassend

… lässt sich feststellen:

1. Das Qualitätsniveau der führenden Browser ist nicht befriedigend (aber noch problematischer sind einzelne Plugins und die Qualität zahlreicher Websites).

2. Alle drei führenden Produkte bewegen sich in der gleichen Security-Bandbreite.

3. Security ist bei den Browserentwicklern momentan etwas an den Rand gerückt – alles dreht sich um Speed und HTML 5 Kompatibilität.

Das heisst nicht, dass Internet Explorer 9 oder Firefox 4 weniger sicher als die Vorgängerversionen sein werden. Es besteht aber das Risiko, dass die weiten neu codierten Teile (GPU Acceleration etc.) erneut von unangenehm vielen Verletzlichkeiten gespickt sein könnten. 2011 zu beobachten.

Softwareverletzlichkeiten wurden erfunden, um Professionalität und Nervenstärke der IT-Branche jahrzehntelang auf die Probe zu stellen. Das Leiden bei Profis und Amateuren dauert. Secunia tritt an, einen Ausweg auf dem Patching Fegefeuer zu markieren. Der neue Personal Software Inspector (PSI) 2.0 Beta soll über das Aufdecken von Lücken hinaus auch einen Teil derselben automatisch patchen können. Ein kurzer Test.

Wir ziehen einen Windows 7 Laptop aus dem Schrank, der dort einige Wochen gedöst hat. Die Installation geht flink voran, der Inspector 2.0 Beta kann gestartet werden. Auf dem schlank gehaltenen Laptop dauert es etwa zwei Minuten, bis die Anwendungen in bekannt zuverlässiger Art analysiert sind. Die meisten sind Up-to-date und interessieren nicht weiter. Bei den patchbedürftigen Apps treten nun ganz verschiedene Szenarien auf:

1. Running update. Da detektiert der Inspector richtigerweise, dass (hier für Adobe Reader) ein Updateprozess am Laufen ist und kein zusätzlicher Handlungsbedarf besteht.

2. Install Solution. Am vorliegenden Beispiel in fünf von sieben Fällen sieht der Inspector keine Möglichkeit, das Patching direkt zu erledigen und verweist auf die Webpage des Herstellers. Möglicherweise betrifft das alle Fälle, wo die Installation einer neuen Version fällig wird oder Windows Update involviert ist.

3. Kein Kommentar. Im Fall des Cisco VNP Client 5.0.04 stellt der Inspector zu Recht Handlungsbedarf fest – liefert aber keinen Patching Hinweis.

4. Automatic. Im vorliegenden Fall nicht aufgetreten, dem Vernehmen nach gibt es aber entsprechende Apps, wo PSI automatisches Patchen anbietet.

Fazit: Mit der nötigen Vorsicht geht PSI 2.0 Beta in Richtung eines eleganten Patchings. Vorläufig bleibt das Ziel aber noch in weiter Ferne und es besteht für EndanwenderInnen kein Grund, auf diese Beta zu wechseln. Profis in Windows-Umgebungen sollten die Entwicklung aufmerksam verfolgen und sich eine Testinstallation ansehen.

Was secunia vor Monaten angekündigt hat, wird nun schrittweise umgesetzt: Der Personal Software Inspector 2 kann Patchingbedarf nicht nur identifizieren, sondern auch Patches installieren.

Die soeben veröffentlichte Betaversion patcht vorerst nur eine Minderheit der analysierten Programme. Trotzdem zeichnet sich hier für Private User und Kleinbetriebe eine Möglichkeit ab, rationeller einen akzeptablen Patching Stand zu erreichen.

Der Zeitpunkt könnte nicht günstiger sein. Die aktuellen DLL Loading Risiken sind bei zahlreichen Applikationen identifiziert worden. In den nächsten Wochen und Monaten dürfte sich ein Schwall von Patches und Updates über die User ergiessen. Für die Betreiber von standalone PCs lohnt es sich, das neue Produkt genauer anzusehen.

Nachdem das Risikopotential des unsicheren DLL Loading jahrelang kaum Beachtung fand, wird es momentan intensiv diskutiert und untersucht. Damit entsteht ein Bündel von Zero Day Situationen.

Nun sind auch leicht handhabbare Tools und Methoden greifbar. Darum werden zahlreiche Anwendungen untersucht und schlagartig landen Dutzende von ihnen auf den entsprechenden Listen. Darunter auch solche von Microsoft, bei denen die Programmierer sich über die „good practices“ des Konzerns hinweg gesetzt haben. Bei Secunia dominiert nun „Insecure Library Loading Vulnerability” das Bild:

Secunia listet die betroffenen Applikationen auch in einer zusammenfassenden Liste.  Die Sicherheitsfirma bewertet die DLL Verletzlichkeiten der Applikationen als „highliy critical“. Dabei wird aber nicht spezifiziert, unter welchen Voraussetzungen die Verletzlichkeit ausgenutzt werden kann.

Bestimmt werden diese Verletzlichkeiten in die Malware-Baukästen Eingang finden. Die betroffenen ungepatchten Anwendungen werden auf Monate und Jahre hinaus auch über diese Verletzlichkeitskategorie angegriffen werden.

Es bleibt vorläufig offen, wie weit dieses Bündel von Verletzlichkeiten kurzfristig zu einem substantiellen Anstieg des Risikos führt.

Beim Programmieren von Anwendungen auf wiederverwendbare Komponenten zu bauen, hat sich durchgesetzt. Es entsteht dabei ein Risiko, wenn Angreifer eine Anwendung veranlassen können, eine manipulierte Komponente nachzuladen. Dieser Problematik wird seit Jahren diskutiert, im Fall von Windows beispielsweise hier.

Brisanter ist die Problematik geworden durch die Ausbreitung der Konnektivität und durch aktuelle Hinweise auf Exploits. Microsoft hat ein Advisory publiziert.

Beim dynamischen Laden von Komponenten sind zwei Szenarien zu unterscheiden. Entweder programmiert der Programmierer den Pfad zur Komponente. Das empfiehlt Microsoft als Good Practice, weil damit ein Laden von Malware-Komponenten unterbunden wird. Oder der Pfad wird offen gelassen, dann sucht das Betriebssystem nach einer vorgegebenen Liste in verschiedenen relevanten Pfaden nach der DLL. Einer dieser Pfade ist das aktuelle Arbeitsverzeichnis.

Dieses aktuelle Verzeichnis kann auch ein USB-Laufwerk, eine WebDAV Verbindung oder ein mit SMB eingebundenes Netzlaufwerk sein. Damit sind gleich die wichtigsten Verbreitungspfade angesprochen. Die Bedingungen für eine erfolgreiche Infektion sind:

1. Malware muss auf einem potentiellen Pfad eines Systems platziert sein, am einfachsten ein externes Medium.
2. Dieser Pfad muss der aktuelle Pfad sein.
3. Die Anwendung muss so programmiert sein, dass sie beim Öffnen bestimmter Filtypen das Betriebssystem nach noch nicht eingebundenen DLLs suchen lässt.

Nicht alle in der aktuellen Diskussion als verletzlich genannten Anwendungen verhalten sich gleich und schicken bei einem Standard-Filetyp das Betriebssystem auf DLL-Suche. Es kann durchaus sein, dass ein Media-Player bei jedem MP3 eine Suche anstösst, die ins aktuelle Verzeichnis führt. Beim von Secunia ebenfalls als verletzlich gelisteten PowerPoint zeigt andererseits ein kurzer Test mit Version 2010, dass das Öffnen ein *.pptx Files von einem Memorystick nicht zu einem DLL-Search auf diesem Stick führt. Eine allfällig vorhandene Malware würde nicht geladen. Die genauen Modalitäten der Ausnützbarkeit bleiben offen.

DLL Preload ist vorerst ein ernst zu nehmendes Potential, aber kein sich schlagartig auftürmendes Risiko. An der grundsätzlichen Ausnützbarkeit bestehen keine Zweifel. Ob das leicht in grossem Ausmass möglich ist, dürfte sich im Verlauf des Monats September zeigen.

Von den grossen Softwareproduzenten darf erwartetet werden, dass sie zügig Ihre Produkte analysieren und wenn nötig die Lademechanismen für DLLs abdichten.

Auf Ebene des Betriebssystems liegt keine Verletzlichkeit im üblichen Sinne vor. Für Umgebungen mit erhöhtem Schutzbedarf hat Microsoft einen Workaround publiziert, welcher die Einschränkung der Ladepfade möglich macht. Derartige Einschränkungen des Möglichkeitenraums haben häufig einen Preis. Im vorliegenden Fall werden bei einzelnen Programmen wie Google Chrome Kompatibilitätsprobleme gemeldet.

[Fortsetzung zum Thema DLL: Apps mit unsicherem DLL Loading]

Serie Zero Day – Teil 4

Die Einschätzung von patchlosen Verletzlichkeiten und der resultierenden Situation ist nicht ganz einfach. Entsprechend weit gehen zuweilen die Meinungen auseinander. Wie könnte eine solide Basis für die Beurteilung dieser Problematik aussehen?

Ein möglicherweise solider Ausgangspunkt könnte Risikomanagment sein. Eine Zero Day Situation wird als vorübergehendes zusätzliches Risikopotential für die betriebliche IT betrachtet.

Aus dieser Perspektive lässt sich nun die Problemstellung besser fassen: Stellt eine laufende Zero Day Situation eine relevante Erhöhung des Risikos für die nächsten Tage / Wochen dar? Ist das Ausmass der Risikoerhöhung so gross, dass Qualitätsziele in Frage gestellt werden und Workaround Massnahmen in Frage kommen? Steht die Risikominderung in einem angemessenen Verhältnis zu Aufwand und möglichen Funktionsbeschränkungen?

Nach der Erhöhung des Risikos zu fragen, wirft zwei Problemkreise auf. Einmal ist die Frage bezogen auf des das ‚normale‘ alltägliche Risiko. Dazu sind die Vorstellungen oft verschwommen. Eine Einschätzung des Basisrisikos vorzunehmen, ist aber unumgänglich, wenn die relative Risikoerhöhung durch eine Zero Day Situation bewertet werden soll. Niemand würde irgendwelche Aktionen auf zwanzig Doktoranden-PCs verstehen, wenn eine Zero Day Situation das Risiko für zwei Wochen um drei Prozent erhöht. Hingegen dürfte das Management beispielsweise einer Finanzabteilung durchaus Massnahmen befürworten, wenn das Risiko auf Wochen hinaus um mehrere hundert Prozent höher erscheint.

Gesichtspunkte

Die zweite Herausforderung besteht darin, das zusätzliche Risikovolumen abzuschätzen, das auf eine bis zwei Wochen durch eine ungepatchte Verletzlichkeit entsteht. Wichtig ist dabei, eine Einschätzung immer auf ein konkretes Umfeld zu beziehen. Es sind verschieden paar Schuhe, Aussagen über die ganze Welt, eine Hochschule oder ein bestimmtes Institut zu machen. Das Risikopotential muss über eine kombinierte Analyse verschiedener Elemente abgeschätzt werden:

1. Die technische Abschätzung der Verletzlichkeit klärt, ob zentrale Mechanismen betroffen sind, Malware entwickelt und verbreitet werden kann, gewisse Mechanismen sich dämpfend auf die Ausnützbarkeit der Verletzlichkeit auswirken kann.
2. Existiert ein Exploit? Ein Exploit für sich klärt gewisse Aspekte der Ausnützbarkeit.
3. Existiert sich verbreitende Malware? Das klärt weitere Aspekte der Ausnützbarkeit und generiert zumindest ein leicht erhöhtes Risiko.
4. Verbreitungsdynamik. Gibt es eine relevante Dynamik der Verbreitung und welche Milieus sind betroffen?
5. Kontaktwahrscheinlichkeit. Lassen die Verbreitungsmechanismen eine relevante Wahrscheinlichkeit erwarten, dass eigenen Maschinen mit der Malware in Kontakt kommen?
6. Resilienz. Sind die betrachteten Maschinen durch ihre Ausstattung, Softwareversion und Konfiguration in einem relevaten Ausmass anfällig dafür, bei einem Kontakt auch kompromittiert zu werden.
7. Dauer. Wann ist ein regulärer Patch zu erwarten, welcher der Zero Day Situation ein Ende setzt?

Zeitschwellen

Mit diesen Fragestellungen müssen betroffene Akteure an zwei Zeitschwellen aktiv werden.
Nach der Publikation einer wichtigen Verletzlichkeit und hinreichenden Informationen sind drei Akteure gefordert, eine potentielle substantielle Risikoerhöhung zu identifizieren: Die IT-Security Experten einer Institution, die Verantwortlichen des Paketierungs- und Deploymentsystems in gemanagten Umgebungen sowie die IT-Verantwortlichen von Umgebungen mit erhöhtem Schutzbedarf. Das Paketieren und Ausliefern von Workarounds muss vorbereitet und eine Auslöseschwelle diskutiert werden.

Damit wird eine Beobachtungsphase eröffnet. Täglich müssen Verbreitung der Malware, Kontaktwahrscheinlichkeit und Widerstandfähigkeit der eigenen Maschinen betrachtet und gefragt werden, ob für die nächsten Arbeitstage ein Überschreitung des akzeptablen Risikos zu erwarten ist. Wenn ja, muss das Deployment von Workarounds oder andere risikomindernde Massnahmen angesetzt werden. Sofern nicht der Patch bereits angekündigt ist.

* * *
Es gibt durchaus Möglichkeiten, Zero Day Situationen professionell zu handhaben. Es erscheint nützlich, dass sich die betroffenen Stellen ein schlichtes Beurteilungsschema und Prozessdesign entwickeln, auch wenn ein ‚Ernstfall‘ sich nur selten einstellt. Ein Effizienzgewinn resultiert dann, wenn unnötige Aufregungen, Funktionseinschränkungen und Paketierungsaktivitäten vermieden werden können.

Serie Zero Day – Teil  3

Der Beitrag von Zero Day Situationen zum Risikovolumen wird eher überschätzt. Warum sie sich zu emotionaliserter Berichterstattung durch die Tagespresse eignen, haben wir im letzten Beitrag dargelegt. Ignoriert werden können sie aber auf keinen Fall. Wie lässt sich ihre Bedeutung fassen? Wer muss sich damit auseinandersetzen?

Wenn wir in der Geschichte fünf, sechs Jahre zurückblättern, sehen wir eine Welt mit vielen ‚naiv‘ konfigurierten PCs. Sie hatten keinen Firewall und publizierten Services (etwa freigegebene Ordner) direkt ans Internet. Das machte epidemieartige Infektionen möglich. Innerhalb weniger Stunden konnten im Direktkontakt hunderttausende von Maschinen angesteckt werden. Da war Alarmstimmung in Zero Day Situationen durchaus berechtigt. Seit der Verbreitung von XP SP2 ist die Mehrheit der Rechner am Internet durch Firewall geschützt. Auch verletzliche Maschinen werden nun durch indirektere Mechanismen infiziert, zB Besuch eines kompromittierten Websites.

Die Welt der IT wird immer differenzierter. Auch von Zero Day Situationen sind verschiedene Player unterschiedlich betroffen. Die Hersteller von Software sind bei jedem Hinweis auf Verletzlichkeiten herausgefordert, das Problem zu analysieren, das Risikopotential zu benennen, auf Workarounds hinzuweisen und Patches zu publizieren. Dabei ist es von institutionellen Kunden her dringend erwünscht, dass das in einem berechenbaren Schema erfolgt. Ein ausserterminliches Deployment ist dann angebracht, wenn die Risiken kurzfristig über ein tolerierbares Mass zu steigen beginnen.

Endanwenderinnen und Privatuser sollten sich um Zero Day Situationen nicht kümmern, sondern ihre sehr beschränkten Ressourcen darauf konzentrierten, ein paar einfache Bausteine der IT-Sicherheit in Schuss zu halten. Hier findet die grosse Risikoreduktion statt.

Für IT-Verantwortliche im Nebenamt mit sehr limitierten Ressourcen gilt das gleiche. Sie haben nicht die Zeit und die Infrastruktur, um situativ zu agieren und heute einen Workaround zu verteilen, morgen einen andern Browser bei ihren KollegInnen zu installieren, übermorgen alles wieder rückgängig zu machen und dann den endlich erschienenen Patch zu installieren. Je geringer die Ressourcen, umso eher sollten diese auf die Basics konzentriert werden.

Gemangte Umgebungen mit Standardqualität sind von Zero Day Situation nur am Rande betroffen. Weil Zero Day das Risikovolumen nur vorübergehend und allenfalls um wenige Prozent erhöhen, gilt als Faustregel: Das Deployment von Workarounds und andere situative Aktionen erübrigt sich, ohne dass die Qualitätsziele gefährdet werden. Ausgenommen sind Spezialsituationen, wo zB ein krasses Versagen eines Herstellers sich mit besonderer Exposition eines Userumfelds kombiniert.

Gemanagte Umgebungen mit erhöhtem Schutzbedarf müssen sich um wichtige Zero Day Situationen kümmern, indem sie diese einschätzen und mit der eigenen Risikotoleranz vergleichen. In den meisten Fällen drängt sich weder ein Deployment von Workarounds noch andere risikomindernde Massnahmen auf. In bestimmten Fällen kann das erwartete Risiko für die nächsten fünf Arbeitstage die Toleranzschwelle erreichen. Dann sind risikomindernde Schritte zu prüfen, die in verschiedene Richtung gehen können: Implementierung eines temporären Workarounds oder Funktionalitätsbeschränkungen auf der Maschine; Erlass von temporären Verhaltenseinschränkungen an die Enduser; Limitieren der Kontaktrisiken mit Malware, indem etwa ein Webproxy temporär den privat motivierten Kontakt zu Websites einschränkt.

Im Kontext der gemanagten Umgebungen sind die Betreiber der Deployment-Infrastruktur besonders herausgefordert. Wenn die Verantwortlichen von gemanagten Umgebungen plötzlich einen Workaround verteilen wollen, muss dieser paketiert und getestet im Deploymentsystem bereit liegen. In Abstimmung mit diesen Kunden muss der Deployment Provider stufenweise und abhängig von der Risikosituation in die Bereitstellung einsteigen. Das ist anspruchsvoll, weil die Vorlaufzeit noch grösser ist als für den direkten IT-Verantwortlichen, der unmittelbar die Entwicklung der nächsten paar Tage abschätzen muss.

Kurz: Enduser sollen sich in Ruhe auf ein paar Basics konzentrieren – die Verantwortlichen für betriebliche Umgebungen mit erhöhten Qualitätsanforderungen müssen Zero Day Situationen in ihr generelles Risikomanagement einbauen. Als Bezugspunkt können allgemeine Lagebeurteilungen genommen werden, wie sie an der ETH für jede Betriebssystemfamilie aktualisiert werden.  Für die Festlegung der Risikotoleranz und für die Beurteilung der konkreten Risiken vor Ort sind die betrieblichen Verantwortlichen zuständig.