OWASP Top 10: Kritischer Blick auf die Charts

Die Entwicklung der OWASP Top 10, einer Liste von Sicherheitsrisiken, fand Ende 2017 erstmals öffentlich statt. Die Neuerungen können sich sehen lassen, boten aber auch Stoff für Diskussionen.

Know-how  –  0 Kommentare
OWASP Top 10: Kritischer Blick auf die Charts

Ende November 2017 sind nach einigen anfänglichen Widrigkeiten die vom OWASP benannten Top-10- Sicherheitsrisiken in ihrer sechsten Auflage erschienen.

OWASP ist das "Open Web Application Security Project" – eine nach amerikanischem Recht gemeinnützige Organisation, die Softwaresicherheit sichtbarer machen will. Dazu dienen Tools und zahlreiche Dokumente, die alle unter einer FOSS-Lizenz stehen. Jeder kann Beiträge leisten.

Erstmals hatte die Entwicklung an dem Awareness-Dokument wirklich öffentlich stattgefunden. Mit etwas Abstand betrachtet stellt sich die Frage, wie die Top 10 zu bewerten sind und wie die Öffentlichkeit sie aufgenommen hat.

Die 2017er Ausgabe hat eine längere Geschichte – mit gutem Ende. Obwohl die Top 10 ein sogenanntes Flaggschiffprojekt vom OWASP sind, lud sie durch die Open-Source-Brille betrachtet bisher nicht gerade zur Zusammenarbeit ein. Die vorigen Autoren schrieben üblicherweise eine Nachricht

mit einem Inhalt wie "hier ist der RC1 als PDF, schaut mal drüber" an die entsprechende Mailing-Liste und klebten ihr Firmenlogo drauf. Die Top 10 für 2017 hatten dieselben Anfänge und sollten planmäßig im Juli oder August 2017 erscheinen.

Allerdings hatten die beiden Autoren zwei Punkte in ihren Release-Kandidaten 1 hineingeschrieben, bei denen sie die Rechnung ohne den Wirt OWASP gemacht haben: Zumindest der siebte Eintrag (A7) "Insufficient Attack Protection" war ein Reibungspunkt. Zum einen in technischer Hinsicht – viele Leute haben sich beschwert, dass der Punkt als Anreiz geeignet sei, defekte Software weniger zu fixen und stattdessen durch andere Maßnahmen Löcher mehr oder weniger gut zu kaschieren. Zum anderen lag ein Interessenkonflikt vor: Die Ankündigung des RC1 und ein Eintrag im Firmenblog waren nicht nur beide am 10. April erschienen, sondern in A7 war namentlich das recht seltene Produkt RASP (Runtime Application Self-Protection) im Release-Kandidaten referenziert ("You can use technologies like WAFs, RASP, and OWASP AppSensor to detect or block attacks, and/or virtually patch vulnerabilities."). Die Empörung außerhalb und innerhalb vom OWASP war schließlich dermaßen groß, dass zwei Monate später die Teilnehmer des OWASP Summit, einer Arbeitskonferenz, die langjährige Leitung des Projektes abgelöst und den RC1 zurückgezogen haben.

Das neue vierköpfige Team hatte Mitte Oktober den neuen Release-Kandidaten 2 auf der GitHub-Plattform veröffentlicht, die zur echten Zusammenarbeit einlädt. Diskussionen fanden auf dem Weg zum RC2 und zum Release nur dort statt – in zeitgemäßer, transparenter Weise. Das bewirkte, dass viele die Chance zum Mitdiskutieren genutzt haben – der Anhang zur Top 10 erwähnt schließlich die aktiven Beteiligten mit ihrem Handle oder sogar namentlich.

Angesichts der dadurch resultierenden Mehrarbeit für das Team war es umso erfreulicher, dass es den Zeitplan dennoch einhalten konnte und am 21.11.2017 die finale Version der Top 10 erschienen ist.

Das Deckblatt der OWASP Top 10 2017 trägt den Untertitel "The Ten Most Critical Web Application Security Risks". Das führt zu der Frage, wie die Beteiligten die kritischsten zehn Risiken ermittelt haben.

Wie zuvor dienten als Grundlage Daten, die aus dem sogenannten "Data Call" stammen. Dabei bat das Team Hersteller und Institutionen, ihre Scan-Ergebnisse einzusenden. Die Rückläufe hat es ausgewertet und einem sogenannten Risk Rating unterzogen (s. Abb. 1).

Risikobewertung nach OWASP mit den Faktoren in der ersten Zeile (von Threat Agents bis Weakness Detectability). Das technische Risiko stellt der "Technical Impact" dar (Abb. 1). (Bild: Bildlizenz(en): CC-BY-SA 4.0, owasp.org, unverändert.)

Grundsätzlich ist ein Risiko das mathematische Produkt aus Schadeneintrittswahrscheinlichkeit und dem Schadenausmaß. In ersteren Faktor sind Daten der Data Calls eingeflossen (Weakness Prevalence). Wie man dem Risk Rating entnehmen kann, hat das Team die Daten ähnlich wie bei CVSS noch gewichtet, je nachdem

  • wie leicht die Lücke auszunutzen ist (Exploitability) und
  • wie einfach sie zu entdecken ist (Weakness Detectability).

Beispielsweise ist das Schadensausmaß bei SQL Injection immer der GAU, auch wenn die Häufigkeit des Auftretens geringer ist als bei Cross-Site Scripting (XSS). Mehr zu den Risiken ist den Seiten 5, 21 und 22 des Reports zu entnehmen.

Die OWASP Top 10 können nur technische Risiken beurteilen – das Businessrisiko mag im Einzelfall anders sein und lässt sich über die technische Betrachtung nicht ermitteln: Eine SQL Injection auf einem längst vergessenen Server in einem ungepatchen CMS, das außer Webseiten keine Informationssicherheitswerte bietet, hat sicherlich eine andere wirtschaftliche Konsequenz für die betroffene Organisation als ein gehacktes Finanzportal.

Dem Data Call sind jedoch nur acht der zehn Punkte entnommen. Die restlichen beiden kamen aus einer Firmenumfrage und sind nach vorne gerichtete Punkte, also solche, die für die nächsten drei bis vier Jahre relevant sein sollen.

Was viele vergessen: Neben den ersten zehn gibt es eine Reihe lesenswerter einleitender sowie abschließender Seiten, auf denen die Macher erklären, was ein Risiko ist und wie es die zehn Plätze besetzt hat.

Die zusätzlichen Seiten verdeutlichen, was die OWASP Top 10 darstellen: ein Awareness-Dokument, bei dem Application Security anfängt. Nach den zehn Punkten nimmt das Dokument die unterschiedlichen Zielgruppen wie Entwickler, Security Tester, Organisationen und neuerdings Application-Manager unter dem Titel "What's next" an die Hand. In den weiterführenden Tipps sind auf jeweils einer Seite fünf oder sechs grundlegende Punkte für die einzelnen Zielgruppen zu finden. Aus Security-Managementsicht sind es somit die wirklich wichtigen Seiten.

Leider fokussieren sich viele nur auf die eigentlichen Top 10. Besonders das Marketing vieler Hersteller und Dienstleister ist regelmäßig ein falsch verstandener Anlass zum Phrasendreschen.

Dabei sind sie explizit nicht

  • ein heiliger Gral der Websicherheit,
  • die Abdeckung aller Risiken,
  • eine Darstellung des SDLC (Software Development Lifecycle Project),
  • eine Schablone für Pentests,
  • eine Richtlinie, nach der sich WAF-Hersteller (Web Application Framework) oder DAST-Scanner-Anbieter (Dynamic Application Security Testing) ab sofort und ausschließlich richten müssen.

OWASP weiß von den fachlichen Fehlinterpretationen, die es jedoch auch mit einem lachenden Auge betrachtet, da die OWASP Top 10 der am häufigsten zitierte Standard der Applikationssicherheit sind. Die Ausreißer nimmt man dabei in Kauf – frei nach dem Sprichwort "There is no such thing as bad publicity": Auch eine schlechte Werbung ist hilfreich.