IV. The Processes for Patch Management
1. Security and Patch Information Sources
- Vendor Reported Criticality - vendor reported criticality is a key input for calculating a patch's significance. Higher priority should be considered for "High" vendor reported criticality as reverse engineering of the patches may result in severe security breaches.
- System / Service Criticality - The relative importance of the information systems or data is another valuable input for assessing the priority. The servers of a university's financial system or student information registry are more critical than desktops and should be patched first.
- System Exposure - information systems accessible by external users or the general public are exposed to higher probability of malicious attacks and therefore require close attention by the universities.
For example, vulnerabilities or program bugs for DMZ systems could lead to more dangerous security incidents than those related to internal file servers. Therefore, the relevant patches of DMZ systems should enter the patch cycle earlier.
Based on the nature of the IT environments and service characteristics, each university should establish a prioritisation matrix, which provides clear guidance and criteria on patch prioritisation for the responsible IT security staff.
3. Patch Validation and Testing
The patch testing process begins with the acquisition of the patches and continues through acceptance testing after production deployment.
- Report to software vendor and obtain an understanding of the underlying risks for not deploying the patch, and request an updated version of the patch
- Implement additional security controls to mitigate associated risks
- Shut down the software function where the vulnerability resides so that it cannot be exploited