http://www.zdnet.com.au/insight/security/soa/Security_researchers_problematic_bunch_/0,39023764,39204741,00.htm
By Mary Ann Davidson
Special to ZDNet
05 August 2005
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 get
Many 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 find
Most 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.
_________________________________________
Attend ToorCon
Sept 16-18th, 2005
Convention Center
San Diego, California
www.toorcon.org
This archive was generated by hypermail 2.1.3 : Thu Aug 04 2005 - 22:24:25 PDT