Last week I recorded a module about working with clients ahead of a penetration test for my upcoming online course, Breaking Web App Security. The module is a fairly straight forward discussion about the things we need to do as penetration testers before beginning any engagement. The section that I spent the most time on was scoping a penetration test. Why? Because it is one that a lot of new penetration testers struggle with. So let’s take a look at scoping a penetration test here too.
What are our goals in scoping?
We need to know what our goals are before a scoping call to effectively scope an engagement. There are a few key things that we need to find out when doing this.
- What does the client want tested and why?
- If it is a web app test…
- How big is the application and what does it do?
- How many user roles are there and what can they do?
- If it is a network test…
- How large is the network?
- What does segmentation look like? Do we need to test from multiple locations?
- What types of systems are on the network?
- Test windows. When can we test and when can we NOT test?
- What is their company’s secret sauce? What is it they do to provide value and what disruptions would be catastrophic?
I can actually think of a few more things I’d want to find out, but these are the big ones. When we are on the scoping call, this is the stuff we need to be finding out.
We absolutely should be asking what the driver behind a penetration test is during any scoping call. We need to know what the problem is that they are trying to solve. Are they dealing with a PCI and need a penetration test report for their QSA? If so, that frames how we do the report. The same goes for a test driven by a customer requirement. More businesses are requiring penetration tests for their service providers and want to see some kind of proof of the test. That probably means we need to provide a letter of attestation or a specialized report for this third party. We can’t meet their needs if we don’t know what they are.
Scoping a web app penetration test
I’ve been asked several times how to scope a web app penetration test. Some example questions are things like, “how do I know how long it will take to test?” or “do I get a count of pages, forms and fields in the application?” This is a rough one to answer since my approach is based on past experience testing web apps. My approach is to determine what the application does, how many different account roles it has, and ask about some of the main pages used within the app. I also find out if the application is used only by my client, is it used by individuals external to the client, or is it both?
Then I think through the similar apps that I’ve tested and how those assessments went. How long did I have for those assessments? Was it enough or did I need more time? I’ll consult notes that I keep on these questions for apps. My notes don’t identify the client or contain security information, due to limits I place on retaining client data. These notes allow me to not rely solely on memory and I can share them with another person who is scoping a job if needed.
With this information in hand, I can then decide how long I think the test is going to take and the number of people who should be on it. Once I have this decided, then determining the cost of the assessment is simply a case of multiplying the hourly rate I use for projects by the hours I’ve determined are needed. The process is similar for scoping a network penetration test.
Obviously, this takes some practice and you will probably make some missteps along the way. Even with experience I occasionally misunderstand something and make a mistake. It’s not the end of the world, so don’t stress out too much about it. One way to get some practice for yourself is to setup an open source web app and treat it like a penetration test for a client. Look at what the app does and write down how long you think it will take to do. When you are done, check to see how you did and then make some notes on it. You can refer back to these notes to help you in scoping your clients’ penetration tests. Hopefully this helps you as you scope your penetration tests.
Breaking Web Application Security – the course
Of course there is a lot more that goes into getting ready for an engagement and more information that we gather up. I cover this topic more completely in Breaking Web App Security and get into things like writing the statement of work, kick off calls, and protecting myself legally. If you would like to get emails about the class, you can sign up for emails specific to it using the form below. It’s really low volume, so you won’t be getting tons of messages from me. But you will know when the course launches and be informed of webcasts relating to it.