Software ohne Bremsen

Software ohne Bremsen

Stefan Friedli
von Stefan Friedli
am 02. Juni 2016
Lesezeit: 6 Minuten

Verwundbarkeiten in Software sind bares Geld wert. Bug Bounties dienen heute als Einnahmequelle für viele unabhängige Sicherheitsexperten. So hat Facebooks Bug-Bounty-Programm alleine im Jahr 2014 über eine Million US-Dollar ausbezahlt. Microsoft hat im selben Jahr zum ersten Mal eine Rekordsumme von 100’000 US-Dollar für eine einzelne Schwachstelle ausbezahlt – für einen Bug in Windows 8, den der britische Forscher James Forshaw entdeckte.

Doch nicht nur die Entdeckung von Schwachstellen kann lukrativ sein – auch die Entwicklung von unsicherer Software kann sich lohnen. So kommt es immer wieder vor, dass Entwickler im Auftrag von Kunden Softwareprodukte entwickeln und dabei – vermutlich mangels besseren Wissens – essentielle und rudimentäre Sicherheitsmechanismen vergessen oder falsch implementieren. Die böse Überraschung folgt, wenn diese Schwachstellen in einer Sicherheitsprüfung zum Vorschein kommen und Mitigationsmassnahmen gefragt sind.

Spätestens wenn der Security Officer eines Unternehmens die Notbremse zieht und das Release der Applikation auf Eis legt, ist meist Krisenstimmung angesagt: Wie lange dauert es, in eine Applikation eine angemessene Eingabevalidierung zu implementieren? Die für SQL-Injection anfälligen Datenbank-Queries durch Prepared Statements zu ersetzen? Oder ein solides Session Management, das das Datenmodell der Applikation berücksichtigt, in die bestehende Applikation zu integrieren ohne dabei andere existierende Komponenten in Mitleidenschaft zu ziehen? Und wer bezahlt den ganzen Aufwand? Nicht selten suchen Entwickler ihr Glück frei nach dem Motto Angriff ist die beste Verteidigung und präsentieren ihre Aufwandsschätzung inklusive dem zu erwartenden Rechnungsbetrag.

Zu Recht fragt sich der betroffene Kunde hier: «Muss ich das bezahlen?» – und die Antwort müsste nach allen Regeln der Vernunft ein klares Nein sein. Warum soll ein Kunde für grundlegende Qualitätsmerkmale bezahlen, die heute absolut gang und gäbe sind? Die stets gerngesehene Security/Auto-Analogie dazu: Ein Kunde darf erwarten, dass er ein Auto mit funktionierender Bremse und Airbag kauft. Wenn das nicht der Fall ist, wäre es eine Frechheit noch einmal 50 Prozent des Kaufpreises zu verlangen, wenn der Kunde zwei Monate nach dem Kauf einen funktionierenden Airbag verlangt – wenn er denn dann überhaupt noch in der Lage ist, nach etwas zu verlangen.

Crashtests sind sowohl in Software als auch bei Autos wichtig

Doch so einfach ist die Sache nicht. Ist im Vertrag nicht klar festgehalten, wie mit Korrekturen aufgrund von Sicherheitsmängeln umzugehen ist, so stehlen sich viele Entwickler aus der Verantwortung. Grund dafür ist, dass oft vergessen geht, Sicherheitsanforderungen genau wie fachliche und funktionale Anforderungen im Rahmen des Vertrages und/oder des Service Level Agreements zu regeln.

Diese Massnahmen sind unabdingbar. Sie nicht zu berücksichtigen kann ein riesiges Projektrisiko darstellen: Was, wenn kurz vor dem Release bekannt wird dass die Applikation beim Umgang mit Kundendaten komplett versagt und einem Angreifer mit einfachsten Mitteln Zugang zu sensitiven Informationen ermöglicht? Die Verhandlungsposition ist denkbar schlecht: Die Applikation im aktuellen Zustand zu nutzen ist ein riesiges Risiko, das kaum jemand zu tragen gewillt sein dürfte. Die Applikation einzustampfen würde bedeuten, sämtliche bereits getätigten Investitionen in Entwicklung, Projektkoordination und so weiter aufzugeben und von vorne anzufangen. Was bleibt, ist dann die bittere Pille zu schlucken und den Entwickler ganz nach dessen Belieben für das Einbauen von Bremsen und Airbags zu entlöhnen.

Noch etwas komplizierter wird die Diskussion, wenn einige der gefundenen Schwachstellen die Bezeichnung eklatant nicht mehr ganz verdienen: Fehlende Sicherheitsfeatures, nicht zwingend aber direkte Schwachstellen. Sogar wenn man sich darauf einigen kann, dass an Fahrlässigkeit grenzende Versäumnisse vom Hersteller zu beheben sind, stösst man rasch auf Widerstand. Manchmal zu Recht, weil der Kunde nicht bereit war, zusätzliches Budget für die gewünschte Mehrfaktorauthentisierung aufzuwenden. Manchmal aber auch zu Unrecht, weil man eigentlich erwarten würde, dass eine Softwareschmiede mit über zehn Jahren Markterfahrung weiss, welchen Standard ein Finanzinstitut im Hinblick auf Softwaresicherheit erwarten dürfte.

Ein solider Ansatz ist es, ein bestehendes Framework für Sicherheitsanforderungen zu nutzen und zum Vertragsbestandteil zu erklären. So bietet sich für Webapplikationen zum Beispiel das Application Security Verification Standard (ASVS) Project an. ASVS beinhaltet drei Stufen mit Anforderungen, die eine Applikation auf dieser Stufe zu erfüllen hat. Stufe 1, mit der Bezeichnung Opportunistic versehen, wird gemeinhin als Mindestanforderung für sämtliche Applikationen genutzt: Hier müssen Schwachstellen verhindert werden, die mit kleinem Aufwand oder automatisiert und ohne Zugang zum Quelltext identifiziert werden können. Das beinhaltet zum Beispiel Cross-Site-Scripting- oder simple SQL-Injection-Verwundbarkeiten.

Darüber hinaus gehen die Stufen 2 und 3: Standard (2) beinhaltet Anforderungen, die notwendig sind um einem durchschnittlichen Angreifer standzuhalten und wird typischerweise für Applikationen eingesetzt, die mit sensitiven Daten, wie zum Beispiel Kundendaten oder durch Regulatorien definierte, schützenswerte Daten umgehen. Advanced (3) stellt die höchste Stufe dar, die einen Fokus auf Sicherheitsmerkmale legt, zum Beispiel weil sie kritische Daten verarbeiten, wie es oft im Gesundheits-, Finanz- oder Militärbereich der Fall ist.

Durch die Integration einer Anforderungsstufe in den Ausschreibungsprozess sowie in das Vertragswesen – also nicht bloss den Vertrag, sondern den Prozess, der Vertragsinhalte definiert – können Konflikte und böse Überraschungen von Anfang an verhindert werden. Die Situation wird so transparenter und gerechter für alle Beteiligten: Für den Entwickler sind der Aufwand und die Erwartungshaltung von Anfang an klar, der Auftraggeber kann sich darauf verlassen, dass am Ende die notwendigen Anforderungen erfüllt sind – und kann dies guten Gewissens auch durch ein Security Assessment oder einen Penetration Test prüfen lassen, auch ohne gut gefüllte Kriegskasse für den Fall, dass dieser nicht ganz so positiv ausfällt, wie erwartet.

Über den Autor

Stefan Friedli

Stefan Friedli gehört zu den bekannten Gesichtern der Infosec Community. Als Referent an internationalen Konferenzen, Mitbegründer des Penetration Testing Execution Standard (PTES) und Vorstandsmitglied des Schweizer DEFCON Group Chapters trägt er aktiv zum Fortschritt des Segmentes bei.

Links

Haben Sie Interesse an einem Penetration Test?

Unsere Spezialisten kontaktieren Sie gern!

×
TIBER-EU Framework

TIBER-EU Framework

Dominik Altermatt

Vertrauen und KI

Vertrauen und KI

Marisa Tschopp

Datenverschlüsselung in der Cloud

Datenverschlüsselung in der Cloud

Tomaso Vasella

Cyber Threat Intelligence

Cyber Threat Intelligence

Marc Ruef

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv