{"id":18865,"date":"2019-03-28T15:01:40","date_gmt":"2019-03-28T13:01:40","guid":{"rendered":"https:\/\/www.kaspersky.de\/blog\/?p=18865"},"modified":"2019-11-22T12:08:31","modified_gmt":"2019-11-22T10:08:31","slug":"patching-strategy-rsa2019","status":"publish","type":"post","link":"https:\/\/www.kaspersky.de\/blog\/patching-strategy-rsa2019\/18865\/","title":{"rendered":"RSAC 2019: Auf der Suche nach der perfekten Patch-Strategie"},"content":{"rendered":"

\u201eEntschuldigen Sie, haben Sie einen Moment Zeit, um sich \u00fcber Sicherheitsupdates zu unterhalten?\u201c<\/p>\n

\u201eTut mir leid, ich bin zu besch\u00e4ftigt mit der Installation von allen verf\u00fcgbaren Patches.\u201c<\/p>\n

Aber im Ernst: es lohnt sich wirklich einen Moment innezuhalten und dar\u00fcber nachzudenken, wie effektiv (oder auch nicht) Ihr Patch-Management wirklich ist.<\/p>\n

In einer perfekten Welt w\u00fcrden Sie alle Patches f\u00fcr jede in Ihrem Unternehmen verwendete Software unverz\u00fcglich nach der Ver\u00f6ffentlichung installieren. Im echten Leben ist das Ganze jedoch etwas komplizierter als in der Theorie und es ist nie genug Zeit f\u00fcr die Installation aller Patches \u2013 daher m\u00fcssen Sie Priorit\u00e4ten setzen. Aber wie macht man das am besten?<\/p>\n

Auf der RSA-Konferenz 2019 pr\u00e4sentierten Jay Jacobs vom Cyenta Institute und Michael Roytman von Kenna Security<\/a> eine Studie mit dem Titel \u201c The Etiology<\/a> of Vulnerability Exploitation\u201c (dt: Die Ursachenforschung der Ausnutzung von Schwachstellen). Der durchaus gut begr\u00fcndete Bericht befasste sich haupts\u00e4chlich mit den Schwachstellen, die eine erh\u00f6hte Aufmerksamkeit verdienen sowie mit der Art und Weise, wie sowohl die Installation von Patches also auch die Sicherheitsupdate-Strategie drastisch verbessert werden kann.<\/p>\n

Die Grundvoraussetzung ist, dass nicht alle Schwachstellen in der Praxis ausgenutzt werden. Unter der Annahme, dass diese Aussage wahr ist, k\u00f6nnen viele Updates ganz einfach in den Hintergrund gestellt und Schwachstellen<\/strong> priorisiert werden, die tats\u00e4chlich (und mit hoher Wahrscheinlichkeit) bei einem Angriff verwendet werden k\u00f6nnen. Aber wie unterscheidet man \u201egef\u00e4hrliche\u201c Schwachstellen von der \u201ehaupts\u00e4chlich harmlosen\u201c Sorte?<\/p>\n

Bewaffnet mit Beschreibungen aus der CVE-Datenbank (Common Vulnerabilities and Exposures<\/em>) und \u00f6ffentlich verf\u00fcgbaren Exploit<\/strong>-Datenbanken sowie Daten von Vulnerability Scannern und IPS\/IDS-Systemen (insgesamt 7,3 Milliarden Angriffsdatens\u00e4tze und 2,8 Milliarden Schwachstellen in 13 Millionen Systemen) haben die Forscher ein Modell erstellt, das diese Aufgabe ziemlich gut bew\u00e4ltigt. Um das Ganze zu relativieren, bedarf es einer kleinen Analyse der Schwachstellenlandschaft<\/strong>.<\/p>\n

<\/div>\n

Wie viele CVEs existieren in der Wildnis?<\/h2>\n

Jeder Experte f\u00fcr Informationssicherheit wird Ihnen sagen, dass die Anzahl der bekannten Schwachstellen unglaublich gro\u00df<\/em> ist. Aber nicht viele Experten kennen die genaue Ziffer (wenn sie \u00fcberhaupt jemand kennt). Bislang sind etwa 108.000 CVEs<\/strong> ver\u00f6ffentlicht worden.<\/p>\n

Ber\u00fccksichtigen Sie auch, dass die monatliche Ver\u00f6ffentlichungsrate in den letzten Jahren gestiegen ist: Wenn in den Jahren 2005 bis 2017 jeden Monat etwa 300 bis 500 CVEs ver\u00f6ffentlicht wurden, \u00fcberschritt der durchschnittliche Monatswert Ende 2017 die 1.000er-Marke und ist seitdem auch nicht mehr gesunken. Das sind pro Tag Dutzende neue Bugs!<\/p>\n

\"DieDie Existenz eines Exploits wird im Allgemeinen entweder kurz vor oder unmittelbar nach der Ver\u00f6ffentlichung des jeweiligen CVEs bekannt. Es gibt Ausnahmen, aber in den meisten F\u00e4llen betr\u00e4gt das Zeitrahmen mehr oder weniger zwei Wochen um das Datum der CVE-Ver\u00f6ffentlichung. Daher verlangen CVEs eine schnelle Antwort.<\/p>\n

\"In<\/a>Es versteht sich von selbst, dass die Installationsquote von Updates etwas hinterherhinkt. Im Durchschnitt wird ein Monat nach der Entdeckung lediglich ein Viertel aller Schwachstellen behoben. Es dauert ganze 100 Tage, bis die H\u00e4lfte entfernt wurde, und ein Viertel der Schwachstellen ist auch ein Jahr nach dem Vorfall noch immer nicht gepatcht.<\/p>\n

\"Im<\/a><\/p>\n

Mehr als zwei Drittel der ungepatchten Schwachstellen<\/strong> lassen sich in Produkten von lediglich drei Anbietern finden. Um welche Marken und Produkte es sich handelt, sehen Sie in der folgenden Grafik:<\/p>\n

\"Mehr<\/a>\"Produkte<\/a><\/p>\n

Unterdessen gibt es f\u00fcr 77% der CVEs keine ver\u00f6ffentlichten Exploits. Interessant ist auch, dass nicht alle ver\u00f6ffentlichten Schwachstellen in realen Umgebungen angetroffen werden \u2013 genauer gesagt nur 37.000 der 108.000 vorhandenen CVEs. Und lediglich 5000 dieser CVEs k\u00f6nnen ausgenutzt werden und gleichzeitig in freier Wildbahn existieren. Genau diese Schwachstellen sollten<\/em> priorisiert werden \u2013 sie m\u00fcssen nur richtig erkannt werden.<\/p>\n

\"Von<\/a><\/p>\n

Patch-Strategien<\/h2>\n

Die Forscher haben die Relevanz der Patch-Strategien anhand zweier Messgr\u00f6\u00dfen gemessen: Der Anteil \u201egef\u00e4hrlicher\u201c Schwachstellen an der Gesamtzahl gepatchter Schwachstellen<\/strong> (Effizienz) und umgekehrt der Anteil der gepatchten Schwachstellen an der Gesamtzahl \u201egef\u00e4hrlicher\u201c Schwachstellen (Abdeckung).<\/p>\n

\n
\"Die<\/a>

Kommt Ihnen das Bild bekannt vor?<\/a><\/p><\/div>\n<\/div>\n

Eine der allgemein akzeptierten Patch-Strategien basiert auf dem Common Vulnerability Scoring System<\/em> (CVSS), wobei CVSS-Werten, die einen bestimmten Wert \u00fcbersteigen, Priorit\u00e4t einger\u00e4umt wird. Die Berechnung der Effizienz und Abdeckung f\u00fcr CVSS 10 ergibt jeweils 23% bzw. 7%. Interessanterweise kann das gleiche Ergebnis auch durch die zuf\u00e4llige Installation von Patches<\/strong> erreicht werden.<\/p>\n

<\/a><\/p>\n

Der \u00fcbliche Ansatz \u2013 alles mit einem \u201ehohen\u201c CVSS-Wert (7 oder h\u00f6her) zu patchen \u2013 f\u00fchrt zu deutlich besseren Ergebnissen. Dieser Ansatz ist im Gro\u00dfen und Ganzen nicht schlecht, aber er ist zeitaufw\u00e4ndig, da auf diese Weise die Installation einer gro\u00dfen Anzahl von Patches priorisiert werden muss.<\/p>\n

\"Vergleich<\/a><\/p>\n

Eine Alternativstrategie w\u00e4re das Priorisieren von Patches nach Anbieter. Denn tats\u00e4chlich weisen alle Entwickler ein unterschiedliches Verh\u00e4ltnis zwischen der Anzahl der tats\u00e4chlichen Exploits und der Gesamtzahl der CVEs auf. Aus diesem Grund w\u00e4re es durchaus logisch, diejenigen Hersteller zu priorisieren, deren Produkte Schwachstellen aufweisen, die in der Praxis am ehesten ausgenutzt werden.<\/p>\n

\"Die<\/a><\/p>\n

Trotzdem ist diese Strategie im Hinblick auf die Effizienz und Abdeckung schlechter<\/em> als zuf\u00e4lliges Patchen, denn sie ist in etwa nur halb so effektiv.<\/p>\n

\"Anbieter-basierte<\/a><\/p>\n

Aus diesem Grund ist dieser Ansatz langfristig gesehen noch weniger relevant als der auf CVSS basierende Ansatz.<\/p>\n

Wahrscheinlichkeitsberechnungsmodell f\u00fcr das Ausnutzen von Schwachstellen<\/h2>\n

Dies f\u00fchrt uns erneut zur\u00fcck zu dem von den Forschern entwickelten Modell. Beim Vergleich von Daten aus den CVE-Beschreibungen, \u00f6ffentlich verf\u00fcgbaren Exploit-Datenbanken<\/strong> und IPS\/IDS-Systemen, konnte das Team eine Reihe von Anzeichen identifizieren, die die Wahrscheinlichkeit, das seine Schwachstelle tats\u00e4chlich auch in der Praxis ausgenutzt wird, beeinflussen.<\/p>\n

Einerseits erh\u00f6hen Anzeichen wie eine CVE-Referenz von Microsoft oder die Existenz eines Exploits in Metasploit die Wahrscheinlichkeit, dass die fragliche Schwachstelle ausgenutzt wird, drastisch.<\/p>\n

\"Die<\/a><\/p>\n

Andererseits gibt es auch Anzeichen, die die Wahrscheinlichkeit einer Ausnutzung reduzieren \u2013 dazu geh\u00f6ren beispielsweise Schwachstellen im Safari-Browser<\/strong>, Exploits, die in der ExploitDB-Datenbank ver\u00f6ffentlicht wurden, \u201eauthentifizierte\u201c oder \u201edouble free Memory\u201c (Mehrfache Deallokation) in den CVE-Beschreibungen, usw. Durch die Kombination dieser Faktoren k\u00f6nnten Forscher die Wahrscheinlichkeit eines m\u00f6glichen Exploits berechnen.<\/p>\n

\"Einige<\/a><\/p>\n

Um die Genauigkeit des Modells zu \u00fcberpr\u00fcfen, haben die Forscher ihre Prognose mit den Daten tats\u00e4chlicher Angriffe verglichen und Folgendes herausgefunden:<\/p>\n