Myth #5: It’s too risky to patch
I can’t count the number of
times I’ve been told by a client that it’s too risky to patch. The
justifications are varied, but they usually fall into one of these general
categories: (a) we can’t afford any downtime; (b) it’s a legacy system; (c)
patches have been known to cause problems; or (d) our systems aren’t certified
if we patch.
Let’s look at each of them in
more detail.
“We can’t afford any
downtime” is code for the implementation doesn’t have any redundancy or
resilience, combined with a lack of understanding of whatever business process
it is supporting. There is no such thing as 100% uptime, as some of the natural
disasters in the last year have proved. And if there is a real business
requirement for something close to 100% availability, then building a system
without appropriate redundancy is an epic fail. This has nothing to do with
patching.
“It’s a legacy system” is an
excuse used by businesses that have poor strategic planning. A system which no
longer has patches available, also no longer has support available. If a
business is running a critical system with unsupported components I hope the IT
manager is wearing their peril sensitive sunglasses! That way when they have a
critical failure it will be without all the fear and worry that normally
precedes one. This also has nothing to do with patching.
“Patches have been known to
cause problems” is an example of the logical fallacy called the excluded
middle. Just because a bad event has ever happened, doesn’t mean that the
opposite is always true. By using this same logic, we should never get in a car
as car crashes have caused deaths. It is true that patches sometimes do caused
problems, but this isn’t a reason not to patch. While this is at least related
to patching, it’s actually more about having a poor testing process,
insufficient change management, and lack of understanding of risk management.
“Our systems aren’t certified
if we patch” is code for letting the vendor set the security posture rather
than the business. I mentioned this before in Myth #2 as a problem with
outsourcing security, and it’s equally true here. This really doesn’t have
anything to do with patching either.
In reality the certain loss
from not patching is far higher than the theoretical loss from patching. In the
Defence Signals Directorate top 35 mitigations against targeted cyber-attacks,
patching applications is #2 and patching operating systems is #3. I really
think that DSD has a much better understanding of the risk than most IT
managers.
Patching is a foundation for
good security as it eliminates the root cause of most compromises. Better patch
management leads to lower accepted risk, and this is something that all
executives want.
Any system too risky to patch
is too risky to run, and that is why this myth is completely busted.
Phil Kernick Chief Technology Officer
@philkernick www.cqr.com