Retired-Computer Security Policy

Information Systems and Computing's Office of Information Security has the authority and responsibility to establish information security policies, guidelines, and standards.

This policy describes the requirements for securing computing devices and protecting confidential University data. It includes a baseline set of requirements for all computing devices that connect to PennNet, and additional requirements for devices that store or access confidential University data or operational data as defined in Section VI. - Definitions. The policy also provides best practices recommendations to guide users, administrators, and IT staff in further steps to protect Penn's computing and network infrastructure and data. Requirements pertaining to PDAs and Social Security numbers are handled in separate policies.

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. ISC Information Security and the Office of Audit, Compliance and Privacy are also resources for implementation issues raised by this policy and for security matters in general.

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.

Threats to networks and to data stored or transmitted by those networks are on the rise and exist in many forms. Examples include lost or stolen laptops and thumb drives, hacks of servers and desktops, interception of data in transit, abuse of legitimate access by individuals, and mistakes by well-intentioned people who accidentally misroute or otherwise allow unauthorized access to data.

Keeping Penn's networks and data secure depends on a multi-layered approach. One key aspect is that all members of the Penn community adhere to the security standards in this policy.

Non-compliance with this policy poses a 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 loss of privacy may result, together with possible 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.

Confidential University Data includes

Sensitive Personally Identifiable Information

Information relating to an individual that reasonably identifies the individual and, if compromised, could cause significant harm to that individual or to Penn. Examples may include, but are not limited to, Social Security numbers, credit card numbers, bank account information, student grades or disciplinary information, salary or employee performance information, donations, patient health information, information Penn has promised to keep confidential, and account passwords or encryption keys used to protect access to confidential University data.

Proprietary Information

Data, information, or intellectual property in which the University has an exclusive legal interest or ownership right, which, if compromised, could cause significant harm to Penn. Examples may include, but are not limited to, business planning, financial information, trade secrets, copyrighted material, and software, or comparable material from a third party when the University has agreed to keep such material confidential.

Other data

Other data whose disclosure would cause significant harm to Penn or its constituents.

Critical Component

A critical component is a host or application which, if compromised, could significantly harm the University. Examples of significant harm could include legal liability, reputational damage, interruption of critical business functions, and disclosure of confidential information.

Key recovery

A special feature of a key management scheme that allows data to be decrypted by an authorized party even if the original key is lost.

Operational Data

Data whose loss or corruption would impair the academic, administrative, or research functions of the University, or result in a significant business or financial risk or a significant legal risk or liability.

PennNet Demarcation Point

PennNet wallplate or as defined in specific customer service level agreements.

Personal Digital Assistant (PDA)

A hand-held electronic organizer that has the capability of accessing, storing, and/or transmitting data. PDAs may or may not be managed by a server for the purpose of "push" of data and/or policies. They may be owned by an individual or by the University.

Portable Computing Devices, Storage Devices, and Media

Laptops, PDAs, devices with built-in storage (e.g. video camera, MP3 player), removable media (e.g. memory cards, USB flash drives), and media such as CDs, DVDs, and tapes.

Qualifying Penn-Owned Computers:

Faculty and staff laptop and desktop computers purchased with Penn funds capable of being managed remotely through the installation of a local software agent without disrupting the reliable operation of the system or the business process the system is intended to support.

Scan

The process of inspecting systems, typically over the network, for common vulnerabilities and for common signs of intrusion. Tools typically used include ISS, Nessus, NeXpose, NMAP, and Scanline.

Security Liaison

An individual appointed by a School or Center who is responsible to be aware of major information security policies, programs, and initiatives at Penn, to actively promote security awareness in his or her School or Center, and to serve as a contact person for information security incidents.

Server

A computer used primarily to provide network-based services (e.g. web, file, or email), typically for use by multiple users.

Storage Devices and Media

Storage devices and media include (but are not limited to) internal hard drives, external drives, printers, and Portable Computing Devices, Storage Devices, and Media as defined above.

Strong Encryption

Encryption which is generally acknowledged by the scientific cryptographic community to resist a cipher-text-only attack given current levels of computer power available to the general hacking community.

Strong Password

One that will resist password cracking attacks and meets the requirements set forth in the Password Selection Rules (see References, below).

System Events

Any event associated with the operation of a computer system or device that can be locally recorded and reported. Common examples include activities associated with: end-user authentication (logons, logoffs, attempts/failures), connection requests, relevant data transfers (remote access, website transactions) and operations and monitoring (enabling or disabling services, equipment failure or malfunction).

The policy applies to:

• All students, faculty, staff, contractors, and their respective agents.

• All devices connected to PennNet, whether they are connected directly to PennNet (i.e. using or associated with a PennNet IP address), or indirectly through another device that is connected to a PennNet demarcation point - this includes computers connected to PennNet via a Virtual Private Network (VPN), but excludes computers connecting via remote desktop control software, e.g. Remote Desktop Protocol (RDP) (see Statement of policy 1).

• All Portable Computing Devices, Storage Devices, and Media that store confidential University data including Penn-owned and personally owned devices, devices used on and off campus, and devices hosted on third-party networks by outside service providers (see Statement of policy 2).

• All servers that store confidential or operational University data, including devices hosted on third-party networks by outside service providers (see Statement of policy 3).

• All email servers on PennNet (see Statement of policy 4).

This policy, once in effect, supersedes the PennNet Computer Security Policy and the Critical PennNet Host Security Policy (see References, below).

1. Basic Requirements for All Devices Connecting to PennNet. 

Each computing device that connects to PennNet must comply with these basic security requirements: 

1. Passwords
   • Passwords must be encrypted in transit and in storage.
   • Where effective technology is available, devices must be protected by strong passwords that are resistant to dictionary attacks. For strong password rules, see the Password Selection Rules in References, below. (For additional guidance on password complexity, see NIST Electronic Authentication Guideline in References, below.)
2. Security Patches. Security patches must be applied on a timely basis. Patches for security vulnerabilities that vendors designate critical must be applied on the following schedule:
   • Servers - immediately or as soon as reasonably practical.
   • Other devices - within two business day of availability or as soon as reasonably practical. In addition to computers, these devices include, but are not limited to, routers, printers, and special purpose devices connected to PennNet.
3. Firewalls. If a device is network connected, and the operating system includes a software firewall, activating it is a minimum requirement in the absence of other mitigating security practices (e.g. disabling unneeded services, use of a hardware firewall).
4. Antivirus protection. For operating systems for which Penn supports or recommends antivirus software (see Supported Computing Products in References, below), there must be a regular program of maintaining current virus signatures and real-time scanning, consistent with software vendor recommendations. For other operating systems or circumstances precluding real-time scanning, equivalent compensating controls must be in place.
5. Centralized Endpoint Management. Qualifying 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. Administrators of systems must ensure compliance with this requirement working with their local support provider as required. See Endpoint Management Recommendations in References, below.

2. Additional Requirements for Portable Computing Devices, Storage Devices, and Media with Confidential Data 

1. Encryption of Stored Data. Certain types of confidential University data stored on such devices must be protected at rest using strong encryption, with a key recovery component. Such data includes data that (1) by law, requires notifying individuals in the event of a breach - specifically, Social Security numbers, credit or debit card numbers, bank account numbers, and as required under HIPAA and the HITECH Act or (2) sensitive health information (e.g., treatment, diagnosis, test results, and certain care settings that are more sensitive than others). See HIPAA and HITECH Act in References, below.
2. Additional Requirements for PDAs. See Policy on Server-Managed Personal Digital Assistants in References, below.

3. Additional Requirements for Servers with Confidential or Operational Data

1. Management and Support. A regular, full-time University staff member with an IT position designation must serve as the system administrator. The system administrator must be identified, and registered in ISC's Assignments Service. The system administrator must have 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:
   
   1. he or she is registered as a contact in ISC's Assignments Service;
   2. third parties or designated University members have the necessary skills and training to protect University systems and data; and
   3. third parties or designated University members are clearly informed of their obligations to comply with this policy.
   4. For guidance on these duties, contact the local Security Liaison. ISC Information Security has ultimate responsibility for clarifying responsibilities related to managing third parties.
2. Encryption of Data in Transit. The system administrator must configure servers and server backups to encrypt any confidential University data that is transmitted over networks whenever network data encryption is a readily available capability that does not impose undue burden. ISC Information Security shall publish technical interpretations of this requirement (see References, below).
3. Encryption of Social Security Numbers in Transit. See Social Security Number Policy in References, below.
4. Registration and Compliance. The system administrator must ensure that the host or application is properly registered in the Critical Component application, and that the requirements of this policy are met. For instructions on registering components and reporting on existing components, see Critical Component Registration in References, below.
5. Physical Security. Servers must be housed in a locked, physically secure area accessible only by those requiring access.
6. Scanning. ISC will scan or examine servers at least quarterly for common security vulnerabilities. The system administrator must address, and if necessary, correct any serious vulnerabilities - those that allow a remote or local user to gain full privileges on the system - within two business days. Servers located behind hardware firewalls must be scanned from inside the firewall by the system administrator subject to ISC providing and supporting security scanning.
7. Backups and Recoverability. The system administrator must implement a routine program of data backup and regular recovery testing for any servers storing operational data.
8. Disabling Accounts. The system administrator is responsible for ensuring that user accounts are promptly disabled when informed that users no longer require access.
9. Secure Data Deletion. When storage devices or media are to be retired, they must be securely wiped or destroyed first. See Secure Data Deletion in References, below.
10. Central Logging - System administrators (or their designee) must:
    1. Log system events consistent with current Security Logging Guidelines to a central solution selected and supported by their home organization
    2. Periodically review logs for anomalies, with automated real-time alerts configured wherever possible.
    3. Periodically re-assess what events are being logged to ensure they continue to be consistent with current guidance.

4. Additional Requirements for Email Servers

1. Virus protection plan (for email servers) Email servers must have a documented plan to prevent viruses from being either accepted from, or delivered to, users of the email server.

1. Confidential University Data. Data should be maintained in the safest environment consistent with educational, research, service, or operational needs.
   1. In general, data is safest when maintained on secure servers in one instance only.
   2. The proliferation of data on multiple devices, particularly mobile devices, creates additional risk.
   3. Printers that typically are used to print confidential University data should be in locations with restricted physical access.
   4. Physical backups should be stored in locations with restricted physical access.
2. Secure Data Deletion. Data that are no longer necessary for educational, research, service, or operational needs and that need not be retained by law or University policy should be securely deleted once discovered. For recommendations on secure file deletion tools, see Secure Data Deletion in References, below.
3. Configuring New Computers. Most computer systems as shipped by the vendor are very insecure. Steps must be taken by the system administrator at the time of installation and connection to ensure that known vulnerabilities are eliminated and strong passwords required.
4. SPIA. Participate in the University's Security and Privacy Impact Assessment (SPIA) program, which provides a framework and support for inventorying confidential data, assessing risks to data, and identifying appropriate steps to remediate those risks. For additional information see References, below.
5. Managed Computers. For Windows environments, manage all computers in an Active Directory Domain, using Group Policy and Security Templates to push out security policies and IPSEC to block access to unneeded services. Local Administrator accounts should not be permitted.
6. Patch Management. The use of automated patch management tools and antivirus update software is strongly encouraged. For operating systems in wide use on campus (e.g. Windows, Mac OS), it is a low risk to automatically download security patches from the operating system vendor. For servers, untested security patches pose a moderate risk. System administrators are encouraged to test security patches or check that others have done so before applying them.
7. Unneeded Services. Remove or disable unneeded services to reduce the risk of break-in.
8. Stored Passwords. Avoid storing unencrypted private keys and cleartext passwords wherever possible. Some applications permit users to script or store their ID and password. Web browsers and other clients sometimes intercept logins and offer to auto-complete logins by filling in the username and password based on what was typed previously. Such features should be avoided since they expose passwords to theft. For scripted batch processes, special care should be taken to ensure that access to stored credentials is limited to the users and process(es) that need access.
9. Authentication. Configure authenticated services to add a delay (backoff) between failed authentication attempts, or consider locking an account after a set number of failed attempts.
10. Least Privilege Necessary. When end users are permitted to install their own software applications on their computer, security can be undermined. For any computer used to store or access confidential University data, it is good practice to restrict users from installing their own software applications by removing their Administrator privileges. Where technically feasible, use operating system-specific privilege elevation mechanisms (e.g. Microsoft Windows User Account Control).
11. Scanning. System administrators are encouraged to scan their own systems for common security vulnerabilities, assuming they have obtained the necessary authorization from their organizations. Users who may be affected should be notified in advance, since a scan carries risk of disrupting service on a host. See Vulnerability Scanner in References, below.
12. System Administration by Third Parties. Request a SSAE 16 (Statements on Standards for Attestation Engagements No. 16) SOC1 or SOC2 ( Service Organization Control) auditing statement and determine if appropriate and effective security controls are in place. See References below. These reports provide pre-defined, standard benchmarks for controls related to the security, availability, processing integrity, confidentiality, or privacy of a system and its information.
13. Home Computers.  Avoid using insecure home computers shared with other family members to gain remote access to confidential University data. Rather, use a properly secured computer that is not shared with others.
14. Mobile Device Security. For mobile devices with a high replacement cost, such as laptops, or where the ability to prevent theft of data is extremely important, consider using whole disk encryption and software that permits location of the device and secure deletion of the data remotely, should the device be lost or stolen. See Operation Theft Awareness, and Encryption in References, below.
15. Endpoint Management of Additional Devices. Endpoint management tools may be capable of managing additional devices not prescribed in this policy. Where possible these devices should also be managed.

A. Verification:ISC Information Security will use security scanners at least quarterly to scan all registered servers and applications, and will periodically scan other campus devices for security vulnerabilities.
B. Notification: ISC Information Security will report violations of this policy to the primary contact in ISC's Assignments Service, or to the appropriate Security Liaison.
C. Remedy: The remedy may be immediate removal of the device from the network, depending on the severity of the operational impact on PennNet. ISC Information Security shall report non-compliance to local School/Center management and University management. ISC Information Security will offer assistance to the LSP for the area in correcting security problems, after which the device may be reconnected to the network, and/or normal service restored.
D. Financial Implications: The individual, department, or unit owning the device shall bear the costs of ensuring compliance with this policy.
E. Responsibility: For servers, responsibility for compliance lies with the system administrator, or the individual appointed to oversee third party system administrators or designated University members. The system administrator is responsible to make encrypted services available when there is a reasonable expectation that the services are handling or may be used to handle confidential University data. Data custodians are responsible to ensure they are handling confidential University data in compliance with this policy. For all other devices, the individual owner or user of the device is responsible for compliance with this policy. The Office of Audit, Compliance, and Privacy, and the Office of Information Systems and Computing, are available for consultation in connection with this policy.
F. Time Frame:This policy shall be effective three months after final approval for new systems and 12 months after final approval for existing systems. If a school or center security liaison believes that the school or center cannot comply with this timeframe, he or she may petition for an extension under Appeals, below.
G. Enforcement: Following consultation with School/Center IT management and Security Liaisons, ISC Information Security shall publish quarterly to School/Center IT management, the Vice President for Information Systems and Computing, and the Associate Vice President for Audit, Compliance and Privacy, a summary of Schools and Centers not in compliance with this policy based on available information. In addition, the Office of Audit, Compliance and Privacy shall conduct periodic audits. Please see the Policy on Computer Disconnection from PennNet in References, below. Individuals not adhering to the policy may be subject to sanctions as appropriate under Penn policies.
H. Appeals: Requests for waiver from the requirements of this policy are decided by the Vice President for Information Systems and Computing. A waiver granted for the inability to meet one compliance requirement does not exempt the system owner from meeting all other requirements. All waiver requests may be submitted to ISC Information Security.

• Credit Card Sales PCI Compliance Policy: https://www.finance.upenn.edu/sites/default/files/2006%20Sales%20and%20Services%20-%20Credit%20Card%20Sales%20PCI%20Compliance.pdf
• Critical PennNet Host Security Policy: https://www.isc.upenn.edu/ITPC/dhcpserver
• Critical Component Registration: https://www.isc.upenn.edu/security/critcomp
• Endpoint Management Best Practices: https://www.isc.upenn.edu/security/standards#Endpoint-
• HIPAA (Health Insurance Portability and Accountability Act): https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/HIPAA-ACA/index.html
• HITECH Act (Division A, Title XIII, and Division B, Title IV, of the American Recovery and Reinvestment Act of 2009): http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=111_cong_bills&docid=f%3Ah1enr.pdf
• NIST Digital Identity Guidelines: https://pages.nist.gov/800-63-3/
• Operation Theft Awareness: https://www.publicsafety.upenn.edu/safety-initiatives/theft-awareness/
• Password Selection Rules: http://www.upenn.edu/computing/email/pswd_guide.html
• PennNet Computer Security Policy: https://almanac.upenn.edu/archive/volumes/v51/n01/OR-pennNet.html
• Policy on Computer Disconnection from PennNet: http://www.upenn.edu/computing/policy/disconnect.html
• Policy on Server-Managed Personal Digital Assistants: https://www.isc.upenn.edu/ITPC/serverpda
• Requirement for Encryption of Data in Transit: https://www.isc.upenn.edu/ITPC/computersecurity
• Secure Data Disposal Standard: https://www.isc.upenn.edu/security/standards#Secure-Disposal
• Logging Standards: https://www.isc.upenn.edu/security/standards#Logging-
• Security and Privacy Impact Assessment (SPIA): https://www.isc.upenn.edu/security/spia
• Social Security Number Policy: http://www.upenn.edu/almanac/volumes/v54/n16/sspolicy.html
• SSAE-16: http://en.wikipedia.org/wiki/SSAE_16
• Supported Computing Products: https://www.isc.upenn.edu/how-to/current-supported-computing-products
• Vulnerability Scanner: https://www.isc.upenn.edu/vulnerability-scanning-service (limited to authorized users - contact security@isc.upenn.edu)
• Encryption: https://www.isc.upenn.edu/security/encryption

https://www.isc.upenn.edu/ITPC