Open Mobile Menu


How Much Scanning Is Enough?

Views: 2407

Written By: Stephen Haywood March 18, 2016

When we do a penetration testing job, we typically use both Nmap and Nessus to scan the target devices for potential vulnerabilities. These scans provide us with a good understanding of the target devices and many of the common vulnerabilities present on those devices. Nmap and Nessus do not provide the whole picture but are a good starting point. Recently though, we had a client where our typical network scanning caused major issues. We were only able to run limited scans, but we were still able to find a number of severe vulnerabilities that could result in unauthorized changes to the client's systems. At this point, we were satisfied that we had completed the penetration test to the best of our abilities and had produced an actionable report with remediations that would result in a significant improvement in the client's security posture. Unfortunately, the client was not satisfied with our work because we were unable to complete the Nessus scans against the target devices. The client requested that we spend time working with their network engineer to determine why the scans were causing network outages and run the full Nessus scans.

This situation begs the question, how much scanning is enough? The answer is it depends. I have conducted penetration tests where an open NFS share contained plaintext credentials to the primary database. The NFS share was identified as part of a larger Nessus scan but could have been identified by scanning for a single port. I’ve run into similar situations with vulnerabilities like MS08-067, anonymous FTP servers, and open SMB shares. All were found as part of a thorough scan but could just as easily have been found by scanning a single port.

When engaging a company to conduct a penetration test, ask them about the typical network scanning process they use. It could range anywhere from doing the minimum scanning needed to identify potential break in points to doing thorough vulnerability scans on all of the target devices. When trying to determine how much scanning is enough for your penetration test, keep these things in mind.

  1. What level of thoroughness do you want or need in the scans? Do you want a thorough scan that lists as many vulnerabilities as possible and a report that shows the impact of those vulnerabilities or do you only want to know that the penetration tester was able to gain control of specific systems and how? Personally, I would want to know about as many vulnerabilities as possible so I can fix them or at least be aware of them.
  2. What does the Scope of Work document say about scanning? Read the Scope of Work document to determine if the penetration testing company will spend a certain amount of time attempting to penetrate the network and provide a report of the findings or if they will thoroughly scan the network and attempt to verify as many of the identified vulnerabilities as possible in the time allotted for the test. If the Scope of Work doesn’t match your expectations then have it modified.
  3. How much testing time are you willing to buy? Thorough network scans require time, especially if there are network issues that interfere with the scanning. If you expect to have thorough network scans completed for each target device then expect to allot an appropriate amount of time to the project. If issues arise during the network scans you may have to adjust your expectations or add more time to the project.

At AppSec Consulting we prefer to write the Scope of Work to allow time to conduct both Nmap and Nessus scans of at least the default ports. Using both tools saves us a lot of time during the enumeration phase and provides our clients with a better understanding of their security posture. These scans do not typically present a problem with intrusion detection systems because our clients white list our scan servers. By using a commercial vulnerability scanner and white listing our scan server, we can spend less time scanning and more time exploring the damage that could be done by an attacker. With that said, it is always our goal to meet the client’s expectations so please let us know what you want so that we can tailor our scope of work to your expectations.

A number of penetration testers will argue that real attackers do not use Nessus and do not have their scan servers white listed. I would counter with the fact that real attackers are also not time constrained. Truthfully, there are many paths an attacker or penetration tester can take to enter your network and they only need to find one of those vulnerabilities. The real question is what do you want to know at the end of your penetration test, a detailed description of the one path the tester took or a list of many potential paths?

Stephen Haywood

Stephen Haywood, aka AverageSecurityGuy, is a Senior Penetration Tester with AppSec Consulting with 14 years of experience in the Information Technology field working as a programmer, technical trainer, network operations manager, and information security consultant. He holds a Bachelor of Science in Math, the Certified Information Systems Security Professional (CISSP) certification, the Offensive Security Certified Expert (OSCE) certification, and the Offensive Security Certified Professional (OSCP) certification. Over the last eight years, he has helped improve the network security of many small businesses ranging in size from ten employees to hundreds of employees by offering practical, time-tested information security advice.

In his off hours, Stephen created a number of security tools including the Prometheus firewall analysis tool and a set of penetration testing scripts used by testers worldwide. In addition, Stephen has made multiple contributions to the Metasploit exploitation framework including, auxiliary, exploitation, and post exploitation modules. Finally, Stephen created and delivered high-quality security training, spoke at multiple security conferences, and self-published an introduction to penetration testing book.

read more articles by Stephen Haywood