IT Security Policy - Draft

Policy Presented for 30-Day Review

This policy has been developed by the IT Policy Committee (ITPC) and is being submitted for comment and review.

The comment period ends on noon, January 15, 2021

Comments may be directed to: IT-POLICY-ADM@LISTS.UPENN.EDU


DRAFT

IT Security Policy

1 Introduction

1.1 This policy is organized according to the National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF).

It describes requirements for the following:

  • securing computing devices
  • protecting confidential University data.
  • securing web applications developed by Penn that access University data
  • ensuring that security incidents are identified, contained, investigated, and remedied.

This policy also includes:

  • a baseline set of requirements for all computing devices that connect to PennNet
  • additional requirements for devices that store or access confidential University data or operational data as defined in Definitions located in the Governance Standards.
  • a baseline set of requirements for all web applications
  • additional requirements for applications that access moderate or high-risk University data as defined in the Data Risk Classification
  • a process for documentation, appropriate reporting internally and externally, and communication so that organizational learning occurs
  • responsibility and accountability for all steps in the process of addressing computer security incidents.

2 Purpose

2.1 The purpose of the policy is to protect the confidentiality, integrity, and availability of University data, and to protect Penn's computing and network infrastructure.

3 Scope

3.1 This policy applies to the scope contained in the IT Policy Governance Policy Scope Section with the following scope inclusions and exclusions:

3.2 Inclusions

3.2.1 This policy applies to all University users who employ any computing devices owned or leased by the University of Pennsylvania that experience a Computer Security Incident. It also applies to any computing device regardless of ownership, which either is used to store Confidential University Data, or which, if lost, stolen, or compromised, and based on its privileged access, could lead to the unauthorized disclosure of Confidential University Data. Examples of systems in scope include, but are not limited to, a User's personally owned home computer that is used to store Confidential University Data, or that contains passwords that would give access to Confidential University Data.

3.2.2 This policy also applies to all mobile devices running a workstation-class operating system supported by Penn, and capable of doing native full-disk encryption, except for Temporary Use Mobile Devices.

3.2.3 With regard to applications, this policy applies to:

  • All web applications that are developed by Penn employees and that access "Moderate" or "High" risk University data.
  • All developers and application owners of those applications.
  • All web application dependencies, including libraries, frameworks, and software that serves those applications.
3.3 Exclusions

3.3.1 This policy does not cover incidents involving the University of Pennsylvania Health System (UPHS) information systems, which has a separate incident response policy. Penn's Office of Information Security (OIS) will coordinate with UPHS as appropriate when UPHS computing devices, data, or personnel are involved.

4 Risks to Non-Compliance

4.1 Non-compliance with this policy poses great risk to Penn and to individuals whose data Penn maintains. For Penn and its Schools and Centers, there may be regulatory fines, lawsuits, reputational damage, and the loss of trust by critical members of our community. For individuals, a breach of confidentiality may result in identity theft, embarrassment, harassment, and other problems. Further, security incidents can threaten the confidentiality, integrity, and availability of Penn's computing infrastructure and the critical data on which Penn's research, teaching, and service missions depend.

4.2 Non-compliance with incident response policy may delay corrective action and harmful effects may be unnecessarily exacerbated. Individuals who fail to comply are subject to sanctions as appropriate under Penn policies.

5 Requirements

 

5.1 Identify

 
5.1.1 Critical Component Registration

5.1.1.1 System administrators must ensure that critical components are properly registered in the Critical Component application to ensure that regular vulnerability scanning by Penn's Office of Information (OIS) is performed.

5.2 Protect

5.2.1 Responsibility

5.2.1.1 Every computer user is responsible for securing and protecting the information technology resources and data over which he or she has control. In meeting this requirement, users may rely upon the expertise, advice, and assurances of Local Support Providers, and School or Center Security Liaisons. Penn's Office of Information Security (OIS) and the Office of Audit, Compliance and Privacy (OACP) are responsible for providing consultation and assistance in implementing this policy and for security matters in general.

5.2.2 Authentication

5.2.2.1 All users and/or accessors of private University resources must be authenticated using the appropriate, University-managed authentication mechanism for the populations served, as defined by this policy?s associated Standards and Guidelines documents.

5.2.2.2 The user namespace used for authentication must be fully PennNames compliant.

5.2.2.3 Remote access services must authenticate the user connecting to the service.

5.2.2.4 Any host involved in the authentication process must be registered in Critical Components.

5.2.2.5 The following information must be logged for each attempted authenticated connection:

  • The login name used for authentication
  • IP address and timestamp of authenticating user

5.2.2.6 Passwords

5.2.2.6.1 Devices and services that use passwords for authentication must be protected by strong passwords or passphrases as specified in the Password Complexity Standard so that they are resistant to modern-day attacks.

5.2.2.6.2 Devices and services that access "High" Risk Classified data must use strong authentication as specified in the Strong Authentication Standard

5.2.2.6.3 Passwords must be encrypted in transit and in storage.

5.2.2.6.4 Wherever possible, use PennKey for user authentication.

5.2.2.6.5 Web applications and their associated APIs accessing moderate or high-risk data must require strong authentication.

5.2.2.6.6 Authentication credentials (for example: private keys or passwords) must not be hard coded into the source code of the application or stored in the source code repository.

5.2.3 Identification

5.2.3.1 PennIDs for members of the Primary University Community

5.2.3.1.1 All persons belonging to the ?PRIMARY UNIVERSITY COMMUNITY?, which explicitly includes all faculty, staff, students, alumni, and contractors, are to be assigned a universal identifier, called a PennID, which is used to uniquely reference individuals within and among University systems. PennIDs are unique, permanent, and exclusive to one identity.

5.2.3.1.2 PennIDs are assigned to a Primary University Community member only after collecting a set of personally identifying information and verifying that the person does not already have a PennID from a prior relationship with the University.

5.2.3.2 PennName Policies

5.2.3.2.1 Any name used by a system or service must be sponsored, if that name falls within the PennNames namespace.

5.2.3.2.2 An individual who is assigned a PennName must be assigned a single, unique PennName by a sponsor.

5.2.3.2.3 A PennName which is used by groups or non-humans must be reserved, so that it will not be assigned to an individual as a PennName. A reserved PennName must be sponsored by each school, center or service that uses it.

5.2.3.2.4 A PennName for an individual must have a Penn ID associated with it. A limited number of PennNames created prior to July, 2004 may not have Penn IDs associated with them, and they may not be reactivated until Penn IDs are provided. Furthermore, they may be released (made available for re-use).

5.2.3.2.5 Application owners must register and relinquish sponsorship of PennNames using the PennNames service since sponsors will need to be notified in the event a PennName changes.

5.2.3.2.6 The existence of a PennName does not imply authorization status. Applications should perform authorization based on verified status using appropriate affiliation data from Penn Community or other sources of authorization data.

5.2.3.2.7 The PennName will be associated with an individual indefinitely, regardless of the following events:

  • the username's removal from the sponsor's system(s); or
  • the individual's separation from Penn, whether through graduation, retirement, resignation, termination or death

unless the PennName is transferred, as described below.

5.2.3.2.8 Individuals may change their PennName under the following conditions:

  • legal name change;
  • PennName deemed offensive;
  • typographical, technical, or administrative error discovered within 1 business week of creation, as long as the PennName only has been used in ways that can easily be undone (e.g. accounts can be renamed, but publication of an email address cannot be reversed);
  • harassment; or
  • transfer of their PennName

In such cases, the former PennName is not available for reuse, except in the case of transfer.

5.2.3.2.9 If an individual or group wishes to be assigned a PennName already in use or take a PennName out of circulation, the following process may be used: The requester may contact his or her computing director. The requester's computing director may negotiate with the other sponsor(s), and, where feasible, the current holder of the PennName, to reach a resolution. The current holder may participate in the negotiation, but does not have veto power. The University, as issuer and owner of the PennName, is the governing authority during this process. For the purpose of transfer negotiations, Penn's Chief Information Security Officer will act as the computing director responsible for PennKey sponsorships. If all are in agreement, the PennName may be transferred from the current holder to the requester or taken out of circulation.

5.2.3.2.10 ISC must notify the current holder about the transfer, if the transfer results in the deletion or renaming of the current holder's authentication or authorization credentials for a sponsor's system or service. The last known contact information will be used to attempt to notify the holder of the transfer.

5.2.3.2.11 If a PennName is changed or transferred, the transferring and sponsoring organizations must be responsible for removing any system, application, and/or data access authorized on the basis of that PennName.

5.2.3.2.12 PennName changes will be reported to sponsors by ISC, so appropriate authorization changes can be made.

5.2.3.3 Access

5.2.3.3.1 Access to PennNet in computer labs on campus must require user authentication.

5.2.3.3.2 Records of access to computer labs must be retained for at least 60 days. Logs must include at least the identity of the user, IP address, and the date and time of the connection.

5.2.4 Patching

5.2.4.1 Security patches (including libraries, frameworks, and any other dependencies) must be applied on a timely basis. Patches for security vulnerabilities designated by Penn?s Office of Information Security (OIS) or by vendors as critical must be applied on the following schedule:

  • Servers - immediately or as soon as reasonably practical.
  • Other devices (including routers, printers and special purpose devices connected to PennNet) - within two business days of availability or as soon as reasonably practical.
5.2.5 Account Management

5.2.5.1 System administrators are responsible for ensuring that user accounts are promptly disabled when users no longer require access.

5.2.6 Device Retirement

5.2.6.1 When storage devices or media are to be retired, they must be securely wiped or destroyed before disposal or transfer to salvage vendor.

5.2.7 Event Management

5.2.7.1 System administrators (or their designee) must:

  • Log system security events to a central solution selected and supported by their home organization
  • Periodically review logs for anomalies, with automated real-time alerts configured wherever possible
  • Periodically re-assess what events are being logged to ensure they continue to be consistent with current guidance
  • Ensure that logged data never contains moderate- or high-risk data, unless necessary to the business function.
5.2.8 Endpoint Protection

5.2.8.1 Operating system software firewalls must be activated if the device is connected to the network.

5.2.8.2 For operating systems for which Penn supports or recommends antivirus software, there must be a regular program of maintaining current virus signatures and real-time scanning. For other operating systems or circumstances precluding real-time scanning, equivalent compensating controls must be in place.

5.2.8.3 Penn-owned computers must be managed using an endpoint management solution selected and supported at the School or Center level. This software must enable the automatic reporting of system status as well as delivery of operating system and 3rd-party software patches on demand. System administrators must ensure compliance with this requirement working with their local support provider as required.

5.2.9 Portable Computing Devices including Laptops, Tablets, Storage Devices, and Media

5.2.9.1 Portable Computing Devices, Storage Devices, and Media with Confidential Data must encrypt stored data. Penn High Risk Data as defined in the Penn Data Risk Classification Scheme stored on these devices must be protected at rest using strong encryption, with a key recovery component.

5.2.9.2 Penn-owned portable computing devices running an operating system supported by Penn, and capable of doing native full-disk encryption, must be encrypted.

5.2.9.3 If the portable computing device has multiple disk partitions, all must be encrypted. However, this requirement does not apply to partitions that the operating system does not support encrypting and that are not capable of or designed to store user data (e.g. system-required partitions such as boot partitions or recovery partitions).

5.2.9.4 A key that can be used to decrypt the portable computing device must be stored in a centralized management system or enterprise password vault.

5.2.9.5 In the event a portable computing device is lost or stolen, provisions must be in place to provide a log or report verifying that the portable computing device was encrypted.

5.2.10 Servers with Confidential Data or Operational Data Servers

5.2.10.1 Physical Security

5.2.10.1.1 Servers must be housed in a locked, physically secure area accessible only by those requiring access.

5.2.10.2 Management and Support

5.2.10.2.1 Servers with Penn High Risk Data as defined in the Penn Data Risk Classification Scheme, Confidential University Data or Operational Data must:

  • be assigned a regular, full-time University staff member with an IT position designation as the system administrator.
  • be identified and registered in ISC's Assignments Service.
  • be administered by staff that has attended Penn security training (if offered) or equivalent for the relevant operating system within the past three years. At times, system administration may be delegated to a third party or University member who doesn't meet the foregoing criteria. In such situations, the School or Center must designate a regular, full-time University employee to oversee the system administrator. The appointed individual providing oversight shall be fully accountable for compliance with this policy, and specifically must ensure that:
    • he or she is registered as a contact in ISC's Assignments Service;
    • third parties or designated University members have the necessary skills and training to protect University systems and data; and
    • third parties or designated University members are clearly informed of their obligations to comply with this policy.

5.2.10.3 Encryption

5.2.10.3.1 The system administrator must configure servers and server backups to encrypt any Penn High Risk Data as defined in the Penn Data Risk Classification Scheme or Confidential University Data that is transmitted over networks whenever network data encryption is a readily available capability.

5.2.10.4 Backups and Recovery

5.2.10.4.1 The system administrator must implement a routine program of data backup and regular recovery testing for any servers storing operational data.

5.2.11 Web Application

5.2.11.1 Secure Coding

5.2.11.1.1 Application developers and designers must implement a Software Development Life Cycle (SDLC) that includes:

  • Security as a design requirement
  • Use of a framework where feasible and appropriate as identified by the IT Security Best Practices
  • Following secure coding practices such as minimizing risks identified by the Coding Vulnerability Checklist

5.2.11.1.2 Authentication credentials (for example: private keys or passwords) must not be hard coded into the source code of the application or stored in the source code repository.

5.2.11.1.3 The secret must be encrypted at rest whenever possible using NIST-specified standards and appropriately secured on the file system per the Server Best Practices.

5.2.11.2 Training

5.2.11.2.1 Developers should complete University training where available or security-specific application development training or be able to demonstrate equivalent understanding of secure web architecture design and secure coding practices.

5.2.12 Application Data Security

5.2.12.1 Application managers must purge or move old data offline whenever possible.

5.2.12.2 If stored in a database, application managers must encrypt high-risk data wherever feasible and determined to be not cost prohibitive by the data owner.

5.2.12.3 If high-risk data is hosted by a third party, application managers must ensure that the contract with them covers protection of the data.

5.3 Detect

5.3.1 Vulnerability Scanning

5.3.1.1 Penn's Office of Information Security (OIS) will scan or examine servers at least quarterly for common security vulnerabilities. The system administrator must address, and if necessary, correct any serious vulnerabilities. Servers located behind hardware firewalls must be scanned from inside the firewall by the system administrator subject to OIS providing and supporting security scanning.

5.3.1.2 Email servers must have a documented plan to prevent viruses from being either accepted from, or delivered to, users of the email server.

5.3.1.3 In addition to platform vulnerability scanning, the application layer of all applications housing or accessing moderate or high-risk data must be scanned for vulnerabilities. The application owner can comply with this policy by participating in processes developed and implemented by Penn's Office of Information Security (OIS) in collaboration with the wider campus IT community. Alternatively, the application owner may opt to be responsible for maintaining their own scanning processes which are at least equivalent in both scope and nature to those offered by OIS.

  • The above scanning must be performed at intervals appropriate to the application owner's assessment of technical or business impact of potential exploitation as well as an event-driven basis (e.g., such as prior to initial implementation, after a major code revision, upon publication of a new vulnerability, etc.)
  • If the application owner participates in OIS's scanning program, application owner is responsible for notifying OIS and asking for a scan; OIS is responsible for conducting the scan in a timely manner.
  • If the application owner maintains their own scanning process, they are responsible for scans that are event-driven.
5.3.2 Audit

5.3.2.1 Application administrators must review application and utility (e.g. database) accounts & privileges regularly, especially when someone with elevated privileges leaves.

5.4 Respond

5.4.1 Security Incident Management

5.4.1.1 The Security Incident Response section of this policy is organized around the SANS PICERL (Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned) framework.

5.4.1.2 All Computer Security Incidents must be reported to the Penn Office of Information Security (OIS) promptly.

5.4.1.3 Preparation

5.4.1.3.1 An Immediate Response Team, as designated by Penn's Chief Information Security Officer (CISO), must be created for any Security Incidents involving confidential data.

5.4.1.3.2 Penn's Office of Information Security (OIS) is responsible for logging, investigating, and reporting on security incidents.

5.4.1.3.3 An Immediate Response Team shall be created for Security Incidents involving High or Moderate Risk Data, misappropriation of computing resources and denial of services essential to University function.

5.4.1.3.4 Membership on the Immediate Response Team shall be as designated by Penn's Chief Information Security Officer (CISO). In most cases, members shall include one or more representatives from the Penn Office of Information Security (OIS) and from the affected School or Center's technical and management staff.

5.4.1.3.5 Responsibilities of the Immediate Response Team are to assess the incident and follow incident handling procedures, appropriate to the incident as determined by Penn's Chief Information Security Officer (CISO).

5.4.1.3.6 Immediate Response Team members will share information about security incidents beyond the Immediate Response Team only on a need-to-know basis, and only after consultation with all other team members.

5.4.1.3.7 If Penn's Chief Information Security Officer (CISO) or Penn's Privacy Officer (CPO) in their judgment believe that the incident reasonably may cause significant harm to the subjects of the data or to Penn, each may recommend to the Vice President of Information Systems and Computing (VP-ISC) or Associate Vice President for Audit, Compliance and Privacy (AVP-OACP) that a Senior Response Team be established.

5.4.1.3.8 The Senior Response Team shall be comprised of senior-level officials as designated by the VP-ISC or AVP-OACP. The Senior Response Team shall:

  • Establish whether additional executive management should be briefed and the plan for such briefing.
  • Determine, with final approval by the General Counsel, whether Penn shall make best efforts to notify individuals whose personally identifiable information (PII) may have been at risk. In making this determination, the following factors shall be considered:
    • length of compromise
    • legal duty to notify
    • human involvement
    • sensitivity of data
    • existence of evidence that data was accessed and acquired
    • concerns about personnel with access to the data
    • existence of evidence that machine was compromised for reasons other than accessing and acquiring data
    • additional factors recommended for consideration by members of the Immediate Response Team or the Senior Response Team.
  • Review and approve any external communication regarding the incident.

5.4.1.3.9 Penn's Office of Information Security (OIS) shall maintain a log of all reportable security incidents recording the date, School or Center affected, whether or not the affected machine was registered as a critical host, the type of Confidential University Data affected (if any), number of subjects (if applicable), and a summary of the reason for the intrusion, and the corrective measure taken.

5.4.1.4 Identification

5.4.1.4.1 In the event that a User or a Local Support Provider (LSP) detects a suspected or confirmed Computer Security Incident, the User or LSP must report it to their designated Security Liaison or IT Director.

5.4.1.4.2 Local IT Management must notify Penn's Office of Information Security (OIS) of all Computer Security Incidents with the exception of unsuccessful network scans.

5.4.1.4.3 Penn's Office of Information Security (OIS) shall notify appropriate systems administrators and other personnel of all emergency and attack incidents, as well as all suspicious activity incidents when it believes that an administrator's system is at risk. The system's administrators will then work with OIS to properly address the incident and minimize the risk of future occurrences.

5.4.1.4.4 If an information system involved in an incident affects human life and safety, responding to any incident involving any lifecritical or safety-related system is the most important priority.

5.4.1.4.5 Penn's Office of Information Security (OIS) shall be available for consultation in the event that Schools and Centers have urgent concerns about the availability or integrity of critical systems or data.

5.4.1.4.6 The Immediate Response Team shall promptly work to establish the scope of the incident and to identify the extent of systems and data affected. If it appears that High Risk Data or personally identifiable information (PII) may have been compromised, the Immediate Response Team shall immediately inform Penn's Chief Information Security Officer (CISO) and the Chief Privacy Officer (CPO).

5.4.1.4.7 The Immediate Response Team shall investigate the causes of the incident and future preventative actions. During the investigation phase, members of the incident response team will attempt to determine exactly what happened during the incident, especially the vulnerability that made the incident possible.

5.4.1.5 Containment

5.4.1.5.1 Once life-critical and safety issues have been resolved, the Immediate Response Team shall identify and implement actions to be taken to reduce the potential for the spread of an incident or its consequences across additional systems and networks. Such steps may include requiring that the system be disconnected from the network.

5.4.1.5.2 The Immediate Response Team shall develop a plan promptly upon learning about an incident for identifying and implementing appropriate steps to preserve evidence, consistent with needs to restore availability. Preservation plans may include preserving relevant logs and screen captures. The affected system may not be rebuilt until the Immediate Response Team determines that appropriate evidence has been preserved. Preservation will be addressed as quickly as possible to restore availability that is critical to maintain business operations.

5.4.1.5.3 The Immediate Response Team shall identify and recommend strategies to mitigate risk of harm arising from the incident, including but not limited to reducing, segregating, or better protecting personal, proprietary, or mission critical data.

5.4.1.6 Eradication

5.4.1.7 Recovery

5.4.1.7.1 Once the above steps have been taken, and upon authorization by the Immediate Response Team, the availability of affected devices or networks may be restored.

5.4.1.8 Lessons Learned

5.4.1.8.1 Penn's Office of Information Security (OIS) shall issue a Critical Incident Report for every reportable security incident affecting machines qualifying as Critical Components, or other priority incidents in the judgment of OIS, describing in detail the circumstances that led to the incident, and a plan to eliminate the risk.

5.4.1.8.2 The Immediate Response Team shall develop and arrange for implementation of a communications plan to spread learning from the security incident throughout Penn to individuals best able to reduce risk of recurrence of such incident.

5.4.1.8.3 Penn's Office of Information Security (OIS) shall provide annually for the VP-ISC and AVP-OACP a report providing statistics and summary-level information about all significant incidents reported, and providing recommendations and plans to mitigate known risks.