Verbesserung der Sicherheit durch Ignorieren von Schwachstellen
Generell erwartet man von einem Sicherheitsunternehmen nicht unbedingt die Aussage „Ignorieren Sie Schwachstellen“. Schließlich sind Schwachstellen für Verstöße von solchem Ausmaß verantwortlich, dass sie unsere Feeds monatelang mit nachträglichen Kommentaren, Analysen und Empfehlungen füllen.
Und Sie sehen sicherlich nicht, dass „Schwachstellen ignoriert werden“ mit dem Gedanken verbunden ist, „die Sicherheit zu verbessern“.
Nun haben Sie das – obwohl dieser, wie die meisten Ratschläge, mit Vorbehalten und Einschränkungen verbunden ist.
Natürlich sollten Sie nicht alle Schwachstellen ignorieren, aber es gibt eine Klasse von Schwachstellen, die Sie im Moment getrost ignorieren können – oder die Sie zumindest für schlechte Zeiten zurückstellen können. Ich bin beim Lesen des „2018 State of Open Source Vulnerability Management“ von WhiteSource Software auf dieses Konzept gestoßen.
Neben einigen sehr interessanten Statistiken vertritt das Dokument die Ansicht, dass Open-Source-Schwachstellen in zwei Kategorien eingeteilt werden können: ineffektiv und effektiv.
Die Prämisse der Kategorisierung von WhiteSource besteht darin, dass einige Schwachstellen unwirksam sind, d. h. sie können nicht ausgenutzt werden, weil sie nicht durch benutzerdefinierten Code ausgelöst werden. Die Fähigkeit, zu analysieren und zu differenzieren, so die Geschichte, bedeutet, dass sich Sicherheit und Entwickler auf die als wirksam erachteten Schwachstellen konzentrieren können und so Zeit und Aufwand sparen und gleichzeitig die allgemeine Sicherheit der Anwendung verbessern können.
Stellen Sie sich beispielsweise eine benutzerdefinierte Anwendung vor, die auf einer Open Source-Komponente basiert, die eine anfällige Funktion enthält. Gemäß der Definition von White Source könnte die anfällige Funktion in diesem Beispiel als „unwirksam“ erklärt werden, da sie von der benutzerdefinierten Anwendung nie aufgerufen wird. Aufmerksame Leser werden bemerken, dass die anfällige Funktion durch eine Funktion in einer Open-Source-Komponente (entweder einer anderen oder derselben Komponente) aufgerufen werden könnte und sie somit wirksam machen könnte. Als ich WhiteSource nach dieser Möglichkeit fragte, erläuterten sie ihre Kategorisierung und wiesen darauf hin, dass diese Möglichkeit in Betracht gezogen werde. Wenn der anfällige Code entweder von benutzerdefiniertem Code oder indirekt über eine andere Open-Source-Komponente aufgerufen wird, wird er als „wirksam“ gekennzeichnet. Umgekehrt gilt: Wenn es keinen Pfad (weder direkt noch indirekt) gibt, der die anfällige Funktion aufruft, wird sie als „ineffektiv“ gekennzeichnet.
Angesichts der Tatsache, dass die Untersuchungen von WhiteSource nicht nur ergeben haben, dass 96,8 % der Entwickler auf Open-Source-Komponenten angewiesen sind, sondern auch, dass 7,5 % aller Projekte anfällig sind, wäre es sicherlich ein Vorteil, wenn man die Schwachstellen priorisieren könnte, auf die man sich konzentrieren sollte. WhiteSource stellte außerdem fest, dass satte 64 % der Open-Source-Produkte lediglich ineffektive Schwachstellen aufwiesen, die ihrer Ansicht nach getrost ignoriert werden könnten.
Obwohl ich nicht davon überzeugt bin, dass wir Schwachstellen in jedem Code einfach ignorieren sollten, nur weil sie nicht aktiv ausgenutzt werden, halte ich es für sinnvoll, eine solche Unterscheidung zu nutzen, um dem Schwachstellenmanagement Priorität einzuräumen. Indem sie sich auf anfälligen Code konzentrieren, der aktiv aufgerufen wird , können Entwickler und Sicherheitsexperten die Gesamtsicherheit einer Anwendung sofort verbessern. Dadurch werden erfahrene Entwickler besser eingesetzt, die dem Bericht von White Source zufolge im Durchschnitt mehr Zeit mit der Behebung von Schwachstellen verbringen als Juniorentwickler.
Es muss eine Art Priorisierungsmethode vorhanden sein. WhiteSource gab an, dass im Jahr 2017 fast 3.500 Schwachstellen gemeldet wurden, was einer Steigerung von 60 % gegenüber 2016 entspricht. Nicht alle dieser 3.500 gemeldeten Schwachstellen betreffen jede Anwendung oder Organisation, wir sollten jedoch bedenken, dass es sich hierbei um ansteigende Zahlen handelt. Das heißt, bei den 3500 handelt es sich um neue Schwachstellen, die zu einer Gesamtsumme addiert werden.
Es ist unnötig zu erwähnen, dass der Code – ob benutzerdefiniert oder Open Source – zahlreiche Schwachstellen aufweist. Die Möglichkeit, Abhilfemaßnahmen danach zu priorisieren, ob sie „wirksam“ oder „unwirksam“ sind, steht im Einklang mit neuen Sicherheitsstrategien, die Risiken neben anderen Faktoren auch auf der Grundlage existentieller Bedrohungen bewerten. Die existenzielle Bedrohung durch eine ineffektive Sicherheitslücke ist nahezu nicht vorhanden. Allerdings ist das Ignorieren ineffektiver Schwachstellen möglicherweise nicht der beste Ansatz auf lange Sicht. Es ist möglich, dass solche Schwachstellen letztendlich wirksam sein werden. Änderungen im benutzerdefinierten Code beim Hinzufügen und/oder Erweitern von Funktionen sowie im Laufe der Zeit vorgenommene Änderungen an Open-Source-Komponenten können dazu führen, dass ein Pfad geöffnet wird, der eine anfällige Funktion aufruft. Dies ist einer der Gründe, warum die Quellcodeanalyse speziell auf Schwachstellen hin im besten Fall kontinuierlich und im schlimmsten Fall während des endgültigen Builds erfolgen sollte.
Um Termine einzuhalten und die Zeit der Entwickler effizient zu nutzen, ist es für Entwickler vielleicht gerade jetzt eine der besseren Möglichkeiten, die Sicherheit zu verbessern, die „ineffektiven“ Schwachstellen nach hinten zu schieben, damit die „effektiven“ Schwachstellen sofort behoben werden können.