Purpose
The purpose of the Vulnerability Management Standard is to establish the expectations and guidelines for applying service packs, hotfixes, and security patches (referred to generally as “security patches” throughout this document) in the interest of reducing the University’s vulnerability exposure.
Definitions
Security patch – Code that will update the current version of a script or software, often used to fix a bug, update security, or add a new feature or new functionality (includes service packs, hotfixes, etc.).
Data – Information collected, stored, transferred, or reported for any purpose in digital format. Data can include: financial transactions, lists, identifying information about people, projects or processes, and information in the form of reports. Because data has value and because it has various sensitivity classifications defined by federal law and state statute, it must be protected.
Traffic Light Protocol (TLP) – A simple framework for indicating when and how sensitive information is permitted to be shared.
TLP: AMBER+STRICT – Information with this designation may be shared with members of the organization on a need-to-know basis to protect the organization and prevent further harm.
CISA – The Cybersecurity & Infrastructure Security Agency. A US government agency, part of the Department of Homeland Security, responsible for cybersecurity and infrastructure protection across all levels of government.
KEV Catalog – Known exploited vulnerability catalog. CISA publishes a list of vulnerabilities that are known to be exploited by malicious actors in the wild.
Mitigation – A decision, action, or practice intended to reduce the level of risk associated with one or more threat events, threat scenarios, or vulnerabilities.
Partial control – One of the following is true: The exploit gives the threat actor limited control over, or information exposure about, the behavior of the software that contains the vulnerability; or the exploit gives the threat actor a low stochastic opportunity for total control. In this context, “low” means that the threat actor cannot reasonably make enough attempts to overcome obstacles, either physical or security-based, to achieve total control. A denial-of-service attack is a form of limited control over the behavior of the vulnerable component.
Total control – The exploit gives the adversary total control over the behavior of the system or software, including if the exploit reliably reveals log-in credentials.
Forensic Triage – The collection, assessment, and prioritization of digital evidence or physical clues. For the purpose of this article, it is an assessment of whether or not a system vulnerable to a specific flaw has been compromised.
Scope
All systems and applications operated by or on behalf of the University. This includes user workstations, servers, operating systems, middleware (Java, Adobe, etc.) and applications both on-premise and in the cloud. While this document focuses primarily on security and bug patching, it is necessary to keep all software up to date and on supported code to prevent situations where multiple upgrades need to occur or software is no longer supported.
Introduction
Security patches are updates to products to resolve a known issue or provide a workaround. Service packs update systems to the most current code base. Being on the current code base is important because that's where the operating system support focuses on fixing problems. Individual hotfixes and security patches should be adopted on a case-by-case, "as-needed" basis. They may or may not be relevant to an installation. Evaluate the update, assess the risk of applying or not, and apply if appropriate.
The basic rules are:
The risk of implementing the service pack, hotfix, or security patch should ALWAYS be LESS than the risk of not implementing it
And,
You should never be worse off by implementing a security patch. If you are unsure, then take steps to ensure that there is no doubt before moving changes into production.
Scheduling and Delivery
General system updates, service packs, or hotfixes should be installed at a time that limits interference with the majority of users. Where appropriate testing and signoff have occurred as part of the University change control process, general upgrades may occur at any time convenient to the user base and system administrator or where available on a regularly scheduled process.
Security patches, which may also be included in regular system updates, service packs, or hotfixes should be applied as soon as feasibly possible following research, testing, and notification. Admins are required to apply released security patches to their systems in a specific timeframe based on various risk factors:
- Exposure
- KEV Status
- Automated Exploitation
- Technical Impact
Use the chart below to determine the required remediation timeline:
| External Exposure | Exists in KEV | Automatability | Technical Impact | Timeline for Remediation |
| Yes | Yes | Yes | Total Control | Immediate + Forensic Triage |
| Yes | Yes | Yes | Partial Control | Immediate |
| Yes | Yes | No | Total Control | Immediate + Forensic Triage |
| Yes | Yes | No | Partial Control | 3 Days |
| Yes | No | Yes | Total Control | 3 Days |
| Yes | No | Yes | Partial Control | 3 Days |
| Yes | No | No | Total Control | 3 Days |
| Yes | No | No | Partial Control | 7 Days |
| No | Yes | Yes | Total Control | 7 Days |
| No | Yes | Yes | Partial Control | 7 Days |
| No | Yes | No | Total Control | 7 Days |
| No | Yes | No | Partial Control | 14 Days |
| No | No | Yes | Total Control | 14 Days |
| No | No | Yes | Partial Control | 30 Days |
| No | No | No | Total Control | 30 Days |
| No | No | No | Partial Control | 60 Days |
Exceptions
If the application of security patches is not feasible, mitigating controls must be identified and implemented. The mitigating control(s) selected should be in proportion to the risk. A risk exception must be documented in the Jira Information Security Exception project and approved by Information Security Office. Mitigating controls or risk exceptions are to be used for limited periods of time and may not exceed one year. After this time period the exception case must be reviewed to assess continued need.
Responsibilities and Practices of the Information Security Office (ISO)
The ISO conducts scans of the University network resources to identify vulnerabilities. Only ISO or units approved by the Chief Information Security Officer may conduct such scans. The ISO will create dashboards and ensure access is available to all technology staff managing servers or applications, as appropriate.
Vulnerability data is classified as TLP: AMBER+STRICT. It may only be shared with other UConn employees on a need-to-know basis.
Vulnerability Response Process and Responsibilities
The Information Security Office maintains the Nessus vulnerability scanning service and regularly scans areas of the network where servers and applications are known to exist. Results of scans are immediately available. Individuals responsible for systems and applications are responsible for monitoring these results.
Once notified of the vulnerable resource, the IT administrator or third party managing that resource should follow the schedule presented in the “Scheduling and Delivery” section to close the vulnerability. Care should be taken to ensure all actions are taken to address the vulnerability or it may continue to be a risk or falsely reported as a risk. If a risk is accepted, this should be documented in Nessus within the remediation timeframe.
If the vulnerability is not remediated in the recommended or agreed upon timeframe and no exception has been granted, ISO staff may take necessary actions to safeguard the University network, including disconnecting the resource from the network to protect other computers and the integrity of the University computing environment.