Vulnerability Remediation

If a vulnerability scan identifies vulnerabilities in your unit, or you learn of new vulnerabilities, you are expected to remediate them in accordance with Vulnerability Management (DS-21).

Some systems may be subject to laws, regulations, contractual obligations, or industry standards that require faster remediation or additional controls. Examples may include systems subject to PCI DSS, HIPAA, research sponsor requirements, or other regulatory obligations.

Where an external requirement is stricter than DS-21 or this guidance, the stricter requirement applies.

Prioritize Based on Severity

Prioritize your remediation efforts based on the severity of the vulnerability and its potential impact on the confidentiality, integrity, or availability of the vulnerable system or data, unless otherwise instructed by ITS Information Assurance (IA). Vulnerability severity is determined by the rating provided by the Tenable Vulnerability Priority Rating (VPR). VPR provides a more accurate risk-based severity by incorporating exploits active in the wild. Visit Tenable documentation for information on CVSS vs. VPR rating

Highest priority should be given to vulnerabilities rated Urgent (VPR 10.0),  Critical (VPR 9.0 - 9.9), and High (7 - 8.9). While priority is given to vulnerabilities with Urgent, Critical, and High ratings, this is not an indication to ignore Medium and Low-rated vulnerabilities. Threat actors will link together lower rated vulnerabilities as a method to breach systems. They should be reviewed and patched as needed. 

NOTE: The “Urgent” priority rating is a U-M defined category that pertains to items rated 10.0 and is unique to the university. 

Make a Plan to Remediate

Remediation plans should:

  • Follow your existing patch processes.
  • Validate that the vulnerability is properly identified and prioritized.
  • Include action-oriented descriptions of the steps that will be taken to mitigate the vulnerability.
  • Ensure that appropriate resources are, or will be, available to remediate the vulnerability.
  • Identify milestones in the remediation process to fully address and resolve the vulnerability.
  • Ensure that the schedule for resolving the vulnerability is achievable and allows for appropriate testing.

Can't meet the expected remediation timeline? Contact IA (through the ITS-Network Vulnerability Scanning form) to discuss options and alternatives to ensure a safe IT environment in your unit.

Remediation Expectations

Vulnerabilities that potentially put Restricted or High data or mission-critical systems at risk have the shortest timeframe for implementing recommended mitigation. Detected vulnerabilities are to be remediated in accordance with the timeframes described in this guidance unless an exception has been approved by IA using the Request to Exclude/Recast IT Security Vulnerability in Tenable form.

If there is an IA alert

If IA has issued an alert for a vulnerability, requirements specified within the alert supersede those above. Some vulnerabilities that pose a significant risk may require expedited timeframes for remediation. The IA alert will state when there is a need for accelerated action.

If there is a compliance requirement

Laws, regulations, standards, or contractual agreements may also dictate a higher priority and shorter timeline than the VPR score alone indicates.

For example, PCI prescribes specific remediation timelines based on CVSS score in order to comply with the Payment Card Industry Data Security Standard (PCI DSS).

Blocking and Other Risk-Reduction Actions

Risk-reduction actions may include increased monitoring, additional compensating controls, restricted access, removal from exposed networks, or network blocking.

Blocking is intended to reduce risk to university systems, data, and networks. When circumstances allow, IA will work with the team to validate the issue, communicate expected action, and identify available remediation or mitigation options before blocking occurs.

The CISO may authorize blocking of systems or applications from the U-M network when a vulnerability is not properly remediated within the required timeframe or when the system presents unacceptable risk.

A blocked system may be restored to the network after the vulnerability has been remediated or after IA determines that sufficient mitigation is in place.

Exceptions

When a system is unable to meet the requirements defined in the Vulnerability Management standard, an exception must be requested using the Exclusion form.

Reasons for exceptions may include:

  • Systems that cannot support the installation of the enterprise vulnerability management system.
  • A required patch that is not compatible with the system or application.
  • When remediation would disrupt a critical service before a tested fix is available.
  • If vendor support is required and not yet available.
  • A legacy system that cannot be remediated without replacement.
  • Another documented limitation prevents remediation within the required timeframe.

Units requesting an exception must document the technical or business limitation preventing remediation within the required timeframe, identify compensating controls that reduce risk during the exception period, and provide a planned timeline for remediation.

Exceptions are specific to a system and time-limited. Approved exceptions may remain visible in vulnerability reporting and must include documented compensating controls, monitoring, and a defined target remediation date. Exceptions are subject to review at least annually.

Exception approval depends on the risk and priority of the vulnerability or requirement involved.

  • Exceptions involving Urgent or Critical vulnerabilities may require CISO approval and unit executive awareness or approval.
  • Exceptions involving High vulnerabilities may be reviewed and approved by IA.
  • Exceptions involving the inability to install the enterprise vulnerability management system will be reviewed by IA based on system risk, exposure, and available alternatives.

IA may require additional information, shorter exception periods, compensating controls, or periodic status updates as a condition of approval.