|
Penetration Testing vs. Vulnerability Scanning
I am often
amazed at how a vulnerability scan is sold as a penetration test.
On more than one occasion, I have audited a financial
institution that has a 300-page “penetration test” report that
consists of nothing but a listing of vulnerabilities discovered by
some vulnerability scanning tool.
Here’s one first clue: if your penetration test report is
longer than 10 pages, you’ve probably got a vulnerability scan.
A vulnerability scan (or
even a vulnerability assessment) looks for known vulnerabilities in your systems
and reports potential exposures.
A penetration test is designed to actually exploit weaknesses in the
architecture of your systems.
Where a vulnerability scan can be automated, a penetration test requires various
levels of expertise within your scope of systems.
In short a technician runs a vulnerability scan while a hacker performs a
penetration test.
This is not to sell
vulnerability scans short.
Vulnerability scanning is a necessary part of maintaining your information
security and should be used more often than I am seeing in the field.
For example, every new piece of equipment that is deployed should have a
vulnerability scan run against it and another approximately monthly thereafter.
Baseline reports on key equipment should be maintained, and changes in
open ports or added services should be investigated.
In this way, a vulnerability scanner can be used as a detective tool to
alert an information security program when unauthorized changes have been made
to the environment.
Some common and decent
vulnerability scanners are:
 |
Nessus |
|
GFI LANGuard |
|
Retina |
Now, penetration testing is
a little different. It could
be better described as “looking for ways to exploit the normal course of
business.” For example,
a company may use a software product that transmits a password for back-end
processing. Or the CEO may transmit
his password to his web-based mail, the same password he uses to logon.
Alternatively, an obscure database may have a listing of unique users
with passwords that never change and are good on the directory service.
Perhaps the switches themselves can be compromised to send unencrypted
data to a workstation, data that has personally identifiable information.
As a penetration tester, I have run into all of these exposures and
more, the symptoms of which cannot be detected by a vulnerability scanner.
The tools used for a
penetration test are varied and dynamic, but it is not the tool that performs
the test; rather it is actually the tester.
You want to select somebody who has had some breadth and depth of
experience in IT and preferably your business.
You will want someone who is a bit of a geek and is willing to think
outside the box. But most
importantly, you want someone with an independent streak who will not hesitate
to show how and why you were compromised.
In fact, independence is a listed requirement for all regulations that
expect regular penetration (as opposed to vulnerability) testing.
The deliverable of a
penetration test is the penetration test report.
This report should be short and to the point.
It may have a 100-page appendix listing vulnerabilities that had
attempted exploits, but the main body of the report should focus on what data
was compromised and how. A
listing of false positives or vulnerabilities that were exploited but resulted
in no data loss is extraneous and should be shown in the appendix.
For a penetration test report to be useful, it needs to provide the
customer with the actual method of attack and exploit along with the value of
the data exploited. If requested, possible solutions can be mentioned.
Leave the long list of possible exposures to the vulnerability scans
where they belong.
Here is a table help
understand the difference between Vulnerability Scan & Penetration Test:
|
|
Vulnerability
Scan
|
Penetration Test
|
|
How often to run
|
Continuously,
especially after new equipment is loaded
|
Once a year
|
|
Reports
|
Comprehensive
baseline of what vulnerabilities exist and
changes from the last report
|
Short and to the
point, identifies what data was actually
compromised
|
|
Metrics
|
Lists known
software vulnerabilities that may be exploited
|
Discovers unknown
and exploitable exposures to normal business
processes
|
|
Performed by
|
In house staff,
increases expertise and knowledge of normal
security profile.
|
Independent
outside service
|
|
Required in
regulations
|
FFIEC; GLBA; PCI
DSS
|
FFIEC; GLBA; PCI
DSS
|
|
Expense
|
Low to moderate:
about $1200 / yr + staff time
|
High: about
$10,000 per year outside consultancy
|
|
Value
|
Detective
control, used to detect when equipment is
compromised.
|
Preventative
control used to reduce exposures
|
Ideally, you will want to run a penetration test once a year.
Vulnerability scans should be run continuously.
Vulnerability scans should be run by your own staff, so that they can
build up a baseline of what is normal for your information security program.
Penetration tests should be run by an outside consultancy so that the
benefit of independence and “outside eyes” can be garnered.
Together penetration testing and vulnerability scanning are powerful
tools used to monitor and improve information security programs.
By John Barchie,
Senior
Information Security
Governance Fellow
John Barchie Biography
Back to Top
Information Request Form
|
|
