Before anyone actually talk about patches, we should think why a patch needs to be installed. Actually the patching happens for mainly TWO reasons.
- To fix security vulnerabilities
- To add a feature of some functional addition for the application
As per my experience, I would suggest installing all the security related patches as a priority. Because, if we keep a application unpatched for a security vulnerability, it may lead to exploitation of the particular vulnerability and could actually compromise the entire organization. If I were to be more precise, if the application is public facing or accessible from the Internet, then you should definitely be installing security patches as a priority, because, the application may be accessed by hackers easily through Internet.
To answer your question, there is NO defined period for patch management in the wild. That depends for each application according to the need. here are few tips you can follow to have a better patch management process.
For me to explain it easily, assume that your application is found with a security vulnerability.
- First of all confirm that the vulnerability is TRUE and not a false positive
- Then prioritize the need of patches according to your organizational needs and the impact the vulnerability could pose.
- Then check for any patches available by the vendor (or may be you can develop a patch, if its your own application).
- If the vendor has a patch available, you can go ahead on installing it. But the important part here is, make sure the patch is legitimately from the vendor and confirm the legitimate source of of the patch. because, these days, one of the methods target attacks is by fooling a user saying "you have a security patch to install", and forcing a malicious payload. So, make sure the patch is from the legitimate source.
- While you confirm the source, you have to perform an Impact Analysis on installing the patch, in parallel. This may include any potential adverse situations could occur by installing it (Ex: downtimes, systems crashes, malfunctions, etc). This is simply a form of Risk Assessment. If you find any risks which could occur, please have a roll back plan with you, so you can roll back if something goes wrong.
- The next ideal step is to install the patch in a testing environment and make sure the patch works properly. If the test is successful, then you're almost good to go with the live system.
- The next IMPORTANT thing, which most people miss out is logging. You should be log everything you didn't with this particular patching process and keep documentation regarding that. Documenting such a process may help you in many ways (ex: if you had to refer to any past patches, if the same problem occurs again, you might have to check back, for investigation purposes, etc.)
While you do all of these tasks, please ensure accountability. Assign people for tasks and make sure they are responsible for what they have been assigned. It will make your process more effective. In addition to that, if possible, document this process somewhere as a PROCEDURE and make it formal, so that everyone can follow the same procedure for upcoming patch installations.
This whole cycle simply referred to as Patch Management. And this is not only for security patches, you can have this for any patch.
Hope this was informative. Please add your comments and questions below, i'll respond if I am capable of.
Bookmarks