Inhalt
- Nur die Fakten
- Keine Bugs, kein Stress - Ihre schrittweise Anleitung zur Erstellung lebensverändernder Software, ohne Ihr Leben zu zerstören
- Auswirkungen berücksichtigen?
- Zeit, das System zu ändern?
Quelle: BrianAJackson / iStockphoto
Wegbringen:
Es ist an der Zeit, die Einschätzung des Risikos für Open-Source-Komponenten zu überdenken.
Die Entwicklung eines Systems zur Bewertung, wie ernst die Softwareentwicklergemeinschaft Sicherheitslücken nehmen soll, ist eine Herausforderung, um es leicht auszudrücken. Code wird von Menschen geschrieben und weist immer Fehler auf. Die Frage ist dann, ob wir, wenn wir davon ausgehen, dass nichts jemals perfekt sein wird, wie wir die Komponenten am besten nach ihrem Risiko kategorisieren, damit wir weiterhin produktiv arbeiten können.
Nur die Fakten
Zwar gibt es viele verschiedene Ansätze, die zur Lösung dieses Problems herangezogen werden könnten, wobei jeder eine gültige Begründung hat, doch scheint die gängigste Methode auf einem quantitativen Modell zu beruhen.
Einerseits kann ein quantitativer Ansatz zur Beurteilung des Schweregrads einer Sicherheitsanfälligkeit nützlich sein, da er objektiver und messbarer ist und ausschließlich auf den mit der Sicherheitsanfälligkeit selbst verbundenen Faktoren beruht.
Bei dieser Methode wird untersucht, welche Art von Schaden auftreten kann, wenn die Sicherheitsanfälligkeit ausgenutzt wird. Dabei wird berücksichtigt, wie häufig die Komponente, Bibliothek oder das Projekt in der gesamten Softwareindustrie verwendet wird und auf welche Art von Zugriff ein Angreifer zugreifen kann Wrack Chaos sollten sie verwenden, um ihr Ziel zu durchbrechen. Faktoren wie die leichte potenzielle Ausnutzbarkeit können hier eine große Rolle bei der Beeinflussung des Scores spielen. (Weitere Informationen zur Sicherheit finden Sie unter Cybersicherheit: Wie neue Fortschritte neue Bedrohungen mit sich bringen - und umgekehrt.)
Wenn wir auf Makroebene schauen wollen, wird in der quantitativen Perspektive untersucht, wie eine Sicherheitsanfälligkeit die Herde schädigen kann. Dabei wird weniger auf den Schaden geachtet, der auf die Unternehmen fallen könnte, die tatsächlich von dem Angriff betroffen sind.
Die National Vulnerability Database (NVD), die wohl bekannteste Datenbank für Sicherheitslücken, verwendet diesen Ansatz für Version 2 und 3 des Common Vulnerability Scoring System (CVSS). Auf ihrer Seite, auf der ihre Metriken zur Bewertung von Schwachstellen erläutert werden, schreiben sie über ihre Methode:
Sein quantitatives Modell gewährleistet wiederholbare genaue Messungen, während die Benutzer die zugrunde liegenden Schwachstellenmerkmale sehen können, die zur Erstellung der Bewertungen verwendet wurden. Daher eignet sich CVSS gut als Standardmesssystem für Branchen, Organisationen und Regierungen, die genaue und konsistente Schwachstellenauswirkungswerte benötigen.
Basierend auf den quantitativen Faktoren kann der NVD dann einen Schweregrad-Score ermitteln, der sowohl eine Zahl auf der Skala von 1 bis 10 (wobei 10 die schwerwiegendste ist) als auch die Kategorien LOW, MEDIUM und HIGH enthält .
Keine Bugs, kein Stress - Ihre schrittweise Anleitung zur Erstellung lebensverändernder Software, ohne Ihr Leben zu zerstören
Sie können Ihre Programmierkenntnisse nicht verbessern, wenn sich niemand um die Softwarequalität kümmert.
Auswirkungen berücksichtigen?
Die NVD scheint sich jedoch zu bemühen, sich von dem fernzuhalten, was wir als qualitatives Maß für eine Sicherheitsanfälligkeit bezeichnen können, basierend darauf, wie effektiv ein bestimmter Exploit Schaden angerichtet hat. Um fair zu sein, beziehen sie die Auswirkungen insofern ein, als sie die Auswirkungen der Sicherheitsanfälligkeit auf das System unter Berücksichtigung der Faktoren Vertraulichkeit, Integrität und Verfügbarkeit messen. Dies sind alles wichtige Elemente, die zu betrachten sind - wie der leichter messbare Zugriffsvektor, die Zugriffskomplexität und die Authentifizierung -, aber sie sind nicht der Aufgabe gewachsen, die tatsächlichen Auswirkungen in Beziehung zu setzen, wenn eine Sicherheitsanfälligkeit einem Unternehmen echte Verluste verursacht.
Nehmen wir zum Beispiel die Equifax-Verletzung, bei der die personenbezogenen Daten von rund 145 Millionen Menschen offengelegt wurden, einschließlich der Angaben zum Führerschein, der Sozialversicherungsnummern und anderer Informationen, die von skrupellosen Personen für massive Betrugsfälle verwendet werden könnten.
Es war die Sicherheitsanfälligkeit (CVE-2017-5638), die in dem Apache Struts 2-Projekt entdeckt wurde, das Equifax in seiner Web-App verwendet hat, die es den Angreifern ermöglichte, in die Eingangstür zu gehen und es schließlich mit ihren Armen voller persönlicher Informationen herauszufinden .
Die NVD gab ihr zu Recht einen Schweregrad von 10 und HIGH. Ihre Entscheidung beruhte jedoch auf der quantitativen Einschätzung des potenziellen Schadens und war nicht von dem weitreichenden Schaden betroffen, der später eintrat, als der Equifax-Verstoß öffentlich wurde.
Dies ist kein Versehen der NVD, sondern ein Teil ihrer erklärten Politik.
Die NVD bietet CVSS-Basisbewertungen, die die angeborenen Merkmale jeder Sicherheitsanfälligkeit darstellen. Derzeit bieten wir keine "temporären Bewertungen" (Kennzahlen, die sich im Laufe der Zeit aufgrund von Ereignissen außerhalb der Sicherheitsanfälligkeit ändern) oder "Umgebungsbewertungen" (Bewertungen, die an die Auswirkungen der Sicherheitsanfälligkeit auf Ihr Unternehmen angepasst sind) an.
Für die Entscheidungsträger dürfte das quantitative Messsystem eine geringere Rolle spielen, da es die Chancen berücksichtigt, dass es den Schaden auf die gesamte Branche ausbreitet. Wenn Sie der CSO einer Bank sind, sollten Sie sich über die qualitativen Auswirkungen eines Exploits Gedanken machen, wenn er verwendet wird, um die Daten Ihres Kunden oder, noch schlimmer, dessen Geld zu verfälschen. (Weitere Informationen zu verschiedenen Arten von Sicherheitsanfälligkeiten finden Sie in Die 5 gruseligsten Bedrohungen in der Technik.)
Zeit, das System zu ändern?
Sollte die Sicherheitsanfälligkeit in Apache Strusts 2, die im Fall Equifax verwendet wurde, in Anbetracht des Ausmaßes des Schadens einen höheren Rang erhalten, oder würde sich die Verschiebung für ein System wie das NVD als viel zu subjektiv herausstellen weitermachen?
Wir geben zu, dass es außerordentlich schwierig wäre, die erforderlichen Daten für einen "Umwelt-Score" oder einen "Zeit-Score", wie er von der NVD beschrieben wird, zusammenzustellen, was die Manager des freien CVSS-Teams für endlose Kritik und jede Menge Arbeit öffnet für die NVD und andere für die Aktualisierung ihrer Datenbanken, wenn neue Informationen herauskommen.
Natürlich stellt sich die Frage, wie eine solche Bewertung erstellt werden soll, da nur sehr wenige Organisationen die erforderlichen Daten zu den Auswirkungen eines Verstoßes bereitstellen dürften, es sei denn, dies wäre durch ein Offenlegungsgesetz vorgeschrieben. Wir haben aus dem Fall von Uber gesehen, dass Unternehmen bereit sind, schnell zu zahlen, in der Hoffnung, dass die Informationen, die mit einem Verstoß verbunden sind, nicht in die Presse gelangen, damit sie nicht einer öffentlichen Gegenreaktion ausgesetzt sind.
Möglicherweise ist ein neues System erforderlich, das die guten Bemühungen der Schwachstellendatenbanken einbezieht und eine eigene zusätzliche Punktzahl hinzufügt, wenn Informationen verfügbar werden.
Warum diese zusätzliche Stufe der Wertung einführen, wenn die vorherige in all den Jahren offenbar ihre Arbeit gut genug gemacht hat?
Ehrlich gesagt liegt es in der Verantwortung von Organisationen, die Verantwortung für ihre Anwendungen zu übernehmen. In einer idealen Welt würde jeder die Bewertungen der Komponenten, die er in seinen Produkten verwendet, überprüfen, bevor er sie in sein Inventar aufnimmt, Warnungen erhalten, wenn neue Schwachstellen in Projekten entdeckt werden, die zuvor als sicher galten, und die erforderlichen Patches selbst implementieren .
Wenn es eine Liste gäbe, die zeigt, wie verheerend einige dieser Sicherheitslücken für ein Unternehmen sein können, könnten Unternehmen mehr Druck verspüren, sich nicht mit riskanten Komponenten einzufangen. Zumindest könnten sie Schritte unternehmen, um eine echte Bestandsaufnahme der bereits vorhandenen Open-Source-Bibliotheken vorzunehmen.
Nach dem Equifax-Fiasko kämpften wahrscheinlich mehr als eine Führungskraft der C-Ebene darum, sicherzustellen, dass sie nicht die gefährdete Version von Struts in ihren Produkten hatten. Es ist bedauerlich, dass es eines solchen Ereignisses bedurfte, um die Branche dazu zu bringen, ihre Open-Source-Sicherheit ernst zu nehmen.
Hoffentlich hat die Lektion, dass Schwachstellen in den Open-Source-Komponenten Ihrer Anwendungen sehr reale Konsequenzen haben können, Auswirkungen darauf, wie Entscheidungsträger Sicherheit priorisieren und die richtigen Tools auswählen, um die Sicherheit ihrer Produkte und Kundendaten zu gewährleisten.