Vulnerability Management Standard for Information Technology

Title

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

Introduction

Purpose

Vulnerability management means finding, preventing, fixing, and controlling security vulnerabilities:  

1. through routine patching of system parts;
2. patching or fixing vulnerabilities found by network, systems, and application scanning; and
3. addressing vendor-identified or other known vulnerabilities through extra or different controls or other ways.

Managing system vulnerabilities quickly is key to the protection and security of University of North Carolina at Chapel Hill ("University" or "UNC-Chapel Hill") data and other resources. This keeps those resources available for people to use.

Scope of Applicability

IT service components where we see vulnerabilities include: 

• on-premise (on campus) or cloud (vendor) hosted servers,
• middleware and other behind-the-scenes applications, and
• client-facing application systems.

For “Cloud” systems, consult the contract terms to find out who is responsible for Vulnerability management. The usual arrangements are: 

• Hosted “Software as a Service” (SaaS) applications will have most Vulnerability management activities provided by the vendor unless the University’s contract with the vendor says otherwise. (Configuration and access management, encryption, and other applicable responsibilities you may have still apply.)
• “Platform as a Service” (PaaS) and “Infrastructure as a Service” (IaaS) are likely your responsibility under this Standard unless Vulnerability management in the University’s contract with the vendor says otherwise. Any questions on how the responsibility is assigned can be settled by an Information Security Risk Assessment.

Every system that could be used with Tier 2 or Tier 3 data and systems considered "Mission Critical" is in scope.

Infrastructure that supports Mission Critical applications and services and covered by business continuity requirements must have one or more identified responsible parties able to ensure compliance with this Standard. Those responsibilities might include patching or other fixing of vulnerabilities. This Standard applies to all responsible parties and to people in a role likely to make them a responsible party.

Responsible parties are usually:

•  a "system administrator" for servers,
• an application administrator for a web application,
• a database administrator for a database,
• a service owner or business/functional person for other types of IT services, but may be
• non-traditional roles if the service is a third-party system managed by non-IT staff.

Standard

The Chief Information Security Officer (CISO) can make sure that systems do not pose a threat to University information by:

1. communicating with system owners ahead of time, and
2. taking steps to fix problems directly when needed.

Blocking systems from the campus data network should only happen if it's approved by both the CISO and Chief Information Officer (CIO). (People they assign may act if the CISO and CIO are unavailable.) 

Responsible parties patch systems on a workable schedule. Create a schedule based on:

• the risk profile of the assets,
• regulatory requirements, and
• availability of scanning resources.

Systems covered include the following:

• University network infrastructure;
• Servers;
• operating systems on virtual machines;
• cloud-hosted virtual machines, images, or containers;
• database servers, databases, applications; and
• comparable services and systems.

Correct discovered vulnerabilities. See below for more detail. 

Cloud Systems

Platform as a Service and Infrastructure as a Service

The customer (in this case the University) is usually responsible for Infrastructure as a Service (IaaS) Vulnerability management.

The University and the provider may share responsibilities for Platform as a Service (PaaS) Vulnerability management.

Units need to register these contracted services in the System Administration Initiative (SAI) if the services are for:

• Tier 2 or Tier 3 data, or
• Mission Critical systems.

Check to see if an exception applies.

Software as a Service

The vendor is usually responsible for the Vulnerability management of SaaS systems. If this isn't the case, the contracting UNC-Chapel Hill unit must make an ongoing plan to find and manage vulnerabilities.

Base the plan on the specific environment and service context. You may need specific tools in the environment to support your plan. Identify those tools and costs early in the project.

Consider access control and other security controls requirements and constraints for configuration management. The operational plan should also include a schedule for optional SaaS upgrades.

Consider each unique project's risk and need for Vulnerability management. Plan for the project costs and implementation that fits the risk. This is true whether the Vulnerability management is done by the provider or a University responsible individual, or some combination of both.

Third-party Applications

Follow all applicable University procurement requirements when you buy software for use by or for the University. Manage vendor requirements fitting the risk of the environment and use. Note that scheduled Vulnerability scanning occurs for systems that are managed in the SAI program.  That means the applications in that system are also scanned.

Scanning and Correction

Scan on a workable schedule. Find and fix vulnerabilities as soon as possible based on:

• “level” of the Vulnerability,
• availability of patches,
• specific data types involved, and
• risk-based prioritization.

You must make sure that applications with Tier 3 data are scanned and vulnerabilities fixed quickly if a purpose-built Vulnerability scanning tool is available, unless an exception is allowed. Law or policy may require more assessment and testing (such as penetration testing for specific data types, or by the ISO (Information Security Office) to achieve an approved Tier 3 Security Risk Assessment.)

Scan applications using Tier 2 data. Correct vulnerabilities based on priority. Consider risks and specific use of the application into consideration. Scanning may be required by the ISO to achieve an approved Tier 2 Security Risk Assessment.

It is also a good idea to scan applications with Tier 0 or Tier 1 data. It is needed if the system is Mission Critical or if there are data integrity concerns. Configuration management should be a priority. Do Vulnerability management planning before implementing a new system.

Patching

Software in use at the University must be supported, or at least have security patches available. Routine patching must occur on a planned basis fitting the risk. Ask for an ISO exception if routine patching (in environments where the University controls the patch or upgrade process) will occur less than quarterly.

In-House “Homegrown” Applications

Vulnerability management for homegrown applications is difficult. Tools are available to help. Those include repositories that check for known vulnerabilities in code libraries. GitLab, Azure, GitHub, and Google all have services available. Scan Development and Test systems with server scanning tools. Server scanning tools can find some application vulnerabilities. Outdated or vulnerable libraries may be caught that way. Some tools are available for use through SAI. Secure application development practices can prevent many Vulnerabilities from occurring at all. You can use third-party assessment and penetration testing for Mission Critical or Tier 3 systems.

Applications developed in-house must have Vulnerability management plans. This includes library management plans. Document your plan and processes for applications affecting Tier 2 or 3 data. Unit ISLs (Information Security Liaison) should work with the ISO to understand what tools and resources may be available. Units developing in-house should consider security costs. Plan for Vulnerability management to be a recurring operational expense.

System Administration Initiative

The SAI is a required monitoring program for UNC-Chapel Hill systems that host sensitive information and/or are Mission Critical.  

"Systems" include: 

• servers,
• appliances,
• network devices, and
• Cloud Platforms and infrastructure.

People who handle campus resources within the scope of SAI must register for and receive training. This includes individuals who: 

• have responsibilities as part of their job description or performance plan,
• "inherit" responsibilities, or
• who have "informal" responsibilities that are not part of their job description or performance plan.

If there is no applicable exception, register systems covered by this Standard. Registered systems are enrolled for scanning if it can be done by SAI.

Training

Register with SAI and complete the applicable training if any of the following job duties are within your scope of responsibility, or if these descriptions apply to you.

• You are a systems administrator with direct responsibility for installing, configuring, or patching Operating Systems on servers. This includes on-prem, PaaS, or IaaS servers, or network devices such as routers, switches, security appliances, storage servers/appliances, or similar systemss.
• You are the only application administrator or the designated Responsible Individual for a multi-user application system. Where multiple Application Administrators exist for a single system, each is responsible for ensuring that one is named as the SAI Responsible Individual. Application Administrators for SaaS applications for which vendors are wholly responsible for scanning and patching are excepted.
• You coordinate or are a liaison for an external contractor or OEM that supports on-prem applications.
• You are a Database Administrator or similar infrastructure/middleware manager with direct responsibility for installing, configuring, or patching platform applications.

Registration

You must register systems designated as requiring SAI participation by the Information Security Controls Standard. The most proper individual for a given server must register the device and ensure compliance. This may be a systems administrator or someone in a similar role. Responsibility for driving this compliance stems from the top executive of any unit.

Engagement

Systems enrolled in SAI must be available for authenticated or agent scans unless an exception is granted See SAI program documentation for the process to apply for exceptions.

Timelines for scanning and for remediation of found vulnerabilities are set up by the SAI Program based on severity levels, availability of patches, and risk.

Patching vulnerabilities within the SAI timelines is needed unless the responsible individual applies for and is given an exception.

Grace periods are meant to help with wide differences in system context that affect ability to patch. Grace periods don’t extend the actual deadlines.

Systems that routinely cannot be patched on the SAI timeline should be put in for a blanket exception.

Patching of higher-severity vulnerabilities must be a priority for units, while patching of lower-severity vulnerabilities may happen on the longer timelines SAI provides.

The CISO or ISO staff may address repeated delays in patching the same systems with unit management. This can often shed light on resource constraints or make sure unit management understands the importance of handling Vulnerabilities. In some cases, Responsible Individuals may be assigned added training. In the case of serious lapse(s), the unit might need to take disciplinary action.

In cases where persistently unpatched systems present a threat to the University, the CISO and CIO may decide that the system must be managed by someone else (a commercial contract, ITS, another campus unit, or another responsible individual within the original unit). The original unit will pay the cost of that support arrangement. The CISO and/or CIO may decide that a system must be taken offline until Vulnerabilities are addressed and a plan is started for ongoing maintenance.

Exceptions

• Systems that cannot reach other campus devices and cannot reach the Internet do not have to follow these requirements.
• Individual systems or groups of systems using documented ISO-approved alternate or added (compensating) controls may be excepted from some parts or all of the Standard.

The SAI "VPR" group handles routine exceptions to scanning or fixing vulnerabilities. The process includes ISO staff and peer systems administrators from campus units. They review requests and decide what the exceptions cover.

The ISO may make exceptions to frequency of patching, scanning, or how much time is allowed to fix a Vulnerability. The ISO considers the following criteria:

• alternate or extra controls,
• what the system is in context 
  • patch windows,
  • frequency of vendor patch releases,
  • potential impact of a breach, and
• availability of technical resources.

The CISO and their designated staff member(s) may make exceptions in writing to any part of this Standard.

Internal University committees and the CISO may work together to make specific guidelines about alternative or extra (compensating) controls. Those guidelines may allow for exceptions to the requirements in this Standard. These exceptions will balance the requirements in this Standard with risk to the University’s mission.

Definitions

Software as a Service (SaaS): Allowing the consumer (UNC-Chapel Hill) to use the provider’s cloud-based applications. The applications are accessible from various client devices through either a thin client interface such as a web browser, like web-based email, or through a program interface. The consumer does not manage or control the underlying cloud infrastructure. These include:  

• network, servers,
• operating systems,
• storage, or even
• individual application capabilities, except for limited user-specific application configuration settings.

Platform as a Service (PaaS): The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.

Infrastructure as a Service (IaaS): The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer can deploy and run Arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls).

Mission Critical: A system so critical to the mission of the University business unit that any incident requires immediate response. If a system is considered mission critical by the department, then contact and escalation information has been supplied for the system in advance of any incident or outage. The owning business unit decides whether a resource is Mission Critical. If a system is named as Mission Critical, heightened information security policies and standards apply. That way, the resource stays available. If a business unit does not name a resource as Mission Critical, that resource may not be a priority for restoration of services in an incident or outage.

Responsible Individual: Individual with a role in Vulnerability management for a specific system. If a system is in scope and no Responsible Individual is named, it is assumed to be any system or application administrator.

Sensitive Information: Information classified as Tier 2 or Tier 3 in the UNC-Chapel Hill Information Classification Standard.

System Administration Initiative (SAI): Program through the Information Security Office to supply training to administrators and to manage Vulnerability scanning for covered systems.

Vulnerability: Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source.

Related Requirements

External Regulations and Consequences

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

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

University Policies, Standards, and Procedures

• University of North Carolina at Chapel Hill Information Security Policy
• University of North Carolina at Chapel Hill Information Security Controls Standard

Informational Resources

• The University “System Administration Initiative” (SAI) is a program that trains “Responsible Individual” 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 Information Security Liaison, or the Information Security Office. One source for good background is owasp.org, A good starting place is their 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 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