There's a myth about security researchers that goes like this: Vendors are made up of indifferent slugs who wouldn't fix security vulnerabilities quickly -- if at all -- if it weren't for noble security researchers using the threat of public disclosure to force them to act.The reality is that most vendors are trying to do better in vulnerability handling. Most don't need threats to do so, and some researchers have become the problem.
In so stating, I thank those researchers who are genuinely motivated by the public good, most of whom never get the headlines of their more notorious brethren. I also acknowledge that the vendor community needs to improve the quality of commercial software so we have far fewer vulnerabilities.
Here's a rundown of some of the notions that play into this myth about how security researchers interact with software makers.
1. You should be able to fix this in two days
Some researchers think they can push vendors to work faster by threatening to "tell all," and that if vendors really tried, they could meet the researchers' arbitrary 5-day, 15-day or 30-day "fix window." In reality, many of the best researchers aren't the ones you hear a lot about, because discretion is their stock in trade.
In reality, when a researcher reports a vulnerability, the fix might be a two-line code change and take 20 minutes to do. However, getting the fix in customers' hands often takes weeks. Remediation may require the vendor to analyse whether the bug is specific to a particular version/platform or all versions/all platforms or analyse whether related code has a similar problem (to fix the problem everywhere). Vendors may also need to provide fixes on multiple versions/platforms or bundle multiple security fixes together to minimise patching costs to customers, not to mention various testing on the products shipped to ensure the fix does not break anything else.
As an example, Oracle has done 78 fixes for a single vulnerability, which took more than five days to complete. We also release bundled fixes quarterly on dates tied to financial reporting calendars (e.g., many customers will not touch their production systems during quarter-end).
A two-line code change can take five minutes, but getting a fix into customers' hands in such a way that they will apply it takes way more than a few minutes.
2. The more notorious I am, the more business I will getMany researchers think that the more vulnerabilities they disclose publicly, the more vendors will hire them as consultants. Some engage in explicit threats ("Pay me $X or I sell this to iDefense") or implicit threats ("Fix it in the next three weeks because I am giving a paper at Black Hat"). Not all researchers are noble-minded, and not all vendors are indifferent slugs.
In reality, many of the best researchers aren't the ones you hear a lot about, because discretion is their stock in trade. They are often far better than the "look what I did" researchers who run to the press with their latest vulnerability pronouncements. The circumspect researchers are the only ones we hire and the only ones we recommend to our customers.
Also, notoriety can backfire: I've known customers to terminate contracts with researchers for releasing exploit code. Researchers, you might get applause from hackers when you show off at Black Hat, but businesses will not pay you to slit their throats. With knowledge comes responsibility.
3. I should always get credit for vulnerabilities I findMost vendors credit researchers who report vulnerabilities so that researchers will continue to work with them. Also, saying "Thank you for working with us" is just good manners. The myth is that researchers are always entitled to credit.
In reality, when a researcher puts customers at risk by releasing exploit code for a vulnerability before the vendor has had a chance to fix it, it's ridiculous to expect the vendor to say, "Thank you for putting our customers at risk." I've never had a customer ask us for exploit code or exploit details, though they do want enough information to do a risk assessment.
In some cases, vendors may actually be giving more credit than the researcher deserves. For example, Oracle finds more than 75 percent of significant security vulnerabilities in-house. Yet if a researcher finds an issue that we already found internally but may not have completed the fixes for, we typically still give that person credit, anyway.
The reality is that not all researchers are noble-minded, and not all vendors are indifferent slugs. The other reality is that the highest purpose of everybody in this game should be protecting customers who use these products from harm.
biography
Mary Ann Davidson is the chief security officer at Oracle, responsible for security evaluations, assessments and incident handling.
Linkedin 
RSS Feeds 
Newsletters 
Alerts
