Mit der Macht kommt die Verantwortung
Jeder der sich im Internet bewegt, kennt das Problem: Eine Registrierung hier, ein Passwort da, dort drüben ein Newsletter und auf der nächsten Seite ein Formular zur Übermittlung der Bankverbindung.
Bereitwillig geben viele von uns ihre Daten preis, die dazu genutzt werden, gezieltes und individuelles Marketing zu betreiben. Anhand der Daten und Nutzerprofile werden Werbemaßnahmen zunehmend auf den Konsumenten zugeschnitten, wobei die Daten in vielen Fällen einfach über undurchsichtige Kanäle an andere Anbieter gelangen können. Dieses Vorgehen wird durch die uneinheitliche Rechtslage in Europa sogar noch begünstigt.
In meinen Augen ist durch das übermitteln meiner Daten zu einem Deal zwischen mir und dem Anbieter gekommen: Ich habe dich mit meinen Daten versorgt, du hast für den Schutz dieser Sorge zu tragen.
Wissen diese denn überhaupt wie man Daten schützt?
„Na klar, wir nutzen SSL, die Daten sind verschlüsselt“,
„Wie haben doppelte Firewalls und IPS Devices um unser Netzwerk zu schützen“,
„Jedwede Daten sind in einer verschlüsselten Datenbank gespeichert.“
Diese Statements höre ich tagtäglich – auch von IT Spezialisten, die glauben diese Vorkehrungen würden ausreichen, um die ihnen anvertrauten Daten zu schützen.
Dabei zielen die meisten Attacken nicht auf das System als Ganzes ab, sondern sind anwendungsbasiert. Wenn jemand z.B. eine SQL Injektions-Attacke startet um Daten zu extrahieren, ist es für ihn unerheblich ob die Daten verschlüsselt sind oder nicht; der Befehl wird vom Web Server dennoch ausgeführt und gelangt in die Datenbank.
WEB Application Firewall als Mittel der Wahl
Ähnlich verhält es sich mit Apps. Wenn diese einen Nutzer Parameter setzen, wie kann ich mich darauf verlassen, dass dieser Parameter nicht geändert wurde, wenn er wieder an die App zurückgeht?
Eine typische netzwerkbasierte Anwendung ist nicht in der Lage, vor solchen Fällen zu schützen. Eine umfassende Sicherheitstechnologie muss die jeweilige App und ihre individuellen Eigenschaften verstehen.
Eine solche stellen WEB Application Firewalls (WAF) dar. Diese setzt sich vor den Server und vermittelt alle Nutzer Anfragen und Antworten. Desweiteren unterstützt die Firewall Dienste wie SSL offload und load balancing.
Weil die Firewall in direkter Verbindung zum Server steht kann sie jede Nutzer Sitzung verfolgen und, was noch viel wichtiger ist, die Antworten des Servers bewerten. Dadurch kann sie die Anfrage und die dazugehörige Rückmeldung miteinander abgleichen. Ein Beispiel: Ein Nutzer der auf eine Webseite geht, bekommt eine individuelle Sitzungs-ID zugewiesen. Daneben zeichnet die Firewall die Sitzung mit einem verschlüsseltem Cookie, das weiterführende Informationen über den Nutzer beinhaltet, auf. Im Falle eines Angriffs auf die Sitzungs-ID wird somit gewährleistet, dass dieser Versuch geblockt wird, wenn die Informationen nicht mit denen übereinstimmen, die die WAF beinhaltet. Darüber hinaus wird die komplette Anfrage analysiert, bevor sie an den App Server übermittelt wird. Dies ist deshalb wichtig, weil sich viele Angriffe innerhalb des Codes verstecken oder sich in vielen unterschiedliche Anfragen aufteilen. Herkömmliche Security Anwendungen sind nicht im Stande, solche Attacken zu erfassen, da es sich um gültige http Anfragen handelt. Eine WAF wird im Gegensatz dazu, den Code vor dem App Server ausführen und den Angriff blocken. Wenn etwas in der Anfrage fehlt, kann die Firewall die vom Server kommenden sensiblen Informationen blocken, da die Rückmeldungen ebenso untersucht werden.
Wenn ich mit Entwicklern über solche Probleme spreche, kommt häufig die Antwort: „Wieso benutzt jemand die Anwendung auf diese Art und Weise – für diesen Zweck wurde sie nicht realisiert“.
Das mag zwar stimmen und ist auch einleuchtend. Dennoch ignoriert es die Tatsache, dass man vor der Veröffentlichung nie vorhersagen kann, wie sich die Nutzer verhalten werden. Trotz bester Absichten, darf man sich der Realität nicht verschließen.
Eine WAF lernt die Besonderheiten ihrer Anwendungen kennen und stellt sicher, dass gute Nutzer keine schlechten Dinge tun. Auch wenn es „nur“ ein Unfall war.
Lassen sie mir ein Beispiel geben: Ein Nutzer bookmarkt eine Seite in ihrer App. Einige Tage später kehrt er über den Bookmark auf ihre Seite zurück. Es kann aber gut sein, dass er eine Fehlermeldung bekommt, weil ihre App für diese Art des Zugangs nicht konzipiert wurde und keine Sitzungs-ID vergeben wurde. Eine WAF kann sicherstellen, dass es immer nur einen Zugangsweg zur App gibt, was den Einstieg für Nutzer und Kunden erleichtert. Diese Art von Deal ist mir wesentlich lieber.