What is the best time for a vendor to Disclose a Vulnerability?
Vulnerability disclosure is the most painful activity for any software/hardware company. Conversely, receiving vulnerability notifications from any vendor is one of the most disruptive events any organization can encounter. Rapid and unexpected vulnerability patches are a massive operational disruption.
What follows are some guidelines for any vendor and open source project who are new to vulnerability disclosure. Vendors/Open Source projects should do everything within reason to minimize vulnerabilities in their product. But the reality is that nothing is perfect. Things happen and vulnerability are a fact of life. This is when a transparent and logical vulnerability disclosure process clears the path for everyone – minimizing the risk and getting the fix deployed as fast as possible.
For the Operators, these principles can also be used to interact with their vendors on the timing of the vulnerability advisories.
Principle #1 – Always go full public disclosure for any vulnerability that has been determined to be active exploit.
Vulnerabilities which are being used by criminals, nation state, or other threat actors need to be disclosed publicly as soon as possible … even if there is no fix for the vulnerability. This is not about the brand or reputation of the organization. This is about ethics, liability, and safety. Today’s vulnerabilities are not about Window 98 bugs. They can be embedded system on an M2M control system attached to life support in an emergency room. The guiding principle of disclosing publicly whenever there is a confirmed active exploit should be expected from all vendors (and open source projects). What is disclosed would be a vulnerability advisory with the best available information. New versions of the advisory will be posted as more information is gained, workarounds are validated, and fixed code forecast are confirmed.
Operator’s “Meaningful Conversation” with the Vendor: Ask your vendors and the open source software communities you use inside your organization what they will do if there is a validated active exploit vulnerability. This is a good “meaningful conversation” to have with your vendors.
Principle #2 – Not everything needs a Vulnerability Disclosure Announcement
This might be shocking for some. It is not new for anyone who has built and operated a robust security development process. Vendor security practitioners know that there are a lot of potential security issues found and fixed based on their own testing. Many of these are not disclosed to customers. The logic is often based on the “noise level.” Announcing all of the minor vulnerabilities would dilute the ‘customers’ attention span. This dilution would immune the customer to take immediate action when there is a major vulnerability. This endangers the customer during times when a response is really needed.
What can a vendor do to “triage” all the vulnerabilities? Luckily this is where the Common Vulnerability Scoring System (CVSS) solves this problem (see https://www.first.org/cvss). If you think a bug could be exploited, then run a CVSS assessment against that bug. See what the CVSS base score would be and if that bug could be feasibly a big issue. Then have a policy where CVSS values trigger the type of vulnerability disclosure.
For example, the Internet Systems Consortium (ISC) (that open source company that maintains BIND & DHCP) used CVSS to “triage” the bugs using this scale (see figure).
As seen in this CVSS table, low CVSS scores are just documented and fixed. Others trigger critical notification processes. This approach allows a vendor/open source project to focus on finding security issues, but not get bogged down having to push out disclosures for every vulnerability found.
Operator’s “Meaningful Conversation” with the Vendor: Ask the vendor how they use CVSS. Ask they are using CVSS version 2.0 or 3.0 (check the details here: https://www.first.org/cvss. This is another meaningful conversation with the vendor. During this CVSS dialog, see what you need to do with your own processes if the vendor discloses a vulnerability with a CVSS Base Score of 10. What would you need to do if you need to patch now vs waiting for the weekend’s maintenance window?
Principle #3 – Minimize Operational Disruption
All vulnerability disclosure will have some type of operational disruption. Networks and systems will need to be upgraded to remediate the vulnerability. Vendors/Open Source projects need to be mindful of this operational disruption and take steps to minimize the disruption. No operator likes to drop all their plans right before a network freeze before a major holiday and rush an unplanned patch through their network. Here are some general guidelines:
The key general principle to minimized operational disruption is look out for the major network/systems lock downs. These network/systems “lock downs” are done to keep humans from messing up the operations during a major event (remember – humans are the #1 cause of failure in a network/systems). Sometimes these network/systems lockdowns overlap with holidays. Other times it is over the end of the financial year and the closing of the books. Still others are during major events like national elections. As a general guideline avoid major vulnerability disclosures:
- in December (holiday and shopping season)
- during Lunar New Year weeks (more shopping and people going home)
- during Ramadan (people are fasting and reflecting)
- in June (end of school and end of year finance closing)
- Some would also include August for the European summer holidays.
- Be consistent. Some companies have “patch Tuesdays” or “patch Wednesdays” once a month as a regular vulnerability disclosure time.
Operator’s “Meaningful Conversation” with the Vendor: Have a conversation with the vendors on when your network has lock downs, when they normally have vulnerability disclosures.
Principle #4 Reality Check – Disclosure Dates are Driven by Outside Events
If you find a vulnerability within your team, then you have the luxury to drive the timetable for the fix and disclosure. But, many times vulnerability timetables are driven by outside forces. “Vulnerabilities finders” report the vulnerability and then say they will announce at this conference is common in today’s environment. Some national CERT Teams also have disclosure timelines they enforce to ensure the vendors don’t “sit” on vulnerabilities.
When these “outside factors” happen, it is important for the vendor/open source project negotiation a reasonable timeline which gets a fix deployed ASAP while minimizing operational disruption. This negotiation will be helped if the vendor/open source project creates a policy that is friendly to vulnerability reporting. For example:
- Does the vendor make it easy for someone to report a vulnerability? For example, if you go to the “/security” or the “/about” pages ( likewww.example.com/security) are there instructions for reporting vulnerabilities?
- Does the vendor thank and welcome the vulnerability finder? Is the attitude one of thankfulness or spite?
- Does the vendor publicly acknowledge the vulnerability finder on their vulnerability disclosure? Many times putting a name and thank you on the vulnerability disclosure document creates a huge amount of good will between the vendor and the overall community.
- Does the vendor use a bug bounty program that rewards the vulnerability finder? Bug bounty programs are a valuable tool for developing community good will.
- Does the vendor allow the vulnerability finder to include a quote in their “conference slide deck” to thank the finder? This is a powerful good will tool. Having the vendor clear the path with a “vendor quote” or details in the conference slides communicates to everyone in the audience that this vendor is serious about their vulnerability disclosure process and seek active partnerships.
Some may feel this “building good will” is not good for the vendor. The reality is that an effective program that reaches out to the larger community and welcomes the “3rd party vulnerability reporter” communicates confidence and strength. Vulnerability will happen. It is stupid and dangerous to think that hiding vulnerabilities are good for the customers or shareholders.
It is idiotic to think that attacking the 3rd party vulnerability reporter is good for the customer or shareholders. Vendors that invest in the 3rd party vulnerability reporter relationship will find productive dialogs over the disclosure timetables – minimizing operational disruption and find the best possible disclosure options. Vendors who attack the 3rd party vulnerability reporters will turn the community of “hackers” who find vulnerabilities against them. Today, this is extremely dangerous. In some cases, people will “full disclosure” the vendor – posting the vulnerability with no notice. This “full disclosure” is the best case. The worse case is when the vulnerability finder sells the exploit to a criminal, nation state, or another threat actor to be used as a “zero-day” exploit.
Operator’s “Meaningful Conversation” with the Vendor: Have a long conversation with the vendor on their policy, processes, and procedures for 3rd party vulnerability disclosure. Ask them what they would do if you found a vulnerability on their product while testing inside your operations.
Principle #5 – Be Open with the Vulnerability Disclosure Process
Trust is critical in the vulnerability discloses process. There have been vendors kicked out of major networks for mishandling the vulnerability in their product and breaking trust with their customers. The first step in building trust is to write down the vulnerability disclosure process. This produces should then be posted publicly on the vendors website. Allows everyone to review the process and be able to have meaningful dialog on that process. The documentation/publication of the vulnerability disclosure process is a transparent step that builds trust. It does not have to be perfect. It does not have to be like other vendors. But, it does need to be written and available to the constituents who depend on the product.
Operator’s “Meaningful Conversation” with the Vendor: Check the vendor’s website. Look for the vulnerability disclosure process. If there is none posted, do an Internet search. If you still cannot find, it, call in the vendor and have a meaningful conversation as to why they are not publicly posting their vulnerability disclosure process.
≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣
➥ Barry Greene is Business Development Executive ★ Internet Technologist ★ 25 Year Veteran of Internet Security ★ Emerging Technology Mentor ★ Advisor to Innovative Startups ★ Internet in Asia Expert
➥ Barry connects to peers, colleagues and aspiring talent via Linkedin (www.linkedin.com/in/barryrgreene/). You can also follow on Barry on Twitter (@BarryRGreene) or his blogs onSenki(www.senki.org).