The Difference Between Vulnerability Management and Penetration Testing

We’re in the business of network-based security tools, so we bump into this issue a lot with our customers. It usually goes something like this:

• The Customer runs a routine vulnerability scan against their own network
• Their Sentinel blocks the scanning IP
• The Customer wonders why the scan didn’t work
• The Customer figures out what happened and asks us to whitelist the scanner’s IP range because we blocked their “pen test”
• We ask the question: “Ummm, wait, is this a vulnerability scan or a penetration test?”

It’s common in our industry for folks to use those two terms interchangeably. When most people say, “penetration test,” for instance, they really mean “vulnerability scan.” So, let’s spend some time cutting through this ambiguity and defining both these terms.

What Is Vulnerability Scanning?

The industry defines vulnerability scanning as the process of detecting and classifying potential points of exploitation in network devices, computer systems, and applications. Organizations commonly focus these scans on firewalls, applications, and other services that threat actors—internal or external—might try to use to gain unauthorized access to their assets. This involves looking for open ports, a lack of implemented patches, and other discernible security weaknesses on those parts of their infrastructure.

Vulnerability scans generally fall into one of four main categories:

• Unauthenticated scans that look for security weaknesses from the vantage point of someone lacking access. As such, these types of exercises may take an “outside-in” approach by remotely looking for misconfigured firewalls, vulnerable web servers, and similar flaws on a DMZ or across the network.
• Authenticated scans that adopt the perspective of an agent running on an in-scope machine. These scans therefore target application, operating system (OS), and similar vulnerabilities that affect servers, workstations, and other network hosts.
• Web application scans that look for misconfigurations, insecure coding practices, and known software vulnerabilities within an organization’s applications.
• Database scans that evaluate database applications and services for well-known security issues such as SQL injection attacks.

Vulnerability scans are most effective when they operate as part of a broader vulnerability management program. Such an initiative uses what the Centers for Disease Control and Prevention (CDC) calls a vulnerability management life cycle to go beyond just identifying computer system security weaknesses. This tracks pretty closely with “cyber hygiene” identified in the CIS Controls Implementation Group 1, but defines the life cycle across the following six stages:

1. Discover – To begin, organizations need to first build an inventory of all hardware and software that’s connected to the network. It’s true what they say, “You can’t protect what you don’t know about.” Building an up-to-date asset inventory isn’t always possible with manual discovery tools alone. (Think shadow IT where an employee installs an app to improve their workflow.) That’s why many organizations also add passive asset discovery capabilities into the mix.
2. Prioritize – Not every asset requires the same level of treatment. For instance, a critical national infrastructure (CNI) organization might be running legacy systems in their industrial environment that doesn’t receive patches anymore or that can’t receive software fixes remotely. Meanwhile, another entity might elect to store their intellectual property on a segregated endpoint device for safekeeping. Organizations need to know what assets they’re running so that they can categorize them based on their business value and the risk posed by a vulnerability event.
3. Assess – At this stage, organizations need to set a baseline risk profile for their assets. They can then use those profiles to orchestrate their remaining vulnerability management steps.
4. Report – Using the level of business risk associated with their assets, organizations can document a security plan for addressing known vulnerabilities. This phase may also involve monitoring for suspicious activity and conducting a vulnerability scan.
5. Remediate – Here, organizations prioritize and fix known vulnerabilities according to business risk. They may also implement mitigating controls and document their progress in addressing their assets’ known vulnerabilities.
6. Verify – Organizations conclude by conducting an audit to verify whether they have eliminated the risks posed by the vulnerabilities they previously identified.

Of course, organizations are always bringing on new assets, and security researchers are constantly finding new security issues. These factors highlight why vulnerability management needs to be an ongoing process for organizations. Along the way, organizations might decide to change the metrics surrounding their vulnerability scans. They might classify some of their existing assets as out of scope and add new ones in, for instance. Similarly, they might decide to modify the frequency with which they scan for vulnerabilities.

What Is a Penetration Test?

In the words of CSO, a penetration test (aka a pentest) is a “simulated cyber attack where professional ethical hackers break into corporate networks to find weaknesses … before attackers do.” Pentests are like vulnerability scans in that they come in different types. Provided below are the three most common types of penetration tests, as identified by Infosec Institute.

• Black-box testing – In this type of scenario, the ethical hacker or “pentester” lacks any knowledge of the organization’s target system(s) prior to the start of the exercise. It’s therefore up to them to see what vulnerabilities they can find to move from outside the network into the client’s targeted systems.
• Gray-box testing – This type of penetration test involves a pentester who has access and knowledge levels that are commensurate with the average user. With this limited knowledge of the network, the pentester can focus their efforts on assets that hold the greatest business value and pose the greatest risk to the client.
• White-box testing – By far the most time-consuming penetration test, a pentester needs to sift through available source code, network architecture documentation, and other information to identify potential points of access into their client’s systems. They can use static code analysis, debuggers, and other tools to help them towards that end.

With this understanding, several differences between penetration tests and vulnerability scans emerge. The first variance is the basis that organizations use to conduct these exercises. As noted by BMC, vulnerability scans are list-based in that they use an inventory (or list) of authorized assets and a list of known possible vulnerabilities. This is different from penetration tests’ focus on goals, i.e., a pentester discovering and exploiting points of weakness to see how deep they can drill down into in-scope systems.

That part about in-scope systems is key. Penetration tests take a targeted approach in that they evaluate only certain systems which the organization has designated for a specific test. As such, pentests can involve a fair amount of time and customization on the part of the evaluators. By contrast, vulnerability scans consistently use tool-based methods to uncover a wide range of risks. Such exercises therefore tend to use more automation, consume less time, and cost clients less than a penetration test.

How Sentinel Relates to Vulnerability Scanning and Pentesting

In our experience with both vulnerability scans and penetration tests, our customers usually whitelist the IP ranges of the testers on the Sentinel Outpost. They do this for two reasons. First, the Outpost usually blocks customers’ initial probes of their network. Second, the goal of these tests is to find vulnerabilities on the network and remediate them, not necessarily to test the efficacy of the Outpost itself.

After taking that step, many customers then embrace a “set-it-and-forget-it” mindset to block malicious traffic going forward. But it doesn’t need to be that way. If customers look at the events that are tripping on Sentinel, for instance, they will notice patterns. They might see attackers attempting to exploit X, Y, and Z like Remote Desktop Protocol (RDP) vulnerabilities. They can then say to themselves, “We getter go fix those things.”

In other words, customers can use Sentinel to spot the same things that show up in a vulnerability scan. It is not a replacement for vulnerability scanning or penetration testing. But it’s a complement to it as part of a broader network detection and response (NDR) strategy.

Learn how to improve your network visibility of security weaknesses with Sentinel IPS.

‍