Organization for Internet Safety

Frequently Asked Questions

	Why did the OIS develop a set of guidelines for reporting and responding security vulnerabilities?
	In a perfect world, security vulnerabilities wouldn’t exist. In the real world, though, all complex software contains security vulnerabilities, and they pose a constant threat to the systems we all rely on. Yet there’s currently no agreed method for handling them, with the result that vulnerabilities are handled inconsistently. Worse, because the different parties involved in investigating and remedying them often use different, sometimes contradictory processes – or no process at all – it’s easy for communications breakdowns to happen. When that happens, users are the ones who suffer. The OIS document, Guidelines for Security Vulnerability Reporting and Response, is intended to help rectify this situation by providing guidelines for effectively reporting, investigating and remedying security vulnerabilities. We believe that they embody a process that a critical mass of the security community subscribes to, and that implementing them will measurably improve the security of computer users, the Internet, and the critical infrastructures that depend on it.

	Where can I get a copy of the guidelines?
	The guidelines are available from the OIS web site, http://www.oisafety.org.

	Who should use the guidelines?
	The intended audience for the guidelines is anyone who finds vulnerabilities in software products, or who maintains a software product in which security vulnerabilities might be found.

	Is the OIS saying that there’s only one “right” way to handle security vulnerabilities, and this is it?
	We recognize that several models for reporting and investigating security vulnerabilities are in use today. These guidelines describe how to implement one model, which is characterized by close collaboration between the Finder and Vendor. In our shared experience, we’ve found this model to be the most effective one, as it offers the best prospects for minimizing the risk security vulnerabilities pose

	Is it mandatory to use these guidelines?
	No. These are guidelines, not laws, and nobody is required to use them. In our experience, though, people who try these guidelines generally find them useful and beneficial.

	Suppose I can’t implement one or more of the guidelines. Does that mean I can’t use them?
	You can adopt the guidelines in whole or in part. We do suggest, though, that for the sake of clarity, adopters disclose in advance any parts of the guidelines that they choose not to implement.

	The guidelines clearly have in mind the case where the Finder wants to be actively involved in the investigation. What if the Finder just wants to report a vulnerability to the Vendor and not be part of the investigation?
	The guidelines are flexible enough to let the Finder select any desired level of engagement. There’s no requirement that the Finder be involved in the entire investigation. Similarly, a Finder who wanted to pick and choose the parts of the investigation it wanted to be involved in could do so.

	What’s to prevent one party from misusing the guidelines to support an ulterior motive? Won’t vendors use the process to cover up vulnerabilities? Won’t finders use them to “set up” vendors?
	The fundamental presupposition underlying these guidelines is that the Vendor and Finder are committed to working collaboratively and in good faith. If this isn’t the case, no set of guidelines will be successful. But with that said, the guidelines do offer several checks and balances. For instance, both parties retain the right to publish their findings, even in the case where they agree with the other party’s conclusions. And in the worst case, the guidelines provide a clear-cut means by which either party can exit the process if it’s not working. We believe that in most cases these checks will be sufficient to dissuade the participants from misusing the process.

	If these guidelines are so effective, why does there need to be a process for leaving it?
	Anytime human beings are involved in a process, there’s always a possibility of communications breakdown or, in the worst case, bad faith on the part of one or both of the parties. This process is no exception. The guidelines are a means toward the end of protecting users’ information systems – they are not an end unto themselves. If they are not leading toward a timely, effective resolution, it’s entirely appropriate for the parties to abandon them and try a different method.

	How do the guidelines account for the case where the Vendor isn’t a company, or where more than one company distributes a particular product?
	The guidelines provide a formal definition of the Vendor that covers most cases: the Vendor is the person or organization that developed the product, or is responsible for maintaining it. However, there’s a simpler (though less precise) definition that may help in the case where the development, sales, and maintenance duties are shared among multiple people or organizations: the Vendor is whoever you get patches from.

	The guidelines give the Vendor up to 7 days to acknowledge receipt of a vulnerability report. Why so long?
	Actually, the guidelines stipulate that the Vendor should acknowledge receipt of a vulnerability report immediately. Realistically, though, the guidelines need to accommodate for the possibility that a report might arrive during non-work periods like weekends or holidays, or less likely possibilities like temporary technical failures or human error. As a result they recommend that the Finder allow seven days before sending a formal request for acknowledgment.

	Why do the guidelines give the Vendor 30 days to investigate the report and develop a fix? Isn’t that too long?
	The guidelines don’t actually set a hard time limit. Every security vulnerability is different – the engineering complexity varies from case to case, as do the appropriate steps for ensuring the remedy is applied widely – and the guidelines recognize this fact. Rather than specifying a fixed time limit that could be too long for some cases and too short for others, the guidelines recommend that the Vendor and Finder negotiate a timeframe based on the specifics of the case. Thirty days is just the conventional starting point for the discussions.

	Why don’t the guidelines provide specific engineering requirements for the Vendor? For instance, why don’t they specify what an adequate level of testing is for a patch?
	In general, the guidelines say what should be done, but not how. This was a deliberate strategy – every security investigation has unique engineering requirements associated with it, and it would be unwise to try to specify what constitutes sufficiency in every case.

	Why don’t the guidelines instruct vendors on steps they could take to incentivize security researchers to work with them? For instance, the guidelines don’t mention whether vendors should pay finders for reporting security vulnerabilities to them.
	The OIS guidelines deliberately steer clear of attempting to change the current business ecosystem related to security research. That is, they don’t address the reasons why a person or organization might find a security vulnerability and choose to report it to a Vendor. Instead, they take as their starting point the fact that a Finder found a security vulnerability and chose to report it to the Vendor, and they focus on how to make the subsequent investigation and remedy as effective as possible.

	Why aren’t users or media listed as participants in the process?
	The guidelines exist for the purpose of protecting users’ systems, but users don’t play a role in investigating vulnerabilities and building remedies. That is, users are beneficiaries of this process but their role begins at the conclusion of this process, when the security advisory and remedy are released. Likewise, although the media can play a vital role in informing users of new security investigations when they’re published, they don’t participate in the investigations themselves.

	Do the OIS guidelines support fully disclosing information about vulnerabilities?
	The guidelines make it clear that vendors have an obligation to acknowledge vulnerabilities in their products and help users assess their risk and protect their systems. They also recognize that finders can play an important role, by providing information that corroborates, disputes, or augments the Vendor’s information. The guidelines include a number of measures to encourage fully disclosing timely, useful information about vulnerabilities, in way that respects its capacity to be misused. For instance, they encourage the publication of detailed security advisories, but only when a remedy is actually available. The guidelines also designate a specific type of data, termed supplementary data, for special handling.

	What is “supplementary data”, and why do the guidelines recommend special handling for it?
	Supplementary data is anything that directly enables people to exploit the vulnerability; for instance, point-and-click tools that exploit the vulnerability, or step-by-step instructions for carrying out an attack. The guidelines single this data out for special treatment because, historically, publishing it indiscriminately increases the risk of users being attacked. The guidelines recommend that a 30-day grace period be observed, during which supplementary data should not be published.

	Some have argued that supplementary data is useful in some cases and its publication shouldn’t be delayed. Why do the guidelines advocate differently?
	We agree that it can be useful. For instance, it can aid antivirus and intrusion detection vendors in developing robust defenses against the vulnerability. Likewise, it can aid academic research into software security techniques. However, it undoubtedly also can pose a threat to unprotected systems. The 30-day grace period is a compromise intended to balance these competing interests. The guidelines recommend that, during the first 30 days after the availability of the remedy, the interest of users should predominate and supplementary data should only be shared with people and organizations that are directly involved in developing countermeasures against the vulnerability. Once users have had a decent interval during which to protect their systems, the interest of the research community predominates, and the data can be shared without restriction.

	Do the guidelines mandate that supplementary data be released at the end of the grace period?
	No. The guidelines recognize that there are a variety of opinions exist regarding the handling of supplementary data, and they do not require that adopters publish it, even once the grace period expires.

	Does the source code for a patch constitute supplementary data? What about a description of the underlying cause of a vulnerability?
	Neither of these constitutes supplementary data according to the guidelines, because in both cases some analysis would be required to derive a means of exploiting the vulnerability. Except for the very narrow cases described above, all data related to a vulnerability could be published in conjunction with the availability of the remedy.

	Do the guidelines give OIS members an “inside track” that will make them privy to supplementary data?
	There’s no preferential treatment for OIS members. Although some members of the OIS are involved in intrusion detection, antivirus, and infrastructure protection, there’s no requirement to share data with them.

	Why don’t the guidelines mandate the use of a Coordinator or Arbitrator?
	Coordinators and Arbitrators both can be extremely helpful to a security investigation. However, they aren’t needed in every case, so it wouldn’t be appropriate to make them mandatory.

	How often will the guidelines be updated?
	By rule, the OIS will review the guidelines at least every two years and offer amendments based on adopters’ feedback. However, we plan to do the first review six months after its public release.

	How can I provide feedback on the Guidelines?
	Comments, suggestions, and feedback can be sent to feedback@oisafety.org. Because of the volume of mail, we can’t respond to individual letters. But we do read every one, and try to implement as many suggestions as we can.