N-1 patching strategy

The technology industry is no different to many other industries and businesses – in that it has jargon and terminology that may often need to be defined to be understood. Within IT, the term “n-1” means that you are one version or release behind the most recent. This is part of IT language is the way to take a strategy for patching and updates to always be one version behind the latest. But, what should your N-1 patching strategy be?

Reason for patches and updates

What is the reason for patches and updates to be released anyway? Why do software vendors need to send out modifications for their software? Apart from releasing new features and capabilities, the software vendors may need to fix security vulnerabilities and provide stability fixes. Not all software can consider all the ways that people can break it, or what ingenious hackers can do to find vulnerabilities or ways to make the software unstable.

Automatic Updates

Almost all software has built-in mechanisms to allow updates to be automatically downloaded from the vendor’s servers over the Internet, and then to prompt the user to install the update, and restart the software if necessary. I’m sure that you have personally experienced a prompt on your own computer or phone for an update to be installed. In a business environment, this can be an impact for operations where the user of the software is asked to confirm, install, and restart. Instead, most enterprises will centrally manage updates and patches to schedule them to happen out of hours and multiple at once. So, most business-level software allows the control of update timing.

The problem with updates

Unfortunately, the same issues with developing software in the first place that may have problems or vulnerabilities, will exist with the updates. This is, that the updates themselves may have new vulnerabilities. Additionally, if it is a feature or functionality update or release, this may remove or change features that may not meet with the business’ needs. The largest concern is that the update or patch may introduce instability or even make the system fail. For this reason, many IT functions will delay the implementation of an update – until others

N-1 patching strategy – benefits

A common approach is to not install the most recent update, and always be one version behind. This n-1 strategy for patching will allow an organisation to protect themselves from the risk of a new update being the cause of new problems. The benefits of taking the n-1 approach to patching is that you are avoiding running software that is untested or unverified. The software vendor will test their patch works, but they cannot test in your environment will all your software and systems – your unique combination of software and hardware may be the cause of instability of the new patch. Sometimes, a vendor may release a patch, and then recall it – and being at n-1 will avoid the process of trying to handle a rescinded update.

The problems of an N-1 strategy

The most significant drawback of taking an N-1 approach is that you are running software that has known problems, with a known fix. If there is an update released by the software vendor, it is because they have resolved a vulnerability or stability issue. For a security concern, this could be significant, as a known vulnerability is what hackers are looking for – finding an unpatched vulnerability is their aim. The only really protection of taking an N-1 approach is that you are protecting from the software vendor having poor software testing capabilities. With the aforementioned issue that the vendor cannot test their software in your environment, this vendor testing failure issue becomes less relevant.

Taking an “n minus one” strategy, there is a requirement for your team to keep an eye on discussion forums or the vendor websites to find out if there are issues or problems with the update. This may be fine for major products, for smaller or less popular products, this will depend on the vendor announcing their failings. How long could it be before the issues are found? Are problems only identified after monthly activities?

With an N-1 strategy, you have no idea how long it will be before the next fix is released – so there is a risk that you could be running buggy or vulnerable software for months or even years. It is far better to apply the fix for known issues, but if you are concerned, not immediately roll out the patch.

Alternative to N-1 strategy

It has been in IT dogma for a long time that you should be in an N-1 environment, however the threat landscape has changed. When there is a fix available for a security vulnerability, there are malicious actors scanning the Internet for anyone who has not yet implemented the fix. Instead of leaving your environment in a vulnerable or buggy state, set a time for rolling out the update. I have recommended before to use a N+45 approach to patching, with the intention of leaving a full month and a half for identifying any known issues with updates on the Internet. However, for security updates, this may be too long. Depending on the product (operating system and security products should be updated swiftly), it may be best to take an approach of N+5 to allow issues to be identified.

Internal testing

The pressure on the IT department to be responsible for the stability and security of all the environment, is growing. It has become increasingly important to test all releases and products, but also to test all updates and patches. Microsoft moved to a Patch Tuesday approach in October 2003 (switch from a “release when it is ready” approach prior), and this meant that IT departments created processes to test patches before deployment, but can all updates be tested? Read my war story on an anti-virus update considering that key files were infected, falsely.