Recovering From a Cybersecurity Earthquake: 4 Lessons Companies Must Learn

In this article, the author discusses four lessons that help companies stay safe when building and using open-source software.

August 9, 2022

Recent incidents, such as SolarWinds, Log4Shell attacks and Spring4Shell vulnerabilities, show that open source solutions have increased risks of cyberattacks. Tony Hadfield, director solutions architect, Venafi, discusses four lessons that help companies stay safe when using open source software.

It has been more than a year since SolarWindsOpens a new window Sunburst sent shockwaves through thousands of organizations worldwide. More recently, we have seen an aftershock, as cybercriminals took advantage of the Log4ShellOpens a new window vulnerability, allowing them to access entire networks through affected devices or applications using a popular logging API from Apache.

This vulnerability was used to compromise millions of devices across the internet. This was quickly followed by another vulnerability called Spring4Shell that left millions of apps and websites open to attack, with 37,000 instancesOpens a new window of the vulnerability being exploited in a single week.

The scope of these attacks is what sets them apart. We have seen supply chain attacks before, but 2021 was the year this attack method was used successfully to comprise so many users. As in the Spring4Shell and Log4j attacks, the use of open source solutions has increased the risk. Open source software is ubiquitous in nearly every software development team, and these components are often developed at a speed that can leave gaps in security. Because open source components are shared widely, if there are any vulnerabilities within these components, then the impact of a successful attack will be far larger than an attack targeting a specific company’s network. 

In the wake of both Log4J and Spring4Shell, four key lessons can help organizations remain safe while building and utilizing open-source software:

1. Spot the Risks

Developing, managing, and maintaining a software supply chain is a bit like anything that relies on a chain — you need to know where the weakest links are. To do this, you first need visibility into all the links. For instance, if you are a team of first responders to the scene of a building that has collapsed in an earthquake, there is a lot you need to know. Who on the team has medical experience? Who has experience with earthquakes and aftershocks and can help with risk assessments? Are there any unsafe areas that might require special safety equipment? You need to know the details right down to the language spoken by people who may be trapped. If you do not have all that information, you will have significant blind spots. 

Enterprises must take the same approach when looking to protect their software supply chains, making sure every link is clearly identified so the risks connected with it can be accurately assessed. It is inevitable that new critical vulnerabilities will be discovered in software, particularly in the open source libraries and frameworks that are becoming increasingly popular and are deployed across organizations worldwide. 

However, to ensure security, businesses need a complete inventory and a comprehensive understanding of all the open source components in use. If incidents like Log4Shell, Spring4Shell and SolarWinds have taught us anything, it is that we need more awareness of all the different pieces of software used within an organization. This includes how and where they were developed and used throughout the company so that when vulnerabilities are discovered, the problem can be remediated quickly to limit the damage.

2. Build a Better Open Source Ecosystem

Number two on the list is the need to make the open source software you build for yourself and share with the community shockproof. When developing frameworks or libraries, it is important that the software is fit for the purpose. It is also important to take a security-minded approach so that you do not unknowingly introduce vulnerabilities.

In general, when building open source components, it is better to concentrate on doing a few things well. Complex open source software will always be more likely to be vulnerable because of its complexity. In the case of Log4J, it had all the bells and whistles, which no doubt made it such a popular product, but also left it vulnerable. The obvious point is that the more features there are, the more likely there is to be a critical vulnerability. 

This maxim is also true when developing proprietary software. When your development teams are deciding which new features they would like to add to products and services, think carefully about whether each function is really needed and only switch on features that you know are essential. The need to innovate quickly is a business imperative, but companies also need to make sure they are taking the time to really think about which features they absolutely need and why. Anything surplus to the requirement may just leave the door open to vulnerabilities. 

See More: Importance of Cybersecurity Awareness for Rural Communities, Minorities, and Small Businesses

3. Simplify, Simplify, Simplify

Preparing for the inevitability of an earthquake — ensuring people are educated on what to do, working earthquake protections into buildings in regularly affected areas — can all help reduce the impact. We should be working the same safeguards into our software. Our third piece of advice, therefore, is for teams to cross-cutting concerns when designing and developing different applications. Be it logging, metrics, encrypted communications, or caching, it is important to consider whether these ongoing concerns need to be handled within the application or whether they can be externalized instead. 

Let us take an example particularly relevant to Log4j. Many logging frameworks send logs to a variety of locations, including output files called stdout as well as alerting services. But there is a better, more secure approach you could take. Instead, think about building your application to send logs to stdout and leveraging a log collector service that sends the logs to all required end locations. By externalizing these concerns, there is less code and configuration for developers to worry about, reducing the application’s attack surface.

4. Build Security Into Software Development

Code is designed by humans and is fallible. As such, earthquakes, like software vulnerabilities, are inevitable. Yet, as an industry, we can do more to insulate ourselves from the tremors. In theory, Log4Shell and Spring4Shell could have been prevented. The breaches that resulted from these vulnerabilities really emphasize the need for organizations to take proactive steps to safeguard their software development and distribution environments. However, accomplishing this requires increased focus by public and private sector organizations. We all need to get better at building security in our software development processes. 

The good news is that progress is happening; there are multiple organizations helping to support the shift toward building more secure software and improving the security of the open source ecosystem. We believe this shift is the future for software development. And the faster we can make this shift, the faster we will realize the benefits. Not only will we all be better protected against software vulnerabilities, but developers and maintainers will also have more time to build and innovate the products our digital economy depends on for everything from healthcare to transportation.

What steps have you taken to mitigate cyberattacks due to usage of open-source software? Let us know on FacebookOpens a new window , TwitterOpens a new window , and LinkedInOpens a new window .

MORE ON CYBERSECURITY:

Tony Hadfield
Tony Hadfield

Director Solutions Architect, Venafi

Tony Hadfield is a Senior Director Solutions Architects at Venafi, where he works with strategic accounts across a variety of verticals including manufacturing, retail, finance, and healthcare. Tony has spent the last 24 years of his career focused on computer security. After starting his career at McAfee as a software developer, he has worked with antivirus, network Security, white listing and encryption.
Take me to Community
Do you still have questions? Head over to the Spiceworks Community to find answers.