Herkömmliche WAFs: Vier Gründe, warum diese veraltete Technologie nicht genügend Schutz für Ihre Anwendungen bietet
Web Application Firewalls (WAFs) sind eine altbewährte Technologie, die von Generation zu Generation weitergereicht wurde – vom Datacenter über die Cloud bis hin zu Serverless. Und doch sind sie selten effektiv und weitgehend unbeliebt. Im Bereich der Web Application Security gibt es einige schlecht gehütete Geheimnisse, aber wohl keines ist größer als dieses: Die herkömmliche WAF hat nicht überlebt, weil sie bestens funktioniert, sondern weil ihre Verwendung von oben diktiert wurde.
Die herkömmliche WAF hat nicht überlebt, weil sie bestens funktioniert, sondern weil ihre Verwendung von oben diktiert wurde.
In diesem Post wollen wir uns näher mit der Geschichte der WAF befassen, einschließlich der Frage, warum sie überall im Einsatz ist, obwohl sie ihren Zweck oft nicht vollständig erfüllt – und was Sie dagegen tun können.
Die herkömmliche WAF: eine veraltete Technologie
Traditionelle, perimeterbasierte WAFs beruhen auf einer veralteten Technologie, die entwickelt wurde, um den Anstieg von Sicherheitslücken einzudämmen, von denen Unternehmen zunehmend überfordert waren. Statische und dynamische Analysetools überfluteten Entwicklerteams mit riesigen Mengen an Bugs, sodass diese keine Möglichkeit hatten, die ganzen Codeprobleme zu beheben.
Die WAF war als Überbrückungsmaßnahme gedacht, um dieses Problem anzugehen. Sie ermöglichte es, ausufernde SQLi-, Command-Execution- und XSS-Angriffe herauszufiltern, die alle verfügbaren Ressourcen von Entwickler- und Sicherheitsteams aufzuzehren drohten. Die Idee hinter der herkömmlichen WAF war, dass die Anwendungs-Bugs und Sicherheitslücken vorläufig ausgemerzt werden sollten, um den Ursprung des Problems schließlich im Code zu beheben.
Zum damaligen Zeitpunkt erschien ein Drop-in-Sicherheitsfilter für Webanwendungen als gute Idee. Manchmal führte das zwar dazu, dass legitimer Traffic blockiert wurde, aber es bot zumindest ein gewisses Maß an Schutz auf Anwendungsebene – also dort, wo Compliance-Systeme verzweifelt nach Lösungen suchten. Dann kamen dieVorschriften der Payment Card Industry (PCI) ins Spiel, und die Situation änderte sich vollkommen.
PCI-Anforderung 6.6 besagt, dass Sie entweder eine WAF einsetzen oder eine gründliche Codeüberprüfung bei jeder Änderung an der Anwendung durchführen müssen. Da die zweite Option ziemlich unattraktiv war, verstanden die meisten Unternehmen dies als Aufforderung, sich eine WAF zuzulegen. Mit anderen Worten: Sicherheitsverantwortliche installierten WAFs nicht wegen ihrer sicherheitsrelevanten Bedeutung – sie wollten nur ihre obligatorische PCI-Zertifizierung bestehen. Man kann mit Recht behaupten, dass PCI den Markt an herkömmlichen WAFs von einer interessanten Idee zu dem Giganten gemacht hat, der er heute ist.
Und es gibt sie immer noch, diese veraltete Technologie, die eher durch Floskeln und irrtümliche Annahmen als durch tatsächlichen Nutzen gestützt wird und ein falsches Gefühl von Sicherheit vermittelt, ohne viel zu leisten. Wenn das für Sie nicht Grund genug ist, um Ihrer vorhandenen WAF den Laufpass zu geben, finden Sie hier vier weitere Gründe, warum Sie Ihre veralteten WAFs ersetzen sollten.
1. Der Ansatz, ein Minimum an WAF-Regeln zu nutzen, ist gescheitert
Ein häufiger Nebeneffekt einer herkömmlichen WAF-Implementierung ist die Blockierung von legitimem Traffic. In der Anwendungssicherheitsbranche nennen wir diese Fehlalarme „False Positives“. Lassen Sie sich von dieser harmlosen Formulierung nicht täuschen. Sie bedeutet nämlich, dass Kunden nicht in der Lage sind, Dinge zu kaufen, die sie haben möchten, ihre neuesten Urlaubsfotos hochzuladen oder generell die Funktionen Ihrer Anwendungen zu nutzen. Das ist die Art von Erfahrung, die aktuelle Kunden schnell zu ehemaligen Kunden machen kann.
Um False Positives von herkömmlichen WAFs zu verhindern, beschränken die meisten Unternehmen die Anzahl der Regeln auf ein absolutes Minimum.
Um False Positives von herkömmlichen WAFs zu verhindern, beschränken die meisten Unternehmen die Anzahl der Regeln auf ein absolutes Minimum. Dadurch werden aber nur die offensichtlichsten und schwerwiegendsten Angriffe abgefangen. Alle anderen laufen einfach am Filter vorbei. Einfache Regeln lassen sich leicht umgehen. Und das führt dazu, dass Ihre WAF letztendlich keinen effektiven Schutz bietet.
2. Der Learning Mode scheitert an seiner Geschwindigkeit
Eine Möglichkeit, wie veraltete WAFs versuchen, False Positives zu reduzieren und zu vermeiden, dass legitimer Traffic herausgefiltert wird, besteht in der Nutzung eines „Lernmodus“. Im Learning Mode lernt die herkömmliche WAF, wie normaler und bösartiger Traffic aussieht, und bietet entsprechenden Schutz. Wir könnten Bände darüber schreiben, wie schwierig es ist, den Learning Mode selbst unter perfekten Bedingungen richtig zu nutzen. Aber kommen wir zu dem eigentlichen Problem, das wir in Produktivumgebungen beobachten.
Lernen braucht Zeit. Herkömmliche WAFs, die lernen müssen, „normales Verhalten“ zu erkennen, müssen zunächst eine gewisse Menge an Traffic ins Visier nehmen, bevor sie alles andere aktiv blockieren können. Bis sie sichere Muster im Anwendungs-Traffic erkennen, können Stunden vergehen.
Wenn Sie von einem Wasserfallmodell zu Agile-Methoden und DevOps übergehen, erhöht sich die Bereitstellungsgeschwindigkeit immer mehr. Der Anwendungscode ändert sich wöchentlich, täglich oder sogar stündlich. Wenn Sie neuen Code auch nur annähernd in Echtzeit bereitstellen, bedeutet das, dass Sie Ihre herkömmliche WAF bei jeder Codeänderung in den Lernmodus versetzen müssen. Im Grunde genommen kann jede Art von Learning Mode, wenn er auf moderne Anwendungsentwicklungstechniken angewendet wird, einfach nicht mit dem Produktionstempo mithalten.
3. Der Monitoring Mode ist nicht dasselbe wie Compliance
Die Tatsache, dass herkömmliche WAFs eher aufgrund gesetzlicher Vorgaben als wegen ihrer Effektivität überlebt haben, ist nicht das einzige offene Geheimnis in der Branche. Deshalb ist es auch nicht verwunderlich, dass die meisten Unternehmen ihre veraltete WAF nie in den aktiven Blockiermodus (Blocking Mode) versetzen. Schließlich gibt es im Blocking Mode eine hohe Falsch-Positiv-Rate und legitimer Traffic wird herausgefiltert. Dieser Modus eignet sich also nur dann, wenn Sie Ihre Anwendung zum Erliegen bringen möchten.
Stattdessen werden herkömmliche WAFs oft im Überwachungsmodus (Monitoring Mode) betrieben, wo sie den Traffic beobachten und jedes Ereignis als Angriff protokollieren. Vor einem Compliance Audit, wird die herkömmliche WAF kurz eingeschaltet und anschließend wieder ausgeschaltet. In der Praxis ist es einigen Prüfern tatsächlich egal, ob Sie Ihre WAF im aktiven Blocking Mode betreiben. Sie geben sich schon alleine mit der Tatsache zufrieden, dass Sie überhaupt eine WAF haben.
Vor einem Compliance Audit, wird die herkömmliche WAF kurz eingeschaltet und anschließend wieder ausgeschaltet.
Ihre WAF im Monitoring Mode zu betreiben, stellt keine effektive Kontrolle dar. Es führt lediglich zu einem falschen Sicherheitsgefühl und bedeutet zusätzlichen Aufwand für das Sicherheitsteam bei der Auswertung der Logs. In diesem Szenario geben Sie unnötig Geld aus und erhalten im Gegenzug so gut wie keinen Schutz.
4. Herkömmliche WAFs erfordern kostspielige Regelanpassungen
Eine weitere Voraussetzung für den Betrieb einer traditionellen, perimeterbasierten WAF ist, dass Sie sich an Regelanpassungen gewöhnen müssen, um False Positives zu vermeiden – und zwar jede Menge davon. Die meisten Anbieter traditioneller WAFs haben die Angewohnheit, diesen Wartungsaufwand zu beschönigen, um den Prozess für Kunden, die wissen, dass sie ihre Produktionsanwendungen und APIs schützen müssen, attraktiv zu machen. Sie verkaufen Ihnen ein „Servicepaket“, in dem das Tuning als erstklassiges Erlebnis vermarktet und verkauft wird. Das klingt gut, kostet Sie aber einen Aufpreis. Andere Security-Anbieter sagen ihren Kunden sogar, dass die Beseitigung von False Positives ein selbstverständlicher Teil eines WAF-Systems sein sollte!
Unabhängig davon, ob die Regelanpassungen einer herkömmlichen WAF ausgelagert oder intern gehandhabt werden, können zusätzliche Kosten auf Unternehmen zukommen, die bei der Evaluierung von Anbietern oft nicht berücksichtigt werden. Professional Services können je nach Qualifikation des Personals und Komplexität des Tunings Vor- oder Nachteile haben. Und die Kosten dafür können sich schnell summieren, wenn sie auf einem Stundensatz basieren. Das Tuning intern durchzuführen, kann anfangs eine praktikable Option sein, wenn Sie über sachkundige Mitarbeiter verfügen, lässt sich aber nicht skalieren, wenn die Code-Base einer Anwendung immer komplexer wird und die Angriffsfläche wächst.
WAFs mit veralteten Nutzeroberflächen, die vor zehn Jahren oder mehr entwickelt wurden, sind oft schwer zu erlernen und zu bedienen. Außerdem wird die WAF-Abstimmung mit der Zeit von einer Teilzeitaufgabe eines Teammitglieds zu einer Vollzeitaufgabe, da immer mehr Anwendungen und APIs bereitgestellt werden, um das Wachstum und die Wettbewerbsfähigkeit eines Unternehmens auf dem Markt zu steigern. Für diese Aufgaben wird zusätzliches, speziell für die Verwaltung der WAF geschultes Personal eingestellt, was sich wiederum auf das Budget und die Ressourcen der Abteilung auswirkt.
Die Lösung: eine Next-Gen WAF, die Schutz für das moderne Internet bietet
Begnügen Sie sich nicht mit Compliance. Es gibt neue Optionen, um den Schutz auf dem Application-Layer zu erhöhen und gleichzeitig die Compliance sicherzustellen – zum Beispiel den Einsatz einer Next-Gen WAF (NGWAF), die eine anwendungsspezifische Absicherung bietet. Anstatt nur die PCI-Anforderungen zu erfüllen, können Sie sich aktiv gegen die schwerwiegendsten Risiken, die sogenannten OWASP Top 10, Account-Übernahmen, Instrumentierung der Business Logic und die Abwehr von Bots verteidigen – und das alles, ohne legitime Kundenaktivitäten zu beeinträchtigen.
