Slashdot Mirror
Internet Draft on Vulnerability Disclosures
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."
Its fair that there has been some disagreement between parties, but the current state allows corporations to brand anyone who discloses information responsibly (after appropriately informing the company of a vunerability) as a blackhat hacker and the corporation as a wounded party. They don't care to mention that their vunerability has resulted in countless manhours of sys admin time to correct the fault, deal with the Nimda/Code Red of the week and apply patches - and the corporations often maintain that they should be allowed to keep the information secret from responsible sys admins well after script kiddies are trading the exploit.
Having a standard document will allow mature parties to avoid being branded crackers if they can follow a published disclosure protocol.
You shank my Jengaship!
a day or 2 ago, i started thinking about the DMCA and how those who support it defend it...
usually, they say something like "its to prevent hackers from learning about and exploiting the weaknesses before we have time to fix them" or some similar reason. fair enough, this is valid; i can see how this would be a good thing for preventing software piracy and that sort of thing.
But, when it comes to security and vulnerability to attack, don't I have a right to know? Did I waive that right in an EULA? I'm pretty sure that if this happened with any other kind of product, the government would swoop down and set things right.
Think about it. What if ford had kept the firestone recall under wraps (this "vulnerability" can "crash" the "application" and we don't want hackers/competitiors to exploit it). Yeah- good plan... But I'm the one riding in it! This situation sounds pretty ridiculous when its a "real world" product and not software.
Has anyone else come to this conclusion or know how consumer protection got written out of the DMCA? I'm scratching my head here.
Somewhere on this page I have hidden my signature.
This document is no more than a formalization of @Stake and Microsoft's desire to see the public disclosure that takes place on Security Focus and Cert come to a grinding halt. In their process, the community isn't informed of a the hole/vulnerability until after there's a fix.
I feel that this gives the companies no motivation to fix the hole. I would instead suggest that when the "reporter" informs the company, The company receives a grace period of 30 days to work on a fix after such a point the "reporter" could come forward, and release the hole publically if he/she/it felt that the company wasn't making a good faith effort to fix the problem. Of course this whole process is null and void if the program is open source/free software and the "reporter" releases a patch for the flaw at the same time the "reporter" releases the flaw.
Ponder that my friends.
troll Function: noun Date: 1869 a lure or a line with its lure and hook used in trolling troll Function: noun Etymology: Norwegian troll & Danish trold, from Old Norse troll giant, demon; probably akin to Middle High German trolle lout Date: 1616 a dwarf or giant in Scandinavian folklore inhabiting caves or hills I for one care less for them.
It is interesting that Chris is in favor of controlling full disclosure. I don't see how he can be objective, since @stake is one of a handfull of security product vendors that is now in bed with Microsoft. They want to limit the accessibility of inforomation to a select few and increase the time limit before the disclosures are made publice. This works well for them as they can then sell themselves as a one of the select few in the know, besides the person who really discovered the vulnerability and released it into the wild. What a bunch of hypocrites.
OK, I've made an attempt to read the document critically. It reminded me of some of its more obvious failings though:
I have to admit that it's a good general solution for presentation to and ratification by the Microsofts of this world - companies for whom marketing departments have more control over release dates than systems engineering or test departments...
...but these are the very companies that are LEAST likely to pay attention to the words of the technological minority, in favour of placating the fickle majority. Anyone else see a problem here??
jer
We may be human, but we're still animals
- Steve Vai
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.
This draft (or rather the idea of this draft) was discussed in some detail at the SAAG meeting at the last IETF. A number of people objected to the idea of standardizing stuff like this. The danger is that the MUSTs and SHOULDs could end up in US law. Also there was a previous effort by the GRIP working group which caused a lot of tension with vendors.
While there were a few dissenting opinions, most people agreed that most intelligent thing to do is to notify the vendor, give them some time to fix the problem, and then publish the vulnerabilty. However, no one spoke out in favour of the formalized system as described in the draft.
-a
How to rationalize theft.
This process seems to be heavily biased towards the vendor and does not seem to offer very much to the community at large. A vendor not interested in exposing vulnerabilities could easily exploit this process.
/reported/ discovery.
Simply setting up the recommended email address and generating an auto-reply (or the equivalent with form letters and an assistant) to all reports would acknowledge all claims. This auto-reply could immediately include a request for extension. Delay the auto-reply from 4-7 days, put snapshots of similar keyword searches from the internal knowledgebase, and you have a suitable claim for an extension.
Any disclosure of the flaw before the extension and the vendor can quite happily say that they are following the process and the reporter is not. Meanwhile the vendor themself has no reason, what-so-ever to follow the remaining sections of the process, then can simply allow all periods to lapse and proceed on their own accord. This allows the reporter to be labelled in bad faith, whereas the vendor can artificially appear to act in good faith.
Not following this best practice would furthermore not generate any additional bad publicity for the offending company. Vendors operating in bad faith will already have a negative image. Vendors operating in good faith will have an extra overhead that they may not be able to support if they follow this process.
It additionally appears vendor biased because it does not offer any benefit to the security community, or the user community at large. Prevention of exploits does not appear as a goal of this process. Nor does protection from exploitation of flaws. Unless of course we make the unreasonable assumption that exploits do no appear until over 30 days past the point of
These "musts" are not going to end up in a US law any more than the "musts" in the DHCP spec ended up in a law. When I look to buy a home router that does DHCP I check it against the RFC, if it doesn't do the musts, I return it. So now we could have an RFC for how responsible software companies act, if they don't follow the RFC, don't do business with them.
Free cell phone tracking
I can even arrange to have Steve Jobs anally rape you!
How? Are you going to make them buy a Macintosh?
When you are implementing a system that uses an RFC, it is solely your responsibility to comply with the requirements. The same goes here.
The assumption is that both the Reporter and the Vendor act in good faith.
Think of this as a proposed guideline that researchers and vendors should follow. Vendors are still free not to fix bugs, and researchers are still free to recklessly publish exploits to the world at large.
But if they both followed the instructions, things wouldn't be too bad. Of course if a Vendor persists in denying a bug's existence then the Reporter can, and should, publish the details. This is how things work most of the time already.
You should note an earlier poster who mentioned concern that if this turned into an RFC, it might eventually lead to legislation. Which would be a bad thing.
Microsoft PR-FUD-etc. Best quote "Mundie: Microsoft has always had an interest in making secure products", just not enough to make it a priority.
Microsoft, world's largest software producer Posting this anonymoustly, probably get modded as -1 broken record, but some reminders.
announces stopping new development to fix bugs, translation "Whoa, yeah, we got bugs big time, huge bugs, bugs MIB couldn't swat!"
They want the messenger to shup up, already.
Virii are terrorism, so leaving holes must be patriotic...
Somewhere in the distant past (I can't find it with the weak /. search) they withdraw from Bugtraq
Full disclosure of vulnerabilities is as important for software security as free journalism is for figthing koruption. Defining some rules for responsibly doing that is a step in the right direction. However - since M$ has a history of ingnoring industry standards I do not have high hopes that it will actually improve something...
-- Contradictions only exist in thought - not in reality.
- Vendor: the producer of software in which vulnerabilities are discovered (e.g. Microsoft)
- Reporter: someone who finds a security hole (typically someone in the "security community")
- Coordinator: someone who mediates between Reporters and Vendors
- Customer: end-user of vendor products
- Security Community: the usual researchers, sysadmins, etc. who are trying to improve overall information technology security (it doesn't say whose security).
The first thing I notice is that while there are several places where it says the vendor MUST do this or that (e.g. the vendor MUST respond to vulnerability reports within 7 days), and several things the reporter SHOULD do (the reporter SHOULD provide Vendor with all known details of the issue), there's nothing the reporter MUST do. So it's not an attempt to impose mandatory policies on reporters through a standards process.The recommendations make a reasonable attempt to protect vendors and customers (i.e. it doesn't go for the zealous instant-full-disclosure approach) without allowing reports to go ignored for too long. It basically says the vendor should get 7 days to initially respond to the report, then 30 days to fix the problem, and then can request a 30 day grace period to get the fix out to customers before the reporter releases details to the public . If the reporter goes along with this, the vendor must credit the reporter in its own public announcement of the fix.
It's kind of weird, seeing an internet draft using protocol-like terminology to describe how people and companies (rather than computers) are supposed to interact with one another. I hope this isn't supposed to be an RFC, or else that this kind of thing is normal for the IETF (I haven't read that many IETF docs). I've never seen a thing like this and it seems to turn the IETF into an even more political body than it already is. I thought the IETF was supposed to make recommendations about bits and packets, not people and companies.
Anyway, I can take issue with some of the points in the document, but at first glance there's nothing in it that I'd call outrageous. It seems like a genuine effort to find a good intermediate policy between instant full disclosure (and instant widespread exploits) and leaving stuff secret forever (letting exploits spread without the public knowing). Whether that policy is the optimal one is of course a matter of opinion and reasonable people can differ on it.
The document's authors came from several different camps (two names I recognize are Bruce Schneier's co-author Adam Shostack (presumably on the full disclosure side), and Microsoft's Scott Culp representing the Evil Empire) and it looks like they managed to arrive at a consensus. I guess that's a good sign and I hope Bruce and/or Adam will publish their own opinions of the draft soon.
This document seems to downplay the role of public disclosure, and instead inserts the coordinators as the middlemen between reporters and vendors. This is fine for Bugtraq, CERT, and all the other so-called "coordinators," but where does that leave the public? Several times, the document addresses public disclosure, but only in the vein that vendors can choose to withhold recognition or other feedback if a reporter chooses to go public with the information.
I think this document is a big win for the coordinators, but a big loser for the public.
For the most part they are opponents of the full disclosure model, and they would love to have rules imposed on people who discover vulnerabilities.
So if you discovered a bug and published it's details without notifying the vendor or going through the correct process, you could go to jail.
And if such legislation was introduced, guess who it would favour, the Customer, the Reporter, or the Vendor?
One subject that is avoided, and when hit upon is looked down on, is that sometimes vendors refuse to respond and reporters release information publicly. If a vendor is unresponsive and refuses to do anything about a vulnerability there is usually very little a reporter can do to get that vulnerability fixed. If there is no vendor receipt a coordinator should be contacted. If there is still no response then the vendor should be notified that if there is no resonable reply that indicates effort to fix the vulnerability then information about the vulnerability will be released publicly after a grace period of about 15 days (long enough for a reply but short enough to decrease those vulnerable). If they are still unresponsive then the responsible thing to do is to get the information out there and to make an effort to force them to fix the vulnerability. This method should be avoided if at all possible because it causes a quick and less thought out fix to the problem. It is, however, better than leaving the vulnerability open to others who have discovered the vulnerability or will do so and exploit the unknowing users.
That's possible, but I don't really think so. @stake obviously has roots in the non-corporate security community, so we know that they're aware of the benefits of disclosure. It is possible that they are angling for an RFC as a means of protecting amature security researchers who want to disclose what they find without suffering the fate of Dimitry Sklyarov. After that debacle, many people stopped disclosing anything because it was obvious that the DMCA would be used to make their lives miserable if they annoyed the companies too badly. A formal RFC that is approved by the IETF would go a long way towards discouraging prosecutors from bringing charges against researchers. ("Members of the jury, how can my client's actions be construed as a crime? He was only following the established procedures laid out by the IETF....")
The problem with drafting an RFC is that not all bugs are created equal, and that usually doesn't get reflected in a standards document. If a popular server application has a local exploit in the installation/registration process, you might want to treat that differently than if the same server application has a remote exploit caused by an inability to handle malformed requests. Why? The first one will affect sites for a brief period of time while the sysadmin installs some software. The second example affects any site running the software, thus having the ability to impact many more people. I'd be much more likely to give the software manufacturer more time to fix a remote exploit...
"Weapons should be hardy rather than decorative" - Miyamoto Musashi
I think that goes for OS's too
I'm just an at-home sysadmin but I have a fat pipe and 5 computers. I have been exploited for DOS attacks (back when I had no firewall and all Win machines).
Now I run a linux firewall and a couple of other linux distro machines for education/work and two Win32 machines (ME and 2000).
I'm in the position of knowing almost nothing about security, and although I know something about network programming I know very little about the common networking components available and/or how to fix them myself if there is an exploit.
This means (obviously) that I am completely dependant on posted security holes to keep my network secure. If this standard keeps me from knowing about a hole for the sooner of 30 days or a patch to even KNOW about a whole doesn't that make me, the consumer, intentionally and knowingly left open to attack by the vendor? Shouldn't they be required to let me know? I can't immagine the pressure high-security network admins would be under if the standard required those 30 days.
Just my two cents.
My $0.02 will always be worth more than your â0.02, so
I've seen a site well and truly compromised because frickin' Microsoft sat on a bug long after the Blackhat's had an exploit. It only took two days before their entire DMZ was rooted and credit card details stolen, and the stupid thing was, if the site had known that there was a problem they could have worked around it and avoid the legal mess they got into and are still in.
The only saving grace is that this probably won't happen to them again; they are now an ex-customer of Microsoft's and running Apache instead. True, Apache has its own problems, but at least they give you a chance to prevent any issues arising if you care to do so.
PS. Can I interest anyone in 40 used copies of NT Server? Thought not.
UNIX? They're not even circumcised! Savages!
I know it's a strange term, but generally a whitehat finding a bug doesn't do it all alone. They do it with the help of others. So if I'm looking at a bit of code and see something that looks poorly coded, am I still permitted to go post on a public mailing list "hey, this kinda looks broken, someone wanna take a look at it?" or is that against the draft (and as such I'll be labeled as "malicious"). If I happen to be looking at a config file or a protocol specification and notice that the design seems to have an inherent security flaw (trusting user data for example), am I permitted to talk about it publically, or as a "reporter" am I required to go look at every product that implements that standard and report my findings only to the vendor of those products. I suppose all these questions will get sorted out in the wash eventually.
How we know is more important than what we know.
Answer: very few, if any.
However, what RFCs (and BCPs) like this can potentially provide is an escape clause for responsible employees who discover a problem with their company's software to make it public without having their own employer sue their ass under the DMCA or whatever local equivalent might exist. Let's face it, if a Techie gives his PHB a procedure for dealing with incidents that includes a phrase like "in compliance with RFC's X, Y & Z" how many are going to read them before they sign off on them?
Or you could even be honest and openly use the RFC as a basis for your own company policies on the matter at hand.
UNIX? They're not even circumcised! Savages!
You can always publish the details of a bug in text, we still have the right of free speech, it just gets a little hazy about working code, the supreme court has yet to rule if code is the same as speech
Free cell phone tracking
One more step in the 'Full-Disclosure' is bad camp seems to be trying to get their idea of responsibility standardized so they have some RFCs and STDs to point to in their argument. Yes, one should make a reasonable attempt at contacting a vendor, and yes it would be nice if every vendor was so helpful as to 'work with the Reporter' in solving the vulnerability. This doesnt work in practice hardly ever. This whole document is merely an echo of Microsoft's and @Stake's recent push towards limited disclosure and the occulation of vulnerabilities (see no evil). This concept is irresponsible and lazy. Just because I happen to be the first person to report a bug doesnt mean im the first to find it, nor does it mean that there are other people out there who are not actively exploiting it. It is my duty to disclose this information to the WHOLE community in as timely a fashion as possible so that the people who will be affected by this can find a work around or an alternative solution until a patch is issued. This RFC as it stands is much too pro-vendor and would do nothing but harm the security industry were it ever to be widely adopted as a working standard.
--Ks9
Why is the finder of a flaw automatically labeled as the bad guy, and given this list of things to do after the fact? We have completely lost touch with reality here. If a finder releases an exploit or details he/she is considered the faulty party. What about the vender who made the software? I, in no way shape or form, work for that vendor. In the case of closed source, they created the software, they market the software, and they control every aspect of the software. They made a conscience effort to get the software out the door ASAP to make a jump on the competition. In the process they overlooked security, did not test the product fully, and did not care less about you, the end user who found this flaw. Now they want you to work with them and not inform others that are acting as Guinea pigs too? The only reason MS and other large vendors are even considering security now is because of the general public getting wind of it from main stream news media. For me, it depends on the specific vendor for what action to take. MS is not my buddy or friend, and not one I'd care to help for free. They charge per call for general phone support, if they want my support, they can call my 800 number with thier major credit card and pay me, if it turns out not to be a flaw, I'll refund the payment. They have more then enough money to hire thousands of programmers. To them, security is a PR issue and a non-revenue generator.
Bad boys rape our young girls but Violet gives willingly.
It's only me or it's blocking free speech (if free speech still exists in USA, anyway)? At the majority of the countries deemed "democratic" free speech is guaranteed by constitution. I really can't care more of the vendor's image, I care about my own: if my site get robbed because someone's software for which I paid I would be VERY upset cause my customers would be at risk because of me. If I get it free, it's my decision, I assume the risk since I paid nothing.
So I could happilly accept the proposed standard if the vendor has to pay for damages ocurred because of its software in a proportion of what you paid (this releases free software from any problem).
Say you paid $1,000.00 for a Web Server, someone informed the Vendor of a vulnerability and after 30 days they did nothing and your site got hacked, they would pay you 100 times the value ($100,000.00). Believe me when I say they would be much more "responsive".
Back on the free speech. Imagine a serial killer that only kills white male men wearing blue shirts at midnight in a city. If you live there, would you wait until police captures the killer to publish the story? I, as a male man wearing blue shirt living in that city would be VERY gratefull to know it and, at least, avoid using the shirt or beeing at the streets at midnight.
Just my 2 cents
I think it stinks that Weld Pond would put his name on an RFC advocating something like this.
For those too young to know, once upon a time there were several guys that called themselves L0pht Heavy Industries. They worked to disclose vulnerabilities and took great pleasure in providing "security by embarrassment" (Mudge's term, BTW), to the general community.
I hope you guys can sleep well at night with your consciences choking on those big bucks.
How about taking this a bit further and REQUIRE the Vendor contact registered Customers. And I don't mean posting a bulletin to www.mycompany.com/security or offering an option to subscribe to some mailing list.
Of course I doubt vendors would agree to this requirement, since it would imply the vendor take some kind of responsibility for the vulnerability associated with their product.
www.sguil.net
The Analyst Console for NSM
"We strongly encourage folks to report such problems to our private security mailing list first, before disclosing them in a public forum."
Let's not bash Microsoft too much, if Apache is doing the same thing.
Can you give an estimationg of how long is "long after". If it was more than 2 months, that's really irresponsible (but yes, they ahve a track record of that). If it was under a month, it might have been too fast to fix.
I agree though. If there is evidence that this has appeared in the wild, it should be immediate, even if it means disabling the service.
Interesting that I get to go to work today to image a machine that has been netbus'd
-- Who is the bigger fool? The fool or the fool who follows him? --
One reason cited for why Reporters (those who find flaws) go public:
...malicious intent to damage the reputations of specific vendors
If you find a glitch with a competitors product, why is it automatically evil to publicly disclose? One valid tactic of advertising (in the US) is to denigrate competing products. When Microsoft announced that Windows NT beat Linux in performace tests, did they give Linus private notice and 30 days to respond before issuing the press release? Does Compaq let IBM know beforehand that it has better TPC numbers? After Dateline NBC staged exploding gas tanks, did the Wall Street Journal give them a month to come clean before revealing the scam?
If you worked at Be in 1998 knew of a fundamental, nearly unfixable flaw in Windows, how much time would you grant Microsoft to address it?
I am sure that you are receiving dozens of comments on this draft, so I will try to keep mine brief. I am a security technician and sysadmin for a large nonprofit research organization. In your draft's terms I believe I represent a "User" more than a "Reporter" -- though a user with security-specific experience.
It seems to me that your draft undervalues the powers of users to protect themselves independent of the actions of vendors. Users are not entirely reliant upon the vendors of the software they presently use to protect themselves, and they can make use of published security information even if a vendor does not choose to acknowledge or proceed responsibly with the knowledge of a vulnerability. Moreover, they have a need for this information outside of its use in getting patches for existing software.
Most software users are not obligate users of particular pieces of software. They choose among competing software products (or even system designs), and make use of published information about these products in making their choices. They may choose to migrate from an installed software product to a competing one on the basis of published security concerns.
Because users need security disclosure to make informed decisions about the costs and benefits of pieces of software, they have an interest in a fuller and more analytical disclosure than vendors may desire. Large vendors may prefer users who have already purchased their products not to later question this purchase. They may resist the idea that a /pattern/ of vulnerabilities or poor practices exist in their software.
And for a vendor to quietly roll security patches into an "upgrade" may
help the user to avoid being cracked, but does not help him or her make
responsible decisions about future purchases.
Security researchers, it seems to me, have an ethical obligation not to aid criminals in attacking users. However, they (you) do not have an obligation to keep vendors from losing business, or to allow vendors to keep users in the dark regarding the comparative security strengths of software products. In many cases, users would be better served by being advised when the software they are using is poorly designed, has a history of vulnerabilities, and is likely to remain vulnerable to new sorts of attack -- rather than merely being told to wait for a patch, or not told anything independently at all.
... while reporters literally don't have to do anything to be compliant with the spec. There are no MUSTs for reporters at all, and only one or two for coordinators. There are about a dozen for vendors.
I'm not against vendors taking some responsibility for their products. I work for a vendor, and we take our defects (and trying to prevent them in the first place) very seriously. But if someone is going to poke and prod and pry our product to find vulnerabilities, then they should bear some of the responsibility for responsible disclosure.
Not all random numbers are created equally.
The proposed protocol favors only the vendors and those that work closely with them. This does nothing whatsoever for independent security reporters or the actual customers who remain unknowingly exposed to exploits because they aren't being reported.
Reporting should be public and immediate. Someone who discovers an exploit in a particular piece of software is under no obligation whatsoever to protect that vendors image; in fact, using that as a reason *not* to release an alert is just plain brain-dead. If the vendor releases buggy code and customers migrate to another product - hey, that's capitalism, straight from Adam Smith! The consumer makes an informed choice based on actual facts - which is how the market is supposed to work if people aren't colluding to keep secrets or misinform the consumer.
Vendors have no right to non-disclosure. Vendors have no right to have their 'image' or 'reputation' protected. If the company is that concerned it's up to *them* to invest the time and energy tracking down the bugs and repairing them. If we find them then we have every right to circulate them publicly for review, pointing out the flaws for all to see. This gives the consumer - you and me - the option to abandon the software in favor of a competitor's product, or to disable whatever part of that software is causing the problem until the vendor can be bothered to put out a patch.
Incidentally, it also allows us to determine who makes the shittiest software and avoid future purchases of their products. Now why does my cynicism kick in when I consider the fact that the people who put together this proposal are sucking away at the Microsoft tit?
Max
My god carries a hammer. Your god died nailed to a tree. Any questions?
I'm just sayin'.
sulli
RTFJ.
Security is not the responsibility of Joe Random who finds a flaw. Security is the responsibility of the programmer who created the flaw in the first place and the company who hired him (if any).
Oh, but since the average EULA disclaims all responsibility for any flaws I suppose it's not their's either, right? So it's basically the responsibility of the people who bought the software! People need to realize that when they buy/use software with a license that disclaims all responsiblity for defects/bugs/security holes/explosions that the software very well may have defects/bugs/security holes and explosive devices in it. If people don't like this they need to start buying software with EULA that are more favorable to them.
If having security holes immediately disclosed by everyone to everyone upon discovery is what will ultimately teach people about this then I'm all for it.
Without anonimity a lot of people would be very weary of close cooperation with vendors, because disclosure can become very risky if the vendor turns out to not be of good faith ...
That realizes that the security community (meaning bug hunters and researchers) provide their services, for the most part, free of charge.
In my book, this is considered a favor.
So now there's a draft which is going to tell me how to properly do this favor for them or else I am a 4$$hole?
So if you do me the favor of watching my dog, and I turn around and tell you that you need to watch my dog in my house, and that the dog needs to remain in my garage, which you need to remain in there to make sure he does not eat anything which may make him ill. And on top of that I tell you that you cannot wear anything blue/black/red/white because it makes my dog nervous, and that you MUST play with him for at least 45 minutes. And only feed him the special mixture of dogfood/yogurt served in the yellow tweety bird bowl which you will have to wash at every feeding.
Or of course, I could just be grateful that you informed me of a vulnerability in my software, and grateful that you are watching my dog.
(Score: -1 Ranting)
The nature of security problems has been changing with some regularity. If this only deals with disclosures regarding a certain vendor, ok...this plan will cover things nicely. But what about questions of disclosure with respect to protocols that aren't bound to (or invented by) any one entity? What about, for example, problems in new wireless technologies? IPv6? And so on? The IETF does not move as quickly as things in the security space do...not that they should, but still, I wonder if this will only go partway, and leave the rest of the problem harder to address.
For your security, this post has been encrypted with ROT-13, twice.
Actually mine was moderated off-topic just like yours. With -3 I got karma to burn though ;-)
"And we have seen and do testify that the Father sent the Son to be the Savior of the World"
1 John 4:14
The only responsible disclosure is a full disclosure, immediately, without time given to the vendor to "fix" the bug. The vendor does not need a "second chance" to fix the bug-- the bug should've been fixed before the software was released in the first place. Any short term advantage that hackers or script kiddies have to exploit a vulnerability is overcome by long term improvements in software quality.
It is true that not all bugs or vulnerabilities can be fixed prior to release. This is okay. However, major bugs can and should be caught. How the vendor does this-- stress test tools, better compilers, etc-- doesn't matter.
Each application entails a degree of risk that the user assumes. Do you care if there is a buffer overflow vulnerability in a computer game? What about your web server? Different applications have different levels of acceptable risk. It is the user's responsibility to decide what level of risk is acceptable, knowing that the risk can probably never be zero.
One factor in the risk is the user's assessment of the vendor. Has the vendor been responsible in fixing past vulnerabilities? The vendor's behavior after a vulnerability is exposed is just as significant as the number and types of vulnerabilities that are exposed.
Another factor is the price. If you use free software, you may be able to fix the bug/vulnerability yourself (if it is open source.) Otherwise, you get what you pay for. If you pay $2000 for the software, how severe of bugs/vulnerabilities are you willing to tolerate?
By making disclosure a huge embarassment to software vendors, the software industry is forced to check their work more carefully before release. I'm tired of paying to be a beta tester.
What this document doesn't address is the severity of the vulnerability. If a vendor can get up to 30 days to find a fix for a problem regardless of how severe any potential exploits are, I certainly would not feel comfortable as a sysadmin or customer.
I have to admit. Considering the amount of SHOULD conditions in the document, it is nowhere even close to being a final document. Addressing the severity of the problem is a very important part of the equation. It simply cannot be ignored.