|
Reduce
the Monthly Pain of Patching
Security
experts might imagine that the highest priority of
any IT department would be the immediate mitigation
of any important known vulnerability as soon as a
patch becomes available. But operations personnel
know that any change to a running system brings with
it the risk of interruptions to the very service
that they are tasked with maintaining. Also,
introducing changes to an operating environment can
make it incompatible with the applications that
enable that service. How then to balance the
potential threats from an unpatched vulnerability
with the potential threats from the installation of
that patch?
To
answer that question, JW Secure reached back into
its previous work with the National Vulnerabilities
Database (NVD).
The NVD database is generated by the process that
creates and archives all of the Common
Vulnerabilities and Exposures (CVE)
numbers that show up in software vendors’ patch
reports.
In
analyzing vulnerabilities on all major operating
system (OS), two unfortunate trends became clear:
first, that the incidence of reported
vulnerabilities has not been reduced on any OS,
including the open-source ones. Second, most of the
patches required a reboot of a critical service –
this guarantees some level of disruption.
However, one approach which promises immediate
reduction of service outage is a careful evaluation
of the components running on the server. If a
software component is not running, then a patch for
that component will not require a reboot. Not only
that, but less code running on the server means a
reduced surface for attackers to target.
Unfortunately, the security bulletins from software
vendors offer little help in determining whether a
patch will really cause a reboot on the server.
Bulletins do, however, often provide a work-around
that helps to determine if the vulnerability can be
mitigated by disabling the software component that
contains the vulnerability.
In
summary, here are the two steps that have been shown
to empirically reduce the number of reboots from
patches by 60%:
- If
the service doesn’t need the functionality of a
software component, don’t run that component. If
it is only needed occasionally, say for
maintenance, don’t keep it running during normal
production.
-
Examine each patch as it is released. If the
software to be patched is not needed, disable
it. The patch should be deferred if possible to
some later time when a reboot is needed for
other purposes.
Interesting reports on vulnerabilities and patching:
|
Welcome to the
ninth edition of the JW
Secure Informer, our bi-monthly newsletter. This is
an opportunity to share what’s on our radar,
specifically with respect to enterprise network
security, but also regarding IT and business more
generally.
