Recovering from a cybersecurity earthquake: The lessons organizations must learn

It’s been over a year since the SolarWinds supply chain hack sent shockwaves through thousands of organizations worldwide, but this cybersecurity earthquake is by no means over. More recently we’ve seen aftershocks fueled by the Log4Shell and Spring4Shell vulnerabilities, which impacted organizations using the Log4j library and the Spring Core framework.

We had seen supply chain attacks before, but 2021 was the year they really took off. As was the case in the Spring4Shell and Log4j attacks, the use of open-source solutions has increased the risk. They’re ubiquitous in almost every form of software development and often developed at speed, leaving gaps in security. This means that if there are any vulnerabilities within open-source components, the impact will massive.

In the wake of Log4Shell and Spring4Shell, there are three key lessons organizations must learn so they stay safe while utilizing open-source software:

Spotting the risks

To securely develop, manage, and maintain a software supply chain, you must understand and have visibility of all the links.

To ensure security, businesses need a clear inventory and true understanding of all the open-source components in use. You can’t afford to blindly trust the provenance and security of software components. If incidents like Log4Shell, Spring4Shell and SolarWinds have taught us anything, it’s that we need more awareness of all the different pieces of software used within an organization.

This includes how and where they were developed, as well as where they’re being used throughout the company, so that if vulnerabilities are discovered the problem can be addressed quickly to limit the damage.

Don’t overcomplicate

Number two on the list is the need to make yourself shockproof. When developing frameworks or libraries, it’s important to do it well. But it’s also important to take a more simplistic approach so you don’t unknowingly introduce vulnerabilities.

Concentrating on doing a few things well is better than introducing a lot of features badly. The more features there are, the more likely there is to be a critical vulnerability. So, when looking at what new features you’d like to add to products and services, think carefully about whether you need them and only switch on features that you know are essential.

Despite the need to develop fast, companies need to make sure they’re taking the time to really think about what features they absolutely need and why – as anything that is surplus to requirement may just leave the door open to vulnerabilities.

Remove the toil

Thirdly, organizations need to be aware of cross-cutting concerns when designing and developing different applications. Whether it be for logging, metrics, encrypted communications, or caching, it’s important to think whether these ongoing concerns need to be handled within the application or whether they can be externalized instead.

Let’s take an example. With logging, many frameworks can send logs to a variety of locations including output files called stdout and alerting services, which your application is responsible for. But there is a better, more secure approach you could take. Instead, think about getting your application to send logs to stdout and then leverage a log collector service, to send the logs to all required end locations. By externalizing these concerns, there’s less code and configuration for developers to worry about, and therefore fewer vulnerabilities that can creep in.

The aftermath

Log4Shell and Spring4Shell have only served to emphasize the need for organizations to take proactive steps to safeguard their environments. However, this is only going to become harder as innovation accelerates, creating more and more machine identities for businesses to keep an eye on.

Attempting to monitor and manage all those machine identities, whilst also keeping stock of all software components and ensuring development remains simple will be no easy task. Organizations nowadays just lack the skills and resources to ensure they can tick all those boxes. Instead, they should utilize automation and security tooling to ensure these vulnerabilities are kept to a minimum, so the shockwaves of attacks like those that hit Log4j aren’t felt as widely.