Ich weiss, der Titel dieses Blogs führt zu Fragezeichen – aber geben Sie mir 5 Minuten und ich versuche, alles in einen sinnvollen Zusammenhang zu bringen.
Ich habe um ca. 1999 (noch während meines Studiums) meine erste Webapplikation geschrieben. Klassisch wurden ein paar Skripts per FTP in einen Ordner hochkopiert und die Applikation der weiten Welt zur Verfügung gestellt. Es ging dabei um einen Marktplatz für gebrauchte Lastwagen und bevor Sie fragen, nein, es war mitnichten ein Erfolg.
Persönlich war es aber eine Bereicherung. Mir war von nun an klar, in welchen Bereich der Informatik ich mich weiterentwickeln wollte.
Ich denke hier und da an diese Zeiten zurück. Denn die heutige Entwicklung von modernen Webapplikationen hat mit der damaligen Zeit überhaupt nichts mehr gemein. Wir alle setzen mittlerweile Frameworks für den Front- und Backendbereich ein. Jedes davon lässt unsere Applikation um Tausende, Hunderttausende oder Millionen von Codezeilen grösser und komplexer werden.
Frameworks helfen uns, unsere Software zu strukturieren. Sie leisten, wenn richtig eingesetzt, auch einen wichtigen Beitrag für die Qualität der Software. Mit ihnen erhöhen wir die Produktivität unserer Entwickler und sie erlauben es uns, von Best Practices zu profitieren. In vielen Fällen „produzieren“ Frameworks auch Sicherheit.
Ohne diese Frameworks und Tools können wir uns heute als Softwareentwickler am Markt nicht mehr behaupten. Sie sind ein zentraler und immer wichtiger werdender Bestandteil unserer Lösungen und Produkte. Das Resultat unserer Arbeit ist im besten Fall so gut, wie die darunterliegenden Komponenten.
Die Währung
In der Individualsoftwareentwicklung gibt es die eine wichtige Währung: Vertrauen. Der Kunde muss vertrauen haben, dass wir in der Lage sind, die Projekte oder Produkte in der geforderten Qualität, dem zur Verfügung stehenden Zeitrahmen und mit dem gegebenen Budget umzusetzen.
Dieses Vertrauen gilt es zu erarbeiten, mit technischem Know-how, Aufrichtigkeit, persönlichem Einsatz und dem projekttechnischen Rüstzeug, welches einem ermöglicht, die Anforderungen zu erfüllen.
Damit ich, als Ersteller von Software, ein Projekt für alle Seiten erfolgreich umsetzen kann, muss ich wissen, welche Kriterien ich wie gut erfüllen kann. Ich muss wissen, welche Parameter ich selbst steuern kann, wo ich extern gesteuert werde und welche Rahmenbedingungen ich einhalten muss, damit ich im Markt überlebe. Es verhält sich wie mit allen Risiken, entweder ich akzeptiere sie und lebe mit ihnen, versuche sie aktiv zu minimieren und damit in den Griff zu kriegen oder versuche mich dagegen zu versichern.
Die Reputation
Wenn uns ein Kunde die Entwicklung einer Webapplikation anvertraut, bedeutet das im Umkehrschluss, dass er uns ein Teil seiner Reputation anvertraut. Wir sind damit mitverantwortlich, wie unser Kunde von der Aussenwelt wahrgenommen wird. Kommt es zu einem Vorfall, welcher unseren Kunden kompromittiert, sind wir mitverantwortlich.
Damit wir unsere Webapplikationen betreiben können benötigen wir eine Vielzahl an Komponenten: Vom Kernel, über das Betriebssystem, hinzu Server Applikationen und Laufzeitumgebungen bis hin zu unseren eingesetzten Frameworks und Drittkomponenten muss alles vorhanden sein.
Am Ende spielt es keine Rolle, welche der vielen Komponenten bei einem Angriff kompromittiert werden. Die Integrität der gesamten Lösung ist bei einem erfolgreichen Angriff kompromittiert.
Das Risiko
Die Frage ist nun, wie wir damit umgehen.
Wir können das Risiko akzeptieren (ok, das war jetzt ironisch gemeint).
Wir können versuchen, das Risiko zu minimieren, indem wir uns Gedanken um Angriffsarten und Schwachstellen unseres Systems machen. Das Problem dabei: es gibt viel zu viele Komponenten. Ein Team bräuchte viel zu viele Spezialisten und auch dann könnten wir mit den im Internet lauernden Gefahren nicht Schritt halten. Die Angriffsvektoren werden vielfältiger, Methoden und Werkzeuge entwickeln sich rasant weiter. Alte Muster hingegen bleiben. Die Bedrohungslage ist additiv.
Bleibt damit für die meisten Softwareentwickler sinniger Weise wohl nur noch eine letzte Möglichkeit: wir versuchen, uns bestmöglich zu versichern.
Die Versicherung
Aus den genannten Gründen setzen wir in praktisch allen Projekten eine Web Application Firewall an. Wir geben damit einen Teil der Applikationssicherheit in die Hände von Spezialisten.
Der Einsatz von Web Application Firewalls kann zu Beginn relativ schwierig sein. Die Systeme müssen auf die jeweilige Applikation abgestimmt werden. Dabei gibt es zeitweilig die Möglichkeit sowohl die Webapplikation, als auch die Web Application Firewall anzupassen. Schwierig kann es werden, wenn Drittkomponenten ganze Löcher in die Web Application Firewall reissen – dann ist zu untersuchen, ob man auf andere Lösungen ausweicht oder die Konsequenzen in Kauf nimmt. Selbstverständlich sollte man dies nicht erst am Ende oder während der Einführungsphase eines Projektes erfahren müssen. Stellen Sie sicher, dass das Equipment schon den Entwicklern zur Verfügung steht.
Eine Web Application Firewall kann das Design einer Webapplikation massgeblich beeinflussen. Sprechen Sie mit dem Hersteller und seinen Beratern. Erfragen Sie die Best Practices für das jeweilige Produkt. Hinterfragen Sie Antworten. Und seien Sie auch bereit, ein paar liebgewonnen Angewohnheiten aufzugeben.
Es ist darüber hinaus auch wichtig, den Entwicklern den Grund näher zu bringen, weshalb wir diese zusätzlichen Schutzmechanismen einsetzen wollen. Es ist nicht selten der Fall, dass eine Lösung grundsätzlich einwandfrei funktioniert, aber aufgrund der Implementierungsweise nicht Web Application Firewall tauglich ist. Machen Sie zu Projektbeginn klar, dass die WAF als wichtige Teil-Komponente der ganzen Lösung zu verstehen ist.
Planen Sie zusätzliche Zeit während der Stabilisierungsphase ein. Nur der Live-Betrieb wird weisen, ob die Abstimmung zwischen WAF und Applikation in jeder Situation in Ordnung ist. Stellen Sie sicher, dass Ihnen die Web Application Firewall geblockte Anfragen in einer geeigneten Form zur Verfügung stellt, so dass Sie schnell reagieren können.
Web Application Firewalls helfen uns Entwicklern. Sie nehmen uns Arbeit ab, sie produzieren Sicherheit und erhöhen den Wert der Lösung für unseren Kunden und seine Benutzer. Wir Entwickler von Business Applications sollten uns mit Web Application Firewalls genauso befassen wie mit den neusten JavaScript Frameworks. Damit dienen wir dem Kunden, zum Schluss aber vor allem uns selbst.
Frederik Schaller ist CTO der Uptime Systems GmbH. Er hat nach seinem Abschluss 2003 in Wirtschaftsinformatik an der Universität Zürich während zwei Jahren als IT-Berater bei einem grossen internationalen Beratungsunternehmen gearbeitet. Er ist bei Uptime Systems GmbH für die technischen Belange zuständig.