Purpose

The purpose of the Server Vulnerability Management Standards 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.).
Severity – This is the level of importance of the security patch as defined by the vendor or as a Common Vulnerability Scoring System (CVSS) score.
Priority – This is the level of importance of the security patch as defined by UConn. This includes a timeframe for the expected installation of the security patch.
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.

Scope

All systems and applications operated by or on behalf of the University. This includes 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 notification) using the following timeframes:

 

CVSS or Vendor Defined Criticality	Timeline
CVSS (9.0 – 10.0) or Critical designation by vendor	Patches should be installed as soon as reasonably possible or mitigating controls put in place to reduce vulnerability. Patch Timeframe – Within 7 days Mitigation Timeframe – Within 2 days (if necessary)
CVSS (7.0 – 8.9) or High designation by vendor	Patches should be installed as soon as reasonably possible or mitigating controls put in place to reduce vulnerability. Patch Timeframe – Within 14 days Mitigation Timeframe – Within 2 days (if necessary)
CVSS (4.0 – 6.9) or Medium designation by vendor	Remediated or accepted and documented in Nessus within 60 days
CVSS (0.1 – 3.9) or Low designation by vendor	Remediated or accepted and documented in Nessus within 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. If mitigating controls cannot be implemented, then a risk exception must be documented in Nessus and reviewed by Information Security Office. Mitigating controls or risk exceptions are to be used for limited periods of time and may not exceed one year without approval of the Chief Information Security Officer.

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 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 (server farm network). Results of scans are immediately available via individuals created custom reports for systems of interest. Individuals responsible for systems and applications are responsible for setting up and monitoring these reports or manually checking in on a regular basis.

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.