Im Allgemeinen erwartet man von einem Sicherheitsunternehmen nicht die Aussage „Schwachstellen ignorieren“. Schließlich sind Schwachstellen für Sicherheitsvorfälle von einem solchen Ausmaß verantwortlich, dass unsere Feeds noch monatelang mit nachträglichen Kommentaren, Analysen und Empfehlungen gefüllt sind.
Und ganz sicher sieht man „Schwachstellen ignorieren“ nicht in Verbindung mit dem Gedanken, „die Sicherheit zu verbessern“.
Jetzt schon – allerdings gilt auch hier, wie bei den meisten Ratschlägen, dass es Vorbehalte und Einschränkungen gibt.
Sie sollten sicherlich nicht alle Schwachstellen ignorieren, aber es gibt tatsächlich eine Kategorie von Schwachstellen, die Sie derzeit gefahrlos außer Acht lassen können – oder deren Behebung Sie zumindest auf später verschieben können. Auf dieses Konzept bin ich beim Lesen des Berichts „2018 State of Open Source Vulnerability Management“ von WhiteSource Software gestoßen.
Neben einigen sehr interessanten Statistiken stellt das Whitepaper die These auf, dass sich Schwachstellen in Open-Source-Software in zwei Kategorien einteilen lassen: unwirksame und wirksame Schwachstellen.
Die Kategorisierung von WhiteSource basiert auf der Annahme, dass einige Schwachstellen wirkungslos sind – d. h., sie können nicht ausgenutzt werden, weil sie nicht durch benutzerdefinierten Code aufgerufen werden. Wenn sich diese Schwachstellen analysieren und unterscheiden lassen, so die Argumentation, können sich Sicherheitsteams und Entwickler auf diejenigen konzentrieren, die als wirksam eingestuft werden. Dadurch lassen sich Zeit und Aufwand reduzieren und zugleich die Gesamtsicherheit der Anwendung verbessern.
Betrachten wir beispielsweise eine benutzerdefinierte Anwendung, die auf einer Open-Source-Komponente mit einer anfälligen Funktion basiert. Nach der Definition von White Source könnte die anfällige Funktion in diesem Beispiel als „wirkungslos“ eingestuft werden, da sie von der benutzerdefinierten Anwendung nie aufgerufen wird. Aufmerksame Leser werden feststellen, dass die anfällige Funktion aufgerufen werden könnte – und zwar durch eine Funktion in einer Open-Source-Komponente (entweder in einer weiteren oder in derselben Komponente) –, wodurch sie wirksam würde. Als ich WhiteSource auf diese Möglichkeit ansprach, erläuterte das Unternehmen seine Kategorisierung näher und wies darauf hin, dass diese Möglichkeit berücksichtigt wird. Wird der anfällige Code entweder durch benutzerdefinierten Code oder indirekt über eine andere Open-Source-Komponente aufgerufen, wird er als „wirksam“ eingestuft. Gibt es hingegen keinen direkten oder indirekten Pfad, über den die anfällige Funktion aufgerufen wird, wird sie als „wirkungslos“ eingestuft.
Da die Untersuchungen von WhiteSource nicht nur ergaben, dass 96,8 % der Entwickler auf Open-Source-Komponenten zurückgreifen, sondern auch, dass 7,5 % aller Projekte Sicherheitslücken aufweisen, wäre es zweifellos von großem Vorteil, priorisieren zu können, auf welche Schwachstellen man sich konzentrieren sollte. WhiteSource stellte außerdem fest, dass erstaunliche 64 % der Open-Source-Produkte ausschließlich nicht ausnutzbare Sicherheitslücken enthielten, die nach Ansicht des Unternehmens bedenkenlos ignoriert werden können.
Auch wenn ich nicht davon überzeugt bin, dass wir Schwachstellen in beliebigem Code einfach unbekümmert ignorieren sollten, nur weil dieser nicht aktiv aufgerufen wird, halte ich eine solche Unterscheidung für sinnvoll, um bei der Behebung von Schwachstellen Prioritäten zu setzen. Indem sie sich auf anfälligen Code konzentrieren, der tatsächlich aktiv aufgerufen wird, können Entwickler und Sicherheitsexperten die Gesamtsicherheit einer Anwendung unmittelbar verbessern. Dadurch werden erfahrene Entwickler effizienter eingesetzt, die laut dem Bericht von WhiteSource im Durchschnitt mehr Zeit mit der Behebung von Schwachstellen verbringen als weniger erfahrene Entwickler.
Es muss eine Methode zur Priorisierung geben. Laut WhiteSource wurden 2017 fast 3.500 Schwachstellen gemeldet, ein Anstieg um 60 % gegenüber 2016. Nicht alle dieser 3.500 gemeldeten Schwachstellen betreffen jede Anwendung oder Organisation, doch wir sollten bedenken, dass sich diese Zahlen summieren. Das heißt, bei den 3.500 handelt es sich um neue Schwachstellen, die zu einer fortlaufenden Gesamtzahl hinzukommen.
Es versteht sich von selbst, dass Code – sowohl individuell entwickelter als auch Open-Source-Code – zahlreiche Schwachstellen enthält. Die Möglichkeit, die Behebung danach zu priorisieren, ob Schwachstellen „wirksam“ oder „unwirksam“ sind, entspricht neuen Sicherheitsstrategien, bei denen das Risiko neben anderen Faktoren auch anhand der konkreten Bedrohung bewertet wird. Die konkrete Bedrohung durch eine unwirksame Schwachstelle ist nahezu nicht vorhanden. Dennoch ist es langfristig möglicherweise nicht der beste Ansatz, unwirksame Schwachstellen zu ignorieren. Es ist denkbar, dass solche Schwachstellen irgendwann wirksam werden. Änderungen an individuell entwickeltem Code durch das Hinzufügen und/oder Erweitern von Funktionen sowie Änderungen an Open-Source-Komponenten im Laufe der Zeit können dazu führen, dass ein Ausführungspfad entsteht, über den eine anfällige Funktion aufgerufen wird. Dies ist einer der Gründe, warum eine speziell auf Schwachstellen ausgerichtete Quellcodeanalyse im besten Fall kontinuierlich und im schlechtesten Fall beim finalen Build durchgeführt werden sollte.
Um jedoch Fristen einzuhalten und die Zeit der Entwickler effizient zu nutzen, könnte es derzeit eine der besten Möglichkeiten zur Verbesserung der Sicherheit sein, die „nicht wirksamen“ Schwachstellen ans Ende der Warteschlange zu stellen, damit die „wirksamen“ Schwachstellen umgehend behoben werden können.
Ü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 ...