From: Javier Fernandez-Sanguino Pena (jfernandez@germinus.com)
Date: Mon Jun 17 2002 - 08:33:17 EDT
> I tend to separate this into three different categories :
I have a different view myself (see below)
>
> - the pen-test is all about getting in, as Mark said. Indeed, its very
> name implies that the main purpose is to find _a_ hole, and not _all_
> holes, the point (or one of the points, depending on the particulars)
(...)
A penetration test is not useful for the client if you just report
a single hole and they close it. If you want to do a real penetration test
it should be broad in scope, i.e., detect _all_ holes that could be used
to gain entrance and get in.
The fact that you exploit the holes and try to get in is the one
that distinguishes it from a vuln assesment since you are:
1.- proving that the hole exists, so that false positives are (or should
be) reduced to 0 in the reports
2.- prove that it can be exploited and thus determine the overall
impact to
security in the organization. That is you not only say "there is
a hole here
and people can get in" but: "there is a hole here and, due to the current
security layout I can jump to your internal network and do so and so"
I like to see penetration tests as both broad (check all the systems
and all the vulnerabilities) and deep (exploit all the vulnerabilities to
their maximum extent and determine the real consequences, i.e. _impact_ of
them in the client).
>
> - the vulnerability assessment is similar to the pen-test as far as the
> tools and methods are concerned, but aims at identifying _all_
> vulnerabilities in a target platform.
>
I do not agree here. A vulnerability assesment is IMHO just
the first step in a penetration test which could be made/sold isolated.
Main differences:
- it is done mainly with automatic tools and there is no "manual hacking"
done most of the time. That's why I call most automatic tools
(Nessus, ISS, CyberCop, eEye...) "vulnerability scanners"
- vulnerabilities tend to not be checked out manually so a lot of false
positives
and false negatives might appear
> - the security audit is the full package, heavily relying on a formal
> methodology, including a complete analysis of the client's security
> policy and how it is applied, and so on.
Agree with you here. However I also think that there are some kind
of audits that are more "lightweight": technical audits that include both
black-box and white-box analysis (usually with automated tools + hacking)
but which do not correlate against a formal policy (since the client might
not have one in place) but do correlate against "standard" policies
(i.e. ISO-17799)
>
> But, of course, that's just me, and as far as I know, there's no
> precise, widely accepted definition.
/me agrees
Javi
----------------------------------------------------------------------------
This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
Service. For more information on SecurityFocus' SIA service which
automatically alerts you to the latest security vulnerabilities please see:
https://alerts.securityfocus.com/
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:22 EDT