Paid Advertising is
ha.ckers sla.cking
For any nonsense or banter that doesn't fit anywhere else. LoL! omg! ROFL! 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
Time estimate for Web Application Remote Penetration Test
Posted by: Ivan
Date: July 11, 2008 03:25AM

Ok, so far when I must estimate time I only see website, do same checking and I have number of days/hours for that project. On that I add few days/hours for testing and surprises.

But now I need some technic for calculating this time. If there is something like that ? Something like: URI x hours + Forms x hours + ...

Or maybe I can make some questionnaire for clients where they answer on specific details. And after that I can make estimate.

What are You doing ? Is there some texts about this problem ?


Options: ReplyQuote
Re: Time estimate for Web Application Remote Penetration Test
Posted by: Ivan
Date: July 11, 2008 03:15PM

Interesting discussion about subject:

Options: ReplyQuote
Re: Time estimate for Web Application Remote Penetration Test
Posted by: ntp
Date: September 10, 2008 06:25PM

Those answers were terrible. Another source of mis-information is ISECOM (which you would think could give the best advice, but no...).

Never believe anything you hear in an Ethical Hacking training course or on LinkedIn.

I would plan for 2 days per IP or virtual-host for a local-LAN QualysGuard or WebInspect style scan. It's also best to first run these tools one-IP at a time, with DNS completely off, if possible. You can run them a second time using DNS names, with DNS configured in various ways (in the case of virtual-hosts, you have to).

Of course, issues such as IPS and WAF need to be taken into account, as does round-trip latency and packet loss from source network to destination network in a remote testing scenario. The best way to calculate latency and packet loss is to use iPerf (requires client-server), or possibly pchar (client-server is not necessary) - - if no accessible NTP or DNS server is available. If an NTP server is available, you can use ntpq to get very accurate latency information; DNS server allows the use of nsping. Measure the results (start and stop time of test) with the vulnerability scanning tool that you use for a variety of targets. Note that updates to the tools may change these characteristics, so it's best to graph with data over time. Changes to the network could also result in fluctuation, so using a tool such as SmokePing would certainly help.

For a full application penetration-test, this clearly depends on scope. A single expert armed with Fortify 360 might be able to do 500 KLOC per month, but the largest applications in the world (~5M LOC) are going to require at least 10 experts to do so in a month. This assumes that the infrastructure is already in place for that team to get access to the build servers where the code is compiled/assembled. It is nice to know ahead of time if the development team used standard/official validators and did not re-assign properties. In other words, you also have to spend time going through specifications, requirements, design documents, code walkthoughs and/or other artifacts ahead of time. Lastly (and probably most importantly), you have to be sure that the tool supports the language, framework, and third-party components used as external dependencies. Otherwise, you'll have to spend time customizing rules for every method that is a potential source or sink.

I suggest using consistent people, tools, and practices if you really want consistent time estimates.

Options: ReplyQuote
Re: Time estimate for Web Application Remote Penetration Test
Posted by: ntp
Date: September 11, 2008 12:24AM

Another factor to consider is the maturity of the organization. If the organization-under-test regularly does network pen-tests or vuln scans - along with remediation - then it may take a lot less time. If they've never done an app pen-test, then regular network vuln scanning may not make the app pen-tests go any faster, although it certainly helps to a small degree.

So organizational readiness and maturity is another factor you'll want to figure into your equations.

As far as IPS/WAF detection, there are plenty of tools that can help with this. osstmm-afd is one, lft is another, and w3af contains many plugins that can help identify WAF's. If you are trying to determine how many IP's are behind a load-balancer, and halberd could prove helpful - although nothing is more helpful than a full-knowledge (or a more-knowledgeable) assessment.

Options: ReplyQuote

Sorry, only registered users may post in this forum.