This is the first blog in a 5-part series entitled, The Vulnerability & Exposure Management Survival Series. In this inaugural blog, we will first explore strategies for improving governance and compliance. 

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

Governance and compliance is a key piece of a vulnerability and exposure management program. We use governance and compliance to align our programs with organizational objectives and risk tolerance, while also ensuring adherence to external regulations, standards, or legal requirements.

Align Risk Reduction with Compliance Requirements to Reduce Conflicts

Many organizations struggle to balance compliance requirements with addressing the riskiest vulnerabilities or exposures in their environment. Imagine knowing that Log4Shell is present and running on an externally facing server but compliance requires you to focus your energy on remediating other low-risk, non-exploitable vulnerabilities. That's a frightening thought, but it happens more often than you might think, especially in highly-regulated industries. This is often due to the fact that Service Level Agreements (SLAs) are tied to the severities produced by vulnerability scanners or the base Common Vulnerability Scoring System (CVSS) scores, as determined by CVE Numbering Authorities (CNAs). These risk scores are limited in their applicability because they do not incorporate the necessary threat and environmental context. CVSS can be so much more than just the base score.

CVSS provides the ability to enrich your risk assessment with threat intelligence and asset context specific to your organization. When determining the risk associated with a vulnerability, it is impossible to generalize the risk posed to every organization affected by that vulnerability. This is what makes layering in the threat and asset context so important. By doing so, we reduce the conflict between compliance and risk reduction activities, as they become more closely aligned (e.g., your riskiest vulnerabilities have the shortest SLAs).

‍Key Insight:

‍

Enriching the CVSS score is not just a luxury for mature organizations. In fact, the National Institute of Standards and Technology (NIST) encourages organizations to adjust CVSS base scores with additional risk factors, such as internet exposure, exploit availability, and compensating controls, to name a few. There is a wealth of information on how to enhance your CVSS scoring from the Forum of Incident Response and Security Teams (FIRST.org), the organization that developed and maintains the CVSS scoring system. Many scanning and prioritization tools assist in enriching your scoring or provide the ability to bring in additional context and inputs—though perhaps not as effectively as Zafran (SHAMELESS PLUG!).

If you're interested in evaluating the impact this can have on your organization, I recommend sampling a couple of your vulnerability CVEs (Common Vulnerability Enumeration) and using the CVSS calculator available at FIRST.org to add additional context. You'll likely be amazed at the discrepancy between the CVSS base score and the more accurate, context-enriched risk assessment. For example, a vulnerability might be rated as low-risk but becomes critical when running on an externally exposed asset without compensating controls.

By incorporating this enriched CVSS framework into your vulnerability management process, organizations can prioritize more effectively, ensuring that resources are focused on the vulnerabilities that pose the greatest real-world risk. This helps reconcile the often-competing demands of compliance and genuine risk reduction.

Critically ranked vulns are not the most exploited, so you should enrich base CVSS scores

Source: IBM X-Force Vuln Database

Patching is Proactive, Not Reactive

Do you take your car in periodically for preventive maintenance like an oil change or do you wait for the check engine light to come on before calling the mechanic? Hopefully you are a proponent of preventive maintenance. Think of patching in the same way. Patching is the preventive maintenance in this analogy, while the check engine light is the communication of a vulnerability from cybersecurity. In many organizations, application and asset owners wait for notifications from the vulnerability management team before deploying patches to address these vulnerabilities. The problem with this approach is that patching is not a detective control — it's preventive. If I scan my network on a monthly basis and a new vulnerability is published one day after you perform the scan, you may not detect that vulnerability for at least another 29 days. This is too long, considering the time it takes to weaponize and exploit vulnerabilities.

I know what you're thinking: why not just increase the frequency of scanning (I'm getting there!), but the reality is that this is an uphill battle in many organizations. Agents for agent-based scanning may not be deployed, authenticated scanning may be too intrusive during business days, and the business may not see the value. This is why it's important that your organization has documented policies, controls, and standards which require asset and application owners to patch at a frequency tied to the criticality of the asset or application.

‍Key Insight:

‍

Your next thought may be: well, how would they know what to patch if we aren't sending them vulnerabilities? Let's not let them off the hook so easily! Do you know when Microsoft releases patches? (Ever heard of Patch Tuesday? It's the second Tuesday of every month). They also likely know this. Additionally, vendors generally send advisories or give you the ability to sign up for notifications of available patches. In fact, these notifications generally include the same information provided for remediation from your vulnerability scanner. Many organizations also have automated patch management capabilities with the ability to send notifications when new patches become available.

At the very least, application and asset owners can go to the vendor's website on a periodic basis, say monthly, to see if any new patches have been released. It's not that hard.

I would be remiss if I didn't point out that asset and application owners should want to make sure patching is up to date. Not all patches or updates are for security, after all. Many patches are necessary to ensure performance is optimized, interoperability is enabled, or new features and capabilities are added. Available updates are not just a security risk; it's also a risk to your business.

So why not patch regularly to reduce the likelihood of incidents affecting your business?

Conclusion

Enriching risk assessment signals with threat intelligence and environmental context specific to your organization, you can prioritize and remediate the vulnerabilities most likely to be exploited. This more effectively aligns risk management with the intent of compliance requirements. Moreover, by transforming patch management from a reactive crisis to a proactive, preventative maintenance control, organizations may reduce mean time to remediate and enhance compliance management initiatives.

In the next blog in the Vulnerability and Exposure Management Survival Series, we will explore strategies to improve threat detection.


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.