Vulnerability Management Standard for Information Technology

Title

University of North Carolina at Chapel Hill Standard on Information Technology Vulnerability Management

Introduction

Purpose

Vulnerability management means finding, preventing, and fixing security problems in IT systems. Protecting University of North Carolina at Chapel Hill ("University" or "UNC-Chapel Hill") data and technology requires quickly managing security vulnerabilities. This Standard gives requirements for that management, which includes:

• Routine patching of system parts when patches become available;
• Patching or fixing vulnerabilities found by network, systems, and application scanning; and
• Using methods other than patching (“alternative controls”).

Scope

This standard applies to all technology, all University IT systems covered by the Information Security Controls standard (also known as the “Minimum Security Standard” or “MSS”). Every person responsible for those systems under the MSS must follow this Vulnerability Management Standard for those systems. This includes personal devices used for University purposes. Check the MSS for what is required of personal devices.

The types of technology covered are more than just laptops and computer servers. Examples include:  

• Network devices (e.g., switches, routers, wireless access points, Virtual Private Network (VPN) systems); 
• Servers (e.g., hosting web servers, database servers, statistical processing engines, and much more); 
• Virtual machines; 
• Containers (cloud-hosted or on-premises) 
• Software installed on computers (e.g., databases, web browsers, applications); 
• Web applications 
• In-house or "homegrown” applications and application code (including those developed by a third party);  
• Internet of Things (e.g., printers, lightbulbs, microwaves, and other electronic devices attached to computer networks running computer code);  
• Many types of medical and research devices that store electronic data or attach to computer networks; 
• Embedded systems 

This Standard does not require patching or upgrading software features or bugs (functional patching) unless they affect the security of the system.

Standard

Overview

This Standard describes what is required to manage security vulnerabilities. Security patching timelines are tiered by risk. Patching timelines are driven by:

• Impact on the University if a security incident happens on the system. “Low” protection systems have a lower impact on University operations than higher levels. Lower level systems have longer patching times.
• Internet accessibility of the system. Boundary protections like network firewalls, Intrusion Detection Systems (IDS), Intrusion Prevention Systems (IPS) are not perfect. However, these systems do allow for longer timelines for patching, because boundary protections make it more difficult for bad actors to discover and exploit problems. Border or boundary protections do not eliminate the requirement to patch. Boundary protections only allow a longer time to get it done.
  • NOTE: Internet accessibility is about specific parts of a system.  If one part of a system can be accessed through the Internet, that does not mean that other parts of the system that are not accessible from the Internet need to be updated or fixed more quickly. For example, an Internet-facing Web server may communicate to a database server only the Web server can access. The Web part of the Web server is “Internet accessible,” but the database server is not.
• Severity: Not all vulnerabilities are the same. Classification schemes analyze and score vulnerabilities based on how easy they are to exploit and whether they allow access to data. By any measure, critical vulnerabilities:
  • Can be exploited across a network,
  • Do not need authentication, and
  • Allow information disclosure
• Active exploitation. When a Vulnerability goes from a possibility to reports of use in the real world, the patching times shrink. The University’s Information Security Office (ISO) will act to reduce harm from critical vulnerabilities if they are actively being exploited. ISO monitors national and international threat intelligence services for that information.

You must keep an operational ability to apply security patches promptly. That means:

• Named people actively receive vulnerability and patch announcements for all software and devices as part of their assigned responsibilities; and
• They must have a working process to deploy security patches for all components of the system; and
• They must have a plan in place in case emergency patching is needed.
• The technology must be supported, meaning the supplier provides prompt security patches.

A working process covers system testing, maintenance windows, contingency planning, communications plans, backout plans, and coordination of people needed to do the work.

Responsible Persons must be aware of their systems and threats against them in order to manage vulnerabilities. Vulnerability scanning alone is not an acceptable first line method to become aware of vulnerabilities or patches. Scanning is a safety net or check to catch when you accidentally miss a vulnerability or patch announcement. Suppliers often tell you what scanning cannot.

Response Timelines

Responsible Persons must make sure that vulnerabilities for each part of the system they are responsible for are handled within the specific emergency and standard timelines described below unless an approved Exception exists.

Emergency Patching

Critical security vulnerabilities must be addressed using an emergency security patch process. Patch within 48 hours (two days) of release of the patch from the provider of security patches.

Critical Security Vulnerability Criteria

A critical security vulnerability exists when all the following are true:

1. Security Baseline Protection Level High (See MSS): The system protects or would likely impact data considered “need-to-know" or it is considered mission critical.
2. Vulnerability Severity: Severe vulnerabilities are those that can be exploited across a network, without authentication, and may allow access to data. No single vulnerability severity scoring system covers all vulnerabilities. Vulnerabilities with a CVSS score of 7 or greater (or Qualys score of 5 or comparable ISO-approved framework) are severe if an exploit of that Vulnerability would expose data or disable the system. If you have questions, please ask the University’s Information Security Office. Remember that any software is in scope: operating systems, libraries, packages, applications, databases, containers, lambda code, etc.
3. Network scope of system: The system part is Internet accessible. The vulnerability could be exploited from the Internet without credentials on the system.
4. Active exploits: The global cybersecurity industry is aware of an active proof-of-concept or practical exploit of the vulnerability.

If you are reading any of the above carefully to second guess whether they apply, invoke the emergency security patch process for your system or service.

Managing Critical Vulnerability Risk

Critical vulnerabilities create a situation where the University does not have much time to patch before a bad actor can be expected to exploit the weakness. Responsible Persons must immediately take actions needed to protect the University and the University’s IT systems.

The University’s Information Security Office may remove a Unit’s IT system or service from the University’s network or take other steps if the IT system or service cannot be patched within 48 hours (two days) of patch release. If all four Critical Security Vulnerability criteria are true and the system cannot be patched, it is likely the Information Security Office will have no choice but to take drastic action.

Standard Patching

For all other security vulnerabilities that do not meet the emergency security patching criteria, the following times are required: 

Roles and Responsibilities

Accountable Person: A unit head at a Vice Chancellor/Provost or Dean level unless otherwise arranged through the Information Security Office. This person must make sure their organization is handling security vulnerabilities properly.

Responsible Person: Ensure that regular patching, configuration, and related vulnerability management activities are happening. The individual acting as a “service owner” for the application or IT system is the primary “Responsible Person.” Staff may share responsibility under this Standard. For smaller IT devices, applications, or systems that do not require a Service Owner, the responsible person may be, for example:

• An application administrator for a web application,
• A database administrator for a database,
• Non-IT staff or faculty for small applications, or for third-party systems

Chief Information Security Officer (CISO): Supporting compliance with this Standard. Determine exceptions. The Chief Information Security Officer (CISO) has the responsibility to act. This means communicating with responsible people to make sure that vulnerable systems are not a threat to the University and directing actions to address systems that are not in compliance and pose a threat to the University.

Administrators/IT Managers/Information Security Liaisons (ISL): Ensure Responsible Persons follow this Standard or escalate to University management.

Other members of the University community: Cooperate in scheduling IT system downtime and service outage windows. Provide access to IT systems to allow patching, Be aware of vulnerability status of IT systems you use.

Exceptions

Difficult to Patch Systems 

On occasion, a Responsible Person may become aware of a vulnerability that has exceeded the timelines in this Standard by a large margin. The best choice to address an identified vulnerability is to immediately plan for and apply the appropriate security patch from the software supplier or make the configuration change as the supplier directs.

Regardless of plans established to address vulnerabilities, the Responsible Person must file an exception if the system is not expected to be addressed within:

• 90 days for high protection obligation systems or systems with external obligations at the high level if the system is not Internet-accessible or
• 30 days for Internet-accessible high protection level/external obligation systems

This Exception must be:

• Written;
• Approved by the unit through a process the unit considers appropriate, and
• Sent to the University’s Information Security Office ISO for final review and approval following instructions provided through the System Administration Initiative (“SAI”) program.

The Exception review is intended to:

• Consider and document whether all reasonable options have been weighed for applying available security patches;
• Identify and apply effective Alternative Controls; and
• Set a timeline to permanently address the vulnerability. 

Web Application Firewall (WAF)

A Web Application Firewall that has been determined to protect against a specific Vulnerability allows a system to be classified as “not Internet Accessible” for the purposes of patching time requirements and for that specific Vulnerability.

Other Rare Exceptions 

There are specific cases where patching of the IT system will not be possible or other exceptions are needed. In those cases, the Responsible Person must arrange to apply alternative controls to mitigate the Vulnerability risk. The unit and the University’s Information Security Office must approve proposed alternative controls for Moderate or High protection obligation systems, and for all systems under MSS Overlays due to external obligations.

Implementation Timeline

Transition to the new security model represented by this Standard may require planning and time. A “hardship” exception allows for phased implementation.  

• Until January 1, 2026 Units and Responsible Persons may opt to use either the previous Vulnerability Management Standard (version effective 12/15/2020 and attached for reference) or this current Standard. 
• Beginning January 1, 2026 all technology is governed by this version (unless revised in that time).  

Definitions

• Accountable Person: Unit heads of each unit within the university are accountable for meeting the requirements in this Standard for all University IT systems used by the unit.
• Internet Accessible: Systems not protected by border firewalls, or by Intrusion Protection and Intrusion Detection Systems that are configured in a way that will prevent exploitation of a specific Vulnerability are considered “Internet Accessible.” If an uncredentialed person can reach the service in a way that they could exploit a Vulnerability from non-University address space, it is “Internet Accessible.”
• Intrusion Detection System (IDS): A security service that monitors and analyzes network or system events for the purpose of finding, and providing real-time or near real-time warning of, tries to access system resources in an unauthorized manner.
• Intrusion Prevention System (IPS): Software that has all the capabilities of an intrusion detection system and can also try to stop possible incidents.
• Overlays: See MSS
• Responsible Person: Also known as a “service owner,” the person responsible for the overall service throughout its lifecycle. The service owner handles the service within the University regardless of where the technology components or professional capabilities live. Service owners ensure that their application/system/service is available for use meeting documented service levels (service level agreements or SLAs). Service Owners are accountable to the University and to the people using the service.
• Security-relevant patches: Patches addressing identified security vulnerabilities (rather than functional issues.)
• Web Application Firewall (WAF): an application firewall for HTTP applications. A WAF applies a set of rules to an HTTP conversation. Generally, these rules cover common attacks such as Cross-site Scripting (XSS) and SQL Injection. A WAF, to be effective, must be customized to protect its specific application.

Related Requirements

External Regulations and Consequences

Failure to follow this Standard may put University information assets at risk and may have disciplinary consequences for employees, up to and including termination of employment. Students who do not adhere to this policy may be referred to the UNC- Chapel Hill Office of Student Conduct. Contractors, vendors, and others who do not adhere to this policy may face termination of their business relationships with UNC-Chapel Hill.

Violation of this policy may also carry the risk of civil or criminal penalties.

At the direction of the Chief Information Security Officer or Chief Information Officer (or their delegates if they are unavailable) drastic actions such as blocking noncompliant systems from the campus network may be taken in order to protect the University.

University Policies, Standards, and Procedures

• UNC-Chapel Hill Standard on Information Security Controls
• Information Classification Standard

Informational Resources

• System Administration Initiative 
• Common Vulnerability Scoring System 
• The University “System Administration Initiative” (SAI) is a program that trains “Responsible Person” University staff, who have IT security responsibilities for particular systems, and registers certain kinds of systems for scanning/monitoring/tracking purposes.
• Many of the topics in this Standard are covered on safecomputing.unc.edu. Training and resources are available to individuals and campus units to support the work of Vulnerability management.
• Questions about secure application development and checking of homegrown applications and code can be directed to your unit’s Information Security Liaison, or the University’s Information Security Office. One source for good background is the Open Worldwide Application Security Project (OWASP), A good starting place is OWASP’s document on using components with known vulnerabilities.
• For more background on Sensitive Information please go to help.unc.edu and search for "Sensitive Information." You can also visit safecomputing.unc.edu, datagov.unc.edu, or consult the University’s Information Classification Standard.
• University Procurement Services can help with vendor requirements and management.

Contact Information

Document History

Effective Date: Previous Standards were incorporated in Vulnerability Management Policy dated 30 June 2010. Standalone Standard effective 2/18/2016, signed by the Chief Information Security Officer