There is an article over at Dark Reading that discusses the challenges of vulnerability management and the slow integration of disparate products to produce a more comprehensive platform for such initiatives. Many are familiar with the pain of managing the variety of automated and manual tasks to measure compliance. Especially fun is the prioritization of the torrent of findings produced by these tasks.

Enterprises also must consider risk from the business perspective rather than just go about wielding a patch checklist. “If a system has limited business value, it’s less important than a vulnerability in a server that holds our credit card numbers,” Maiwald says.

I agree a hundred percent with the first sentence and disagree 100 percent with the latter. That last statement is so filled with assumptions that it is hard to take it seriously. It is an exceedingly dangerous generalization. It takes a systems involvement in storing sensitive information as the primary metric in prioritization. Now, I know that it was only an example in the article, but it was a bad one. This is because there are many, many more factors that should be considered when prioritizing remediation. A quick shotgun list would include things like position in the network (it is not a binary internal/external game), the relationship (logical and physical) between a system and other identified critical systems, the characteristics of the identified vulnerability and the types and roles of users on the vulnerable system. I think it is time to handle prioritization in a way that isn’t a binary comparison between things like internal/external or sensitive/public, don’t you?