Union IT Policies
General
Data Classification Guidelines
Purpose
The purpose of this Guideline is to establish a framework for classifying institutional data based on its level of sensitivity, value and criticality to the University as required by the University’s Information Security Policy. Classification of data will aid in determining baseline security controls for the protection of data.
Applies To
This Policy applies to all faculty, staff and third-party Agents of the University as well as any other University affiliate who is authorized to access Institutional Data. In particular, this Guideline applies to those who are responsible for classifying and protecting Institutional Data.
Definitions
Confidential Data is a generalized term that typically represents data classified as Restricted, according to the data classification scheme defined in this Guideline. This term is often used interchangeably with sensitive data.
A Data Steward is a senior-level employee of the Seminary who oversees the lifecycle of one or more sets of Institutional Data.
Institutional Data is defined as all data owned or licensed by the University.
Non-public Information is defined as any information that is classified as Private or Restricted Information according to the data classification scheme defined in this Guideline.
Sensitive Data is a generalized term that typically represents data classified as Restricted, according to the data classification scheme defined in this Guideline. This term is often used interchangeably with confidential data.
Data Classification
Data classification, in the context of information security, is the classification of data based on its level of sensitivity and the impact to the Seminary should that data be disclosed, altered or destroyed without authorization. The classification of data helps determine what baseline security controls are appropriate for safeguarding that data. All institutional data should be classified into one of three sensitivity levels, or classifications:
A. | Restricted Data |
Data should be classified as Restricted when the unauthorized disclosure, alteration or destruction of that data could cause a significant level of risk to the University or its affiliates. Examples of Restricted data include data protected by state or federal privacy regulations and data protected by confidentiality agreements. The highest level of security controls should be applied to Restricted data. | |
B. | Private Data |
Data should be classified as Private when the unauthorized disclosure, alteration or destruction of that data could result in a moderate level of risk to the University or its affiliates. By default, all Institutional Data that is not explicitly classified as Restricted or Public data should be treated as Private data. A reasonable level of security controls should be applied to Private data. | |
C. | Public Data |
Data should be classified as Public when the unauthorized disclosure, alteration or destruction of that data would result in little or no risk to the University and its affiliates. Examples of Public data include press releases, course information and research publications. While little or no controls are required to protect the confidentiality of Public data, some level of control is required to prevent unauthorized modification or destruction of Public data. |
Classification of data should be performed by an appropriate Data Steward. Data Stewards are senior-level employees of the Seminary who oversee the lifecycle of one or more sets of Institutional Data. See Information Security Roles and Responsibilities for more information on the Data Steward role and associated responsibilities.
Data Collections
Data Stewards may wish to assign a single classification to a collection of data that is common in purpose or function. When classifying a collection of data, the most restrictive classification of any of the individual data elements should be used. For example, if a data collection consists of a student’s name, address and social security number, the data collection should be classified as Restricted even though the student’s name and address may be considered Public information.
Reclassification
On a periodic basis, it is important to reevaluate the classification of Institutional Data to ensure the assigned classification is still appropriate based on changes to legal and contractual obligations as well as changes in the use of the data or its value to the University. This evaluation should be conducted by the appropriate Data Steward. Conducting an evaluation on an annual basis is encouraged; however, the Data Steward should determine what frequency is most appropriate based on available resources. If a Data Steward determines that the classification of a certain data set has changed, an analysis of security controls should be performed to determine whether existing controls are consistent with the new classification. If gaps are found in existing security controls, they should be corrected in a timely manner, commensurate with the level of risk presented by the gaps.
Calculating Classification
The goal of information security is to protect the confidentiality, integrity and availability of Institutional Data. Data classification reflects the level of impact to the University if confidentiality, integrity or availability is compromised.
There is no perfect quantitative system for calculating the classification of a particular data element. In some situations, the appropriate classification may be more obvious, such as when federal laws require the University to protect certain types of data (e.g. personally identifiable information). If the appropriate classification is not inherently obvious, consider the security objective as it pertains to each data set.
Data Security Rider
Last updated: January 2025
Background
This contract rider must be added to all contracts with any service provider (also known as “vendor” and “data processor”), if the service provider, in connection with its services creates, obtains, accesses (via records, systems, or otherwise), receives
from or on behalf of Union Theological Seminary or uses in the course of its performance of the contract UTS restricted data which includes, but is not be limited to:
- Social Security numbers,
- Credit card numbers, data protected by the Payment Card Industry Data
Security Standard (PCI DSS), or other financial account information, - Data protected by the Family Educational Rights and Privacy Act, as set
forth in 20 U.S.C. §1232g (“FERPA”), - Data protected by the Gramm-Leach-Bliley Act (GLBA), Public Law No:
106-102, or data protected by any other applicable federal or state
law or regulation. - If Protected Health Information (PHI) as defined by HIPAA is being accessed,
a Business Associate Agreement is required. Contact the university
Director of Privacy for assistance.
UTS represents that it has necessary rights to provide the Covered Data and Information (CDI) to the vendor for the processing to be performed in relation to the services. The service provider agrees to the terms of this contract rider.
Data Definition: Covered data and information (CDI) includes paper and electronic data classified as “Restricted”, or otherwise sensitive data as defined by the Data Security Rider. This includes information supplied by the university or any individuals to the service provider.
Security Standards: UTS will determine the scope, purposes, and manner by which the CDI may be accessed and processed by the vendor. The vendor will process the CDI only as set forth in UTS’s written instructions. All of the service provider’s systems storing or processing CDI must comply with federal, state and local laws concerning data privacy, UTS’s Data Governance and Classification Policy, Vendor Minimum Safeguards, and where applicable, the European Union‘s General Data Protection Regulation (GDPR).
Service provider shall develop, implement, maintain and use appropriate administrative, technical and physical security measures to preserve the confidentiality, integrity and availability of all electronically maintained or transmitted CDI received from, or on behalf of university or any individuals. The service provider will extend these security standards obligations to all subcontractors by contract.
- Service provider must supply documentation of compliance with any applicable laws and regulations upon request.
- All systems and applications shall undergo vulnerability assessments, such as testing patch level, password security, and application security in accordance with industry best practices, or will provide reports upon request if conducted by a third party.
- Service provider agrees to allow UTS to perform regular pen testing/vulnerability scans (operating system, patch, and
application) in accordance with industry best practices. - Routine event monitoring will be performed by the service provider; the service provider will immediately identify events related to unauthorized activity and unauthorized access.
- Service provider shall agree to forward unmodified system (and other appropriate) logs to the UTS Director of Technology.
- The service provider shall agree to undergo regular security audits, preferably by certified third parties, occurring at least annually, and any identified issues must be resolved within 90 days of the audit report. UTS may demand written proof of this audit at any time during the term of the contract.
- All services gathering Restricted data, or otherwise sensitive data as defined by UTS’s policies must utilize secure communication methods, such as TLS, and use a certificate from an approved independent authority.
- All file transmissions involving CDI, or otherwise sensitive data as defined by the seminary, must utilize secure communication methods; for example, TLS, SSH, SFTP.
- Service provider agrees to allow the use of Shibboleth authentication (or comparable authentication mechanism with seminary approval) if and when appropriate as requested by the university.
- Physical access to facilities where data is stored, whether production or backup, must reside within the continental United States. Any damage or unauthorized access to facilities must be reported to UTS within 24 hours of its discovery. If any unauthorized access to UTS’s CDI occurred, the service provider must consult with UTS officials before notifying those
affected by the unauthorized access.
Acknowledgment of Access to CDI: Service provider acknowledges that the Agreement allows the service provider access to CDI. Data access shall be limited to those with a “need to know” and controlled by specific individual(s). As required by law, at no time will UTS data be physically or logically accessible to a foreign national. The service provider must have procedures and solutions implemented to prevent unauthorized access, and the procedures will be documented and available for UTS to review upon request. All of the service provider’s employees with access to UTS’s CDI must be identified with names provided to the university upon request.
Prohibition on Unauthorized Use or Disclosure of CDI: Service provider agrees to hold CDI in strict confidence. Service provider shall not use or disclose CDI received from or on behalf of UTS (or any individuals) except as permitted or required by the Agreement, as required by law, or as otherwise authorized in writing by UTS. Service provider agrees not to use CDI for any purpose other than the purpose for which the disclosure was made.
International Data Transfers: In accordance with GDPR Article 44, Processor shall rely on a Valid Transfer Mechanism to transfer Personal Data for Processing (whether performed by Processor or by a Subprocessor) from the European Economic Area to another country.
Retention, Return or Destruction of CDI: Upon termination, cancellation, expiration or other conclusion of the Agreement, service provider shall return all CDI to UTS or, if return is not feasible, destroy any and all CDI. Destruction of CDI shall be carried out in accordance with UTS’s data retention policies. UTS shall approve the method of data destruction prior to destruction. If the service provider destroys the information, the service provider shall provide UTS with a certificate confirming the date and method of destruction of the data.
Maintenance of the Security of Electronic Information: Service provider shall develop, implement, maintain and use appropriate administrative, technical and physical security measures to preserve the confidentiality, integrity and availability of all electronically maintained or transmitted CDI received from, or on behalf of UTS or its students. These measures will be extended by contract to all subcontractors used by service provider.
Reporting of Unauthorized Disclosures or Misuse of Covered Data and Information: Service provider shall, within one day of discovery, report to UTS any use or disclosure of CDI not authorized by this Agreement or in writing by university. Service provider’s report shall identify:
- The nature of the unauthorized use or disclosure,
- The CDI used or disclosed,
- Who made the unauthorized use or received the unauthorized disclosure,
- What service provider has done or shall do to mitigate any deleterious effect of the unauthorized use or disclosure,
- The corrective action service provider has taken or shall take to prevent future similar unauthorized use or disclosure,
- Service provider shall provide such other information, including a written report, as reasonably requested by UTS.
Remedies: If UTS reasonably determines in good faith that service provider has materially breached any of its obligations under this contract, UTS , in its sole discretion, shall have the right to require service provider to submit a plan of monitoring and reporting; provide service provider with a fifteen (15) day period to cure the breach; or terminate the Agreement immediately if cure is not possible. Before exercising any of these options, UTS shall provide written notice to service provider describing the violation and the action it intends to take. Service provider shall defend and hold UTS harmless from all claims, liabilities, damages, or judgments involving a third party, including UTS’s costs and attorney fees, which arise as a result of service provider’s failure to meet any of its obligations under this contract. Nothing in this paragraph limits any other remedies available to UTS.
Note: Inclusion of data provided by individuals into the terms of the contract will depend upon the contract and may not be needed.
Acceptable Use of Information Technology Resources
Policy Statement
Computers and other information technology resources are essential tools in accomplishing the Union Theological Seminary’s mission. Information technology resources are valuable assets to be used and managed responsibly to ensure their integrity, confidentiality, and availability for appropriate research, education, outreach and administrative objectives of the institution. Community members are granted access to these resources in support of accomplishing the stated mission.
All users of information technology resources, whether or not affiliated with the Seminary, are responsible for their appropriate use, and by their use, agree to comply with all applicable Seminary policies; federal, state and local laws; and contractual obligations. These include but are not limited to information security, data privacy, commercial use, and those that prohibit harassment, theft, copyright and licensing infringement, and unlawful intrusion and unethical conduct.
Union Theological Seminary accepts no responsibility or liability for any personal or unauthorized use of its resources by users.
Acceptable Use
Acceptable use includes, but is not limited to, respecting the rights of other users, avoiding actions that jeopardize the integrity and security of information technology resources, and complying with all pertinent licensing and legal requirements. Users with access to Union Theological Seminary’s information technology resources must agree to and accept the following:
- Only use information technology resources they are authorized to use and only in the manner and to the extent authorized. Ability to access information technology resources does not, by itself, imply authorization to do so.
- Only use accounts, passwords, and/or authentication credentials that they have been authorized to use for their role at the Seminary.
- Protect their assigned accounts and authentication (e.g., password, and/or authentication credentials) from unauthorized use.
- Only share data with others as allowed by applicable policies and procedures, and dependent on their assigned role.
- Comply with the security controls on all information technology resources used for school business, including but not limited to mobile and computing devices, whether seminary or personally owned.
- Comply with licensing and contractual agreements related to information technology resources.
- Comply with intellectual property rights (e.g., as reflected in licenses and copyrights).
- Accept responsibility for the content of their personal communications and may be subject to any personal liability resulting from that use.
Unacceptable Use
Unacceptable use includes and is not limited to the following list. Users are not permitted to
- Share authentication details or provide access to their seminary accounts with anyone else (e.g., sharing the password).
- Circumvent, attempt to circumvent, or assist another in circumventing the security controls in place to protect information technology resources and data.
- Knowingly download or install software onto seminary’s information technology resources, or use software applications, which do not meet University security requirement, or may interfere or disrupt service, or do not have a clear business or academic use.
- Engage in activities that interfere with or disrupt users, equipment or service; intentionally distribute viruses or other malicious code; or install software, applications, or hardware that permits unauthorized access to information technology resources.
- Access information technology resources for which authorization may be erroneous or inadvertent.
- Conduct unauthorized scanning of information technology resources.
- Engage in inappropriate use, including but not limited to:
- Activities that violate state or federal laws, regulations, or University policies.
- Harassment
- Widespread dissemination of unsolicited and unauthorized electronic communications.
- Engage in excessive use of system information technology, including but not limited to network capacity. Excessive use means use that is disproportionate to that of other users, or is unrelated to academic or employment-related needs, or that interferes with other authorized uses. Units may require users to limit or refrain from certain activities in accordance with this provision.
Privacy and Security Measures
Users must not violate the privacy of other users. Technical ability to access others’ accounts does not, by itself, imply authorization to do so.
Users play an important role in the protection of their personal information. All faculty, staff and students are required to use all available user specific security controls provided by the Seminary as available (including multi-/two-factor authentication) and meet the user specific controls in Administrative Policy: to assist in the protection of assets and the protection of their personal information and assets. Failure on the part of faculty, staff or students to employ in good faith the available security controls and to secure their personal information appropriately will mean that the seminary will not reimburse the faculty, staff or student for the loss of misdirected salary, expense reimbursements, financial aid or any other assets.
Employees must understand that any records and communications they create related to seminary business, electronic or otherwise, on an assigned or personally owned device, may be subject to disclosure under New York State’s Data Practices laws.
The Seminary takes reasonable measures to protect the privacy of its information technology resources and accounts assigned to individuals. However, the University does not guarantee absolute security and privacy. Users should be aware that any activity on information technology resources may be monitored, logged and reviewed by Seminary-approved personnel or may be discovered in legal proceedings. The Seminary assigns responsibility for protecting its resources and data to technical staff, data owners, and data custodians, who treat the contents of individual assigned accounts and personal communications as private and do not examine or disclose the content except:
- as required for system maintenance including security measures;
- when there exists reason to believe an individual is violating the law or Seminary policy; and/or
- as permitted by applicable policy or law.
The Seminary reserves the right to employ security measures. When it becomes aware of violations, either through routine system administration activities or from a complaint, it is the Seminary’s responsibility to investigate as needed or directed, and to take necessary actions to protect its resources and/or to provide information relevant to an investigation.
Enforcement
Individuals who use information technology resources that violate a Seminary policy, law(s), regulations, contractual agreement(s), or violate an individual’s rights, may be subject to limitation or termination of user privileges and appropriate disciplinary action, legal action, or both. Alleged violations will be referred to the appropriate office or law enforcement agency.
The Seminary may temporarily deny access to information technology resources if it appears necessary to protect the integrity, security, or continued operation of these resources or to protect itself from liability.
Individuals or units should report non-compliance with this policy to a member of the senior staff in the organization.
Exceptions
Departments within the Seminary may define additional conditions of use for information technology resources or facilities under their control. Such additional conditions must be consistent with or at least as restrictive as any governing Board or Administrative policy, and may contain additional details or guidelines.
Information Security Program
December 2024
Union Theological Seminary is required by the Gramm-Leach-Bliley Act (“GLBA”) and its implementing regulations at 16 CFR Part 314, to implement and maintain a comprehensive written Information Security Program (“ISP”) and to appoint a coordinator for the program. The objectives of the ISP are to (1) insure the security and confidentiality of covered information; (2) protect against anticipated threats or hazards to the security and integrity of such information; and (3) protect against unauthorized access or use of such information that could result in substantial harm or inconvenience to customers.
Related Policies
This ISP is in addition to existing Union Theological Seminary policies and procedures that address various aspects of information privacy and security, including but not limited to, the Student Privacy Rights Policy (Family Educational Rights and Privacy Act Policy), the Information Security Policy, and the Computing Policy.
ISP Coordinator
Union Theological Seminary has designated the Chief Information Officer as its ISP Coordinator. The ISP Coordinator may designate other individuals to oversee and/or coordinate particular elements of the ISP.
Covered Information
“Covered information” means nonpublic personal information about a student or other third party who has a continuing relationship with UTS, where such information is obtained in connection with the provision of a financial service or product by UTS, and that is maintained by UTS or on UTS’s behalf. Nonpublic personal information includes students’ names, addresses and social security numbers as well as students’ and parents’ financial information. Covered information does not include records obtained in connection with single or isolated financial transactions such as ATM transactions or credit card purchases.
Elements of the ISP
- Risk Identification and Assessment.UTS’s ISP identifies and assesses external and internal risks to the security, confidentiality, and integrity of covered information that could result in the unauthorized disclosure, misuse, alteration, destruction or other compromise of such information. The ISP Coordinator will provide guidance to appropriate personnel in the central administration, academic units, and other university units in evaluating their current practices and procedures and in assessing reasonably anticipated risks to covered information in their respective areas. The ISP Coordinator will work with appropriate personnel to establish procedures for identifying and assessing risks in the following areas:
- Employee Training and Management. The ISP Coordinator will coordinate with the appropriate personnel to evaluate the effectiveness of current employee training and management procedures relating to the access and use of covered information.
- Information Systems.The ISP Coordinator will coordinate with the appropriate personnel to assess the risks to covered information associated with the university’s information systems, including network and software design as well as information processing, storage, transmission and disposal.
- Detecting, Preventing and Responding to Attacksand System Failures The ISP Coordinator will coordinate with the appropriate personnel or consulting group to evaluate procedures for and methods of detecting, preventing and responding to attacks, intrusions or other system failures.
- Designing and Implementing Safeguards. The ISP Coordinator will coordinate with appropriate personnel to design and implement safeguards, as needed, to control the risks identified in assessments and will develop a plan to regularly test or otherwise monitor the effectiveness of such safeguards. Such testing and monitoring may be accomplished through existing network monitoring and problem escalation procedures.
- Overseeing Service Providers. The ISP Coordinator, in conjunction with Vice President for Finance and Operations, and appropriate contractors, will assist in instituting methods for selecting and retaining service providers that are capable of maintaining appropriate safeguards for covered information. These standards will apply to all existing and future contracts entered into with service providers to the extent required under GLBA.
- Adjustments to Program.The ISP Coordinator will evaluate and adjust the ISP as needed, based on the risk identification and assessment activities undertaken pursuant to the ISP, as well as any material changes to UTS’s operations or other circumstances that may have a material impact on the ISP.
Breach Reporting Policy
A. Reporting
Any suspected or confirmed breach or compromise of Sensitive Data must be reported to the departments set forth in Section D below in a timely manner in order to mitigate the risk to Information Resources and protect the University’s operations.
B. Seminary’s Response Team
Upon receipt of such report, the Chief Information Officer, the Chief Operating Officer, Senior Staff and the General Counsel or his or her delegate will convene to determine response message and mitigation strategy.
The following lists the general responsibilities of this group:
- The Information Technology Office will be responsible for serving as Incident Lead for any actual or suspected compromise of Sensitive Data (other than PHI).
- The assigned Data Stewards will be responsible for serving as Incident Lead for any actual or suspected compromise of PHI.
- The General Counsel is responsible for all legal issues associated with an actual or suspected compromise of Sensitive Data.
- The Director of Security is responsible for all contacts with law enforcement and for non-technical aspects of any investigation.
- The Communications Office is responsible for all internal and external communications and media relations.
- Human Resources will advise on personnel issues and communications to University staff.
The affected Seminary department(s) will provide the support required to investigate and respond to the actual or suspected compromise of Sensitive Data.
C. Procedures
Each Department will establish detailed internal procedures for compliance, external and internal communications, oversight of the investigation and technical support associated with a suspected or actual breach of Sensitive Data.
The specific incident response procedures are set forth in the applicable Information Security and Privacy Incident Procedure and Checklist.
The general steps in a response include the following:
- Incident Categorization
Incidents will be categorized based on the applicable UTS Information Technology Office’s internal procedures. Based on the severity of the incident, an appropriate response action will be taken. - Response and Recovery
The assigned incident response team may call upon any necessary additional offices and resources required to carry out the investigation and remediation of any breach. This expanded team will be responsible for the investigation of the incident and any technical support required. Incident team members will include representatives of affected Data Owners and any other units responsible for the Information Resources involved.
Any individual responsible for an Information Resource containing Sensitive Data that may have been compromised must take immediate steps to secure that system and preserve it without change. - Lessons Learned
After an incident has been resolved, an incident report will be created and distributed to the Seminary’s Senior Staff. The Chief Information Officer will then convene to discuss the security controls that failed and establish the steps necessary to prevent or limit the risk of the incident recurring.
D. Contact Information
To report a possible breach of PHI or to report a possible breach of Sensitive Data at UTS:
UTS Information Technology Office
Email: [email protected]
Telephone: 212-280-1460
Business Risk, Contingency, and Data Backup Plan Policy
A. Business Risk Assessment and Business Impact Analysis
Each Department Manager is required to perform a Business Risk Assessment and Business Impact Analysis for each Key Business System that is used in his/her area of responsibility. The assessment should identify and define the criticality of Key Business Systems and the repositories that contain the relevant and necessary Seminary Data for the Department. The assessment should also define and document the Disaster Contingency and Recovery Plan (the “Contingency Plan”) for his/her area of responsibility. Such Plan shall include the following:
- Key business processes;
- Applicable risk to availability;
- Prioritization of recovery;
- Recovery Time Objectives; and
- Recovery Point Objectives.
For purposes of this Policy, a “Recovery Time Objective” is the duration of time and a service level within which a business process must be restored after a disaster or disruption in order to avoid unacceptable consequences associated with a break in business continuity and a “Recovery Point Objective” is the maximum tolerable period during which Data might be lost from an Information Resource.
B. Contingency Plans
Each Key Business System must have a Contingency Plan documented for when hardware, software or Networks become critically dysfunctional or cease to function (short term and long term outages). This Plan should include an explanation of the magnitude of information or System unavailability in the event of an outage and the process that would be implemented to continue operations during the outage. In addition, the feasibility of utilizing alternative off-site computer operations should be addressed.
Specifically, the Contingency Plan must include:
- An Emergency Mode Operations Plan for continuing operations in the event of temporary hardware, software or Network outage. This Plan should contain information relating to the end user process for continuing operations.
- A Recovery Plan for returning functions and services to normal on-site operations when a disaster is over.
- A procedure for periodic testing, review and revision of the Contingency Plan for all affected Systems, as a group and individually as needed.
C. Data Backup Plans
Each System Owner and IT Custodian will implement a Data Backup Plan or document the decision to forgo a Plan with a risk-based analysis. Such Plan should define the following:
- Who is responsible for taking reasonable steps to ensure the backup of University Data, particularly Sensitive Data and Confidential Data;
- A backup schedule;
- The Key Business Systems that are to be backed up;
- Where backup media is to be stored and workforce members who may access the stored backup media;
- Where backup media is to be kept secure before it is moved to storage, if applicable;
- Who may remove the backup media and transfer it to storage;
- Restoration procedures to restore Key Business System Data from backup media to the appropriate System;
- Test restoration procedures and frequency of testing to confirm the effectiveness of the Plan;
- The retention period for backup media; and
- A method for restoring encrypted backup media, including encryption key management.
Registration and Protection of Systems Policy
A. Registration of Systems
The following Systems must be registered with the Union Theological Seminary’s Information Technology Department. If there are access control ramifications connected to the technology then the Security Office must be informed.
- Any System that processes, transmits and/or stores PHI, regardless of location;
- Any System that processes, transmits and/or stores Seminary Data whose Data Owner or any related Executive Manager, Security Manager, System Owner, IT Custodian or IT Group
- Any System physically located in the Union Theological Seminary Data Center.
Registration will be carried out in accordance with the procedures established by each such Office.
B. Risk Assessment and Certification Requirements for Systems
Each System is subject to risk assessment by the Seminary’s Information Technology Office, remediation, if necessary by the System Owner and certification by such IT Office in accordance with procedures established by the Seminary. Each certified System shall be recertified on a periodic basis, as determined by the level of risk, by the applicable Information Security Office.
C. General Protection Requirements for Systems
- Each System Owner will ensure that the following protections, at a minimum, are implemented for each System:
An IT Custodian has been appointed for the System by the Chief Information Officer of the organization, as applicable. - The facility that houses the System’s Servers, including primary and backup equipment, is environmentally controlled and physically secured from unauthorized access.
- Each Server is physically identifiable.
- All Seminary Data files on a Server are backed up and adhere to all Disaster Recovery and Business Continuity standards agreed to by Union Theological Seminary Chief Operation Officer and Senior Staff
- Each of the System’s production Servers has a UPS that can provide emergency power and shut the Server down in case of a power outage.
- Standard configurations, as defined by the Chief Information Officer. Access to the System’s Servers and the Seminary Data residing on the System is restricted and is maintained in accordance with agreed upon access control standards.
- The System’s Servers are not used for general desktop functions, such as web browsing, conducting personal email or other Union business or non-business functions.
- The System’s Servers are running vendor-supported operating systems and have up-to- date security patches installed.
- The System’s Servers are accessible only for the services provided and only to as much of the Network as is required to provide such services, and firewalls or equivalent protections prevent unauthorized access. To the extent practicable, anti-virus, anti-spyware and System monitoring programs are installed to protect and/or prohibit unauthorized access.
- Any Peer-to-Peer Program is used only for Seminary purposes, is configured properly as directed by the applicable Information Security Office and does not permit general purpose file sharing over the Internet.
- Only required services that run on the System’s Servers are enabled. Unneeded services are disabled.
D. Additional Protection Requirements for Systems Containing Sensitive Data
Each System Owner shall ensure that, in addition to the protections described in Section C above, the following protections are implemented for each System that processes, transmits and/or stores Sensitive Data:
- A record is kept of what type of Sensitive Data are stored on the System’s Servers and of all changes to the configuration of the Server, and such documentation is kept in a secure, locked location away from the Server.
- In web-based Systems that are exposed to the Internet, protection mechanisms are implemented to prevent common web-based attacks. Examples of protection elements include web-based firewalls and/or source code security reviews. All such Systems are protected according to the security standards set by the organization.
- Sensitive Data are encrypted while in transit.
- Removable Media containing Sensitive Data are encrypted.
- In Relational Database Management Systems, Sensitive Data are encrypted in a way that permits database administrators to perform their management functions without access to such Data in a readable format.
- The System’s Servers are maintained in appropriate Data centers, Server closets or Data closets that meet or exceed the following physical requirements:
- Video camera surveillance;
- Badge reader (rather than key) access;
- Use of a visitor log to document all visitors who accompany an authorized User, which is posted by the main ingress/egress point of the secure facility;
- Alarms on the door that alert University Public Safety if (x) the door is left ajar, (y) the door is forced open or (z) the security lock malfunctions; and
- An emergency power shut off button that can cut off power to all circuits in the case of a fire or other physical threat.
It is recommended, but not required, that Confidential Data be protected with a password while in transit or in storage.
E. Additional Protection Requirements for Registered Systems
Each System must follow the specific procedures relating to Systems in accordance with the Seminary’s policies.
F. Additional Protections for Email Systems
Each email System Owner shall ensure that, in addition to the protections described in Section C and, if applicable, Sections D and E above, the following protections are implemented for such System:
- Virus, spam and phishing protection for inbound and outbound messages is implemented through the use of mail filtering software that includes features such as content analysis and real time blacklists.
- SMTP relay is performed only for authenticated Users or Systems.
- Monitoring to detect compromised email accounts is implemented and such accounts are disabled on a timely basis.
- Data loss prevention is implemented to ensure that unencrypted Sensitive Data is not released.
- Detection or prevention mechanisms are implemented to monitor the use of automatic forwarding, redirection or other automated delivery of email as required by the Seminary’s policies.
G. Additional Protections for Credit Card Information
Each System Owner shall ensure that, in addition to the protections described in Sections C and, if applicable, D, E and F above, the following protections are implemented for such System:
- All local IT support groups comply with the requirements of the Merchant Security Review Form referred to in the Credit Card Policy prior to the implementation of or changes to any credit card related services in the merchant environment.
- All merchant environments are approved by Union’s technical team and security vendors.
H. Waivers and Exceptions
Any System Owner may request that a System that contains Sensitive Data, but cannot use encryption because of technology or business limitations be granted a waiver of the provisions of this Policy by the applicable Information Security Office. Such a waiver may only be granted if such Office determines that there are compensating controls in place to address all major information security risks.
I. Supplemental Requirements
The requirements lists set forth in this Policy are not comprehensive and supplemental controls may be required by the Seminary to enhance security as necessary.
Union IT Procedures
Electronic Data Security Breach Reporting and Response Procedure
A. Reason for Procedure
This Procedure established measures that must be taken by the Senior Staff and Chief Operation Office as response to a possible breach or compromise of Sensitive Data in order to comply with all applicable federal and state laws and regulations.
B. Responsible Office and / or Officer
The Chief Operating Officers is responsible for initiating the Electronic Data Security Breach Procedure. The Union Theological Seminary IT Department is responsible for determining the extent of a confirmed breach.
C. Procedures
The following procedures will be followed when a breach of Sensitive Data is suspected or known to occur:
- Report
Any suspected or confirmed compromise of Sensitive Data must be reported to Union Theological Seminary Information Technology Department [email protected]> as soon as possible – include the keyword “[Data Security Breach]” in the subject of the email. This will automatically open a ticket with the support team that will be used to document and track the response to the incident. - Breach Confirmed – Report to Chief Operating Officer & Security Office
If a breach is confirmed, UTS IT Department will report the breach to the Chief Operating Officer, who will report the breach to the appropriate Senior Staff, Legal Counsel, and Vendors to mitigate the risk to the Seminary’s Information Resources and protect the operations. - Isolate System
The compromised system must be isolated from the UTS network as soon as possible and preserved in its current state. Systems affected by potential ransomware attacks should also isolate their backup systems and secure any uncompromised backups available.
4. Secure Logs
Administrator for the system should attempt to secure logs whenever possible to aid in the investigation. - Incident Categorization
The incident will be categorized based on the duration of the breach, the type of data that was affected and the potential to breach other systems in the UTS network and external networks. Categories include:- Vulnerability on a system with Sensitive Data detected
- Inadequate security for Sensitive Data detected
- Unauthorized access to Sensitive Data detected internal to UTS network
- Unauthorized access to Sensitive Data detected external toUTS network
- Breached system used to breach other systems on UTS network
- Breached system used to breach other systems external to UTS network
- Damage Assessment
Union Theological Seminary’s IT Department will determine the extent of any data security breach. UTS IT may contact any additional offices and resources required to classify the incident and determine the extent of the breach. - Recovery
The affected system will be repaired / reconfigured / cleaned as necessary by the Administrator responsible for the system.
D. Lessons Learned
An incident report will be generated, highlighting how the existing security systems failed and suggest ways to prevent similar breaches in the future.
Incident Report Details
- What systems were affected?
- System name
- IP address
- Which Data was compromised?
- Identify from the Data Asset Inventory
- When and how was the breach performed?
- Software involved (include version numbers)
- Hardware if relevant (include firmware version)
- When and how was breach detected?
- How can a similar breach be prevented in the future?
Change Management Procedure
A. Purpose
Change Management helps to assure that system and data integrity controls are appropriate for systems which process Sensitive Data, including network administration, research system configuration control, research system software, proprietary (application) software and research data.
B. Responsible Office and Staff Member
The Project Owner is responsible for reporting any changes to system configurations, installed software, etc. The Chief Operation Officer is responsible for categorizing the change requests and approving, denying or modifying the changes.
The Union Theological Seminary’s Chief Operation Officer will work in conjunction with the Chief Information Officer to maintain and review these procedures.
C. Scope
This procedure is required whenever a change is planned for the following aspects of the Union Theological Seminary network and hosted platforms that process, store or access Sensitive Data:
- System configurations
- System software
- Application software
- Proprietary software
- Procedures
- Processes
- Infrastructure
D. Risk Matrix
Changes are classified into three different priorities, based on the potential impact that would occur in the wider UTS network:
Priority 1 | Crosses organizational boundaries, serving the business functionality of many units. Is critical to the ability of UTS to meet its business and regulatory obligations, support the delivery of education, or administer research.
Priority 2 | The system is a feeder to Priority 1 systems; or is a system that does not cross organizational boundaries, but is still critical to the ability of UTS to meets its business and regulatory obligations
Priority 3 | Any outside hosted system that supports the internal operations of the Seminary or departmental function and does not cross organizational boundaries.
E. Change Classification
Changes will be classified into four categories:
Classification | Description | Change Request Required | Approval Required | User Notification Required |
---|---|---|---|---|
Routine | A Routine change is one that has relatively low risk with well-understood outcomes that is regularly made during normal business. A routine change follows predetermined processes and can be performed with zero impact on users. | Notification of change for record keeping only | No | No |
Minor | A Minor change is one that has low to medium risk for critical services, involves less understood risk, has less predictable outcomes, and / or is a change that not regularly made during normal business. Because of the ability to affect downstream or upstream services, changes must be reviewed and approved before implementation. | Yes – submit Change Request before the change | Yes | Yes, unless the impact is transparent to users |
Major | A Major change is one that has medium to high risk for critical services, involves unknown risks, and involves downtime which impacts a large percentage of users across Union Theological Seminary. | Yes, at least two days before the change | Yes | Yes |
Emergency | An Emergency change is one that involves services which are already impaired and requires the utmost urgency to resolve. The approach here is to fix the problem first and document the change afterwards. Root-cause analysis must be performed to determine if the issue can be prevented in the future | Notification of change for record keeping only | N/A | N/A |
F. Procedure
- Request for Change
Open a ticket at [email protected] with the heading of “Change Item” and answers the following questions, at a minimum:- Change Classification (Routine, Minor, etc.)
- When is the requested date to perform the change?
- What are the proposed technical changes?
- What systems are impacted?
- Why is the change necessary?
- Union Theological Seminary – IT Response
- Approval – the change will be scheduled and communications will be sent to the appropriate group or groups.
- Denied – the request will be closed OR modifications will be requested.
- Implementation
- After proper approval notification, the change is released / performed on the date and time communicated.
- Testing
- Test the change thoroughly to verify success.
- Review
- If the change is successful, communicate that to the relevant users and peers, update the ticket to indicate the change was successful.
- If the change failed, communicate that to the relevant users and peers, attempt to restore the previous state of the system and update the ticket with all relevant information as to what went wrong and possible solutions to the issue.
- Update the project’s Information Asset Inventory to reflect the new state of the system.
G. References
See the IT Policy Section here: https://utsnyc.edu/about/institutional-info