On "Patching"

IT projects are historically, not to say always, late.  There are a number of reasons for this.  We prioritize schedule before quality; it is part of our culture.  We think that schedule is easy to measure. We think that we are on schedule until late in the effort, when quality jumps up and bites us in the ass.  Another reason that we are late is that we fix things in the order of their discovery rather than in the order of their importance.

This is a way of behaving that we replicate in Cybersecurity.  Not only do we fix things in the order of their discovery but we fix them in the order that someone else discovers them.  Microsoft announces forty vulnerabilities, ten critical, on "patch Tuesday."  We drop anything else we might be doing to apply the patches.  

Microsoft was shamed into publishing one or more of the patches.  Google Project Zero discovered the vulnerability and generously gave Microsoft ninety days to fix it under the threat of a public shaming if they failed.  

Ninety days is arbitrary.  It is not based on the ease of exploiting the vulnerability, how wide spread it is, how costly it is to fix, what the fix might break, or what other vulnerabilities Microsoft may have on its plate.  It is one size fits all.  Sometimes Microsoft even chooses the shaming, in part because of what it knows that Google does not and cannot know.  We often patch without even considering whether or not the vulnerability represents a risk to us.  

Again, it is part of our culture.  Of course, as a result of this automatic, Lemming like, behavior, we may all be at greater risk than we need to be.  

Whatever our vendors or our peers may be doing, we need to fix things in order of their risk to our enterprise.  We need to resist letting others allocate our scarce resources into "unplanned activity."  We need to put aside fear generated by the breach of our neighbor because of an unapplied patch.  

Know your risk tolerance.  Identify your risks.  Mitigate, accept, and assign them in the order of that risk.  Document risk acceptance.  Plan your work and work your plan.  Prefer mitigation measures that are broad over those that are merely most effective.  Keep in mind that hiding vulnerabilities, for example behind firewalls, is often more efficient than patching them.  At least the mistakes you make will be your own.