GDL-3000.07D: System Patching Guidelines
Guideline Summary
Intended Audience: University personnel responsible for patching systems
Guideline Owner: Director of Information Security
Definitions
|
System Steward |
An individual responsible for management of a University-owned system such as a workstation, server, router, switch, printer, controller, or other network-attached device. They may create and enforce management and access policies. They are often referred to as Business Owners. |
|---|---|
|
System Custodian |
An individual responsible for the technical management of a University-owned system such as a workstation, server, router, switch, printer, controller, or other network-attached device. They implement the best practices defined by the System Steward and perform operational duties. |
Introduction and Scope
This guideline covers Patching requirements for any device connected to the University network including servers, workstations, printers, networking equipment, controllers, IoT devices, and anything else requiring network connectivity, as well as any of the services or applications provided by the equipment. Patching includes, but is not limited to applications, database servers, middleware, operating systems, and firmware.
Systems running on an isolated network segment may be exempted from this guideline.
Patch Management of University-Owned Systems
All University-owned systems and devices should have designated System Stewards and System Custodians who are responsible for inventories of the systems’ hardware and software and assuring that the systems are being patched. Patching includes but is not limited to software, database systems, middleware, operating systems, and firmware. System Stewards are responsible to ascertain that patch management is documented. Documentation may include automated processes that are audited.
Notification of Patches
System Custodians performing patching will subscribe to services providing notification of the availability of patches.
Patching Windows
All systems should have regular designated patch windows. Exceptions should be approved by the Director of Information Security.
Categorizing Patches and Patching Timeframes
System Custodians should categorize patches using the Common Vulnerability Scoring System (CVSS) on a quantitative scale from 0 to 10, and a qualitative scale of None to Critical. Table 1 translates between the qualitative and quantitative vulnerability scales.
Table 1 – Vulnerability Severity Scales
| Qualitative | Quantitative |
|---|---|
| None | 0.0 |
| Low | 0.1-3.9 |
| Medium | 4.0-6.9 |
| High | 7.0-8.9 |
| Critical | 9.0-10.0 |
Security updates, patches, or upgrades designated as Critical or High should be applied as soon as possible and within 7 days. Those vulnerabilities rated as Medium should be patched within 30 days. The patching of Low vulnerabilities is optional. Table 2 summarizes the vulnerability rating and patching window requirements.
Table 2 - Vulnerability Ratings and Patch Windows
| Vulnerability Rating | Patch Window Requirement |
|---|---|
| Critical or High | 7 Days |
| Medium | 30 Days |
| Low | No Requirement/Optional |
Patch Testing and Schedules
Where possible, patches should be deployed and verified in a test environment prior to release into production. If a test environment is not available, systems should be backed up and a rollback plan should be in place.
Patching Verification
A process should be in place to verify that patches have been applied. Using automated tools and reporting is recommended.
Patch Management of Non-University Owned Systems
Any individual connecting a personal device to the University network is responsible for patching their system using standards comparable to the patching of University-owned systems.
Unpatched Systems and Legacy Systems
Any unpatched systems found on the network may be isolated, blocked, and/or disconnected by University IT personnel.
The University should avoid running systems that are no longer supported with security patches. System Stewards and System Custodians are responsible for planning for end of life/end of support for all equipment and applications including but not limited to hardware, firmware, operating systems, and software.
A plan to upgrade or replace a legacy system should be made a year in advance, and the replacement completed six months prior to end of support. Exceptions must be approved by the Director of Information Security.
For the complete guideline, click "Full Document" tab at top of page.
Full Document
Intended Audience: University personnel responsible for servers, workstations, printers, networking equipment, controllers, IoT devices, and anything else requiring connectivity to the University network, as well as any of the services or applications provided by the equipment
Guideline Owner: Director of Information Security
1. Definitions
|
Patching |
The process of distributing and applying updates to software, operating systems, and firmware. Patches are often necessary to correct system and application security Vulnerabilities or functionality (bugs). In the context of security, patching also includes changes in configuration settings that mitigate security Vulnerabilities. |
|---|---|
|
Risk |
The potential that an event may cause a material negative impact to an asset. Risk can be determined as a product of the severity of a vulnerability, the likelihood the Vulnerability will be realized, and the potential impact of a threat being realized. |
|
System Steward |
An individual responsible for management of a University-owned system such as a workstation, server, router, switch, printer, controller, or other network-attached device. They may create and enforce management and access policies. They are often referred to as Business Owners. |
|
System Custodian |
An individual responsible for the technical management of a University-owned system such as a workstation, server, router, switch, printer, controller, or other network-attached device. They implement the best practices defined by the System Steward and perform operational duties. |
|
Vulnerability |
A point of risk that could result in penetration of a security barrier. Awareness of potential vulnerabilities is key to designing more effective defenses against attack by unauthorized parties. (OCIO 141.10). |
2. Introduction and Scope
This guideline covers Patching requirements for any device connected to the University network including servers, workstations, printers, networking equipment, controllers, IoT devices, and anything else requiring network connectivity, as well as any of the services or applications provided by the equipment. Patching includes, but is not limited to applications, database servers, middleware, operating systems, and firmware.
Systems running on an isolated network segment may be exempted from this guideline.
3. Patch Management of University-Owned Systems
OCIO 141.10: 5.5
University-owned systems must be patched for vulnerabilities.
3.1 Designation of a System Steward
OCIO 141.10: 5.5(1), 8.2(2)
All University-owned systems and devices should have designated System Stewards and System Custodians who are responsible for assuring that the systems are being patched. Patching includes but is not limited to software, database systems, middleware, operating systems, and firmware. If a system and the services and applications it hosts have multiple System Stewards and System Custodians, the responsibilities for patching should be agreed on by all parties.
3.2 Authorized Software and Systems
OCIO 141.10: 5.5(2), 8.2(1)
The University should maintain an inventory of systems and software deployed to University-owned systems. System Stewards should identify authorized and unauthorized software, and System Custodians should ensure that only authorized software is installed.
3.3 Documentation
The System Steward is responsible to ascertain that patch management is documented. Documentation may be done by any party responsible for patching. Documentation may include automated processes that are audited.
3.4 Notification of Patches and Vulnerabilities
OCIO 141.10: 5.5(3)
System Custodians performing Patching will subscribe to services providing notification of system Vulnerabilities.
3.5 Categorizing Vulnerabilities
OCIO 141.10: 5.5(4)
System Custodians should categorize Vulnerabilities using the Common Vulnerability Scoring System (CVSS) on a quantitative scale from 0 to 10, and a qualitative scale of None to Critical. Table 1 translates between the qualitative and quantitative vulnerability scales.
Table 1 – Vulnerability Severity Scales
| Qualitative | Quantitative |
|---|---|
| None | 0.0 |
| Low | 0.1-3.9 |
| Medium | 4.0-6.9 |
| High | 7.0-8.9 |
| Critical | 9.0-10.0 |
3.6 Patching Timeframes
OCIO 141.10: 5.5(6)
Security updates, patches, or upgrades designated as Critical or High should be applied as soon as possible and within 7 days. Those vulnerabilities rated as Medium should be patched within 30 days. The patching of Low vulnerabilities is optional. Table 2 summarizes the vulnerability rating and patching window requirements.
Table 2 - Vulnerability Ratings and Patch Windows
| Vulnerability Rating | Patch Window Requirement |
|---|---|
| Critical or High | 7 Days |
| Medium | 30 Days |
| Low | No Requirement/Optional |
3.7 Patching Timeframes Exceptions
Systems that are not tolerant of downtime due to the business cycle or that are at risk of having functionality impaired may develop alternate patching strategies. The strategies should be documented and include:
- A description of the system components (e.g., servers or application components and their functions).
- A ranking of the risk exposure of each system component. Risk factor should be qualitatively or quantitatively calculated using vulnerability severity, likelihood of vulnerability exploitation, and impact if the vulnerability were to be exploited (Risk = severity x likelihood x impact).
- Any mitigations that can be put in place (segmentation, application proxying, etc.).
- A patching schedule that occurs no less than quarterly throughout the year.
3.8 Patch Testing
OCIO 141.10: 5.5(5)
Where possible, patches should be deployed and verified in a test environment prior to release into production. If a test environment is not available, systems should be backed up and a rollback plan should be in place.
3.9 Patching Windows and Schedules
Every system including the hardware, firmware, operating system, and software components should have a designated patching window and be patched on a regular schedule. For any system that cannot have a regular schedule, an alternative patching strategy must be documented.
3.10 Patch Verification
A process should be in place to verify that patches have been applied.
3.11 Patching Recommendations
3.11.1 Patch Reporting Recommendation
OCIO 141.10: 5.5(7)
Successful patching may be verified using tools such as:
- Reports from configuration management tools (e.g., Puppet, SCCM, Jamf).
- Reports from endpoint management tools (e.g., Microsoft Defender Security Center).
- Vulnerability scanning reports (e.g., Nessus).
4. Patch Management of Non-University Owned Systems
OCIO 141.10: 5.5(9)
Any individual connecting a personal device to the University network is responsible for patching their system using standards comparable to the patching of University-owned systems.
5. Unpatched Systems
OCIO 141.10: 5.5(10)
Any University-owned systems that cannot be patched require an Exception to Policy to be approved by the Director of Information Security. Any unpatched systems found on the network may be isolated, blocked, and/or disconnected by University IT personnel.
6. Legacy Systems
The University should avoid running systems that are no longer supported with security patches. This includes patches for any servers, workstations, printers, networking equipment, controllers, IoT devices, or anything else connected to the University network.
6.1 System End of Life/Support
System Stewards and System Custodians are responsible for planning for end of life/end of support for all equipment and applications including but not limited to hardware, firmware, operating systems, and software. A plan to upgrade or replace a legacy system should be made a year in advance.
6.2 System End of Life/Support Guidelines
6.2.1 Upgrade and Replacement Plan Timeline Guideline
Upgrading or replacing a legacy system is recommended six months prior to the end of life/support date.
6.3 Legacy System Exceptions
The University should only allow legacy systems to run on the University network if the following conditions are met:
- There is a critical business need for the application.
- The upgrade or replacement will take longer than 120 hours of labor.
- Mitigations are put in place to protect the systems and data.
- An upgrade, replacement, or retirement plan has been drafted and approved by the University Chief Information Officer.
6.4 Legacy System Tracking
The Information Security Office should maintain a list of legacy systems that are no longer supported.
7. Authority
- University policy POL-U3000.07 - Securing Information Systems
- Washington State Office of the Chief Information Officer (OCIO) 141.10 – Securing Information Technology Assets Standards
8. References
- NIST 800-171: Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
- NIST 800-40: Guide to Enterprise Patch Management Technologies
- OCIO 141: Securing Information Technology Assets
- OCIO 141-10: Securing Information Technology Assets Standards
- OCIO Policy No. 103: Technology Policy and Standards Waiver Request
- National Vulnerability Database
Change Log
| Revised | Version | Author | Approver | Change |
|---|---|---|---|---|
| 03/26/2021 | 1.0 | Beth Albertson | ITS Standards & Guidelines Committee | Original Version |