Scoping is one of the most important parts of a penetration testing engagement as it will determine if you will be able to do a good job:
- Not enough time: you will struggle to finish in time, and you will miss things or provide an incomplete report.
- Too much time: the client is not going to buy your services (and you are likely to fall into the “not enough time” category for the next job if you need money).
- Perfect… good job, but remember, things can still go wrong.
The goal is to find the right balance to provide a level of testing matching a realistic threat without wasting clients’ money
The best way to scope an application is to perform a lot of testing and know how much time you spent on them and if it was enough or not.
You can obviously spend weeks and weeks on the same engagement and try to find some 0–days but it is unlikely that most clients will be willing to pay for this.
There are a lot of factors to take into account during the scoping of an application:
- Criticality of the application. The security required for a personal blog is different from an online banking application.
- Where the testing has to be done (onsite/offsite). Being offsite can make you more productive as you will be able to get help from your team. Also, this type of jobs are easier to schedule.
- Approximate number of IP addresses, Systems involved, Pages and parameters for websites…. Everything that give you an idea of the volume of testing.
- WAF/IDS that may slow your testing down.
- If the testing has to be performed in a production environment (you will need to be more careful and avoid automated tools).
- Number of updates need to be sent to the client and meetings. Loosing an hour every day will slow down your testing. Spending one hour per day in meeting for a week is equivalent to losing one full day of testing (if you factor in the time to prepare the meeting, go to the meeting, send updates, refocus...).
- …
Another thing to take into account is if the testing as to be done against third-party infrastructure (Amazon EC2, Hosting companies). That may add some requirements that will take more time.
Based on your knowledge of the clients, adding some buffer can help to stay on schedule. For example, if you know that the environment will not be ready on the first day of testing, make sure you include that during the scoping.
Make sure you keep all the information you have and provide them to the testers (it may not be you). The account(s) used to access the application are likely to be reused and you don’t want the people testing the application asking the clients for them:
- You will waste time waiting for the answer.
- You (your company) will look disorganised.
For some good clients (and after asking), it is sometimes tolerate to have a quick poke around during testing… Finding a bug during this step usually helps a lot to seal the deal (you however don’t want to try to hard and break something).
Scoping meeting
Sometimes, the scoping will be done as part of a “scoping meeting”. If it happens, you need to be prepared: ask for any documentation you can get beforehand and carefully read it.
These meetings are also a good time to ask as much questions as possible:
- What the application does?
- Do they have a go-live date? Does the testing need to happen at a specific time (after-hours?)?
- Why they want to test the application? This sounds silly but it may really change how you can help your clients and create a proposal that better suits their needs.
- Who can you contact if you have further questions?
- Biggest risk they can think of for the system they want to see tested
A lot of clients think that penetration testers are a bunch of keyboard cow-boys. Looking organised and structured will help them trust you: “They are the right people for the job” should be in their mind when you leave.
You also needs to look smart (not arrogant, smart…), this is what you are trying to sell. You are smart, you will find more bugs and do a better job. When you are selling penetration testing, you are selling brain-time.
If you have information try to think about threats. If you know what the application is doing, think of all the malicious ways you can take advantages of it and discuss it during the meeting.
If you have information on the technology they are using make sure you know about it, you understand it, and know common issues impacting it. If they have a JBoss server in scope, know what are the most common issues with this server and what you will check (they may ask you).
An example
Let’s look at a quick example to give you an idea of how you can/should scope for a given test…
Let’s take a vitrine website for a small company. The website is tiny and is used to provide information to clients and allow them to search the website and request information through a contact form. The application is pretty simple and is based on Drupal. Limited testing needs to be performed on a network level, only the application is in scope.
To perform this kind of test, you will need between 2 and 3 days with one person including writing the report and quality assurance. This kind of pentest cannot really be splat between two people (however it’s always a good idea to get someone else to have a quick look to make sure you have not missing something obvious).
You can speed up this type of testing (and lower the number of days) if you have a bit of automation around web application discovery and fingerprinting of common frameworks. So 2 or 3 days should be fine.
How to get started as a beginner?
To get started, you can keep a list of all the pentests you did with:
- Number of day/cost.
- Did you have enough or too much time?
- Why did you need more/less time?
Once you have practice this for few months, ask to do “unofficial” scoping. When a client comes up, do the scoping on your own (price/number of days) while a senior tester is doing the real one. Then compare the figures and explain how you came up with this number. Then ask the senior how he came up with his/her number
Share&Educate
Some time, you will also need to “educate the client”. Despite “being always right”, some clients don’t always have a clear understanding of threats (or they may be buying their first pentest). [If you know the clients well enough,] it’s often worth introducing different ways to look at the testing.
For example, your client wants a “Red Team” testing for one month. And you know that they have unpatched systems all over the place, no network segregation, and internet-facing applications written in PHP from 2009. It may be worth suggesting another approach to the testing. For example by doing a pentest for 5 days, an internal audit of critical systems and SOE images for 5/10 days, and taking it from there.
Conclusion
I hope this article gave you a bit of an inside of the “art” of scoping a penetration testing. When you start your career it’s seems like a really daunting tasks, but it gets easier and easier with practice.
