Application security is increasingly important in software development and deployment. Two of the main app security...
test, penetration testing and code review, are examined in this tip.
According to 2002 Gartner Research, nearly 75% of attacks occur at the application-layer for enterprise organizations. This fact, coupled with increasingly complex applications and bolt-on immature application security products, is leading to a flourishing service market. With the slew of new security boutiques pushing a variety of application protection services, it's critical to understand the advantages and limitations for two of the most popular offerings: penetration testing and code review.
Traditional penetration testing usually refers to "popping a box" or hacking into a target system -- no-holds-barred. The strategy, similar to current Web application pen tests, includes: conducting reconnaissance, identifying potential entry points to exploit a vulnerability or poor configuration, and then leveraging that foothold to escalate privileges to administrative or root level.
In a Web application pen test, a consultant gains familiarity with the application through a series of standard user tests in an effort to learn basic information like the operating system, Web server type, linked applications (databases, media servers), security mechanisms (SSL, input filtering) and language base. With the reconnaissance completed, Nikto (an open source Web server scanner) is typically run to find the flagrant holes prior to deploying a full-blown application security scanner such as WebInspect or AppDetective.
After Nikto, the application security scanner tests for myriad vulnerabilities, including SQL injection and manipulation, cross-site scripting (XSS), directory traversing and authentication weaknesses. The vulnerabilities flagged should then be manually verified (given the immature app security scanner market). Once verified, the consultant can perform fuzzing to find exploitable code, and unleash a series of custom attacks, proxied requests and scripted detection engines -- all of which can uncover significantly more dangerous vulnerabilities, far deeper within the application. In general these services can take 40 to 200 hours, whereas each unique Web page input form can range from two to four hours to adequately assess.
Source code security audits encompass a process where an engineer reviews the application code, scrutinizing the key security areas and functionality line-by-line. Compared to pen testing, code audits are both more time consuming and much more costly. This aspect is especially true on large code bases or if multiple languages are utilized. However, the advantage of spending the extra time and money on a code audit potentially provides more granular recommendations through a deeper understanding of the application.
Of course, granularity takes time, and the average code assessment takes approximately one hour per 1000 lines of code. Though, depending on language, proprietary tools and engineer expertise this metric could vary as much as 50-200%. While there are available tools (such as Application Defense, RATS, and SPLINT) to expedite the review process, the engineer's level of experience is a factor; a hybrid background and expertise in application security and programming knowledge is needed. The tools simply help engineers to visually traverse code trees or find potentially risky methods or functions that have been implemented.
The cost for an assessment can vary depending on the scope and size of the target application. It would be common to spend $25,000 on a remote Web penetration assessment or $40,000 on a code review for a small- and medium-sized application. While code reviews can uncover the more obscure memory leaks, race conditions, logic bugs and back-end misconfigurations, it's usually difficult to justify the additional cost. From an external risk perspective, it would provide more value to your organization to give a group of ethical Web hackers free reign of your application after-hours for a couple weeks; they could offer the same perspective as any other malicious user on the Internet.
Whether you choose a pen test or code audit, be sure to request a comprehensive list of tests that will be completed beyond the assessment completed via the commercial tool of choice. This list will ensure that the party that you're hiring can do more than merely talk-the-talk. Additionally, offer up your application's source code tree at the end of the engagement to ensure that inline code fix recommendations get included in the final report.
As the technology continues to advance and average engineer's knowledgebase increases, code reviews may eventually surpass pen tests in terms of ROI. Until then, spend the money you save on getting regular penetration tests versus code reviews and on educating your developers. The fact remains, novice programmers introduce the issues and are the root cause of your app-layer vulnerabilities.
About the author
James C. Foster is the deputy director for Global Security Solution Development at CSC. Foster has also worked for Guardent (acquired by Verisign), Foundstone (acquired by McAfee) and the Department of Defense.