Ich habe bereits ausführlich erläutert, warum Anwendungssicherheit aus mehreren Ebenen besteht. Ich wiederhole das, weil wir manchmal daran erinnert werden müssen, dass moderne Anwendungen niemals isoliert bereitgestellt werden. Das werden sie nicht.
Jede moderne Anwendung wird auf einer bestimmten Plattform bereitgestellt. Das kann Apache oder IIS sein, aber auch ein Anwendungsserver von Oracle oder IBM. Ebenso kommen node.js mit Express oder Python mit allen erforderlichen Bibliotheken infrage. So wie wir uns darauf verlassen, dass Betriebssysteme und Virtualisierungslösungen bzw. Container die Netzwerkfunktionen für uns bereitstellen, sind Anwendungen auf Plattformen und Bibliotheken angewiesen, die Protokolle wie TCP und HTTP handhaben.
Darüber hinaus nutzen Entwickler Bibliotheken, um bestimmte Funktionen bereitzustellen. Das Rad neu zu erfinden, ist Zeitverschwendung. Daher greifen sie für JSON-Parser, Dateiverwaltung, Authentifizierung und Autorisierung sowie Datenbankunterstützung auf Open-Source-Lösungen und andere Quellen zurück. Gleiches gilt für das Layout und die Verwaltung der Benutzeroberfläche. Heutzutage verwenden die meisten Entwickler Bibliotheken für diese Funktionen, damit sie sich auf das konzentrieren können, was einen Mehrwert schafft: Geschäftslogik und Dienste.
Eine 2017 von Contrast Labs durchgeführte Untersuchung von Anwendungen ergab, dass „Softwarebibliotheken von Drittanbietern 79 % des Codes einer Anwendung ausmachen“. Bei Java lag der Durchschnitt bei 107 verschiedenen Bibliotheken. Bei .NET? 19. Ich selbst verwende mit node.js mindestens fünf verschiedene Bibliotheken.
Was Sie jedoch aufhorchen lassen sollte, ist, was sie über die Sicherheitslage im Zusammenhang mit dieser Aufteilung herausgefunden haben.
Obwohl eine App zu 79 % aus Bibliotheken besteht, entfallen auf diese nur 2 % der bekannten Schwachstellen (also CVEs). Auf benutzerdefinierten Code entfällt mit 97,3 % nahezu der gesamte Rest der Schwachstellen.
Dieses Missverhältnis beim Sicherheitsrisiko zwischen Bibliotheken und Schwachstellen könnte erklären, warum eine SANS-Umfrage zu dem Ergebnis kam: „Obwohl 23 % der Befragten in hohem Maße auf Softwareprodukte und -dienste von Drittanbietern (COTS, cloudbasierte Dienste und Open-Source-Software) angewiesen sind, übernehmen sie nicht genügend Verantwortung dafür, die Sicherheit von Drittanbieterlösungen zu gewährleisten. Nur 23 % der Sicherheitsprogramme berücksichtigen COTS.“
Hm. Nun, das könnte die von Kenna Security gemeldete geringe Reaktionsquote bei der Behebung von Schwachstellen erklären. Bereits 2015 berichtete Kenna Security über eine Studie mit einer Stichprobe von 50.000 Organisationen, 250 Millionen Schwachstellen und über einer Milliarde (EINER MILLIARDE) Sicherheitsvorfällen. Dabei wurden zwei sehr interessante Erkenntnisse zur Behebung von Schwachstellen gewonnen:
- Im Durchschnitt benötigen Unternehmen 100 bis 120 Tage, um Sicherheitslücken zu beheben.
- Nach 40 bis 60 Tagen liegt die Wahrscheinlichkeit, dass eine CVE ausgenutzt wird, bei über 90 Prozent.
- Zwischen dem Zeitpunkt, ab dem eine Schwachstelle wahrscheinlich ausgenutzt wird, und ihrer Behebung liegen etwa 60 Tage.
Mit anderen Worten: Die meisten Unternehmen beheben diese 2 % der Schwachstellen nicht schnell genug, um zu verhindern, dass eine davon ausgenutzt wird. Möglicherweise liegt das daran, dass sie sich in Bibliotheken befinden, die nicht in das Sicherheitsprogramm des Unternehmens einbezogen sind.
Unabhängig davon, warum das so ist, muss dies oberste Priorität haben. Lassen Sie mich erklären, warum.
Früher mussten Angreifer:
- Von der Sicherheitslücke erfahren
- Eine Opfer-Website ausfindig machen
- Versuchen, einen Exploit auszuführen
Dies erfolgte manuell und war zeitaufwendig. Wenn Sie kein prominentes Ziel waren, würde niemand seine Zeit mit Ihnen verschwenden.
Heutzutage werden Informationen über Schwachstellen mit Internetgeschwindigkeit verbreitet (also mit Lichtgeschwindigkeit, falls Sie sich das gefragt haben. Glasfaser-Backbone und so), und die Suche nach Zielen erfolgt automatisiert. Skripte und Bots können Websites viel schneller (und kostengünstiger) als Menschen aufspüren und als Angriffsziele markieren. Auf dieselbe Weise entstehen auch Todesstern-große Botnetze aus ungesicherten IoT-Geräten. Automatisierung steigert eben nicht nur die Produktivität der Guten.
Das sind ungerichtete Angriffe. Gelegenheitsangriffe sozusagen, die nicht geplant sind. Vielleicht verfügen Sie nicht über wertvolle oder interessante Daten, aber Sie haben Ressourcen. Und Ressourcen können genutzt werden, um weitere Opfer zu finden und weitere Angriffe zu verüben – und nun ja, Sie wissen, wie das endet.
Nicht zielgerichtete Angriffe treten besonders häufig nach der Veröffentlichung einer CVE auf. Das liegt daran, dass Ihr individueller Code einzigartig ist. Zwar enthält er zahlreiche Schwachstellen, doch diese aufzuspüren kostet Zeit und Mühe. Eine CVE auszunutzen, die in einer weitverbreiteten Bibliothek oder Plattform vorhanden ist, ist dagegen kinderleicht. Diese Gelegenheit ist einfach zu gut, um sie sich entgehen zu lassen, denn die Rendite ist enorm hoch. Der Verizon DBIR von 2015 stellte fest: „Bei 70 % der Angriffe wurden bekannte Schwachstellen ausgenutzt, für die bereits Patches verfügbar waren.“
Deshalb sollte das Einspielen von Patches – entweder durch tatsächliche Softwareupdates oder virtuell mithilfe einer Web Application Firewall – oberste Priorität haben, sobald eine neue CVE in einer der 79 % der Bibliotheken bekannt wird, aus denen Ihre Anwendung besteht. Wenn diese CVE die Plattform (man denke an Apache Killer), betrifft, sollte es heißen: „Alles stehen und liegen lassen“, denn Web- und Anwendungsserver zu identifizieren ist noch einfacher, als Bibliotheken auf Schwachstellen zu untersuchen.
Tatsache ist: Selbst wenn Sie nicht prominent genug sind, um gezielt angegriffen zu werden, sind Sie dennoch gefährdet. Wahrscheinlich verwenden Sie denselben Technologie-Stack wie namhafte Organisationen, sodass auch ungezielte Angriffe Sie mit hoher Wahrscheinlichkeit treffen. Falls Sie das bezweifeln, bedenken Sie, dass ich einfach die CVE-Datenbank aufrufen und dort alle veröffentlichten CVEs zu node.js finden kann. Anschließend rufe ich builtwith.com auf und suche nach Websites, die mit Express – einem node.js-Framework – erstellt wurden. Dabei stelle ich nicht nur fest, dass die Website „230.116 aktive Websites kennt, die Express verwenden, sowie weitere 263.872 Websites, die Express früher verwendet haben“, sondern praktischerweise auch einen Link zum Herunterladen dieser Listen bereitstellt.
Es ist zwar nicht ganz das shodan.io für Web-Apps, aber es ist auch nicht viel schwieriger, eins und eins zusammenzuzählen und einen erfolgreichen Exploit zu entwickeln.
Machen Sie also nicht den Fehler zu glauben, dass Sie „nicht groß genug“ seien und deshalb eine CVE-Sicherheitslücke in einer Bibliothek oder Webplattform ignorieren könnten.
So landen Leute schließlich in den Twitter-Trends. Und zwar nicht im positiven Sinne.
Gehen Sie auf Nummer sicher. Priorisieren Sie die Reaktion auf CVEs, die den gesamten Stack Ihrer App betreffen. Von oben bis unten.
Ü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
F5 und Equinix bündeln ihre Kräfte, um die sichere Anwendungsbereitstellung in Multicloud-Umgebungen zu vereinfachen
F5 und Equinix ermöglichen es Unternehmen, sich weltweit sicher und zuverlässig mit ihren Partnern zu vernetzen.
API-Sicherheitsrisiken und -herausforderungen
Erfahren Sie, warum APIs für die moderne App-Entwicklung unverzichtbar sind und wie Sie sie vor den häufigsten Sicherheitslücken schützen. Profitieren Sie von Expertentipps und direkt umsetzbaren Strategien.
Ein Meilenstein für die Community Impact Grants von F5
F5 feiert das fünfjährige Bestehen seines innovativen Community Impact Grant-Programms, das gemeinnützige Organisationen, bei denen sich F5-Mitarbeitende ehrenamtlich engagieren, mit Fördermitteln in Höhe von 5.000 US-Dollar unterstützt.
Mit moderner, anpassungsfähiger und sicherer Gesundheits-IT Leben retten
Die IT-Investitionen im Gesundheitswesen tragen dazu bei, die schnellsten Wege zu einer besseren Versorgung zu finden, indem sie die medizinische Betreuung näher an die Patientinnen und Patienten bringen. Viele Gesundheitsunternehmen nutzen riesige Mengen an klinischen und anderen Gesundheitsdaten, um Entwicklungen zu verfolgen und übergreifende Trends in der gesamten Gesundheitslandschaft zu erkennen. Gleichzeitig nähern sie sich einer möglichst präzisen, individuell zugeschnittenen Versorgung an.
Verbesserung der Benutzer- und Administrationserfahrung durch sicheren hybriden Zugriff
Diese Kombination aus BIG-IP Access Policy Manager und Azure Active Directory ermöglicht Identitätsföderation, zentralisierten Benutzerzugriff (über Single Sign-on) und erhöhte Anwendungssicherheit (durch Multi-Faktor-Authentifizierung) für geschäftskritische Anwendungen sowie cloudbasierte und SaaS-Anwendungen. Dieser Ansatz vereinfacht die Einrichtung und Bereitstellung, reduziert den Verwaltungsaufwand und verbessert die gesamte Administration.
Das Internet der Sicherheitsdinge
Nein, das ist keine Tirade über die Sicherheit des IoT. Es ist eine Geschichte über Veränderung – genauer gesagt über Veränderung und ihre Auswirkungen auf die Sicherheit. Veränderung ist allgegenwärtig. Es gibt unzählige Axiome und Sprichwörter über Veränderung, also ist es ...