[Notice: This blog post should not be interpreted in any way as representing the position of any particular ICASI member company, or a formal position statement from ICASI itself.]

A recent blog post brought back to the forefront debate around how and under what timeframes security vulnerabilities should be handled and disclosed. When dealing with an active exploitation, time is of the essence. But setting arbitrary deadlines for resolving or disclosing information about a vulnerability actively under exploit is not practical. After all, when it comes to vulnerability response and disclosure, one size truly does not fit all.

While an organization that controls the entirety of its infrastructure will likely need less time to deploy certain remedies, there are many environments where this level of agility is simply impossible. For most vendors, it is not the clock that determines the appropriate response path but rather the diverse needs of its customers. Below are just a few reasons why proposing arbitrary deadlines around vulnerability response and disclosure is concerning:

  • Not all systems can be patched in a finite set of time regardless of the platform.. For example, critical infrastructures, life support systems and embedded environments (such as mobile) require extended test periods that may span months. Some of the requirements may be necessary to comply with regulatory requirements. In other cases, customers have deployed the affected product in their enterprise and very few enterprises can apply a patch to production within a week. These elongated cycles should not give vendors a reason to drag their feet in addressing known exploits. Instead, they should guide vendors’ actions around appropriate disclosures so that they can mitigate risk to already vulnerable systems.
  • A vendor’s primary focus is to provide timely solutions to its customers – whether interim mitigations or fully tested patches – that will not introduce further disruption or risk to their enterprises. When investigating a vulnerability or exploit, vendors must weigh response time against factors such as thoroughness, quality and other particular customer requirements.
  • Remediation speed and quality are not always complimentary. While no vendor wishes to leave its customers vulnerable longer than necessary, patch integrity directly correlates with patch adoption. Patch adoption rates are already low and promulgating incomplete solutions simply to respond to arbitrary deadlines may only worsen the problem.

Though vendors need to minimize their customer’s risk swiftly, arbitrary deadline-driven approaches may only serve to increase risk.  Speed of resolution should be balanced against a few guiding practices and principles:

  • Manage risk: There is ample research showing that disclosure can actually accelerate exploitation. Best practice around disclosure calls for doing so in any way that does not amplify risk for any party. In terms of what to disclose, a good rule of thumb is publish only enough information to allow customers to evaluate their level of risk. Anything more may be a recipe for disaster. That being said, in situations where there is known or suspected active exploitation occurring, or where vulnerability detail is made public in advance of a published mitigation, a vendor should, where practical, communicate information to those affected and provide available guidance.
  • Coordinate: Researchers or other parties who discover vulnerabilities or exploits in hardware, software or services should disclose those items directly to the vendor of the affected product(s). The vendor should be given a reasonable opportunity to diagnose and offer fully tested updates, mitigation, or other corrective measures before any party discloses detailed vulnerability or exploit information to the public. In addition, the vendor needs to determine if the vulnerability affects multiple products or requires engagement with other vendors to coordinate patch releases. Again, only vendors have a complete view of the risks across their product portfolio, underlying protocols and customer installations.
  • Collaborate: With today’s deeply interconnected and critical infrastructure, it is rare these days that an exploit affects only one vendor’s products. Multi-vendor collaborative response toward vulnerabilities and exploits can be of significant benefit in addressing them quickly and effectively. Even if other vendors do not have products immediately affected by an exploit, their knowledge or experience dealing with similar cases may be of benefit.

The bottom line is that managing vulnerability remediation during active exploit is no easy business. As an industry, we should collectively strive to minimize response times to reduce the risk to global networks and critical infrastructure. However, creating arbitrary deadlines for such responses is not a one-size-fits-all proposition.

Greg Kohn
Executive Director