Penetration Testing mailing list archives
honeypot in conjunction with pen test?
From: "Javier Fernandez-Sanguino Pena" <jfernandez () germinus com>
Date: Mon, 17 Jun 2002 14:33:17 +0200
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/
Current thread:
- RE: honeypot in conjunction with pen test? Aleksander P. Czarnowski (Jun 05)
- <Possible follow-ups>
- RE: honeypot in conjunction with pen test? Javier Fernandez-Sanguino Pena (Jun 06)
- Re: honeypot in conjunction with pen test? Bennett Todd (Jun 06)
- Re: honeypot in conjunction with pen test? Mike Riley (Jun 06)
- Re: honeypot in conjunction with pen test? Mark Tinberg (Jun 07)
- Re: honeypot in conjunction with pen test? Daniel Polombo (Jun 07)
- honeypot in conjunction with pen test? Javier Fernandez-Sanguino Pena (Jun 18)
- Re: honeypot in conjunction with pen test? Alex Russell (Jun 19)
- RE: honeypot in conjunction with pen test? Woody Weaver (Jun 19)