Für den Umgang mit Schwachstellen gibt es einige allgemeine Grundsätze, die als Orientierungshilfe für das Sicherheitsdenken und die Entscheidungsfindung dienen können.
Zunächst einmal ist es immer wichtig zu verstehen, was wir schützen wollen, da dies Auswirkungen auf die zu ergreifenden Maßnahmen hat. Handelt es sich bei unserem Artefakt beispielsweise um einen Webserver, dann müssen wir ihn vor nicht vertrauenswürdigen Benutzern schützen. Handelt es sich bei unserem Artefakt um eine Verschlüsselungssoftware, dann müssen wir sie natürlich auch vor Benutzern schützen, die physischen Zugang zum System haben. In jedem Fall sind die Risikogrenzen klar erkennbar und wir müssen uns darauf konzentrieren.
Zweitens ist die Konfiguration Teil der Codebasis. Wenn ein böswilliger Akteur Zugriff auf Ihre Konfiguration hat, dann ist das im Grunde dasselbe, als wenn dieser böswillige Akteur Zugriff auf Ihre Codebasis hätte.
Angesichts der Flut an verwundbaren Systemen, die durch die jüngste Sicherheitslücke in Log4j 2.x (Log4Shell) ausgelöst wurde, suchen wir als Sicherheitsorganisation vielleicht verstärkt nach anderen potenziellen Sicherheitslücken. Vielleicht sollten wir diese Gelegenheit aber auch nutzen, um innezuhalten und nachzudenken, bevor wir vorschnell über jedes potenzielle Sicherheitsproblem urteilen, das wir in unserem Code finden. Ein kühlerer Kopf könnte auch zu dem Schluss kommen, dass nicht alles, was zu einem Sicherheitsproblem führt, zwangsläufig als gleich eingestuft wird.
Als Beispiel können wir die jüngste Verbreitung von CVE-2021-4104 gegen Log4j 1.x durch diese Linse betrachten. Um dies auszunutzen, ist ein direkter Zugriff auf die Konfigurationsdatei erforderlich, um die Einstellungen zu manipulieren. Ähnliche Themen tauchen jetzt rund um das Logback-Projekt auf, ebenso wie Beispiele in der Node-Community.
Um es klar zu sagen: Das Aufdecken potenzieller Schwachstellen ist immer noch eine gute Sache. Aber inmitten der Medienpanik ist es auch angebracht, unser eigenes kritisches Denken zu überprüfen und eine Grundlinie der Gemeinschaft festzulegen, auf die wir uns konzentrieren sollten. Ein weiterer Tsunami potenzieller Schwachstellen könnte mehr schaden als nützen, die ohnehin schon überlasteten Sicherheitsteams weiter überfordern und die laufenden Bemühungen der Branche zum Schutz von Open-Source-Software unterbrechen.
Kritisches Denken CVE
Die in dem oben genannten Thread geführte Diskussion wirft einige sehr interessante Fragen auf.
Wenn eine Sicherheitslücke beispielsweise nur durch privilegierten Zugriff auf die internen Dateien eines Systems ausgenutzt werden kann, handelt es sich dann wirklich um eine Sicherheitslücke? Fast jedes wichtige Stück moderner Software kann so konfiguriert werden, dass es unsichere Operationen erlaubt. In ähnlicher Weise ist es durchaus möglich, dass sshd so konfiguriert wurde, dass es Anmeldungen mit leeren Passwörtern zulässt. Sollten wir dies als eine neue Schwachstelle von sshd betrachten?
Einer der Mechanismen, die unser Sicherheitsteam einsetzt, ist die Abwägung zwischen erwartetem und unerwartetem Verhalten. Wenn eine Software so konfiguriert werden kann, dass sie ferngesteuerten Code ausführt, und diese Funktionalität gut dokumentiert ist, handelt es sich dann um ein Verhalten, das eine Schwachstelle darstellt, die ausgenutzt werden kann? Es könnte als erwartetes Verhalten und nicht als Sicherheitslücke an sich betrachtet werden.
Sollten wir Software so gestalten, dass es keine unsicheren konfigurierbaren Muster gibt? Dies kann als lobenswertes Ziel angesehen werden, steht aber im Widerspruch zu der Art und Weise, wie wir Open-Source-Software in den letzten 30 Jahren oder mehr entwickelt haben. Das typische Designziel für Open-Source-Software ist es, ein Höchstmaß an Konfigurierbarkeit zu erreichen, um alle Anwendungsfälle zu berücksichtigen. In den letzten Jahren sind einigermaßen sichere Standardeinstellungen zu einem zweitrangigen Ziel geworden, aber das Prinzip war immer, den Benutzern die Möglichkeit zu geben, die Software so zu konfigurieren, wie sie es für richtig halten, sicher oder unsicher.
Außerdem leben wir derzeit in einer Welt, in der CVEs sowohl von Einzelpersonen und Unternehmen leicht zu mobilisieren als auch aufgrund ihrer Glaubwürdigkeit und ihres Caches wertvoll sind. Diese einzigartige Kombination kann zu einer problematischen Verbreitung führen. Andererseits kann die Möglichkeit, potenzielle Sicherheitsprobleme reibungslos zu melden, nur positiv sein, so dass wir mit einigen Paradoxien konfrontiert sind.
Als Industrie werden wir immer besser darin, Schwachstellen zu erkennen, während wir gleichzeitig immer mehr Software entwickeln, so dass das Potenzial für eine Überlastung leicht zu erkennen ist.
Die korrekte Identifizierung von Schwachstellen in Software, deren Bewertung und die Bereitstellung von Abhilfemaßnahmen ist ein sehr ressourcenintensiver und weitgehend manueller Prozess, insbesondere bei komplexen Situationen. Obwohl die Methoden des maschinellen Lernens immer nützlicher werden und KI sich als noch wertvoller erweisen könnte, sind Computer in vielen Fällen (ironischerweise) bei der Diagnose nicht so nützlich für uns.
vorausschauend
Die hier dargelegten Diskussionspunkte zielen nicht darauf ab, ein bestimmtes CVE zu ändern, sondern vielmehr darauf, einen Dialog über die Zukunft der Schwachstellenbewertung zu eröffnen und darüber, was wir jetzt und in Zukunft als unsicher ansehen. Die Entwicklung robuster und generischer Open-Source-Software für gängige Anwendungsfälle führt zwangsläufig zu konfigurierbaren Mustern, die mehr oder weniger Sicherheit bieten. Wenn wir so weitermachen wollen, liegt es auch in der Verantwortung des Benutzers, die Fallstricke bei der Nutzung zu verstehen. Vielleicht liegt die Antwort in einer besseren Dokumentation und Ausbildung sowie in der Kategorisierung potenzieller Schwachstellen in normalen Anwendungsfällen.
Referenz: https://snyk.io/blog/when-is-a-cve-not-a-cve/
Originalartikel von CNCSO, bei Vervielfältigung bitte die Quelle angeben: https://cncso.com/de/sicherheit-von-context-html
