I’ve often run into the case of the network that simply can’t be satisfactorily tested in the time allotted to it. There are a couple reasons for this: tight budgets, sales processes that lead to “cookie-cutter” penetest sales, poor scoping, etc.
The typical solution to this is to document what could not be completed or tested fully and present this to the client. This is frustrating to both the pentester (who scoped the work) and the client (who likely expected the work to fully be completed on time).
I’m wondering if there’s a better way to do such work.
What if a pentest could be scheduled to happen over a two/three month period in which the client would be aware the the pentest could happen at any time, but wouldn’t be expecting malicious traffic at any given moment.
There are obvious benefits to such a situation:
- The pentester has a more relaxed schedule to execute an attack.
- The attacks can be more complex, as there is more time to plan.
- The client’s defense can be more accurately tested (as they won’t be fully expecting the attack when it happens).
And obvious drawbacks:
- The client needs to trust the pentester / pentester’s firm that they’re getting a fair share of time / work (A project plan and an unabridged log of work completed would help in this situation).
- Project management would be more difficult. How do you ensure that you, as a tester, are giving adequate attention to a project?
- The client couldn’t be under any time crunch (This happens more often than you would expect).
This could even be taken to the next level by putting a pentester on retainer, and ensuring that the network is fully examined every ~month. This seems the natural way to ensure complete and continuing coverage.
What are your thoughts? Is this a good / bad idea? How would you respond as a network manager? As a pentester?
Jonathan Cran 
You also have to think about the tester now having to possibly manage several tests at once when the actual testing can take place over several months.
Not impossible but might make the report writing and documentation more difficult when you’re trying to remember exact details about x,y, or z from one network to the next.
other issues arise with this as well from the PT perspective:
1-I now have to keep a shell on a client’s network for longer than my usual 2 week period…maybe thats ok and maybe its not
2-some clients may prefer you to do everything on site
3-now you have to ensure you have static IPs or keep good notes of what IP was doing what on what day.
None of those make remote ops impossible, just more of a pain in the ass than just going on-site and plugging in.
All good points. There are many problems that come with non-contiguous project like this…
Still, the question remains… Is it a good test of the network’s security? How much value is in a continuous pentest vs a one-timer. can it be made worthwhile / manageable?
food for thought.
jcran