Bei so vielen Sicherheits- und Entwicklerteams, die Post Mortems zum Fiasko der Sicherheitslücke Log4j durchführen, das sich Ende 2021, nur 10 Tage vor Weihnachten, abspielte, lautet die Hauptfrage:Wie können wir diese Art von Schmerz in Zukunft vermeiden? Die Antwort lautet leider … es ist kompliziert.
Sicherheitshinweise unbedingt lesen
Laut neuen Daten von (ISC)2, dem weltweit größten gemeinnützigen Verband zertifizierter Cybersicherheitsexperten, verzichteten fast die Hälfte (48 %) der Cybersicherheitsteams auf Urlaubszeit und Wochenenden, um bei der Behebung zu helfen, und 52 % der Teams verbrachten „Wochen oder mehr“. ” Wiederherstellung von Log4j. Nicht gerade, wie bereits gestresste Entwickler die Feiertage verbringen wollten.
Positiv ist jedoch, dass der Schmerz dieser Erfahrung bei Entwicklern und Sicherheitsteams zu einem umfassenden Umdenken in Bezug auf die Sicherheit der Softwarelieferkette geführt hat.
Schwachstellen beheben, ohne alten Code zu beschädigen
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 erste Veröffentlichung bis ins Jahr 2001 zurückreicht. Log4J berührt also nicht nur eine Menge Produktionssysteme, sondern auch viele Altlasten Code.
„Niemand möchte Legacy-Code anfassen“, sagte 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 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 Sie nicht hundertprozentig darauf vertrauen können, dass sich die Anwendung korrekt verhält, bis Sie sie tatsächlich ausführen und die Echtzeitverknüpfung zwischen Abhängigkeiten und testen Zusammenstellungen.
Laut Egorov hat Log4j das Interesse an der bereits beliebten Testcontainers-Plattform gesteigert, 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. Testcontainer werden 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 Sicherheitslücke Log4j und ihr schreckliches Timing während der Hauptferienzeit haben Entwicklerteams vor eine perverse Wahl gestellt:Stellen Sie Fixes jetzt bereit und riskieren Sie, Systeme während der Hauptfeiertags-E-Commerce-Zyklen herunterzufahren, oder verschieben Sie die Bereitstellung von Fixes in wirtschaftlich weniger riskante Intervalle ?
Es ist eine Entscheidung, die unmöglich zu treffen ist, wenn Sie nicht den richtigen Kontext haben.
„Log4j versetzte viele Ingenieurteams in Panik, 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.“
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 wurden und die Nobl9 in eine Plattform kommerzialisiert hat.
SLOs ermöglichen es Entwicklern, Betriebszeit und Erfolgsraten über Softwareinteraktionen hinweg zu modellieren und Schwellenwerte für Benutzerergebnisse zu definieren – sagen Sie zum Beispiel, wie viel Prozent der Einkaufswagen-Checkouts korrekt ausgeführt werden. Die Unternehmen, die SLOs modellieren, können, so Kurc, ein echtes Gespräch über das Risiko des Patchens im Vergleich zum Nicht-Patching führen.
Solche Lösungen kommen jedoch erst im Nachhinein bzw. 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 in einem viralen Beitrag schrieb, fallen viele dieser Open-Source-Betreuer „in eine von zwei Kategorien:Freiwillige oder Angestellte großer Unternehmen. Manchmal beides. Keines der Modelle ist gesund.“
Log4j beleuchtete die Tatsache, dass ein Großteil der modernen Software-Lieferkette auf Open-Source-Projekten mit einer Handvoll Betreuern oder sogar einem einzigen Betreuer basiert, der die Technologie oft als Nebenprojekt entwickelt hat. (Und seien wir klar:Aktuelle Daten deuten darauf hin, dass die überwiegende Mehrheit aller Open-Source-Software von weniger als 10 Personen geschrieben wird.)
„Moderne Anwendungen bestehen aus vielen Komponenten, von denen viele nicht intern entwickelt, sondern mithilfe von ‚Standard‘-Lösungen zusammengestellt werden“, 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 dieser Mangel an 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, bekamen wir mit Log4j einen großen.“
Google und andere Schwergewichte engagieren sich für diese Open-Source-Sicherheitslückenherausforderung, 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.
Quelllink