A version of this article appeared in SC Magazine. It has been modified and syndicated here.


If you’ve ever had your home broken into by thieves, you’ll understand that initial sinking feeling that something is wrong, followed by the realization that you have, indeed, 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 your home is 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, you notice all too late that the jewelry you hid in the freezer is gone, your safe has been emptied, and your personal belongings have been ransacked. This is the equivalent reality an organization faces if it falls victim to a zero-day cyberattack. In 2020, a study by the Ponemon Institute revealed 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 that could be exploited, because the threat actor got in first. The damage is done and then it’s a mad scramble to fix both the software and reputational damage to the business. Attackers are always at an advantage, and closing that edge as much as possible is crucial. 

The holiday gift nobody wanted - Log4Shell - is currently blowing up the internet, with over a billion devices said to be affected by this catastrophic Java vulnerability. It’s shaping up to be the worst 0day attack on record, and we’re just getting started. Despite some reports stating that exploits started a few days before public disclosure, a presentation given at Black Hat Conference in 2016 would suggest this has been a known issue for some time. Ouch. Worse still, it’s painfully easy to exploit, and every script kiddie and threat actor on the planet is chasing paydirt with this vulnerability. 

So, what is 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. 

Zero-day attacks against big targets are rare (and expensive)

There’s a huge market for exploits on the dark web, and zero-days tend to go for a pretty penny, with one example in this article listed for $2.5M at the time of writing. Reported to be an exploit of Apple iOS, it’s no surprise that the security researcher’s asking price is through the roof; after all, this could indeed be the gateway to compromise millions of devices, harvest billions of sensitive data records, and do it 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 be buyers of their own potential zero-day exploits so they can mitigate disaster. 

2021 saw records broken for live zero-day exploit discoveries, and it is large organizations, government departments, and infrastructure that are most at risk of being probed for any weaknesses. There is no way to be completely safe from the possibility of a zero-day attack, but you can “play the game” somewhat by offering a generous and well-structured bug bounty program. Rather than wait until someone offers the keys to your software castle on a dark web marketplace, get legit security buffs on your side and offer them decent rewards for ethical disclosure and potential fixes. 

And if it just so happens to be a hair-raising zero-day threat, it’s safe to assume you’ll need to cough up more than an Amazon gift card (and it will be worth your while to do so).

Your tooling could be a liability for your security personnel

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 (metaphorical) Swiss Army Knife, 53% of enterprises aren’t even confident they’re working effectively, according to a study by the Ponemon Institute. Another study revealed that just 17% of CISOs thought their security stack was “completely effective”.

In a field known for its burnout, lack of security-skilled people to meet demand, and need for agility, forcing security professionals to work with information overload in the form of data, reporting, and monitoring of huge toolsets is burdensome. This is 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. 

Preventative 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.
‍
It shouldn’t come as a surprise that 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. 

If we bring this back to the Log4Shell exploit, we are unfortunately seeing a scenario where a catastrophic 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 (think SQL injection-level, certainly not genius stuff). 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 to be effective, as does secure coding and configuration at the architectural level of software and applications. This is not something that developers should be thrown into overnight, but a clear pathway to upskill them to a level where they can take the pressure off the security team for this important task is ideal (and it’s a great way to build rapport between both teams). 

Zero-days lead to n-days

The next part of dealing with a zero-day is getting patches out as fast as possible, hoping like hell that every user of the vulnerable software applies it as soon as possible, and certainly before an attacker gets there first. 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 is 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 you would critical infrastructure, we can all have a fighting chance.