Valid reasons for running unauthenticated vulnerability scans

Authenticated vulnerability scans are usually better than unauthenticated scans. But sometimes there are valid reasons for running unauthenticated vulnerability scans. Here are some reasons you might want to do that.

The main reason to run unauthenticated vulnerability scans is to limit the information you share with people outside your organization, such as auditors. But they are also helpful for preparing for penetration tests.

External scans

External scans should always be unauthenticated. You don’t want to open up your systems from the outside in order to authenticate. Always scan your external IP space with your provider’s cloud scanners to see the outside view. Then scan inside your DMZ with authentication to get the true view.

If a problem shows up in that unauthenticated external scan, investigate it thoroughly. It could be a false positive. But don’t assume. Scan the corresponding system from the DMZ and make sure the vulnerability is clear in that scan.

PCI compliance

Your scans that you submit for PCI compliance, to allow you to process credit cards, always should be unauthenticated, because that’s the standard. It’s not ideal, but it’s what the standard calls for, so don’t go beyond the standard. Give ’em what they want.

But the scan you submit to the regulating bodies and the scan you use internally don’t have to be the same thing. Work off an authenticated scan to clear up your vulnerabilities, then scan with a PCI profile and submit the clean PCI scan. This way you have security, not just compliance.

For auditors

Auditors will want to see evidence that you conduct vulnerability scans on a regular basis and fix them. Conduct unauthenticated scans for those purposes, and show the auditors those results, rather than your authenticated ones. Again, this is a case of using one set of scans for work, and another set to show the outside world. Using an unauthenticated scan limits how much data you share outside your company, since, if you’re doing a good job at all, your unauthenticated scans ought to be pretty clean.

For penetration testing

Pen testers may very well conduct a vulnerability scan as part of a pen test. These scans will be unauthenticated, of course, since the test would be over if you handed them credentials. In the runup to the test, make sure you have a clean unauthenticated scan, so you don’t make the pentester’s job needlessly easy. If they find MS08-067 right away, the game’s over. It’s fine if they find some false positives. But you don’t want them finding anything real, if you can help it.

To get both views

Some people like to scan a network to get both an unauthenticated and an authenticated view of their internal network. The unauthenticated view is less useful, but it’s a good feeling when your unauthenticated scan has more findings than your authenticated scan does. That means you’re good at patching, when you cross that threshold.

Personally, I don’t find the unauthenticated view that useful, because usually the people I deal with don’t have enough cycles to deal with one scan, let alone two. I use those scans for auditing and compliance but don’t generate them on a weekly or monthly basis like I would an authenticated vulnerability scan. I generate the unauthenticated scans 1-2 times per quarter, because that’s generally all I need.