Slashdot Mirror
Group Releases Anti-Disclosure Plan
dki writes "SecurityFocus reports that the Organization for Internet Safety (OIS), a group of 11 of the largest software and security companies, has released a public draft of a proposed bug disclosure standard. The document outlines a process for reporting and disclosing bugs that aims to eliminate releasing exploits to the general public. Not surprisingly, the OIS was founded out of a Microsoft-hosted security conference. Comments on the draft will be accepted until July 4th; the final copy will be released at the Black Hat Conference in Las Vegas."
"7.1 Advance Notification
This document does not address processes for notifying selected groups of users about vulnerabilities in advance of the general population. While such âoepre-release notificationsâ are sometimes done, and in very well-controlled cases can be carried out effectively, they are not a recommended practice in the general case. Because this document addresses only activities that are appropriate for typical cases, advance notification is beyond its scope."
"8.2 Use of Third Parties
In some cases, investigations may be made more effective by the use of people or organizations other than the Finder and Vendor. There is no requirement to use a third party, but in cases where one is used, it should be a person or organization that the Finder and Vendor have agreed to in advance of its involvement. Characteristics of a good third party include sound judgment, freedom from bias or conflicts of interest, demonstrated technical expertise in security technologies, and discretion regarding the handling of the information it is entrusted with to resolve the dispute. Third parties normally serve in a voluntary capacity, as a service performed in the public interest."
Members of the OIS... (From the OIS site http://www.oisafety.org/about.html#1) What companies are members of OIS?
The current members are: @stake, BindView, Caldera International (The SCO Group), Foundstone, Guardent, ISS, Microsoft, NAI, Oracle, SGI, and Symantec.
We're actively soliciting software vendors and security research companies to join. Send OIS your feedback on the draft until July 7th! (From the OIS site http://www.oisafety.org/resources.html) "Comments on the Security Vulnerability Reporting and Response Process should be sent via email to draft-feedback@oisafety.org. Comments should include your name, address, and email contact information. Organizations submitting public comments should include the name and title of the person submitting the comments. While OIS will respond to as many comments as possible, because of the anticipated volume of comments, we cannot guarantee an individual response to every comment."
Heil Sig! -Rob
2.2 Phases
The basic steps of the Security Vulnerability Reporting and Response Process are:
# Discovery. The Finder discovers what they consider to be a security vulnerability (the Potential Flaw).
# Notification. The Finder notifies the Vendor and advises it of the Potential Flaw, and the Vendor confirms that it has received the notification.
# Investigation. The Vendor investigates the Finderâ(TM)s report in an attempt to verify and validate the Finderâ(TM)s claims, and works collaboratively with the Finder as it does so. # Resolution. If the Potential Flaw is confirmed, the Vendor identifies where the Flaw resides, then develops a remedy (in the form of a software change or a procedure) that eliminates or reduces the risk of the vulnerability.
# Release. In a coordinated fashion, the Vendor and the Finder publicly release information about the vulnerability, along with its resolution.
Now look at this under the context of the recent MS Passport Vulnerability to see how effective this process is.
As an aside, this draft is backed by MS and SCO, amongst other companies. It'll be interesting to read the amount of bashing this gets over the weekend.
FYI, the 11 companies involved are:
u ardent
Microsoft
@stake
BindView
SCO
Foundstone
G
Internet Security Systems
Network Associates
Oracle
SGI
Symantec
-Mani
Bugtraq is one of those 11 companies. (Bugtraq is part of Symantec)
90%? Maybe that's a little bit too much, but all in all, most other 'higher' languages are written in hm, well, C/C++.
Using something that was written in C/C++ doesn't really exclude buffer overruns, just minimizes it.
The Sig, the sig
http://www.computer.org/proceedings/sp/1046/104602 14abs.htm
This was presented at the "2001" Oakland conference, held in 2000.
There were some fascinating points in the presentation that weren't spelled out in the paper.
Disclosure didn't matter for the exploits they studied. That's right, didn't matter, for good or for ill. The rate of exploitation in the wild didn't spike after public announcements. The exploitation rate didn't go down after patch release.
Events that did matter included the public release of scripted exploits, and the cycle of the academic year.
Exploitation rates finally faded away over time but the fade-out curve didn't relate to patch adoption or availability. In fact, sometimes an exploit would flare up again after fading away. The authors attribute the decay of the exploit rate to boredom on the part of attackers, and maybe to the gradual replacement of vulnerable software.
If they're right, the policy lessons that follow (you're getting my opinion here) are:
o Disclosure is harmless and should be allowed
o Patches should be encouraged. They won't stop the next Code Red but they have benefit for anyone willing and able to install them.
o Distribution of attack scripts has a high social cost.
o When a vendor ignores a problem until there's an attack script in the wild, you've got a dilemma.
Here's a brainstorm: full liability for the damages caused by exploitation of a security hole. Liability lands on the vendor if they ignore a bug report that includes a demonstration attack, lands on the script author if the attack goes into the wild before there's been a chance to fix the problem.