Re: Why Penetration Test?

[Petr.Kazil () eap nl]

In our practice we report the risk at a high abstraction level for 
management.
Example:

Persons without credentials CANNOT access systems AT ALL.
Persons with user credentials CAN access systems, but CANNOT elevate 
permissions.
Persons with admin access CAN access a subset of systems, and can perform 
ALL actions.
Viruses and unauthorized programs CANNOT access workstations.

You get my drift ...

Then we have a detailed matrix where we "check off" requirements like:

Systems have no unnecessary ports open and services running
Systems don't show vulnerabilities as detected by the common scan programs
Systems don't provide unnecessary information

Etc.

We give a high level risk assesment for each requirement that is not met:

Because there is no authorized list of admins it's not possible to asses 
whether all administrators have the right permissions. This creates a risk 
of "rogue" administrators.

I'm cutting a lot of corners here of course ...

> Scenario A

Our approach is closes to this one.

> Scenario B
> Scenario C

These would be put in the appendix of the report.

Usually it's not expected of us that we exploit a vulnerability. It's 
sufficient if we filter out the "false positives". If a relevant patch is 
missing that's bad enough, we don't have to show that it can be exploited. 
In most cases we don't have/get the time to research the exploit and 
prepare a working demo - most clients are not willing to pay for that.