Tag 0 war Tag 1 der Entwicklung

Einer aktuellen Studie der Columbia University zufolge müssen wir täglich über 70 Entscheidungen treffen. Dies gilt, wenn man nur die wichtigen Entscheidungen zählt. Denn frühere Untersuchungen der Cornell University ergaben, dass wir an einem beliebigen Tag allein hinsichtlich der Ernährung über 200 Entscheidungen treffen.

Viele der Entscheidungen, die wir an einem Tag treffen, sind auf lange Sicht belanglos. Die Auswirkungen sind minimal und die meisten können nicht als „gut“ oder „schlecht“ eingestuft werden. Sie sind lediglich die Wahl, die wir getroffen haben. Manche Entscheidungen haben jedoch erhebliche Konsequenzen. Manche davon sind beabsichtigt und mit Voraussicht gemacht. Andere sind unbeabsichtigt und werden erst im Nachhinein offensichtlich.

Einige unbeabsichtigte Folgen, die im Nachhinein offensichtlich erscheinen, beziehen sich auf die Sicherheit unserer Anwendungen. 

Auswahlmöglichkeiten: PLATTFORMEN, FRAMEWORKS und KOMPONENTEN  

Vom ersten Tag der Entwicklung an werden Entscheidungen getroffen. Viele dieser Entscheidungen drehen sich um Plattformen und Frameworks, Bibliotheken und Komponenten von Drittanbietern. Viele dieser Entscheidungen werden während der Entwicklung getroffen. Schätzungen zufolge bestehen heute 80–90 % einer Anwendung aus Open Source-Komponenten bzw. Quellcode von Drittanbietern . Jede Entscheidung, die zur Einbindung einer Open-Source-Komponente bzw. einer Komponente aus einem Drittanbieter-Source-Produkt führt, hat potenzielle Konsequenzen, insbesondere im Hinblick auf die Anwendungssicherheit. Die Analyse von Black Duck Software kommt auf einen Durchschnitt von 105 Open-Source-Komponenten pro kommerziellem Softwareangebot.

Oberflächlich betrachtet sind diese Konsequenzen nicht so schrecklich. Schließlich ergab eine Untersuchung von Contrast Security , dass Softwarebibliotheken lediglich 7 % aller Schwachstellen ausmachen.  Black Duck fand durchschnittlich 22,5 Open-Source-Schwachstellen pro Anwendung. Vierzig Prozent (40 %) dieser Schwachstellen wurden als „schwerwiegend“ eingestuft. Dies ist jedoch minimal, wenn man bedenkt, dass die restlichen 10–20 % einer Anwendung – benutzerdefinierter Code – für die meisten Sicherheitslücken in Anwendungen verantwortlich sind.

Leider wird der Großteil der Schwachstellen nicht über CVEs offengelegt, und Beispiel-Exploit-Code ist für Angreifer leicht zugänglich. In einer Umgebung, in der Tausende und Abertausende Webanwendungen häufig dieselben Komponenten und Bibliotheken verwenden, müssen sich böswillige Akteure die Suche nach Zielen nicht allzu sehr anstrengen. Derzeit zählt builtwith.com – das den Einsatz der zum Erstellen von Apps und Websites verwendeten Technologie verfolgt – fast 40.000 Live-Sites, die auf Apache Struts basieren. Die meisten von uns sind sich der erfolgreichen Ausnutzung veröffentlichter Schwachstellen in Apache Struts 2 bewusst, die zu einer leichten Panik im Internet geführt hat. Ähnliche Panik wurde durch die Offenlegung schwerwiegender Sicherheitslücken in anderen häufig genutzten Open Source- und Drittanbieterbibliotheken wie beispielsweise OpenSSL ausgelöst.

Aber nicht nur die Entscheidung, ob wir Bibliotheken oder Komponenten von Drittanbietern einbinden oder Apps auf Open-Source-Frameworks erstellen, ist potenziell problematisch. Auch andere Entscheidungen, die wir während der Entwicklung treffen, können schwerwiegende Folgen haben, insbesondere wenn sie zu unsicheren Entwicklungspraktiken führen.

Auswahlmöglichkeiten: SICHERHEIT GEGEN GESCHWINDIGKEIT EINTAUSCHEN

Es ist keine Überraschung zu hören, dass Sicherheit gegen Geschwindigkeit eingetauscht wurde. Das war schon immer so. Eine McAfee-Umfrage aus dem Jahr 2014 unter 504 Sicherheitsexperten ergab, dass „etwa ein Drittel der befragten Organisationen bzw. Betreiber zugaben, dass sie versuchen, die Netzwerkleistung zu steigern, indem sie regelmäßig die Sicherheitsfunktionen der Firewall deaktivieren.“

Wie sich herausstellt, ist es in der Entwicklung nicht anders. Ihr Fokus liegt nicht auf der Ausführungsgeschwindigkeit, sondern auf der Pipeline-Geschwindigkeit. Um der Forderung nach zeitnaheren Anwendungsveröffentlichungen und Marktaktualisierungen nachzukommen, geben viele zu, dass sie die Sicherheit während der Entwicklung völlig vernachlässigen. Eine 2017 von Arxan | IBM durchgeführte Umfrage unter Entwicklern mobiler und IoT-Anwendungen ergab, dass 26 % der Befragten mobile Apps überhaupt nicht auf Sicherheitsprobleme testen und fast die Hälfte (48 %) IoT-Apps nicht testet.  69 % der Befragten gaben als Grund an, dass Sicherheitsmaßnahmen häufig vernachlässigt werden.

Eine Umfrage unter den Teilnehmern unserer Kundenveranstaltung „Agility“ in diesem Sommer hat bestätigt, dass dies die Realität ist. Über die Hälfte (62 %) gab zu, dass sie in ihrer Organisation Sicherheit gegen Geschwindigkeit eingetauscht hätten.

Und dann sind da noch die Entscheidungen darüber, wie Organisationen mit entdeckten Schwachstellen umgehen. Die Analyse von Black Duck ergab, dass 10 % der im Jahr 2018 gescannten Anwendungen immer noch anfällig für die Heartbleed-Sicherheitslücke aus dem Jahr 2014 waren. Einer von Ponemon durchgeführten ServiceNow-Studie zufolge gaben beunruhigende 57 % der Opfer von Datendiebstählen an, sie hätten die Datendiebstahls durch die Installation eines verfügbaren Patches verhindern können. 

Entscheidungen haben Konsequenzen

Vom ersten Tag der Entwicklung bis nach der Bereitstellung sind die Entscheidungen, die wir bezüglich der Sicherheit des gesamten Anwendungsstapels treffen, wichtig. Diese Entscheidungen sind nicht dasselbe wie ein Burger oder ein Salat zum Mittagessen. Sie haben Auswirkungen nicht nur auf die IT und das Unternehmen, sondern auch auf Kunden, die darauf vertrauen, dass App-Anbieter das Thema Sicherheit ernst nehmen. 

Die wenigsten von uns können behaupten, noch nie einen Brief mit der Aufschrift „Sehr geehrter App-Benutzer“ erhalten zu haben, in dem sie darüber informiert wurden, dass ihre Daten offengelegt wurden. Dies ist jedoch keine Erlaubnis, in Sachen Sicherheit nachlässig zu sein. Im Gegenteil, wir sollten alle bestrebt sein, unseren Kunden gegenüber einen besseren Schutz persönlicher und privater Informationen zu gewährleisten.

Der beste Weg hierzu besteht darin, zu erkennen, dass jede Entscheidung vom ersten Tag der Entwicklung an eine Chance ist, die Sicherheit der von uns entwickelten Anwendungen zu verbessern . Wählen Sie bewusst und mit Bedacht.