For those who’ve ever had their home broken into by thieves, they will understand that initial sinking feeling that something has gone wrong, followed by the realization that the house has been stolen from and violated. It usually results in lasting discomfort, not to mention a pivot to security measures that would rival Fort Knox.
Now imagine that the home was breached because the thieves have made themselves a key. They creep around, coming and going as they please, but are careful to remain undetected. Then, one day, it’s clear that the jewelry hidden in the freezer has been stolen, the safe has been emptied, and all personal belongings have been ransacked. An organization faces this when it falls victim to a zero-day cyberattack. In 2020, a study by the Ponemon Institute found that 80% of successful data breaches were the result of zero-day exploits, and sadly, most companies remain ill-equipped to make a significant improvement on this statistic.
Zero-day attacks, by definition, give developers zero time to find and patch existing vulnerabilities attackers can exploit because the threat actor got in first. They do the damage and then it’s a mad scramble to fix both the software and reputational damage to the business. Attackers are always at an advantage it’s crucial close that edge as much as possible.
The holiday gift nobody wanted - Log4Shell – has been blowing up the internet, with more than 1 billion devices reportedly affected by this Java vulnerability. It may wind up being the worst zero-day attack on record, and we’re just getting started. Despite some reports that said the exploits started a few days before public disclosure, a presentation given at the Black Hat Conference in 2016 suggests this has been a known issue for years. Ouch. Worse still, it’s painfully easy to exploit, and every script kiddie and threat actor on the planet has been chasing paydirt.
So, what’s the best path forward for defending against a slippery, sinister threat, not to mention vulnerabilities that have been missed in the software development process? Let’s take a look:
- Large organizations may consider buying an exploit – but a bug bounty program costs less.
There’s a huge market for exploits on the dark web, and zero-days tend to go for a pretty penny, with one example listing for $2.5 million. Reported to be an exploit of Apple iOS, it’s no surprise that the security researcher’s asking price was through the roof; after all, this could wind up being the gateway to compromising millions of devices, harvesting billions of sensitive data records – and the attack could run for as long as possible before it’s discovered and patched.
But who has that kind of money, anyway? Typically, organized cybercrime syndicates will come up with the cash if it’s deemed worthy, especially for ever-popular ransomware attacks. However, global governments and defense departments are among the clientele for exploits they can use for threat intelligence, and in more positive scenarios, the companies themselves may buy their own potential zero-day exploits so they can mitigate disaster.
2021 saw records broken for live zero-day exploit discoveries, and it’s large organizations, government departments, and infrastructure that are most at risk of being probed for any weaknesses. There’s no way organizations can fully protect themselves from the possibility of a zero-day attack, but they can “play the game” somewhat by offering a generous and well-structured bug bounty program. Rather than wait until someone offers the keys to the organization’s software castle on a dark web marketplace, get legit security buffs on the company’s side and offer them decent rewards for ethical disclosure and potential fixes.
And if the zero-day presents a hair-raising threat, it’s safe to assume the organization will need to cough up more than an Amazon gift card.
- Do an inventory of the security team’s tooling.
Cumbersome security tooling has been an issue for a long time, with the average CISO managing anywhere from 55 to 75 tools in their security arsenal. Aside from being the world’s most confusing Swiss Army Knife, 53% of enterprises aren’t even confident they’re working effectively, according to a study by the Ponemon Institute. Another study found that just 17% of CISOs thought their security stack was “completely effective.”
In a field known for its burnout, lack of skilled security people to meet demand, and the need for agility, forcing security professionals to work with information overload in the form of data, reporting, and monitoring of huge toolsets causes additional burdens. It’s exactly the type of scenario that can cause them to miss a critical alert, which may well have been the case when it came to properly assessing Log4j for its weaknesses.
- Proactive security should include developer-driven threat modeling.
Code-level vulnerabilities are often introduced by developers, and they need precision guidance and regular learning pathways to build secure coding skills. However, next-level secure developers have been given the opportunity to learn and practice threat modeling as part of their software creation process.
The people who know their software best are the developers who have sat there and created it. They have powerful knowledge on how users interact with it, where the features are used, and when sufficiently security-aware, potential scenarios where it could break or be exploited.
When we think about the Log4Shell exploit, we are unfortunately seeing a scenario where a vulnerability has escaped detection by experts and complex toolsets, however, it may not have occurred at all if the library was configured to sanitize user input. The decision against doing so seems to have been an obscure feature for added convenience, but made it painfully easy to exploit. If threat modeling was done by a group of keen, security-savvy developers, it’s highly likely this scenario would have been theorized and considered.
A great security program has an emotional component, with human intervention and nuance at the heart of solving human-created issues. Threat modeling takes empathy and experience, as does secure coding and configuration at the architectural level of software and applications. Please do not throw developers into this overnight. Create a clear pathway to upskill them to a level where they can take the pressure off the security team for this important task. It’s also a great way to build rapport between both teams).
- Get patches out quickly.
Finally, get patches out as fast as possible, encouraging every user of the vulnerable software to apply it urgently. With Log4Shell, it could eclipse Heartbleed in its endurance and potency in the face of it being embedded in millions of devices, and creating complex dependencies across a software build.
Realistically, there’s no way to completely stop this type of insidious attack. However, with a commitment to using every avenue to create quality, secure software, and approaching development with the same mindset as the company would critical infrastructure, we can all have a fighting chance.
Matias Madou, co-founder and CTO, Secure Code Warrior
