Sudden, unexpected, and potentially very damaging. Zero-day attacks are the perfect storm for malicious actors and one of the worst-case scenarios for developers, security professionals, and DevOps teams. Yet it’s not all bad news for those charged with protecting your code, software, and applications, as long as you expect the unexpected and prepare for it. Building a fast, effective mitigation response for zero-day attacks starts with these three tactics:
Perhaps the most important factor is to know what software components and dependencies are used in your organization. To do so, maintain active scans of all your projects and their components so you know exactly what is being used. That level of visibility means that it’s easier to quickly detect new vulnerabilities and identify where they are. That doesn’t remove the surprise factor of a zero day, but it does ensure that you’ve greatly reduced the time it takes to find and deal with them.
Software bills of materials (SBOMs) are crucial for success, particularly in organizations that use components at scale. In addition to fulfilling compliance criteria, an SBOM is a good way to pass information around inside the organization, thereby increasing awareness of your software’s components and dependencies and becoming more sensitive to anomalies and previously unidentified components that could be malicious.
However, an SBOM only provides a snapshot of a moment in time in your code base, so it’s not a one-and-done process.Regularly and frequently review and revise your SBOMs to ensure that they’re up-to-date and to maintain visibility into your code base.
It’s also important to ensure that you’re using recent dependency versions, valid licenses, and applying critical security patches to your software. As new vulnerabilities are discovered, it stands to reason that you should implement the most recent updates to handle them. Be aware that, in general, dependency names, versions, and their licenses are static, unless you’ve made changes to the application. What changes without explicit intervention are the vulnerabilities that are associated with these components. So, once again, knowing what you’re using, knowing quickly what’s changed, and achieving this via continuous vigilance and updates, is what will accelerate your responsiveness to anomalies and damaging vulnerabilities.
This knowledge is what gives you the ability to respond. If you’re using a dependency that’s three years out of date, you’ll face a fire-drill dilemma of two bad choices should a zero-day vulnerability arise:
To avoid that, maintain recent dependencies. It gives you a much better ability to react when a zero-day vulnerability hits.
Knowledge and awareness are key starting points for handling zero-day attacks, but you need to accompany this with a plan of action. First, someone must be made accountable for your organization’s security response and for leading the remediation efforts, and others must be charged with locating and remediating any vulnerabilities. If it isn’t clear who does what, then any efforts are likely to be compromised, or, at worst, will prove to be ineffective. There has to be a clearly defined process in place.
One key element is to build proactive security activity early into the development process in a way that developers will embrace. While developers’ main challenge is to create and deliver software and applications, they must increasingly incorporate security processes as security shifts left in the SDLC. However, you’ll only succeed if the tools developers employ are effective, easy to adopt, and easy to use. You increase the likelihood of getting your developers to do things such as maintain current dependency updates if the tools seamlessly integrate with their current workflow. For example, Mend Renovate achieves this by being open source and widely used within the development community. It scans the repo to detect dependencies and treats every component as a dependency that should be examined for vulnerabilities, such as Docker images, Kubernetes manifests, and infrastructure as code files. It aggregates all of that data and enables project leaders to see what’s going on everywhere in the code base.
And it’s scalable, which is important because it enables enterprises to confidently expand their vulnerability detection and mitigation capabilities as projects grow. This is a big consideration for major enterprises like IBM, Capital One, Fidelity, and Morgan Stanley, who want to be sure that they don’t encounter scaling issues when keeping pace with changing and new dependencies. For that, your tool must roll out efficiently, like Mend Enterprise, where you can use the repo integrations, and scale endlessly in the organization, and it’s all fed back to the Mend Enterprise app.
It’s almost axiomatic that as technology develops, so do the ways that malicious actors can create and exploit vulnerabilities. As hackers get wilier and zero-day vulnerabilities get more sophisticated, security tools must stay ahead of them by becoming even more effective, easier to use, and faster to integrate.
This means that the implementation and adoption of new tools in any software stack needs to be as seamless and simple as possible. No organization wants to roll out a security tool that makes a ton of noise from their repos, opens too many pull requests, and creates issues like an overwhelming number of false positives. Rather, they need ease of use and effectiveness. For example, tools that comprehensively scan in the background and feed the data to the CISO. Then you want to easily on-board the development team once they’re ready, with whatever plan you have, by application, criticality, and such, simply by moving to an active mode. If you’re scanning in the background, you’re not making any noise for anybody, except for the DevOps admin who is approving the app, and you’ll get all the data very quickly, with no protest from anyone. So, when you’re ready, the rollout is unproblematic. You can do it in minutes. And you can prioritize the rollout and test the active parts on whichever themes you like. Some tools are already on the way to achieving this, but there’s still work to be done to perfect this capability.
In talking with our customers, I generally see that most have clear visibility into their components and dependencies. Maintenance of these components and dependencies is reasonably good and improves dramatically with increased adoption of our tools.
However, planning often remains a challenge. While many companies are very well set up with issues management and crisis planning, others have considerable work to do in that area. We saw this in the case of Log4j, as some customers responded rapidly and remediated the vulnerability in just a matter of hours. Others took three, four, or five days or more to remediate it.
Behind all of this is the necessity for an important cultural shift, which is driven by educating users. Many people aren’t really aware of the benefits of up-to-date dependencies, mainly because, when things are working well, you see no problems. Ironically, the benefit of thwarting zero-day attacks with a policy of up-to-date dependencies is that nothing happens. It’s just invisible. Only when you fall victim to a zero-day attack, or you implement a malicious dependency update, does it make headlines.
So don’t be a headline-maker. Be aware, be vigilant, be prepared, and be confident in the security of your code, your software, and your applications.