Table Of Contents

Quick Links

Introduction
  Definitions
    Assets
    Vulnerability
    Threat
    Loss
    Exploit
Why Vulnerability Management?
  The Attack Chain
  Breaking Attack Chains
    The Defender Advantage
    The Attacker Advantage
    Effective Defense
How Vulnerability Management Works
  Asset Management
  Discovering Vulnerabilities
    How Attackers Do It
    How Defenders Find Vulnerabilities
  About Vulnerability Scanners
    Vulnerability Checks (SCAP Feed or OVAL Data)
    Scan Engine or Agent (SCAP Validators or OVAL Scanners)
    Network Scans (Unauthenticated Scans)
    Agent Scans (Authenticated Scans)
    Other Scans
Using The Power of Vulnerability Knowledge
  You’ve Got A Vulnerability Inventory
  It’s a Big List - How To Begin
    Asset Criticality
    CVSS Scoring
    EPSS Scoring
  Sometimes, the scanner is wrong
  It’s OKAY to “Wont-fix” … but
    Accepting Risk must be Formalized
    Formalizing a Default Risk Accept
    Accepting Individual Vulnerability Risks
    Other Stakeholders
  Vulnerability Management For The Win
Next Steps
  What is Enough Security?
    Risk Assessment is Mandatory
    Adopting A Cyber Compliance Framework
    Cyber Hygiene Eliminates The Most Risk
    Advanced Security

Introduction

Before you can understand the nature of vulnerability management, it is first necessary to understand some related cyber risk concepts. Let’s start with a quick overview of concepts.

Definitions

Assets

An “Asset” is anything that is valuable. This is the thing that you’re trying to protect.

In cyber, we usually mean Data, Software or an IT component such as a physical device. An asset might also be an entire IT system (or collection of systems) such as “Payroll”. It might also be part of an outsourced business function like “Stripe” (or another payment processor).

Vulnerability

A vulnerability is a weakness in your asset or asset protection. This is the opening that allows an attacker in.

When evaluating cyber risk, we look at different types of vulnerabilities. Some are inherent in the way a system is designed or operated. Others exist due to weakness in how an overall system is designed or configured. The most pernicious are software vulnerabilities. These exist everywhere and are newly discovered every day. A well designed system can be secure on a Friday and an open door by Monday when a vulnerability opens in a critical asset.

Threat

A threat is any circumstance or actor that could have a negative impact on an asset, if not stopped in some way.

Most people are aware that threat actors exist in the form of cybercriminals, or even nation states. Through persistent effort or sophisticated methods, they can subvert cyber systems to make money or to cause other mischief. A threat actor can also be other types of situations, such as accidental data loss, fire damage, or all too frequently, a disgruntled or unwitting insider.

Loss

A loss is a negative impact or consequence of either damage or compromise to an asset.

Typically expressed in dollars, a loss measures the damage or cost of impact. Human time, reputational damage, and lost productivity can be particularly difficult to quantify, and thus losses are just as often ignored or accepted as cost of doing business (and this is the most expensive way to manage).

Exploit

An exploit is the act that leads to compromise and/or loss of an asset.

An exploit is the action that a threat actor or agent uses to take advantage of a vulnerability. Though technically "exploit" is a verb, it is also common to refer to specific pre-packaged code as “an exploit” (noun).

Why Vulnerability Management?

The Attack Chain

Let’s put all the above concepts together into a form that makes practical sense.

A Threat actor uses an Exploit to leverage a Vulnerability so as to create a Loss in an Asset.

Cyber professionals have a whole universe of highly specialized technical definitions and concepts just to describe attack chains for security analysis. The MITRE ATT&CK Framework is the predominant leader in this space and is intended as an up-to-date observation-based knowledge base of adversary tactics and techniques.

Breaking Attack Chains

A loss can be prevented by breaking the attack chain in order to stop a threat from acting.

The Defender Advantage

Since the attacker needs a series of circumstances or actions in a chain to create a loss, breaking the chain in any location can stop the attack.

The Attacker Advantage

To the advantage of the attacker, a defender needs to succeed by protecting every angle of potential attack, but an attacker only needs to succeed once. There are many routes that can be used to create an attack chain.

Effective Defense

An effective defense requires identifying the assets that need to be defended (Asset Management), and then discovering and eliminating weaknesses that can compromise those assets (Vulnerability Management).

Since essential cyber hygiene gained from asset and vulnerability management are the most cost effective measures (most bang for the buck), security architects and compliance standards all rate these functions as high priority essential functions.

How Vulnerability Management Works

Asset Management

Quick Side Note About Assets

Asset management is a complex topic. Highly effective security requires more consideration here.

In simple terms, one must understand that you can’t defend what you don’t know about. You need to make a list of what you’re trying to defend before you can measure risk or take defensive action.

For those of you considering implementing vulnerability management, you’re in luck. Many vulnerability management tools are paired with basic asset management features, and these tools are good enough for many organizations.

Discovering Vulnerabilities

Both attackers and defenders discover vulnerabilities by using automated tooling.

How Attackers Do It

Attackers utilize discovery tools with the intent of leveraging exploits they have access to via vulnerable software.

Open-source scan tools such as NMAP do a serviceable job of looking for vulnerable versions of known software. More sophisticated scan and attack automation tools like the open-source tool Metasploit are also common. A whole constellation of freely available attack tooling exists on the open web, while crimeware vendors operate illicit commercial subscription software ventures on the darkweb.

If you’ve ever watched a firewall log for a day, you’ll have seen a constant bombardment of this type of scan traffic.

How Defenders Find Vulnerabilities

Scanning for vulnerabilities should be done everywhere, as frequently as possible, in order to effectively defend against a continuous bombardment of attacks. Targets include external internet services, malicious webpages (or ads), and potential phishing victims.

In previous times, an enumerative vulnerability scan, sometimes called an “external penetration test” or “public IP scan”, was the best practice. These tests were commonly combined with the annual risk assessment cycle.

Since new vulnerabilities are discovered every day, the current best practice is now daily or weekly scanning. This means that it is necessary to deploy sensors to continuously monitor assets for vulnerabilities (and not wait around for the auditors to show up).

Regular monitoring gives the defender a chance to patch a newly discovered vulnerability within a remediation SLA (such as 14 days). For high profile vulnerabilities, faster patching is required.

About Vulnerability Scanners

Vulnerability scanners are built in a two-part architecture that should be familiar to anyone who has installed antivirus applications. There is a scanner, which is controlled by a scan database of known vulnerabilities. Most vulnerability scanning solutions combine these two technologies into a single product (but this is not always the case).

Unlike antivirus scanners, US NIST has standardized both the scanning technology and data feeds in a way that makes these products easier to compare. All modern vulnerability scanners leverage the same Security Content Automation Protocol (SCAP) specifications designed, and often tested, by NIST.

Vulnerability Checks (SCAP Feed or OVAL Data)

The cybersecurity industry collectively researches and trades in standard tests for software vulnerabilities. While all feeds that include a specific test should test equally, not all feeds have all tests.

Some SCAP data is freely available via the US NVD, but unlike CVEs (human readable reports of a vulnerability discovery), SCAP data has a high commercial value, and as such, vulnerability scan products have varying levels of access to these tests.

The best feeds are aggregated from as many sources as possible through license and information sharing agreements which would be impossible for individual organizations to acquire themselves. The quality of the feed should be a major factor in selecting a vulnerability scanner.

Scan Engine or Agent (SCAP Validators or OVAL Scanners)

While there are open source and freeware SCAP Validators, they should be referenced for research or academic use only. Real world environments have diverse environments, and uniquely commercial functionality is required to cover the operating systems, device types, and software platforms encountered in the wild.

Network Scans (Unauthenticated Scans)

Network scanners are run from sensors that are configured with unlimited access to the target network. These tools scan the entire network address space looking for target systems, then enumerate exposed services on each system to find vulnerabilities that are visible from the outside.

A network scan is important because it can find unknown devices, and it can scan devices that do not support more advanced scan types. While it’s recommended that everyone deploy network scanners, it’s important to note that the scan should be from the inside to find vulnerabilities across the network (not just at it’s edge).

Agent Scans (Authenticated Scans)

While an authenticated scan can be implemented in agentless fashion, regardless of method, it’s important that data is collected from inside a device (and not just it’s network surface). This can be done by distributing remote admin credentials to your network scanner, or more safely and commonly, by using locally installed scanning agents.

An authenticated scan, because it has local access, can find all software on the system and check it for vulnerabilities. This is necessary because some vulnerabilities are not network scannable (such as an old version of Chrome that can be hijacked via a malicious ad), or there may be a network service or website that can’t be distinguished as vulnerable or not-vulnerable from the outside.

Other Scans

When it comes to finding vulnerabilities, it's not always possible to design standardized tests. Organizations with self-engineered or customized software systems may need to have their source code inspected on a regular basis. Organizations should consider whether they need to implement a static (SAST) or dynamic (DAST) source code analysis tool.

Using The Power of Vulnerability Knowledge

You’ve Got A Vulnerability Inventory

Okay, so now you’ve managed to deploy vulnerability sensors and collect a vulnerability inventory…. Now what?

If you’re like most organizations and you’re new to this game, you’ll find many hundreds or thousands of vulnerabilities across your devices and network.

The first few weeks or months after implementing a vulnerability management system will be a triage effort of eliminating the most risk with the least amount of effort.

You’ll probably find that your list quickly dwindles as you address:

• Turning on automatic updates (because it’s never as automatic as you think it is)
• Removing old software (because cruft tends to collect, and the easiest way to address it is to exorcise it)
• The absolute most glaring critical issues requiring manual intervention

It’s a Big List - How To Begin

After a first pass of cutting the list down in size using these methods, you’re still going to be overwhelmed with vulnerabilities that require manual action, and this is where you want to start looking at how to prioritize a remediation project.

Asset Criticality

The first thing you should always look at is your highly critical systems (if you have any). If you’re already doing a good job of asset management, then you already know which systems are critical. If you have not yet done this, just ask yourself, is there a system that would be world ending if it was compromised? More than one?

Do you have any critical assets? Carefully clean these up first.

Unfortunately, even if you only care about your critical assets, you can’t stop there. Your other systems ultimately will interact with your critical systems, so you need to make sure to keep your whole house in hygienic condition.

CVSS Scoring

The Common Vulnerability Scoring System (CVSS) was standardized by a Special Interest Group of the Forum of Incident Response and Security Teams. Adopted universally by products and security organizations worldwide, CVSS provides a way to objectively classify “just how bad is it”.

While CVSS scores provide more information for specialized security analysts, the base score (or “CVSS Score”) is a simple number from 0 (informational only) to 10 (the barn door is wide open). CVSS Scoring is the most widely used method to prioritize vulnerability management

CVSS Base Scores can be simplified even further:

EPSS Scoring

You could just fix every vulnerability the day it is discovered of course, but most organizations find this goal not economically viable.

Also developed by a FIRST SIG (just like CVSS), EPSS leverages machine analysis of data points currently known about every CVE, and then factors in real world threat data found by security organizations all over the planet. This process generates a predictive model of how likely a particular vulnerability is to be exploited, and how that likelihood relates to all other CVEs.

It’s been estimated that by combining EPSS and CVSS scoring in remediation efforts, remediation efforts might be cut by as much as 78%.

Figure courtesy of the EPSS SIG

Learn more about EPSS and why it's joining CVSS in a triage scoring club of 2.

Sometimes, the scanner is wrong

It’s rare, but sometimes, after a deep dive on an issue, a technologist will discover that an identified vulnerability does not in fact apply.

This should never be confused with “we don’t think it’s very risky”, and should be reserved specifically for actual errors in detection logic.

In these cases, the technologist, security officer, and/or engineer should document the exception and exclude it from the scan results.

It’s OKAY to “Won't-fix” … but

Accepting Risk must be Formalized

Running any organization is a giant risk management exercise. A zero-risk business would have no revenue.

It’s perfectly okay to decide you’ve identified a problem and you’re not going to fix it because it would be too costly, or it might damage the business in some way. Making this decision is called “Risk Acceptance”, and is happily endorsed by auditors everywhere.

It’s important, however, to not confuse “Risk Acceptance” with a related, but totally unacceptable, concept called “Risk Ignorance”.

Formalizing a Default Risk Accept

Organizations may, with approval of the Chief Information Security Officer (CISO or ISO), identify a level of risk they accept by default, such as (for example) vulnerabilities with a CVSS of less than 5.

Accepting Individual Vulnerability Risks

To adequately accept risks that exceeds the organization’s default SLA:

• A system owner (or business owner) responsible for the business value, or who would be most affected by a loss, should formally take responsibility for the “won't fix” issues. The system owner must confirm that they are taking responsibility and that they have been adequately informed on any potential impacts.
• A technical or security professional should work with the system or business owner. There should be confirmation that they indeed have been coached.
• When both parties agree to a risk acceptance, it should be documented.

Other Stakeholders

It’s important to note that the system or business owner is not the only system stakeholder, and that risk rolls uphill.

For example, a business process owner (such as Payroll Manager) is responsible for the entire payroll systems. They would therefore automatically assume any risk accepted by a timesheet clerk. If the payroll manager disagrees with assuming this risk, then they must negotiate with their clerk to get the issue resolved. The Payroll Manager probably reports to the CFO or HR Director, and as department heads, one of them also assumes this risk and the responsibility be held accountable for the risk accepted by their employees.

All risk eventually rolls up to the chief executive (such as CEO), and cannot be further delegated. The chief executive is ultimately responsible for the entire business.

While it’s true that there will be systems designated as IT owned, if all your risk is sitting in the IT department, then your organization is not demonstrating acceptable enterprise risk management practices. IT is probably only the custodian for most systems, and the risks and benefits should accrue to individual business lines.

Vulnerability Management For The Win

Success in vulnerability management is most commonly measured by how well your organization complies with the target SLA (and how aggressive the SLA is).

After you’ve completed initial triage and introduced your teams to the vulnerability management workflow, it's possible to set a Vulnerability Management SLA (Service Level Agreement).

Here’s an example:

This SLA may be modified over time. Consider as good starting place an initial SLA of 30 days with a default accept of vulnerabilities below 9. As your organization continues to mature and invest in it’s vulnerability management practice, the SLA can be gradually lowered to decrease risk over time.

Next Steps

What is Enough Security?

It’s never possible to eliminate 100% of risk, so businesses must accept some risk of failure or loss.

It's justifiable to accept residual risk when you've covered all the commercially reasonable best practices in your industry for a company of your size.

Risk Assessment is Mandatory

One practice you can't reasonably skip is some sort of risk assessment. It's mandatory because you cannot credibly say you have enough security if you haven't studied what risks you face, and then evaluated whether your practices provide sufficient risk reduction.

Adopting A Cyber Compliance Framework

There are many security standards worth considering, and choosing one deserves it's own article. It's important to note that choosing a compliance framework is also in the mandatory category because:

• A standard framework ensures your security dollars are distributed in an effective way. It does no good to build a 20-foot castle wall but then leave the side door open. All good security standards address this by helping you target a level of investment first, and then instructing you how best to deploy your resources.
• Formalizing your security on a standard compliance framework also lets you communicate credibility to stakeholders both inside and outside your organization. By letting others know what framework you are following, you are signaling the approximate maturity of your security without disclosing details that an attacker could leverage.

Cyber Hygiene Eliminates The Most Risk

If you’ve done a good job of implementing cyber hygiene, then you’ve already eliminated most of your risk. You've laid the necessary foundations for more advanced defensive measures.

Advanced Security

For organizations with an appetite to use sophisticated and expensive methods to stop even more risk, it's time to consider other compensating controls, such as real-time anomaly detection, ongoing forensic analysis, and retained incident response specialists.

All of these methods require the groundwork achieved by implementing cyber hygiene, so if you are not yet performing effective vulnerability management, make sure to go back and do that first.