Das WAF-Wirksamkeits-Framework: So messen Sie den Wirkungsgrad Ihrer WAF

Haben Sie sich jemals gefragt, wie effektiv Ihre WAF (Web Application Firewall) wirklich ist, ob sie Angriffe auch wirklich stoppt und wie viele falsch-positive Ergebnisse sie liefert? Oder möchten Sie vielleicht herausfinden, ob eine kürzlich erfolgte Änderung die bestehenden Erkennungsmöglichkeiten verbessert oder beeinträchtigt hat?

Die meisten WAF-Technologien sind ziemlich schwierig zu verwalten. Sie funktionieren mit langen Listen regulärer Ausdrücke, die wirklich niemand gerne pflegt. Bei so viel Ungewissheit ist es nur natürlich, dass man sich fragt, ob man überhaupt eine WAF nutzen soll.

Um Licht ins Dunkel zu bringen, haben wir ein WAF-Wirksamkeits-Framework entwickelt, das wir Ihnen im Folgenden genauer vorstellen möchten. Das Framework bietet ein standardisiertes Verfahren zur Messung der Effektivität der Erkennungsfunktionen einer WAF durch kontinuierliche Überprüfung und Validierung. Es hilft, Lücken zu erkennen und bietet eine Feedback-Schleife für Verbesserungen und Wartung. Es umfasst Auswertungen simulierter Angriffe zum Testen verschiedener Angriffsarten und fasst die Ergebnisse in einer Gesamtbewertung zusammen. Diese Ergebnisse fließen in einen Continuous-Improvement-Workflow ein, der als Stichprobenkontrolle der aktuellen Wirksamkeit oder für Trendanalysen der sich im Laufe der Zeit entwickelnden Wirksamkeit verwendet werden kann.

Unser Ansatz

Eine WAF prüft den HTTP/S-Traffic, bevor er einen Anwendungsserver erreicht. Sie können sich eine WAF als Vermittler zwischen einer Anwendung und einem Client vorstellen, der die gesamte Kommunikation zwischen ihnen analysiert. Sie überwacht verdächtigen und anomalen Traffic und schützt vor Angriffen, indem sie Anfragen auf Grundlage bestimmter Regeln blockiert, sodass unerwünschter Traffic von Ihrer Anwendung fernbleibt.

Eine HTTP/S-Anfrage umfasst:

Eine Domain (wie fastly.com)
Eine Ressource (wie /cat.png)
Eine Methode (GET, POST, PUT etc.)
Header (zusätzliche Informationen, die an den Server gesendet werden und Angreifern eine weitere Möglichkeit bieten, um schädliche Inhalte zu platzieren)

Außerdem wäre da noch ein zusätzlicher RequestBody. Im Gegensatz zu POST-Anfragen, die legitime Informationen senden oder unerwünschte Daten einspeisen können, enthalten GET-Anfragen in der Regel keinen Body.

Um dies zu veranschaulichen, hier eine HTTP 1.1 GET-Anfrage für fastly.com/cat.png:

Und dies ist ein Beispiel für eine POST-Anfrage mit einem JSON-Body:

Ob URL, Textkörper, Cookies oder andere HTTP-Header, Angreifer suchen immer nach Stellen in einer Anfrage, an denen sie leicht einen Angriff starten können. Deshalb geht es bei unserem Framework hauptsächlich darum zu prüfen, ob Payloads an verschiedenen Stellen einer Anfrage erkannt werden.

Wie bei allen Sicherheitstechnologien gilt auch hier: Wenn die Erkennungsmethoden stärker werden, suchen Angreifer nach Möglichkeiten, diese zu umgehen, damit sie ihre Ziele weiterhin erreichen können. Eine beliebte Methode zur Umgehung von WAFs besteht darin, Payloads so zu kodieren, dass sie nicht erkannt werden. Aus diesem Grund umfasst unser Framework auch Tests, die eine Mischung aus verschiedenen Kodierungstechniken enthalten. Wir injizieren jede vordefinierte Payload in jede Payload-Position und senden sowohl die unverschlüsselte als auch die verschlüsselte Version der Anfrage an das Ziel. Dies ist ein wertvolles Mittel, um die Erkennungsabdeckung zu testen, selbst wenn eine Umgehung vorliegt.

Aber natürlich ist es nicht so, dass eine magische Payload-Fee Payloads ganz einfach vom Himmel fallen lässt! Relevante Payloads können sich im Laufe der Zeit ändern, wenn sich Angriffsmethoden weiterentwickeln. Wir empfehlen PayloadsAllTheThings, PortSwigger, Nuclei, exploit-db und Twitter als Ausgangspunkt für die Pflege und regelmäßige Aktualisierung Ihrer Payload-Listen.

Sie brauchen keine anfällige Anwendung, um die Wirksamkeit einer WAF zu testen. Unser Ziel ist es, die Wirksamkeit der Erkennungsfunktionen einer WAF zu messen und nicht zu prüfen, ob in den Anwendungen selbst Schwachstellen vorhanden sind. Schließlich besteht das Endziel einer WAF darin, dass Schwachstellen in Ihren Anwendungen nicht mehr zu Sicherheitsproblemen führen. Die Bestätigung, dass Ihre WAF vor Angriffsklassen schützt, bedeutet, dass Sie sich nicht mehr um einzelne Schwachstellen kümmern müssen. Ein einfacher HTTP-Anfrage- und Antwortservice wie https://httpbin.org ist für unsere Zwecke also völlig ausreichend.

Für jeden Angriffstyp testen wir zwei verschiedene Fälle, um die Wirksamkeit der WAF zu bewerten: True Positives und False Positives. Ein True-Positive-Test stellt fest, ob Angriffs-Payloads korrekt identifiziert werden.

Ein False-Positive-Test ermittelt, ob akzeptable Payloads fälschlicherweise identifiziert werden. Um festzustellen, ob die WAF eine Anfrage korrekt identifiziert, wird der Statuscode der Antwort untersucht. Die meisten WAF-Lösungen sollten die Erstellung eines nutzerdefinierten Antwortstatuscodes für blockierte Anfragen unterstützen (ein Beispiel hierfür finden Sie in unserer Dokumentation). Wenn Ihre WAF-Lösung nicht in der Lage ist, nutzerdefinierte Antwortcodes festzulegen, sollten Sie Ihre Investition noch einmal überdenken.

Im Rahmen unseres WAF-Wirksamkeits-Frameworks suchen wir speziell nach der Ausgabe eines „406 Not Acceptable Response Code“, wenn eine Anfrage blockiert wird. In einem echt-positiven Testfall wird die Ausgabe eines anderen Antwortcodes als 406 als falsch-negativ angesehen. Umgekehrt wird in einem falsch-positiven Testfall die Ausgabe eines anderen Antwortcodes als 406 als echt-negativ betrachtet. Diese Ergebnisse werden verwendet, um pro Angriffstyp einen Wirksamkeits-Score zu berechnen. Diese Scores werden anschließend zu einer Gesamtbewertung des WAF-Wirkungsgrads für alle Angriffstypen zusammengefasst.

Auswertung der Ergebnisse

Wie verwandeln Sie nun ihre einzelnen und zusammengefassten Wirksamkeits-Messwerte in umsetzbare Erkenntnisse? Eine wichtige Grundlage für die Bewertung dieser Ergebnisse sind die Prioritäten Ihres Unternehmens. Maximiert Ihr Unternehmen lieber den Traffic zu seiner Anwendung, auch wenn dabei einige Angriffe durchs Raster fallen? Oder sollen lieber so viele Angriffe wie möglich geblockt werden, auch wenn dies zu einem niedrigeren Traffic-Volumen führt? Wir haben festgestellt, dass unsere Kunden meist eine Maximierung ihres Traffic-Volumens bevorzugen, da sich ein Rückgang auf die Einnahmen auswirken kann, was aus Unternehmenssicht die schlimmste der beiden Folgen ist.

In der Praxis ist ein unfehlbarer Schutz vor Web-Angriffen nicht möglich, es sei denn, man blockiert jede einzelne Anfrage. Dies würde aber den grundlegenden Zweck einer Web-Anwendung nicht nur in Frage stellen, sondern komplett zunichte machen. Aus diesem Grund ist das richtige Gleichgewicht zwischen falsch-positiven und falsch-negativen Ergebnissen ein Schlüsselfaktor bei der Bestimmung der Wirksamkeit einer WAF-Lösung. Bei jedem Sicherheitstool gibt es falsch-positive und falsch-negative Ergebnisse. Könnte man in allen Fällen 100 % sicher sein, gäbe es gar keine Security-Probleme mehr.

Je höher die False-Positive-Rate, desto wahrscheinlicher ist es, dass Sie einen Angriff erkennen. Aber auch legitimer Traffic wird fälschlicherweise als Angriff identifiziert– ein Problem, das im Blocking Mode noch häufiger auftritt. Hinzu kommt, dass ein falsch-positives Ergebnis wie ein falscher Alarm ist, und es in der Natur des Menschen liegt, Fehlalarme bei allzu häufigem Auftreten zu ignorieren. Dies erhöht nicht nur die Wahrscheinlichkeit, dass echter Angriffs-Traffic unberücksichtigt bleibt, sondern schmälert auch die Rendite Ihrer WAF. Darüber hinaus führen Fehlalarme zu einer Überlastung von Mitarbeitern, was letztendlich sogar eine höhere Fluktuation in den Teams zur Folge haben kann.

Auf der anderen Seite bedeutet eine höhere Falsch-Negativ-Rate eine geringere Wahrscheinlichkeit von False Positives, was zu einer hohen Zuverlässigkeit der Warnungen, aber auch zu einer höheren Wahrscheinlichkeit für nicht erkannten Angriffs-Traffic führt.

Um der Diskrepanz zwischen diesen negativen und positiven Ergebnisklassen Rechnung zu tragen, enthält unser WAF-Wirksamkeits-Framework eine Messgröße namens „ausgewogene Genauigkeit“. Diese Messgröße berücksichtigt die Unausgewogenheit
der Klassen und ist ein gutes Maß, wenn es gleichgültig ist, ob Sie die negativen oder die positiven Fälle richtig vorhersagen. Sie müssen diese Messgrößen lediglich sinnvoll für
Ihr Unternehmen und die von Ihnen geschützten Systeme nutzen. Mehr zur Berechnung der ausgewogenen Genauigkeit erfahren Sie später.

Automatisierung von Aufgaben

Manuelles Testen ist alles andere als einfach und kann schnell zu einer Sisyphos-Aufgabe werden, wenn man versucht, alle Möglichkeiten des Testens und der Ergebnismessung zu berücksichtigen. Dies gilt insbesondere bei großen Datensätzen von Angriffs-Payloads. Tests sollten reproduzierbar und flexibel sein, damit Sie sich auf die Ergebnisse konzentrieren können, um Ihre Web-Appsec-Strategie anhand konkreter Daten anzupassen.

Zu diesem Zweck haben wir uns als Grundlage für unser Framework für ein Open-Source-Projekt namens Nuclei entschieden. Nuclei übernimmt viele der mühsamen, manuellen und
repetitiven Aufgaben des Testens, indem es einfache YAML-Vorlagen nutzt. Nuclei Vorlagen legen fest, wie die Anfragen gesendet und verarbeitet werden. Außerdem sind sie vollständig konfigurierbar, sodass Sie jeden einzelnen Punkt der Anfragen, die gesendet werden, konfigurieren und definieren können.FF

Da das Sammeln von neuem Wissen für Feedback-Schleifen unerlässlich ist, wird jede Anfrage aufgezeichnet und im JSON-Format protokolliert. Die Logs enthalten Anfrage/Antwort-Paare und zusätzliche Metadaten. Sie können diese Protokolle für Dashboarding, historische Vergleiche und andere Erkenntnisse nutzen, die Ihnen helfen, Ihre WAF-Strategie zu verbessern. Als Beispiel haben wir die Ergebnisse in einen Google Cloud Storage Bucket (GCS) hochgeladen, der als Datensatz für die Erstellung einer Tabelle in BigQuery dient. Von dort aus haben wir die Daten mit Data Studio verknüpft, um informative Berichte mit Scores zu generieren.

Da Automatisierung Skalierbarkeit und Wiederholbarkeit ermöglicht und Ihnen und Ihrem Team mühsame Arbeit erspart, empfehlen wir, diese Schritte zu einer CI/CD-Pipeline für die Durchführung von WAF-Wirksamkeitstests zusammenzufassen. So definieren Sie einen Workflow:

Erstellen Sie Ihr Testziel.
Führen Sie Wirksamkeitstests durch.
Speichern Sie die Ergebnisse in einem Backend Ihrer
Wahl.
Generieren Sie Berichte.
Wiederholen Sie diesen Vorgang so oft Sie möchten.

Erste Schritte

Um auch der breiteren Sicherheits-Community den Zugriff auf diese Funktionen zu ermöglichen, hat das Fastly Security Research Team ein Open-Source-Projekt namens „wafefficacy“ ins Leben gerufen, das den Code und die Vorlagen enthält, die Sie für den Einstieg benötigen. Das Projekt bietet Boilerplate-Beispiele für Command Execution (cmdexe), SQL Injection (sqli), Traversal (traversal) und Cross-Site-Scripting (xss), sodass Sie sofort mit Ihren Wirksamkeitstests für die wichtigsten Angriffsarten beginnen können.

Vor der Durchführung von Wirksamkeitstests gilt es zwei Voraussetzungen zu prüfen:

Die WAF, die Sie testen, muss so konfiguriert sein, dass sie Angriffe blockiert.
Für blockierte Anfragen muss ein Antwortstatuscode gesetzt werden. Standardmäßig prüft wafefficacy auf die Ausgabe von „406 Not Acceptable“.

Sobald Sie die Ersteinrichtung abgeschlossen haben, können Sie das Skript run.sh aus dem Projektverzeichnis ausführen, indem Sie eine Ziel-URL oder einen Host angeben:

./run.sh -t https://example.com

Wenn die Bewertung abgeschlossen ist, zeigt das Skript die Ergebnisse in der folgenden Standardausgabe an:

Wirksamkeits-Score

Schauen wir uns nun an, wie wir die Wirksamkeits-Scores berechnen, indem wir die ausgewogene Genauigkeit als Messgröße verwenden.

Wir beginnen mit einer Konfusionsmatrix:

In den obigen Ausführungen bezieht sich „positiv“ oder „negativ“ in TP/FP/TN/FN auf die getroffene Vorhersage, nicht auf die tatsächliche Klasse. (Ein „False Positive“ ist also ein Fall, in dem unsere Vorhersage fälschlicherweise positiv ausgefallen ist).

Die ausgewogene Genauigkeit basiert auf zwei häufig verwendeten Metriken:

Die Sensitivität (auch bekannt als „True-Positive-Rate“) beantwortet die Frage, wie viele der positiven Fälle wir entdeckt haben.
Die Spezifität (auch bekannt als „True-Negative-Rate“ oder „1 minus Falsch-Positiv-Rate“) beantwortet die Frage, wie viele der negativen Fälle wir entdeckt haben.

Veranschaulichen wir doch einmal anhand eines Beispiels, dass die ausgewogene Genauigkeit eine bessere Beurteilung der Detections in unausgewogenen Klassen ermöglicht. Angenommen, wir simulieren SQL-Injection-Angriffe gegen eine WAF und erhalten die in der folgenden Konfusionsmatrix dargestellten Ergebnisse:

Diese Konfusionsmatrix zeigt, dass von 750 echt-positiven Testfällen 700 als True Positives und 50 als False Negatives angezeigt wurden. Außerdem wurden von 105 falsch-positiven
Testfällen 5 als False Positives und 100 als True Negatives erkannt.

Anhand dieser Informationen lässt sich wie folgt die ausgewogene Genauigkeit berechnen:

Basierend auf der Berechnung der ausgewogenen Genauigkeit beträgt der Wirkungsgrad der WAF beim Schutz vor SQL-Injection-Angriffen etwa 94,3 %.

Nehmen wir zum Vergleich an, dass wir eine andere WAF getestet haben und die falsch-positiven Ergebnisse invertiert waren. Von 105 falsch-positiven Testfällen wurden zum
Beispiel 100 als falsch-positiv und 5 als richtig-negativ angezeigt.

Dadurch würde sich der Prozentwert für die Spezifität wie folgt ändern:

Außerdem würde sich auch der Prozentwert für die ausgewogene Genauigkeit wie folgt ändern:

Anhand der ausgewogenen Genauigkeit können wir mit Sicherheit sagen, dass die erste WAF besser (94,3 %) als die zweite (49,1 %) vor SQL-Injection-Angriffen schützt.

Zusammenfassung

Stellen Sie Ihre Security-Lösung am besten selbst auf die Probe, bevor es jemand anderes tut. Unser WAF-Wirksamkeits-Framework beruht auf dem Konzept der kontinuierlichen Überprüfung und Validierung. Durch den Einsatz automatisierter Angriffssimulationen werden technische Sicherheitskontrollen validiert, Lücken aufgedeckt und eine Möglichkeit für Reporting und Messung der Wirksamkeit von Tools geschaffen. Diese Methodik lässt sich sogar auf jedes Sicherheitstool anwenden, das für Ihr Unternehmen oder Ihre Systeme relevant ist.

Die derartige Durchführung von Wirksamkeitstests ist eine Möglichkeit zur Einführung kontrollierter und sicherer Tests, mit denen Sie beobachten können, wie gut Ihre Sicherheitskontrollen unter realen Bedingungen reagieren. Sie kann ein äußerst wertvolles Instrument für die Einführung einer Feedback-Schleife sein, die dabei hilft zu verstehen, ob eine Sicherheitskontrolle korrekt und effektiv durchgeführt wurde.

Nutzen Sie unsere Verfahren und Tools, um die Wirksamkeit Ihrer WAF besser verstehen und gegebenenfalls verbessern zu können.

Wenn Sie mehr darüber erfahren möchten, wie wir Sie bei der Sicherheit Ihrer Webanwendungen unterstützen können, sehen Sie sich unsere Übersicht über unsere Sicherheitsprodukte an. Und wenn Sie an einer Zusammenarbeit interessiert sind, informieren Sie sich über unsere Stellenangebote.