Geschäftsprozesse überschreiten immer häufiger Firmengrenzen und erlauben den direkten Zugriff Dritter auf Unternehmensdaten. Der Verlust an Integrität, Vertraulichkeit und Verfügbarkeit kann – je nach Prozess – großen Schaden anrichten. Die Datenverarbeitung erfolgt durch Anwendungen, die eine geforderte Geschäftslogik abbilden und – vor allem im Fall von Web-Applikationen – Schnittstellen für den Benutzer bereitstellen. Sichere Anwendungen werden für Geschäftsprozesse daher immer wichtiger. Dabei gilt es, Applikationssicherheit stets ganzheitlich zu betrachten – sowohl auf den verschiedenen technischen Ebenen als auch im Hinblick auf den Entwicklungsprozess.

Im Folgenden wird der Entwicklungsprozess einer Anwendung mit den relevanten Sicherheitsaspekten beschrieben, da er alle technischen und organisatorischen Ebenen umfasst. Der Hauptfokus liegt jedoch auf den Sicherheitsprinzipien beim Design und bei der Programmierung einer Web-Applikation.

Sicherheit im Entwicklungsprozess

Unabhängig davon, welches Entwicklungsmodell ein Unternehmen favorisiert (etwa das V-Modell oder agiles Programmieren) – stets werden die Phasen "Anforderungsanalyse", "Architektur und Design", "Implementierung", "Test", "Integration in Produktion" durchlaufen. In allen Schritten sind Sicherheitsaspekte zu berücksichtigen, die hier als ein erster Überblick über die Materie skizziert werden. Als Beispielanwendung dient ein einfacher Webshop, der unter anderem Funktionen wie das Speichern von Kontodaten beziehungsweise Kreditkarteninformationen für registrierte Benutzer bereitstellt.

Anforderungsanalyse

In der Anforderungsanalyse, auch Requirements Engineering genannt, sind nicht nur funktionale, sondern auch sicherheitsrelevante Anforderungen zu definieren. Letztere lassen sich mit Hilfe etwa von Threat Modelling sowie Risiko- und Abuse-Cases-Analyse sowie aus Firmenrichtlinien und gesetzlichen Vorgaben ermitteln. Das Ergebnis der Anforderungsanalyse muss im Hinblick auf Sicherheit bereits so belastbar sein, dass Architektur und Design der Anwendung in der Folgephase möglich werden.

Bei unserem Webshop werden zunächst die gesetzlichen Anforderungen ermittelt. Aufgrund der Speicherung beziehungsweise Verarbeitung personenbezogener Daten kommt das Bundesdatenschutzgesetz (BDSG) zum Tragen. Da Kreditkarteninformationen gespeichert werden, muss die Anwendung zudem PCI-Compliance erreichen. Ferner gilt es zu berücksichtigen, dass es sich bei dem eingesetzten Server um einen Multiprojekt-Server handelt, sprich: die Kompromittierung einer Anwendung kann auch andere Applikationen betreffen. Aus der Risikoanalyse ergibt sich außerdem ein hoher Schutzbedarf für die personenbezogenen Daten – vor allem für Kontoinformationen. Der größtmögliche Schaden ist hier ein Imageverlust für den Fall, dass Schwachstellen des Webshops bekannt werden.

Architektur und Design

In der Architektur- und -Designphase werden die wesentlichen Komponenten der Anwendung mit ihren Funktionen beschrieben. Außerdem gilt es, die Schnittstellen zwischen den Komponenten zu spezifizieren und den Datenfluss zu modellieren. Ferner werden alternative Lösungsvarianten aufgezeigt und anhand einer Wirtschaftlichkeitsbetrachtung bewertet. Folgende sicherheitsrelevante Aufgaben sind in dieser Phase zu erledigen:

• Bedrohungs-, Schwachstellen- und Restrisikoanalyse;

• risikosenkende Maßnahmen müssen definiert und spezifiziert werden;

• Architektur- und Designvorschläge sind zu erstellen – unter Berücksichtigung von Best Practices (Security Design Patterns) beispielsweise zur Umsetzung des fachlichen Berechtigungskonzepts;

• Architektur- und Design-Reviews – auch im Hinblick auf die identifizierten Sicherheitsanforderungen;

• Tests zur Überprüfung der Sicherheitsfunktionen müssen spezifiziert werden.

In unserem Beispiel wird für Authentisierung, Autorisierung und Session-Management auf Security Design Patterns zurückgegriffen. Eine Zwei-Faktor-Authentisierung mittels SMS-Bestätigung soll Phishing- oder Trojaner-Attacken erschweren. Für eine komfortable Administration wird ein einfaches Rollenkonzept mit normalen Benutzern und Administratoren eingeführt.

Als zusätzlicher "Defense-in-Depth"-Ansatz sollen Zugriffe mehrfach, an verschiedenen Layern der Applikation, geprüft werden. Die erste Schutzschicht auf Ebene der Requests prüft, ob für den Zugriff auf eine spezielle URL ausreichende Rechte vorhanden sind. Die zweite Schutzschicht auf dem Service-Layer stellt sicher, dass auch für den Aufruf einer bestimmten Servicefunktion entsprechende Rechte vorliegen. Die dritte Schutzschicht auf Datenebene sorgt dafür, dass beim Zugriff auf das DAO (Data Access Object) nur Daten zurückgeliefert werden, auf die rechtmäßig zugegriffen werden darf. Eingaben von Benutzern werden so streng wie möglich validiert. Beispiel Postleitzahlenfeld: Da nur Kunden in Deutschland unterstützt werden, wird geprüft, ob die angegebene Nummer fünf Stellen hat.

Um gegen Injection-Angriffe gefeit zu sein, werden im Vorfeld alle integrierten Interpreter ermittelt und zentrale Maskierungsfunktionen für den jeweiligen Kontext zur Verfügung gestellt. Beispiel: HTML- oder Javascript-Code wird durch spezielle JSTLs (Javaserver Pages Standard Tag Library) maskiert.

Implementierung

Das eigentliche Coding der Anwendung erfolgt in der Implementierungsphase, in der die Vorgaben aus den vorangegangenen Phasen zu realisieren sind. Unterstützt wird die Implementierung durch Frameworks und Programmierumgebungen, die mit bereits definierten Sicherheits-Features konfiguriert sind oder die Programmierung bestimmter Sicherheitsfunktionen erleichtern. Zudem sollten Programmierrichtlinien den Entwicklern klare Vorgaben für die verwendeten Frameworks, Programmierumgebungen und -sprachen an die Hand geben. Die bereits definierten Sicherheitstests sind weiter zu verfeinern oder zu ergänzen. In dieser Phase werden auch Installations- und Betriebshandbücher unter Berücksichtigung von Sicherheitsanforderungen für die Betriebsumgebung (etwa Härtungsvorgaben für Server) erstellt.

Für unseren Webshop werden Muster für die Einbindung von Interpretern erarbeitet. Beispiele hierfür sind die Ausgabe von HTML beziehungsweise Javascript, die Anbindung einer Datenbank mittels JPA (Java Persistence API) und die Anbindung an einen LDAP-Service.

Sicherheitskritische Funktionen wie die Nutzung von Security Design Patterns und das Aufrufen von Interpretern werden mittels Sourcecode-Reviews geprüft und gegebenenfalls korrigiert. Ferner sollen in den Build-Prozess integrierte Tools wie "Findbugs" und "Checkstyle" die Codequalität verbessern und Programmierfehler (auch sicherheitsrelevante) reduzieren.

Test

Wichtig ist, die Anwendung nicht nur funktional zu testen. In einem Testplan sind die zuvor definierten Sicherheits-Checks zu verfeinern oder zu ergänzen, auszuführen und zu dokumentieren. Nach der Fehlerbereinigung muss erneut geprüft werden. Dabei sind nicht nur Checks vorzunehmen, die sich direkt auf die bereinigten Fehler beziehen, sondern auch mögliche Nebeneffekte der am Code vorgenommenen Änderungen zu berücksichtigen. Die Security-spezifischen Tests sollte ein Sicherheitsverantwortlicher überprüfen oder besser: abnehmen.

Bei unserem Webshop wird ein Teil der Tests, die sich leicht automatisieren lassen, in eine Suite fachlicher Checks integriert. Die restlichen Überprüfungen sind vor jedem Release als Testplan manuell vorzunehmen. Inhalte sind unter anderem das Rollenkonzept, einfache Injection-Flaws und die strenge Eingabevalidierung der Daten. Ein externer Sourcecode-Review sorgt für PCI-Compliance. Parallel dazu erfolgt ein Penetrationstest, der einer Attacke eines qualifizierten Angreifers entspricht. Zudem prüft der Tester auch unkonventionelle Vorgänge, auch die Produktions- beziehungsweise Integrationsumgebung wird getestet. Die Ergebnisse der Tests werden in einer Restrisikoanalyse bewertet und das verbleibende Risiko eingeschätzt.

Integration in Produktion

Selbst eine Anwendung ohne ein einziges Sicherheitsproblem lässt sich nicht sicher betreiben, wenn die Produktionsumgebung nicht hinreichend abgesichert ist. Mangelhafte Abstimmung zwischen Entwicklung und Betrieb verursacht häufig schwerwiegende Schwachstellen für die Applikation. Schwerpunkte in der sicheren Produktion sind die Härtung von Systemen, hinreichendes Patch-Management sowie sichere Administration.

Noch mehr Abstimmung ist beim Einsatz einer Web Application Firewall (WAF) notwendig, da sich damit auch Schwachstellen in der Applikation absichern lassen. Eine WAF mit voreingestelltem Regelwerk erhöht zwar das Sicherheitsniveau, reicht als Schutz vor gezielten Angriffen (auf eine unsichere Anwendung) jedoch nicht aus. Das erfordert spezielle, auf die jeweilige Applikation zugeschnittene Policies. Idealerweise bildet die WAF eine zweite Schutzschicht – vor einer sicher entwickelten Anwendung.

Für unseren Webshop gilt es darüber hinaus, sichere Verschlüsselungsalgorithmen für SSL/TLS zu konfigurieren und unsichere Protokolle wie SSLv2 zu deaktivieren. Der Application-Server wird in der demilitarisierten Zone (DMZ) betrieben, und vom Internet her ist nur der Port für SSL (443) freigegeben. Die Administration der Anwendung, des Application-Servers und des Betriebssystems ist nur über ein spezielles Administrationsnetz im internen LAN möglich.

(kf)