Recently (at time of writing) there has been a huge world-wide Ransomware outbreak that was totally preventable by a patch that had been made available some two months before the outbreak. Hospitals (UK in particular) have been brought to their knees and have reportedly resorted to paying the ransom in an effort to have their data restored. Patients have had surgeries rescheduled. Doctors unable to view past history of patients. A total balls up to say the least!
"Wait a Bit" arguments to applying updates..
As I mentioned in my summary above, for years System Administrators have used a "Wait a Bit" type of reasoning to justify not applying Security Updates as soon as they are made available. I'm not just talking about Microsoft Operating System updates here either, but of third party software solutions that end users and organisations rely on daily. The idea behind this type of reasoning includes;
..the reasoning (or excuses) for waiting to patch can go on and on.
So are these types of excuses valid? - Not in this authors opinion!
Let’s briefly discuss the above arguments to wait..
There are (undeniably) reported cases from around the world where organisations have experienced downtime as a result of a released security patch. So what? I would lay the blame of downtime as a fault of the System Administrator's patch implementations and support methodology, rather than the patch itself. Note that as a system administrator of several company servers myself, this isn't a statement I make lightly.
Most of us generally patch Windows Operating Systems once a month unless an urgent hot-fix is required - third party software solutions all year round as updates are made available. It just doesn't make any sense to wait when talking in terms of security. If problems after patching are realised, then they should be dealt with and resolved immediately. Sticking your head in the sand and hoping that waiting won't bring dire consequences is just a way of avoiding any possible required remediation works if something did go wrong.
Moving on to Blue Screen of Death possibilities - this is so rare that it barely deserves a mention. The same goes for the "Recall Patch" argument. A simple roll-back of the system if such a problem is struck after patching is all that's required until an altered patch can be obtained.
The last example I provided does have a small amount of merit when it comes to available company resources. Where it falls over is that a resource strategy rethink is required on the part of the company. It's never a good idea to trade security improvements to avoid any possible problems in immediately implementing patches designed to address already realised security flaws.
A sensible approach to patching..
It can often be a case of that security flaw simply not applying to your own particular environment. If for example, a patch addresses an identified IIS (Internet Information Services) security flaw and you don't use IIS in your environment, then that could be a valid reason to wait before applying the patch.
Make sure you have a way of easily reverting your system to a pre-patched state in a worst case scenario, whether that be as simple as using built in system restore functionalities, to having an incremental image backup of your system prior to the installation of any newly released patches.
It's always imperative that you keep in mind that things can and do go wrong. It's how "you" choose to protect yourself in handling such eventualities when they crop up that will separate you from the rest of the pack.
I'll end this by saying that my own personal practice has always been to apply any available operating system security patches immediately. The same rings true for third party software solutions that I or my clients heavily rely on. I always take an incremental image backup prior to applying updates and have had to use them to restore from on odd occasions over the years. These however, have been far and few between.
I encourage comments and discussion on this topic in the comments area below.
Please do share your opinions / ideas.