It has been observed that attackers will attempt to start exploiting vulnerabilities within the first fifteen minutes of their disclosure. As the time to patch gets shorter, organizations need to be more pragmatic when it comes to remediating vulnerabilities, particularly when it comes to prioritization.
Organizations need to strike the balance of carrying out enough due diligence before patching, and then patching as quickly as possible to defend themselves against emerging threats. A few things should be considered to make this easier:
Understanding your attack surface
Attack surfaces constantly evolve and change as new applications are developed, old systems are decommissioned, and new assets are registered. Also, more and more organizations are moving towards cloud-hosted infrastructure, which changes the risk and responsibility for securing those assets. Therefore, it is essential to carry out continuous or regular assessments to understand what systems are at risk, instead of just taking a point-in-time snapshot of how the attack surface looks at that moment.
The first step would be to map “traditional” asset types – those easily associated with an organization and easy to monitor, such as domains and IP addresses. Ownership of these assets can be easily identified through available information (e.g., WHOIS data).
The less traditional asset types (such as GitHub repositories) aren’t directly owned by the organization but can also provide high-value targets or information for attackers. In addition, it’s beneficial to consider the less obvious attack scenarios that may be introduced due to employees working from home and relying on remote access solutions and home network setups.
It’s also important to understand which technologies are in use to make sound judgements based on the vulnerabilities relevant to the organization. For example, out of one hundred vulnerabilities released within one month only 20% might affect the organization’s technologies.
Prioritization and context
Once organizations have a good understanding of what assets might be at risk, context and prioritization can be applied to the vulnerabilities affecting those assets. Threat intelligence can be utilized to determine which vulnerabilities are already being exploited in the wild. So, from the above example, even though only 20% of those one hundred vulnerabilities might affect the organization’s technologies, only 8% of that 20% are actively exploited in the wild. Therefore, the list of vulnerabilities you should be concerned with is reduced and much more manageable.
It’s also crucial to understand the specific threats to your organization. For example, web skimmer-based attacks are most likely to target retail businesses. Likewise, if ransomware attacks are a particular threat to your organization, consider the likely access vectors and prioritize remediation of related issues.
Remediate based on the likelihood of exploitation – is it a new vulnerability, or is it already well-established and extensively discussed online? For example, the most exploited vulnerabilities during the first half of 2022 were all released towards the end of 2021, demonstrating that the most popular vulnerabilities are more likely to be exploited.
It can, however, work the other way. For example, when a vulnerability affecting Apache Commons named Text4Shell was released, the media perceived the vulnerability to be far more serious than it turned out to be, partly due to the name and Log4Shell flashbacks. It took a moment for security researchers to investigate and reassure organizations that it was, in fact, far less serious than most media outlets made it out to be.
But is this enough?
Seeing the above stats can leave organizations feeling like they’re never going to be able to patch in time, so maybe we need to consider a different approach.
For example, OpenSSL recently notified customers that a security patch would be released the following Tuesday to address a critical severity vulnerability affecting versions 3.0.0 and 3.0.6.
While the announcement caused some panic, it also gave organizations time to prepare for the patch release and minimize their exposure time. In an ideal world, if organizations already have a good understanding of their attack surface, they can proactively prepare affected systems for patching. However, this doesn’t take into consideration the time required to test patches before rolling them out to production systems.
What is then the correct answer for this conundrum? The answer is that there is no answer! Instead, organizations should consider a mindset shift and look towards preventing issues whilst adopting a defense-in-depth approach; focus on minimizing impact and risk by prioritizing assets that matter the most and reducing time spent on addressing those that don’t. This can be achieved by understanding your organization’s attack surface and prioritizing issues based on context and relevance.