Everybody needs to be more creative in addressing vulnerabilities

 

Almost predictably, Walter Haydock has produced another excellent post dealing with vulnerability management. I recommend you read it.

You will notice that the post addresses concerns of software developers, not end users. Since I don’t think too many developers read my post for development advice (for that matter, I don’t think too many hog producers read my blog for hog production advice, either. The two are about equally likely to occur), you may wonder why I’m suggesting that you, an end user of software, read it.

The first and perhaps more obvious reason is that end uses need to know what’s reasonable to require of suppliers regarding vulnerability management and what isn’t. If you look at Waler’s post from that perspective, you can read it as saying in general that requiring suppliers (in contract language or simply in an email) to follow rigid rules like “Never release a product with vulnerabilities having a CVSS score of >7.0” will sometimes be counter-productive (as Walter explains, this might mean the supplier will take longer to patch a serious vulnerability, if another serious vulnerability appears just before the deadline for the supplier to patch the first one). He suggests a more nuanced approach.

And while I’m at it, you should keep in mind that requiring a supplier never to release a product if there are any vulnerabilities in it could lead to the supplier ceasing to report vulnerabilities to the NVD at all (remember, by a large margin, most vulnerabilities are reported to the National Vulnerability Database by the supplier itself). Unless assiduous security sleuths are searching for and reporting vulnerabilities in that supplier’s products (and I doubt that happens for any but a tiny fraction of software products and intelligent devices today), soon there won’t be any vulnerabilities that show up in a scan of the product, since none will be found in the NVD. Problem solved (from the supplier’s point of view, anyway). The fact is that patching all vulnerabilities, regardless of severity or exploitability, is a fool's errand.

The second reason why a software user should read Walter’s post is the careful, balanced way he approaches vulnerability management. This applies both to this post and his posts on vuln management that are aimed at end users (note to Walter. Please put links to one or two posts focused on end user vuln management in the comment section below, as well as in the comments on this post in LinkedIn). 

Walter always keeps the North Star of maximum possible risk mitigation in front of him when he writes these posts, but he’s also careful not to become dogmatic about that. This is especially true when striving for maximum risk reduction would require a complicated process that would make Rube Goldberg blush with envy. It’s much better to provide advice that people can actually follow, as opposed to advice that might win kudos with the risk management freaks but would be impossible to follow in practice (or even counterproductive, as Walter regularly points out).

Tim Roxey emailed me the following commment on this post:

Failure of imagination was a blue ribbon panel finding for the 9/11 commission. It is a finding of many of the attacks I have studied both inside CONUS and on the events the US gov had asked me for support in other locations globally. Including war zones. 

It’s simplest observable is in the question “who would do that?  Or “wait, what? 

Cognitive dissonance. 

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.