Patch management defines a managed process that describes changes to systems and, if possible, tests or checks the changes before they are rolled out.
A classic change would require change management and the approval of those responsible. Since patches come regularly, they should be considered “standard changes” and are approved after successful testing.
Patch management belongs to the change enablement from ITILv4, to the change management from ISO 27001 or to the OPS: Operation module from IT-Grundschutz. These frameworks describe generically or as “best practices” how to deal with these types of changes in your IT infrastructure.
A patch is, for example, a bug fix in software or an operating system. A “patch” that fixes a gap or error in the system or improves functionality. Basically, there is a difference between a security patch, i.e. fixing a security gap and preventing it cyber attacks, a bug fix, the error correction and the feature update, the functional expansion.
A common problem with patch and change management is insufficient resources to make this process truly effective. If patch management is centrally automated using software in order to save costs and time, compatibility with the existing systems should still be tested beforehand. Unfortunately, occasional errors also occur with patches, which, if rolled out untested, may cause more problems in the IT system network than they resolve.
To ensure that the IT security level is as high as possible and the risk to the information network remains low, it is important to prioritize the patches before testing. First, security vulnerabilities and vulnerability closed and the errors are only corrected afterwards and new functions are activated. This is the only way to ensure effective patch management.
Of course, no administrator should go to each system individually and test the unrestricted functionality. Rather, a separate and separate test area that is very similar to the IT network is suitable for manually testing the compatibility of the systems. After a successful test, the patches can be rolled out fully automatically and promptly to all affected systems. Nothing stands in the way of successful patch management. For Windows systems, Microsoft's own Windows Server Update Service is usually used, in which you can set up several areas and thus control the release of patches for the respective areas. There are countless other providers who also monitor third-party software, which can also be affected by security gaps.
In the event of an error, which hopefully occurs during patch management, the patch must be withheld and a suitable workaround for security patches and possible bug fixes must be found. Of course, the test network must be restored and the workaround must also be checked.
As part of patch management, these should be tested before distribution so that they do not cause errors in the system network. Testing should be done in a separate area that is secured separately so as not to endanger the entire system. The final rollout to the affected systems should then be carried out in a timely manner, automated and software-supported. Of course, the result should also be checked as far as possible so that a backup can be installed for patch management in the event of an error.
