When I hear the word “hacker,” it makes me cringe. Hackers search with enthusiasm for problems with an application's construction. Enthusiasm does not equal engineering, however, as an application's security is as reliant on its design as its construction. Design and construction both need to be examined to measure the amount of trust that can be placed in a web application or web service.
The realization that trust in a web app or web service needs to be measured before placing any confidence in its security is both good and bad news. The good news is that there are all sorts of tools and techniques already available in the marketplace. The bad news is that there are huge ranges in the coverage and level of rigor that different tools and techniques provide. Any use of tools and techniques also has to be web app- or web service-independent of any software development lifecycle (SDLC) model, and there has to be general agreement about how to use tools and techniques to perform measurement.
Tools and techniques that can be used to examine different aspects of web app and web service security basically fall into two categories: tools and techniques. The first category consists of using automated tools to examine web apps and web services while they are running. The second category consists of performing manual review and analysis using, for lack of a better way to put it, one's eyeballs. Which tools and techniques and which combinations of tools and techniques provide what coverage and rigor?
Typically, this type of information is prescribed in a standard. It turns out that there are no such standards that are specific to web apps or web services, at least until very recently. An Open Web Application Security Project (OWASP) has recently produced such a standard. It is, in fact, OWASP's first standard. It is called the OWASP Application Security Verification Standard (ASVS).
OWASP ASVS was designed to normalize the range in the coverage and level of rigor when reviewing the security of a web app or web service. It defines four levels of examination (verification) that increase in both breadth and depth as one moves up the levels. The breadth is defined in each level by a set of security requirements that must be addressed. The depth of the verification is defined by the approach and level of rigor required in verifying each security requirement.
OWASP ASVS Level 1 treats web apps and web services as single monolithic entities. Level 2 requires examining web app and web service components after they have first been organized into an architecture. Level 3 further examines web app and web service design. Level 4 includes a search for malicious code that might have been added to the web app or web service source code during development. The range in the coverage and level of rigor between the levels was designed to be relatively linear. If a web app might take one or two weeks at Level 1, a Level 2 examination of the same app might take two or three weeks; a Level 3 might take three or four weeks; and a Level 4 might take four or six weeks.
How can OWASP ASVS be used in practice to measure the amount of trust that can be placed in a web app or web service? Using OWASP ASVS requires planning. The first step is agreeing on an OWASP ASVS level to use. The next step is to develop a test plan and a project schedule to figure out who will be doing what and when. The next step is to perform the testing according to OWASP ASVS level requirements. The last step: write up findings according to OWASP ASVS reporting requirements, come up with a strategy to perform remediation, and re-test until OWASP ASVS level requirements are met.
Mike Boberski is project lead and co-author of the Open Web Application Security Project ASVS.
