Haben Sie sich jemals gefragt, wie effektiv Ihre WAF (Web Application Firewall) wirklich ist? Haben Sie sich gefragt, ob sie Angriffe auch wirklich stoppt? Wie viele False Positives erzeugt sie? Hat eine kürzliche Änderung die bestehenden Erkennung verbessert oder beeinträchtigt?
Die meisten WAF-Technologien sind ziemlich schwierig zu verwalten, 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.
Wir haben beschlossen, diese Fragen mit einem WAF-Wirksamkeits-Framework zu beantworten, das Gegenstand dieses Posts ist. 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, um verschiedene Angriffsarten zu testen, 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 App-Server erreicht. Sie können sich eine WAF als Vermittler zwischen einer App 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 Anforderungen auf Grundlage bestimmter Regeln blockiert, sodass unerwünschter Traffic Ihre App nie erreicht.
Eine HTTP/S-Anforderung umfasst:
Eine Domain (wie fastly.com)
Eine Ressource (wie /cat.png)
Eine Methode (GET, POST, PUT usw.)
Header (zusätzliche Informationen, die an den Server gesendet werden, und auch ein Ort, an dem Angreifer schädliche Inhalte platzieren können)
Es gibt auch einen optionalen Anforderungs-Body; GET-Anforderungen haben normalerweise keinen Body, während POST-Anforderungen – die legitime Informationen senden oder unerwünschte Inhalte einschleusen könnten – in der Regel einen Body enthalten.
Um dies zu veranschaulichen, hier eine HTTP 1.1 GET-Anforderung für fastly.com/DE/cat.png:
Und dies ist ein Beispiel für eine Post-Anforderung mit einem JSON-Body:
Ob URL, Textkörper, Cookies oder andere HTTP-Header, Angreifer suchen immer nach Stellen in einer Anforderung, 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 Anforderung 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 sowohl die unkodierte als auch die kodierte Version der Anforderung werden an das Ziel gesendet — 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 einfach vom Himmel fallen lässt — und 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 einer Liste von Payloads sowie für die regelmäßige Aktualisierung Ihrer Payload-Listen.
Sie brauchen keine anfällige App, um die Wirksamkeit einer WAF zu testen. Ziel ist es, die Wirksamkeit der Erkennungsfunktionen einer WAF zu messen, nicht zu prüfen, ob in den Anwendungen selbst Schwachstellen vorhanden sind. Schließlich besteht das angestrebte Endziel einer WAF darin, dass Schwachstellen in Ihren Apps nicht mehr zu Störungen führen; die Bestätigung, dass Ihre WAF vor Angriffsklassen schützt, bedeutet, dass Sie sich nicht mehr um Kleinigkeiten wie bestimmte Schwachstellen kümmern müssen. Daher ist die Verwendung eines einfachen HTTP-Anforderungs- und Antwortservice wie https://httpbin.org für diesen Zweck 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 Anforderung korrekt identifiziert, untersuchen wir den Antwortstatuscode. Die meisten WAF-Lösungen sollten die Erstellung eines benutzerdefinierten Antwortstatuscodes für blockierte Anforderungen unterstützen (ein Beispiel hierfür finden Sie in unserer Dokumentation). Wenn Ihre WAF-Lösung nicht in der Lage ist, Custom Antwortcodes festzulegen, sollten Sie Ihre Investition noch einmal überdenken.
Im Rahmen unseres WAF-Wirksamkeits-Frameworks achten wir speziell auf den Erhalt eines 406 Not Acceptable -Antwortcodes, wenn eine Anforderung blockiert wird. In einem echt-positiven Testfall wird der Erhalt eines anderen Antwortcodes als 406 als falsch-negativ angesehen. Umgekehrt wird in einem False Positiven Testfall der Erhalt eines anderen Antwortcodes als 406 als echt-negativ angesehen. Diese Ergebnisse werden verwendet, um pro Angriffstyp einen Wirksamkeits-Score zu berechnen; diese Scores werden anschließend zu einer Gesamtbewertung der WAF-Wirksamkeit für alle Angriffstypen zusammengefasst.
Auswertung der Ergebnisse
Wie generieren Sie nun ihre einzelnen und zusammengefassten Wirksamkeits-Metriken 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 App, 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 den Umsatz auswirken kann, was aus Unternehmenssicht die schlimmste der beiden Folgen ist.
In der Praxis ist ein unfehlbarer Schutz vor Web-Angriffen unmöglich – es sei denn, Sie blockieren buchstäblich jede Anforderung, was den grundlegenden Zweck des Betriebs einer App im Internet zunichtemacht. Aus diesem Grund ist das richtige Gleichgewicht zwischen False Positives und False Negatives ein Schlüsselfaktor bei der Bestimmung der Wirksamkeit einer WAF-Lösung. Jedes Sicherheitstool hat False Positives und False Negatives. Wenn es möglich wäre, in allen Fällen 100 % sicher zu sein, wäre Sicherheit ein gelöstes Problem.
Je höher die False-Positive-Rate, desto wahrscheinlicher ist es, dass Sie einen Angriff erkennen – aber legitimer Traffic wird fälschlicherweise als Angriff identifiziert, ein Problem, das im Blocking Mode nur noch verschärft wird. Hinzu kommt, dass ein False Positive wie ein Fehlalarm ist. Von Natur aus blenden Menschen Benachrichtigungen nach genügend False Positives aus, was nicht nur die Wahrscheinlichkeit erhöht, dass echter Angriffs-Traffic unbeachtet bleibt, sondern auch den Return on Investment Ihrer WAF schmälert. Es gibt auch einen kognitiven Preis: Der Umgang mit Fehlalarmen führt zu Burnout, was es für Menschen schwieriger macht, gute Leistungen zu erbringen, und zu einer höheren Fluktuation in Teams führen kann.
Auf der anderen Seite bedeutet eine höhere Falsch-Negativ-Rate eine geringere Wahrscheinlichkeit von False Positives, was zu hochpräzisen Benachrichtigungen führt – aber auch, dass die Wahrscheinlichkeit höher ist, dass echter Angriffs-Traffic nicht erkannt wird.
Um der Diskrepanz zwischen diesen negativen und positiven Ergebnisklassen Rechnung zu tragen, enthält unser WAF-Wirksamkeits-Framework eine Metrik namens „ausgewogene Genauigkeit“. Die ausgewogene Genauigkeit berücksichtigt die Unausgewogenheit der Klassen und ist ein gutes Maß, wenn es Ihnen gleichgültig ist, ob Sie die negativen oder die positiven Fälle richtig vorhersagen. Sie müssen diese Metriken lediglich sinnvoll für Ihr Unternehmen und die von Ihnen geschützten Systeme nutzen. Mehr zur Berechnung der ausgewogenen Genauigkeit erfahren Sie im folgenden Abschnitt.
Automatisierung von Aufgaben
Manuelles Testen ist alles andere als einfach und kann schnell zu einer nicht praktikablen Aufgabe werden, wenn Sie versuchen, alle Möglichkeiten zum Testen und Messen von Ergebnissen zu berücksichtigen. Dies gilt insbesondere bei der Arbeit mit 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 Belege anzupassen.
Zu diesem Zweck haben wir uns für ein Open-Source-Projekt namens Nuclei als Grundlage für das Framework entschieden. Nuclei übernimmt viele der mühsamen, manuellen und repetitiven Aufgaben des Testens, indem es einfache YAML-basierte Vorlagen nutzt. Nuclei Vorlagen legen fest, wie die Anforderungen gesendet und verarbeitet werden. Außerdem sind sie vollständig konfigurierbar, sodass Sie jeden einzelnen Aspekt der Anforderungen, die gesendet werden, konfigurieren und definieren können.
Da das Sammeln neuer Erkenntnisse entscheidend ist, um Feedback-Schleifen zu fördern, wird jede Anforderung aufgezeichnet und im JSON-Format protokolliert. Die Logs enthalten Anforderung/Antwort-Paare und zusätzliche Metadaten. Sie können diese Logs für Dashboarding, historische Vergleiche und andere Einblicke nutzen, die Ihnen helfen, Ihre WAF-Strategie zu verbessern. Als Beispiel haben wir die Ergebnisse in einen Google Cloud Storage (GCS) Bucket hochgeladen, der als Datensatz zum Erstellen einer Tabelle in BigQuery dient; von dort aus haben wir die Daten mit Data Studio verbunden, 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:
Build Sie Ihr Testziel
Führen Sie Wirksamkeitstests durch.
Speichern Sie die Ergebnisse in einem Backend Ihrer Wahl.
Berichte generieren
Wiederholen Sie diesen Vorgang in Ihrem bevorzugten Rhythmus
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 eines Wirksamkeitstests sind zwei Voraussetzungen zu prüfen:
Die WAF, die Sie testen, muss so konfiguriert sein, dass sie Angriffe blockiert.
Für blockierte Anforderungen 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 die ausführbare Binärdatei aus dem Projektverzeichnis ausführen, indem Sie eine Ziel-URL oder einen Host angeben:./wafefficacy run -u 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, wobei wir die ausgewogene Genauigkeit als Metrik 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 wir fälschlicherweise ein positives Ergebnis vorhergesagt haben.)
Die ausgewogene Genauigkeit basiert auf zwei häufig verwendeten Metriken:
Sensitivität (auch bekannt als True-Positive-Rate) beantwortet die Frage: „Wie viele der positiven Fälle habe ich erkannt?“
Die Spezifität (auch bekannt als True-Negative-Rate oder 1 - False-Positive-Rate) beantwortet dieselbe Frage: „Wie viele der negativen Fälle habe ich erkannt?“
Veranschaulichen wir anhand eines Beispiels, wie die ausgewogene Genauigkeit bei unausgewogenen Klassen ein besseres Maß für Erkennungen sein kann. Angenommen, wir simulieren SQL-Injection-Angriffe gegen eine WAF und erhalten die in der folgenden Konfusionsmatrix dargestellten Ergebnisse:
Diese Konfusionsmatrix zeigt, dass von 750 True-Positive-Testfällen 700 als True Positives und 50 als False Negatives angezeigt wurden. Außerdem wurden von 105 False-Positive-Testfällen 5 als False Positives und 100 als True Negatives angezeigt.
Anhand dieser Informationen lässt sich wie folgt die ausgewogene Genauigkeit berechnen:
Basierend auf der Berechnung der ausgewogenen Genauigkeit ist die WAF beim Schutz vor SQL-Injection-Angriffen etwa 94,3 % wirksam.
Nehmen wir zum Vergleich an, dass wir eine andere WAF getestet haben und die False Positive-Ergebnisse invertiert waren. Von 105 False Positiven Testfällen wurden zum Beispiel 100 als False 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 Sicherheit 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 Kontrollen 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 Kontrolle korrekt und effektiv implementiert wurde.
Nutzen Sie unsere Verfahren und Tools, um die Wirksamkeit Ihrer WAF besser zu verstehen und hoffentlich zu verbessern.
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 mit uns interessiert sind, informieren Sie sich über unsere Stellenangebote.
Playbook: Cloudnative AppSec
Verstehen Sie die zunehmend ausgefeilten Techniken, mit denen Angreifer Enterprise-Webanwendungen ins Visier nehmen, und wie Sie diese verhindern können. Dieses Playbook liefert Engineering-, Operations- und Sicherheitsteams das „Wie“ und „Warum“ der cloudnativen Anwendungssicherheit. E-Book herunterladen