UMS Official Policy Document for Vulnerability Management
UMS Vulnerability Management Program
- Contact: infosecurity@maine.edu
- Adopted Date: 6/1/2022
- Responsible Office: Office of Information Security
- Approved By: Office of Information Security
Reason for Policy
Vulnerability management is a critical component in cyber resilience and necessary to reduce risks to the University.
Who Should Read This Policy
IT Staff; Others who manage computing systems on behalf of the University.
Policy Statement
Vulnerability Management Program
CONTENTS
1: Overview & Purpose
2: Scope
3: Roles and Responsibilities
3.1: Default Patch Management Responsibilities
3.2: US:IT Vulnerability Management Responsibilities
3.2.1: University of Maine System Chief Information Officer (CIO)
3.2.2: Information Security Office (ISO)
3.2.3: System and Application Administrators
4: Active Scanning Program
4.1: Systems Scanned
4.2: Scanning Frequency
4.3: Scanning Environment
5: Vulnerability Findings & Risk Assessment
5.1: Escalation and Expedited Timelines
6: Remediation
6.1: Remediation Timeframes
6.2: Corrective Action Plans
7: Exception Process
7.1: Exception Approval and Risk Acceptance
8: Periodic Reporting
8.1: Measures of Effectiveness
1: Overview & Purpose
Due to the dynamic nature of software applications, firmware, operating systems, networks, and evolving external threats, vulnerabilities are ever present. Vulnerability management is a critical component in cyber resilience and necessary to reduce risks to the University.
The University of Maine System Information Security Office (ISO) maintains this Vulnerability Management Program in compliance with the UMS Information Security Policy and Standards.
Objectives of the vulnerability management program include identifying, communicating, assessing, and remediating vulnerabilities and system flaws and their associated risks.
2: Scope
This vulnerability management program applies to any cyber assets connected to University of Maine System networks or operated by the University. Systems not owned by the University (such as students’ systems) that affect University services or assets may be subject to this program at the University’s discretion and included in scanning and mitigation strategies under this program.
Vulnerabilities present in UMS assets or services arise most commonly when:
- Software remains unpatched after a vendor has released fixes following the discovery of a vulnerability
- Services or applications are configured in a way that allows for unauthorized access to data or other resources
- Software or systems enter an end of life state, where vendors no longer release software patches
Note: The University may investigate other external leads but does not operate a bug bounty program.
3: Roles and Responsibilities
Anyone who maintains software on University owned systems will maintain awareness of security vulnerabilities and other system flaws that impact the systems they maintain, either directly from vendors or software maintainers, or other reliable, independent sources.
3.1: Default Patch Management Responsibilities
Anyone with responsibility for maintaining a University owned system is responsible for identifying and mitigating security flaws on the systems they maintain in a timely manner.
- Responsible party will maintain awareness of software and firmware updates through automatic (rss feed, email subscription, auto-updating) or manual methods (e.g. visiting a vendor's support website) on a routine basis, in order to learn the availability of new patches within at least 7 days of initial availability.
- Once the responsible party has learned of an update to address a system flaw, the relevance to the party's managed systems will be evaluated and an action plan created within established timelines based on criticality, see Remediation Timeframes
- The flaw will be remediated by applying the update or otherwise mitigating it by following vendor recommended workarounds, within established timeframes, see Remediation Timeframes
Valuable resources for timely vulnerability information include:
- NIST’s NVD National Vulnerability Database (nvd.nist.gov)
- CVE - Common Vulnerability Enumeration website (cve.org)
- Communication channels maintained by software vendors and open-source software development teams to notify customers of emerging vulnerabilities in the software they provide.
- Alert feeds from US-CERT, CISA, SANS, and other independent organizations about emerging vulnerabilities with widespread impact.
3.2: US:IT Vulnerability Management Responsibilities
3.2.1: University of Maine System Chief Information Officer (CIO)
The CIO is authorized to act, as needed to ensure un-remediated systems do not pose a threat. When a critical vulnerability is not properly and promptly remediated, the CIO may direct IT staff to block the system from the network until appropriate actions are taken to reduce risk.
3.2.2: Information Security Office (ISO)
ISO is responsible for conducting routine enterprise-wide vulnerability scans of systems connected to the UMS network. ISO will assist in assessing risk from scan results and managing exceptions and the process for accepting risk. The ISO will conduct one-time scans and provide ad hoc threat/vulnerability advisories.
ISO actively identifies security vulnerabilities in a select subset of US:IT managed systems.
- Network Vulnerability Scanning (Tenable, SecureTrust, Dorkbot)
- Agent-based Vulnerability Scanning (Tenable)
- Penetration tests for PCI compliant environments
ISO relies on a variety of threat feeds and detection processes to identify potential vulnerabilities across all UMS cyber assets:
- Threat Intelligence via membership in Sharing and Analysis Centers (REN-ISAC, MS-ISAC)
- Threat Intelligence from government sources (InfraGard)
- Network Visibility Intelligence Services (Shodan, ShadowServer)
- Intrusion Detection with Open Source and Commercial Rulesets
3.2.3 System and Application Administrators
System and application administrators are responsible to assess and apply vendor-supplied security patches and other remediations for systems under their purview. This includes addressing ISO conducted scans results or advisories/alerts and promptly remediating or filing for exception.
4: Vulnerability Discovery Procedures
Discovering vulnerabilities that affect the University is essential to the Vulnerability management program, and this is most often accomplished via vulnerability scanning coordinated by the Information Security Office. Vulnerability scanning is an automated task that identifies missing system patches, improper configurations, or other software vulnerabilities. Scanning will be conducted with minimal operational impact.
4.1: Systems Scanned
All systems connected to the UMS network or operated by the University can be subject to vulnerability scans. Certain regulatory programs (PCI, CUI, HIPAA) and University Policy require scanning for vulnerabilities. Scanning for vulnerabilities varies depending on the type of service, ownership, or location.
- All servers that are property of the University or are located at the University are subject to vulnerability scanning. This includes servers that are owned or managed by those departments outside of US:IT.
- End-user systems that are property of the University or are located at the University may be subjected to vulnerability scanning. Systems under certain offices with compliance programs will be regularly scanned.
- Payment card industry requires scans by an approved scanning vendor. The University currently uses Secure Trust (Trustwave) to perform internal scans and INNO4 for penetration tests of certain environments in accordance with the data security standard (PCI-DSS). PCI scanning is conducted per program requirements, and results are fed into the Trust Keeper portal.
- Vulnerability scanning is not a routine service offered to students or other personally owned devices except to the extent that a known vulnerability may cause disruption to systems belonging to the UMS, or other University data.
- Cloud based IaaS and PaaS systems that don’t include appropriate vulnerability scanning by the vendor may be subject to scans.
4.2: Scanning Frequency
ISO scans systems at least weekly. One-time scans can be requested as can post-remediation scans.
4.3: Scanning Environment
Active network scanners and software agents comprise the scanning environment. Network scanners, both on-premise and cloud-based, are used to identify vulnerabilities in services exposed via network connection. Agent scanners are installed on key assets to identify a wider range of software and configuration vulnerabilities from within the particular system.
5: Vulnerability Findings & Risk Assessment
Vulnerability findings provide a severity rating according to NIST’s Common Vulnerability Scoring System (CVSS) v3.0, where possible.
Other factors that are considered during the vulnerability findings risk assessment process:
- Exposure to the public internet
- Presence of restricted/confidential Data
- Datacenter firewall protection
- Management by US:IT staff
- Single user(endpoint) or multi-user(server)
- Service impact: user base
- End of life/vendor unsupported Operating System or other software
5.1: Escalation and Expedited Timelines
If ISO, in consultation with the systems administrator, determines an elevated need for remediation/patching, expedited timelines may supersede those above. Some critical vulnerabilities that pose a significant risk may require expedited timeframes for remediation, such as exploit code has been released publicly, exploit code has been bundled into common exploit frameworks (e.g. metasploit), attacks have been observed in the wild, attacks in the wild are widespread, etc.
6: Remediation
Remediation should be prioritized according to the associated severity and the impact on the confidentiality, integrity, or availability of the vulnerable system. Scores are provided that best represent the risk and should be used for prioritization. However, system administrators and owners of the systems may have a different perspective of the systems which may warrant exceptions to the scanning results or accepting of risks due to other factors.
6.1: Remediation Timeframes
1. Determine Remediation Timeframe
After a vulnerability is detected and a fix is available, the timeline for remediation begins.
- Critical (CVSS 9-10) Vulnerabilities:
Create a corrective action plan within 3 calendar days
Remediate vulnerability within 14 calendar days
- High (CVSS 7-8.9) Vulnerabilities:
Create a corrective action plan within 14 calendar days
Remediate vulnerability within 30 calendar days
Can be resolved based on availability of staff resources.
6.2: Corrective Action Plans
Corrective actions plans are for the benefit of the teams that are responsible for implementing the remediation. In the event of ongoing or evolving vulnerabilities, corrective action plans may be requested by ISO to coordinate multiple teams’ remediation efforts.
Corrective action plans are intended to follow proper change management and should:
- Validate that the vulnerability is properly identified and prioritized;
- Action-oriented descriptions of the steps that will be taken to mitigate the vulnerability;
- Ensure that appropriate resources are or will be available to resolve the vulnerability;
- Identify milestones necessary to fully address and resolve the vulnerability;
- Ensure that the schedule for resolving the vulnerability is achievable.
7: Exception Process
In accordance with the Information Security Policy and Standards, exceptions to a vulnerability may be considered when there is a justifiable business and/or research case, resources are sufficient to properly implement and maintain the alternate configuration, the exception process is followed, and other University policies and standards are upheld.
An exception request should include a mitigation strategy, the estimated duration, and any other factors which reduce the risk. A form is available to improve the efficiency of this process.
7.1: Exception approval and risk acceptance
When the risk is sufficiently mitigated or shown to not be significant, the CISO or the CIO may approve an exception. When the risk cannot be sufficiently mitigated, an acceptance of risk must be made by the appropriate business owner, generally the campus Chief Business Officer (CBO) or equivalent, or by the CIO.
8: Periodic Reporting
In order to keep the vulnerability management process inclusive of leadership to manage risk, periodic reporting will be presented to the CIO. This will be done on a semi-annual basis with ad hoc reporting upon request.
A report will include a summary of
- Systems with critical vulnerabilities that have not been mitigated in specified timeframes.
- A summary of high and medium vulnerabilities
- A list of systems with exception and/or risk acceptance
- A list of systems that have not had risk acceptance approved.
- A summary of the devices with operating systems that are at the end of support.
8.1: Measures of Effectiveness
Metrics will be collected to show the effectiveness of the program and trends. Such measurements will include:
- Number of assets that were not remediated within the required timeframes
- Percentage of IT assets that were not remediated within required timeframes.
- Mean time to remediate.
Additional Policy Details
None
Resources
NA
Definitions
None