A number of years ago the problem of application vulnerability disclosure was solved by a security researcher named Rain Forrest Puppy. RFP wrote a policy that described his own method of responsible disclosure. He named it RFPolicy (Rain Forrest Puppy/Policy). It solved a problem where vulnerability researchers were able to disclose their vulnerabilites in software applications safely. Additionally this allowed companies to fix their issues before public release of the vulnerability. The world was a happy. Then the disclosure issue reared up again regarding web application security.

I noticed about a year ago there was a gap in vulnerability disclosure. There were a lot of vulnerable web applications on the web, but there was no way to raise awareness of them. There were only a few scenarios. Firstly, the security researcher could submit them to lists like full disclosure, but even other security researchers didn't want to get innundated with tons of website specific vulnerabilities. Secondly, the security researcher could send the vulnerability to the company. But the security researcher had no way of knowing what would happen with the vulnerability, no way to track how long it took to close, and worse yet, they risked prosecution for finding the hole. The third option was to leave the vulnerability open, and not disclose it to anyone. However, the last issue was perhaps the worst in that it left the security researcher with only the ability to sell it to the underground.

In the short term I created the full disclosure board on sla.ckers.org to fill the gap. It did not, however, solve the corporate issue of knowing before the world knows. It also tends to get watered down due to the volume of reports, it's difficult for companies to search and ultimately it brings only negative press to all parties involved. In particular the security researcher looks evil and the company looks ignorant of security. This situation was not good for anyone.

I wanted to find a way to solve several problems with one policy. I wanted to fix the gap that the original RFPolicy left behind while allowing security researchers an outlet to a) get the vulnerability fixed in a timely manner but make it flexible based on the type of vulnerability, and b) allow them to take credit for it after the fact if they so choose to be credited. From the corporation's perspective this is also a win, because it allows them to fix their holes through responsible disclosure. Everyone wins. Thus RSPolicy (RSnake's Policy) was born.

Through the coordination of a few large enterprises, I was able to come up with a reasonable way to solve this issue, while maintaining the flexibility of the vulnerability class in question. Some vulnerabilities are much harder to fix than others, and that was something missing in the original policy. This policy takes into account specific vulnerability classes and gives the appropriate weights to those issues. However, I wanted to put a stake in the ground where companies should look to the timelines as both a best practice and a guideline for the worst case scenario for application fixes.

RSPolicy is not a license to hack. Rather since companies know some researchers will do it regardless of the safety in doing so to the infrastructure and without concent this still allows the companies to continue to have an open dialogue with the security researchers in question or at minimum allow the researchers to contact the companies. This is a way for the security researcher to disclose their findings responsibly, insure that the problem is dealt with and they get the credit for their findings.

One of the complaints I have heard from hackers is that it would take as much time to write and send the emails to the vulnerable companies as it would to find the vulnerabilities in the first place. In this way, the sla.ckers.org full disclosure forum has been a fast and effective way to blast out a number of vulnerabilities. That does not, however, solve the corporate problem.

The RSPolicy tool is designed for two things: speed and anonymity. I do not require authentication, I do not try to find the real location of the users, and I attempt to make the IP address of the user apparent so they can protect themselves using a proxy. It also allows researchers speed unparalleled by any other disclosure mechanism, to hopefully remove the issue of time to disclose.

I'm sure at some point someone will ask, "Why these companies in particular?" I chose these companies purely for three reasons. 1) I knew someone in the security team in the company 2) they are the type of company who constanty faces these issues and 3) they have a large name brand associated with their websites. I felt like these three companies had the most to offer in terms of support and clout amongst the web application security world. Additionally, each of them have made a commitment to securing their respective enterprises. In working with the various companies on this project, I have made a section of this page availible to them to voice their opinions on RSPolicy. The following paragraphs are their words, not mine (alphabetically sorted):

Company A

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Company B

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Company C

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Note, that although the comments above may be representitive of a larger scale accepted feeling towards these issues, they can in no way speak on any other company's behalf.

The following list is based on the OWASP Top 10. Although there are a number of other security issues that affect web technologies, the OWASP top 10 represents "a broad consensus about what the most critical web application security flaws are." Rather than re-invent other people's work, I opted towards using existing lists. If you disagree with this list, please contact OWASP and get them to change it.

The companies mentioned above each participated in a virtual round-table where we discussed what their thoughts about each of the vulnerability classes were. I asked them to give me timelines on what it took, on average, to fix their vulnerabilities. Without specifically telling anyone who said what, I made this portion anonymous to protect each company's strategy. This is designed not so that just these three companies can follow the policy but any company with the huge technology burdens associated with the types of infrastructures these companies have can comply.

Why have timelines at all in the RSPolicy? Unfortunately due to the nature of web applications the only way to find the vulnerabilities is to test them against the target. This often means exploitation of live/production systems. Many security researchers do not want to risk disclosing who they are to the companies in question due to fact that they fear legal reprisal. RSPolicy is designed to be both two way communication as well as one way communication - meaning if the security researcher chooses to disclose the vulnerability anonymously, they should still have a timeline in place to drive the companies towards fixing their security issues. Also, the time it takes to fix one form of vulnerability may be disproportionally difficult compared to another. RSPolicy attempts to make that distinction as clear as possible.

Vulnerability Class	Company-1	Company-2	Company-3	RSPolicy Deadline
Unvalidated Input	0 weeks	0 weeks	0 weeks	0 weeks
Broken Access Control	0 weeks	0 weeks	0 weeks	0 weeks
Broken Auth & Sess Mngmt	0 weeks	0 weeks	0 weeks	0 weeks
Cross Site Scripting	0 weeks	0 weeks	0 weeks	0 weeks
Buffer Overflows	0 weeks	0 weeks	0 weeks	0 weeks
Injection Flaws	0 weeks	0 weeks	0 weeks	0 weeks
Improper Error Handling	0 weeks	0 weeks	0 weeks	0 weeks
Insecure Storage	0 weeks	0 weeks	0 weeks	0 weeks
Application DoS	0 weeks	0 weeks	0 weeks	0 weeks
Insecure Conf Mngmt	0 weeks	0 weeks	0 weeks	0 weeks

Obviously this is not a one-size-fits-all table, and in the case of exploits that don't match any of the above, it is suggested that the security researcher use their best judgement and/or work with the companies in question to come up with a reasonable amount of time for the software fix.

Use this policy, and the tool responsibly!