Advisory Ambiguity
by Jeff NathanIn the course of notifying the public, some vendors’ vulnerability advisories have been less informative than others. Whereas a significant number of vendors have come to realize the value of some form of disclosure over time, others continually fail to provide actionable information. This entry is not a discussion of the merits and failings of disclosure. Rather, a commentary on half-hearted efforts to disclosure information.
The purpose of a security advisory is to inform customers and presumably security professionals of a risk that requires some sort of action. Obviously, advisories are consumed by a broad audience, which includes people of varying technical expertise. Well-written vendor advisories often include enough information for concerned parties to be able to take action. IT staff might install a patch, add some firewall rules and add some new detection rules to their NIDS. Technical managers might become aware of an issue so that they can discuss it with business management. All these details are rhetorical and presumably well known to anyone releasing an advisory. Given the obviousness of how advisory information is consumed, it is extremely puzzling to come across advisories that are completely lacking in actionable information.
Informing customers that an issue exists and where to download a patch is the bare minimum amount of effort that can be put forth in the disclosure process. However, if that is the extent to which an advisory describes an issue, the affected customer is sorely unarmed to cope with the issue. Simply put yourself in the place of such a customer. An email message arrives in your inbox from Vendor X. The email message informs you that a piece of network management software, provided by Vendor X, contains a vulnerability and that a patch is available for download. Wondering if more information is available, you visit the vendor’s website only to discover there are not any additional details. Seeking to identify the salient details of the vulnerability, you turn to your preferred Internet search engine. After wasting an hour on a fruitless search, you are proceed with the bare minimum remediation effort; you install the patch and regret it.
Without any information on the nature of the exposure, IT staff is extremely limited in their ability to respond. Further, IT staff is not the only poor souls who are detrimentally affected by insufficient advisories. In some organizations, business managers make the ultimate decision as to whether or not a patch should be installed. If a system administrator cannot explain the impact and risk of an exposure, how can they be expected to argue the necessity of installing the associated patch?
Our imaginary, but representative scenario does not simply end with unequipped IT staff. The security products IT organizations rely on to protect their information and infrastructure are continually updated to keep pace with new exposures. The ability of manufacturers of security products to provide timely and accurate protection for their customers is quite literally impeded by vendors who provide insufficient advisory information. On top of the often-significant effort security product vendors must put forth to continually develop their protection and detection technologies, we are occasionally forced to reverse-engineer a patch to determine whether it can be detected and/or protected against.
Presumably, these details are already well known by some vendors who provided insufficient disclosure information. Perhaps customers ought to shake their collective fingers at these vendors and in unison say “shame on you”. As for the vendors who do not yet understand the negative impact of their curt advisories, perhaps some of their customers could kindly request that they peruse this posting.
Popularity: 5% [?]