> I'm following up a story at present on a 'Responsible Vulnerability
> Disclosure Process' draft that was submitted to and recently rejected by
> the IETF. The draft aimed to create a common framework for releasing
> details about security flaws.

Ah-ha, another interesting topic!

> Key points of the draft are ensuring that the discoverer of the
> vulnerability informs the vendor of the affected product, and then waits
> until a patch is ready before releasing the information publicly. It also
> states the vendor should notify the discoverer of receipt of the flaw
> report within 7 days and should try to resolve the problem within 30 days.
> 
> Is the issue of bug reporting processes an important one? If so, why?
> Are there inconsistencies in the way flaws are reported at present?

Reporting of flaws, if handled inappropriately, can be a massive pain for
both users and vendors/authors. Users can be exposed to increased risks
if the discovery is genuinely "new" and the vendor takes time to produce a
fix or workaround. Needless to say, this produces dissatisfaction amongst
the user base of a product, which impacts on the vendor.

There are currently inconsistencies in the way flaws are reported at the
moment, but a substantial number of researchers already follow responsible
disclosure guidelines, such as those proposed by "Rain Forest Puppy" in his
RFPolicy <http://www.wiretrip.net/rfp/policy.html>.

> Is the potential threat from flaws increased by the risk of the discoverer
> going public before telling the vendor/waiting for the vendor to make a
> fix available?

It certainly can be; it depends entirely on whether the disclosure is news
to the "black hat" community or not.

If individuals in that group have known about the issue for some time,
there's a good chance that at least the "elite" have been using and abusing
the flaw to compromise systems for some time. If that's the case, then
getting a public advisory out as soon as possible, regardless of the impact
on the vendor, may well be the best policy. Doing so puts the users on an
equal footing with attackers and allows them to do their own risk/benefit
assessment and make the choice as to whether or not they wish to continue
using software with known flaws.

If there is no information that suggests to the researcher that the flaw is
known by others, then some kind of responsible disclosure policy should be
adopted. Releasing a public advisory without giving the vendor time to
create a fix can open a window during which attackers can create exploit
tools (i.e. before the vendor has a patch available and the users have had a
chance to install it). Some vendors are very unresponsive to such "polite"
approaches, however, and may need the threat of public disclosure to coax
them into actually understanding the problem and behaving responsibly
towards their customers. Without a fix, users are still exposed to risk, as
sooner or later, someone else with the requisite skill will independently
re-discover the flaw and create an exploit tool for it. For this reason, I'm
against indefinite "grace periods" for vendors.

> Would a standardised reporting system be effective in terms
> of protecting users' systems or a vendor's credibility?

Certainly, but given the anarchic way the security research community works,
it'll be nigh on impossible to enforce any such policy uniformly.
Professional researchers working for reputable companies will doubtless
follow anything that's credible, but many researchers perform their research
in their free time, often without reward, and owing the rest of the world
nothing. Hopefully, they too will see that at least attempting to disclose
vulnerabilities responsibly benefits them too, both through recognition and
their career.

> Who should manage this type of standard? The IETF, or a similar body?
> Corporate/government-backed groups?

I do fear that some well-meaning, but mis-advised government agency  will
eventually draft a draconian law that discourages researchers from
publicising their findings at all. This won't help users one bit; attackers
will still find flaws and exploit them - they'll just keep them even more
closely guarded.

> Are there other ways of improving the process of security flaw reporting
> aside from the above-mentioned points from the draft? (Link to the draft -
> www.ietf.org/internet-drafts/draft-christey-wysopal-vuln-disclosure-00.txt)
> 
> A response to any or all of the above questions by Wed am would be greatly
> appreciated.

Best Regards,
Alex Butcher
Security Analyst, Assursys Computing Ltd.