Zero Trust mit verteilter Zugriffskontrolle
Die rasche Zunahme von API-Attacken, Denial-of-Service und bösartigen Bots stellt traditionelle Web Application Firewalls vor neue Herausforderungen. Der erste Teil dieses Artikels ging darauf ein, wie moderne Sicherheitslösungen diesen Bedrohungen begegnen: Mit vielfältigen Schutzmechanismen und künstlicher Intelligenz.
Hier im zweiten Teil geht es darum, wie sich eine identitätsbasierte Zero-Trust-Architektur umsetzen lässt, um insbesondere Cloud-native Anwendungen vor unbefugten Zugriffen zu schützen. Zudem geben wir Tipps für die Auswahl einer geeigneten WAAP-Schutzlösung.
Kritik und Herausforderungen
WAAP ist eine wirksame Ergänzung, um Web-Anwendungen und APIs vor aktuellen Bedrohungen und Angriffen zu schützen. Zu einer umfassenden Sicherheitsstrategie gehört ein ganzes Bündel von Massnahmen: Automatisierte Schwachstellen-Scans, regelmässige Penetrationstests oder die Ausbildung im Bereich sichere Programmierung. Als weitere wichtige Hürden gegen Angreifer gelten auch eine starke Authentifizierung und strenge Zugriffsberechtigungen. Diese Kontrollen finden idealerweise vor dem Zugriff auf die Anwendung statt, wobei das Login häufig an ein Identity und Access Management System (IAM) delegiert wird.
Kritiker bemängeln, dass die negativen Sicherheitsfilter durch professionelle Hacker ausgetrickst werden können. Diese Kritik ist allenfalls bei Systemen berechtigt, die jeder einzelnen Schwachstelle mit einer entsprechenden Signatur begegnen. Solche signaturbasierten Filter können bei Variation des Angriffes oder durch geschickte Codierung umgangen werden, im Englischen spricht man dann von einer "Filter Evasion". Moderne WAAP-Lösungen hingegen führen zuerst eine mehrfache Decodierung und Normalisierung der Daten durch bevor die Angriffserkennung startet. Mit struktureller Intelligenz und wenigen Regeln sind sie zudem in der Lage, nicht nur einzelne Angriffsbeispiele, sondern ganze Angriffsklassen zu erkennen.
Microgateways für Container und Zero Trust
Der Trend zu Microservices, Continuous Delivery und kurzen Release-Zyklen kann für WAAP-Systeme ebenfalls eine Herausforderung sein, vor allem wenn sie zentral durch die IT-Abteilung gemanagt werden. Wenn eine Anwendungsänderung auch nur kleine Anpassungen der Sicherheitsregeln bedingt, kann die Koordination zwischen WAAP-Betreiber und App-Eigentümer schnell zum Flaschenhals werden. Um solchen Verzögerungen aus dem Weg zu gehen, werden die WAAP-Funktionen manchmal auch ganz ausser Kraft gesetzt — hoffentlich nur vorübergehend.
Dieses Problem kann mit Dezentralisierung und zusätzlichen Befugnissen für die Anwendungsteams gelöst werden. Die Schutzkomponente wird in Richtung Anwendung verschoben: Statt nur auf eine zentrale Filterung zu setzen, erhält jede Anwendung oder API zusätzlich ein eigenes kleines Schutzsystem. Diese leichtgewichtigen «Mini-WAAPs» leben meist im gleichen Container wie der geschützte Microservice und werden deshalb Microgateways genannt.
Das Anwendungsteam wird gewissermassen selbst zum WAAP-Betreiber und erhält damit mehr Autonomie bei den Sicherheitsregeln. Ganz im Sinne von «Shift Left» können die Schutzfunktionen sehr einfach bereits während der Entwicklung oder beim Testen aktiviert werden. Das reduziert den Abstimmungsaufwand und mögliche Feuerwehrübungen kurz vor dem Release. Mit dieser dezentralisierten Ausprägung von WAAP ist eine Zero-Trust-Architektur möglich, bei der jeder Zugriff «vor Ort» nochmals überprüft und autorisiert wird.
Checkliste:
Sechs Fragen, die man sich bei WAAP-Einführung stellen sollte
Bei der Auswahl eines WAAP-Produktes lohnt der Blick auf ein paar Punkte, die über die Feature-Liste hinausgehen. Dabei können Sie sich folgende Fragen stellen:
- Sichere Standardeinstellungen: Sind die Filter bereits durch einen Application-Security-Experten vorkonfiguriert und aktiviert? Oder wird von Beginn an erst einmal alles durchgelassen und muss erst selbst konfiguriert werden?
- Hohes Sicherheits-Niveau: Werden die Filterregeln kontinuierlich weiterentwickelt und gehärtet? Ein starkes Signal ist beispielsweise ein Bug-Bounty-Programm: Nur eine bereits sehr sichere Lösung kann es sich überhaupt leisten, Sicherheitsexperten für das Aufdecken von Sicherheitslücken zu bezahlen.
- Reaktion bei Zero Day Schwachstellen: Wie schnell wird das Produkt jeweils aktualisiert? Fragen Sie nach, wie lange es beispielsweise bei Log4Shell dauerte, bis die WAAP-Filter alle Formen des Angriffs blockieren konnten? Oder waren die Anwendungen sogar schon vor dem Bekanntwerden der Schwachstelle geschützt?
- Einfachheit und Support: Basiert das Produkt auf einer Open Source-Lösung oder gibt es professionellen Support? Wie sind die Verfügbarkeit und die Antwortzeiten bei Fragen und Problemen?
- Container-Umgebungen: Welche Architekturvarianten stehen für den Schutz von Microservices oder Serverless-Anwendungen zur Auswahl? Wie können Cloud-native und Serverless Anwendungen geschützt werden?
- DevOps/GitOps: Wie lässt sich das Produkt in DevSecOps-Prozesse einbinden? Können Security Policies als Code definiert werden?
Shift Left und Shield Right
Webanwendungen und insbesondere auch APIs bleiben im Visier von Cyberkriminellen. Anwendungssicherheit muss deswegen so früh wie möglich adressiert werden, im Idealfall schon in der Design- und Entwicklungsphase. Zusätzlich zu diesem «Shift Left» braucht es auch einen effektiven Schutz zur Laufzeit, das entspricht einem «Shield Right».
WAAP-Lösungen bilden diesen letzten Schutzwall und komplettieren damit das Sicherheitskonzept. Sie erkennen nicht nur gezielte Angriffe im Betrieb, sondern wehren auch verteilte DoS-Angriffe und unerwünschte Bots ab. Im Cloud-Umfeld ist gleichzeitig ein Trend von zentralen zu verteilten Application Firewalls erkennbar: Microservices und Container-Applikationen werden heutzutage von Microgateways geschützt. Das engmaschige Netz dieser «Mini-WAAPs» bildet in Kombination mit einem Zugriffsmanagement eine Zero-Trust-Architektur: Mit diesem Ansatz wird die Identität zum neuen Perimeter. Entsprechend sollten die eingesetzten Applikations- und API-Sicherheitslösungen auch eng mit dem Zugriffsmanagement zusammenarbeiten und im besten Fall auch das Konzept von Continuous Adaptive Trust unterstützen können. Continuous Adaptive Trust bedeutet mehr Sicherheit bei gleichzeitig weniger mühsame Interaktionen für den Anwender.
Dank einer kontinuierlichen Risikoanalyse und laufendem Abgleich mit dem gerade bestehenden Vertrauensniveau, kann die Sicherheit vermehrt im Hintergrund bleiben. Dabei werden die Identität und deren Berechtigung jedes Aufrufs mit Hilfe eines Identity Providers laufend überprüft und so das Nutzerverhalten kontinuierlich auf bösartige Absichten untersucht.
Zurück zu Teil 1: Die WAF ist tot — es lebe WAAP!
Blognews direkt in Ihr Postfach
Der Airlock Newsletter informiert Sie laufend über neue Blogartikel.