Unser Gast - Niklas Ott
Mein Name ist Niklas Ott und ich bin aktuell Linux System Engineer im Team Incident Management bei der SysEleven GmbH. Dort kümmere ich mich um den sicheren und robusten Betrieb von unterschiedlichsten Software-Stacks, wobei Software-Sicherheitslücken regelmäßig ein großes Thema sind. Vorher war ich in den Bereichen IT-Security und Softwareentwicklung tätig, in meinem Studium habe ich mich ebenfalls auf die IT-Sicherheit spezialisiert. Dabei konnte ich das Thema Software-Lifecycle-Managementent aus unterschiedlichen Perspektiven betrachten und versuche daher möglichst Alle einzubringen, um den gesamten Software-Stack ein wenig sicherer zu machen und die Arbeit für Alle zu erleichtern.
Was ist eigentlich Lifecycle-Management und warum ist dies für den soliden Betrieb einer Software so wichtig?
Unter Lifecycle versteht man in der IT die gesamte Lebensdauer eines Systems, von Ressourcen bis hin zu Workloads. Das Lifecycle Management begleitet diese von der Planung bis hin zur Stilllegung. Mit dem Fokus auf Systeme und Software betrachten wir dabei hauptsächlich die (meist automatisierte) Erstellung und Provisionierung, den ordnungsgemäßen Betrieb, sowie die Überwachung/Monitoring
und auch die Dekommissionierung, wenn das System nicht mehr benötigt wird. Das ist besonders wichtig, da sonst oftmals System-Leichen entstehen, die „irgendjemand irgendwann mal eingerichtet hat“ und niemand den gewollten Zustand kennt oder in der Lage ist, das System zu betreiben. In Bezug auf die Sicherheit eines Systems reden wir hier hauptsächlich vom Betrieb, der auch regelmäßige Updates umfasst.
Warum wird das Thema Lifecycle-Management oft unterschätzt?
Meistens wird beim Lifecycle-Management nur der eigene Teil eines Systems betrachtet. Dabei werden jedoch viele Dinge außer Acht gelassen. Beispielsweise bestehen (fast) alle Systeme aus Komponenten mehrerer Hersteller, beispielsweise eingebundenen Software-Bibliotheken, so wie bei Log4j. Das Problem an der Sache: diese Bibliotheken können wiederum andere Bibliotheken einbinden und so weiter, so dass moderne Software teilweise direkt oder indirekt von mehreren hundert oder tausend Bibliotheken abhängig ist. Das zu überblicken ist schon sehr komplex, wenn man das von Anfang an beachtet. Das im Nachhinein zu erarbeiten, wenn es schon “brennt”, macht es die Dinge nicht einfacher.
Worauf kommt es an, sich im Lifecycle-Management gut aufzustellen?
Klare Verantwortlichkeiten aufstellen (wer ist für welche Software zuständig) und eine gute Übersicht über eingesetzte Software und Abhängigkeiten sind hierfür sehr wichtig. In einer optimalen Welt kann man einfach in einer Tabelle nachschauen, wo beispielsweise Log4j in welcher Version eingesetzt wird. Das ist natürlich weit entfernt von der Realität, da die IT-Landschaft meist viel zu komplex ist, um sogar Bibliotheken zu tracken. Eine Übersicht über die eingesetzte Software und die verantwortlichen Personen ist jedoch immer ein guter Anfang und eine gute Ausgangsbasis, um den Lifecycle zu verbessern.
Wie kann man Probleme wie bei der Log4j-Lücke verhindern bzw. wie geht man effektiv damit um?
Grundsätzlich lässt sich sagen, dass ein vernünftiges Lifecycle-Management mit regelmäßigen Updates (auch von eingebundenen Bibliotheken) zu einer sicheren Software führt, da Sicherheitslücken meist schnell geschlossen werden können und Patches verfügbar sind. Im Falle von Log4j war das leider etwas anders. Dabei handelte es sich um eine sogenannte Zero-Day-Lücke, also eine Sicherheitslücke, die bis zu ihrer Veröffentlichung nicht bekannt war. Grundsätzlich haben sowohl Software-Hersteller als auch Sicherheitsforscher Interesse an sogenanntem „responsible Disclosure“. Dabei wird zuerst der Softwarehersteller informiert, um die Sicherheitslücke zu beheben und anschließend wird die Lücke inklusive Patch veröffentlicht. Das war bei Log4j leider nicht gegeben, so dass der Angriff global ausgenutzt werden konnte, bevor ein Patch zur Verfügung stand.
Wie schafft man es, dass das Thema Lifecycle-Management präsent ist und man sich hier vorausschauend gut aufstellt?
Die Probleme von keinem bzw. schlechtem Lifecycle-Management werden immer wieder aufgezeigt, sobald es ein kritisches Problem gibt, das schnell behoben werden muss – zum Beispiel Software, die plötzlich nicht mehr funktioniert oder eben eine Sicherheitslücke. Diese Risiken müssen allen Beteiligten bewusst sein und präsent gehalten werden.
