3 ms·

I don't recall being at, or working with, a company where this wasn't _the_ reason patches were delayed at least some period if time. Companies are driven by p

I don't recall being at, or working with, a company where this wasn't _the_ reason patches were delayed at least some period if time. Companies are driven by profit; unknown patches can negatively affect profit and are usually treated as such. Alternatively, there are sometimes political reasons. A director may not want to risk an outage for fear of being dressed down by their VP. Any change to a production environment comes with risks, sometimes having a security risk is judged to be lower risk than making a change. I've seen this from small startups to multi-billion dollar companies. Ignoring these factors is also putting your head in the sand.

dopamean 9y ago
> Alternatively, there are sometimes political reasons. A director may not want to risk an outage for fear of being dressed down by their VP. This is such a weird thing to me. I've never worked anywhere like this and so I have a hard time imagining it really. Wouldn't that same director get more than dressed down by the VP if on their watch a _known security vulnerability_ was ignored and the system was breached? I just can't understand this way of thinking.
- thehardsphere 9y ago
  It's easy to understand once you get just how simplistic it is. The VP will deliver a dressing down if the company loses money and the blame can be placed on the director. The cost of an outage is very easy to quantify (revenue per minute the system is down), and the probability that something will go wrong while applying the patch is also somewhat easy to predict, and usually greater than zero. The director will be blamed with certainty for the outage, since he approved it. The cost of a security breach is difficult to quantify; it depends on what gets breached and how bad. Note here, I say breach, not vulnerability. Even if there is a known security vulnerability, it's not immediately obvious in all systems what the consequence will be; there may be other mitigations in place outside of software that reduce the potential damage, or there may be unknown vulnerabilities that are exploitable due to the known vulnerability that make would make a breach worse. The lack of certainty about the consequences means it's also possible for the director to avoid blame if the breach is minor ("how was I supposed to know that other team is still using MD5?"). If there is no breach, then there is nothing for the director to be blamed for. Given that the director would like to avoid being dressed down, director will be more inclined to delay patching over possibly causing an outage, because the costs of an outage are easy to predict and he will take all blame for it. The breach may never happen and even if it does, it may cost him personally less than the outage. If this still seems weird, it might be because you are someone who views patching as an easy thing to do, because you probably work for a software company. Software companies are used to managing changing software, and have all kinds of practices around minimizing the risks of doing so. Non-software companies typically find patching to be hard and costly because their core business is something else; changes can disturb the "something else."

dopamean 9y ago

> Alternatively, there are sometimes political reasons. A director may not want to risk an outage for fear of being dressed down by their VP. This is such a weird thing to me. I've never worked anywhere like this and so I have a hard time imagining it really. Wouldn't that same director get more than dressed down by the VP if on their watch a _known security vulnerability_ was ignored and the system was breached? I just can't understand this way of thinking.

thehardsphere 9y ago
It's easy to understand once you get just how simplistic it is. The VP will deliver a dressing down if the company loses money and the blame can be placed on the director. The cost of an outage is very easy to quantify (revenue per minute the system is down), and the probability that something will go wrong while applying the patch is also somewhat easy to predict, and usually greater than zero. The director will be blamed with certainty for the outage, since he approved it. The cost of a security breach is difficult to quantify; it depends on what gets breached and how bad. Note here, I say breach, not vulnerability. Even if there is a known security vulnerability, it's not immediately obvious in all systems what the consequence will be; there may be other mitigations in place outside of software that reduce the potential damage, or there may be unknown vulnerabilities that are exploitable due to the known vulnerability that make would make a breach worse. The lack of certainty about the consequences means it's also possible for the director to avoid blame if the breach is minor ("how was I supposed to know that other team is still using MD5?"). If there is no breach, then there is nothing for the director to be blamed for. Given that the director would like to avoid being dressed down, director will be more inclined to delay patching over possibly causing an outage, because the costs of an outage are easy to predict and he will take all blame for it. The breach may never happen and even if it does, it may cost him personally less than the outage. If this still seems weird, it might be because you are someone who views patching as an easy thing to do, because you probably work for a software company. Software companies are used to managing changing software, and have all kinds of practices around minimizing the risks of doing so. Non-software companies typically find patching to be hard and costly because their core business is something else; changes can disturb the "something else."