“We build our computers the way we build our cities — over time, without a plan, on top of ruins.”

― Ellen Ullman

Das ist einer meiner Lieblingssprüche, wenn es um die Beschreibung des allgemeinen Sicherheitsniveaus unser aller IT-Systeme geht. Umso mehr trifft dieser Spruch auf das Apache Log4j Desaster zu, womit sich aktuell die halbe Welt beschäftigt und Admins panisch alles stehen und liegen lassen, um Systeme zu patchen. Nun ist es so, dass man für sich klar haben sollte, dass solche Schreckensszenarien in der Zukunft immer wieder und vor allem häufiger auftreten werden. Dies liegt hauptsächlich an der steigenden Komplexität von IT-Systemen und der Art und Weise, wie heutzutage Software entwickelt und Infrastrukturen gebaut werden, und zwar: over time, without a plan, on top of ruins.

Wenn wir uns „State of the Art“-Softwareprojekte anschauen, werden wir feststellen, dass dort mit Abhängigkeiten zu Third-Party Libraries nicht gekleckert wird. Ganz besonders schlimm ist dies bei Webapplikationen, da zieht man sich ganz schnell mal eine mittlere zweistellige Zahl an Dependencies in die Codebase, die von irgendwelchen Menschen mal entwickelt wurden und mehr oder weniger gepflegt sind. Da diese Third-Party Libraries meist Hobby bzw. semiprofessionelle Ansätze verfolgen, kann man als Nutzer nicht erwarten, dass der Informatiker, der nebenbei nach der Arbeit mal einen NodeJS Parser für Excel-Dateien gehackt hat, regelmäßig das Projekt und seinen Code pflegt, den Bugtracker im Blick hat und Pull Requests sichtet.

Wir sehen z.Zt. etliche Hersteller, die ihre komplexen Softwareprodukte auf Anfälligkeiten bzgl. der Log4j Schwachstelle prüfen. Alleine die Tatsache, dass man seine Codebase erst prüfen muss, um dann später festzustellen, ob die Library überhaupt im Einsatz ist oder in welcher Version diese mitgeliefert wird, sagt einiges über die Qualitätsprozesse der Hersteller aus.

Während Penetrationstests stellen wir diese Problematik leider regelmäßig fest, oft heißt es im Reporting: „Remote Code Execution durch veraltete und verwundbare Library X“ oder „Cross-Site Scripting durch veraltete und verwundbare Library Y“.

Was lernen wir nun daraus?

Schwachstellen entstehen nun mal, wenn Menschen Software entwickeln, das ist unvermeidlich und auch Ok. Wir benötigen aber allerdings für unsere IT-Systeme viel weniger Komplexität und mehr Klarheit darüber, wie diese tatsächlich funktionieren, dadurch ergibt sich einfacheres und schnelleres handeln, wenn es wirklich darauf ankommt.

Ein Kommentar von Jens Regel.