Die Konsequenz von Log4j – Was kann getan werden, um Unternehmen zu schützen?

Die Apache Log4j-Schwachstelle hat letztes Jahr für viel Chaos gesorgt, also was kann getan werden, um Unternehmen vor Sicherheitsauswirkungen zu schützen?

Tim Mackey, Chief Security Strategist am Synopsys Cybersecurity Research Center, sagt, dass es zwar verlockend sein kann, eine größere Schwachstelle als Hinweis auf Open Source in irgendeiner Weise zu betrachten, die Realität jedoch weit davon entfernt ist.

„Open-Source-Software ist nicht mehr oder weniger sicher als kommerzielle Software, und tatsächlich enthält die meiste kommerzielle Software Open-Source-Technologien oder läuft darauf“, sagte er.

„Open Source bedeutet einfach, dass die Software so entwickelt wird, dass der Quellcode jedem zur Verfügung steht, der ihn haben möchte.“

Mackey sagt: „Was wir in der Log4J-Antwort des Apache Log4J-Teams gesehen haben, war genau das, was wir von einem Team erwartet hatten, das die von ihnen erstellte Software ernst nimmt und auf die Bedürfnisse ihrer Installationsbasis reagiert.

„Wenn man bedenkt, dass es sich um Freiwillige handelt, zeigt eine solche Antwort den Stolz auf die Eigenverantwortung, den wir oft in Open-Source-Communities sehen“, sagte er.

„Tatsächlich wird ein Vorfall wie Log4J wahrscheinlich die Open-Source-Entwicklung insgesamt auf die gleiche Weise verbessern, wie Heartbleed die Entwicklungspraktiken offener und geschlossener Entwicklungsteams verbessert.“

Mackey sagte, das allgemeine Denkmuster sei, dass es einen kommerziellen Ersatz geben sollte, um Unternehmen vor den Auswirkungen auf die Sicherheit nach Log4j zu schützen, aber einer, der nicht verstehe, wie die Softwareentwicklung funktionieren wird.

„Jede Softwarekomponente hat eine bekannte Schnittstelle. Diese Schnittstelle kann in Form einer API vorliegen, wenn es sich um einen Webdienst handelt, oder sie kann Funktionen darstellen, die aufgerufen werden können, wenn die Komponente in eine Anwendung geladen wird“, sagte er.

„Wie die Schnittstelle aussieht, wie sie funktioniert, welche Arten von Daten benötigt werden und in welchem ​​Format, das sind alles Beispiele für Entscheidungen, die das Entwicklungsteam getroffen hat, das die Komponente erstellt hat, als sie die Komponente geschrieben haben.

„Diese Entscheidungen können sich auch ändern, wenn neue Funktionen implementiert werden oder der Code fortschreitet. Log4J hat eine Schnittstelle für jede seiner Hauptversionen, und sie sind nicht gleich“, sagte Mackey.

„Für einen kommerziellen Ersatz einer vorhandenen Komponente muss es einen verfügbaren Markt dafür geben. Im Fall von Log4J protokolliert die Komponente Nachrichtendaten in einer Protokolldatei. Daran ist nichts Reizvolles, und es gibt viele andere Möglichkeiten Logging-Daten als nur Log4J.“

Er sagt, das bedeutet, dass es auf dem kommerziellen Softwaremarkt nicht viel für einen Ersatz gibt.

„Nehmen wir jedoch an, dass jemand bereit ist, diese Investition zu tätigen, um einen kommerziellen Ersatz für Log4J zu haben. In diesem Fall muss er die vorhandene Log4J-Schnittstelle neu implementieren und dann einen vermeintlich sichereren Code aufschreiben“, so Mackey sagt.

„Das Konzept von Open Source auf eine Weise, die weniger sicher ist als kommerzielle Software, mag vor Jahrzehnten wahr gewesen sein, aber das ist heute alles andere als wahr, aber nehmen wir an, dass es unserem fiktiven Unternehmen gelungen ist, ein perfektes Protokollierungsdienstprogramm zu entwickeln, das Log4J getreu kopiert Schnittstelle.

„Sobald sie diesen Ersatz hergestellt haben, müssen sie ihn verkaufen und sicherstellen, dass keine Software mit Log4J beschädigt wird.“

Laut Mackey ist das Erkennen von Open-Source-Schwachstellen kein Problem, aber das Identifizieren von Softwarefehlern, die eine Schwachstelle darstellen, die ausgenutzt werden könnte, ist ein wichtiges Thema.

„Diese Diskrepanz ist signifikant, da Sicherheitslücken möglicherweise keine Codefehler darstellen, sondern Fehler in der Bereitstellungskonfiguration oder Hardwareänderungen“, sagte Mackey.

„Es ist wichtig zu beachten, dass Open-Source- und Closed-Source-Software das gleiche Potenzial für Sicherheitsprobleme haben, aber mit Open Source ist es jedem möglich, die Probleme zu identifizieren“, erklärte er.

Da es jedem möglich ist, die Probleme zu identifizieren, stellt sich laut Mackey die Frage, wie viele Menschen tatsächlich versucht haben, die Open-Source-Probleme zu identifizieren, und wie hart die Bemühungen waren.

„Ein Teil des Problems ist das Gefühl, dass es Verbraucher oder Benutzer von Open-Source-Projekten gibt, die sich so verhalten, als ob sie erwarten, dass das Open-Source-Projekt wie ein kommerzieller Softwareanbieter handelt“, sagte er.

„Wenn Sie sich die Liste der Probleme in einem einigermaßen populären Open-Source-Projekt auf GitHub ansehen, sehen Sie Feature-Anfragen und Kommentare dazu, wann bestimmte Probleme gelöst werden sollten. Die moderne Open-Source-Bewegung basiert auf dem Prinzip, dass, wenn Sie es nicht tun wie der Code funktioniert, dann steht es Ihnen frei, ihn zu modifizieren und alle Lücken in der Funktionalität zu schließen, von denen angenommen wird, dass sie bestehen, und dass sie zu einer Roadmap hinzugefügt und schließlich kostenlos veröffentlicht werden.

Mackey sagt, dass Lücken in der Funktionalität und sogar entdeckte Fehler in Wirklichkeit Gelegenheiten darstellen, nicht um kostenlose Programmierdienste zu bitten, sondern stattdessen zum zukünftigen Erfolg des Codes beizutragen, der wesentlich ist.

“Ja, einige Leute kennen vielleicht die im Projekt verwendete Programmiersprache nicht, aber zu erwarten, dass andere Leute einer Beschwerde von einem unbekannten Dritten über Änderungen Priorität einräumen. von Problemen für aktive Mitwirkende ist unrealistisch. Wie alles andere funktioniert Open Source durch den Altruismus der Beitragszahler”, sagte er.

„In den letzten Jahren haben wir gehört, dass Top-Beitragende für beliebte Open-Source-Projekte ihre Frustration über die Gewinne zum Ausdruck brachten, die große Unternehmen durch die Verwendung ihrer Software erzielen. Partei profitiert von den Bemühungen, Tatsache ist, dass, wenn die Drittpartei von den Bemühungen eines Open profitiert Source-Entwicklungsteam, dann sollten sie zum zukünftigen Erfolg beitragen.

„Wenn sie dies nicht tun, laufen sie nicht nur Gefahr, dass der fragliche Code auf eine Weise geändert wird, die sie nicht erwartet haben, sondern auch, dass sie, wenn Sicherheitsprobleme bekannt und behoben werden, Verzögerungen bei der Implementierung haben könnten.“ sagt Mackey.

Wenn ein Unternehmen nicht die Zeit hat, die Teams zu engagieren, die die Software entwickeln, die sein Geschäft vorantreibt, dann weiß es wahrscheinlich nicht, woher all die Software kommt, die sein Geschäft vorantreibt, und es ist nicht zuverlässig, sie zu patchen .