In my previous post, I disclosed that SonicWall had quietly released vulnerability fixes over the course of several days before vulnerability advisories were published for CVE-2020-5135.

Rather than properly fixing CVE-2020-5135, SonicWall’s fix introduced a new vulnerability in the same code. SonicWall was aware of the new vulnerability but deferred the small fix until the next release, more than 6 months later. These disclosures, more than most, touched into a couple of interesting topics with regard to what should be expected from a Product Security Incident Response Team (PSIRT) and what considerations to make when establishing a vulnerability response policy.  After years of working with vendors and having greatly varied experiences, I think it is long overdue for me to write a post sharing some of my thoughts on the best practices for operating a PSIRT. To begin, the topics I’ll be discussing are briefly enumerated below:

1. Advisory Timing: How should the release of patches and associated fixes be coordinated? Is it better to release patches first, advisories first, or at the same time?
2. Fix Verification: What is the process for verifying that a vulnerability has been fixed and that the fix has not introduced new issues?
3. Release Scheduling: What’s an acceptable time for a vendor to know about a ‘0-day’ vulnerability before releasing a fix?

Advisory Timing

In most circumstances, I think it is bad practice for a vendor to do anything other than having patch and advisory publication synchronized. There may be exceptions to this, such as when a vulnerability is under active attack before a patch is available, but there are risks worth considering on either side of a synchronized release. Making vulnerability descriptions available before patches clearly can give attackers a head start seeking out and exploiting the described vulnerabilities before patches are available. Releasing (Read more...)