kentoh - Fotolia
Die Herausforderungen für Web Application Firewalls
Webanwendungen werden häufig mit Web Application Firewalls abgesichert. In Zeiten von DevOps und schnellen Entwicklungszyklen kann der WAF-Betrieb eine Herausforderung sein.
In den letzten Jahrzehnten hat sich die Web Application Firewall (WAF) zu einem allgegenwärtigen Teil der meisten IT-Absicherungen entwickelt. Jede Organisation mit einer Webanwendung – was die meisten großen Unternehmen und Konzerne einschließt – hat eine WAF installiert, um deren Daten und Werte gegen Angriffe zu schützen. Diese Verallgemeinerung hat jedoch dazu geführt, dass es als Best Practice für die Absicherung von Webanwendungen angesehen wird, schlicht eine WAF vor die Nase des Programms zu setzen.
Dagegen steht jedoch die Tatsache, dass die DevOps-Gruppen mittlerweile Updates für Anwendungen in viel höherer Frequenz erstellen können. Hier kann aber die lange bewährte Web Application Firewall nicht mehr Schritt halten, was ihre Wartung aufwendig und kompliziert macht, um sie überhaupt am Laufen zu halten.
Nun gilt es sich zu fragen, wie dennoch verhindert werden kann, dass Webanwendungen zur Eingangstür für Hacker in die IT-Infrastruktur des Unternehmens würden. Damit korreliert die Frage, ob sich der Aufwand noch lohnt, eine WAF trotzdem zu betreiben, obwohl die DevOps-Abteilung ständig neuen Code entwickelt, der eingepflegt werden muss. Vor dieser Herausforderung stehen derzeit viele Firmen. Welche Hürden stellen sich konkret in den Weg einer WAF?
Erstens: Inhaltsbezogene Analyse
Während sich bei der Netzwerksicherheit alles um die Überwachung statischer Netzwerke dreht, die untereinander die gleichen Protokolle verwenden, wurden WAFs entwickelt, um Webanwendungen zu schützen, die sich deutlich unterscheiden. Jedes Programm ist einzigartig und jedes Stück eines Codes ist anders gebaut und verfügt leider über seinen eigenen Satz von Schwachstellen.
Es gilt zu bedenken: Schon vor der Einführung von Cloud-Speichern und der Verwirklichung der DevOps-Geschwindigkeit wurden WAFs nur als mittelmäßige Sicherheitslösung angesehen. Der Grund ist einfach: Die Verwendung einer Sicherheitslösung, die vor der zu schützenden Anwendung sitzt, bedeutet unweigerlich, dass eine inhaltsbezogene Analyse der Bedrohungslage unmöglich ist. Ohne den Kontext aber kann die WAF den Inhalt der Applikation, mit der sie interagiert nicht verstehen. Es ist daher außerdem unmöglich, die Entwicklung einer WAF parallel zur Entwicklung einer Anwendung automatisiert laufen zu lassen.
Zweitens: Maschinelles Lernen
Verbesserungen durch maschinelles Lernen haben dieses Rätsel nur bis zu einem gewissen Grad gelöst. Hochentwickelte WAFs benötigen zwar nur noch einen Monat, um genug gelernt zu haben, dass sie eine grundlegende Richtlinie für eine Anwendung erstellen können, doch ein Monat des Wartens ist eine lange Zeit. Derweil ist die Applikation weitestgehend ungeschützt im Internet verfügbar. Es ist in diesem Fall unvermeidlich, dass Menschen eingreifen und bei der Kalibrierung der WAF helfen müssen. Das aber ist der Zeitpunkt, zu dem die Wartung der WAF zur Schwerstarbeit wird.
Wenn die WAF jedoch einige Zeit braucht, um für jede Baseline zu lernen – oder sogar neu zu lernen, sobald sich der Inhalt oder der Code einer Anwendung verändert – gibt es für den zuständigen Administrator dauernd sehr viel zu tun, um Warnungen zu reduzieren, Fehlalarme zu bearbeiten und Ausnahmen zu erstellen. Fachkräfte werden gebunden, die an anderen Stellen viel dringender benötigt würden, um große Projekte zu betreuen.
Drittens: Automatisierung
Deutlich zeigt sich, dass eine WAF bei kontinuierlicher Bereitstellung nicht selbstständig eine Webanwendung im aktuellen Umfeld von DevOps schützen kann, ohne menschliches Eingreifen zu erfordern. Die erschreckende Wirklichkeit lautet daher, dass sich die meisten WAFs derzeit nicht im Alarmzustand befinden, denn: Ihnen zu erlauben, sehr viel zu blockieren, ist gefährlich, weil die hohe Anzahl von echten oder falschen Alarmen zu einer Ermüdung des Personals führen würde. Die Aufmerksamkeit und Sensibilität sinken.
„Deutlich zeigt sich, dass eine WAF bei kontinuierlicher Bereitstellung nicht selbstständig eine Webanwendung im aktuellen Umfeld von DevOps schützen kann, ohne menschliches Eingreifen zu erfordern.“
Christine Schönig, Check Point Software Technologies GmbH
Natürlich kann ein Administrator eine Feinabstimmung vornehmen, sodass sensible Teile der Webanwendung von Blockierungsregeln gedeckt werden, doch der Rest wird von der WAF im Alarmmodus plump durch Musterabgleich und andere grobe Techniken geschützt. Dies erschafft eine Sicherheitslösung, die unfähig ist, sich automatisch anzupassen, um ihre zugehörige Anwendung gegen neue logische Angriffe zu schützen, während die Anwendung verbessert und verändert wird. Sie kann den Prozess der Entwicklung nicht mitgehen.
Den Wandel akzeptieren
Native Cloud Computing lebt von der Agilität. Was 2015 noch zwei Wochen dauerte, geschieht nun in wenigen Sekunden und wegen der Einführung neuer Mikrodienste kann und muss eine Anwendung oft in wenigen Minuten drastisch verändert werden. In dieser neuartigen IT-Umgebung ist es absurd, eine Sicherheitslösung für die Anwendungssicherheit zu verwenden, die nicht für diese Cloud-Idee geschaffen wurde, sondern auf langwieriges Lernen und aufwendige manuelle Konfiguration angewiesen ist.
Am schlimmsten wird es, wenn ein Entwickler, wie so häufig, den Code ändert, ohne Rücksprache mit den Sicherheitsleuten zu halten, und die WAF davon ausgeht, dass alles in der Netzwerkumgebung generisch ist, also keine logischen Verknüpfungen im Kontext erstellt. Dann ist sie schlichtweg nicht mehr funktionsfähig. Somit hat DevOps-Geschwindigkeit das Ende der WAF eingeläutet. Alle Verantwortlichen sollten daher dieser Sicherheitslösung nicht mehr hinterhertrauern, sondern den Wandel akzeptieren und die WAF außer Dienst stellen. Nun muss eine für die Cloud entwickelte Sicherheitslösung den Schutz der Anwendungen übernehmen, die alle Vorteile der neuen IT-Umgebungen für sich nutzen kann. Das kann sie besonders als Teil einer umfangreichen IT-Sicherheitsarchitektur, die nicht nur einen Bereich abdeckt, sondern mehrere Aspekte der IT-Sicherheit bedient und daher aufeinander abgestimmte Schutzmaßnahmen bereit hält.
Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.