If you do not currently have a process for applying security patches and updates for your system, the first step is to develop one. To avoid unintended consequences, it’s important to have a plan of action before beginning to apply patches. Some key things to consider:
This can be in the form of a log where you document what patches you applied, to what systems, and at what time. You may also want to include a short detail of what the patch fixes, why you have chosen to apply it, and the potential level of risk if something were to break as a result.
Schedule a recurring time every month or quarter in which you plan to take systems offline to update them. Many IT folks do all their patching immediately following Patch Tuesday, which is the second Tuesday of every month. This is when Microsoft releases all of their patches for the month, so it’s a good time to apply some potentially serious updates. Many other software vendors also release their patches around this time, so you can take care of a great number of updates with one systems outage.
Not all patches and updates are critical. Research the nature of the update, what it fixes, and determine whether or not it applies to your systems. Zero-day vulnerability patches are considered critical as they are a direct result of a known exploited security hole in software.
If you are far behind on updates, or you have many different types of patches to apply, avoid doing more than a few at once. Deploying too many at one time creates the possibility that something may go wrong, and you will need to dig through all of them to find out which one caused an issue. However, make sure to look at how these updates may interact in case one depends on another.
If you have a non-production environment, development environment, or sandbox, test installing these updates to see how the operate and any potential consequences. The best way to do this is within a full non-production copy of your current environment, as that is the closest you can get to the real thing without affecting production systems.
If test deployments go well, you may want to start with production systems that are least critical if failure occurs, and updates that are less likely to cause major issues. Once the update has been running solid for 1-2 weeks, you may begin rolling out the update on other systems.
Not all patches and updates go smoothly. Determine an appropriate method for bailing out depending on what you’re updating. Sometimes this is as easy as uninstalling the update, or reinstalling the prior version. In other cases, reverting to a backup copy or snapshot of your system immediately prior to the update may be necessary. It is extremely important to have a contingency plan should things go wrong.
There are some simple measures you can take that require minimal effort and may help you in the long run.
If you are running any operating systems or software packages that have reached end-of-life support, please strongly consider upgrading them to more current versions or uninstalling it altogether. End-of-life means that the company or vendor is no longer releasing security updates or patches and is in essence no longer supporting it. This leaves them highly vulnerable to attack if an exploit is found.
If you absolutely must run end-of-life software due to business needs or compatibility issues, consider whether or not that system requires internet access. By isolating the system and keeping it off the network, you greatly reduce the risk of attack.
Take inventory of what’s installed on your systems and if they are no longer needed, uninstall them.