Vulnerability scanning best practices

Last Updated on September 29, 2019 by Dave Farquhar

As a vulnerability management professional, I talk about vulnerability scanning best practices a lot. There’s a lot more to vulnerability management than just scanning, but if you don’t get scanning right, the rest of the program suffers.

I’m going to talk about a lot of technical controls here, but don’t forget the nontechnical side. People and processes have to support all technology.

Three things I wish everyone did

In working with 30 large companies over the course of about a year and a half, I noticed three things that make a huge difference. Failing vulnerability management programs do none of these things. I’ve never seen a vulnerability management program fail if it did all three.

  • Get training on the tool
  • Know your network architecture
  • Listen to your SME

Let’s talk about all three.

Get training on the tool

You can learn any tool by fumbling around in the user interface, but just because it seems to work doesn’t necessarily mean it’s the best way to do it.

All of the major security vendors offer training. Some charge for the training while others don’t. Either way, it’s essential. You can learn any of the tools by fumbling around in the user interface, but just because something seems to work doesn’t necessarily mean it’s the best way to do it.

Spend the time sitting through the on demand training if nothing else. You’ll learn the specifics of your tool. I don’t care if you already have advanced certifications. Your certifications are broad and vendor neutral. Your CISSP or your CEH gives you the background to decide whether I know what I’m talking about in a job interview or a product demo. Having one or even both of them does not make you an expert on vulnerability scanning.

Even if you are familiar with vulnerability scanning with another tool, it helps to get the tool-specific training. Every tool has subtle differences. I’ve seen customers repeatedly waste hours opening support tickets about things the documentation and/or training cover in depth, and waste more time every single month than it would take to just do the training.

Know your network architecture

There’s a reason why the CISSP exam spends so much time on networking concepts.

Vulnerability scanners are really good at finding the weird behavior in your network. The things that your computers will tolerate break when you go scan the entire network for vulnerabilities. Many people like to blame the tool, but I participated in a rip-and-replace project. What we found was the second vulnerability scanner uncovered another set of problems in the network and it didn’t work right at first either.

Your DNS, your Active Directory, and your routing need to be rock solid for vulnerability scanning to work right. Chances are you’ll need your networking team’s help to figure out the best settings to use for some things. Most security professionals don’t have enough networking background to go it alone on this.

That said, there’s a reason why the CISSP spends so much time on networking concepts. I once had to explain DHCP to another security professional. I don’t think I should have had to do that. If I ask another security professional if he or she is scanning their entire DHCP range, he or she ought to understand the question.

Listen to your SME

SMEs tailor their suggestions, but generally speaking, best practices are things that worked for dozens or hundreds of others.

Some sales people have a background in enterprise vulnerability scanning. Some have a background in sales. It really helps to bring in a subject matter expert to look over your system design early. It’s much easier to make adjustments early than years into a failing program. Some companies give you access to a SME as part of your agreement. Others charge, or refer you to an integrator. Either way, bring in an expert for a day to look things over and make suggestions, then listen.

I was once on a site visit with a SME and the customer didn’t like what he was saying. “What’s company X do?” they asked, bringing up the name of the biggest company they could think of. He answered. So then they asked another question. “What’s company Y going to do?” they asked, mentioning the biggest local company. The same thing. SMEs may tailor their suggestions based on what they’re able to know about your company’s architecture, but generally speaking, best practices are universal. They also worked for dozens or hundreds of others.

Authenticated scans vs. unauthenticated

You know you’re getting good at patching when the unauthenticated scan has more findings.

Unauthenticated scans poke a machine’s ports, observe the behavior, and report their best guess based on the response. This gives you an attacker’s view of your network. But you don’t want the attacker’s view. You want the inside view so you can actually fix stuff.

An authenticated scan runs interacts with the operating system to determine what’s installed and what’s missing. Some tools probe deeper than others, but no matter which tool you use, you’ll get better results with authenticated scans. They’re more accurate and far more thorough.

Some organizations resist authenticated scans because unauthenticated scans have fewer findings. You know you’re getting good at patching when the unauthenticated scan has more findings.

Scanning vs agents

Most major scanners now offer an agent. The agent reports in rather than having a scanner probe the machine. For workstations, and especially laptops, agents help with scanning and tracking. It’s easier on the network to run the agent, and it makes tracking and authentication irrelevant. Agents are always authenticated, and tracking becomes moot since the machine can identify itself.

It’s usually less work to deploy the agent than it is to fix the problems agents are designed to solve.

Scanning vs reporting

The other place I see people making mistakes is not properly distinguishing between scanning and reporting. Some tools make you marry the two things. Others don’t. Make sure you understand how to correctly structure your scanning to support the reporting that you need to do. If the two things are married, you may have to first figure out how you want to report, then structure your scanning to support it. Either the training or the SME should be able to cover this.

Here’s a real world example. Qualys will track a machine’s history over time. This is incredibly useful, properly implemented. But if you don’t choose the right tracking method, you can end up with a machine showing both Mac and Windows vulnerabilities on it. Once your patching team sees that and picks up on it, they won’t listen to you. Unfortunately, if you just deploy Qualys and accept all of the defaults, there’s about a 67% chance the default will be wrong for you. That’s why the training is so critical.

Exclude superseded patches

Just about every month, at least one Microsoft patch replaces an earlier patch. You only need to apply the later one. Microsoft tools only want to deploy the later one. If you exclude the earlier one from your reports, you gain credibility with your patching team. Qualys calls this the patch report. Other tools may not have this capability and you may have to rely on a reporting tool like Kenna to get that capability.

Visualize the data

Dashboarding the data using a tool like Kenna or even Splunk or visualizing it in a tool like Tableau can transform a vulnerability management program. There’s no point in scanning if you can’t find the actionable data in the results. To be successful, you need to be able to tell the patching team what they’re good at, so they can figure out what those things have in common and replicate that success elsewhere.

You may find you need two tools, one for pushing Microsoft patches and one for pushing third-party patches. Most organizations will resist that expense. This will help you prove if it’s necessary. A second patching tool is cheaper than becoming a Verizon or Mandiant customer.

Relationship management

Relationships aren’t a technical issue, but they are just as critical as all of the other vulnerability scanning best practices.

There’s one more important element in vulnerability scanning best practices, and it has nothing to do with anything technical. It’s relationships. Successful vulnerability management relies heavily on other teams. They feed inputs into the patching team. The patching team has to trust the data and trust that the vulnerability management has their back if something goes wrong. Both rely on a solid underlying network, so they need the help and support of the network team.

Share data with the teams. Use project managers and the organizational psychology department if they are available. Spread credit around generously when things go right.

I still meet former patch management colleagues for lunch sometimes, even though it’s been years since we worked together. Those guys will go through a wall for me if I ask them to, because I helped them. I got them credit for their work when things went right. I defended them when things didn’t go quite so right. I fed them data to put onto their annual reviews so they got better bonuses and promotions.

It went both ways too. Having a good, productive relationship with them helped when we needed other teams’ help. Whoever had the better relationship could reach out to the other team. Overall, the whole was greater than the sum of the parts.

A lone ranger vulnerability management team that just dictates never accomplishes much. But a collaborative, engaged vulnerability management team forms an effective first line of defense for the business, preventing much bigger problems before they happen.

If you found this post informative or helpful, please share it!