Vulnerability Scanning - authenticated scan vs unauthenticated


Imagine you have the choice between opening a box and looking inside, or shaking and prodding it from the outside to guess what it may contain. Imagine further, that if you are unable to successfully guess the contents of the box, something bad may happen, something damning, damaging or dangerous. Which of the two choices would you decide to take?

Unauthenticated testing alone will not fully simulate targeted attacks on your application or system. Although unauthenticated scans will show weaknesses in your perimeter, it will not show you what the attacker will exploit once breaching your perimeter: weaknesses within your network.

Authenticated scans allow vulnerability scanners to use privileged credentials to dig deeper into a network and detect threats around weak passwords, malware, installed applications, and configuration issues. They are able to simulate what a user of the system can actually do. By finding and fixing internal security holes, you can prevent an attacker who breached your perimeter defenses from moving deeper within your network.

By configuring your vulnerability scanner(s) to log into the hosts you're testing, you're going to see the rest of the story -- the side of security that's often ignored in the name of saving time or money, or because of its complexity. Yes, the truth of the matter is that running authenticated scans will indeed take more time, but the payoffs in terms of vulnerabilities discovered (and, ultimately, risks mitigated) can be tenfold compared to what you discover through an unauthenticated scan.

Here are five things security teams can do in order to successfully prepare for, run and get the most out of the results of an authenticated vulnerability scan:

1    . Know in advance which systems you're going to scan with authentication. This might include all Windows and Linux-based systems or a limited subset of computers (i.e., servers or workstations). Be sure to also consider scanning Web applications, databases and any network host that allows or requires authentication via protocols such as Telnet, FTP, SSH and SNMP.
Many commercial vulnerability scanners, like Nexpose and LanGuard, provide the ability to scan through various means.

2    .Decide what user role level (or levels) you want to scan with. I recommend scanning with administrator or root-equivalent credentials at a minimum; you'll find the most flaws this way. However, by scanning with different user roles -- such as a manager-level role or basic user role -- you can get a better idea of what each user group can see and exploit.
The more user roles you test with, the better your results, to an extent (the law of diminishing returns will kick in at some point). You'll know when enough is enough when you see that your results are no longer varying by permissions.

3    . Set up the user accounts for authenticated scanning so no password change is forced upon initial login (a common setting in Active Directory Group Policies and some Web applications). If you forget this, the first time your scanner logs in it will be prompted to change the password -- which, of course, it won't be able to do. You may be unaware that this has taken place and then proceed with the scan. Several minutes -- or more likely hours -- later you'll realize that authentication didn't work and you'll have to start your scans over. With Web vulnerability scanners, you'll likely have to create a login macro that you'll be able to test.
For some reason, most network vulnerability scanners don't provide an option to test your login credentials before you start scanning. The only two scanners I've ever known to have this feature are the old Harris STAT Scanner and Rapid7's Nexpose. It may seem trite, but this feature can save you massive amounts of time and hassle over the long haul.

4   . Authenticated vulnerability scans of network hosts are fairly benign. That said, they can be problematic for production environments, especially when scanning Web applications. Regardless of what you're scanning, CPU, disk and network cycles will be consumed, log files and databases can get filled up, user accounts can get locked out, and so on.
I recommend running authenticated scans on one or two systems at first to see what the side effects are going to be before branching out and scanning hundreds or thousands of systems.

5   . The security vulnerabilities uncovered during authenticated scans can be downright overwhelming, especially when viewing the results in a traditional PDF report. I've found that generating HTML or spreadsheet reports sorted by vulnerability is the best way to view the findings.
When you sort your results by vulnerability, you'll save a ton of time by being able to see things more simply and clearly (i.e., which hosts or webpages are affected by each vulnerability) and can generate your final report or remediation plans more easily that way, rather than looking at one host at a time.


REFERENCES
A-Z of Vulnerability Management: A - is for Authenticated Scanning 
https://www.securityweek.com/z-vulnerability-management-authenticated-scanning
Vulnerability Scanning: Is Unauthenticated Scanning Enough? 
https://thycotic.com/company/blog/2014/10/14/vulnerability-scanning-unauthenticated-scanning-enough/
Five steps for improving an authenticated vulnerability scan
https://searchsecurity.techtarget.com/tip/Five-steps-for-improving-an-authenticated-vulnerability-scan