Immer wieder lesen wir in den IT-Nachrichten etwas über gefundene Sicherheitslücken. Je schwerer die Einstufung dieser Lücke ist, desto mehr Aufmerksamkeit bekommen diese Informationen in der allgemeinen Presse. Über all die gefundenen Sicherheitslücken, die nicht den Bekanntheitsgrad von zum Beispiel dem SolarWinds Hack erlangen, hört und liest man meistens nichts. Aber wie ist die typische Lebenslinie einer solchen Sicherheitslücke? 

Beginnen wir mit der Geburt einer Sicherheitslücke. Das kann auf zwei unterschiedlich motivierte Arten geschehen. Zum einen kann es jedem Entwickler passieren, dass er durch eine unglückliche Kombination von Quelltextstücken eine Sicherheitslücke erzeugt. Zum anderen kann es auch auf einer gezielten Manipulation beruhen. Allerdings hat das im Wesentlichen keine Auswirkungen auf den weiteren Verlauf der Lebenslinie einer Sicherheitslücke. Wir gehen im nachfolgenden einfach davon aus, dass eine Sicherheitslücke erzeugt worden ist und diese sich nun aktiv in irgendeiner Software befindet. Dabei kann es sich um ausführbare Programme handeln oder auch um angebotene Bibliotheken die als Dependency in andere Softwareprojekte eingebunden wird.

Das Video zu diesem Artikel gibt es auf meinem Youtube-Kanal unter : https://youtu.be/j52nBLVJp1Y

Gefunden bis Public available

Es ist in den meisten Fällen nicht nachvollziehbar wann genau eine Sicherheitslücke erzeugt worden ist. Aber gehen wir einmal davon aus, dass es eine Sicherheitslücke gibt und dass diese gefunden wird. Hier kommt es eindeutig darauf an, welche Person oder welches Team diese Schwachstelle findet. Das hat gravierenden Einfluss auf den nachfolgenden Verlauf der Geschichte. Nehmen wir an, diese Sicherheitslücke ist von den Personen gefunden worden, die ein Interesse haben diese Schwachstelle entweder selbst zu verwenden oder durch andere Parteien ausnutzen zu lassen. Hier werden die Informationen entweder unter Verschluss gehalten oder an einschlägigen Plätzen im Internet zum Erwerb angeboten. Dabei bestehen meist finanzielle oder politische Motive, auf die ich hier nicht näher eingehen möchte. Allerdings ist an dieser Stelle ganz klar erkennbar, dass die Weitergabe der Informationen in Kanälen mündet, die nicht der Öffentlichkeit im Allgemeinen zur Verfügung stehen.

Wenn jedoch die Sicherheitslücke von Personen oder Gruppen gefunden wird, die das Interesse haben das Wissen darüber der Allgemeinheit zur Verfügung zu stellen, so greifen verschiedene Mechanismen. Allerdings darf man nicht vergessen, dass auch hier in den meisten Fällen kommerzielle Interessen mit im Spiel sein werden. Wobei die Motivation unterschiedlich gelagert ist. Handelt es sich um das Unternehmen oder das Projekt selbst, dass von dieser Schwachstelle betroffen ist, so besteht meistens ein Interesse daran die Information als eher harmlos darzustellen. Der befürchtete Schaden kann sogar dazu führen, dass die Sicherheitslücke behoben, die Kenntnis darüber aber weiter verborgen wird. Dieses Vorgehen ist als durchaus kritisch zu betrachten. Man muss davon ausgehen, dass es auch andere Gruppen oder Personen geben wird, die dieses Wissen erlangen werden.

Gehen wir aber einmal davon aus, dass die Informationen über die gefundene Sicherheitslücke von Personen gefunden worden ist, die nicht direkt in die betroffenen Komponenten involviert sind. Hier besteht in den meisten Fällen die Motivation, die Kenntnis der Schwachstelle zu verkaufen. Neben den betroffenen Projekten oder Produkten gibt es auch die Anbieter der Schwachstellendatenbanken. Diese Unternehmen haben ein direktes und offensichtliches Interesse daran, dieses Wissen zu erwerben. Aber an welches Unternehmen wird nun der Finder der Schwachstelle dieses Wissen verkaufen? Es ist anzunehmen, dass dies mit sehr hoher Wahrscheinlichkeit die Unternehmung sein wird, die den besseren Preis bezahlt. Das hat einen weiteren Nebeneffekt, welches Auswirkungen auf die Klassifizierung der Schwachstelle hat. Viele Schwachstellen werden mittels dem CVSS mit einer Bewertung versehen. Hierbei wird der Basiswert von unterschiedlichen Personen vorgenommen. Unterschiedliche Personen werden unterschiedliche persönliche Interessen haben, die sich dann auch in diesem Wert widerspiegeln werden.

Unabhängig über welche Umwege das Wissen zu den Vulnerabilities-Datenbanken kommt. Erst wenn die Information an einer dieser Stellen angelangt ist, kann man davon ausgehen, dass diese Erkenntnis über die Zeit hinweg der Allgemeinheit zur Verfügung stehen wird.

Wer mehr über CVSS wissen möchte,

kann gerne mein Youtube Video dazu ansehen:

https://bit.ly/CVSS-explained-DE  

Public available bis consumable

Allerdings ist ein Sachverhalt an dieser Stelle sehr deutlich zu erkennen. Egal für welchen Anbieter von Schwachstellen man sich auch entscheiden wird, es wird immer nur eine Untermenge aller bekannten Vulnerabilities in diesem Datensatz vorhanden sein. Als Endverbraucher kann man hier eigentlich nur einen sinnvollen Weg gehen. Anstelle sich direkt an die Anbieter zu wenden, sollte man auf Integratoren vertrauen. Gemeint sich hier Dienste, die selbst die unterschiedlichsten Quellen integrieren und diese dann aufbereitet und zusammengeführt anbieten. Diese Erkenntnisse müssen derart aufbereitet werden, dass die Weiterverarbeitung durch Maschinen möglich ist. Damit andere Programme mit diesen Informationen arbeiten können müssen die Metainformationen, wie zum Beispiel der CVE oder der CVSS Wert mitgeliefert werden. Der CVSS Wert wird zum Beispiel in CI Umgebungen dafür verwendet, um bei Erreichen eines bestimmten Schwellenwertes die Weiterverarbeitung zu unterbrechen. Erst wenn die Informationen in dieser Art vorliegen und dem Endverbraucher zur Verfügung stehen, kann man davon sprechen, dass diese Informationen konsumierbar sind. Da die Informationen im Allgemeinen einen beträchtlichen finanziellen Wert darstellen, werden die kommerziellen Anbieter solcher Datensätze schneller über aktualisierte Informationen verfügen als frei verfügbare Datensammlungen.

Consumable bis running in Production

Wenn nun die Information konsumierbar ist, also mit den in der Softwareentwicklung eingesetzten Werkzeugen verarbeitbar ist, beginnt der Handlungsstrang in den eigenen Projekten. Für welchen Anbieter man sich auch entschlossen hat, ab einem bestimmten Zeitpunkt steht einem diese Information zur Verfügung und man kann nun selbst darauf reagieren. Die Anforderung ist, dass die notwendigen Änderungen so schnell wie möglich in Produktion aktiviert werden. Nur dadurch kann man den möglichen Schaden, der durch diese Sicherheitslücke entstehen kann, vermeiden. Daraus ergeben sich verschiedene Anforderungen an die eigenen Softwareentwicklungsprozesse. Die offensichtlichste Anforderung ist an die Durchlaufzeiten gestellt. Nur wer einen hohen Automatisierungsgrad implementiert hat, kann bei den Auslieferungsabläufen kurze Reaktionszeiten ermöglichen. Ebenfalls ist es von Vorteil, wenn das betroffene Team, die dafür notwendigen Entscheidungen selbst und unkompliziert treffen kann. Langwierige Genehmigungsprozesse sind an dieser Stelle nicht nur ärgerlich, sondern können auch zu weitreichenden Schäden für das Unternehmen werden.

Ein Punkt der an dieser Stelle hohe Potentiale freisetzen kann, ist die Bereitstellung der sicherheitskritischen Informationen in allen beteiligten Produktionsstufen. Je früher die Informationen in der Produktion mitberücksichtigt werden, desto geringer sind die Kosten für die Entfernung von Sicherheitslücken. Eine weitere Frage, die sich stellt, ist die der effektiven Mechanismen gegen Vulnerabilities.

TestCoverage is your safety-belt; try Mutation Testing

Das beste Wissen um Sicherheitslücken nutzt nichts, wenn dieses Wissen nicht in Wert gesetzt werden kann. Aber welche Werkzeuge hat man in der Softwareentwicklung um effizient gegen bekannte Sicherheitslücken vorzugehen? Hier möchte ich eine Metrik ganz besonders hervorheben – die Testabdeckung der eigenen Quelltextteile. Mit einer starken Testabdeckung kann man Änderungen an dem System vornehmen und sich auf die Testsuite verlassen. Wenn ein reibungsloser Test aller betroffener Systemkomponenten stattgefunden hat, steht dem Weg zur Bereitstellung der Software aus technischer Sicht nichts entgegen.

Aber gehen wir einen Schritt zurück und betrachten die Situation genauer. In den meisten Fällen werden bekannte Sicherheitslücken durch die Änderung der eingesetzten Version derselben Abhängigkeit entfernt. Das bedeutet, dass ein effizientes Versionsmanagement einem die notwendige Agilität verleiht, um schnell reagieren zu können. Meistens müssen betroffene Komponenten durch semantische Äquivalente anderer Hersteller ersetzt werden. Und um die neue Komposition von Versionen derselben Komponenten als valide einzustufen, bedarf es einer starken Testabdeckung. Manuelle Tests würden den Zeitrahmen bei weitem sprengen und sind auch nicht mit derselben Qualität bei jedem Durchlauf durchführbar. Aber was ist eine starke Testabdeckung?

Ich selbst verwende die Technik des Mutation-Testing. Es ermöglicht eine wesentlich konkretere Testabdeckung als das mit herkömmlicher Line- oder Branch-Coverage meist der Fall ist. 

Wenn Du mehr über das Mutationstesting

erfahren möchtest besuche:

https://bit.ly/devsecops-mutation-testing 

In diesem Video werden der theoretische und der praktische

Teil des Mutationstests für Java und Kotlin erläutert.

The need for a single point that understands all repo-types

Wenn wir im Folgenden davon ausgehen, dass wir sowohl in der Entwicklung als auch im Betrieb der Software nach bekannten Sicherheitslücken suchen wollen, so benötigen wir eine Stelle, an der wir die Suchvorgänge durchführen können. Hier eignen sich verschiedene Stellen. Allerdings gibt es eine Anforderung, die erst einen effizienten Scan über alle eingesetzten Technologien ermöglicht. Die Rede ist von einer logischen zentralen Stelle, über die alle Binaries gehen müssen. Damit meine ich nicht nur die jar-Dateien die als Abhängigkeiten deklariert sind, sondern auch alle anderen Dateien, wie zum Beispiel die Debian-Pakete oder Docker-Images. Hierfür eignet sich Artifactory als zentraler Dreh- und Angelpunkt, da fast alle Paketmanager an einem Punkt unterstützt werden. Dadurch, dass man nicht nur die Kenntnis über die einzelnen Dateien hat, sondern auch im Besitz der Metadaten ist, können verschiedene Dinge mit ausgewertet werden.

Als Erstes ist es möglich nicht nur die direkten Abhängigkeiten zu erfassen. Durch die Kenntnis der Strukturen von den eingesetzten Paketmanagern sind auch alle indirekten Abhängigkeiten bekannt. Als Zweites ist es möglich, Technologie übergreifende Auswertungen zu erhalten. Gemeint ist hiermit der volle Impact Graph, um die effektive Bedeutung der einzelnen Vulnerabilities zu erfassen. Ein mögliches Werkszeug welches hier Überblick geben kann und direkt an JFrog Artifactory angebunden wird, ist JFrog Xray. Für welches Werkzeug man sich auch entscheidet, wichtig ist es, nicht nur einen Technologielayer zu scannen. Nur bei einem umfassenden Blick über den gesamten Tech-Stack kann gewährleistet werden, dass keine bekannten Sicherheitslücken direkt oder indirekt in Produktion enthalten sind. 

Fazit

Wir haben auf die meisten Abschnitte einer typischen Lebenslinie von IT-Sicherheitslücken kaum Einfluss. Eigentlich gibt es nur zwei Abschnitte, die wir direkt beeinflussen können. Zum einen ist es der möglichst schnelle und umfassende Zugriff auf zuverlässige Sicherheitsdatenbanken. Dabei sollte man sich nicht nur einem Anbieter anvertrauen, sondern sich auf Merger oder Aggregatoren konzentrieren. Durch den Einsatz solcher Supersets können die wirtschaftlich motivierten Unschärfen der einzelnen Anbieter kompensiert werden. Als Beispiel eines solchen Aggregators hatte ich JFrog Xray genannt. Der zweite Abschnitt einer typischen Lebenslinie ist im eigenen Haus. Sobald Kenntnisse über Sicherheitslücken vorliegen, muss selbständig gehandelt werden. Hierbei hilft eine starke Automatisierung und ein eingespieltes DevSecOps Team. Ein weiterer Artikel wird sich mit genau diesem Abschnitt aus der Perspektive Sicherheit auseinandersetzen.

Eine starke Testabdeckung ist einer der Schlüsselelemente im Kampf gegen Vulnerabilities und die Testmethodik Mutation-Testing gibt uns ein sehr effektives Mittel im Bereich des TDD an die Hand.

Wer einen solchen DevSecOps Ansatz ausprobieren möchte,

kann sich gerne zu einem meiner freien/kostenlosen Workshops in deutsch und englisch anmelden.

(https://jfrog.com/resources/upcoming-webinars/ ).

Dort werde ich anhand von JFrog Artifactory und JFrog Xray zeigen,

wie man praktisch gegen bekannte Vulnerabilities vorgehen kann.

 

Mehr zum Thema auf meinem Youtube-Kanal (https://www.youtube.com/svenruppert)

Happy Coding

Sven

 

Sven Ruppert


Sven Ruppert has been coding Java since 1996 in industrial projects, is working as Developer Advocate for JFrog and Groundbreaker Ambassador (former Oracle Developer Champion). He is regularly speaking at Conferences worldwide and contributes to IT periodicals, as well as tech portals. He was working over 15 years as a consultant worldwide in industries like Automotive, Space, Insurance, Banking, UN and WorldBank. Additional to his main topic DevSecOps he is working on Mutation Testing of Web apps and Distributed UnitTesting besides his evergreen topics Core Java and Kotlin.

Leave a Reply