Automatic Updates: Set It And Forget It … I Don't Think So
By Ian Trump, Security Lead, MAXfocus
It’s true that Microsoft and other vendors have built automatic updating capability into their systems. Microsoft Office and some of the more common third-party applications, such as Adobe Flash, Adobe Reader, and others, have this functionality too. As a result, many organizations have used a combination of Group Policy Objects, the free Windows Update Services, and adjusting the corporate image of some products to do automatic updates. Sadly, these organizations are under the mistaken impression that they are managing their IT. However, those IT pros who have tried to adopt this kind of “set it and forget it” approach are setting themselves up for a number of nasty shocks, and could even end up getting fired
There are a lot of terrible things about auto-updating in the real world. For example, it’s highly possible, and indeed probable, that a Java update could render critical business websites or applications unavailable to a large number of users. This generates a tremendous amount of stress and pressure on IT teams to restore services. This is just one powerful reason why patches should be tested before mass deployment. If you’re not pretesting your patches, then you are putting your business and your career at risk. If you’re set to “auto,” every day a vendor pushes out a new patch could be your last.
IT history is littered with stories of auto-updates that have stopped working. Unfortunately, when they do there is no way for this to be noticed by busy IT staff. The choice to “auto-update it and forget it” introduces a false sense of security at best, and a gigantic vulnerability at worst. The reality is, if you’re not clean booting machines prior to patch deployment, there is a good chance the install is not going to work.
Furthermore, some auto-updates require administrative privileges to successfully deploy, and if your users all have those you are in for a whole heap of trouble, as you have ultimately lost control of your IT environment. You’re not managing IT you’re the equivalent of the cleaning staff in IT.
One of the key reasons that vendors issue patches is because of the discovery of an active exploit, which has been incorporated into the latest cybercrime toolkits. If some or all your machines are not updated properly, you have a situation where — especially in the case of Adobe Flash — bad things are going to happen. Those bad things are ransomware and Cryptolocker attacks; and they don’t just affect workstations they go after the file shares on a file server too. So if one (or more) machine(s) fail to auto update, and you don’t know, everybody ends up suffering.
With new Cryptolocker variants running around, which exploit Microsoft Office, Java, and Adobe Flash to name a few, do you really want to risk all your files to an infection because auto-update failed and you didn’t notice? This scenario has affected countless folks who have tried to rely on auto-updates, so don’t think it’s not going to happen to you.
And infection is only just the start of it … Once a security breach has occurred you have another — possibly career ending — problem on your hands. Whether you’re an IT services provider or internal IT person, you’re going to have a rough time convincing executives of your due diligence if you have set things to automatic and failed to notice they were not updating.
If you’re in a situation in which your reliance on auto-updating has caused a breach, expect awkward questions from regulatory bodies, government, or lawyers. Expect to be asked for evidence and documentation of your vulnerability (patch) management program (this blog will act as a good starting point of you don’t have a patch management program already). Not having one may expose you to allegations of not being compliant with regulatory requirements, or privacy law. It gets ugly from that point onwards.
When you sit down and think about it, placing your IT career in the hands of large vendors that provide limited update functionality (and no warning that it failed) is not a wise idea. A tool to coordinate patching, document your patching efforts, identify failed patches and, most importantly, test a patch on a single system before mass deployment is a much better option for your business and ultimately your future in IT.