Re: Penetration Testing Scheduling

[David Howe <DaveHowe.Pentest () googlemail com>]

Pete Herzog wrote:
> Hi,
>
> I just uploaded a little slide with graphic about test types from 
> OSSTMM 3: http://www.isecom.org/Test_types.ISECOM.pdf
>
> A thorough test is one where the auditor knows what is being tested 
> and the target knows nothing of the test.  This allows the auditor to
>  test the target as completely as possible including the reactions of
>  the staff.  The worst kind of test is the kind where the auditor 
> knows nothing about the target and the target is aware of the test 
> because this will only test the skill of the auditor and the ability 
> of the target to move itself out of "harm's way".

I would say the BEST test is one where the attacker knows almost
everything about the target system and its topology (other than valid
access credentials at administration level - usually a user account or
four is ok), and the local admins know nothing about the attack and
believe the attacker is in fact a valued customer or normal employee to
be given active assistance (to an extent consistent with good security)

The WORST attack is one where the attacker knows nothing about the
target system, is given no opportunity to perform intelligence gathering
in advance of the attack period, and his actions are constrained to
follow a script pre-approved by the defending administrators and for
which they have had a period of time to anticipate and develop specific
defences against.

A sane real-world scenario will usually fall somewhere between the two,
usually closer to the former; A lot depends on the scenarios agreed with
those commissioning the test, but three practical attack scenarios are

1) Cheating Customer - attacker has a valid customer account and the
   goal is to obtain goods or services without being billed for them.
   Administration and user support staff (as applicable) are unaware
   this isn't a normal customer and that an attack is planned at all.

2) Interested Competitor - attacker has the active co-operation of a
   couple of regular employees, who won't do or give anything that would
   be tracable back to themselves, but will happily give process and
   internal topology (as known to them) and could possibly be induced to
   run some sort of testing tools provided site security allows and they
   are convinced they won't be "traced". Administration and user support
   staff again are unaware that a test is taking place.

3) Disgruntled ex-employee - this scenario is actually much more complex
   to set up, as potentially the employee (depending on role) could have
   had opportunity to introduce backdoor access, cache sensitive files,
   or observe the passwords of people in their vicinity. Scoping this
   one can take a *lot* of time :)

------------------------------------------------------------------------
This list is sponsored by: Cenzic

Need to secure your web apps NOW?
Cenzic finds more, "real" vulnerabilities fast.
Click to try it, buy it or download a solution FREE today!

http://www.cenzic.com/downloads
------------------------------------------------------------------------