Thursday, 16 September 2010

OWASP ASVS "Level 0 - No Verification"

According to OWASP, the Application Security Verification Standard (ASVS)
   "can be used to establish a level of confidence in the security of Web applications."

ASVS is a great idea, eventhough my efforts to introduce it have been 100% unsuccessful. Any takers?

The standard defines four verification levels ranging from 1 to 4. Broadly speaking you can verify the security of your applications based on a specific level. For the least critical applications you might verify to level 1 - which is basically an automated scan. If it passes the scan, then the application is secure enough.

For the most critical applications you could verify to level 4. This includes manual testing, code reviews of all code (including external libraries).

Level 0 - No Verification
I think that there is an implied 5th level which is "Level 0 - No Verification". Basically we have no level of confidence in the security. Most current applications probably fall into this level. The applications have not been subject to any security verification. This does not mean that they are not secure. But since they have not been verified, we can have no confidence in the security so they fall into our imaginary ASVS Level 0.

This begs the question, should ASVS formally include "Level 0 - No Verification"? Probably not. No point really! Developers could claim that their applications have been verified to Level 0 - which defeats the purpose.

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

8 comments:

  1. (Repost because I got an error earlier)
    We have a dedicated security resource set on achieving level 1 compliance in our upcoming release. We intend to reach level 2 in future releases. We already had a security process, but ASVS revealed several gaps in our security architecture, even at level 1. In our case getting the resources assigned was not a big issue, because we are selling to several banks and multinationals, and they're tightening up on web app security.

    ReplyDelete
  2. Joeri, It's interesting to hear of a company that has decided to formally adopt the standard as you have. I wonder would the PCI standards council ever specify that payment card applications need to verify to a specific ASVS level. Alexis

    ReplyDelete
  3. There could be some internal applications where level 0 is enough to aim for (and automatically achieve)

    If it is literally a loader for some scripts that are handy to run every so often or something of similar ilk where if it breaks no one would actually miss it then I think it is fine to say it reaches level 0.

    ReplyDelete
  4. @alexisfitzg,

    In relation to PA-DSS,

    I doubt the PCI SSC will transition to ASVS in the short to medium term considering a majority of the Validated Payment Application(s) (VPA) still conform to the former Payment Application Best Practice (PABP) published by VISA.

    Furthermore, ASVS is scoped to web applications only and hence may not be applicable to Payment Applications which are served from TANDEM, AS/400 and Mainframe unless the Payment Application is served from a web server on an LPAR.

    I have highlighted a number of other issues with PA-DSS within http://www.slideshare.net/cmlh/padss

    ReplyDelete
  5. @alexisfitzg,

    In relation to ASVS,

    The major cause of resistant to ASVS is that it was created from the perspective of an webappsec vendor with some experience Common Criteria (i.e. CC EAL was translated to ASVS Target of Verification (TOV) - yes this is an oversimplification) rather then the perspective of the consumer.

    Creating a TOV 0 would imply that the vendor has at least dedicated some effort to webappsec controls and hence would confuse the consumer and would therefore simply be exploiting the intent of ASVS as you have stated.

    TOV 1 and TOV 2 should be consolidated as should TOV 3 and TOV 4 as a majority of the effort to reach the higher TOV has already been delivered in the lower TOV - again this is an oversimplification due to the discrete overlap of each TOV

    I will rectify your issues which I had already identified previously when I am elected as the OWASP ASVS Project Leader i.e. http://www.owasp.org/index.php/OWASP_Request_for_Proposals/New_Project_Leader/ASVS/Application_5

    ReplyDelete
  6. I wish you all the best in your new role as ASVS project leader!

    ReplyDelete
  7. This comment has been removed by a blog administrator.

    ReplyDelete
  8. The most outstanding component about this blog is the means by which it doesn't neglect to keep its gathering of people connected with at each point.
    web design company

    ReplyDelete