Tim (not his real name) routinely spends some of his free time prowling the web for exotic security tools and exploits. Shortly, he stumbled upon a new exploit that was circulating within an underground forum. It pertains to a standard security product by a particular vendor. Although the affected product does not distribute locally, he postulates that the exploit would also work on the local competitors’ product. Especially since the competing products operate on a similar nomenclature.
The next day, Tim performed the exploit on some security devices deployed in the vicinity of his workplace. As he has anticipated, it worked! Out of curiosity, Tim attempted the same exploit across multiple vendors over various locations. He gathered that while the exploit was not widespread, it affected the market leaders who have their products widely used in both commercial and government offices.
Now confronted with a dilemma, Tim is unsure of what he should do with his newly discovered vulnerability and exploit.
Should he release this vulnerability to the public?
Should he inform the vendor?
Should he sell this vulnerability to the competitors?
Should he do nothing and pretend that nothing happened?
Should he inform the authorities (i.e. law enforcement) to coordinate a workaround / compensating control while the vendor finds a permanent solution for this exploit?
While Tim ponders over these options for the first time, these questions are not new to security policymakers or security researchers. Unfortunately, to date, there are no widely accepted or adopted policies for vulnerability disclosure. In the absence of such guidance, we explore the possible options for vulnerability disclosure in this article.
The 4 Paths
When it comes to vulnerability disclosures, there are, in my opinion, four paths (aside from doing nothing). While I would not consider all options to be “responsible”, they nonetheless valid routes.
The four paths are namely:
Full Disclosure (release to the public);
Inform the vendor;
Inform a coordinating entity; and
Sell the vulnerability.
1. Full Disclosure
In full disclosure, you release the details of the vulnerability or/and the exploit to the general public. As a result of releasing the vulnerability, a race between the vendor (to repair the vulnerability) and attackers (to exploit the vulnerability) begins.
While on the bright side, vendors are forced to fix the vulnerability in their software product quickly from fear of losing its’ customers and product confidence, you effectively leave other users of the software product without a patch or fix to defend themselves. By releasing the vulnerability to the public, you would have created a negative externality where both the users and vendor bear the cost of your decision to release the vulnerability to the public.
Meanwhile, before the patch is released and deployed, other end-users of the vulnerable software are left defenceless. Attacks pertaining to the particular vulnerability would likely increase, and users would be exploited. (Source: Impact of Vulnerability Disclosure and Patch Availability: An Empirical Analysis). From a societal point of view, full disclosure (or instant disclosure) often ends in sub-optimal results. (Source: Optimal Policy for Software Vulnerability Disclosure).
2. Inform the vendor
Submitting the vulnerability to the vendor in hopes that they would fix the vulnerability and release a patch would be one of the first options that come to mind. However, it would be naive to expect the vendor to fix the vulnerability as soon as possible. This is because it costs more for the vendor to release a patch earlier.
Given the fact that the vendor would likely require you to sign a Non-Disclosure Agreement (NDA), they can take their time and release a patch that is “cost-optimal” for them. Consider the following graph showing the approximation of cost over time.
Note: The graph above is by no means meant to calculate actual specific costs. It is meant to illustrate two things:
Releasing a patch within a short span of time is costlier than releasing the patch over a longer span of time.
The longer the vulnerability remains unpatched, the higher the probability that the customers will be breached, incurring a higher customer loss.
That said, the “cost-optimal” option for vendors (in the orange box) is almost always not socially optimal, where there is the least overall cost to society. In some extreme cases, vulnerabilities are not fixed, and end-users are kept in the dark until someone comes along to exploit the vulnerability.
This leads us to the next option; informing a vulnerability coordinating entity.
3. Inform a Coordinating Entity
Institutions like CERT/CC seeks to: “balance the need for the public to be informed of security vulnerabilities with vendors’ need for time to respond effectively.”
Their vulnerability disclosure policy gives vendors 45 days to fix the vulnerability (from the date of the initial report) before the news about the vulnerability is released to the public. Acknowledgements will be given to the reporter when the vulnerability is being publicised.
The goal is to nudge the vendors towards fixing the vulnerability within a timeframe, closer to what is socially optimal.
One criticism of such policies is that the cost parameters used to derive a socially optimal timeframe for these vendors are mostly estimated values based on previous incidents, patch cycles, etc. Since the 45-day disclosure policy cannot be a “one size fit all” solution, CERT/CC practices discretion on the final publication schedule: “The final determination of a publication schedule will be based on the best interests of the community overall.”
While you do not get any incentives other than an acknowledgement for reporting the vulnerability, it is in my opinion; the more responsible path to take since it seeks to reach a “win-win” scenario for everyone.
There are however limitations to this option. Reaching out to CERT/CC from abroad to coordinate vulnerabilities for end-user products such as your office productivity suite or the web browser is fairly straightforward. However, it gets complicated when the vulnerabilities involve national interests.
For example, assuming that you are a citizen of Atlantis (a made-up country), and you found a critical vulnerability within a bespoke SCADA system that is maintained by a local vendor. Do you proceed to release this information to CERT/CC that is based in the US? Would you trust another country with critical vulnerabilities that pertain to your country’s critical infrastructure?
As with many countries today, what if there are no clear avenues for citizens to report vulnerabilities pertaining to a country’s Critical Infrastructure (CI) or Critical Information Infrastructure (CII)? Which agency or government body will be responsible for coordinating these sensitive vulnerability disclosures? Can countries mirror or adopt the same disclosure policies that CERT/CC has?
These are questions that policy-makers (within the government) need to address as the world moves towards an era where software plays an ever more important role in society.
4. Sell the vulnerability
Selling vulnerabilities on the open market can be an option. With brokers like Zerodium, you can quickly look up the price list below to find out how much your zero-day is worth and perhaps submit an application to them.
WIRED first broke the news on this firm back in 2015, and you can read the full story here. In essence, the firm buys zero-days from hackers or software researchers and resells them to its’ clients on a subscription basis. These clients include government agencies.
While the payouts are undeniably attractive, I cannot recommend this option to be the most responsible choice as it is unclear how these the zero-days are utilised.
Hybrid Vulnerability Disclosure — the 5th option
There exist a fifth option that lies between coordinated security disclosure and selling the vulnerability. This convergence is found in the Zero Day Initiative (ZDI) by an IPS vendor called TippingPoint.
The ZDI coordinates responsible vulnerability disclosure to the affected product vendors, TippingPoint customers, security vendors and the general public.
According to their information page, once a vulnerability has been submitted and verified, TippingPoint notifies the affected product vendor. While the affected product vendor develops a patch, TippingPoint will write IPS protection filters and distribute it to its’ customers. Since writing IPS filters are faster than developing full patches, TippingPoint customers will get to enjoy some form of protection before a software patch is released. TippingPoint then notifies the other security vendors on the details of the vulnerability before public disclosure. Once a patch is complete, ZDI discloses the vulnerability to the public. You can learn more about ZDI procedures here.
Sounds good? — Not quite.
Based on this business model, I would argue that TippingPoint might not have the interest to nudge affected companies to produce a patch within a timeframe that is socially optimal. This is because, the more time it takes to produce a patch, the longer TippingPoint holds its exclusivity on the zero-day. In other words, until a patch is found, end-users will need to rely on TippingPoint for protection.
Do you see the conflict of interest here?
In the end, it will likely take longer for vendors to remedy a given vulnerability. One that is far from being socially optimal.
Final thoughts
Without any widely accepted or adopted policies for vulnerability disclosure. We are left to our own devices to navigate through this grey area. Hopefully, this discussion would have triggered some thoughts on the consequences for each path as we still ought to make informed decisions in such muddy waters.
Finally, while the market can take care of the task of rewarding individuals for reported vulnerabilities, there is still a clear need for regulators in this space. As the topic of responsible disclosure becomes harder to ignore in today’s software empowered society, it would certainly be exciting to watch this area develop in the years ahead.
Do not hesitate to let me know what you think in the comments below 😉
Author
Andre Ng, First Mate, Div0.