Software updates: why you shouldn’t ignore them

Software

You know the drill. Your computer prompts you that there are software updates pending, but it just isn’t a convenient time. Maybe you’re in the middle of paying bills. Maybe you are writing a paper. Maybe your excuse is simply that you are Facebook stalking our buddy’s latest love interest.  No matter the reason, you simply put the updates off over and over again.  You might have even become adverse to installing them at all because it seems that every time you do, something stops working the way you like it to.

What’s the point of software updates?

Many people believe that regular software patches provide new features, added compatibility, or otherwise modernize applications so that they stay current with technology.  While this is sometimes true, to an extent, these sorts of updates are normally reserved for major revisions, such as going from version 1.x to version 2.x of a particular program. Patches, or minor revisions, are instead normally released to correct flaws and improve security.

After an application or an operating system version is released, it is an accepted fact that it is not perfect.  Software is simply a set of instructions, compiled together, that define what the program is supposed to tell a computer to do in response to some sort of input. The instructions, or code, that make up software are complex and the developers who write them are prone to human error.  Because of this, software products are continuously tested and evaluated for flaws that either leave the software functioning improperly or allow it to be exploited to do something it was not intended to do.

Once  software flaws are discovered, which is very often, software vendors begin working on ways to fix those flaws.  After a fix is developed, it is then pushed out as a patch. Then your operating system’s software update mechanism or the application itself begins to pester you to update.

What is the risk in not updating software?

By simply knowing that the existence of flaws in software is the primary reason for patches, it should go without saying that if software remains unpatched, then those flaws, also called vulnerabilities, continue to exist.  While some software companies find many of their own vulnerabilities, security researchers like those at McAfee are responsible for discovering the vast majority of software vulnerabilities and reporting those flaws to the software vendors.  They also frequently publish their findings so that others might have the opportunity to address these issues in their own products.

Some security researchers, sometimes called bug hunters, are what you would call black-hat; looking for flaws so they can exploit them or use them to harm the software developer in some way. Others are grey-hat, or neutral in their motivations for finding bugs and opt to give or sell them to the party with the most enticing offer.  These not-so-virtuous security researchers are known to share their findings with those who create malicious applications or utilize exploits to directly take advantage of software vulnerabilities.

Viruses, worms, root kits, ransomware, and many other forms of ‘malware‘ are the result of known vulnerabilities being exploited by malicious programmers. Often times variations of the same malware will persist for quite some time, as we have recently seen with the WanaCry ransomware and again with it’s more recent variant, Petya.  Malware developers focus on known vulnerabilities because they know that millions of people simply do not apply software patches and known vulnerabilities can often continue to exist around the world for several years.

Many security researchers agree that one of the greatest threat in cybersecurity is unpatched software. If organizations and individuals would simply apply every patch available and stay updated to the latest versions of software, a significant number of the attempted attacks each year would be far less successful, if at all.

Addressing issues from updates

But what about when patches break things? It is true that sometimes applying patches may make applications or even entire systems stop functioning as well as they did before the patch was applied. This is most prevalent in organizations with group policies, a great deal of shared data, standard system configurations, and a great deal of interconnected systems.  Being adverse to applying patches until you know what they will do to your network isn’t exactly the wrong approach to take but you should take expeditious measures to find out how they might affect your systems so  you can apply these fixes ASAP.

It is advised by most commonly accepted information security standards to first test updates.  To do this, it is best to have a test network that is as similar as possible to your actual network environment so that the effects of any change are likely to indicate what a real-world patch deployment will mean to your organization. Can’t afford a test network?  Well, an acceptable alternative is to first make sure you are diligent at backing up your important data and simply apply patches to a small sampling of your systems so you can evaluate the effects.  Once you have determined that the patch doesn’t produce any undesirable side effects, or you have at least worked through the kinks, then push the patch out to the rest of your network.

It is important to take patch management seriously, though.  Remember that for every moment you have unpatched systems on your network, you are allowing the existence of potentially dangerous vulnerabilities that might easily be exploited to bring your entire network to a screeching halt or expose sensitive information to those who should not have it.

 

About Dustin Wilson

I have been working professionally in Cybersecurity since 2011. I earned my A.A.S. in Computer Science, a B.S. in Cybersecurity, and am currently working on a M.S. in Cybersecurity. Prior to working in this field, I was a computer programmer for nine years.

View all posts by Dustin Wilson →

Leave a Reply

Your email address will not be published. Required fields are marked *