Patch Management Standard

Purpose and Benefits

Patch management is the process for identifying, acquiring, installing, and verifying patches for products and systems. Patches correct security and functionality problems in software and firmware. Applying these patches proactively prevents the exploitation of known vulnerabilities.

Authority

The Chief Information Security Officer (CISO) and business unit Information Security Officers (ISO) are authorized by the university’s executive officers to act, as needed, to ensure that un-remediated systems or applications do not pose a threat to university information resources. When a critical vulnerability is not remediated within a required timeframe or is improperly remediated, the CISO or ISO may temporarily block the system or application from the network until such time as the remediation is effectively completed.

Scope

This standard relates specifically to vulnerabilities that can be addressed by a software or firmware update (patch) and applies to all software used on the entity’s systems. The Vulnerability Scanning Standard Exception process should be followed for requirements on addressing non-patched vulnerabilities.

Department IT Responsibilities

1.  Departments must assign an individual or group that is responsible for patch management.
2. Responsible individuals must continuously monitor scan results and follow through with remediation efforts based on the vulnerability reports provided by the enterprise vulnerability scanning service.
3.   If patch management is outsourced, service level agreements must be in place that address the requirements of this standard and outline responsibilities for patching.  If patching is the responsibility of the third party, entities must verify that the patches have been applied.
4.  A documented process must be in place to manage patches.  This process must include the following:
   • Monitoring security sources for vulnerabilities, patch and non-patch remediation, and emerging threats.
   • Overseeing patch distribution, including verifying that a change control procedure is being followed.
   • Testing for stability and deploying patches.
   • Using an automated centralized patch management distribution tool, whenever technically feasible, which:
     • maintains a database of patches
     • deploys patches to endpoints
     • verifies installation of patches
5.  It is recommended that appropriate separation of duties exist so that the individual(s) verifying patch distribution is not the same individual(s) who is distributing the patches.
6.  As per the Information Security Policy, all entities must maintain an inventory of hardware and software assets.  Patch management must incorporate all installed IT assets. 
7.  Patch management must be prioritized based on the severity of the vulnerability the patch addresses according to Enterprise Vulnerability Management ratings or as deemed necessary based on risk by threat intelligence and the information security team.
8. To the extent possible, the patching process must follow the timeline contained in the table below.

Vulnerability Remediation Timeframes

 Any of these timeframes may be accelerated at the discretion of the appropriate ISO.

9.   If patching cannot be completed or a vendor has not made a patch available within the timeframe in the table outlined above, compensating controls must be put in place within the timeframes listed above and the exception process must be followed.
10.   If a patch requires a reboot for installation, the reboot must occur within the timeframes outlined above.

Existing Servers

• Every networked server must be enrolled in the Enterprise Vulnerability Scanning (EVS).
• An administrator account must be established on each server to be used solely for the purpose of conducting scans, or the appropriate agent must be installed to provide vulnerability details.
• Vulnerability assessments must be performed at least monthly. Failure to have monthly authenticated scans may result in the system being removed from the network.
• Scans shall be performed during hours that minimize disruption to normal business functions.
• System administrators must not make any temporary changes to networked servers for the sole purpose of passing a scan.
• Servers connected to the network cannot be specifically configured to block vulnerability scans from the authorized EVS.
• Vulnerabilities must be mitigated or eliminated through proper analysis and repair methodologies, in accordance with the university's Data Classification System and within the timeframes specified in the table above.

New Servers

• No new servers can be placed into production until a vulnerability assessment has been conducted and vulnerabilities are addressed.
• Scans will be conducted in accordance with procedures established by the ISO at each business unit but, at a minimum, before the server goes into production.
• Vulnerabilities must be mitigated or eliminated through proper analysis and repair methodologies, in accordance with the University's Data Classification System and within the timeframes specified in the table above.
• It is the responsibility of the service owner to monitor for available patches and updates to the service, as well as monitor the security posture of the operating system used to distribute the service, and if necessary, take action to mitigate known vulnerabilities.

Web Application Scans

Web application services that handle sensitive information (DCL3 and DCL4) should request a security scan for new deployments and for significant changes. Vulnerability assessments for systems handling public or DCL2 data can be requested and conducted at the discretion of the information security team with the resources available to them. 

The information security team may perform unauthenticated exploratory scans on web services to determine vulnerable systems and escalate if necessary.

Exceptions

An ISO may grant exceptions to the scanning requirement or to remediation of a discovered vulnerability at their discretion. Requests for such an exception including the justification must be submitted in writing according to procedures established by each ISO.