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."
"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"
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.
Well, i don't think obscurity can really improve security. Most hackers find the information they need anyway. This is just an attempt of the software companies to cover up their lousy code. If they would implement secure code in the first place, none of this would be nessecary. Way to go closed source!
- Never underestimate the power of human stupidity.
To me, it sounds like this is only relevant to organizations that maintain closed-source code trees, since the impetus on fixing the bug lies with their in-house development staff rather than with a decentralized team of programmers. It's to "protect" the company's bottom line from being affected by the propagation of bug exploits for which they have not done their part in fixing.
On the flip side, this mentality rarely exists in open-source code projects due to the lack of a need to safeguard against decreased shareholder value. Also, IMHO, open-source developers continue to maintain a sense of pride in their work that is for the most part missing in closed-source projects due to the direct recognition (and therefore, culpability) that is possible by putting your name to a piece of software that others can peruse and make comments and criticisms about. With closed-source projects, the company's reputation is primarily at stake while their programmers are largely hidden behind the web of corporate logos and NDA's, and therefore may not have reasons as strong as those of OSS developers to fix and release bugs in a timely manner.
So in other words, it's to protect lazy software companies from being held accountable for their own poor coding practices and lacadaisical maintenance policies.
Rule #1 -- Politics always trumps technology.
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.
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.