Scoping a Penetration Test

Scoping a penetration test is difficult. This is why Statements of Work and Requests for Proposals are necessary evils. It’s not an exact science.

There’s a lot of factors that can be involved:

• Number / Complexity of Systems and Networks – Standard windows boxes? What about the patching system controlling their updates? Are they located in the DMZ, or would exploitation of the system drop you directly into the internal network?
• Number / Complexity of Applications – Number of pages (a horrible metric)? What technologies were involved? How many developers? In-house, or Third-Party? Remote Administration? The List goes on…
• Depth of Testing – How “deep” should the test go? Should we stop once we’ve run a vulnerability scan and confirmed / denied the results? What about brute forcing of authentication? What about attacking the users? What happens when we gain access? Should we continue?
• Focus Areas – Where should testing be focused? What systems are of critical importance? How are those systems used?

A number of helpful things to do:

• Define a goal. If you haven’t DEFINED a goal, you should start there. Some goals are obvious — Gain Domain Administrator access. Some are not so obvious: Gather document on sally from accounting’s desktop.
• Accept that each test is going to be different. Each time you do one of these, the goals are going to be slightly different. Disregard that fact at your own risk.
• Look at the system from the perspective of controls. Which controls are you trying to test? The firewall? The spam filter? The user’s intuition? (The danger of this method is testing to the control, not the gaps between them.)

In the end, it’s scoping == budgeting. You have to be able to make reasonable estimates about the time that you’re going to spend testing. How do you scope penetration tests and other services work? I’m interested in the tactical (and repeatable) metrics that you use!