I think the best way to differentiate between them is that a Vulnerability Scan is an assessment of your security status, whereas a Penetration Test has a specific goal of penetrating a system. You tend to find that Vulnerability Scans are highly automated, and can be run on a daily/weekly/monthly basis to ensure that what was secure last week is still secure now. Penetration Tests tend to be more human driven, a person or team has been given a goal and it is up to them to try and get to that goal. They will normally use scanning and automated tools as part of that job, but their role is not to give you an assessment, server by server of potential vulnerabilities. Their job is to poke around until they find a weakness and then exploit it. It is therefore a task that is normally performed infrequently.
You often see in an environment the vulnerability scans running in an automated fashion, whereas a penetration test is done annually (or as part of a large code release).
Vulnerability Scans are normally broken into two types, internal and external. An external scan is going to come in the same way as your inbound internet traffic, it will pass through the firewalls etc and ultimately hit a web server. The job of the scan is to identify what it can of the infrastructure and application and report potential vulnerabilities. This could be along the lines of ports being left open that are common attack vectors, or basic SQL Injection and Cross-site scripting issues.
For a more detailed examination, you need to do an internal scan. This is launched from within the environment, and can be configured to have the authentication credentials to actually log onto the servers. This allows the scan to look for application and file versions, configuration settings etc etc. This gives you a far more detailed view than an external scan can ever achieve.
It also raises the bugbear of vulnerability scanning - false positives. The scanner has a set of rules that it is checking for. These rules cover off a wide range of potential issues, from being able to check that a server is fully patched to which ports are open. Once the scan runs, your job is then to determine which vulnerabilities are an issue and need to be fixed, and which not. You may have a very good reason to have specific ports open, or run an old version of an application. One thing that often causes confusion is that in some cases, even if a patch has been applied, the system may still flag it as potentially vulnerable. This is often because the old file is still on the system. You may have run the patch, but if the old vulnerable file is still on the filesystem, it ‘could’ be referenced by code directly. The vulnerability scanner cannot make that decision, you need to.
As you can see with Vulnerability Scanning, one of the key elements is how the system deals with false positives. You need be be able to flag them up as not being an issue - and that needs to remain between scans. Otherwise you have to re-check all the false positives every time.
Another potential gotcha is that you often need to warn your infrastructure provider and your own teams. A vulnerability scan looks a lot like an attack - your infrastructure provider may block it (or even block you as you are launching the attack!). For example on AWS you need to complete this form https://aws.amazon.com/security/penetration-testing/ identifying where the scan is coming from, and what it is being targeting before you start.
One sub-note to this is the PCI Scan that has to be performed as part of PCI. This is a set of tests defined by the PCI Organisation, that have to be performed against your environment by an approved scanning vendor. It is effectively a external scan that has been defined by the PCI Organisation with a prescribed way of dealing with false positives and a report that you get sent at the end. For more information about PCI take a look at the PCI section of our website, download our PCI cheat-sheet or take a look at our PCI webinar on Brighttalk
At Alert Logic, the vulnerability scanner is included free as part of the Threat Manager IDS system. For us, we see this vulnerability scanner as covering two different roles. Firstly is the traditional role - helping you identify the potentially vulnerable parts of your system. It also has a second role, it gives us context for determining the criticality of an attack. If you are running an un-patched IIS server, and we see an exploit targeting that vulnerability; that is critical. Our security team will escalate that hard and fast. However if we know you are patched, that is a different story. We are not going to get anyone out of bed at three in the morning for a failed exploit. As an accredited PCI scanning vendor, we can perform the full PCI scans for you, as well as internal and external scans.