Ist HEIST ein Risiko oder eine Bedrohung?

Die Aufgabe von Sicherheitsexperten besteht darin, den Unterschied zwischen Risiken und Bedrohungen zu erkennen und entsprechend zu handeln. Für den Laien (und das sind die meisten von uns) scheint der Unterschied zwischen beiden möglicherweise nicht vorhanden zu sein. Sind sie nicht letztlich semantisch gleichwertig? Verwenden wir sie nicht synonym, um Schwachstellen, DDoS-Angriffe und den neuesten Zero-Day-Exploit zu beschreiben?

Das könnte sein, aber Sicherheitsexperten gehen oft viel präziser vor. Denn wenn sie es nicht täten, würden ihre Budgets die der gesamten IT übersteigen, während sie einen digitalen Krieg gegen den wachsenden Vorrat an Tools, Techniken und Technologien führten, mit denen sie ihre Abwehrmaßnahmen überwinden wollen. Das liegt daran, dass nicht alle Bedrohungen das gleiche Risiko bergen.

Das Risiko ist ein kalkulierter Messwert, der eine Reihe von Faktoren berücksichtigt, darunter die Eintrittswahrscheinlichkeit und die Auswirkungen im Falle einer Ausnutzung. Wir alle wissen, dass wir heute beim Überqueren der Straße von einem Bus angefahren werden und schlimme Folgen erleiden könnten. Allerdings ist die Wahrscheinlichkeit dafür so gering, dass die meisten von uns das Risiko als sehr gering einstufen (sofern es auf unserer Risikoskala überhaupt einen Wert aufweist). Umgekehrt besteht beim Tragen von drei Zoll hohen Absätzen ohne Profil mitten im Winter in Wisconsin eine hohe Wahrscheinlichkeit eines Sturzes mit ungünstigen Folgen, weshalb ich das persönlich in den Wintermonaten für ein ziemlich hohes Risiko halte.

Das ist ein Risiko.

Drohungen sind etwas anderes. Auch auf andere Dinge haben wir keinen Einfluss, beispielsweise das Wetter, die Busverbindungen oder die Entscheidung eines Angreifers, heute einen volumetrischer Angriff auf unsere Website zu starten.

Eines der Ziele von Sicherheitsexperten und ihren Organisationen besteht darin, Risiken zu minimieren, indem sie Bedrohungen eindämmen und die Wahrscheinlichkeit eines Exploits reduzieren. Bei minus 20 Grad und vereister Einfahrt trage ich flache Stiefel mit gutem Profil. Die Bedrohung wird eingedämmt (aber nicht beseitigt) und somit das Risiko verringert.  Wenn plötzlich eine neue Schwachstelle entdeckt wird, muss ich entscheiden, welches Risiko diese neue Bedrohung für mein Unternehmen darstellt.

Tatsächlich ist dies als Methode zur Risikobewertung so anerkannt, dass die Branche es mathematisch beschreibt:

A(sset) + V(Verwundbarkeit) + T(Bedrohung) = R(isk)

Dadurch ist es den einzelnen Organisationen möglich, einzelne Faktoren nicht nur entsprechend ihrer Geschäftsanforderungen und Risikobereitschaft zu gewichten, sondern auch einheitlich zu agieren. Dadurch können panische, überstürzte Reaktionen bei Bekanntwerden neuer Sicherheitslücken vermieden werden, insbesondere dann, wenn sich herausstellt, dass das eingeschätzte Risiko unterhalb der organisatorischen Toleranzen liegt.

Also, was ist mit HEIST?

Was uns zu HEIST bringt, steht für „HTTP Encrypted Information can be Stolen through TCP-Windows“ (HTTP-verschlüsselte Informationen können über TCP-Windows gestohlen werden). „HEIST“ lässt sich offensichtlich viel einfacher aussprechen und klingt ganz nach „Mission Impossible“, nicht wahr? Diese Sicherheitslücke wurde bei BlackHat vorgestellt und macht auch jetzt noch im Internet in Artikeln bei Ars Technica und Engadget die Runde. Bisher wurde es in freier Wildbahn nicht gesichtet. Es handelt sich nicht um eine Schwachstelle, die sich leicht ausnutzen lässt, und Forscher – darunter auch unsere eigenen – weisen darauf hin, dass die Ausnutzung eines HEIST-Angriffs keine triviale Aufgabe ist. Es handelt sich um einen komplexen Seitenkanalangriff, der das Verhalten der Browser-API (er beobachtet die normale Funktionsweise von TCP mit einer Browser-API, die die Antworten zeitlich festlegen kann), das Verhalten von Application , Inhaltskomprimierung, TCP und Kryptografie kombiniert.

Dieser Angriff könnte das Netzwerk stark belasten, wenn mehrere Anfragen ausgeführt werden müssen, ist aber eher für die Kategorie „laut“ geeignet. Beide sind für schlechte Schauspieler, die nicht auffallen wollen, unattraktiv. Und doch: Wird die Malware erfolgreich ausgenutzt, können Angreifer sie mit BREACH oder CRIME kombinieren, um Nutzdaten zu entschlüsseln und den sprichwörtlichen digitalen Jackpot zu knacken, wodurch sensible (und möglicherweise kritische) persönliche und geschäftliche Daten preisgegeben werden. In diesem Fall wäre es ihnen wahrscheinlich egal, wie laut sie sind, wenn es ihnen gelingt, an personenbezogene Daten (PII) zu gelangen – den digitalen Jackpot.

Das ist eine Drohung. Es könnte zum Exfiltrieren von Daten verwendet werden. Das nennt man einen Verstoß und es ist eine sehr schlimme Sache™. Die Frage ist, wann wird diese Bedrohung zu einem echten Risiko?

Nun, heute (genauer gesagt, als ich dies schrieb) war diese Bedrohung nicht existenziell. Das heißt, es wurde in freier Wildbahn nicht gesehen. Das heißt aber nicht, dass es nicht in freier Wildbahn vorkommt, sondern nur, dass es in freier Wildbahn noch nicht gesehen wurde. Noch. Heute. Im Augenblick.

Dreht sich schon der Kopf? Jetzt wissen Sie, warum Sicherheitsexperten immer einen benommenen Gesichtsausdruck haben. Weil sie solche Denkprozesse und Entscheidungsprozesse ständig bewältigen müssen. 

Die Frage ist also, welches Risiko besteht, wenn diese Bedrohung existenziell wird? Um diese Frage zu beantworten, müssen Sie ermitteln, welche Auswirkungen es hätte, wenn die Schwachstelle ausgenutzt würde. Welche Auswirkungen hätte es, wenn es jemandem gelänge, Daten aus Ihrer App oder Ihrer Site zu exfiltrieren? Wie hoch werden Ihre Kosten sein? Vergessen Sie nicht, den Einfluss der Marke einzubeziehen, denn er ist Teil der (zunehmend komplexen) Gleichung. Dies gilt auch für die Kosten der Schadensbegrenzung. Die Gleichung ändert sich, wenn die Kosten der Schadensbegrenzung im Vergleich zu einer Lösung mit relativ geringen Auswirkungen hoch sind. Wenn Sie jeden Webserver im Rechenzentrum (und in der Cloud) berühren müssen, um nur eine einzige Einstellung zu ändern und so die Bedrohung einzudämmen, kostet Sie das viel Zeit (und damit Geld) für etwas, das eine existenzielle Bedrohung darstellen könnte. Wenn das Risiko gering ist, würden Sie wahrscheinlich eine verständliche „Abwarten“-Haltung einnehmen, anstatt in Panik zu geraten, weil der Junge „Wolf“ gerufen hat.

Wenn die Auswirkungen der Risikominderung im Hinblick auf die Implementierungskosten relativ gering sind – beispielsweise ein einfaches Skript, das den Angreifer verwirrt, indem es die Größe der zurückgegebenen Daten variiert und so die Durchführung von HEIST erschwert –, können Sie die Umsetzung in Erwägung ziehen. Schließlich waren die Kosten für eine weitere Risikoreduzierung minimal und mit ziemlicher Sicherheit weitaus geringer als die Konsequenzen, wenn der Raubüberfall in der Zukunft erneut durchgeführt wird.

Ein ständiger (Neu-)Balanceakt

Die Realität ist, dass Sicherheit ein ständiger Kampf ist, bei dem es darum geht, Risiken durch die Eindämmung von Bedrohungen zu minimieren und sich gleichzeitig durch das politische Minenfeld zu kämpfen, das die meisten IT-Organisationen ausmacht. Zu häufig verzichten Sicherheitsexperten auf die Umsetzung selbst einfacher Maßnahmen zur Risikominderung bei Bedrohungen mit schwankender Risikowahrscheinlichkeit, weil die IT in isolierten Funktionen existiert.

Sie warten, bis das Risiko steigt und eine Reaktion erzwungen wird, anstatt die Bedrohung proaktiv einzudämmen. Beispielsweise waren viele der am meisten diskutierten Exploits der letzten zwei Jahre application . Um diese Risiken einzudämmen, müssen Lösungen im Datenpfad vor der Application eingesetzt werden, denn der effizienteste und effektivste Ort hierfür ist nach wie vor der Punkt, an dem die Applications letztendlich zur Skalierung und Bereitstellung aggregiert werden. Dieser strategische Kontrollpunkt wird jedoch von Application verwaltet, nicht von Sicherheitsteams. Der Aufwand, solche Bedrohungen frühzeitig einzudämmen, überwiegt das Risiko. Weil die Fähigkeit dieser beiden Gruppen, sich sozusagen in der Mitte zu treffen, für Unternehmen weiterhin eine ständige Herausforderung darstellt, gelingt es ihnen einfach nicht, Risiken proaktiv zu reduzieren und Bedrohungen auf der Application einzudämmen.

HEIST wird derzeit für die meisten Organisationen wahrscheinlich als geringes Risiko eingestuft. Aber seien wir unbesorgt: Es handelt sich um eine Bedrohung und daher müssen wir uns jetzt Gedanken darüber machen, dass es sie gibt, bevor sie in die Tat umgesetzt wird. Es bedarf einer bereichsübergreifenden Koordination, damit „serverlose“ Sicherheitslösungen wie diese HEIST-Abwehr eingesetzt werden können, bevor die Bedrohung existenzielle Ausmaße annimmt und das Risiko einer Ausnutzung alle Beteiligten zu einem Wirbelwind kostspieliger Maßnahmen und Implementierungen zur Bekämpfung des Problems treibt.