In this the second installment of The Vulnerability & Exposure Management Survival Series, we will explore strategies for improving threat detection. 

• Strategies for Improving Governance & Compliance
• Strategies for Improving Detection (YOU ARE HERE)
• Strategies for Improving Assessment & Prioritization
• Strategies for Improving Communication
• Strategies for Improving Mitigation & Remediation

‍

Detection is a critical component of both vulnerability management and continuous threat exposure management programs. Detection refers to the process of identifying potential security weaknesses, vulnerabilities, or threats within an organization's systems, networks, or applications. By enhancing detection capabilities and supporting processes, organizations can identify and address risk faster, thereby improving the overall security posture.

Scan More Frequently: It Will Make You Look Good and Reduce More Risk

This one probably seems obvious, but in practice, it can be difficult to do. As I noted previously, there are often business constraints like the inability to scan during working hours or an organizational aversion to agents preventing teams from improving their detection frequency. There are a number of strategies for overcoming these barriers, including demonstrating that agent-based scanning is less intrusive when compared with authenticated scanning.

The reality is that every organization is different, and with different challenges to overcome. Find your champions and neutralize your blockers with data showing the benefits to your security posture and minimized impact to performance. The obvious benefit to scanning more often is that it reduces mean time to detection (MTTD) by minimizing the time it takes to identify vulnerabilities. But wait, there's more! For the low cost of scanning more frequently, you too could recognize boosts in compliance rates and an overall reduction in MTTR (Mean Time to Remediation).

Key Insight:

How does more frequent scanning result in such positive benefits on seemingly unrelated remediation-based metrics like SLAs? It's pretty simple. Many off-the-shelf software products have auto-updating capabilities, which organizations have enabled to reduce the amount of patching and speed up the delivery of new features and bug fixes. Let's take Google Chrome, for example. Google's Chromium-based browser is vulnerable to new CVEs (Common Vulnerabilities and Exposures) on what seems like a daily basis. (In 2023, Chrome averaged about 25 vulnerabilities reported per month). Generally, this browser is on almost every laptop and workstation and sometimes even on servers (Why? Beats me, ask your local system admin). Let's say Chrome has over 50,000 instances across your environment, and it's impacted by a new CVE once a week. However, you only scan monthly. You will likely never know that you're impacted by a large percentage of those hypothetical 200,000 vulnerabilities. That's because they were closed via auto-update prior to you completing your monthly scan—and guess what? You didn't get credit for closing them!

Scanning more frequently creates easy wins all over your network, especially when auto-update or auto-patching capabilities are enabled. As scanning becomes more frequent and you reduce your mean time to detect (MTTD) vulnerabilities, you are also reducing your MTTR by finding and fixing issues faster.

In 2023, Chrome averaged about 25 vulnerabilities reported per month

Increase the Depth of Your Scanning, Include Runtime

Runtime can be a challenging concept to understand if you have never been a developer, software engineer or supported an application security team. Luckily we don't need to understand runtime in-depth to understand how it relates vulnerabilities and their susceptibility to exploitation. Our friend's at NIST have a simple explanation of runtime, defining it as the period during which a computer program is executing. So what does this have to do with vulnerabilities? A lot - stick with me.

A computer program can be complicated, often consisting of packages, libraries, modules, executables, APIs and so forth. All of these parts that make up a computer program are built upon code which can be written in a large number of languages like Python, Java, Go, Ruby and more. Now about those pesky vulnerabilities. OWASP defines a software vulnerability as a problem in the code that can be directly used by a hacker to gain access to a system or network. We've already established that runtime is when a computer program, or code, is executing so now let's put it all together.

A vulnerability in code that is not executed in runtime is less susceptible to exploitation because it cannot be triggered or reached during the program's operation. If there's no execution path that leads to the vulnerable code, attackers have no means to interact with it, making exploitation practically impossible. So why would we prioritize a vulnerability not in runtime the same as one that is? We shouldn't.

Key Insight:

You have probably guessed by now that I like analogies. Well I have another one for vulnerabilities in runtime that helps me to simplify the concept for those unfamiliar. You have 2 cars. 1 car that is parked in a parking lot and another that is speeding down the highway. Which is more likely to get into an accident? It has to be the car on the highway and in this analogy that is the vulnerability in runtime which is more likely to be exploited.

Ok, now you may be asking why you would include code that is never executed as part of the program. Well there are lots of reasons and most of them aren't good. There is even a Common Weakness Enumeration associated with Dead Code, CWE-561. This weakness is present when the code in question cannot be executed during runtime, which may indicate a logic error or the presence of leftover code that was not properly removed after debugging or refactoring. Bottom line - removing code that is never in runtime can improve the efficiency, maintainability, and security of a software application by reducing unnecessary complexity and eliminating potential vulnerabilities.

Cloud Native Application Protection Platforms (CNAPP) like Wiz, Prisma Cloud, Sysdig and others have made the detection of vulnerabilities in runtime a reality in recent years. However this is much more difficult to do on-prem, unless you have Zafran that is (SHAMELESS PLUG). Jokes aside we should see more and more technologies introducing these capabilities over the coming years making this practice realistic for most organizations.

I encourage you, where possible, to incorporate runtime detection into your process so that you can prioritize the vulnerabilities that present the most risk to your organization. We already have more vulnerabilities than we can keep up with, so let's focus on the ones that present real risk to our organizations.

Conclusion

In this blog, we discussed how to improve the means of detection. To reduce mean time to detection (MTTD), increase the frequency and depth of vulnerability scanning. This reduces the risk that a newly published vulnerability and exploit will fall between scan intervals. Moreover, prioritizing vulnerabilities found in runtime focuses your exposure management program on those which are much more likely to be exploited.

In the next blog, we will examine Strategies for Improving Assessment & Prioritization of exposures.

To discuss your exposure management program, and how Zafran might help you sharpen the focus on the vulnerabilities most likely to be exploited, click Get A Demo to connect with an expert.

In the next blog post in the Vulnerability and Exposure Management Survival Series, we will explore strategies for improving assessment & prioritization
‍

Who is Nate Rollings?

Nate is an accomplished cybersecurity leader with more than 15 years of experience at Fortune 500 companies. He is a subject matter expert well versed in building high-functioning vulnerability and exposure management programs. Nate is a respected voice in the cybersecurity community, and currently serves as Zafran’s Field CISO.