In an article in the German speaking c’t Magazin, lazy programmers are expelled to Dante’s fourth terrace of Purgatory for wanting to avoid using up to three more lines of code. Without demonstrating own knowledge of Dante’s Divine Comedy right now, it can be said that this indeed an audacious conclusion with regard Log4J.
A Friday unlike any other
No IT expert will forget December 10, 2021 anytime soon. A software bug stepped into the limelight of the IT world, something that fortunately rarely happens. As a result, millions of servers belonging to small and large companies could in theory be completely taken over remotely. The term Log4J, which before that date many did not know, caused employees in both operational IT and management to break into a sweat in such a way that had not been seen since Y2K.
Most readers know the story behind it, but here is a summary nevertheless:
On November 24, 2021, an Alibaba developer wrote to the Apache Software Foundation and reported on the bug. Panic set in. A manager of the software, Gary Gregory, simply thought: “Oh Sh…. We were surprised. Not because there was a security problem, but because of its scope.” Log4J is a free solution that does logging in the background of Java applications. However, because these components are so deeply buried in the core, a large number of applications utilize them and are therefore susceptible to attacks. This application was created by developers in their free time and had been made available as a free open-source software.
Afterwards, the experts tried to plug the loopholes, though this did not proceed as quickly as the loopholes were leaked. Then, at least as early as December 1, 2021, hackers began to exploit the loopholes (though these had already existed since 2013). The bug was made official by the BSI and within a few hours the number of attacks increased from a few thousand into in the millions. Hackers are happy to put in the overtime.
Impact on insurance companies and software manufacturers
Many German insurance companies and software manufacturers were affected by the attacks. They were attempted on companies such as R+V. Many others, such as Signal Iduna, Allianz and Debeka disabled parts of their IT structure as a precaution. Insurance companies such as Zurich Deutschland and Hanse Merkur went on high alert. Relying on its ISM and a task force, Gothaer navigated through the events as well. Debeka temporarily deactivated its homepage. Even big players such as Apple, Google, and Amazon were not spared, and we at adesso were also not an exception: we’ve temporarily restricted some services as a precaution. Cyber insurers feared enormous loss amounts due to this Black Friday, and inquiries with IT security experts were through the roof. Money was secondary, while security became a necessity.
Fortunately, the feared IT apocalypse didn’t happen. Many insurance companies and software manufacturers were able to prevent the worst with the help of an operating ISM, emergency plans, and probably many hours of overtime. Although it was initially expected that the major attacks would occur after the servers had been taken over, little damage has been identified as of this date.
So how is it possible that such important program code is the responsibility of a few volunteer developers? One reason is that many software manufacturers make use of these components and don’t always have to develop from scratch. In this case, many experts can the review the code. That’s not so easy with proprietary developed software. Generally-speaking, open-source components are the right decision. The problem with open-source components is often the financing. The Log4J developers, for example, worked full-time in their main job and were not paid for the maintenance of Log4J.
To help prevent similar scenarios in the future, the following points will need to be observed:
- Companies should enter into contracts with open-source developers so that the latter are paid for their work
- Open-source teams should not maintain more than 3-4 projects
- At the state level, open-source developers should be supported, as state institutions were just as much affected as private institutions. To this end, there is a feasibility study by the NGO Open Knowledge Foundation (OKFN) that the “the development, improvement and maintenance of open digital basis technologies” is supposed to support.
Conclusions
It is not a matter of lazy programmers who earned themselves a place in purgatory, but of companies, state officials, and politicians having to consider what IT security and resilience is worth to them.
Politically, the chances of this happening are not so bad, as the German government acknowledged open source ideas in various parts of its coalition agreement. On the one hand, there is to be open standards for public IT projects. Also, “development jobs are to normally be commissioned as open source,” and the resulting software is going to essentially be made public. And the key word of ‘digital sovereignty’ is also found in the agreement. This is to be achieved through the right to interoperability and portability as well as relying on open standards, open source, and European ecosystems, such as 5G or AI.
Regardless of these proposals, it is important for software developers and insurance companies to have an operating ISM with clear processes, responsibilities, communication chains, escalation rules and customer communication that is in line with all of these areas. What is crucial is not whether problems appear, but that they are addressed in a way that is professional and solution-oriented. All the same, I don’t know what sort of progress companies are making in this regard. We’ll have to wait another 20 years for the next exploit of this magnitude.
Are you trying to standardize highly customized inventory and benefit systems while also making them resilient? Do you need a software manufacturer with proven ISM processes? With our experts, we would actively support you and would look forward to tackling this with you as your partner! Get in touch with our expert Karsten Schmitt, Head of Business Development.
