How to Estimate time taken for Web Application Security Testing?

Question

I would like to do some kind of estimation for time taken to test a website/ web application for security vulnerabilities. I will be testing websites against OWASP Top 10

Based on my understanding, Number of static/dynamic URLs, number of parameters to test (URL, Body) in a website , other insertion points like cookies parameters , parameter name, HTTP Headers, REST Style parameters are all the contributors towards the time taken. Please correct if I am wrong.

With that said, what are all the factors that we can include for arriving at a time taken for performing security assessment ?

Also, Since estimation should be done before we start testing and number of URLs / Parameters in a website will be known in later stages (like after spidering/crawling), is there any way that we can do the estimation beforehand ?

Business Logic, Number of functions to test, Number of Privilege levels may have an say on the time taken, but still will it not break down to the number of parameters that we are going to test ?

I would like to do this estimation to convince my client about the time taken for performing assessment.

For example, if my client asks to perform assessment of 10 websites in 'n' days, I should be in a position to tell them with proof/estimation that it will take 'X' time.

Could some one share your thoughts ? Is there any methodology for this ?

Answer 1

You cannot provide proof that it will take n days for the vulnerability assessment. You can provide them with an estimation.

When I scope an application for testing, there are a few things I look at. Most of it is what you've already covered.

• What the application does (process money or HR data, or serve a blog)
• How large the application is (a few URLs/pages or a lot; just content, or lots of functionality)
• How complex the application is (size and complexity are not always the same thing)
• How many roles are involved (eg user, admin, super admin)
• Any APIs involved (eg REST, SOAP, custom)
• Multiple clients involved (eg mobile, thick client, and web)

Like anything, it takes experience to be able to accurately scope an item for testing. You'll take in to consideration how long an application of similar size and complexity would take you to test, and scope appropriately. Depending on where you work, there may be a formula for x time spent on different types of functionality and other factors, that's up to your employer.

If you have the option, I would suggest listening to someone more experience on your team do the scoping so that you can understand how they do it and why they made the decisions they made. Under-scoping or over-scoping for a client can cause one or both of you issues. If you under-scope it, you or the person on your team may not have enough time to complete the testing, and over-scoping can cause the client to spend money unnecessarily. Mistakes are made of course, that's part of the learning process, but it's important to understand why things are scoped the way they are scoped before jumping in without the experience to back it up.

Answer 2

I'd add my opinion on this. Let's say you have an application to test (I am not including thick clients here as it's pure web application). The conditions on which the estimation might rely are:

Considerable Items

• Number of URL's which could be fetched via Burp's Spider
• Number of Parameters which could be fetched via Burp's Engagement tools
• Number of vhosts if not pointing to same main application resources

• Existence of Web Service or API's which are included in scope

  1. Here you will like to fetch the API's included via Questionnaires
  2. Map the web services parameter (REST or SOAP)
  3. Add all of this to the pointers of Web Services (sum)

Estimation

The complexity and the size as discussed previously in the answer can be determined via accessing the vhosts, the number of dynamic URL's (dynamic only means the application is talking to the back-end at the data tier level). Consider using test cases such as I in my one of the research had did previously for the clients below (this is private and one can define there own):

If you are not aware and almost need to estimate a timeline delivery, use Gnatt chart for each submission and test case module i.e. define modules in periodic terms such as 'Input Validation Security Test cases', Session Management Security Test Cases', etc. A look at the below timeline must give an absolute idea how to estimate a proper enterprise delivery schedule:

But before all of this, what most significant is to roadmap the project planner and describe the client the needed test cases in worksheet so that the client could necessarily go through the requirements document and provide a submission for the same to fix a proper timeline scheduling for you; this can be done in one of these ways:

1. Map the requirements, if white-box, what are the credentials requirements, etc?
2. Fill the gaps, check the application before you commit, what are more details required?
3. Always reach to the conclusions from summation of the aforementioned.
4. Add more amount of days than the original derived, that way you ensure quality.

A project planner could look something like this which can be a integral need for planning the web application security project phases as well as help you in defining timelines for the project:

The estimation again is the by-product and it's not necessarily that you wouldn't face any scope creep's, time delay on the project, resources for the project, etc in-between the project (which is why the additional day post which you map the timelines). Now, what rest that remains is to pin-point the critical path and the break points of the project e.g. what could go possibly wrong and to what extend, etc. You need to manage this extremely well and define everything beforehand. Best of luck! I hope you find this information useful.