Your cybersecurity team deserves the gift of an overdue vacation, or maybe a few extra days. While most of us were enjoying the festive year-end season, many cybersecurity professionals were hard at work trying to fix the Log4j vulnerability that became a major problem that began in late November. Instead of coming out of the latter part of December in lockdown mode, IT professionals have been scrambling to track down the extent of the problem and take all necessary remedial steps. A lot of sleep and vacation time was lost in the process.
Even if your company has not directly experienced a cyber incident caused by Log4j, you may have been affected by a third-party vendor. Just in time for year-end reports, Kronos, a provider of HR products, discovered,Unusual activity affecting UKG solutions using Kronos Private Cloudmaking the services unavailable.
Log4j, the vulnerability in the Java logging package, shows the importance and vulnerabilities of open source software. in a warningThe FTC stated, “The Log4j vulnerability is part of a broader set of structural issues. It is one of thousands of unannounced but critically important open source services that are used across an infinite array of Internet companies. These are often created Projects and their maintenance by volunteers, who do not always have sufficient resources and personnel for incident response and proactive maintenance even when their projects are critical to the Internet economy.”
This vulnerability is not a single occurrence, nor is it anything new. the Equifax breach Several years ago, for example, it was also due to the weakness of open source.
open source cyber attacks 650% increase Between 2020 and 2021, and it will continue to increase because open source is more reliable than ever across the software supply chain.
Threat actors target the popularity of open source
Many users are stuck in the mindset that viruses and vulnerabilities are primarily found on Windows devices and in Microsoft software. While that may have been the case a decade ago, we’re past it. Thanks to the popularity of Linux and open source, hackers have moved on, and now some of the biggest and most malicious attacks we see happen, sometimes in the simplest units of software.
Like the recording function. It’s a nice piece of code, but Log4j exploits poorly written code in the logging function used across thousands of Linux embedded products and systems. This is not an essential component of the application; Creates records. It’s an essential feature that has become a backdoor to threats, as part of your code is usually ignored and hijacked. Now it’s all over the place, and thanks to the timing of its discovery, Log4j has become the Grinch that stole so many birthdays and holiday celebrations.
It should serve as a warning of the risks involved in the open source supply chain.
Not all code is created equal
Because open source is a collective software design, developers need to take responsibility for vulnerabilities and vulnerabilities in the code. This is how it’s supposed to work, in theory. In fact, not all code is created equal. The code scanners used by the developers did not identify the registry vulnerability to be exploited.
The challenge for CISOs and CIOs who use open source software within their organization is to come up with a way to scrutinize larger elements of the code, and dig deeper into the weeds to find potential problems in unexpected places. The tools used need to be developed.
Most computer science graduates prefer writing their own programs rather than debugging or finding weaknesses in other developers’ code. But it must be done. Information security managers and engineering executives will now ask why the logging function hasn’t come under more scrutiny. After the next exploit of the forgotten code, the same question will arise: “Why didn’t anyone think to look at this and fix it before it became a problem?” (Answer: Because everyone wants to work on more interesting problems.)
There should be a focus on open source security, at all levels of the code. It should be part of a set of checks and balances that developers use to make sure no code is lost. It should also be partially automated, using AI to do the hard work humans would rather skip. Both parts, working in tandem, must be used across all open source components, especially when open source is used in critical infrastructure.
It’s scary to think that something so fundamental, such an insignificant piece to the value of the product as a whole, has the potential to end entire business operations. Yes, some believe that open source is more secure than proprietary software because millions of people have passed the code. Last December, we saw that those million eyes didn’t see it all. Until deep-code scans are implemented, open source will still be a potential threat.