Vulnerability Assessment vs. Penetration Test
There are several perspectives on what the difference is between a vulnerability assessment versus a penetration test. The primary distinction, appears to be that many hold the belief a comprehensive penetration test consists of identification of as many vulnerabilities as feasible, while others hold the belief that Penetration Tests are objective-oriented and primarily don’t concern themselves with other vulnerabilities might exist.
We hold the latter belief, and in this blog by AICorespot, we try to persuade you as to why you should hold that belief as well.
Language is critical, and we have two terms for a purpose. A vulnerability assessment is a comprehensive compilation of a cumulative listing of vulnerabilities. If there isn’t a obvious, communicable distinction between this evaluation variant and a penetration test then we ought not to be leveraging independent terms. This distinction is a real thing however, and it’s a critical one.
Vulnerability assessments are developed to provide a prioritized listing of vulnerabilities and are targeted at clients and end-users who already comprehend they are falling short in terms of their security efforts. The client is aware of the hiccups they are facing and merely need assistance in identification and prioritization.
The more issues detected, the rosier the scenario, so obviously a white box strategy should be embraced when possible. The deliverable for the evaluation is, most critically, a prioritized listing of identified vulnerabilities (and usually how to remediate).
Penetration tests are developed to accomplish a particular, attacker-simulated objective and ought to be requested by clients who are already at their ideal security positioning. A common objective could be to access the contents of the prized client database on the internal network, or to alter a record in an HR system.
The deliverable for a penetration test is a report of how security was breached in order to attain the agreed-upon objective (and how frequently to remediate)
A Physical Analog
A good analog for this concept is a Tiger Team operating on the behest of the State, like Richard Marcinko used to run with Red Cell. You can imagine the magnitude of their missions, stuff like obtaining control of a nuclear submarine and bring it out into the bay.
On a typical day, he’s being debriefed following a successful mission where he penetrated (no pun intended) via the east fence, and if an individual were to question him regarding the security of the western portion of the facility, his answer would be simple.
“We didn’t even bother. We scoped out an opening on the east-facing fence and we went after our target.
If the individual performing the debrief were to reply with, “You did not check the other fences? What type of security test is this if the case is that you didn’t bother checking the totality of the fences?” – the response to this would be equally direct.
“Listen up, bro. We could’ve penetrated in a million ways.
- Burrowing under the fences, avoiding them totally
- Parachute in to the facilities
- Infiltrate an incoming truck
Those are just some of the ways. The request was to steal a sub, and that’s exactly what happened. If your goal is to obtain a detailed listing of all the various ways in which your security is ineffective, hire an auditor, not a SEAL team.
The Question of Exploitation
Another error individuals commit when talking about vulnerability assessments as opposed to penetration tests is to pivot immediately to exploitation. The essential narrative is this:
“Identifying vulnerabilities is a vulnerability assessment, and their exploitation is a penetration test.”
This is the wrong perspective.
Exploitation can be visualized as a slider bar ranging from none and full, which can be harnessed both in the case of vulnerability assessments and penetration tests.
Even though a majority of hardcore pentests lean in the direction of displaying instead of telling (i.e., primed towards the exploitation side), it’s also the scenario that you can usually display that a vulnerability is real without complete exploitation.
A penetration testing unit might be able to merely capture images standing next to the open safe, or to show they have complete access to a database, etc., without actually taking the full set of actions that a malicious actor could. And vulnerability assessments can move along this scale in addition to any subset of the list of issues/problems identified.
This is a process that ought to be time-intensive, but exploitation does not, by definition, move you out of the realm of vulnerability assessment. The only critical attributes of a VA vs. PT are list-orientation vs. goal-orientation, and the question of exploitation is merely not aspect of that calculation.
The idea that penetration tests consist of vulnerability assessments
It’s also wrong to state that penetration tests always consist of a vulnerability assessment. Remember that penetration tests are objective-based, implying that if you accomplish your objective then you have a success on your hands. So, you are probably performing something like a vulnerability assessment to identify a good vuln to compromise during a pentest, but you could just as simply identify a vuln in the span of twenty minutes that helps you to attain your objective.
It is precise to state, putting it differently, that penetration tests are reliant on identifying single or additional vulnerabilities to take advantage of, and that individuals typically leverage some variant of procedure to systematically identify vulns for that reason, but as they cease when they have what is required, and don’t provide the client a total and prioritized listing of vulnerabilities, they didn’t actually perform a vulnerability assessment.
- Client maturity level: Low to medium. Typically requested by clients who are already aware that they have problems to tackle, and require help beginning.
- Objective: Obtain a prioritized listing of vulnerabilities in the environment so that remediation can happen.
- Focus: Breadth over depth.
- Client maturity level: High. The customer holds the belief that their defence mechanisms are robust, and wishes to evaluate that assertion.
- Objective: Determine if a maturity security posture can withstand an intrusion incident from a sophisticated attacker with a particular objective.
- Focus: Depth over breadth.