From: Dave Aitel (dave@immunitysec.com)
Date: Wed Jun 19 2002 - 09:50:31 EDT
On Mon, 2002-06-17 at 16:56, Gulrez Jamadar wrote:
> All,
Caveat: I do penetration testing
(http://www.immunitysec.com/services.html), so this only reflects MY way
of doing it. Other companies can feel free to chip in. Think of it as
"full disclosure."
Keep in mind, part of my value is my honesty about these sorts of things
- I keep the business covert action to a minimum so I can concentrate on
more fun technical things. Also, as a very small company, I don't have
staffing issues or project management or company overhead, which may
complicate other company's equations.
Basically cost is estimated time and materials capped so the customer is
more comfortable with it. Of course, this means I have to over-estimate
so as not to burn myself, which means that most of the time, the
customer is actually paying for more than they need to. But we all know
the persuasion power of a flat rate versus a per-hour rate, so that's
the way most people do it. As a small company, I'm comfortable billing
either way. Experienced customers will probably get a better deal on a
per-hour basis.
So your question really is "how long does it take to do a typical
penetration test in my environment." This is complicated by the fact
that most penetration tests are not full-day affairs. In general, there
will be at _least_ 30% down time as the customer fixes their software,
or requires that you only test off hours, or simply starts the pen-test
without being ready for you to test all the components.
Some companies do multiple penetration tests at once, since otherwise
the "churn" on many consecutive penetration tests basically eats the
entire margin (you can do the math here - 4 two week projects, average
of 2 weeks each, with one week between them...). Obviously, if the
company is using the %30 percent down-time for other projects, you're
probably not paying for that time. Otherwise you probably are. (In my
case, I often use the downtime for SPIKE or other development).
When most people say "penetration test" as a customer, they really want
what the penetration test companies call a "network vulnerability
assessment." Basically when it comes down to it, companies feel weird
about having people running code on their machines that arn't them. So
typically no matter what the words at the top of the statement of work
are, you end up enumerating vulnerabilities rather than exploiting them.
This sort of thing is done by Nessus/ISS Scanner/CyberCop/etc rather
well. Usually it's a throw-in, unless the number of hosts to be scanned
is rather large. The larger the number of hosts, the larger the number
of vulnerabilities I'm going to have to _verify_ by hand. Most scanners
excel at producing false positives. So during the sales call, if I
figure that there are going to be a number of hosts connected to the
Internet without a firewall, I add about four hours per host for
verification time. Otherwise, it's simple web stuff usually, and that's
pretty easy.
So let's take your sample metrics - really they're just a way for the
company to figure out how many people they're going to need for how
long. My metrics are basically this on a typical (simple) test:
((per web server for a medium sized web application done in .asp or .jsp
or .php but _not_ using a custom client)
Scanning for ODBC errors and overflows: 2 days (this is fast and easy
with SPIKE)
Scanning for logical vulns, session fun, etc: 2 days (I should already
be familiar with the app by now, so it's relatively easy)
Docs: 1 day per web server)
(plus optional retesting time of 1-3 days)
Nessus Scan and Verification on some hosts: Free unless I think there
will be a ton of things I have to personally verify, but typically
anything but port 80 and 443 goes down in my deliverable as "close this
off."
* my bill rate=cost of the job. Easy, huh? :>
I add into this my (estimated) legal fees (minimal, usually) and that's
what I use as my bid.
For anything especially large or non-typical, I'm going to use these as
additional factors when scoping out the project. Basically I try to
measure out how much extra time I'm going to need to do a good job.
The optimal case for me is
1. Access to developers ("So HOW are you doing the authentication here
again?")
2. Testing on a development bench (during the day)
3. Access to source code (on my machine so I can use my tools to analyze
it, preferably)
4. Ability to put debug statements into the source code, recompile, and
retest
5. Ability to play man-in-the-middle (can be made difficult with custom
encryption and protocols)
6. Access to the logs of the running application, and core files (if
unix) or debugger access (if windows).
Each of these will drastically help me when looking at someone's large,
custom application. Customers tend to underestimate the additional
advantage of being on site, and looking at their source code with a
running debugger.
Other than these issues though, it's still just time and materials. How
long does it take to do a good job? I know that I'm fairly fast at
looking through source code, so there is a sizable "discount" in time
for when I have access to that. Likewise, I know that if the developers
are based in some other time zone, I'm less likely to be able to lean
over and ask them a question about how their password system works.
So if you're building "slabs" of different test and price categories, I
would take that into account.
-dave
>
> WHAT I NEED
>
> What are the factors affecting the pricing of a penetration test? Factors
> such as complexity of the application, duration of the test, lines of source
> code, number of developers involved in the project etc. Need detailed
> information.
> If anyone has assisted a client in rolling out an RFP to address similar
> concerns. Interested in going through the requirements definition part of
> the RFP.
> Any additional info, links etc much appreciated.
>
> Rgds,
>
> Gulrez Jamadar
>
> ----------------------------------------------------------------------------
> This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
> Service. For more information on SecurityFocus' SIA service which
> automatically alerts you to the latest security vulnerabilities please see:
> https://alerts.securityfocus.com/
>
>
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:22 EDT