Eine aktuelle Studie der Columbia University ergab, dass wir täglich mit mehr als 70 Entscheidungen belastet sind. Und dabei sind nur die wichtigen Entscheidungen berücksichtigt, denn frühere Untersuchungen der Cornell University haben ergeben, dass wir allein in Bezug auf Lebensmittel jeden Tag über 200 Entscheidungen treffen.
Viele der Entscheidungen, die wir im Laufe eines Tages treffen, sind langfristig ohne Bedeutung. Ihre Auswirkungen sind gering, und die meisten lassen sich weder als „gut“ noch als „schlecht“ einstufen. Es sind einfach Entscheidungen, die wir getroffen haben. Manche Entscheidungen haben jedoch weitreichende Folgen. Einige treffen wir bewusst und wohlüberlegt. Andere sind unbeabsichtigt, und ihre Tragweite wird erst im Nachhinein deutlich.
Einige unbeabsichtigte Folgen, die im Nachhinein offensichtlich erscheinen, betreffen die Sicherheit unserer Anwendungen.
ENTSCHEIDUNGEN: PLATTFORMEN, FRAMEWORKS und KOMPONENTEN
Vom ersten Tag der Entwicklung an werden Entscheidungen getroffen. Viele davon betreffen Plattformen und Frameworks, Bibliotheken und Komponenten von Drittanbietern. Im Laufe der Entwicklung müssen zahlreiche solcher Entscheidungen getroffen werden. Heutzutage wird geschätzt, dass eine Anwendung zu 80–90 % aus Open-Source- bzw. Drittanbieterkomponenten besteht. Jede Entscheidung, die zur Einbindung einer Open-Source- oder Drittanbieterkomponente führt, kann Konsequenzen haben, insbesondere im Hinblick auf die Anwendungssicherheit. Die Analyse von Black Duck Software kommt auf durchschnittlich 105 Open-Source-Komponenten pro kommerziellem Softwareprodukt.
Auf den ersten Blick sind diese Folgen nicht allzu beängstigend. Schließlich zeigen Untersuchungen von Contrast Security, dass lediglich 7 % der Schwachstellen auf Softwarebibliotheken entfallen. Black Duck ermittelte durchschnittlich 22,5 Open-Source-Schwachstellen pro Anwendung. Vierzig Prozent (40 %) dieser Schwachstellen wurden als „schwerwiegend“ eingestuft. Dennoch ist das wenig, wenn man bedenkt, dass die verbleibenden 10–20 % einer Anwendung – der individuell entwickelte Code – für die meisten Schwachstellen in Anwendungen verantwortlich sind.
Leider wird der Großteil der Schwachstellen nicht über CVEs und Beispielcode für Exploits offengelegt, der Angreifern leicht zugänglich ist. In einer Umgebung, in der dieselben Komponenten und Bibliotheken häufig von Abertausenden Webanwendungen genutzt werden, müssen sich böswillige Akteure nicht besonders anstrengen, um Ziele zu finden. Derzeit verzeichnet builtwith.com – eine Website, die den Einsatz von Technologien zur Entwicklung von Apps und Websites erfasst – fast 40.000 aktive Websites, die auf Apache Struts basieren. Die meisten von uns wissen, dass veröffentlichte Schwachstellen in Apache Struts 2 erfolgreich ausgenutzt wurden, was im Internet eine leichte Panik auslöste. Ähnliche Panikreaktionen wurden durch die Offenlegung schwerwiegender Schwachstellen in anderen weitverbreiteten Open-Source- und Drittanbieterbibliotheken wie OpenSSL verursacht.
Doch nicht nur die Entscheidung, ob wir Bibliotheken oder Komponenten von Drittanbietern einbinden oder Anwendungen auf Basis von Open-Source-Frameworks entwickeln, kann problematisch sein. Auch andere Entscheidungen, die wir während der Entwicklung treffen, können schwerwiegende Folgen haben, insbesondere wenn sie zu unsicheren Entwicklungspraktiken führen.
ENTSCHEIDUNGEN: SICHERHEIT GEGEN GESCHWINDIGKEIT EINTAUSCHEN
Es ist nie überraschend zu hören, dass Sicherheit zugunsten der Geschwindigkeit geopfert wurde. Das war schon immer so. Eine McAfee-Umfrage aus dem Jahr 2014 unter 504 Sicherheitsexperten ergab, dass „die Betreiber bei etwa einem Drittel der befragten Unternehmen zugaben, regelmäßig Firewall-Sicherheitsfunktionen zu deaktivieren, um die Netzwerkleistung zu steigern.“
Wie sich herausstellt, ist es bei der Entwicklung nicht anders. Dabei liegt der Fokus nicht auf der Ausführungsgeschwindigkeit, sondern auf der Geschwindigkeit der Entwicklungspipeline. Um der Forderung nach einer schnelleren Markteinführung von Anwendungen und Updates gerecht zu werden, räumen viele ein, die Sicherheit während der Entwicklung vollständig außer Acht zu lassen. Eine Umfrage von Arxan | IBM aus dem Jahr 2017 unter Entwicklern von Mobil- und IoT-Anwendungen ergab, dass 26 % der Befragten mobile Apps überhaupt nicht auf Sicherheitsprobleme testen und fast die Hälfte (48 %) keine IoT-Apps testet. 69 % nannten den Auslieferungsdruck als Grund dafür, dass Sicherheitsaspekte häufig außer Acht gelassen werden.
Eine Umfrage unter den Teilnehmern unserer Kundenveranstaltung Agility in diesem Sommer bestätigte, dass dies tatsächlich der Fall ist. Mehr als die Hälfte – 62 % – gab zu, in ihrem Unternehmen Sicherheit zugunsten von Geschwindigkeit geopfert zu haben.
Hinzu kommen die Entscheidungen darüber, wie Unternehmen mit entdeckten Schwachstellen umgehen. Eine Analyse von Black Duck ergab, dass 10 % der im Jahr 2018 untersuchten Anwendungen noch immer für die 2014 bekannt gewordene Heartbleed-Sicherheitslücke anfällig waren. Eine von Ponemon durchgeführte ServiceNow-Studie ergab, dass erschreckende 57 % der von Sicherheitsverletzungen Betroffenen angaben, sie hätten den Vorfall durch die Installation eines verfügbaren Patches verhindern können.
ENTSCHEIDUNGEN HABEN KONSEQUENZEN
Vom ersten Entwicklungstag bis zur Phase nach der Bereitstellung sind die Entscheidungen, die wir hinsichtlich der Sicherheit des gesamten Anwendungs-Stacks treffen, von großer Bedeutung. Diese Entscheidungen sind nicht mit der Wahl zwischen Burger und Salat zum Mittagessen vergleichbar; ihre Auswirkungen können nicht nur in der IT und im Unternehmen nachhallen, sondern auch Kunden betreffen, die darauf angewiesen sind, dass App-Anbieter das Thema Sicherheit ernst nehmen.
Nur die wenigsten von uns können behaupten, noch nie ein Schreiben mit der Anrede „Sehr geehrte App-Nutzerin, sehr geehrter App-Nutzer“ erhalten zu haben, in dem wir darüber informiert wurden, dass unsere Daten offengelegt wurden. Das ist jedoch kein Freibrief, die Sicherheit zu vernachlässigen. Im Gegenteil: Wir alle sollten uns stärker dafür einsetzen, die persönlichen und vertraulichen Daten unserer Kundinnen und Kunden zu schützen.
Der beste Weg, dies zu erreichen, besteht darin, sich bewusst zu machen, dass jede Entscheidung vom ersten Entwicklungstag an eine Gelegenheit bietet, die Sicherheit der von uns entwickelten Anwendungen zu verbessern – treffen Sie Ihre Entscheidungen bewusst und mit Bedacht.
Über den Autor
Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.
Weitere Blogbeiträge von Lori Mac VittieÄhnliche Blogbeiträge
Ein umfassender Leitfaden zur Bereitstellung und Sicherheit von KI-Anwendungen
Entdecken Sie optimale Strategien für die Absicherung und Bereitstellung von KI-Anwendungen.
KI zulassen und einführen? Lehren aus der Public Cloud
Die Einführung von KI steht unmittelbar bevor und könnte entscheidend sein, um wettbewerbsfähig zu bleiben. Daher muss die IT-Sicherheit proaktiv handeln und der KI-Einführung schon jetzt einen Schritt voraus sein, um sie auf einen risikogerechten Weg zu lenken.
Stand der Anwendungsstrategie 2022: Zeit für die Modernisierung des Betriebs
Es ist deutlich geworden, dass Unternehmen ihren Fokus erneut auf die Geschäftsfunktionen richten müssen, um die Dynamik ihrer digitalen Transformation aufrechtzuerhalten. Kundenerlebnisse haben zwar weiterhin Priorität, doch auch Geschäftsfunktionen wie Recht, Personalwesen und Finanzen müssen digitalisiert werden. Das bedeutet, dass CIOs das Steuer übernehmen, während sich die digitale Transformation von der Modernisierung von Anwendungen hin zur Modernisierung von Betriebsabläufen verlagert.
F5s Weg zu einer vielseitigen Plattform für Anwendungsanalysen
F5 bietet heute die umfassendsten Anwendungsdienste entlang des gesamten Weges vom Code bis zum Kunden. Künftig werden wir verstärkt auf Anwendungstelemetrie und -analysen setzen, damit unsere Kunden wertvolle Erkenntnisse über ihre Anwendungen, Geschäftsabläufe und Benutzererlebnisse gewinnen können. Beim Ausbau unserer Cloud-Analysefunktionen werden wir ML und KI noch stärker nutzen, um unsere Kunden bei der Verbesserung ihrer Geschäftsdienste zu unterstützen.
Telemetrie: Eine andere Art von Daten
Verwenden wir den Begriff „Telemetrie“ nur, weil er attraktiver klingt als „Daten“? Letztlich sind sowohl Daten als auch Telemetrie strukturierte Informationseinheiten. Es ist kein Verbrechen, die Begriffe synonym zu verwenden. Doch wenn man es genau nimmt, gibt es einen Unterschied. Und dieser Unterschied wird immer wichtiger werden, je weiter Unternehmen in die Datenökonomie vordringen.
MTTR bedeutet nicht „Mean Time to Reboot“
„Schnell scheitern“ lautet heute das Mantra für mehr Geschwindigkeit. Ob in DevOps oder im Geschäftsleben: Wer in einer digitalen Wirtschaft agiert, muss eine möglichst perfekte Verfügbarkeit gewährleisten.