Browser und andere Anwendungen sind mittlerweile die einfachsten Angriffsvektoren, um in ein Firmennetz vorzudringen. Vor diesem Hintergrund wird zunehmend die Forderung nach sicheren Anwendungen laut. Doch was ist Application Security eigentlich genau? Dieser Beitrag gibt einen Überblick über die verschiedenen Aspekte der sicheren Anwendungsentwicklung.
Geht es bei der Applikationssicherheit um den Einsatz von Hacking-Techniken, um Sicherheitslöcher zu finden? Ober vielleicht um eine sichere Software-Architektur? Oder beschreibt dieser Begriff vielleicht doch eher Techniken, die den Schutz von – eigentlich unsicheren – Anwendungen übernehmen, wie etwa Web Application Firewalls?
Applikationssicherheit umfasst zwar alle diese Aspekte, geht aber weiter. Es handelt sich um einen methodischen Aspekt der Software-Entwicklung, von Anfang an auf Sicherheit zu achten – und diese gegebenenfalls mit speziellen Tools zu ergänzen. Dieser Artikel versucht, in einer leicht verständlichen Übersicht einen Überblick über die verschiedenen Aspekte von Applikationssicherheit zu geben.
Security Requirements
Schon während der ersten Phase eines typischen Software-Projekts ist es wichtig, an Sicherheit zu denken. Die Sicherheitsanforderungen sollten explizit beim Kunden eingeholt werden, auch wenn sie scheinbar selbstverständlich erscheinen.
Dabei ist es von großem Vorteil, die Sicherheitsanforderungen explizit zu beschreiben, damit sie auch später in der Testphase validiert werden können. So können sie noch als „selbstverständlich“ abgetan werden
Vor allem im Hinblick auf Sicherheit ist es wichtig zu unterscheiden, ob eine Anforderung „funktional“ ist (also die Existenz einer bestimmten Funktionalität fordert) oder „nicht-funktional“ (wenn die Software eine bestimmte Eigenschaft haben soll). Anforderungen für Software-Sicherheit sind oft nicht-funktional und entsprechend schwer zu testen.
Secure Deployment
Software läuft immer in einer bestimmten Umgebung; sie ist beispielsweise abhängig vom Betriebssystem, benötigt einen Web-Browser etc. Die Umgebung ist oft eine Quelle von Sicherheitsproblemen, insbesondere im Zusammenspiel mit Schwachstellen der neu entwickelten Software.
Entsprechend müssen die Sicherheitsanforderungen unter Umständen auch auf die Konfiguration der bestehenden Software-Umgebung angewendet werden. Möglicherweise sind auch weitere Sicherheitstools und -Techniken erforderlich, um die geforderte Sicherheit erreichen zu können (etwa: sicheres Konfigurieren des Web-Servers und Einsatz von SSL).
Zudem darf der Installationsprozess selbst keine Sicherheitslücken hinterlassen, etwa durch Einrichten von Test-Accounts. Das „Scharf-Schalten“ von Software (also etwa das Abstellen von erweiterter Fehler-Information und Zugriffsmöglichkeiten über das Web für Administratoren) gehört ebenfalls in diese Phase.
Security Response
Keine Software ist fehlerfrei, erfolgreiche Angriffe wird es immer geben. Auch wenn diese Aussage vielleicht nicht immer zutrifft, so ist sie doch eine sehr gute Arbeitshypothese; sie fordert einen dazu auf, für den Fall vorzusorgen, dass doch eine Schwachstelle gefunden wird.
Um auf entdeckte Sicherheitslücken angemessen zu reagieren, ist eine Vorbereitung innerhalb der Entwicklungsorganisation erforderlich. Sehr oft ist es sinnvoll, hierfür eine eigene Spezialisten-Gruppe einzusetzen. Denn im Gegensatz zu vielen Standard-Software-Fehlern ist bei Sicherheitsproblemen zu entscheiden, wann das Problem dem Kunden kommuniziert wird, evtl. macht es Sinn, ihn schon zu informieren, auch wenn noch kein Patch vorhanden ist, damit der Kunde selbst Vorsorge tragen kann.
Security Metrics
Investitionen in die Sicherheit der Software sind oft schwer zu rechtfertigen, insbesondere da sie nicht unmittelbar zu einem schnell sichtbaren Ergebnis führen. Im Gegenteil: oft ist die Software erst einmal weniger flexibel und vielleicht dauert die Entwicklung auch länger.
Um einer grundsätzlichen Ablehnung von Sicherheitsmaßnahmen im Entwicklungsprozess entgegenwirken zu können, ist es sinnvoll, die Auswirkung von Sicherheitsmaßnahmen messbar zu machen. Mögliche Faktoren sind beispielsweise Angriffsfläche, Aufwand durch nachträgliches Lösen von Sicherheitsproblemen oder Anzahl gefundener Coding-Schwachstellen bei Black-Box-Tests. Misst man derartige Werte regelmäßig, dann wird der Effekt von Aktivitäten zur Verbesserung der Software-Sicherheit von Software transparent.
Code and Resource Protection
Angriffe auf Software werden nicht selten gut vorbereitet; dafür ist es für den Angreifer oft sehr hilfreich, wenn im Rahmen des Entwicklungsprozesses die Möglichkeit besteht, den Code einzusehen bzw. idealerweise gar zu manipulieren. Folgerichtig ist es in allen vorgenannten Phasen wichtig, dass die Erkenntnisse und Ergebnisse der Arbeit entsprechend vertraulich gehalten werden bzw. vor Eindringlingen – und im Extremfall auch Innentätern – geschützt werden.
Dazu gibt es eine Reihe von Techniken, die beim Projektstart beachtet werden sollten; nicht erst am Ende, denn dann ist das Kind meist schon in den Brunnen gefallen. Auch ist es unter Umständen sinnvoll, den Code zu verschleiern („Code obfuscation“), um es möglichen Angreifern zu erschweren, mittels Reverse Engineering an diese Informationen zu kommen.
Standards und Best Practices
Es gibt eine Reihe umfassender Methodiken, die diese einzelnen Aspekte zusammenfassen, um den Software-Entwicklern einen möglichst leichten Einstieg in die Materie der sicheren Software zu geben. Diese sind zum Teil Technologie- bzw. Hersteller-spezifisch (etwa der Microsoft Secure Development Lifecycle, SDL) und zum Teil sehr formalistisch, um möglichst viele Aspekte beweisbar nachzuhalten (etwa Common Criteria). Eine gute, offene Quelle zum Start ist das Open Web Application Security Project, genannt OWASP.
Letztendlich ist es aber wichtig, die Anwendungsentwickler in allen genannten Bereichen zu schulen, damit sie in der Lage sind, in Bezug auf Sicherheit die richtigen Entscheidungen zu treffen. Davor steht natürlich eine Beschäftigung mit dem Thema Software-Qualität, denn ohne die Prinzipien des allgemeinen Qualitätsmanagement werden auch die hier kurz angerissenen Sicherheitsmaßnahmen oft nur einmalige Aktionen bleiben und werden nicht verstetigt.