How to Avoid Bug Management Mistakes

I was recently asked to comment on some of the most common bug management mistakes enterprises make and how to avoid these issues. I have found that one of the most common mistakes is the failure to track vulnerabilities that have been deemed an acceptable risk and left unpatched.

There are many reasons why an organization may decide to postpone or prevent the deployment of a particular patch. It might be determined that the patch is not applicable to the current environment. The organization might have compensating controls already in place.  In some cases, a patch might adversely impact the business functionality of applications. In the later case, the organization may need to postpone deployment of a patch until the application vendor is also able to provide an update or a workaround.

When an organization decides to postpone the deployment of an update, it should track the decision as part of its overall risk assessment strategy. The tracking should include the overall risk rating, the reason for the delay, all compensating controls, and a schedule for when the risk will be reassessed.

There are several reasons for periodically revisiting the risk assessment of patches previously deemed acceptable. Network topologies change over time, it is important to determine if the compensating controls are still in place and effective. Also, the exploitability of vulnerabilities changes over time. When the vulnerability was first disclosed, there may have been no known exploit, but over time an exploit might be discovered and incorporated into malware.

When organizations fail to track the risk of un-deployed patches over time, a large number of vulnerabilities may accrue, increasing the overall risk to the organization, and also creating a technological debt that can take a great deal of time and effort to reduce.

When breaches have been analyzed, too often it has been found that a system that was missing a security patch that was multiple years old had been exploited to initiate the breach.

A slightly less common mistake occurs when an organization defines how quickly it will deploy patches deemed to have a high severity, but does not define how quickly lower severity patches must be deployed.  In such  organizations, over time, the number of un-deployed patches addressing low severity vulnerabilities grows to a large number making it nearly impossible for a staff to catch up without impacting unrelated tasks.