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.
The author writes:
"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."
This is a stunningly naive view of the infosec market.
Researchers are seldom in direct contact with
businesses. Instead, researchers are usually jockying for interest
or salary at other AV firms. So being notorious
helps researchers, since it lets them demand
larger compensation for their work. They seldom
have business dealing with vendors who make the
vulnerable software.
If you only model the dynamics of the AV community
as two actors: (1) big Fortune 500s and (2) AV vendors, then you
overlook the relation between the researchers and
the AV vendors. This dynamic is (a) valid, (b) driving, (c) the
fundamental factor in exploit research.
If you want to change the problem of "48Hr leak
windows", you'll need to understand this
financial and professional aspect of the problem.
Writing diatribes in ZDNet is not going to
change things, since your only readers are
helpless AV employers, and bemused RE workers. If anything, superficial analysis
like this reveals your level of sophistication,
lets competitors understand what little involvement
you have with the AV industry, and telegraphs to
AV companies a large degree of naivete.
I don't mean to be offensive or rude, but I
was frankly shocked when I read such a simple
analysis from a person who should otherwise be
well informed.