Addressing the challenge of non-patchable security [Q&A]

While many organizations have solutions in place to identify patchable CVEs, non-patchable security issues such as misconfigurations continue to provide threat actors with consistent access points to exploit organizations.

We spoke to Jason Mar-Tang, field CISO at Pentera, to discuss the challenge of non-patchable security issues vs. CVEs, what makes them so much more difficult to identify, the challenges of remediation, and what standards organizations should implement to tackle this challenge.

BN: What are the key differences between patchable and non-patchable security issues?

JMT: On the base level as the names imply, patchable vulnerabilities are those where the issue can be solved relatively simply with a vendor-provided patch or a larger patch management strategy, while un-patchable are those where the mitigation isn't so clean and simple.

Patchable security issues are vulnerabilities addressed by software updates, often identified with a CVE (Common Vulnerabilities and Exposures) designation. These are typically coding flaws or known exploits in software libraries or operating systems, and when discovered it's the vendor's responsibility to provide a patch for users to implement. CVEs tend to be easier to identify with security advisories and vulnerability scanners/vulnerability management (VM) tools readily identifying and tracking them.

Non-patchable issues, however, is a blanket term for a variety of vulnerabilities that stem from factors that software patches alone cannot fix -- such as misconfigurations, excessive permissions, business logic flaws, or insecure system architecture. These vulnerabilities are less visible because they lack a standardized tracking system like CVEs, and they may persist even after all available patches are applied. They are elusive, often going undetected by automated tools, and require specialized, often manual intervention to resolve.

BN: What makes non-patchable vulnerabilities so difficult to identify, and why are they often overlooked in traditional security assessments?

JMT: Non-patchable vulnerabilities are difficult to identify because the issues themselves may be inherent to how systems work. They appear to be legitimate functions or configurations within the system, while actually increasing the risk footprint of an organization. This makes them very difficult to spot because there isn't necessarily a tell-tale sign for them like with CVEs, which have a specific digital footprint, they are context specific and require knowledge of the system and business logic. It's usually a case of 'discovery through exploitation.'

An example, one that we’ve seen across several field assessments is that the same local admin password is repeated across infrastructure. Even if the password itself conforms to best practices and has a complex makeup of numerous letters, numbers and special characters, the repetition of the password would create a vulnerability that would enable lateral easy movement if compromised. This isn't something that is 'patchable' and your security wouldn't necessarily flag it (because the password in a vacuum is strong), but it is something that needs to be rethought, reconfigured, or specially mitigated in order to rectify the exposure.

BN: How is this issue evolving especially in light of increasingly common complex environments?

JMT: As I mentioned, identifying and remediating unpatchable vulnerabilities is increasingly difficult because it demands a deep understanding of how the systems work and the context they exist within. In large organizations that operate hybrid environments, this challenge is amplified as organizations integrate on-premises systems, cloud platforms, and edge technologies, each with its own complexities. No single individual or team can realistically master every component of such a diverse ecosystem, making it harder to identify and address vulnerabilities effectively.

If that wasn't enough the interconnected nature of hybrid environments adds an extra level of complexity. Fixing a vulnerability in one area may unintentionally disrupt another, necessitating a nuanced understanding of dependencies and potential impacts. As these environments grow in complexity, the gap between vulnerabilities and the expertise required to mitigate them is widening, leaving organizations increasingly exposed.

BN: How can organizations balance their efforts between addressing patchable vulnerabilities and tackling non-patchable security gaps?

JMT: If possible, prioritization should always rely on business impact analysis; assessing which vulnerability would have the most adverse impact on my critical business assets if exploited. Of course this is easier said than done as assessing the downstream business impact is not a simple task. Pentera's State of Pentesting 2024 report found that only 34 percent of respondents place business impact as a top priority to guide their remediation strategy, and this is likely because other methodologies are more readily available and easier to achieve, especially for smaller security teams. For instance, CVSS score rankings are typically built into visibility metrics of most VM solutions while the downstream impact assessment on business operations of a vulnerability would be out of reach for the majority of organizations.

Another methodology that we recommend is prioritizing truly exploitable vulnerabilities vs. theoretical. To elaborate, classic VM solutions enumerate every CVE within your organization, however, only a small percentage of those CVEs have the potential to be exploited in the context of your organization. If security teams spend time remediating every critical vulnerability just because it has a high CVSS score, that comes at the expense of other vulnerabilities that have a greater potential impact within the context of the environment. Realistically security and IT teams cannot remediate every issue, so we need to ensure that the ones we fix are truly impactful.

BN: Are there standards or best practices should organizations adopt to better manage the risks posed by non-patchable vulnerabilities alongside CVEs?

JMT: Ultimately, it comes down to proactive testing. Organizations need to test their defenses against the real tactics, techniques and procedures (TTPs) that hackers are actively using in the wild. Seeing our environments from an attacker’s perspective allows us to pinpoint exploitable gaps in our security, whether patchable or un-patchable, before they can be breached. Implementing a Zero Trust framework is a strong step for any organization, but without testing, there’s no way to confirm its effectiveness -- and you certainly don’t want attackers uncovering its weak points for you.

Traditionally, the best methodology for identifying exploitable security gaps has been manual pentesting and red-team exercises. If the testers can breach your organization, so could a malicious hacker. Most enterprises are already testing to some degree, but the problem they face is the scalability of such exercises. Scaling manual pentesting and red-teaming efforts to cover the modern IT environment is not really a viable option, as the costs to achieve continuous testing across the scale of today’s attack surfaces would be unrealistic.

Today there are security solutions that provide automated pentesting and security validation services that make it possible to test and validate the effectiveness of existing security controls at-scale. These are becoming increasingly important to maintaining consistent security postures as security teams are quickly realizing that once or twice a year compliance pentests leave five to 11 month stretches where their security is untested. In fact, Gartner's Continuous Threat Exposure Management (CTEM) framework, advocates for continuous testing and adversarial emulation to improve overall security.

Image credit: WrightStudio/depositphotos.com