Data and System Security Policy

Security and compliance are ongoing, mission-critical business processes of the University and should be viewed as an integral part of the obligations of all members of the University community. The Data Handling and System Security Measures included in this Policy are designed to provide resiliency against the current and rapidly changing threat landscape and include complex and targeted attacks that are often focused on theft of scholarly, research, and administrative data. They are also designed to provide a sound foundation from which to address external compliance regulations, both legal and contractual, the number and complexity of which continue to grow at a rapid pace. The Security Measures have been created with consideration of industry best practices, external compliance requirements, and existing NYU policy. Because no computer system is completely immune from exploitation, applying layered security controls safeguards University systems and NYU’s ever-expanding body of sensitive data/information. The University has implemented this Policy to help you protect and secure the data and system(s) that are in your care whether you are a data or system user or a system administrator.

Within the framework for describing the importance of information technology systems, measures are outlined that represent how severe the impact could be to the University if a given system were compromised or unavailable to perform its function. Systems with a higher classification must meet a stricter system security standard in order to achieve compliance. In order to apply proper security controls, it is the responsibility of all individuals utilizing University computer and data resources to:

1. Know the classification of the system in use: Computer systems are classified into three categories: Low Criticality, Moderate Criticality, and High Criticality, depending upon the criticality of the data stored on it, transmitted by it, or the data to which it provides access. Full instructions on how to classify a system can be found in the Electronic Data and System Risk Classification Policy.
   
2. Know the type of data being handled: Data is classified into one of three categories: Low Risk, Moderate Risk, and High Risk, described in the Electronic Data and System Risk Classification Policy, and based on the risk to the University of its unauthorized release. Additionally, research data may come with special state and federal obligations.
   
3. Follow the appropriate security measures contained in this Data and System Security Policy: These measures outline NYU’s multi-layer security strategy for defense against unauthorized access to University systems and appropriate data handling.
4. Understand the alternate forms of compliance with this Policy: In some cases, a system may be incapable of implementing a control required by this Policy. In such cases, the exception should be documented and approved by the appropriate chain of authority. For High Criticality systems managed by NYU IT, this involves a Security Risk Assessment and approval by the Architecture Review Board (ARB). Information about the Security Risk Assessment is available from the NYU IT Global Office of Information Security (GOIS) (contact security@nyu.edu).

This Policy covers:

• Data Handling Security Measures
  
• System Security Measures

The data and system resources referred to in this Policy must be properly safeguarded regardless of the location of those resources. This Policy applies to anyone who accesses, uses, or controls University computer and data resources, including, but not limited to faculty, administrators, staff, researchers, students, those working on behalf of the University, guests, tenants, contractors, consultants, visitors, and/or individuals authorized by affiliated institutions and organizations. Send questions or comments to: security@nyu.edu.

The measures outlined in this Policy are applicable to a wide range of IT resources which are connected to NYU-NET and/or are used for any NYU business purpose. A system may be any IT resource to which the safeguards outlined in this Policy may be applied. Examples of systems include, but are not limited to:

1. Desktop, laptop, or server computers running general purpose operating systems such as Windows, macOS, Unix/Linux, and mobile applications—whether NYU- or personally-owned—when used for NYU activities.
   
2. Network server applications, such as an SFTP-server application.
   
3. Applications and web applications, such as student information systems, HR systems, learning management systems, websites, CMS, and wikis.
   
4. Databases, data warehouse, APIs, and other data exchange systems.
   
5. Mobile devices, such as tablets, smartphones, and IoT devices where data can be stored.
   
6. Authentication and authorization systems such as SSO, Active Directory, and LDAP.
   

All of the above systems may perform their own authentication and authorization, logging and auditing, and have their own configurations which must be managed, and each of them is considered a compliance object that must be protected.

Refer to the Retention and Destruction of Records Policy and the included retention schedule for additional guidance.

1. Requirements for Handling Low Risk Data (Public Data)
   
2. Requirements for Handling Moderate Risk Data
   
3. Requirements for Handling High Risk Data
   
4. Additional Requirements for Handling Research Data

Description of the Data Handling Security Measures

All access to data is granted to you as part of your role at NYU and that data should be protected appropriately. These Data Handling Security Measures define the minimum security requirements that must be applied to the data types defined in the Electronic Data and System Risk Classification Policy. Understand the different categories of data and what is contained in each. Some data elements, such as credit card numbers and protected health information, are especially sensitive and have additional security requirements defined in external standards. GDPR-related data also requires heightened awareness and oversight. In addition, access and use of University Data is covered by the Administrative Data Management Policy. Please be sure to consult all appropriate documents when determining the appropriate measure to safeguard your data.

The best way to safeguard sensitive data is not to handle it at all, and business processes that can be amended to reduce or eliminate dependence on High Risk data should be implemented. For example, the University ID number often can be substituted for a Social Security number and poses much less risk if accidentally disclosed.

1. Requirements for Handling Low Risk Data (Public Data)

1.1. Access control: Access to data classified as Low Risk is generally available to the public. The use, access, or alteration of public data will not be restricted so long as its release to the public will not have an adverse impact on NYU or an individual community member. The public has implicit permission to use the data that is made publicly available.

1.2. Sharing: Low Risk data may be freely shared and may be released publicly without obtaining permission from a Data Steward.

1.3. Retention: Low Risk data may be stored for as long as is necessary; there are no policies governing the retention of public data.

2. Requirements for Handling Moderate Risk Data

2.1. Access control: Access to Moderate Risk data must be provided on a least-privilege basis. No person or system should be given access to the data unless required by a business process. In such cases where access is required, permission to use the data must be granted by the Data Steward.

2.2. Sharing: Moderate Risk data may be shared among University employees according to a well-defined business process approved by the Data Steward. It may be released publicly only according to well-defined business processes, and with the permission of the Data Steward.

2.3. Retention: Moderate Risk data should only be stored for as long as is necessary to accomplish the documented business process.

2.4. Incident notification: If there is a potential security incident that may place Moderate Risk data at risk of unauthorized access, the NYU IT Global Office of Information Security (GOIS) must be notified.

3. Requirements for Handling High Risk Data

3.1. Collection: High Risk data should be collected only when all of the following conditions are met:

3.1.1. The data is not available from another authoritative source; and

3.1.2. The data is required by a business process; and

3.1.3. You have permission to collect the data from the appropriate Data Steward; or

3.1.4. If the data is requested by the NYU Office of General Counsel in response to litigation.

3.2. Access control: Individuals must be granted access to High Risk data on a least-privilege basis. No person or system may access the data unless required by a documented business process. In such cases where access is required, permission to use the data must be granted by the Data Steward.

3.3. Access auditing: Access auditing for files containing High Risk data should be enabled.

3.4. Labeling: Portable media containing High Risk data should be clearly marked.

3.5. Sharing: Access to High Risk data can be granted only by a Data Steward. No individual may share High Risk data with another individual who has not been granted access by a Data Steward.

3.6. Idle access: Devices which can be used to access High Risk data must automatically lock after some period of inactivity, through the use of screensaver passwords, automatic logout, or similar controls.

3.7. Transit encryption: High Risk data must be encrypted during transmission with a method that meets the following requirements.

3.7.1. Cryptographic algorithm(s) are listed in FIPS 140-2 Annex A, the list of approved security functions.

3.7.2. Cryptographic key lengths meet best-practices for length, given current computer processing capabilities.

3.7.3. Both the source and destination of the transmission must be verified.

3.8. Storage encryption: High Risk data must be encrypted using strong, public cryptographic algorithms and reasonable key lengths given current computer processing capabilities. Keys must be stored securely, and access to them provided on a least-privilege basis (see ISO 11568 for recommendations on securing keys). If one-way hashing is used in lieu of reversible encryption, salted hashes must be used.

3.8.1. Encrypt files containing High Risk data using different keys or passwords than those used for system logon.

3.8.2. Encrypt data stored in databases at the column level.

3.8.3. In addition to file and/or database encryption, implement full-disk encryption on all workstations and/or portable devices that contain High Risk data.

3.9 Retention: High Risk data should only be stored for as long as is necessary to accomplish the documented business process.

3.10. Destruction: When High Risk data is no longer needed, it should be destroyed in accordance with applicable policies, using methods that are resistant to data-recovery attempts such as cryptographic data destruction utilities, on-site physical device destruction, or NAID certified data destruction service.

3.11. Incident Notification: If there is a potential security incident which may place High Risk data at risk of unauthorized access, the NYU IT Global Office of Information Security (GOIS) must be notified. See also: IT Security Information Breach Notification Policy.

4. Requirements for Handling Research Data

For security, privacy, and regulatory reasons, those creating, managing, or storing research data must be especially attuned to its classification and appropriate security measures. Research data that is Moderate Risk or High Risk should be stored on NYU-controlled devices and systems, and not personal devices or personally-acquired services. Data sharing agreements must be vetted by the appropriate University units. Efforts must be made by researchers to ensure that data is secured and available only to those approved for access. Refer to the NYU Policy on Retention of and Access to Research Data.

Especially when working or travelling in the European Union, heightened care must be taken concerning General Data Protection Regulation (GDPR)-impacted data. Special attention should be paid particularly in the context of human subjects research (that is, research concerning identified or identifiable individuals). Anonymization of the data is preferred; pseudonymization presents a greater risk, although it is acceptable. The appropriate NYU Data Steward or the individual Principal Investigator of the research project should advise about sharing the data. In addition, the Advanced System Security Measures and the Data Handling Security Measures for High Risk Data should be followed in all instances. Understanding which NYU systems have greatest access to PII (e.g., SIS, Workday) will help focus on the increased required standard of care. Completion of NYU's GDPR Awareness training (NYU iLearn course COM 006: General Data Protection Regulation) is required. Please review NYU's European Union General Data Protection Regulation research website for further information regarding ensuring that your research will be GDPR-compliant.

1. Basic System Security Measures apply to all systems at NYU, regardless of the criticality level of the system or classification of the data on the system.
   
2. Intermediate System Security Measures define the security measures that must be applied to Moderate Criticality systems.
   
3. Advanced System Security Measures define the security measures that must be applied to High Criticality systems.

Compliance Requirements

When a system falls into more than one criticality category or includes applications or data resources that fall into more than one risk category, the system always should be classified in the highest applicable criticality category. System Criticality Classification and Examples are explained further in the Electronic Data and System Risk Classification Policy.

Low Criticality systems may be deployed by local IT resources and located at their respective units provided they are adequately secured and protected.

Moderate Criticality systems, prior to deployment to production and establishing connectivity to NYU-NET, are required to undergo a Security Consultation conducted by the GOIS. Depending upon the findings of the Security Consultation, the system may require a full Security Risk Assessment in addition to Architecture Review Board (ARB) approval, and may need to be housed in NYU IT-approved data centers or cloud services facilities, or similarly controlled environments. In particular cases, a Moderate Criticality system might need to meet the standards for a High Criticality system.

High Criticality systems, prior to deployment to production and establishing connectivity to NYU-NET, are required to undergo a Security Risk Assessment conducted by the GOIS and receive subsequent ARB approval. The results of the Security Risk Assessment will be reported to the ARB for recommendations. High Criticality systems must be housed in NYU IT-approved data centers or cloud services facilities.

To request a Security Risk Assessment or Security Consultation please refer to the GOIS website.

Increased Responsibilities for System Administrators

System Administrators have increased responsibilities regarding compliance requirements for any system that they manage. They, first, must classify the system and the data it processes according to NYU's policies, particularly the Electronic Data and System Risk Classification Policy; and, then, apply the appropriate system controls, based on that system classification, understanding that the Security Measures are additive. In order to minimize IT security risk, it is recommended that System Administrators integrate compliance auditing into their existing inventory management and auditing framework. Auditing requirements for external standards, such as the Health Insurance Portability and Accountability Act (HIPAA), the Payment Card Industry Data Security Standard (PCI-DSS), and the Gramm-Leach-Bliley Act (GLBA), are not covered by this document.

Please note: Any system causing a disruption to the general availability of NYU-NET may be disconnected, disabled, and/or blocked from accessing NYU-NET by the GOIS. Restoration of network connectivity to NYU-NET shall require GOIS approval.

Description of the Security Measures

The following sections describe the Basic, Intermediate, and Advanced System Security Measures. The measures are cumulative and build for each data and system category. The below security measures apply to any systems used to conduct NYU business, research, or teaching. This includes non-NYU owned equipment, such as personally-owned systems.

1. Basic System Security Measures

The Basic System Security Measures apply to all systems at NYU, regardless of the level of their system or data classification. They constitute a baseline, which all systems must meet. To the extent possible, mobile devices such as phones and tablets should be secured using these Basic System Security Measures. Note that for most individual workstations, these are the only Security Measures that will apply, unless the risk level of the data on the system requires a higher-level Security Measure. The requirements are:

1.1. Password Protection: All accounts and resources must be protected by passwords which meet the following requirements, which must be automatically enforced by the system or application:

1.1.1. Passwords shall be 8 or more characters in length, and consist of all 3 requirements below:

1.1.2. Mixed-case letters (A-Z and a-z)

1.1.3. At least one number (0-9)

1.1.4. At least one special character (!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~)

1.1.5. Additionally, passwords must not be dictionary or slang words in any language, contain repetitive or sequential characters (aaaa, 12345abc, etc.), or be common names, birthdays or readily guessable.

1.1.6. Passwords shall be changed at least once a year for standard accounts, and every 90 days for privileged accounts.

1.2. Software updates: Most systems can and must be configured to receive automatic updates. For those systems, such as production servers, which may require a phased approach to updates, the process and frequency of updating systems must be submitted to the GOIS for review and approval. Systems must be configured to automatically update operating system software, server applications (web server, mail server, database server, etc.), client software (web browsers, mail clients, office suites, etc.), and malware protection software (anti-virus, anti-spyware, etc.).

1.3. Firewall: Systems must be protected by a firewall which allows only those incoming connections necessary to fulfill the business requirements of that system. Client systems which have no business needs to provide network services must deny all incoming connections. Systems that provide network services must limit access to those services to the smallest, reasonably manageable group of hosts that need to reach them.

1.4. Operating System Protection: All systems must be configured with baseline security software requirements, including anti-malware software, installed to detect, prevent and help manage potential threats. Units can supplement these baseline requirements with additional security measures to address specific needs.

2. Intermediate System Security Measures

The Intermediate System Security Measures define the Security Measures that must be applied to Moderate Criticality and High Criticality systems. Note that except under special circumstances, these Measures do not apply to desktop or laptop computers, or to mobile devices. The requirements are:

2.1. Authentication and Authorization

2.1.1. Remove or disable accounts upon loss of eligibility: Accounts which are no longer needed must be disabled in a timely fashion using an automated or documented procedure.

2.1.2. Separate standard user and administrator (privileged) accounts: Administrator (privileged) accounts must not be used for non-administrative purposes. System administrators must be provisioned with non-administrator accounts for end-user activities and a separate administrator (privileged) account that is used only for system administration purposes.

2.1.3. Use unique passwords for privileged accounts: Privileged accounts must use unique passwords that are not shared among multiple systems. Credentials which are managed centrally, such as the NetID/password combination, are considered a single account, regardless of how many systems they provide access to.

2.1.4. Throttle repeated unsuccessful login attempts: A maximum rate for unsuccessful login attempts must be enforced, whenever possible. Account lockout is required after five unsuccessful login attempts. In cases where a vendor cannot provide this, the lockout should be as small as possible.

2.1.5. Enable session timeout: User sessions must be locked or closed after 15 minutes of inactivity. In cases where this is technically unfeasible, the timeout session should be as short as possible.

2.1.6. Enforce least privilege: Non-administrative accounts must be used whenever possible. User accounts and server processes must be granted the least-possible level of privilege that allows them to perform their function.

2.2. Audit and Accountability

2.2.1. Synchronize system clock: The system clock must be synchronized to an authoritative time server run by NYU (currently tick.nyu.edu and tock.nyu.edu) at least once per day.

2.2.2. Enable system logging and auditing: The facilities required to automatically generate, retain, and expire system logs must be enabled.

2.2.3. Follow an appropriate log retention schedule: System logs must be retained for no more than 90 days and then destroyed unless further retention is necessary due to legal, regulatory, or contractual requirements.

2.2.4. Audit successful logins: Generate a log message whenever a user successfully logs on.

2.2.5. Audit failed login attempts: Generate a log message whenever a user attempts to log on without success.

2.2.6. Audit when a system service is started or stopped: Generate a log message when a system service is started or stopped.

2.2.7. Audit serious or unusual errors: Generate a log message when a serious or unusual error occurs, such as crashes.

2.2.8. Audit resource exhaustion errors: Generate a log message when a resource exhaustion error occurs, such as an out-of-memory error or an out-of-disk error.

2.2.9. Audit failed access attempts: Generate a log message when an attempt to access a file or resource is denied due to insufficient privilege.

2.2.10. Audit permissions changes: Generate a log message when the permissions of a user or group are changed.

2.2.11. Include appropriate correlation data in audit events: For each audit event logged, be sure to include sufficient information to investigate the event, including related IP address, timestamp, hostname, username, application name, and/or other details as appropriate.

2.3. Configuration and Maintenance

2.3.1. Security partitioning: Systems may share hardware and resources only with other systems that have similar security requirements, regardless of their criticality classification. Systems which share similar security requirements have user communities of similar size and character, similar firewall profiles, and similar technical requirements. For example:

2.3.1.1. Multiple systems of the same criticality may be aggregated together to share hardware and resources provided they have similar security requirements.

2.3.1.2. Moderate Criticality systems may share hardware and resources with Low Criticality systems provided that all systems meet the Intermediate Systems Security Measures and share similar security requirements.

2.3.2. Follow vendor hardening guidelines: This document cannot be comprehensive for all systems available. Follow basic vendor recommendations to harden and secure systems.

2.3.3. Disable vendor default accounts and passwords: Many systems come with default accounts which are publicly known. These accounts should be disabled.

2.3.4. Disable all unnecessary network services: Processes and services which are not necessary to complete the function of a system must be disabled.

2.4. Additional Requirements

2.4.1. Report potential security incidents: Potential security incidents must be reported to the GOIS at security@nyu.edu.

2.4.2. Security Risk Consultation or Assessment: Before system deployment, a Security Risk Consultation must be done by the GOIS, and, if needed, a Security Risk Assessment must be done as well

2.4.3. Vulnerability assessment: Before system deployment, a vulnerability assessment must be requested from the GOIS This vulnerability assessment may entail a Nexpose, Acunetix, and/or NMAP scan of the system.

2.4.4. Physical access: The system must reside in a secure, managed data center, cloud service, or locked facility to which only authorized personnel have access.

2.4.5. Documentation: Create and maintain documentation summarizing the business process, major system components, and network communications associated with a system.

3. Advanced System Security Measures

The Advanced System Security Measures define the Security Measures that must be applied to High Criticality systems in addition to the Intermediate System Security Measures. The additional requirements are:

3.1. Audit and Accountability

3.1.1. Enable process auditing or accounting: Enable process auditing or accounting, which generates logs information about the creation of new processes and their system activity.

3.1.2. Audit privilege escalation or change in privilege: Generate a log message whenever a user changes their level of privilege.

3.1.3. Audit firewall denial: Generate a log message when the host-based firewall denies a network connection.

3.1.4. Audit all significant application events: Log all significant application events.

3.1.5. Write audit events to a separate system: System logs must be written to a remote system in such a way that they cannot be altered by any user on the system being logged.

3.2. Configuration and Maintenance

3.2.1. Follow advanced vendor security recommendations: This document cannot be comprehensive for all systems and applications available. Conform to best practices and recommendations outlined in vendor security whitepapers and documentation.

3.2.2. Host-based and network-based firewalls: Systems must be protected by both a host-based and network-based firewall that allows only those incoming connections necessary to fulfill the business needs of that system.

3.2.3. Configuration management process: Configuration changes must be regulated by a documented configuration and change management process.

3.2.4. Security partitioning: Systems may share hardware and resources only with other systems that have similar security requirements, regardless of their criticality classification. Systems which share similar security requirements have user communities of similar size and character, similar firewall profiles, and similar technical requirements. For example:

3.2.4.1. Multiple systems of the same criticality may be aggregated together to share hardware and resources provided they have similar security requirements.

3.2.4.2. High Criticality systems may share hardware and resources with Medium and Low Criticality systems provided that all systems meet the Advanced Systems Security Measures, and share similar security requirements.

3.3. Additional Requirements

3.3.1. Physical access: The system must reside in a secure, managed data center or cloud service to which only authorized personnel will have access.

Send questions or comments to: security@nyu.edu.