Security by Design
Unverzichtbar in der Softwareentwicklung
Was ist Security by Design?
Security by Design ist ein Software Engineering Prinzip, bei dem Anwendungen von vorneherein im Hinblick auf Sicherheit entwickelt werden. Sicherheitsmechanismen sind in diesem Fall also nichts, das im Nachhinein zur Anwendung hinzugefügt wird, um die größten Risse zu kitten. Stattdessen sind Anforderungen an die IT-Sicherheit der Anwendung von Beginn an in die Entwicklung mit eingebunden. Auf diese Weise entwickelte Anwendungen sind dadurch in der Regel deutlich besser abgesichert als dies bei nachträglich gesicherten Anwendungen der Fall ist.
Worauf muss man achten – Security by Design für Webanwendungen
Insbesondere Webanwendungen leben von Interaktivität. Reine Infoseiten, die mehr oder weniger nur als virtuelle Visitenkarte einer Firma konzipiert sind, findet man heute kaum noch. Stattdessen haben User immer mehr Möglichkeiten zur Interaktion. Man kann sich registrieren, seine Accounts verwalten, Profilbilder hochladen, Kommentare schreiben usw.
Das ist schön, weil es das Internet natürlich lebendiger macht und viele Funktionalitäten bereitgestellt werden, die früher nicht, oder nur mit großem Aufwand, möglich waren. Gleichzeitig steigt damit natürlich auch die Zahl möglicher Angriffsvektoren rapide an. Da es ungleich schwerer ist, eine bestehende Anwendung nachträglich sicher zu machen, als sie von Anfang an sicher zu entwickeln, wird das Prinzip Security by Design immer wichtiger. Aber worauf sollte man bei der Entwicklung einer Webanwendung denn nun genau achten?
Was kann man eingeben?
Viele Schwachstellen haben ihre Ursache darin, dass User Input ungeprüft verarbeitet wird. Beispiele dafür sind etwa Cross Site Scripting oder Command Injection. Ein besonderes Augenmerk sollte deshalb auf alle Teile der Anwendung gerichtet werden, in denen User Eingaben machen können (Suchfelder, Login- und Registrierungsseiten, Formulare, Kommentarfelder etc.).
Zunächst sollte man versuchen, den Input soweit wie möglich einzuschränken. Bei der Registrierung sollten etwa für Tag, Monat und Jahr des Geburtsdatums ein Dropdown Menü verwendet werden, bei dem nur aus den zulässigen Werten (1-31/1-12 und 1900-2021) ausgewählt werden kann. Die Untergrenze bei der Jahreszahl kann natürlich auch variiert werden und statt 1-12 können die Monate auch ausgeschrieben werden. Wichtig ist aber, dass nur aus vorher definierten Werten ausgewählt wird und keine Möglichkeit besteht, eigenen Texte einzugeben. Das reduziert das Risiko durch bösartigen User Input und hat in diesem Fall noch den angenehmen Nebeneffekt, dass die Eingaben standardisiert sind und somit leichter verarbeitet werden können. Bei einer freien Datumseingabe wären dagegen allerlei Formen möglich: 1.12.2020, 01.12.2020, 1 Dezember 2020 etc.
Trotz fest definiertem Input sollte auf Server Seite allerdings eine Fehlerbehandlung implementiert werden, mit der unerwartete Eingaben behandelt werden können. Für den Fall, dass es ein Angreifer schafft, statt der vorgegebenen Werte im Dropdown Menü eigenen Text einzugeben, sollte eine geeignete Reaktion erfolgen, beispielsweise die Ausgabe einer Fehlermeldung und das nicht verarbeiten des Inputs.
Logischerweise kann der Input nicht an allen Stellen auf diese Weise reglementiert werden. Eine Suchfunktion, die etwa nur fünf vordefinierte Suchbegriffe zulässt, wäre ziemlich sinnlos. Es gibt also Fälle, in denen man nicht um eine freie Eingabe herumkommt. In diesen Fällen ist es aber wichtig, den Input zu filtern. Dafür muss man sich zunächst überlegen, wie eine valide Eingabe aussieht: In ein Suchfeld werden Buchstaben eingeben, Zahlen (etwa für Produktnummern) und evtl. spezielle Suchoperatoren wie +, : oder „“. Nicht erlaubt werden sollte dagegen die Eingabe von JavaScript Code, also insbesondere die Skript Tags <script></script>. Werden diese Zeichen nicht gefiltert, besteht ein Risiko für Cross Site Scripting (XSS).
Allerdings existieren auch diverse Möglichkeiten, diese Zeichen zu codieren, sodass sie von einem Filter eventuell nicht mehr erfasst werden. Als zusätzliche Sicherheitsmaßnahme sollte deshalb so wenig User Input wie möglich vom Server gespiegelt werden. Statt auf der Ergebnisseite einer Suchanfrage den Suchbegriff anzuzeigen, sollte dort am besten immer nur das Wort Ergebnis stehen, der User weiß ja eh, wonach er gerade gesucht hat.
Bei Eingabefeldern die mit einer Datenbank verbunden sind (beispielsweise Produktsuche in einem E-Commerce Shop), muss zudem darauf geachtet werden, dass der User keine SQL Befehle eingeben und somit unerlaubt auf die Datenbank zugreifen kann. Dafür können zum Beispiel „vorgefertigte“ Datenbankabfragen verwendet werden, in die dann nur noch Werte eingesetzt werden können. Zudem muss hier darauf geachtet werden, welche Fehlermeldungen das System gegebenenfalls zurück liefert. Der User sollte nämlich keinesfalls Fehlermeldungen zu Gesicht bekommen, die vom System erstellt wurden, da diese eventuell Informationen über Table Namen oder zur Verfügung stehende Funktionen in der Datenbank liefern können. Tritt ein Fehler in der Datenbank auf, muss dieser stattdessen vom System abgefangen werden. Dem User wird daraufhin eine möglichst generische Fehlermeldung angezeigt („Da ist wohl etwas schief gelaufen, bitte versuchen Sie es zu einem späteren Zeitpunkt erneut“).
Was kann man hochladen?
Viele Webseiten leben geradezu von der Beteiligung ihrer User. Instagram oder YouTube wären nicht denkbar, wenn niemand dort Bilder und Videos hochladen würde. Andererseits stellt so ein Upload natürlich auch ein nicht zu unterschätzendes Risiko dar: Man lädt eine Datei auf den Server, die dieser dann eventuell auch noch verarbeitet. Das ist nicht ganz ungefährlich.
Am besten bedient man sich hierbei dem Prinzip des Whitelistings, bei dem genau angegeben wird, was erlaubt ist (z.B. nur die Dateitypen .png und .jpg), alles andere ist explizit verboten. Alternativ kann man auch Blacklisting verwenden, hierbei wird definiert, was verboten ist und alles andere ist erlaubt. Speziell bei File Uploads ist das aber ein recht großes Risiko, da eine Vielzahl von Dateitypen existieren und es nahezu unmöglich ist, wirklich alle zu erfassen und auszuschließen. Besser ist es also, sich zu überlegen, welche Dateien der Server verarbeiten soll und dann auch nur die entsprechenden Dateitypen zuzulassen.
Unabhängig davon, wie man mögliche Uploads nun einschränkt, muss natürlich seitens der Anwendung auch geprüft werden, ob die definierten Kriterien eingehalten wurden. Am besten wird diese Prüfung direkt im Browser vorgenommen, sodass potenziell bösartige Dateien erst gar nicht auf den Server hochgeladen werden. Dafür kann beispielsweise ein regulärer Ausdruck verwendet werden der prüft, ob der Dateityp den erlaubten Dateitypen entspricht. Falls nicht, wird der Upload abgelehnt und eine Fehlermeldung ausgegeben.
Was kann man sehen?
In den Fällen User Input und File Uploads werden mutwillig bösartige Aktionen der User abgefangen. Doch natürlich ist nicht in jedem Fall der User die Wurzel allen Übels. Manchmal werden auch schlichtweg seitens der Entwickler falsche Entscheidungen getroffen, sodass User Zugriff auf Informationen haben, die sie eigentlich nicht sehen sollten. Dabei muss man zwischen technischen und logischen Fehlern unterscheiden.
Zu technischen Fehlern zählt etwa das Anzeigen von Softwareversionsnummern auf Fehlerseiten oder das Ausgeben von Fehlermeldungen, die direkt vom System generiert wurden. Einem legitimen User nützt es allerdings nur wenig, wenn er erfährt, dass die Webseite auf einem Apache Server in Version 2.4.17 läuft. Für einen Angreifer ist diese Information aber sehr wertvoll, weil sie die Suche nach Schwachstellen deutlich vereinfacht. Genauso bringt es einem User nicht viel, wenn er durch eine Fehlermeldung erfährt, in welcher Funktion welcher Datei sich der Fehler ereignet hat. Einem Angreifer kann diese Information aber zu einem tieferen Einblick in das System verhelfen.
Die Preisgabe von technischen Informationen lässt sich in der Regel recht einfach unterbinden. Das Nicht-Anzeigen der Server Version erfordert etwa nur eine Zeile in der config Datei. Redselige Systemfehlermeldungen können dadurch unterbunden werden, dass eine Default Fehlerseite eingerichtet wird, die immer dann angezeigt wird, wenn etwas Unvorhergesehenes passiert ist.
Schwieriger zu erkennen und zu beheben sind logische Fehler, bei denen User mehr Dinge sehen können als sie sehen sollten. Zum einen weil diese Fehler keine Fehler im klassischen Sinn sind, die man etwa über Log Dateien ermitteln könnte, zum anderen weil sie vielleicht nur in ganz bestimmten Konstellationen auftreten. Solche Fehler finden sich typischerweise in Umgebungen, in denen vielseitige Interaktionen der User mit der Webanwendung stattfinden können, etwa in einem sozialen Netzwerk.
Oftmals entstehen diese Fehler, wenn bestimmte Parameter in der URL enthalten sind, die dort eigentlich nichts zu suchen haben. Wenn die URL zur Profilverwaltung etwa lautet www.beispiel.de/profile/changepwd?user_id=1 dann braucht es keine großartigen technischen Kenntnisse sondern lediglich etwas Neugier, um den Parameter user_id von 1 auf 2, 3 oder eine andere Zahl abzuändern und somit auf die Funktion zum Ändern des Passworts für Profile anderer User zuzugreifen. Aus funktionaler Sicht ist diese Implementierung nicht falsch, jeder User kann ja auf sein Profil zugreifen und sein Passwort ändern. Allerdings kann jeder eben auch auf beliebige andere Profile zugreifen und das ist ein gewaltiges Problem.
Was kann man machen?
Für Anwendungen, die rein informativ sind und bei denen sich mögliche User Interaktionen auf das Ausfüllen des Kontaktformulars beschränken, spielt dieser Punkt keine übergeordnete Rolle. Ganz anders sieht es aus, wenn sich User bei der Anwendung registrieren und einloggen können und dabei auch noch verschiedene Rollen einnehmen (z.B. ein User der Gratisversion kann die Dienste X und Y nutzen, ein User der Premiumversion kann zusätzlich noch die Dienste A und B nutzen).
In solchen Fällen muss natürlich sichergestellt werden, dass User auch nur wirklich genau die Aktionen ausführen können, die ihnen gemäß ihrer Rolle auch zustehen. Das fängt schon bei der Registrierung an: Existiert etwa im Request zur Webseite ein Feld wie isAdmin=false das vom User einfach auf true gesetzt werden kann? Können irgendwelche Funktionen durch Manipulation des HTML Codes auf Clientseite freigeschaltet werden, weil die entsprechenden Berechtigungen auf Seiten des Servers nicht geprüft werden?
Ist das der Fall, hat man relativ gravierende Sicherheitslücken in der Anwendung. Diese lassen sich zwar in der Regel auch nachträglich noch beheben, ziehen aber oftmals einen ganzen Rattenschwanz an Änderungen in anderen Teilen der Anwendung nach sich. Wesentlich einfacher ist es deshalb, die nötigen Sicherheitsmechanismen von Anfang an in die Anwendung zu integrieren und nicht nachträglich dran zu schustern.
Dazu sollte man vor allem auf zwei Dinge achten: Erstens sollten Berechtigungen immer so restriktiv wie möglich vergeben werden. Dazu muss im Vorfeld genau definiert werden, was bestimmte Usergruppen machen sollen. Ein normaler User in einem Onlineshop kann Produkte ansehen und kaufen aber nichts an der Seite ändern. Ein User der Gruppe Redakteur kann vielleicht neue Produkte hinzufügen und Beschreibungen anpassen aber keine technischen Änderungen an der Seite vornehmen. Ein User der Gruppe Analyst kann vielleicht Statistiken zu Userverhalten und Traffic der Seite abrufen, aber keine Produkte anlegen usw. Jeder bekommt nur genau die Berechtigungen, die zur Erledigung seines Jobs notwendig sind. Und je weitreichender die Berechtigungen sind, umso weniger Accounts sollten davon vergeben werden. Dieses Prinzip wird in der folgenden Grafik durch eine Pyramide visualisiert: Die Accounts mit den höchsten Berechtigungen (Admins) sollten nur sehr selten vorhanden sein, Funktionsrollen für bestimmte Aufgaben können ein wenig breiter verteilt werden, allerdings sollte darauf geachtet werden, dass die jeweilige Rolle auch nur die Berechtigungen erhält, die zur Erledigung der Aufgabe notwendig ist. Die Masse der User sollte dagegen normale User Accounts ohne spezielle Berechtigungen erhalten.
Zweitens sollten alle wichtigen Informationen hinsichtlich Berechtigungen auf Server Seite gespeichert und auch dort geprüft werden. Ob jemand Admin ist, sollte also auf dem Server hinterlegt sein, der dann, wenn eine Aktion Admin Rechte erfordert, prüfen kann, ob der User über diese Rechte verfügt. Wird diese Information dagegen auf Clientseite, etwa in einem Cookie, gespeichert, ist sie deutlich leichter durch den User zu manipulieren.
Worauf muss man achten – Security by Design für Netzwerke, Server und Datenbanken
Webanwendungen sind naturgemäß einem besonderen Risiko ausgesetzt, da sie über das Internet erreichbar sind. Bei anderen Systemen ist diese weltweite Erreichbarkeit dagegen nicht zwingend erforderlich. Solche Systeme sind dann gegebenenfalls nur aus einem internen Netzwerk heraus erreichbar, sodass sich ein ganz anderes Risikoprofil ergibt.
Dennoch gibt es auch hier Risiken, einerseits etwa durch interne Angreifer (z.B. unzufriedene Mitarbeiter) oder externe Angreifer, die sich über Angriffsvektoren wie Social Engineering Zugang zu dem internen Netzwerk verschafft haben. Auch Anwendungen, die nicht direkt aus dem Internet erreichbar sind, sollten also nach dem Prinzip Security by Design aufgesetzt werden.
Die meisten Regeln, die für Webanwendungen beachtet werden sollten, können leicht abgewandelt auch für andere Systeme wie Server, Netzwerke oder Datenbanken angewandt werden. Im Gegensatz zu Security by Design in selbst entwickelter Software geht es bei Security by Design in Systemen wie Netzwerken allerdings nicht darum, etwas von Grund auf neu zu konzipieren, sondern eher darum, vorhandene Komponenten (Server von Anbieter A, Router von Anbieter B, Systemüberwachungssoftware von Anbieter C) so zu kombinieren, dass die Sicherheit des entstandenen Systems möglichst hoch ist.
Das hat den Vorteil, dass man mit einer gewissen Sicherheit davon ausgehen kann, dass die einzelnen Komponenten relativ sicher sind, bzw. bei Problemen vergleichsweise schnell mit Updates versorgt werden können. Anbieter mit zigtausenden Mitarbeitern wie Cisco oder Microsoft sind in der Regel in der Lage, auch bei größeren Schwachstellen zeitnah Updates ausliefern zu können. Die Integration von Sicherheitsupdates in einer selbst entwickelten Webseite in einer drei Mann Firma kann dagegen deutlich länger dauern.
Die Schwierigkeit, Security by Design für Systeme wie Netzwerke anzuwenden, liegt dagegen eher in einer reibungslosen Integration aller Bestandteile des geplanten Netzwerks. Dabei muss einerseits die Sicherheit des Gesamtsystems gegeben sein, andererseits aber auch ein normaler Ablauf der betrieblichen Prozesse ermöglicht werden.
Restriktive Berechtigungen
Viele technischen Sicherheitsmaßnahmen können durch den Faktor Mensch vergleichsweise einfach ausgehebelt werden. Eine Firewall kann ein internes Netzwerk noch so gut vom Internet abschirmen, wenn ein Mitarbeiter dann aber den auf dem Parkplatz gefundenen USB-Stick in den Firmenrechner steckt, nutzt das nicht mehr viel.
Dieses Risiko kann wohl nie komplett eliminiert werden. Beim Aufbau eines Systems können durch eine restriktive Vergabe von Berechtigungen aber zumindest die möglichen Auswirkungen minimiert werden. Dazu sollte jeder nur genau die Berechtigungen erhalten, die er zur Erledigung seiner Arbeiten benötigt. Sind zeitweise, zum Beispiel im Rahmen eines Projekts, zusätzliche Rechte erforderlich, sollten diese auch nur genau für den Projektzeitraum gewährt werden.
Zudem sollte darauf geachtet werden, Berechtigungen abhängig von den Aufgaben, die ein Mitarbeiter erledigen soll, zu vergeben und nicht nach dessen Jobtitel. Der CTO eines Konzerns wird kaum selbst den Server administrieren und dort etwa User anlegen, ein eigener Admin Zugang ist für ihn also nicht nötig, auch wenn er möglicherweise aufgrund seiner Position das Bedürfnis hat einen zu haben.
Zu weitreichende Berechtigungen können einem Angreifer aber dann die weitere Ausbreitung im Netzwerk massiv erleichtern. Umgekehrt sind restriktive Berechtigungen also auch ein Mittel, um einen Angreifer auszubremsen und die Chance zu erhöhen, rechtzeitig auf den Angriff aufmerksam zu werden.
Input und Traffic überwachen
Während man bei einer Webseite in der Regel ein relativ genaues Bild möglicher Angriffsflächen hat (in der Regel schon mal alle Möglichkeiten für User Input), sieht die Situation bei einer komplexen IT-Landschaft aus verschiedenen Servern, Datenbanken und verbindenden Netzwerken schon ganz anders aus. Hier sind die möglichen Angriffsflächen deutlich weitreichender.
Um die daraus entstehenden Risiken in den Griff zu bekommen, bietet sich technologische Hilfe an:
- Firewalls sollten genutzt werden, um unerwünschte Anfragen von außerhalb des Netzwerks zu blocken.
- Intrusion Detection Systeme (IDS) sollten genutzt werden, um frühzeitig auf laufende Angriffe aufmerksam gemacht zu werden, beispielsweise laufende Portscans.
- Security Information and Event Management (SIEM) Systeme sollten genutzt werden, um Anomalien festzustellen, beispielsweise stark ansteigende Abflüsse von Daten aus dem Netzwerk.
Neben den technologischen Hilfsmitteln sollte aber auch hin und wieder ein Blick in relevante Log Dateien geworfen werden, um auf diese Weise Auffälligkeiten feststellen zu können, die einem automatisierten System eventuell entgehen.
So wenig wie möglich preisgeben
Server und die darauf laufenden Services identifizieren sich gegenüber anderen Programmen durch sogenannte Banner, die Namen und Versionsnummern der jeweiligen Software enthalten. Wo immer möglich, sollten diese Banner allerdings deaktiviert werden. Denn eines der ersten Dinge, die jeder Angreifer machen wird, ist sich einen Überblick über Services und deren Versionen zu verschaffen (Enumeration).
Wer etwa weiß, dass auf dem Zielserver OpenSSH in der Version 7.9. läuft, kann sich bei der Suche nach Schwachstellen auf diese Version konzentrieren. Wer nur weiß, dass OpenSSH läuft, muss entweder versuchen, auf anderem Weg die Versionsnummer zu enumerieren oder alle möglichen Schwachstellen von OpenSSH testen.
In vielverwendeter Software werden typischerweise auch viele kleine und große Mängel gefunden. Für den häufig verwendeten Apache Server sind aktuell etwa 255 Schwachstellen auf CVEdetails aufgeführt, für Windows 10 sogar 1111. Diese alle zu überprüfen dauert einiges an Zeit. Und dabei steigt die Wahrscheinlichkeit, dass der Angriff nicht unbemerkt bleibt, wodurch das Opfer in der Lage ist, rechtzeitig Gegenmaßnahmen einzuleiten.
Nicht benötigtes deaktivieren
Alles was nicht regelmäßig genutzt wird, sollte auch nicht zugänglich sein. Bei Servern betrifft das insbesondere Ports. Nur diejenigen, die wirklich benutzt werden, sollten auch offen sein, bei einem Webserver etwa die Ports 80 und 443. Nicht genutzte Ports wie 25 (SMTP) und 22 (SSH) sollten dagegen geschlossen werden.
Ähnlich sieht es bei Netzwerken aus. WPS (Wifi protected Setup) mag ein angenehmes Feature sein, um Geräte in das Netzwerk einzubinden. Es stellt allerdings auch ein mögliches Sicherheitsproblem dar und sollte deshalb möglichst wieder deaktiviert werden, wenn das Gerät hinzugefügt wurde.
Das Gleiche gilt auch für Geräte: Eine Bluetooth Verbindung zwischen Laptop und Handy kann manchmal sehr nützlich sein. Wird sie aber gerade nicht benötigt, sollte man Bluetooth sowohl am Laptop als auch am Handy deaktivieren.
Wie testet man Security by Design?
Wenn man eine Anwendung sicher entwickelt, muss man natürlich auch testen, ob die implementierten Funktionalitäten und Sicherheitsmechanismen überhaupt verlässlich funktionieren. In kleineren Firmen wird dies häufig von denjenigen übernommen, die die Anwendung auch entwickelt haben. Das ist für das Testen der erwünschten Funktionalität in der Regel kein Problem: Der Entwickler weiß, was die Anwendung können muss und kann dann gezielt testen, ob die entsprechenden Funktionalitäten wie gewünscht funktionieren.
Problematisch wird es dann aber beim Testen auf Sicherheit. Hierbei wird eine Anwendung ja so verwendet, wie es eben nicht vom Entwickler gedacht war. Beispielsweise wird versucht, in ein Feld das nur Buchstaben akzeptieren sollte, JavaScript Code einzugeben, um diesem vom Browser ausführen zu lassen. Hier entsteht dann doch ein recht hohes Risiko, dass der Entwickler „den Wald vor lauter Bäumen nicht mehr sieht“ und gar nicht auf die Idee kommt, bestimmte Dinge zu testen. Was natürlich auch der Tatsache geschuldet ist, dass seine Hauptaufgabe das Entwickeln von Software ist und nicht das Ausnutzen von Schwachstellen in dieser Software.
Größere Firmen haben dagegen eigene Tester, die sich auch nur um das Testen der Anwendung kümmern und nicht um deren Entwicklung, sodass hier zumindest eine gewisse Unabhängigkeit gegeben ist. Aber auch hier gibt es zwei Probleme: Erstens sind auch die Tester Teil der IT-Abteilung und somit nicht vollkommen unabhängig von ihren Kollegen in der Entwicklung. Wenn also der Leiter der IT-Abteilung beschließt, dass der Zeitverzug bei der Entwicklung schon zu groß ist, wird die Zeit, die für das Testen der Anwendung notwendig wäre, möglicherweise drastisch reduziert. Auch kann in diesem Szenario nicht ausgeschlossen werden, dass Fehler eventuell nicht auf offiziellem Weg gemeldet werden, sondern unter der Hand an die Entwicklerkollegen weitergegeben werden, damit diese nicht dumm dastehen. Aus kollegialer Sicht ist das natürlich ein feiner Zug, es führt aber leider auch dazu, dass Fehler möglicherweise nicht korrekt oder nicht vollständig behoben werden, sondern nur an den Symptomen herumgedoktert wird.
Zweitens liegt auch bei „firmeneigenen“ Testern der Fokus eher auf einer reibungslosen Funktionalität der Anwendung, das heißt es wird eher nach Fehlern gesucht, die die Nutzung der Anwendung erschweren, als nach solchen, die die Anwendung für Zwecke benutzen, für die sie nie vorgesehen war.
Um diese Probleme zu umgehen sollte der Test einer Anwendung zuallererst von unabhängigen Dritten durchgeführt werden, sodass eine vollkommene organisatorische Unabhängigkeit gegeben ist. Dies gewährleistet zum einen, dass die Anwendung von Profis untersucht werden kann, die sich täglich damit beschäftigen, Anwendungen auf deren Sicherheit zu überprüfen. Zum anderen ist sichergestellt, dass alle gefundenen Probleme transparent dokumentiert werden und nichts unter den Tisch gekehrt wird, wie es vielleicht der Fall wäre, wenn sich Tester und Entwickler persönlich kennen.
Ist die Anwendung getestet worden, erhält man als Kunde einen Report mit den beschriebenen Schwachstellen, den Schritten die durchgeführt wurden, um die Schwachstellen auszunutzen, sowie Empfehlungen, welche Schritt nötig sind, um die Sicherheit der Anwendung zu verbessern. Zudem ist angegeben, wie kritisch eine Schwachstelle ist (wir bei pen.sec visualisieren dies durch einen Tacho der von Grün über Gelb bis Rot reicht). Bei der Behebung der Schwachstellen können also gezielt die kritischsten Sicherheitslücken zuerst beseitigt werden.
Case Study: Corona Selbsttest
Damit dieser Artikel nicht nur aus grauer Theorie besteht, soll noch ein aktuelles Beispiel angeführt werden, in dem Security by Design Prinzipien auf besonders eindrückliche Weise missachtet wurden: Die bei Aldi verkauften Selbsttest Aesku Rapid (bzw. die dazugehörige Webanwendung) der Firma Aesku Diagnostics GmbH wiesen in einer ersten Version dermaßen viele Schwachstellen auf, dass ihr Einsatz de facto wertlos gemacht wurde, da sich jeder beliebig viele Negativ Zertifikate ausstellen konnte.
Geplante Funktion
Geplant war der Ablauf wie folgt:
- Kunde kauft den Test.
- Kunde macht den Test.
- Falls negativ kann Kunde den QR-Code scannen und auf der Webseite ein Zertifikat erstellen.
- Zertifikat ist für 24 Stunden gültig.
Verletzungen von Security by Design Prinzipien
In der aktuellen Pandemiesituation kann es sicher vorkommen, dass bestimmte Dinge auch mal schneller ablaufen müssen als sonst. Und wo etwas beschleunigt wird, steigt natürlich auch das Potenzial für Fehler. Dennoch muss man festhalten, dass bei der Entwicklung der Anwendung scheinbar keinerlei Gedanken an die Verarbeitung persönlicher Daten verschwendet wurden. Anders lässt es sich nicht erklären, dass selbst simpelste Mechanismen, die zur Sicherheit beigetragen hätten, nicht umgesetzt wurden.
Informationen sehen die man nicht sehen sollte
Die Probleme fingen schon damit an, dass die QR Codes außen auf die Produktverpackung gedruckt wurden. Ein Kauf der Tests war also nicht nötig, stattdessen konnte auch einfach im Laden der Code gescannt und der Test dann zurückgelegt werden. Die Lösung hierfür wäre simpel gewesen: Statt außen druckt man den Code einfach auf die Innenseite der Verpackung oder legt einen Beipackzettel mit dem Code bei. Das bringt natürlich keine 100 prozentige Sicherheit, da ein Kunde den Test ja immer noch im Laden öffnen kann, aber es erhöht zumindest das Sicherheitslevel. Zudem steigt die Chance, dass das Öffnen von Tests im Laden von Mitarbeitern bemerkt wird, die dann entsprechende Maßnahmen ergreifen können.
Nach dem Scannen des Codes kann auf der Webseite ichtestemichselbst.de ein Zertifikat erstellt werden. Dazu muss entweder die Nummer des Personalausweises oder des Führerscheins eingegeben werden. Dinge also, die vielleicht nicht so privat sind wie eine PIN, die man einem Fremden auf der Straße aber sicher nicht verraten würde. Man sollte also annehmen, dass diese Informationen von der Webseite sicher verarbeitet werden. Aber weit gefehlt: Einzig variabler Teil der URL des Zertifikats war der Unix Zeitstempel (Anzahl der Sekunden die seit 1970 vergangen sind), wurde dieser Teil der URL verändert, konnten Zertifikate anderer Personen aufgerufen und auch heruntergeladen werden. Auch hier wäre die Lösung nicht schwierig gewesen: Statt eines fortlaufenden Zeitwertes hätte man einen Wert verwenden müssen, der nicht sinnvoll zu erraten ist. Zwar wurde der Zeitstempel im Nachhinein durch einen Hashwert ersetzt, der nicht mehr einfach erraten werden kann, doch die negativen Berichte sind nun schon in der Welt und es bleibt abzuwarten, welches Vertrauen die Kunden dem Anbieter künftig noch entgegenbringen werden.
Die ursprüngliche Implementierung ist dabei gleich in mehrerlei Hinsicht problematisch: Durch die vorhersehbaren URLs kann sich jeder Zertifikate besorgen, nicht einmal das Scannen des QR Codes auf der Verpackung war mehr nötig. Ein Verhalten also, dass das Konzept der Selbsttest zur Pandemiebekämpfung ad absurdum führt. Darüber hinaus handelt es sich auch um ein gravierendes Data Leak, da personenbezogene Daten anderer Menschen eingesehen werden konnten. Dieses Leak wurde mittlerweile als meldepflichtig eingestuft und dem Landesdatenschutzbeauftragten gemeldet. Man kann deshalb davon ausgehen, dass zu einem späteren Zeitpunkt ein Bußgeld verhängt wird.
Aktionen durchführen die nicht erlaubt sein sollten
Ein klassischer Logikfehler: aus einer Packung mit fünf Tests sollten sich auch nur fünf Zertifikate generieren lassen. Allerdings war es mit dem QR Code zumindest anfangs möglich, unbegrenzt Zertifikate zu generieren, unabhängig davon, ob die fünf Tests schon lange verbraucht waren. Auch hier ist die Lösung simpel: Jeder QR Code enthält eine 128 Bit ID, alles was auf Server Seite noch zu tun ist, ist die Anzahl an Zertifikaten zu zählen, die mit dieser ID erstellt wurden. Sind bereits fünf Zertifikate generiert, wird das Ausstellen eines sechsten verweigert. Abgesehen davon, dass es für die Bekämpfung einer Pandemie nicht gerade hilfreich ist, wenn sich jeder unbegrenzt negative Tests ausstellen kann, hat dieser Implementierungsfehler auch ganz konkrete Folgen auf den finanziellen Erfolg der Firma: Warum sollten sich Kunden neue Tests kaufen, wenn sie mit einer Packung schon unbegrenzt viele Zertifikate erstellen können?
Die Begrenzung auf fünf Zertifikate pro Packung wurde nach Bekanntwerden des Problems zwar eingeführt, der QR Code befand sich aber weiterhin außen auf der Packung, da die Produktion nicht zeitnah umgestellt werden konnte. Daraus ergibt sich ein neues Problem: Die Zahl der Zertifikate ist nun zwar beschränkt, doch möglicherweise geht der rechtmäßige Besitzer der Tests leer aus, wenn sein Code im Laden bereits von einem anderen Kunden gescannt und zur Generierung von Zertifikaten verwendet wurde.
Ein weiterer Logikfehler besteht darin, dass keinerlei Verknüpfung zwischen einem negativen Test und einem Zertifikat besteht. D.h. das Ausstellen eines Zertifikats ist nicht an ein negatives Testergebnis gebunden, auch wenn man sich positiv testet, kann man sich anschließend ein Negativ Zertifikat ausstellen. Man kann hier natürlich auf die Ehrlichkeit der Bürger vertrauen, sinnvoller wäre aber sicherlich eine technologische Lösung, die nur dann die Möglichkeit bietet ein Zertifikat zu generieren, wenn das Testergebnis auch tatsächlich negativ war. Gelöst werden könnte dies etwa dadurch, dass der QR Code nicht frei zugänglich ist, sondern von dem mitgelieferten Testgerät erst dann generiert wird, wenn der Test tatsächlich negativ war. Dafür wäre sicher eine etwas umfangreichere Elektronik und auch ein größeres Display nötig, da solche Komponenten aber massenhaft in Asien gefertigt werden, kann man davon ausgehen, dass sich der Preis der Tests nur unwesentlich erhöhen würde, die Sicherheit des Gesamtsystems würde dagegen deutlich profitieren.
Fazit
Man kann natürlich nur spekulieren, welche Kosten mit der nachträglichen Änderung der Anwendung verbunden sind, wie hoch ein mögliches Bußgeld ausfallen wird und in welchem Maße das Debakel künftige Geschäfte des Unternehmens erschwert. Mit ziemlicher Sicherheit ist diese Summe aber höher als es die Kosten für die Entwicklung einer sicheren Anwendung nach dem Security by Design Prinzip gewesen wären.
Auswirkungen bei Verletzung des Security by Design Prinzips
Der Verzicht, eine Anwendung gemäß Security by Design zu entwickeln, mag sich kurzfristig in etwas geringeren Entwicklungskosten und einer geringeren Time to Market niederschlagen. Langfristig entstehen dadurch aber diverse Risiken, die sich im Extremfall sogar auf die Existenz eines Unternehmens auswirken können.
Kosten für Beseitigung der Fehler
Eine Anwendung von Grund auf sicher zu entwickeln ist sicher aufwendiger (und somit auch teurer) als eine Entwicklung bei der kein Wert auf Sicherheit gelegt wird. Allerdings ist es immer noch deutlich billiger als eine fehlerhaft entwickelte Anwendung nachträglich sicher machen zu wollen. Klar, manche Probleme lassen sich auch im Nachhinein ohne größere Schwierigkeiten beheben. Fehlende Header können etwa recht einfach über Konfigurationsdateien ergänzt werden:
Header set X-XSS-Protection 0 #Beispiel für Apache
Andere Probleme ziehen sich dagegen durch die komplette Anwendung und erfordern eine Vielzahl an Änderungen. Wenn etwa an einer Stelle der Anwendung der User Input ungefiltert verarbeitet wird, stehen die Chancen ziemlich gut, dass dies auch bei allen anderen Teilen der Anwendung so ist in denen User Input verarbeitet wird. Bei umfangreichen Anwendungen können das leicht dutzende Stellen sein, die dann überprüft und abgeändert werden müssen und dennoch kommt es wahrscheinlich vor, dass man irgendeine Stelle vergisst.
Manche Probleme sind vielleicht auch komplett unbehebbar, weil Abhängigkeiten bestehen, die sich nicht sinnvoll auflösen lassen. In diesem Fall bleibt nur mit dem Problem zu leben (ganz schlecht!) oder die Anwendung neu zu konzipieren (besser, aber teuer!). Letzteres ist vor allem dann extrem teuer, wenn die Anwendung ursprünglich als Monolith entwickelt wurde und nun komplett neu aufgesetzt werden muss. Mittlerweile werden Anwendungen zwar auch immer häufiger aus voneinander unabhängigen Microservices zusammengesetzt, sodass bei Problemen nur einzelne Services ersetzt werden müssen und nicht mehr die komplette Anwendung, doch auch das erfordert meist noch mehr Aufwand als eine von Anfang an sichere Anwendung zu entwickeln.
Geldstrafen
Seit die DSGVO in Kraft getreten ist, sind für Datenschutzverletzungen Strafen von bis zu 20 Millionen bzw. 4% des weltweiten Jahresumsatzes möglich. Ein unerlaubter Zugriff auf Kundendaten hat für Unternehmen also direkte finanzielle Konsequenzen. Diese sind zwar in der Regel nicht existenzbedrohend, können aber doch recht einschneidend sein. Vor allem wenn man bedenkt, dass schon recht simple Mechanismen die Sicherheit einer Anwendung deutlich erhöhen können.
Wer sich einen kleinen Überblick darüber verschaffen möchte, was aktuell so geahndet wird, findet auf dem DSGVO Portal eine Übersicht über aktuell verhängte Bußgelder, sowie das Vergehen, welches damit bestraft wurde. Am 11.3.2021 hat etwa das Italienische Ministerium für wirtschaftliche Entwicklung eine Geldbuße über 75.000 Euro für die Veröffentlichung der Daten von 5000 Managern kassiert. Einen Tag zuvor wurde eine „Fahrlässige Verletzung der datenschutzrechtlichen Rechenschaftspflicht“ seitens des VfB Stuttgart mit 300.000 Euro geahndet. Das auch die oberen Bereiche des Strafmaßes durchaus genutzt werden, zeigt eine Strafe über 8.150.000 Euro, die VODAFONE ESPAÑA, S.A.U. für anhaltende Werbenachrichten und Anrufe bezahlen muss.
Schadensersatz
Für Privatanwender ist es nur sehr schwer möglich, Unternehmen direkt für Versäumnisse im Hinblick auf IT-Sicherheit zur Verantwortung zu ziehen. Die gesetzlich verhängten Strafzahlungen landen in der Staatskasse, Enduser erhalten, wenn überhaupt, einen Gutschein oder ein kostenloses Credit Monitoring für das folgende Jahr, falls die erbeuteten Daten für Kreditkartenbetrug oder Identitätsdiebstahl genutzt werden.
Anders sieht es im B2B Bereich aus. Wenn hier sensible Daten verloren gehen, etwa Patente, oder aktuell in der Coronakrise Forschungsdaten zu Impfstoffen, denn entstehen schnell Schäden in Millionenhöhe. Sind es die eigenen Daten und man hat die Sicherheitslücken selbst verbockt, hilft vielleicht allenfalls noch eine Versicherung dabei den Schaden abzumildern. Anders sieht es aus, wenn ein Dritter für den Datenverlust verantwortlich ist. Wenn beispielsweise ein Automobilzulieferer gehackt wird und sich unter den erbeuteten Daten auch Informationen des Automobilherstellers befinden. In diesem Fall könnte der Hersteller durchaus versuchen, sich den entstandenen Schaden vom Zulieferer ersetzen zu lassen. Und im Gegensatz zu Privatanwendern haben große Unternehmen auch die Manpower und das Geld um selbst jahrelange Prozesse zu finanzieren.
Reputationsverlust
Fragen Sie sich selbst: Würden Sie noch guten Gewissens bei einem Onlineshop einkaufen, dem gerade mehrere Millionen Kreditkarten Daten seiner User abhanden gekommen sind? Vermutlich nicht. Während Geldstrafen vielleicht unangenehm sind, aber dann doch recht schnell wieder vergessen werden, kann sich der Verlust der eigenen Reputation auch noch Jahre später bemerkbar machen.
Insbesondere auch deswegen, weil solche Daten dann nicht mehr aus der Welt zu schaffen sind. Einmal geleakte Emailadressen und Passwörter sind schnell in diversen Listen enthalten und werden für Spamnachrichten verwendet. Kreditkarteninformationen oder Informationen, die einen Identitätsdiebstahl ermöglichen, werden gegen Geld in diversen Hackerforen zum Kauf angeboten.
Nun ist es für die meisten Kunden sicher kein Drama, wenn man hin und wieder eine schlecht gemachte Spam Mail im Postfach vorfindet, die einen zur Bestellung günstiger Potenzpillen bewegen will. Zudem sind viele User vermutlich auch nicht in der Lage, die erhaltenen Spam Mails einem Data Leak bei einem bestimmten Anbieter zuzuordnen, sodass sich manche Unternehmen sicher entscheiden werden, dass Risiko eines Reputationsverlustes zu akzeptieren.
Doch dass ein unerlaubter Zugriff auf Userdaten auch ganz andere, weit schwerwiegendere Folgen haben kann, zeigen zwei Fälle aus der jüngeren Vergangenheit:
- Ashley Madison: Nach dem Hack der Seitensprungplattform Ashley Madison im Jahr 2015, bei dem Daten von 32 Millionen Usern inklusive privater Informationen wie sexueller Vorlieben erbeutet wurden, nahmen sich mindestens zwei Mitglieder das Leben. (Link zum BBC Artikel)
- Vastaamo: Es gibt wahrscheinlich kaum etwas das persönlicher ist als Gesprächsprotokolle zwischen Psychiatern und ihren Patienten. Man mag sich gar nicht ausmalen was passiert, wenn solche Daten öffentlich zugänglich gemacht werden. Genau das ist aber 2020 in Finnland passiert, als der private Therapieanbieter Vastaamo gehackt wurde und Daten von zehntausenden Patienten in die falschen Hände gerieten. Teile des Datensatzes wurden bereits veröffentlicht, andere Patienten erhielten Zahlungsaufforderungen in Bitcoin um sich von einer Veröffentlichung freizukaufen. (Link zum Guardian Artikel)
Neben einer erhaltenswerten Reputation, die einem als Unternehmen weitere Geschäfte sichert, hat man als Betreiber einer Webseite also auch eine moralische Verpflichtung, Schaden von seinen Usern fernzuhalten.
Natürlich kann es keine 100 prozentige Sicherheit geben. Doch wenn bei der Entwicklung einer Anwendung von vorneherein deren Sicherheit berücksichtigt wird, was insbesondere bei Anwendungen, die sensible Daten verarbeiten, wirklich nicht zu viel verlangt sein sollte, dann lässt sich zumindest das Risiko, Opfer eines erfolgreichen Angriffs zu werden, reduzieren.
Einfallstor für weitere Angriffe
Last but not least stellt eine fehlerhafte Anwendung natürlich immer auch ein Einfallstor für weitere Angriffe, etwa auf nachgelagerte oder verbundene Systeme, dar. Insbesondere moderne Webanwendungen sind nur noch in den seltensten Fällen als stand-alone Anwendungen konzipiert. Stattdessen existieren diverse Schnittstellen, etwa zu Zahlungsdienstleistern, Datenbanken, Datawarehouses die Informationen aus diversen Datenbanken aggregieren, Anbindungen an Bestandsverwaltungs- und Lagermanagementsoftware von Drittanbietern, usw.
Dadurch entsteht natürlich ein Risiko, dass sich ein Anbieter, der sich Zugang zu einem Teil dieses Systemverbunds verschafft hat, von diesem weitere Angriffe auf nachgelagerte Systeme starten kann. Und während sich etwa die Kosten für Geldstrafen zumindest in ihrer maximalen Höhe schätzen lassen, sind Angriffe, die tief in das System vordringen, in ihrer Auswirkung praktisch unbegrenzt. Über in das Netzwerk integrierte IoT Geräte könnte etwa Einfluss auf die Produktion genommen werden, wodurch schnell Produktionsausfälle und Materialverluste in Millionenhöhe pro Tag auflaufen können.
Fazit
Security by Design ist mittlerweile eigentlich keine Option mehr, sondern vielmehr eine Notwendigkeit im Softwareentwicklungsprozess. Darauf zu verzichten kann auf lange Sicht extrem kostspielig werden und im Extremfall sogar die Existenz eines Unternehmens gefährden, wenn das Vertrauen von Kunden irreparabel zerstört ist.