Policy Purpose

The purpose of this policy is to address how New York Tech assesses and manages technical vulnerabilities to university-owned or managed IT Resources.

Policy Scope

This policy shall apply to all members of the New York Tech community including faculty, students, administrative officials, staff, alumni, and affiliates who use, access, or otherwise employ, locally or remotely, New York Tech's IT Resources, whether individually controlled, shared, stand-alone, or networked.

Definitions

Common Vulnerability Scoring System (CVSS)

An open industry standard for assessing the severity of computer system security vulnerabilities.

Compensating Control

A data security measure designed to satisfy the requirement or other security measures deemed too difficult or impractical to implement.

Endpoint

Any system or device that stores, processes, or transmits university data.

IT Resources

New York Tech 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.

Patch

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:

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

Vulnerability

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

Policy Statement

All New York Tech IT Resources are covered by this policy. Application owners and system managers are jointly responsible for the continual assessment of IT Resources under their management or supervision. All patches and configuration changes must be deployed to University-owned or managed IT Resources according to the requirements outlined below.

Requirements for Security-Related Patches

The application of security-related patches will be prioritized based on the severity of the vulnerabilities that the patch addresses. ITS shall use the Common Vulnerability Scoring System (CVSS) or a directly compatible alternative to assist with prioritization. Severity scores are categorized, as follows.

ITS will assign patches a priority level that takes into consideration the risk classification of each asset and the severity score. To the extent possible, the patching process will follow the general timeline in the table below unless a more specific patching procedure for a particular system is approved by the VP for IT/CIO or delegated authority.

Timeliness of patch management prioritization may be impacted by several factors, including but not limited to:

• Consideration of asset classification and data affected by the vulnerability
• Stricter requirements set by regulatory standards (such as HIPAA and PCI DSS)
• Discretion of VP for IT/CIO or delegated authority regarding the potential risk to the environment
• Lack of connectivity to the device preventing the ability to perform patching
• Availability of a sufficient workaround that mitigates the risk presented by the patch
• Level of testing required to ensure patches do not introduce interoperability issues

If a solution or remediation is not available to address a vulnerability, the VP for IT/CIO or delegated authority must approve any compensating or other mitigating controls.

Requirements for Non-Security Patches

The timely implementation of non-security related patches should be conducted to mitigate against degradation of functionality and/or interoperability. Examples of non-security patches include software updates to increase functionality. The applicable application and system owners will utilize the ITS processes and standards outlined in the ITS Change Management Policy to address the testing, deployment, and documentation of non-security patches. When feasible, non-security patches will be scheduled and applied during the weekly maintenance window (Wednesdays, between 4 – 7 a.m.).

Related Internal Policies

• Change Management Policy
• Data Security and Access Management Policy

Regulatory References

• Payment Card Industry Data Security Standard (PCI DSS)
• Gramm-Leach-Bliley Act (GLBA)
• Health Insurance Portability and Accountability Act (HIPAA)

Exceptions

Deviations from these policies, procedures, or guidelines may only be done cooperatively between ITS and the requesting entity with sufficient time to allow for appropriate risk analysis, documentation, and possible presentation to authorized university representatives. Failure to adhere to ITS written policies may be met with university sanctions.

Vulnerability Remediation Targets

The application of patches will be prioritized based on the severity of the vulnerabilities that the patch addresses. The following table defines how vulnerabilities will be ranked, prioritized, and remediated.

It may be necessary to further prioritize hosts within the priority rankings above by system/data classification, compliance requirements, and pre-existing risk conditions.