My approach to vulnerability coordination and disclosure

Dear Thierry, why are you such an arrogant asshole?
I don't think I am.

That question really arrived in my inbox, in relation to the recent advisories and forced disclosures [1],[2] . Forced disclosure means that since the vendor hasn't reacted I consider myself forced, (ethically, because you don't want customer to run the risk of not knowing) to disclose the issue. In the last month this happened for Avast, IBM and Fortinet. (In all fairness, fortinet actually replied to my third try to reach them)


Let me get you up to speed: The disclosure policy that I adhere to didn't spontaneously spring out of my head, it is based on Secunias' policy. 

As I have reported quite some bugs in the recent years, and faced some problems with certain vendors, it immediately pleased my mind. I made some changes to it and there it was. It is straight forward and fair. It gives the vendor the chance to react, test their code, share their insight. If however the vendor does not answer this proves that either the vendor doesn't care about the security of their customers or that the vendor has simply not received the mail. 

This however is not really an excuse, the international standard addresses for security notification reports are well known (secure@ / security@) furthermore, repositories such as OSVDB exist where vendors can (an should) enter their security email address should it differ from the standard addresses - see, it's not the "researchers" fault if there was no reply, or reception.

Actually in my experience it's most often the vendor that simply ignores your e-mail and/or silently patches the bug in the next release.

So why do I do it then :

1. You see, responsibly disclosure goes both ways, and several vendors have yet to understand that. As a "researcher" you are bound to be responsible towards the vendor but also towards their customers and end-users. If there is a hole in a piece of code that runs at various customers, they should know they have that hole. If the vendor thinks that hole is minor, they should know the vendor thinks it's minor. If there are discrepancy in perception between the vendor and the "researcher", they also deserve to know. Not because the "researcher" is arrogant or suffers from delusions of grandeur, but the researcher thinks that the vendor has not had the complete oversight when rating the issue, and he wants the customers to know.
   
   Advisories are the essence on what risk management lies upon, no advisory and a risk manager lies in the dark about a particular issue. This by the way is also the reason why I think that the IMPACT of a vulnerability and a good description of it is often more important than releasing POC files and very detailed technical advisories.
   
   
2. Create the necessary business incentives for vendors invest in security vulnerabilities notification procedures, patch procedure, SDL processes and human capital. 
   
   Yes you read correctly, if we as "researchers" do not publish bugs, including verbose time lines and how vendors reacted, there is nearly no (apparent) business incentive for a vendor to create such teams and procedures. Why do I say that there would be no incentive. Simple, it's not visible, how often do you have reported a vulnerability ?
   
   Here is something that should be of interest to you: Customers (and mainly large enterprise customers) absolutely love reading vulnerability notification time lines. It proves or disproves that the million dollar license fees they invested in a company's' product is a good investment that the vendor really cares about the security of their products (and hence the customer) and it gives direct insight on how long it takes them to react.
   
   At this point everything comes together, customers that are interested in holding their vendor to account have then grounds to ask for a more professional approach, sometimes even considering a change to another vendor. This is what creates the very business incentive that I want to see. If it worked with Microsoft it works with everybody. Ask them.
   
   
3. And this leads me to another reason why the policy is more aggressive than that of Rain Forest Puppy. Vendors do silently patch. They take your notification, don't reply and magically the problem is gone in the next version. If you ask them - if they reply at all - they claim it has been found during internal tests. However it is common practice that even rediscoveries are credited - some however don't.
   
   
4. Free labor. I expect a certain degree of professionalism - reporting vulnerabilities is am doing free work for a company that make millions. Discovering and coordinating  vulnerabilities  is free work. I have not introduced those vulnerabilities in the first place, if they are within the product of the vendor, it's because you either didn't invest in controls or their controls failed. In any case, it's their problem.
   
   
5. NOT doing so is unfair to vendors that do respect researchers, invest money, time and effort. I have reported over 900 vulnerabilities in products, out of those 900 only 1% were voluntarily published by the vendor without me publishing first. I am able to tell due to particular circumstances.
   
   And where did that lead us to? Screwed statistics and false assumptions.
   
   Charts displaying that one vendor was being "more vulnerable" than another, when in fact it is exactly the opposite. Vendors hat did not publish their vulnerabilities had a lot more holes then those that published. And that, in my book, is not an acceptable situation towards a vendor that respected both researcher and their customers.
   
   An it is this very fact that  lead me to the conclusion that everything even the low priority issues deserve disclosure, especially if the vendor doesn't answer.