From: Lachniet, Mark (mlachniet@sequoianet.com)
Date: Tue Oct 07 2003 - 14:47:52 EDT
Hello all,
At risk of over-simplifying, I thought I'd post a summary of the responses I got. Please feel free to comment to the list or directly to me if I have missed something important.
I should also have noted in my original message that I also work in security consulting. For that reason, I may not be impartial in my analysis, and my statements should be considered in that light. My intent in writing this summary is to help clarify the issues (for those on all sides of the table) so that this type of work (and those who do it) can be more understandable, accountable and transparent, and that organizations can get the best services possible for their needs.
Anyway, the main issues of scoping the cost of a web application security audit might be broken down into two factors - the depth of analysis (goals and scope) and the size of the target (amount of code).
1) Identify the DEPTH of the analysis. This is essentially "how far you go." In my opinion, this is probably the area with the most potential for confusion. A prospective customer should be very careful to clarify what they are getting for their money, as the depth is probably the more important consideration. The further down the list you go, the more complex the work is, and hence the more intense the skillset for the personnel performing the work will be (unless specialists are used - for example, someone who just does code audits but has no clue about network security.) There are clearly a lot of people in the industry now who are doing (1a) but that pool of people narrows quickly as you do more advanced work such as (1b) and beyond. For example, do you:
1a) Just run tools and interpret the results?
1b) Run tools (almost everyone seems to use *some* tool to save time on trying every possible form input and grep needed to build the database of issues) but also perform manual analysis to verify holes, identify risks and determine other threat vectors?
1c) Perform an infrastructure review (network, firewall, coding practices, procedures, database connectors, etc.)
1d) Perform a code review? (Analyze code using automated tools like RATS or skilled developers)
2) Identify the SIZE of the target. The number of servers, lines of code, etc. There seem to really be three ways to go:
2a) Perform the work on a time and materials basis at a straight billable rate. This might be very difficult in a competitive bid situation, but might actually be the best way to go if there is a relationship in place between the vendor and customer.
2b) Perform some kind of scoping up front, essentially a requirements definition, where the vendor might do something like recurse the web site and evaluate the number of pages of code, the complexity of the web site (using measurements such as complexity, lines of code, etc.). With this information, the vendor should be able to create an adequate statement of work. This might be done by the customer, or by the consultant as part of the pre-sales process.
2c) Perform a "sight unseen" estimate of the amount of work required.
Thanks for everyone who responded,
Mark Lachniet
---------------------------------------------------------------------------
Tired of constantly searching the web for the latest exploits?
Tired of using 300 different tools to do one job?
Get CORE IMPACT and get some rest.
www.coresecurity.com/promos/sf_ept2
----------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:41 EDT