"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
(Repost because I got an error earlier)ReplyDelete
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.
Security testing is must. Everybody wants security at every level of his working. as explained above failures are happened but if we test time to time then it will improve. So it depend on us how much we are serious about this.Delete
Intelligent Big Data Summarization for Rare Anomaly Detection Project For CSE
LBOA Location Based Secure Out sourced Aggregation in IoT Project For CSE
Modelling Cyber Attacks on Electricity Market Using Mathematical Programming With Equilibrium Constraints Project For CSE
Performance Evaluation and Analysis of IEC 62351 6 Probabilistic Signature Scheme for Securing GOOSE Messages Project For CSE
Poisson Reconstruction Based Fusion of Infrared and Visible Images via Saliency Detection Project For CSE
Secure Internet of Things (IoT) Based Smart World Critical Infrastructures Survey, Case Study and Research Opportunities Project For CSE
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. AlexisReplyDelete
There could be some internal applications where level 0 is enough to aim for (and automatically achieve)ReplyDelete
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.
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
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
I wish you all the best in your new role as ASVS project leader!ReplyDelete
This comment has been removed by a blog administrator.ReplyDelete
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.ReplyDelete
web design company
I should assert barely that its astounding! The blog is informational also always fabricate amazing entitys.ReplyDelete
The author has composed this blog in an extremely informal way.ReplyDelete
Brave Browser Download
Individuals everywhere throughout the world are following each other on Twitter, and receiving a major kick in return. In this manner, Twitterific is our top pick from the iTunes Application Store. 먹튀검증ReplyDelete