RUL 08.00.16 – NC State University Security Standards for Sensitive Data and Systems

Authority: Issued by the Vice Chancellor for Information Technology.

History: First Issued: March 25, 2016

Contact: Director of Security & Compliance, OIT 919-513-1194.

1.    Scope
2.    Exception Proces
3.    Definitions
4.    Implementation Timeline
5.    Enforcement
6.    Identification and Authentication
7.    Acceptable Technology Use
8.    Physical Security
9.    Configuration Management
10. Software Development Lifecycle
11. Media Protection
12. Audit and Accountability
13. Contingency Planning
14. External Service Providers
15. Wireless Usage
16. Encryption

S1. Scope

These standards apply to all system components included in or connected to the sensitive data environment (SDE). The SDE is comprised of people, processes and technologies that store, process, or transmit sensitive (“purple” or “red”) University data (See definition in S3. ). System components may include, but are not limited to:

● Systems that provide security services (for example, authentication servers), facilitate segmentation (for example, internal firewalls), or may impact the security of (for example, name resolution or web redirection) the SDE.

● Virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors.

● Network components including but not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances.

● Server types including but not limited to web, application, database, authentication, mail, proxy, Network Time Protocol (NTP), and Domain Name System (DNS).

● Applications including all purchased and custom applications, including internal and external (for example, Internet) applications.

● Any other component or device located within or connected to the SDE.

NC State University REG 08.00.02 – Computer Use Regulation requires authorized users to take appropriate security precautions to protect and secure data residing in or on assigned university accounts or other university and non-university IT Resources. IT Resources include, but are not limited to, University machines, systems or storage devices, or non-university machines, systems or storage devices that may contain the University’s records/data. In order to comply with REG 08.00.02-Computer Use Regulation and ensure appropriate security protections are in place, NC State University has adopted the following Rule which all users, System Administrators, Data Trustees, Data Stewards, and/or Data Custodians (including third party service providers) are required to follow.

S2. Exception Process

Any exceptions to these standards must be reviewed by Office of Information Technology (OIT) Security & Compliance (S&C). S&C may consult with appropriate data stewards in determining if an exception can be granted. Exception requests should clearly document the reason the standard cannot be implemented (e.g., a technical limitation), as well as appropriate compensating controls that will be put in place to achieve the security goal of the standard.

S3. Definitions

Cardholder Data Environment (CDE) – The SDE (sensitive data environment) used primarily for sensitive credit card-related data.

Connected Systems – All systems that can directly affect sensitive data within the SDE.

Remote Administration – System administration from outside the SDE.

Sensitive Data – All data classified as “purple” or “red.” See Determining the sensitivity level for Shared Data to assess your data classification.

Sensitive Systems – All systems that store, process, or transmit sensitive data.

Sensitive Data Environment (SDE) – Collection of computer systems and associated infrastructure devices, facilities, and people that support the storage, processing, or transmission of sensitive data.

S4. Implementation Timeline

Data stewards and/or custodians or their delegates should immediately begin implementing controls to ensure compliance with this standard where possible. However, multiple operational changes, processes and tools need to be identified and implemented to support overall university compliance. As such, OIT Security & Compliance will develop an implementation timeline for this standard by December 31, 2016 and communicate to appropriate stakeholders. Following the development of the implementation plan, the necessary processes and tools to support university-wide compliance will be identified and implemented accordingly.

S5. Enforcement

NC State University REG 08.00.02 – Computer Use Regulation requires authorized users to take appropriate security precautions to protect and secure data residing in or on assigned university accounts or other university and non-university IT Resources. IT Resources include, but are not limited to, University machines, systems or storage devices, or non-university machines, systems or storage devices that may contain the University’s records/data. In order to comply with REG 08.00.02-Computer Use Regulation and ensure appropriate security protections are in place, NC State University has adopted this Rule which all users, System Administrators, Data Trustees, Data Steward , and/or Data Custodians (including third-party service providers) are required to follow.

S6. Identification and Authentication

S6.1. Purpose

Section 6 outlines requirements for all accounts, whether user or system administrator, with access to the SDE.

S6.2. Scope

Section 6 applies to all non-consumer users or system administrators with access to the SDE or connected systems. System accounts are considered Special IDs. Special IDs are not subject to password change rules such as password change frequency and account lockout. See the Data Sensitivity Framework for examples of sensitive data elements.

S6.3. Standard Details

S6.3.1. Privileged Technical, Functional, and End User Access Management

S6.3.1.1. An access control system must be in place.

S6.3.1.2. Access to data must be restricted on a least privilege and “need to know” basis.

S6.3.1.3. Authorization for access to data must be approved by the appropriateData Steward or his/her delegate.

S6.3.2. Identification and Authorization

S6.3.2.1. User accounts must use unique identifiers.

S6.3.2.2. Group or shared accounts must not be used.

S6.3.2.3. User identity must be verified prior to both allowing access and permitting the identity to make any additions, deletions or modifications.

S6.3.3. Password Management

All account passwords must adhere to the Password Standard.

S6.3.4. Account Management

S6.3.4.1. Users must acknowledge understanding of privilege levels and security roles annually.

S6.3.4.2. All user accounts must be disabled after not more than six failed login attempts. Automatic re-enable after 30 minutes is acceptable where supported.

S6.3.4.3. Vendor accounts must only be enabled when needed and disabled immediately after use. (See Section S7.3.1.4.)

S6.3.5. Access Termination

A process must exist to immediately disable and/or remove accounts that are no longer needed. Periodic review of user account privileges must be performed according to the schedule in Table 1 below. The account review consists of system owner and/or management evaluation of user accounts to determine if they are still needed and have the appropriate access.

Table 1.
Security Requirement	User Accounts Reviewed	Inactive Accounts Disabled
CDE and Connected Systems	90 days	90 days
Other SDE and Connected Systems	90 days	90 days

S7. Acceptable Technology Use

S7.1. Purpose

REG 08.00.02 – Computer Use Regulation and POL 08.00.01 – Computer Use Policy provide overall requirements for acceptable use of computing resources at NC State. The purpose of Section 7 is to detail acceptable use of university information technology (IT) resources within SDEs and Connected Systems.

S7.2. Scope

Section 7 applies to all systems within the SDE or connected systems. Section 7 applies to any individuals who will be accessing any systems or devices with the SDE or connected systems, without exception.

S7.3. Standard Details

S7.3.1. Security of Sensitive Information

S7.3.1.1. An inventory of hardware and software shall be maintained and kept up to date.

S7.3.1.2. All sensitive data processing shall be performed within the SDE.

S7.3.1.3. Copying, moving or storage of sensitive data to unauthorized systems is prohibited.

S7.3.1.4. Vendor access to systems within the SDE or connected systems shall only be enabled when needed and immediately disabled after use.

S7.3.1.5. Unencrypted sensitive data may not be sent through unsecure messaging systems such as email or instant messaging (IM).

S7.3.1.6. Password management must adhere to the NC State UniversityPassword Standard, with SDE privileged users considered A4/P4.

S7.3.1.7. All computing devices that have security logging capabilities must have sufficient OS level auditing turned on to facilitate tracking of user accounts in the event of a security breach or other events.

S7.3.1.8. University-approved anti-virus software must be installed and definitions kept up to date for all computers within the SDE or connected systems.

S7.3.1.9. All computing devices in the SDE or connected systems must be logically identified and/or labeled, defining owner, contact information, and purpose.

S7.3.2. Approval to Use Technology

Written approval must be obtained from relevant Data Stewards or their delegates, after consultation with OIT Security & Compliance, before the use of any technology that stores, processes or transmits sensitive data. Disagreements between data stewards must be addressed according to the REG 08.00.03 – Data Management Procedures Section 3.1.3.

S7.3.3. Usage Standards for Specific Technologies

S7.3.3.1 Devices

All network devices, operating systems, applications, databases, remote access technologies, wireless technologies, desktops, mobile devices (such as laptops, cell phones, or tablets) within the SDE:

S7.3.3.1.1. Must be configured and used according to business needs.

S7.3.3.1.2. Must be appropriately hardened and secured in accordance with university standards and industry best practices for applicable business requirements.

S7.3.3.1.3. Shall not be added to or removed from the SDE, or modified (See Section S9.3.2.4) without approval from the relevant Data Steward(s) after consultation with OIT Security & Compliance.

S7.3.3.1.4. Shall not be installed in the SDE or connected systems without proof of purchase and licensing rights.

S7.3.3.1.5. Shall be used by all users for approved business reasons (e.g. Web browsing is not a typical business use of a SDE server).

S7.3.3.1.6. Users must protect laptops, cell phones and other devices used to store, process or transmit sensitive data from loss or theft. Users must report loss or theft of laptops, cell phones or other devices in accordance with REG 07.40.02 – Reporting Misuse of State Property.

S7.3.3.2. Remote Administration

Remote Administration (See definition in S3) within the SDE or connected systems must be conducted as follows:

S7.3.3.2.1. Automatic disconnect of remote sessions after at least 30 minutes of inactivity.

S7.3.3.2.2. Activation of remote access technologies used by vendors will occur only when needed by vendors.

S7.3.3.2.3. Vendor remote access must be immediately deactivated after use.

S7.3.3.2.4. Users are prohibited from copying, moving, or storing sensitive data to local or removable storage unless they have obtained approval from the relevant Data Steward(s) after consultation with OIT Security & Compliance.

S7.3.3.2.5 Two-factor authentication is required for privileged users to administer the SDE or connected systems.

S7.3.3.3. Connection Activities

S7.3.3.3.1. Connections from the SDE to the Internet must be conducted by means of university-approved technologies and resources only.

S7.3.3.3.2. No insecure ports, protocols or services, such as FTP, Telnet, or HTTP are to be used for communicating with the SDE without documented business justification for their use. (See Section S9.3.1.1.6.)

S7.3.3.4. Management Approval Processes for Technology Use

All technical staff, including but not limited to system administrative users, programmers/developers, end users, and database administrators must obtain approval from the relevant Data Steward(s) or their delegates, after consultation with OIT Security & Compliance, before they are authorized to use any technology in the SDE or connected systems.

S8. Physical Security

S8.1. Purpose

Section 8 outlines the physical and environmental controls required to protect facilities that house systems that store, process, or transmit sensitive data, as well as protection of the systems themselves.

S8.2. Scope

Section 8 applies to all facilities that host systems that store, process, or transmit sensitive university data, and the systems themselves.

S8.3. Standard Details

S8.3.1. Access

All SDE and connected systems equipment must be maintained in a secure environment:

S8.3.1.1. Only authorized personnel may be allowed physical access to the SDE and connected systems facilities and devices.

S8.3.1.2. The SDE and connected systems facilities must control authorized users’ access via lock and key, electronic access device, or other physical security controls that have been approved (refer to REG 04.05.03 – Electronic Security Management System (SMS)), after consultation with OIT Security & Compliance.

S8.3.1.3. Visitors must be badged or given a physical token, such as a visitor pass, that distinguishes

them from employees. This token must expire at the end of the visit. Visitors should be escorted by authorized personnel for the duration of the visit. Visitors without appropriate badging should be escorted out of the facility and the access attempt should be logged or reported to appropriate authorities such as Campus Police.

S8.3.1.4. Physical access to wireless access points, wall outlets, and network devices within the SDE connected systems networks (including virtual networks) shall be restricted.

S8.3.1.5. Unless in use, switch and router ports within the SDE and connected systems networks must be disabled.

S8.3.1.6. Ingress and/or egress logs showing access to the SDE and connected systems facilities must be retained according to REG 01.25.12 – University Record Retention and Disposition Regulation. (See log retention requirements in Sections 12.3.3. and 12.3.4. )

S8.3.1.7. Physically secure all paper and electronic media that contain sensitive data.

S8.3.2. Video Surveillance

S8.3.2.1. All video surveillance, recording, and monitoring must be in compliance with University Rule RUL 05.06.03 Close Circuit Television (CCTV).

S8.3.2.2. Use access control vestibules, cameras or other electronic controls to protect SDE and Connected Systems facilities. Surveillance equipment must monitor entrance and exit points and be protected from tampering or disabling.

S8.3.2.3. OIT Security & Compliance will perform periodic testing to ensure the integrity of the camera system and recordings.

S8.3.2.4. Camera footage shall be retained as shown in the Table 2 below:

Table 2.
Security Requirements	Camera Recording Review Frequency	Camera Recording Storage
PCI-DSS	Monthly	At least 90 days
Other SDE	At least quarterly or ongoing based on risk	At least 90 days

S9. Configuration Management

S9.1. Purpose

Section 9 establishes a baseline security configuration for hardware and operating systems for the SDE and connected systems.

S9.2. Scope

Section 9 applies to all hardware devices and operating systems within the SDE and connected systems.

S9.3. Standard Details

S9.3.1. Documentation

S9.3.1.1. Configurations of the network and system devices for the SDE and connected systems must be standardized and documented, including at a minimum:

S9.3.1.1.1. Addressing all known security vulnerabilities.

S9.3.1.1.2 Documented business justification for any security features implemented to compensate for any insecure services, daemons, or protocols. (See Section S7.3.3.3.2.)

S9.3.1.2. Network and system device documentation details shall include:

S9.3.1.2.1. Primary system user (particularly for end-point systems)

S9.3.1.2.2. Device names

S9.3.1.2.3. IP address(es)

S9.3.1.2.4. MAC addresses where applicable

S9.3.1.2.5. Serial numbers where applicable

S9.3.1.2.6. Description

S9.3.1.2.7. Department, college or unit

S9.3.1.2.8. Personnel responsible for management of the device

S9.3.1.3. Data flow diagrams are required for sensitive data flow within the SDE and connected systems environment, between the SDE and external systems, and between connected systems and other systems.

S9.3.1.4. Network diagrams are required showing separation of traffic between the SDE and connected systems.

S9.3.1.5. All services, protocols and ports allowed must be documented including a justification of business need.

S9.3.1.6. Document the business justification for use of any insecure protocols such as FTP, TFTP, Telnet, etc., including adequate compensating controls for security. (See Section 7.3.3.3.2 and Section 9.3.1.1.2)

S9.3.2. General Configuration Requirements

S9.3.2.1. Insecure vendor defaults (including but not limited to default passwords on operating systems, software providing security services, application and system accounts, and SNMP default community strings) must be changed before installing a system on a network.

S9.3.2.2. System clocks on all equipment must be synchronized to a university time source that has been approved by the relevant Data Steward(s) or their delegates, after consultation with OIT Security & Compliance.

S9.3.2.3. All remote console access shall be encrypted using techniques that have been approved by the relevant Data Steward(s) or their delegates, after consultation with OIT Security & Compliance .

S9.3.2.4. Configuration changes must be made via an appropriate change-management process. Any changes must be documented and dated, tested, and include rollback procedures. (See Section 10.3.2.4 and Section 10.3.2.5)

S9.3.2.5. Enabling only the necessary services, protocols, daemons, etc. required for function of the system.

S9.3.3. Firewalls

SDE and connected systems networks must have stateful packet inspection network firewall, approved by OIT Security & Compliance, installed at all Internet connection points, between SDE and connected systems, and between any non-SDE and connected systems network. Firewalls must be configured as follows:

S9.3.3.1. Deny all incoming traffic with exceptions based upon Security & Compliance review of business requirements.

S9.3.3.2. Deny all outgoing traffic with exceptions based upon OIT Security & Compliance review of business requirements.

S9.3.3.3. Disallow any direct (un-firewalled) traffic between the SDE and Internet.

S9.3.3.4. Disallow any direct (un-firewalled) traffic between the connected systems and Internet.

S9.3.3.5. Allow management access only from verified authorized workstations or console.

S9.3.3.6. Logging must be enabled for all incoming and outgoing connections. (See logging requirements in Section 12.3.3. and 12.3.4.)

S9.3.3.7. Startup configuration images must be synchronized with operational configuration changes.

S9.3.4. Firewall Rules Review

Review of firewall access control lists (ACLs) must be performed jointly by OIT Security & Compliance and owners of SDE and connected systems as follows:

S9.3.4.1. Every six months, SDE and connected systems owners are required to review and certify network firewall ACLs that allow traffic to and from their systems.

S9.3.4.2. OIT Security & Compliance coordinates the semiannual network firewall review and certification process.

S9.3.5. Network Equipment

S9.3.5.1. All connections to the SDE and connected systems must be fully documented, including communication protocols, ports, services, and business justifications.

S9.3.5.2. All network ports not in use by an SDE or connected system device must be disabled.

S9.3.5.3. All SDE and connected system devices must have logging enabled and configured at an appropriate level to meet applicable compliance needs (e.g., PCI DSS, ISO 27002 and NIST 800-53). (See Section 12.3.3 and Section 12.3.4)

S9.3.6. SDE and Connected Systems Servers and Workstations

S9.3.6.1. Servers and workstations within the SDE must be installed and configured according to university guidelines and security industry best practices.

S9.3.6.2. Software installations must be limited to software necessary for the operations of the SDE and connected systems.

S9.3.6.3. Unnecessary protocols and services must be uninstalled, or made non-functional.

S9.3.6.4. A host based firewall must: a) be operational and b) deny all incoming traffic by default unless there is a business reason that has been approved by the relevant Data Steward(s) or their delegates, after consultation with OIT Security & Compliance. (See Section 9.3.3)

S9.3.6.5. File integrity monitoring software must be in place on all SDE and connected systems and be configured for monitoring all access and changes to critical files, such as log files, to detect unauthorized changes. (See Section 12.3.3.5.)

S9.3.6.6. Default Local Administrator and Guest accounts must be disabled if possible. If Local Administrator and Guest accounts cannot be disabled, they must be renamed (if supported) before installing a system on the network.

S9.3.6.7. Sessions that have been idle longer than 30 minutes must require re-input of password to re-enable the session.

S9.3.6.8. Access to the system firmware, e.g. Basic Input/Output System (BIOS) or Extensible Firmware Interface (EFI), must be protected via a password where available.

S9.3.6.9. SDE and connected systems and/or servers must have their security logs forwarded to a university-designated server external to the SDE and connected systems (See the logging requirements in Section 12.3.3. and 12.3.4. )

S9.3.6.10. Operating systems must be installed according to RUL 08.00.14 – System and Software Security Patching Standard.

S9.3.7. Vulnerability Assessments & Penetration Testing

S9.3.7.1. Vulnerability scans must be completed on an ongoing basis and after major changes according to the NCSU Vulnerability Scanning Standard.

S9.3.7.2. Critical vulnerabilities must be addressed in a timely manner according to the RUL 08.00.14 – System and Software Security Patching Standard.

S9.3.7.3. Penetration testing, approved by and coordinated with OIT Security & Compliance, must be performed on an ongoing basis according to the NCSU Vulnerability Scanning Standard. Penetration testing methodology must be documented.

S10. Software Development Lifecycle

S10.1. Purpose

Section 10 outlines the security requirements for any development of application software or Web-based applications that store, process, or transmit sensitive data.

S10.2. Scope

Section 10 applies to all software installed in the SDE and connected systems. Section 10 applies to any individuals who will be accessing any systems or devices with the SDE or connected systems, without exception.

S10.3. Standard Details

S10.3.1. Development Environment for SDE and Connected Systems

S10.3.1.1. Software development must be done in separate development and/or test environments.

S10.3.1.2. Production data may not be used in any development environment without being sanitized and all identifying sensitive data removed.

S10.3.1.3. Test data (e.g., IDs, accounts, data, etc.) must be removed prior to systems and/or software being migrated into production.

S10.3.1.4. Strict separation of duties must be maintained between development and production support staff.

S10.3.1.5. Display of sensitive information within an application must be masked in accordance with applicable requirements in Table 3 below:

Table 3.
Security Requirement	Sensitive Data Element	Masking Requirement
PCI-DSS	Payment Account Number (PAN)	Only the first 6 and/or the last 4 digits of a credit card number may be displayed to appropriate parties
University Requirements	Social Security Numbers (SSNs)	Only the last 4 digits of the SSN may be displayed to appropriate parties

S10.3.1.6. A separate code review for security vulnerabilities must be completed prior to software being placed in the production environment. This review must be carried out or approved by OIT Security & Compliance.

S10.3.1.7. Strict adherence to industry best practices for secure coding is required in all aspects of the development of applications. For web applications development, refer to the NC State University Web Application Secure Development Standard.

S10.3.2. Application Lifecycle

S10.3.2.1. All Web-based applications must be scanned for vulnerabilities both at regular intervals and after any changes according to the schedule in Table 4 below:

Table 4.
Security Requirement	Web-based App Scan Requirement
Web-based apps in the CDE or connected systems under PCI DSS	Annual third-party scan
Web-based apps in other SDEs	Risk-based continuous University Security Scans

S10.3.2.2. When applications are no longer needed, they must be securely removed and all data securely disposed according to REG 01.25.12 – University Record Retention and Disposition Regulation and REG 07.40.01 – Disposal of University Property.

S10.3.2.3. Backups of the system and development software must be securely deleted or removed according to REG 01.25.12 – University Record Retention and Disposition Regulation.

S10.3.2.4. System change control procedures including approvals must be implemented, and changes must be logged. It is strictly prohibited to develop or change production software on production systems without following an approved change management process. (See Section 9.3.2.4)

S10.3.2.5. A rollback procedure must be documented and approved prior to any system change. (See Section 9.3.2.4)

S11. Media Protection

S11.1. Purpose

Section 11 outlines the storage and disposal procedure for all sensitive data. Data must be removed from university systems according to REG 01.25.12 – University Record Retention and Disposition Regulation and and REG 07.40.01 – Disposal of University Property using a method documented in Section 11.3.2 below.

S11.2. Scope

Section 11 applies to all sensitive data stored in systems, temporary files, storage media, or applications stored within the SDE. Section 11 applies to any individuals who will be accessing any systems or devices with the SDE or connected systems, without exception.

S11.3. Standard Details

S11.3.1. Storage

Sensitive information is permitted to be stored as long as there is a legal, regulatory, or business reason. The business need for storage must be documented. Table 5 below shows specific data that may or may not be stored:

Table 5.
Security Requirement	May be Stored but Requires Protection	May NOT be Stored
PCI-DSS	● Primary Account Number (PAN) ● Cardholder Name ● Service Code ● Expiration Date	● Full Magnetic Stripe (Track 1 or 2 data) ● CVV2, CVC2, CID, CAV2 ● PIN / PIN Block ● Pre-authorization data including track, CVV2, and PIN information, will be retained only until completion of the authorization of a transaction ● Storage of cardholder authorization data post-authorization is forbidden
Other Sensitive Data	May be securely stored with documented business justification	N/A

S11.3.2. Disposal

All sensitive data must be destroyed when no longer required by legal, contractual, or business need according to REG 01.25.12 – University Record Retention and Disposition Regulation. This applies to NC State personnel, as well as third party organizations or contractors. Techniques for disposal of data on media are listed below:

S11.3.2.1. Hard disks must be sanitized by an NSA approved method. SeeNSA/CSS Storage Device Sanitization Manual.

S11.3.2.2. Floppy disks must be shredded.

S11.3.2.3. Optical media (CD’s, DVD’s, Blu Ray, etc.) must be shredded.

S11.3.2.4. Other storage devices (USB drives, storage cards, etc.) must be overwritten by an NSA approved method, or otherwise physically destroyed.

S11.3.2.5. Paper must be cross-cut shredded.

S12. Audit and Accountability

S12.1. Purpose

Section 12 outlines the process for logging all actions that occur in the SDE and connected systems: type and scale of logging, appropriate storage, encryption and disposal of logs.

S12.2. Scope

Section 12 applies to all SDE data and connected systems. Section 12 applies to any individuals who will be accessing any systems or devices with the SDE or connected systems, without exception.

S12.3. Standard Details

S12.3.1. General

S12.3.1.1. Logs shall include sufficient level of detail to assist in the reconstruction of any event that takes place in the SDE or connected systems; to be able to respond to the question “Who did what, when?”

S12.3.1.2. Integrity shall be maintained over generated logs. Logs shall be securely acquired and stored so as to avoid tampering.

S12.3.2. What to Log

S12.3.2.1. The following events shall be logged for activities in the SDE or connected systems:

S12.3.2.1.1. Any SDE and connected system access (success or failure)

S12.3.2.1.2. User access to any sensitive data

S12.3.2.1.3. Date and time

S12.3.2.1.4. Type of event

S12.3.2.1.5. Origination

S12.3.2.1.6. Identity of affected data, system or resource

S12.3.2.1.7. All authentication attempts to SDE or connected systems, pass or fail

S12.3.2.1.8. Creation or deletion of system level objects

S12.3.2.1.9. Configuration changes

S12.3.2.1.10. Access and changes to root or kernel system files

S12.3.2.1.11 Access and changes to log files

S12.3.3. Log Storage and Retention

S12.3.3.1. Logs must be retained according to REG 01.25.12 – University Record Retention and Disposition Regulation and applicable compliance requirements specified in Table 6 below.

S12.3.3.2. Logs must be forwarded to the university centralized log management system.

S12.3.3.3. Only designated personnel may access logs.

S12.3.3.4. File integrity monitoring software shall be installed to monitor all access and changes to log files. (See Section 9.3.6.5.)

S12.3.3.5. Periodic audits must be conducted at least quarterly by OIT Security & Compliance to verify the viability of logs.

S12.3.3.6. Logs must be reviewed daily. It is permitted to incorporate software for this purpose. The appropriate triggers and alerts must be set up and tested regularly.

S12.3.4. Log Retention Table

Table 6.
Security Requirement	Retained Offline	Available Online
PCI-DSS for CDE and connected systems	1 year	90 days
NIST 800-53 and ISO 27002 for SDE and connected systems	6 months	90 days

S13. Contingency Planning

S13.1. Purpose

Section 13 outlines the control of all backup subsystems and data involved in the SDE: storage, identification, transport, isolation, encryption and disposal of media utilized in the backup systems. Please refer to REG 04.00.07 – Developing Business Continuity and IT Disaster Recovery Plans for further information.

S13.2. Scope

Section 13 applies to all systems data within the SDE.

S13.3. Standard Details

S13.3.1. Backup Storage

S13.3.1.1. The backup subsystem is identified as part of the SDE. Data on the subsystem must be rendered unreadable at rest. Backups of sensitive data must be completed regularly, and restoration testing must be performed at least annually or in accordance with the system and data availability requirements. Restoration done via normal operations may be considered as proof of restorability.

S13.3.1.2. To comply with PCI-DSS, pre-authorization data including track, CVV2, and PIN information will be retained only until completion of the authorization of a transaction. Storage of cardholder authorization data post-authorization is forbidden.

S13.3.2. Backup Media Control

All media containing sensitive data must be marked as confidential and strict control must be maintained over storage and accessibility of the media. “Strict control” is defined as:

S13.3.2.1. Media must be stored in a designated secure location.

S13.3.2.2. Backup media location access must be limited to those that need access.

S13.3.2.3. All access to the secure media location must be logged.

S13.3.2.4. Backup media facility security must be reviewed at least annually.

S13.3.2.5. OIT Security & Compliance must certify all media couriers and transport mechanisms.

S13.3.2.6. Media must be logged in and out before any transport. Logs must be maintained in accordance with REG 01.25.12 – University Record Retention and Disposition Regulation Full chain of custody documentation must be maintained. (See Section 12.3.3 and Section 12.3.4)

S13.2.3. Backup Media Disposal

All media that is no longer needed or has reached end-of-life must be destroyed or rendered unreadable so that no data may be extracted. (See acceptable destruction techniques in Section 11.3.2) Please refer to REG 07.40.01 – Disposal of University Property.

S14. External Service Providers

S14.1. Purpose

Section 14 outlines the operating and contractual procedures for sharing all sensitive data with a third party.

S14.2. Scope

Section 14 applies to all sensitive university data. Section 14 applies to any individuals who will be accessing any systems or devices with the SDE or connected systems, without exception.

S14.3. Standard

A process must exist for proper due diligence prior to engagement with service providers. Third parties may be contractually required to adhere to applicable security standards as specified by appropriate university security personnel and acknowledge that they are responsible for the security of the sensitive data which they possess. Only the minimum amount of data needed must be shared with third parties. In addition, all interactions with third parties regarding data sharing must be documented and logged.

S15. Wireless Usage

S15.1. Purpose

Section 15 outlines the requirements for using wireless communications to transmit sensitive information.

S15.2. Scope

Section 15 applies to all sensitive data in the SDE. Section 15 applies to all wireless technologies used to transmit data to include but not limited to: IEEE 802.xx wireless, global system for mobile (GSM), and general packet radio service (GPRS). Section 15 applies to any individuals who will be accessing any systems or devices with the SDE or connected systems, without exception.

S15.3. Standard Details

S15.3.1. Usage & Encryption

Communications must utilize industry best practices (example: IEEE 802.11i) to implement strong encryption for authentication and transmission.

S15.3.2. Wireless Accounting

Periodic scanning must verify that no unauthorized devices on wireless networks can access the SDE or connected systems. If scanning is not feasible, a Wireless Intrusion Detection/Protection system may be used. Table 7 below illustrates scanning frequencies by security requirement:

Table 7.
Security Requirement	Frequency to scan for unauthorized wireless networks
CDE and connected systems networks	At least quarterly
Other SDE and connected systems networks	Continuous risk-based

S16. Encryption

S16.1. Purpose

All sensitive electronic data must be protected by encryption techniques that have been approved by the relevant Data Steward(s) or their delegates, after consultation with OIT Security & Compliance. Section 16 applies to the management of encryption keys and application of their use.

S16.2. Scope

Section 16 applies to all sensitive university data. Section 16 applies to any individuals who will be accessing any systems or devices with the SDE or connected systems, without exception.

S16.3. Standard

S16.3.1. Encryption Keys

S16.3.1.1. Strong encryption keys (at least 256-bit) shall be used to protect sensitive data. The following are acceptable algorithms/protocols for encrypting sensitive university data:

S16.3.1.1.1. Advanced Encryption Standard (AES)

S16.3.1.1.2. Proprietary Vendor encryption with approval from the relevant Data Steward(s) or their delegates, after consultation with OIT Security & Compliance. Note: for PCI-DSS, proprietary vendor encryption methods must be approved in the PA-DSS.

S16.3.1.1.3. TLS 1.2

S16.3.1.1.4. IPSEC

S16.3.1.2. Encryption keys must be protected in the following manner:

S16.3.1.2.1. Dual custodianship with the fewest number of custodians.

S16.3.1.2.2. Clear-text images of the keys must be kept locked in a tamper proof manner and in the fewest possible locations and forms.

S16.3.1.2.3. System and audit logs showing access to this data must be retained as defined in Sections S12.3.2, S12.3.3, and S12.3.4 .

S16.3.1.2.4. Retain and manage encryption keys for sensitive data stored on third party systems to prevent unauthorized access by the third party party.

S16.3.1.3.5. Use key escrow for encryption of sensitive data stored at a third party.

S16.3.2. Cryptographic Key Documentation

S16.3.2.1. All processes and procedures for the generation, use and destruction of cryptographic keys must be fully documented.

S16.3.2.2. Key custodians must acknowledge and accept responsibilities of their roles, in writing. See Appendix A – Draft Encryption Key Responsibility Form.

S16.3.3. Encryption Use

S16.3.3.1. All sensitive data, whether at rest or in transit, must be rendered unreadable using techniques such as encryption, truncation, one-way hashing, tokenization, masking, etc.

S16.3.3.2. Tables in databases containing sensitive information must also be protected using techniques listed in S16.3.1.1.

S16.3.3.3. All exchanges of sensitive data between systems and third parties must be strongly encrypted.

S16.3.3.4. Encryption keys must be rotated according to the schedule shown in Table 8 below:

Table 8.
Security Requirement	Encryption Key Rotation Schedule
Credit card under PCI DSS	At least annually
Other SDE data	At least annually

S16.3.4. Encryption Key Destruction

Keys must be destroyed when no longer used or trusted.

Appendix A

Encryption Key Responsibility Form

Employees must protect access to all encryption keys in their custody.

I, ___________________, as an employee of ____________________ hereby agree that I:

1. Have read and understood the policies and procedures associated with key management and agree to comply with them to the best of my ability.

2. Agree to never compromise the security of the keys in my custody by divulging any information about key management practices, related security systems, passwords, or other private information associated with the university’s systems to any unauthorized persons.

3. Agree to immediately report any suspicious activity that may compromise key security, to my direct supervisor and OIT Security & Compliance.

Printed Name:

Title:

Date:

Signature:

Table of Contents