Technical Debt und Sicherheitsplanung – Technical Debt and Security Planning

Für IT-Sicherheitsteams ist es eine Selbstverständlichkeit, Software auf dem neuesten Stand zu halten – es sollte eine Selbstverständlichkeit sein, dass Software gepatcht wird, um potenzielle Probleme zu beseitigen. Dennoch stellt EoL-Software nach wie vor ein großes Risiko dar. Die US-Behörde Cybersecurity and Infrastructure Security Agency (CISA) schätzt, dass 48 Prozent aller Schwachstellen in ihrem KEV-Katalog (Known Exploited Vulnerabilities) in veralteter Software und veralteten Betriebssystemen zu finden sind.

Solche Probleme können weitreichende Folgen haben. Als das Apache Log4J-Problem zum ersten Mal entdeckt wurde, verwendeten mehr als 50 Prozent der Anwendungen, die diese Open-Source-Software-Komponente nutzten, eine veraltete Version, die EoS und damit anfällig für die Log4Shell-Schwachstelle war. Laut der Threat Research Unit von Qualys weisen etwa 20 Prozent der kritischen Assets – also der Geräte, Anwendungen und Server, die das Unternehmen antreiben und für den Umsatz verantwortlich sind – Probleme aufgrund von EoL-Software-Schwachstellen auf, deren Schweregrad als „hoch“ oder „kritisch“ eingestuft wird. Das ist kein kleines Problem.

Selbst Unternehmen, von denen man annehmen würde, dass sie sich der Risiken bewusst sind, können von EoL-Ressourcen betroffen sein. So hat die CISA beispielsweise Einzelheiten darüber veröffentlicht, wie eine US-Regierungsbehörde Ende 2023 durch eine kürzlich entdeckte Sicherheitslücke in Adobe ColdFusion angegriffen wurde. Obwohl die Schwachstelle erst kürzlich gemeldet wurde, betraf sie mehrere frühere Versionen von ColdFusion, einschließlich EoL-Versionen.

Wenn das Risiko bekannt ist, warum ist EoL-Software dann immer noch ein Problem? Wenn diese Probleme in einer von fünf geschäftskritischen Anwendungen auftreten, warum werden sie dann nicht sofort behoben? Wie können CISOs und Sicherheitsverantwortliche diese Schwachstellen verstehen und beheben, bevor sie zu Angriffen führen?

Technische Schulden verstehen

Das Problem der EoL-Software entsteht, weil die IT-Teams überlastet sind. Der Tag hat nicht genug Stunden, um alle Aktualisierungen, Änderungen und Ergänzungen, die vorgenommen werden müssen, zu bewältigen, so dass das Mantra, keine unnötigen Änderungen vorzunehmen, immer wieder wiederholt wird. Wenn eine Änderung zu erheblichen Ausfallzeiten führen und das Unternehmen Einnahmen kosten könnte, zögert das Management, diese Projekte zu unterstützen. IT-Führungskräfte können auch risikoscheu sein und zögern, Änderungsprojekte durchzuführen, die keinen zusätzlichen geschäftlichen Nutzen bringen, aber „karrierebedrohende Entscheidungen“ darstellen könnten, wenn etwas schief geht.

Diese Probleme verschärfen sich im Laufe der Zeit. Ein einzelnes Update mag für sich genommen keinen großen Arbeitsaufwand bedeuten, aber mehrere Updates und Patches, die über Monate oder sogar Jahre aufgeschoben werden, summieren sich und werden zu einer Belastung für das Team.

Diese Arbeit wird als „technische Schulden“ bezeichnet. Die Begleichung technischer Schulden kann schwierig sein, da sie einen hohen Aufwand für einen geringen geschäftlichen Nutzen darstellen. Diese traditionelle Denkweise in Bezug auf Aktualisierungen erschwert es den Sicherheitsteams, Unterstützung für ihre Arbeit zu erhalten.

Das bedeutet aber auch, dass viele Unternehmen bei der Betrachtung ihrer technischen Schulden und bei der Entscheidung, wo sie Upgrades durchführen, das Cyber-Risiko nicht berücksichtigen und alle Änderungen, die sie vornehmen, eine Reaktion auf bereits veröffentlichte Probleme sind. Dies bedeutet, dass alle beteiligten Teams reaktiv arbeiten und bereits im Rückstand sind. Diese veralteten Systeme können zum ungünstigsten Zeitpunkt ausfallen, was zu höheren Kosten für die Problembehebung führt.

Um dieses Problem zu lösen, müssen IT- und Sicherheitsteams proaktiv mehr Einblick in Cyber-Risiken und technische Schulden geben. Gleichzeitig darf es sich dabei nicht um einen Ansatz handeln, bei dem mit dem Finger gewedelt und einfach darauf hingewiesen wird, wo etwas schief läuft. Stattdessen muss die IT-Sicherheit einen kollaborativen Ansatz verfolgen und mit den Infrastruktur- und Softwareentwicklungsteams zusammenarbeiten, um Probleme zu lösen, bevor sie größere Auswirkungen haben können.

Cybersicherheitsteams verfügen bereits über einen Großteil der Daten, die für ein besseres Management der technischen Risiken in Unternehmen erforderlich sind, benötigen jedoch Unterstützung bei der Nutzung dieser Daten. Die Nutzung vorhandener Daten über die kritische Bedeutung von Assets, potenzielle Schwachstellen und Risikofaktoren im Zusammenhang mit der Ausbeutung bringt Sie so weit, aber das Hinzufügen von Cyber-Risikodaten speziell für EoL-Software kann aufzeigen, wo diese Risiken bestehen und wie kritisch die Assets sind.

Dies kann dann in Form von Geschäftsrisiken ausgedrückt werden, so dass die Managementteams die Auswirkungen erkennen können, wenn keine Änderungen vorgenommen werden.

In der Praxis bedeutet dies eine effektive Kommunikation, indem Risiko- und Geschäftsauswirkungsdaten mit mehreren Teams geteilt werden und diese Daten für die Planung von EoL-Terminen sechs bis zwölf Monate im Voraus verwendet werden. Wenn bestehende kritische Assets ein hohes Risiko in Bezug auf Tech Debt aufweisen, können diese Geschäftsrisikodaten ein Eurozeichen neben dieses Risiko setzen und klare Informationen darüber liefern, warum es priorisiert werden sollte. Im Hintergrund sollten diese Daten mit anderen Systemen synchronisiert werden, die Unternehmen für ihre Assets haben, wie z.B. Konfigurationsmanagement-Datenbanken (CMDBs), so dass alle Beteiligten den gleichen proaktiven Überblick über Inventar, Risiko und Planung haben.

Diese Informationen können genutzt werden, um Prioritäten für die Behebung von Problemen zu setzen und Risiken zu verringern. Mit der Zeit können IT-Manager einen proaktiveren Ansatz verfolgen und technische Schulden abbauen, um das Risiko ungepatchter und veralteter Technologie zu minimieren. Anstatt auf Ausfälle zu warten, können CISOs im Voraus planen und nachweisen, warum diese Änderungen aufgrund der Geschäftsanforderungen erforderlich sind.

For IT security teams, keeping software up to date is a given – it should be a given that software will be patched to address potential issues. However, EoL software still poses a significant risk. The US Cybersecurity and Infrastructure Security Agency (CISA) estimates that 48 per cent of all vulnerabilities in its Known Exploited Vulnerabilities (KEV) catalogue are found in out-of-date software and operating systems.

Such problems can have far-reaching consequences. When the Apache Log4J problem was first discovered, more than 50 percent of applications using this open source software component were using an outdated version that was EoS and therefore vulnerable to the Log4Shell vulnerability. According to Qualys‘ Threat Research Unit, approximately 20 per cent of critical assets – the devices, applications and servers that run the business and are responsible for revenue – are experiencing problems due to EoL software vulnerabilities rated as ‚high‘ or ‚critical‘ in severity. This is no small problem.

Even organizations that would be expected to be aware of the risks can be affected by EoL assets. For example, CISA has published details of how a US government agency was attacked in late 2023 using a recently discovered vulnerability in Adobe ColdFusion. Although the vulnerability was only recently reported, it affected several earlier versions of ColdFusion, including EoL versions.

If the risk is known, why is EoL software still a problem? If one in five business-critical applications has these problems, why aren’t they fixed immediately? How can CISOs and security leaders understand and fix these vulnerabilities before they lead to attacks?

Understanding Technical Debt

The EoL software problem arises because IT teams are overworked. There aren’t enough hours in the day to handle all the updates, changes and additions that need to be made, so the mantra of not making unnecessary changes is repeated over and over again. If a change could cause significant downtime and cost the business revenue, management is reluctant to support these projects. IT leaders can also be risk-averse and reluctant to take on change projects that don’t add business value but could be „career-threatening decisions“ if something goes wrong.

These issues compound over time. A single update may not be a huge amount of work in itself, but multiple updates and patches over months or even years add up and become a burden on the team.

This work is called „technical debt“. Technical debt can be difficult to pay off because it represents a lot of effort for little business benefit. This traditional way of thinking about updates makes it difficult for security teams to get support for their work.

But it also means that many organizations don’t consider cyber risk when looking at their technical debt and deciding where to update, and any changes they do make are in response to problems that have already been made public. This means that all the teams involved are working reactively and are already behind the curve. These outdated systems can fail at the worst possible time, resulting in higher costs to fix the problem.

To solve this problem, IT and security teams must proactively provide greater visibility into cyber risks and technical debt. At the same time, this cannot be a finger-wagging approach that simply points out where things are going wrong. Instead, IT security must take a collaborative approach, working with infrastructure and software development teams to resolve issues before they can have a major impact.

Cybersecurity teams already have much of the data they need to better manage technical risk in their organizations, but they need help using it. Leveraging existing data on asset criticality, potential vulnerabilities and exploitation risk factors will get you so far, but adding cyber risk data specific to EoL software can highlight where these risks exist and how critical assets are.

This can then be expressed in terms of business risk so that management teams can see the impact if changes are not made.

In practice, this means communicating effectively by sharing risk and business impact data across multiple teams and using this data to plan EoL dates six to twelve months in advance. If existing critical assets have a high risk of technical debt, this business risk data can put a euro sign next to that risk and provide clear information on why it should be prioritized. Behind the scenes, this data should be synchronized with other systems that companies have for their assets, such as configuration management databases (CMDBs), so that all stakeholders have the same proactive view of inventory, risk and planning.

This information can be used to prioritize remediation and mitigate risk. Over time, IT managers can take a more proactive approach and reduce technical debt to minimize the risk of unpatched and outdated technology. Instead of waiting for outages to occur, CISOs can plan ahead and demonstrate why these changes are necessary based on business needs.