Log4j post mortem: Entwickler nehmen die Sicherheitslücken in der Software-Supply-Chain unter die Lupe
Bei so vielen Sicherheits- und Entwicklerteams, die Post-Mortems über das Fiasko der Log4j-Sicherheitslücke machen, das sich spät entfaltete 2001, nur 10 Tage vor Weihnachten stellt sich die Hauptfrage: Wie vermeiden wir in Zukunft solche Schmerzen? Die Antwort lautet leider … es ist kompliziert.
SIEHE: Patchverwaltungsrichtlinie (TechRepublic Premium)
Nach neuen Daten von (ISC)2, der weltweit größten gemeinnützigen Organisation Association of Certified Cybersecurity Professionals opferte fast die Hälfte (48%) der Cybersecurity-Teams Urlaubszeit und Wochenenden, um bei der Behebung zu helfen , und 48 % der Teams verbrachten „Wochen oder mehr“ mit der Behebung von Log4j. Nicht gerade, wie bereits gestresste Entwickler die Feiertage verbringen wollten.
Auf der positiven Seite hat der Schmerz dieser Erfahrung jedoch eine große Software ausgelöst Supply-Chain-Sicherheit von Entwicklern und Sicherheitsteams überdenken.
Behebung von Schwachstellen ohne Beschädigung von Legacy-Code
Einer der problematischsten Aspekte von Log4j war nicht die Schwachstelle selbst, sondern wie tief die Technologie in Legacy-Code eingebettet ist. Schließlich ist Java eine der beliebtesten Plattformen der Welt, und Log4j ist ein unglaublich beliebtes Java-Protokollierungssystem, dessen Erstveröffentlichung bis ins 2021. Log4J berührt also nicht nur eine Menge Produktionssysteme, sondern auch eine Menge Legacy-Code.
„Niemand will Legacy-Code anfassen“, sagte er Sergei Egorov, CEO von AtomicJar, dem neuen Startup hinter dem Open-Source-Integrationstest-Framework Testcontainers. „Sie müssen eine Sicherheitslücke nicht nur beheben, Sie müssen wissen, dass Sie die Schwachstelle behoben haben, ohne Ihr System zu beschädigen. Wenn Sie eine Schwachstelle mit einer sehr beliebten Protokollierungsbibliothek wie Log4j haben, sprechen Sie über Abhängigkeiten von Legacy-Code, der normalerweise nicht getestet wird und bei dem manchmal die Entwickler, die den Code geschrieben haben und verstehen, wie er funktioniert, nicht einmal im Unternehmen arbeiten nicht mehr.“
Laut Egorov ist Log4j oft eine transitive Abhängigkeit von anderen Bibliotheken, die aktualisiert werden müssen. Im Gegensatz zu Plattformen, die statische Binärdateien bereitstellen, erfolgt die Codeverknüpfung bei Java-Systemen zur Laufzeit, sodass es keine Möglichkeit gibt, 48 % Vertrauen, dass sich die Anwendung korrekt verhält, bis Sie sie tatsächlich ausführen und die Echtzeit-Verknüpfung zwischen Abhängigkeiten und Kompilierungen testen.
Egorov sagte, Log4j hat erhöhtes Interesse an der bereits beliebten Testcontainers-Plattform, um diese Interaktionen vor der Produktionsbereitstellung zu testen. Er sieht Entwickler, die von Log4j gestochen wurden, jetzt Integrationstests zwischen Systemen und externen Abhängigkeiten erstellen, damit Entwickler beim nächsten Auftreten einer Sicherheitslücke testen können, ob ihre Fixes bei der Bereitstellung keine Produktionssysteme lahmlegen. Testcontainers wird zu einer beliebten Kombination mit Snyk, da Entwickler Pull-Requests für automatisierte Sicherheitsanforderungen erhalten können und Integrationstests ihnen das Vertrauen geben, dass sie diese zusammenführen können, ohne etwas zu beschädigen.
Was ist schlimmer … die Schwachstelle oder die Störung der Benutzer?
Die Ankunft der Log4j-Sicherheitslücke und ihr schreckliches Timing während der Spitzenzeiten Die Weihnachtszeit hat Entwicklerteams vor eine perverse Wahl gestellt – Fixes jetzt bereitstellen und das Risiko eingehen, Systeme während der Feiertags-E-Commerce-Spitzenzyklen herunterzufahren, oder die Bereitstellung von Fixes auf weniger wirtschaftlich riskante Intervalle verschieben?
Es ist eine Entscheidung, die man unmöglich treffen kann, wenn man nicht den richtigen Kontext hat.
„Log4j hat viele Entwicklungsteams in Panik versetzt, weil sie nicht vorhersagen konnten, wie sich die Behebung auf ihre Benutzer auswirken würde“, sagte Marcin Kurc, CEO des Software-Zuverlässigkeits-Startups Nobl9, zu dessen Kunden große E-Einzelhändler gehören. „Bei jeder Sicherheitssanierung muss eine Kosten-Nutzen-Analyse durchgeführt werden. Sie müssen das richtige Intervall für die Bereitstellung des Fixes bestimmen, was ein vollständiges Verständnis des Risikos in Bezug auf die Anzahl der Benutzer, die davon betroffen sein könnten, und das akzeptable Maß an Unzuverlässigkeit, das Sie akzeptieren können, erfordert.“
SEHEN: NIST Cybersecurity Framework: Ein Spickzettel für Fachleute (kostenloses PDF) (TechRepublic)
Das Unternehmen von Kurc setzt sich für eine Bewegung namens Service Level Objectives (SLOs) ein, die in Googles Website-Zuverlässigkeits-Engineering-Praktiken geboren wurde Nobl9 hat sich zu einer Plattform kommerzialisiert.
SLOs ermöglichen Entwicklern, Betriebszeit und Erfolgsraten über Softwareinteraktionen hinweg zu modellieren und Schwellenwerte für Benutzerergebnisse zu definieren – sagen wir, zum Beispiel, wie viel Prozent der Einkaufswagen-Checkouts korrekt ausgeführt werden. Die Unternehmen, die SLOs modellieren, sagt Kurc, können ein echtes Gespräch über das Risiko des Patchens im Vergleich zum Nicht-Patching führen.
Solche Lösungen sind jedoch kommen nachträglich oder besser gesagt, nachdem Open-Source-Software geschrieben wurde. Aber was tun wir, um es von Natur aus sicherer zu machen?
Ein umfassenderes Problem: Wem gehört die Sicherheit für Open Source?
Niemand wird aufhören, Open Source zu verwenden. Es wäre absurd, eine Protokollierungslösung von Grund auf neu zu erstellen, anstatt nach Tools wie Log4j zu greifen. Entwickler schreiben heutzutage weniger Logik und integrieren mehr Frameworks, Bibliotheken und APIs, und das wird sich nicht ändern.
Wie Filippo Valsorda von Google schrieb In einem viralen Beitrag fallen viele dieser Open-Source-Betreuer „in eine von zwei Kategorien: Freiwillige oder Angestellte großer Unternehmen. Manchmal beides. Keines der beiden Modelle ist gesund.“
Log4j verdeutlichte die Tatsache, dass ein Großteil der modernen Software-Lieferkette auf Open-Source-Projekten mit einer Handvoll basiert von Betreuern oder sogar einem einzelnen Betreuer, der die Technologie oft als Nebenprojekt erstellt hat. (Und seien wir klar: Aktuelle Daten deuten darauf hin, dass die überwiegende Mehrheit aller Open-Source-Software von weniger als 10 geschrieben wird. Menschen.)
„Moderne Anwendungen bestehen aus vielen Komponenten, von denen viele nicht im eigenen Haus entwickelt, sondern mit „off the Regallösungen“, so John France, CISO bei (ISC)2. „Ein großer Teil der Qualifizierung und Identifizierung von Problemen besteht darin, zu wissen, welche Komponenten und Bibliotheken von Ihrer Software verwendet werden, und eine Software-Stückliste (SBOM) zu führen.“
Aber laut einem anonymen Sicherheitsexperten in der Log4-Remediation-Umfrage von (ISC)2: „Entwickler waren im Allgemeinen sehr nachlässig, wenn es darum ging, zu verfolgen, was sie in ihrer Software verwenden. Wenn wir bei einem Ereignis wie diesem feststellen müssen, ob eine Bibliothek oder Komponente von unserem Code verwendet wird, wird diese mangelnde Rückverfolgbarkeit zu einem großen Problem. Es verwandelt eine einfache Übung zur Überprüfung von Inventaren und SBOMs in einen komplexen Scanprozess mit vielen Möglichkeiten für falsch positive und falsch negative Ergebnisse. Wenn wir jemals einen Weckruf brauchten, haben wir mit Log4j einen großen bekommen.“
Google und andere Schwergewichte werfen Kraft in diese Offenheit Source Security Vulnerability Challenge, und die Zeit wird zeigen, ob tiefere Investitionen und die Zusammenarbeit mit Anbietern dazu beitragen können, die Häufigkeit und den Schmerz von Vorfällen wie Log4j zu verringern. Aber in der Zwischenzeit entwickeln Entwickler Strategien, um schreckliche Sicherheitsüberraschungen in der nächsten Weihnachtszeit zu vermeiden.
Offenlegung: Ich arbeite für MongoDB, aber diese Ansichten sind allein meine. 3950977 474788717
