Slashdot Mirror

← Back to Stories (view on slashdot.org)

Internet Draft on Vulnerability Disclosures

Posted by michael on from the end-information-anarchy dept.

Cowboy71 writes: "An interesting posting on Bugtraq by Stephen Christie announcing the release for comment of an internet-draft "Responsible Disclosure Process" document, prepared by himself and Chris Wysopal of @stake. You can view the full paper at the IETF site."

1 of 114 comments (clear)

  1. Anything new? by Proaxiom · · Score: 5, Insightful
    I've been going through it, and I can't seem to find any points on which this differs from the existing full disclosure model that most of the security community already follows.

    There are, of course, people who discover vulnerabilities and immediately publish all the details without notifying the vendor, but an RFC is hardly going to stop.

    All the same, guidelines are nice. I'm a little skeptical of vendors sticking to the suggestions. To many SHOULDs and MAYs.

    To recap, the proposed RFC suggests 7 stages in fixing a vulnerability:
    1. Latent flaw. The flaw exists undiscovered.
    2. Discovery. Somebody finds the flaw (the 'Reporter').
    3. Notification. The Reporter notifies the Vendor.
    4. Validation. The vendor verifies the flaw.
    5. Resolution. The vendor fixes the flaw.
    6. Release. The vendor publishes the flaw.
    7. Follow-up. Analysis of the resolution.

    What a nice world this would be.

    It usually works like that right up until step 5. Here's what really happens:
    5. Denial. The vendor denies the flaw really exists, setting his best PR guys on the job.
    6. Demonstration. The Reporter creates exploit code to prove to the vendor that not only does it exist, but it is serious and should be fixed.
    7. Diversion. The Vendor changes the subject by publicly attacking the Reporter for creating the demonstration, labeling it a "Hacker Tool".
    8. Publication. Third party bug tracking systems and security entities make knowledge of the vulnerability widespread to try to scare the Vendor's customers.
    9. Fix. The Vendor repairs the vulnerability, while still denying that it has any real significance.
    10. Release. The Vendor shuffles the release into a service pack or update, and puts it on his web site.