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
Section 9
All OIS participants must either look like Peter Norton or Steve Balmer. Minimally this can be preformed by wearing khaki pants, blue denim shirt, and sensible shoes.
No person or organization wearing black, having purple hair, or listening to obscure music may participate as either a Finder, Vendor, Coordinator, or Arbitrator.
Heil Sig! -Rob
I welcome the day when we no longer have security bugs.
"As discussed in paragraph 7.3.7 above, the Finder and Vendor should act in concert to release their respective advisories nearly simultaneously, and only after a remedy is available."
It's all in that last phrase "only after a remedy is available"
Personally, I've always thought that a good disclosure policy would be one that informs the software's source of the problem and then waits some period of time befoer disclosing to the public.
Of course, I'd reccomend a very short wait time, probably between 48 hours and one week. Just enough time to solve the problem if enough resources are diverted to it but not long enough to allow anyone to ignore the problem until later.
1337 Reveals limited disclosure plan
Eight hacking groups join together to set an official standard for limiting disclosure of software security holes.
#1337, Efnet â" Eight computer hacking groups rounded up a three-day Exploits in Computing Forum on Thrusday by formally announcing a coalition against full disclosure of vulnerability information, ending a week of intense speculation, and immediately sparking controversy.
WanSan, TCPuke, NetLoft, HeavySak, BitEvil, SYNergy, HPLat, and DownScope joined together to declare they would immediately begin following a policy of limited public disclosure of security vulnerability information. Members of the coalition who discover new vulnerabilities will omit from their initial public advisories any details about how a hole might be exploited in an attack, and will not include code that demonstrates the bug. Thirty days after the first advisory, a more detailed notice can be released under the rules. Full disclosure of the vulnerabilities will be shared only among the members for âtestingâ(TM) purposes.
"We felt that as responsible industry leaders, we, as a voluntary organization, are going to follow a set of reasonable standards," said DXNo, manager of 1337â(TM)s intrusion exploitation, in an interview.
1337 will also draft a proposed international standard for notifying vendors and the public about newly-discovered software security bugs, following the group's limited disclosure ethic. The organization will admit new members, under an as-yet unwritten set of bylaws. The initial draft of the limited disclosure ethic will limit the disclosure to the home pages of the vulnerable sites.
A chief objective of the group is to discourage 'full disclosure,' the common practice of revealing complete details about security holes, even if publication might aide attackers in exploiting them. The group believes that any type of full disclosure would assist software vendors into patching various vulnerabilities before they can be widely exploited.
Publishing complete information, and sometimes "exploit" code that demonstrates a vulnerability, is de rigueur among many computer security professionals, who argue that malicious hackers can acquire the same information themselves, and that network administrators and security gurus often need technical details to properly defend themselves from attack.
But Culp criticized the practice in an essay published on a Microsoft Web site last month, and blamed "information anarchy" for the epidemic of malicious worms that have struck the Internet in the last year. "It's high time the security community stopped providing blueprints for building these weapons," Culp wrote.
Under the plan, member groups would share detailed information during the 30-day grace period with âoeother communities in which enforceable frameworks exist to deter onward uncontrolled distribution.â The last category would allow member groups to share details with one another. "They're not going to ban it among themselves," says Levy. "They might be willing to limit the public access to this information, but I highly doubt that they'll limit it among each other."
"People have to do it Microsoft's way or they'll have this group telling them that they're acting irresponsibly," says Maiffret. "It's going to drive people into the underground, and could lead to more people breaking into computers." The majority of members in 1337 agree with Maiffretâ(TM)s assessment.
"We are not trying to form a secret society of exploiters," says CKLawz "We are just creating a standard... This represents one of the first process standards between security companies and vendors."
wyZopa1 estimate that it will take one or two months to produce drafts of the proposed RFCs. He emphasizes that the standards would not just limit vulnerability disclosure, but would also spur vendors to be more responsive to security vulnerability reports. "My goal in the RFC is to have equally stringent standards for vendors and exploiters," says wyZopa1. âoeWe worked hard to discover these vulnerabilities, the developers should work just as hard to fix them. Providing them with all our tools without compensation is not what software development is about.â
Karma: SELECT `karma` FROM `users` WHERE `userid`=138474;
Face it. Anyone can do security. All you need is the will, the drive, the talent, and the know-how. Which means, me, the average geek, ex-blackhat hacker, technologist, futurist dude.. can play with stuff, learn stuff, share with others, and build my CAREER off it. Not after this.. This would keep all the knowledge I gain from other professionals, from bugtraq, etc, out of my hands, forcing me to subscribe to these people's services, philosophies, etc... no. I will not. This will not stop hackers, this will only stop the admins who are trying to keep everything together. This will be a tax on the admin who manages 1500 machines, and has no time to read simple stuff.. Hackers, don't need bugtraq. Its useful, its a resource, etc, but if they want in bad enough. Fuck em all.
Why don't they ask themselves why is their product so weak and vulnerable, instead? How much of those vulnerabilities were exposed and fixed *because* they were exposed? It's a GOOD thing. There was a bug, people found it, tried reporting it, got told to fuck off, published it - and the bug got fixed.
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.
All you need is the will, the drive, the talent, and the know-how.
Well, that's a short list just anyone could sort out in a weekend
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
FYI, the 11 companies involved are:
u ardent
Microsoft
@stake
BindView
SCO
Foundstone
G
Internet Security Systems
Network Associates
Oracle
SGI
Symantec
-Mani
Why would anyone follow these guidelines? It might piss off these companies, but anyone who really cares about security would realize that giving the vendors the exclusive right to disclose flaws (regardless how much time has passed or how many systems have been compromised) prevents people from making an informed decision to yank these programs until a solution is identified.
Mapped to the real world, it's like some idiotic Police Chief knowing damn good and well that several pizza delivery drivers are mugged every night when they go into a four-block area... but refusing to say anything - not even warning these drivers to avoid the area for a while - until after the muggers have been convicted, sentenced, and in prison for a month.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
You have to sign a non-disclosure agreement in order to see the anti-disclosure plan
can't hurt me.
rehab, captain ahab, you're chasing the wrong fish!
Bugtraq is one of those 11 companies. (Bugtraq is part of Symantec)
The document mentions only Finder, Vendor etc. What about the user? Suppose the Finder tells the vendor, "Hey, there's this bug in Passport Password Reset". Now the vendor (Microsoft) works in conjuction (collusion?) with the finder, and says, Look - this is a trade secret. Wait for a few months, and we'll watch if anyone's using this bug except us.
Poor Joe ServicePack is the one affected, and he figures nowhere in this scheme of things.
If you keep throwing chairs, one day you'll break windows....
Living in the D.C. Metro area, I was very upset when hearing that the D.C. Police Chief had been against revealing the make of the snipers' car when they finally found it out. Once this information was released, the snipers were caught in 2 hours or so, IIRC.
I agree with the parent poster - this seems like an apt analogy. At least if a non-negligible number of bugs, patches, fixes, or workarounds, even if just temporary, come from unexpected sources outside of the vendors or finders.
Shouldn't the title to this story have been "Group Discloses Anti-Disclosure Plan"?
Tarsnap: Online backups for the truly paranoid
This proposal basically calls for the public to act in the same was as an employee would at finding a bug in the software. Perhaps I missed something here but if a bug is sourced in the public domain it should be disclosed there as well.
If they want to put me on the payroll, I'll QA and report their software using this convenient bug ticket they've provided;)
"It's not your information. It's information about you" - John Ford, Vice President, Equifax
US Democracy:The best person for the job (among These pre-selected choices...)
I'm just waiting for Bruce Schneier (author of Applied Cryptography and founder of Counterpane Internet Security. Oh yeah, and author of the Twofish and Blowfish algorithms to boot.) to comment on this in the next Cryptogram...
;)
I'm sure he'll have some interesting things to say.
Large print giveth, and the small print taketh away
Full disclosure only stimulates vendors to come up with a patch quickly. It's their fault in the first place there was an exploitable bug. We don't need a law to regulate bug disclosure. This is security through obscurity and it doesn't work. Information will leak and a limited number of people will take advantage of it anyway, while I, the use won't know to shut that buggy service down.
Let's call a spade a spade: companies like Microsoft should be liable for negligence when they sell buggy software for lots of money, at least for the amount of money the user paid for the software. Now, instead, not only do they want to be able to release buggy software with impunity, they also want to get free testing and bug fixes from users, and all that without the embarrassment and risk of having their bugs revealed.
There are precedents where doing this could be plain wrong, like in the last WebDAV vulnerability in IIS, that was discovered after being actively exploited by black hats. Hiding the facts will not stop crackers to exploit something they know first, and will only make victims unaware of what could or have happened with their sites.
The only time most of those guys release patches in a reasonable timeframe is when they're looking at a PR or a lawsuit debacle. If I find a vulnerability, I'll shoot the vendor an email and see if they hop to it or not. If they hop to it, great. If they blow it off, then it's posted publically before they patch.
That's how it'll always be handled by some people that find vulnerabilities. That's the way it's been handled in the past, and the world hasn't ended. It's just occasionally uncomfortable for a big player that sat on their ass for too long. Tough toenails. They need to put the same energy into just fixing reported problems that they do into trying to put this complicated mechanism in place to cover up problems that they fail to addres
obscurity will eventually always fail as a security protocol.
Being the cost-minimizing/profit-maximizing organizations that they are, they will always wait forever to incur new costs (like fixing bugs) until somebody "lights a fire under them." That's why quick public disclosures is important, because the bug *will* be discovered by the bad guys sooner or later, so it is better to fix it soon than wait for later.
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.