Effective Date | October 1, 2022 | Policy Owner | Information Technology Services (ITS) |
---|---|---|---|
Last Reviewed Date | July 1, 2024 | Approved By | Vice President for Information Technology and CIO |
Review Cycle | Annual | Policy Contact | Information Security & Compliance Analyst |
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.
Vulnerability Severity | CVSS Ranking |
---|---|
Critical | 9.0 – 10.0 |
High | 7.0 – 8.9 |
Medium | 4.0 – 6.9 |
Low | 0.1 – 3.9 |
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.
Priority Level | Patch Review Initiated | Patch Completed |
---|---|---|
1 – Critical | Within two days of patch release | Within one week of patch release |
2 – High | Within one week of patch release | Within two week of patch release |
3 – Medium | Within two weeks of patch release | Within one month of patch release |
4 – Low | Within one month of patch release | Within three months of patch release |
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.
Priority | Definition | Initial Assessment | Target Resolution |
---|---|---|---|
Critical | Vulnerability that is remotely exploitable with no compensating control. | Within 48 hours | 72 hours |
High | Vulnerability that is remotely exploitable with compensating controls. | Within 72 hours | One week |
Medium | Vulnerability that is not remotely exploitable. | One week | 30 days |
Low | Vulnerability that cannot be immediately exploited. | 30 days | 90 days |
It may be necessary to further prioritize hosts within the priority rankings above by system/data classification, compliance requirements, and pre-existing risk conditions.