From: Petr.Kazil@eap.nl
Date: Sat Jun 11 2005 - 11:08:53 EDT
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.
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:54:24 EDT