Vulnerability Management Procedure

Version 2.3

For Students, Faculty, Staff, Guests

Purpose

The purpose of this procedure is to establish a standardized, repeatable approach for identifying, prioritizing, remediating, and validating vulnerabilities across University IT Resources. This procedure supports the implementation of the Vulnerability Management Policy and ensures timely risk mitigation using approved tools and best practices. 

Scope

This IT security document and all policies referenced herein shall apply to all members of the University community, including faculty, students, administrators, staff, authorized guests, delegates, and independent contractors (the “User(s)” or “you”) who use, access, or otherwise employ, locally or remotely, the University’s IT Resources, whether individually controlled, shared, stand-alone, or networked.

Procedure Steps

The steps in the vulnerability management procedure ensure a systematic approach to identifying, prioritizing, planning for, addressing, and validating the resolution of vulnerabilities within IT systems and applications.

1. Discovery Phase:  Identify vulnerabilities present within IT Resources.
2. Prioritization Phase: Discovered vulnerabilities and assets are reviewed, prioritized, and assessed using results from technical and risk reports.
3. Planning Phase: Devise comprehensive mitigation strategies and action plans to address identified vulnerabilities.
4. Remediation Phase:  Implement necessary measures to address and rectify vulnerabilities identified during the discovery phase.
5. Validation Phase:  Conduct subsequent analysis to determine the effectiveness of the remediation measures deployed.

Discovery Phase

Utilize tools (e.g., BitSight, Burp Suite, Invicti, Nmap, Qualys, WPScan) to perform vulnerability scans and detect weaknesses within systems and applications. Alternative assessments, tools, or methodologies may be leveraged to determine vulnerabilities. 

Prioritization Phase

Vulnerabilities must be prioritized based on severity and contextual risk (e.g., public-facing, critical system). Criteria include: 

• Qualys:  
  • Address findings with confirmed severity levels 5 (Critical), 4 (High), and 3 (Medium)  
  • Address findings with a TruRisk Score ≥ 700 
• BitSight: Remediate all findings graded as “Bad” 
• Invicti: Address all findings rated Critical, High, or Medium 

Conflicts in severity assessments must be resolved in consultation with Information Security and Assurance (ISA). 

Planning Phase

Remediation timelines based on the initial discovery date (i.e., first detected date of vulnerability on respective IT Resources): 

• Within 30 Days
  • BitSight “Bad” grade findings 
  • Qualys confirmed severity levels 5 and 4 
  • Qualys confirmed severity level 3 within the PCI environment 
  • Invicti Critical and High findings 
• Within 60 Days
  • BitSight “Warn” grade findings 
  • Remaining Qualys confirmed severity level 3 findings 
  • Invicti Medium and Low findings 
• The ISA may identify findings that are not directly in line with the assessment tools mentioned above and may need to be addressed outside the noted days mentioned.

Remediation Phase

System and application owners must undertake one or more of the following, including but not limited to:

• Deployment of patches or updates 
• Configuration changes 
  • Registry entries, group policy settings, and configuration files 
  • Content security policies and header configurations  
  • Certificate issues 
• Implementation of mitigating controls (with ISA approval) 
• System upgrades or decommissioning  

Validation Phase

Confirm the effectiveness of remediation efforts through the following activities: 

• Verify Resolution: Ensure that identified vulnerabilities have been fully addressed and no longer pose a security risk. 
• Reconcile Discrepancies: Compare remediation actions with validation scan results to identify and resolve any inconsistencies. 
• Confirm Absence of Vulnerability: Validate that the vulnerability no longer exists by referencing the original source of the finding (e.g., vulnerability scanning tool, ad hoc discovery). 
• Escalate Outstanding Issues: Refer unresolved vulnerabilities or suspected false positives to ISA for further investigation or risk evaluation. 

If remediation has been implemented but is not reflected in the validation scan, or if the finding is no longer applicable (e.g., mitigated by compensating controls or identified as a false positive), the system or application owner must notify ISA via email at [email protected].  

Definitions

IT Resources include computing, networking, communications, application, and telecommunications systems, infrastructure, hardware, software, data, databases, personnel, procedures, physical facilities, cloud-based vendors, Software as a Service (SaaS) vendors, and any related materials and services.

A patch is a software update comprised of code inserted (i.e., patched) into the code of an executable program. Typically, a patch is installed into an existing software program. Patches are often temporary fixes between full releases of a software package. Patches include, but are not limited to, the following:

• Upgrading software
• Fixing a software bug
• Installing new drivers
• Addressing security vulnerabilities
• Addressing software stability issues

Remediation is an effort that resolves or mitigates a discovered vulnerability.

Vulnerability is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system’s security policy.

Vulnerability management is the practice of identifying, classifying, remediating, and mitigating vulnerabilities.

Related Policies and Procedures

• Vulnerability Management Policy
• Patch Management Policy

Implementation Information

Review Frequency:	Annual
Responsible Person:	Senior Director of IT Security and Assurance
Approved By:	CISO
Approval Date:	March 25, 2019

Revision History

Version:	Date:	Description:
1.0	01/08/2018	Initial document
1.1	03/25/2019	Procedure updates
	05/08/2020	Periodic review
1.2	07/26/2021	Updated statement and removed products no longer in use
1.3	08/10/2022	Updated procedure statement
1.4	11/29/2023	Updated WPScan
2.0	03/06/2024	Updated purpose, scope, procedure
2.1	05/21/2024	Updated Invicti (formerly Netsparker)
2.2	06/02/2025	Updated Procedure
2.3	08/26/2026	Updated Procedure