This goes to the heart of what we are trying to do at OWASP since it will help to improve the visibility of an website's security.
But before you continue reading the rest of this post, if you are not aware of PayPal's guidelines for external security researchers, please go and read this https://www.paypal.com/us/cgi-bin/webscr?cmd=xpt/Marketing/securitycenter/general/ReportingSecurityIssues-outside (which is linked from https://www.paypal.com/us/cgi-bin/webscr?cmd=xpt/cps/securitycenter/general/UsefulLinks-outside)
Here is what I like about this schema:
- (probably the most important) this is NOT dependent on the website's collaboration or participation (i.e. we can implement this independently)
- It promotes good behavior and security awareness from the website's owner
- it allows OWASP to raise the bar of entire sections of the online industry, since once we have a number of websites that follow the proposed guidelines, then their competitors will have 'market pressure' to follow it
- this is something that the entire OWASP community needs (from member companies, to individual members, to owasp leaders, to participants at our conferences or mailing lists). For example, I (as a web user) would like to know when I use a website about that website's security posture. Another good example was when OWASP had to chose a couple months ago which Online-Voting provider we used for our board elections. Since we were paying for that service, the website's security should had been part of the decision making process (and it wasn't since we had no visibility into that website's security)
- this schema also allows to clarify what is the affected website's point of view regarding their multiple web applications. Let look at a couple examples:
- The Full Disclosure and Fully Open could be used on Sample Apps. For example the ones published with the Spring Framework (like JPetStore or PetClinc)
- the Responsible Disclosure and Open Code Review could be used for Open Source applications (in fact the different between Open Code Review and Fully Open could be that for Fully Open the tests can be executed into the actual live website versus a locally executed copy of the website (which will be possible when we have access the source code)
- the Responsible Disclosure and Open Test is what PayPal is doing
- the Private Disclosure could be used a first step for companies who want to leverage the good guys security knowledge (for example, a lot of us 'accidentally' discover security vulnerabilities in websites but are not comfortable in reporting them since we are not sure how the website's owner would react (in fact in most cases we don't even know who to contact)). Another source of security issues for this is the XSSed database, or the google searches for the latest Flash/XSS vulnerability.
- the No Disclosure is an interesting one since I don't expect that companies will 'officially' embrace, but one we (OWASP) could apply based on that companies past behavior (past examples are: MySpace when it sued Sammy, BT with Daniel, the US Gov departments behind with the Gary McKinnon case, etc...)
- Finally given the current 'hacking laws' the OWASP “Trust Us” Insecurity Program – No testing + no disclosure is what all public websites should be given by default. This would actually be a great way to visually show the current (bad) state of affairs
- For day to day browsing, a Firefox extension that checked the website's status would be a great way to expose this to a wider audience
I'm sure there is a number of tweaks we will need to do to the classification names, its definitions and the scenarios they cover.
So I would say that the next step is for us to try to implement this, mark it as Beta for a while, and once it is working, officially launch it.
Who wants to be the project leader?
