ISO What You Did Last Summer

What was meant as a fun little blog post over the weekend about the human element and excitement at ISO meetings spawned quite a reaction among the researcher crowd. I’d like to set a few things straight before Monday morning rolls around and even more people get the wrong idea and get upset when they could be coding or doing something else productive.

Myth: The ISO draft on Responsible Vulnerability Disclosure is some sort of plot by vendors to tell researchers what to do.

Fact: The ISO draft is misnamed. (I didn’t name it, and I can’t change it.) It should probably be called something like “Guide for Vendors to Implement a Vulnerability Handling Policy”. It has a strict scope to apply to vendors’ actions only, not researchers’ actions. This was decided by the National Bodies participating for many reasons, not the least of which was the fact that researchers don’t usually follow ISO standards. :-)

Myth: Even if it were renamed, it still has “elements” in it that “tie researchers’ hands”. This will somehow still affect researchers!

Fact: I repeat -- There is nothing in this draft that tells researchers what to do. Nothing. Nada. Nil. No matter how hard one may try to make this about researchers, it simply isn’t about them.

The ISO draft is a guide for vendors to help them do three (simple, in theory) things:

0. Receive vulnerability reports from researchers.

1. Process vulnerabilities via some sort of investigation and potentially create some sort of remediation.

2. Communicate the remediation (if any) to affected customers.

All of the guidance in the draft is very basic, and very agnostic to business particulars of how a vendor is to carry out these steps. Since there is no prescriptive guidance in there for vendors, only high-level best practice guidance, there is nothing that will “affect researchers” except maybe, just maybe, make it easier for researchers to find the right contact to report security vulnerabilities at vendors who choose to comply with this ISO standard.

That’s the sum total of the possible ramifications for researchers that could possibly come of this – it might make reporting vulnerabilities slightly less complicated. I know, there’s nothing to get upset over with that, so I’m sure those who still want to yell on the Internet will ignore this entire post or pick it apart in 140 characters or less. ;-)

Besides, even if there were rules for researchers in the draft (which I repeat, there are NOT), researchers can do whatever they want. That has always been the case. Every researcher I’ve met has their own personal vulnerability disclosure (or non-disclosure) policy that they generally follow. I say “generally” because this personal policy varies greatly from researcher to researcher, and can even have significant variation when a single researcher deals with one vendor or another, so much so that in most cases, it shouldn’t even be called a policy, but rather a “collection of exceptions”.

Perhaps one vendor gives them more technical responses, so the researcher is inclined to give them more time. Perhaps another vendor gives them auto-generated emails every month, so the researcher gives up on ever speaking to a human and releases the vulnerability details after receiving a few robot-mails in a row. The researcher may give a reason for changing their mind about giving a vendor more or less time, and they may not.

The point is: nobody can tell researchers what to do now, so how or why on earth would ISO ever try? And if ISO did try to regulate researchers, who would follow the standard? Not the researchers, that’s for sure.

Basically, researchers answer to no one. They do what they want, when they want, and on their own timeline. Nothing will ever change that, so why is there even a “disclosure debate” at all?

In my opinion, the debate only ever comes out when a researcher wants to be *thanked* by a vendor, either via vendor acknowledgement or via monetary compensation. That thanks (or no thanks) is up to the vendor and always will be.

Now, let’s differentiate between gratitude and credit. Credit, as opposed to gratitude, is not something that a vendor can give or withhold. Credit is granted in the numerous vulnerability databases that will inevitably cite the researcher (if they made themselves known publicly), whether they dropped exploits on Full Disclosure ahead of a vendor-supplied fix or not. A researcher who wants credit will always get it. A researcher who wants gratitude will have to abide by the vendor’s rules for how the vendor chooses to express gratitude.

No standard will ever regulate the concepts of responsibility, whatever that means, (for researchers) or gratitude, whatever that means, (for vendors).

So there you have it, in all its futility: Researchers will continue to do whatever they want, and (shocking!) so will vendors.

Only, when this ISO standard comes out, vendors may have a better idea on how to go about their vulnerability handling. I’ve seen many faces of vendor response, and I can tell you that clues are rarer than you’d think, and that there is a place for this kind of basic level of guidance.

If you’re a vendor, this standard will not tell you how many security staff you need to hire to support a whole new vulnerability handling practice, or whether or not to thank a researcher. That’s up to you. If you are a researcher, ISO will not tell you how much time you have to give a vendor or whether or not you have the right to sell your work. That’s up to you.

Now you can all get back to work doing whatever you want, or continue screaming FUD-y murder. It is, as it always has been, up to you.