When you’re looking at a vulnerability scan, you may find several types of findings on the report. Two of them are confirmed and potential vulnerabilities. Let’s take a look at confirmed vs potential vulnerabilities in Qualys.

Potential vulnerabilities are incomplete, in that they show an indication of vulnerability, but not enough for Qualys to confirm it. Confirmed vulnerabilities are more reliable, as Qualys was able to pinpoint a vulnerable file or setting on the system. In some scan results, Qualys refers to potential vulnerabilities as “practice.” As far as Qualys is concerned, practice and potential are interchangeable terms.

What is a confirmed vulnerability?

Confirmed vs Potential vulnerabilities in Qualys

I frequently encounter people who want to ignore potential vulnerabilities in Qualys, but that’s a mistake. The most useful QID that Qualys has is QID 90126, and it’s a potential. By fixing that one, I once cut the vulnerability counts at a large company by 50 percent.

When Qualys is able to determine convincingly that a vulnerability exists on a system, it marks the vulnerability as confirmed. This means Qualys observed a condition in the system that responds to an exploit condition, or that a file version or hash matches a known vulnerable version of the file, or that a necessary configuration to enable the bugfix is missing even if the file itself is up to date.

The results field in the scan results will tell you the condition Qualys observed. If the problem is based on a file being the wrong version, Qualys will tell you the file it observed and the version it was looking for. If it observed the behavior on a port scan, the results field is less useful, as it won’t have remediation information.

Authenticated checks are frequently more reliable than unauthenticated checks, but it depends on the vulnerability.  Authenticated checks also tend to be less intrusive. So I prefer to use authenticated scans whenever possible.

How to turn potential vulnerabilities into confirmed in Qualys

Usually when Qualys flags a vulnerability as potential or practice, it’s an authentication issue. Qualys may not have authenticated and just identified one or more conditions that suggest a vulnerability is there. Backported fixes may trip up Qualys unauthenticated scans and result in potential vulnerabilities, though Qualys has no trouble verifying the presence or absence of backported fixes in an authenticated scan.

Another possibility is Qualys may have authenticated but not had enough rights to read all of the files or the system registry. Ensuring that your Qualys account has administrator rights (in Windows) or sudo access on Unix and that the remote registry service is enabled will usually give Qualys enough rights to either confirm the vulnerability is there, or confirm it’s not there and remove it from the report. If you can’t enable remote registry, enable the dissolvable agent in the scan profile. The dissolvable agent allows Qualys to query the registry without having to use the remote registry service.

Looking at the results field in your authentication QIDs in the system can give you clues about permissions issues or other problems that can keep Qualys from doing what it needs to do. Also look for and check out QIDs 70028 and/or 70053, in addition to 100515, if you find them. Insufficient permissions don’t always cause Qualys to flag a login as failure. But they can flip confirmed vulnerabilities to potential, and drop your accuracy.

If you have authentication issues due to an unhealthy active directory, consider using the agent. It’s usually easier. The agent automatically authenticates and configures itself to have sufficient permissions to do its checks when you install it. The Qualys agent has tons of benefits.

When a scan authenticates and has proper permissions, Qualys false positives are surprisingly rare.

Qualys potential vs confirmed vulnerabilities on databases

And remember, when checking a network based service, such as Microsoft SQL or Oracle, you have to authenticate to that service as well as the OS. If you see a ton of potential vulnerabilities on the database, be sure to configure that authentication, and permissions. With insufficient permissions or lack of authentication, you can get excessive potential vulnerabilities on database ports.

These can be the hardest issues to sort, and you’ll need help from a DBA, but the results are worth it.

Should you fix potential vulnerabilities?

One of the biggest questions when it comes to confirmed vs potential vulnerabilities is whether you need to fix potentials. It’s very common for people to focus on confirmed vulnerabilities. Usually confirmed vulnerabilities are easier to fix since Qualys can point you toward the problem, and the fix action.

It’s best to investigate potential vulnerabilities, but better still, ensure authentication is all in place and working well. That reduces the number of potentials you see. Fix the underlying issues, don’t ignore the potentials. The Qualys product SMEs are fond of saying Qualys doesn’t just find vulnerabilities, it finds whatever else is wrong with your network. Or even your processes. They’re right.

Would I investigate a high-severity potential before fixing a low-severity confirmed? Yes. Yes I would. Especially if you have one Qualys potential vulnerability in particular.

The best Qualys potential vulnerability QID

And here’s the one I’d start with: One of the most useful findings Qualys has is QID 90126, the pending reboot. It’s a potential. It’s super easy to make that one go away: Reboot the system. And then other good things happen. The reason this update comes up is because you have partially-applied updates on the system. Fixing QID 90126 by rebooting will fix those other things. Ignoring potential vulnerabilities throws out the most useful QID Qualys has.

The presence of potentials often points to other things going on. Rather than looking the other way, it’s better to look for root cause and correct it. I once reduced the vulnerability count at a large megacorporation by more than 50 percent by giving the system administrators a list of all the systems with QID 90126 and asking them to reboot those systems a couple of times that month. That was years ago and the people involved still talk about it.

It’s worked everywhere else I’ve tried that, though the results will vary, depending on how big the backlog of pending updates is. But I’m sure there are other 50% reductions out there, just waiting for someone to discover them.

If I could teach every security analyst in the country three things, it would be how to find pending reboots, how to use ETL files, and how to force a Microsoft update. Knowing those three things can be enough to make you a high-performing vulnerability analyst.