Confirmed vs potential vulnerabilities in Qualys

When you’re looking at a vulnerability scan, you may find several types of line items 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?

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 to 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. Pay attention to QIDs 70028 and/or 70053, in addition to 100515. Insufficient permissions don’t always cause Qualys to flag a login as failure.

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

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.

Would I investigate a high-severity potential before fixing a low-severity confirmed? Yes. Yes I would.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: