Approved by President
Effective Date: June 5, 2017
Responsible Division: Business and Finance
Responsible Office:  Compliance and Enterprise Risk Management
Responsible Officer:  Assistant Vice President for Compliance and Enterprise Risk Management

I. Purpose

The primary purpose of this security policy is to establish rules to ensure the protection of cardholder data and to ensure protection of the University’s resources in scope of PCI DSS. The policy assigns responsibility and provides guidelines to protect the University’s cardholder data and cardholder data environment against misuse and/or loss. This document contains the Middle Tennessee State University (MTSU or University) Payment Card Industry Data Security Standard (PCI DSS) information security policy. Detailed standards and processes that support this policy are described in the latest revision of the PCI DSS. This policy has been written to specifically address the security of data used by the Payment Card Industry. Cardholder data must be protected and security controls must conform to PCI DSS. 

II. Introduction

To maintain the ability to accept payment cards, safeguard its payment card customers, and protect its cardholder data environment, MTSU must take adequate security measures. As a result, this information security policy reflects the University’s commitment to comply with the latest applicable PCI DSS, as mandated by its acquiring bank and the payment card brands.

The University can minimize inappropriate exposures, loss, and inappropriate use of cardholder data by complying with PCI DSS, attending to the proper design and control of systems in scope of PCI DSS, and applying sanctions when violations of this security policy occur.

Security is the responsibility of everyone who uses the University’s information technology resources to accept payment cards on its behalf. It is the responsibility of employees, contractors, business partners, and agents of the University. Each party must become familiar with this policy's provisions, and the importance of adhering to it, when using the University’s computers, networks, data, and other resources to accept payment cards. Each party is responsible for reporting any suspected breaches of its terms. As such, all parties authorized to accept payment cards on behalf of the University must adhere to relevant policies and procedures mandated by the Office of Business and Finance, Information Technology Division, and PCI DSS.

III. Scope 

This policy applies to the University’s cardholder data environment, as defined by PCI DSS, and all devices that connect to the cardholder data environment.

Organizations and contractors affiliated with the University are subject to these same definitions and rules when they store, process, or transmit payment card transactions on University property or at a University sponsored event.

IV. Definitions

A.  Acquiring Bank. Also referred to as acquirer, or acquiring, financial institution. Entity that initiates and maintains relationships with merchants for the acceptance of payment cards.

B.  Attestation of Compliance (AOC). The University’s certification that it is eligible to perform, and has performed, the appropriate Self-Assessment Questionnaire. Filed with the University’s acquiring bank.

C. Cardholder. Non-consumer or consumer customer to whom a payment card is issued to or any individual authorized to use the payment card.

D.  Cardholder Data. At a minimum, cardholder data consists of the full primary account number (PAN). Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date, and/or service code.

E.  Cardholder Data Environment. The people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data, including any connected system components.

F.  Merchant. For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos of any of the five (5) members of PCI Security Standards Council (American Express, Discover, JCB, MasterCard, or Visa) as payment for goods and/or services. Note that a merchant that accepts payment cards as payment for goods and/or services can also be a service provider, if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers. For example, an ISP is a merchant that accepts payment cards for monthly billing, but also is a service provider if it hosts merchants as customers.

G.  Primary Account Number (PAN). Also referred to as account number. Unique payment card number (typically for credit or debit cards) that identifies the issuer and the particular cardholder account.

H.  Self-Assessment Questionnaire (SAQ). Tool used by any entity to validate its own compliance with PCI DSS and in filing an AOC.

I.  Sensitive Authentication Data. Security-related information (including, but not limited to, card validation codes/values, full magnetic-stripe data, PINs, and PIN blocks) used to authenticate cardholders and/or authorize payment card transactions.

J.  Service Provider. Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data. This also includes companies that provide services that control, or could impact, the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS, and other services, as well as hosting providers and other entities. Entities such as telecommunications companies, that only provide communication links without access to the application layer of the communication link, are excluded.

V. Security Policy Ownership and Responsibilities

It is the responsibility of the custodians of this policy to publish and disseminate these policies to all relevant system users (including vendors, contractors, and business partners) authorized to accept payment cards on behalf of the University. Also, the custodians must see that the security policy addresses and complies with PCI DSS. This policy document will be reviewed at least annually by the custodians (and any relevant data owners) and updated, as needed, to reflect changes to business objectives or the risk environment.

The Office of Business and Finance and Information Technology Division, as joint custodians of this policy, will administer the following responsibilities:

A.  establish, document, and distribute security policies;

B.  monitor, analyze, and distribute security alerts and information;

C.  establish, document, and distribute security incident response and escalation policies;

D.  administration of user accounts on systems in the cardholder data environment; and

E.  monitor and control all access to cardholder data.

Questions or comments about this policy should be sent to the policy custodians at PCICompliance@mtsu.edu.

VI. University Merchant Requirements

The following outlines general and technical requirements for all merchants who operate on behalf of the University, where applicable:

A.  All merchants that accept payment cards on the University’s behalf must be authorized by the Office of Business and Finance.

B.  All merchants must use processes and technologies approved by the Office of Business and Finance and Information Technology Division.

C.  The University will not process any payment card transactions collected or submitted by unauthorized merchants.

D.  Only authorized merchants may use the University’s resources to accept payment cards.

E.  All merchants must complete annual PCI Compliance training, provided by the Office of Business and Finance.

F.  All merchants must complete the appropriate PCI DSS Self-Assessment Questionnaire (SAQ) and Attestation of Compliance (AOC) and submit both documents to the Office of Business and Finance annually, by the last University working day in January.

G.  The Office of Business and Finance must annually file the appropriate Attestation of Compliance with its acquiring bank on behalf of all merchants, by the last University working day in March.

VII. Build and Maintain a Secure Network

In order to protect cardholder data, it is critical to design and maintain a secure network infrastructure where this data may be electronically processed or transmitted. The University must maintain such a secure network, isolated from all other campus networks. All system components in the cardholder data environment (network hardware, servers, workstations, etc.) must operate in this secure network.

The following technical requirements cover the network infrastructure (hardware such as firewalls, routers, and switches), as well as requirements for the secure configuration of all cardholder data environment system components.

A.  Install and Maintain a Firewall Configuration

All systems must be protected from unauthorized access from untrusted networks, whether entering the system via the internet as e-commerce, employee internet access through desktop browsers, employee email access, dedicated connections such as business-to-business connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.

1. Firewall/Router Configuration Documentation

The University will have documented firewall/router configuration standards that include the following:

a.  A formal process, consisting of a work order in the central IT work order system, for approving and testing all network connections and changes to the firewall and router configurations. PCI DSS Requirement 1.1.1.

b.  Current network diagrams, which must be updated after any change to the network or cardholder data environment, with all connections to cardholder data, including any wireless networks. PCI DSS Requirement 1.1.2.

c.  Firewalls present between each public network segment, including the internet or any other University out-of-scope intranet segments, and the cardholder data environment. PCI DSS Requirement 1.1.3.

d.  Firewall configuration documentation containing the groups and/or individuals responsible for logical management of the firewalls/routers. PCI DSS Requirement 1.1.4.

e.  Firewall configuration documentation containing a detailed list of inbound and outbound services, protocols, and ports required for daily business. This list must contain a description and justification for use of the required services, protocols, and ports on all firewall interfaces. PCI DSS Requirement 1.1.5.

f.  Firewall and router rule sets reviewed at least every six (6) months. PCI DSS Requirement 1.1.6.

2.  Restrict Connections between Untrusted Network Segments and the Cardholder Data Environment

The University will restrict connections from untrusted network segments to system components within the cardholder data environment by doing the following:

a.  Building and maintaining firewall rules to limit all inbound and outbound traffic to/from the cardholder data environment to only those sites required for business as determined by the Office of Business and Finance and Information Technology Division. PCI DSS Requirement 1.2.1.a.

b.  Building and maintaining firewall rules to explicitly deny all other inbound and outbound traffic. PCI DSS Requirement 1.2.1.b.

c.  Verifying router configuration files are secure and synchronized (i.e., running configuration files and startup configuration files have the same, secure configuration). PCI DSS Requirement 1.2.2.

d.  Requiring a firewall between any wireless network and the cardholder data environment. Firewall rules must prohibit insecure traffic and restrict traffic from the wireless segment to only that which is required for business. PCI DSS Requirement 1.2.3.

3.  Prohibit Direct Public Access between the Internet and the Cardholder Data Environment

The University will prohibit direct public access between the internet and any system component in the cardholder data environment by doing the following:

a.  Verifying a DMZ is implemented to limit inbound traffic to system components that provide authorized publicly accessible services, protocols, and ports. PCI DSS Requirement 1.3.1.

b.  Limiting inbound internet traffic to IP addresses within the DMZ. PCI DSS Requirement 1.3.2.

c.  Prohibiting direct network routes (inbound or outbound) between the internet and the cardholder data environment. PCI DSS Requirement 1.3.3.

d.  Prohibiting internal IP addresses (i.e., RFC 1918 address ranges) to pass from the internet into the cardholder data environment. PCI DSS Requirement 1.3.4.

e.  Verifying that outbound traffic from the cardholder data environment to the internet is explicitly authorized. PCI DSS Requirement 1.3.5.

f.  Verifying use of firewall hardware that implements stateful inspection, also known as dynamic packet filtering (only established connections should be allowed in and only if they are associated with a previously established session). PCI DSS Requirement 1.3.6.

g.  Verifying that system components that store cardholder data are on an internal network zone, segregated from the DMZ and other untrusted networks. PCI DSS Requirement 1.3.7.

h.  Preventing disclosure of private IP addresses and routing information from internal networks to the internet using technologies such as NAT, PAT, RFC 1918 address space, etc. PCI DSS Requirement 1.3.8.a.

i.  Verifying disclosure of private IP addresses and routing information to external entities is authorized. PCI DSS Requirement 1.3.8.b.

4.  Personal Firewall Required on Mobile Computers

a.  Personal firewalls must be installed and active on all mobile and/or employee-owned computers with direct connectivity to the internet (i.e., laptops used by employees), and which are used to access the cardholder data environment. PCI DSS Requirement 1.4.a.

b.  Personal firewall software must be configured by the University to its specified standards and must not be alterable by mobile computer users. PCI DSS Requirement 1.4.b.

B.  Change Vendor Supplied Defaults

The University’s general policy is to always change vendor-supplied defaults for system passwords or other security parameters before systems are installed in the cardholder data environment.

Individuals with malicious intent (external and internal to an organization) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determined via public information.

1.  Change Vendor Supplied Defaults

a.  All vendor-supplied defaults must be changed on all system components before being used in the cardholder data environment. (i.e., passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts, etc.) PCI DSS Requirement 2.1.

b.  The University prohibits processing payment card transactions using WiFi.

2.  Develop Configuration Standards

a.  Develop configuration standards for all system components. Assure that these standards address all known vulnerabilities and are consistent with industry-accepted system hardening standards. PCI DSS Requirement 2.2.

b.  Implement only one (1) primary function per server to prevent functions that require different security levels from co-existing on the same server. PCI DSS Requirement 2.2.1.

c.  Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. PCI DSS Requirement 2.2.2.

d.  Configure system security parameters to prevent misuse. PCI DSS Requirement 2.2.3.

e.  Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers. PCI DSS Requirement 2.2.4.

3.  Encrypt All Non-console Administrative Access Using Strong Cryptography. Strong cryptography must be used for any non-console and/or web-based management interface used for administration of systems and/or system components. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access.  PCI DSS Requirement 2.3.

VIII. Protect Cardholder Data

Cardholder data must be protected. To mitigate the risk of unauthorized access, the University prohibits electronic storage of cardholder data. When required, merchants may store paper cardholder data per the following:

A.  Protect Stored Cardholder Data

1.   Minimize Stored Cardholder Data

a.  The University prohibits electronic storage of cardholder data such as the Primary Account Number (PAN).

b.  Only store paper cardholder data in a secure location if necessary for business purposes and then securely destroy such physical copies after authorizing transactions. The Office of Business and Finance must approve storage of paper cardholder data.

2.  Do Not Store Sensitive Authentication Data. Never store sensitive authentication data after authorization, even if encrypted. Sensitive Authentication Data includes card verification codes/values, magnetic-stripe data, PINs, and PIN blocks. PCI DSS Requirement 3.2.

3.  Mask Primary Account Number (PAN) When Displayed

a.  Mask PAN when displayed. Tthe first six (6) or last four (4) digits are the maximum number of digits to be displayed. PCI DSS Requirement 3.3.

b.  This requirement does not apply to employees and other parties with a legitimate business need to see the full PAN.

c.  This requirement does not supersede stricter requirements in place for displays of cardholder data (i.e., point-of-sale receipts).

B.  Encrypt Transmission of Cardholder Data Over Open, Public Networks

Cardholder data must be encrypted during transmission over networks that are easily accessed by individuals with malicious intent. Improperly configured wireless networks and vulnerabilities in legacy encryption and authentication protocols can be continued targets of individuals with malicious intent who exploit these vulnerabilities to gain privileged access to cardholder data environments.

Note transmission of encrypted cardholder data over public networks does not mean transmission via end user messaging, printing, scanning, and faxing, all of which the University prohibits per the following:

1.  Use Strong Cryptography and Security Protocols. Strong encryption algorithms and protocols (i.e., SSL/TLS, IPSEC, SSH, etc.) must be used whenever cardholder data is transmitted or received over open, public networks. PCI DSS Requirement 4.1.

2.  Transmission of Cardholder Data via End User Messaging Technologies

a.  The University prohibits storing, processing, or transmitting cardholder data via end-user messaging technologies (i.e., email, instant messaging, short message service, multimedia messaging service, etc.).

b.  If employees receive unsolicited cardholder data via end-user messaging, they must not process the transaction and permanently delete the original message. Employees must create a new message stating the original transaction did not process and make alternate arrangements to collect payment information (i.e., online or via phone).

3.  Transmission of Cardholder Data via Printing, Faxing, and Scanning

a.  The University prohibits printing, faxing, and scanning of cardholder data.

b.  Printing, faxing, and scanning cardholder data disproportionately increases the University’s PCI scope to include print, fax, document imaging, and email servers and anything connected to such systems.

c.  If employees receive unsolicited cardholder data via fax, they must not process the transaction and instead securely destroy paper faxes with cardholder data per policy. If they receive an unsolicited fax via the University’s fax server, they must permanently delete the associated email. Employees must contact the sender and make alternate arrangements to collect payment information (i.e., online or via phone).

IX. Maintain a Vulnerability Management Program

System components within the cardholder data environment must be part of an active vulnerability maintenance program.  The following requirements ensure system components are protected from malicious software and vulnerabilities that result from software bugs and improperly patched applications and operating systems.

A. Use and Regularly Update Anti-Virus Software or Programs

Malicious software, commonly referred to as malware (icluding viruses, worms, and Trojans) enters a sensitive network segment during many business approved activities including employees’ email and use of the internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats.

1.  Deploy Anti-Virus Software

a.  Anti-virus software must be deployed on all systems in the cardholder data environment commonly affected by malicious software. This includes personal computers, servers, etc. connected to the cardholder data environment. PCI DSS Requirement 5.1.

b.  Anti-virus programs must be capable of detecting, removing, and protecting against all known types of malicious software (adware, spyware, etc.). PCI DSS Requirement 5.1.1.

2.  Regularly Update Anti-Virus Software and Maintain Logs

a.  All anti-virus software and associated definition files must be kept current at all times. PCI DSS Requirement 5.2.a.

b.  The master installation of anti-virus software maintained by the University must be enabled for automatic updates and periodic scans. PCI DSS Requirement 5.2.b.

c.  Systems components must be verified to have anti-virus automatic updates and periodic scans enabled. PCI DSS Requirement 5.2.c.

d.  Anti-virus software log generation must be enabled and logs must be retained for one (1)year in accordance with PCI DSS Requirement 10.7. PCI DSS Requirement 5.2.d.

B.  Develop and Maintain Secure Systems and Applications

Individuals with malicious intent use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities can be fixed by applying vendor-provided security patches. All critical systems must have the most recently released, appropriate software patches to protect against exploitation and compromise of cardholder data by individuals with malicious intent and the use of malicious software.

Note: Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations. For in-house developed applications, the introduction of vulnerabilities can be avoided by using standard system development processes and secure coding techniques.

1.  Install Security Patches Promptly

a.  All cardholder data environment system components and software must have the latest vendor-supplied system security patches installed. PCI DSS Requirement 6.1.

b.  All critical cardholder data environment system and software patches must be installed within 30 days of vendor release. PCI DSS Requirement 6.1.

2.  Identify New Security Vulnerabilities. The University Information Technology Division will establish and maintain a process to identify and assign a risk ranking to newly discovered security vulnerabilities. PCI DSS Requirement 6.2.

3.  The University will not develop or customize payment applications.

X. Implement Strong Access Control Measures 

Access to system components and software within the cardholder data environment must be controlled and restricted to those with a business need for that access. The University achieves this through the use of active access control systems, strong controls on user and password management, and restricting physical access to critical or sensitive components and software to individuals with a need to know.

A.  Restrict Access to Cardholder Data by Business Need to Know

To ensure cardholder data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need-to-know and according to job responsibilities.

Need-to-know refers to when access rights are granted to the least amount of data and privileges needed to perform a job (least privileges model).

1.  Limit Access to Cardholder Data.  Access to cardholder data and system components in the cardholder data environment must be restricted to only those individuals whose job requires such access. PCI DSS Requirement 7.1. Access limitations must include:

a.  Restriction of access rights of privileged user IDs to least privileges necessary to perform job responsibilities. PCI DSS Requirement 7.1.1.

b.  Assignment of privileges based on individual personnel’s job classification and function. PCI DSS Requirement 7.1.2.

c.  Requirement for a documented approval by authorized parties specifying required privileges. PCI DSS Requirement 7.1.3.

d.  Implementation of an automated access control system. PCI DSS Requirement 7.1.4.

2.  Restrict Access to Need to Know. Establish an access control system for systems components in the cardholder data environment with multiple users that restricts access based on a user’s need to know and is set to deny all unless specifically allowed. PCI DSS Requirement 7.2. This access control system must include the following:

a.  Coverage of all system components in the cardholder data environment. PCI DSS Requirement 7.2.1.

b.  Assignment of privileges to individuals based on job classification and function. PCI DSS Requirement 7.2.2.

B.  Assign a Unique ID to Each Person with Computer Access

Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users. The University ensures such accountability by employing the following practices:

Note: These requirements are applicable for all accounts, including point-of-sale accounts with administrative capabilities and all accounts used to view or access cardholder data or to access systems with cardholder data. However, Requirements 8.1, 8.2, and 8.5.8 through 8.5.15 are not intended to apply to user accounts within a point-of-sale payment application that only have access to one card number at a time in order to facilitate a single transaction, such as cashier accounts.

1.  Assign All Users a Unique ID. All users must be assigned a unique ID before allowing them to access systems components in the cardholder data environment or cardholder data. PCI DSS Requirement 8.1.

2. Authenticate All Users. The University must employ at least one (1) of the following methods to authenticate all users: PCI DSS Requirement 8.2.

a.  Something you know, such as a user ID and a password or passphrase;

b.  Something you have, such as a token device or smart card; and/or

c.  Something you are, such as a biometric device.

3.  Incorporate Two (2)-Factor Authentication for Remote Access

a.  The University requires all employees, administrators, and third parties to use two-factor authentication for remote access to the cardholder data environment. PCI DSS Requirement 8.3.

b.  Remote access refers to network-level access originating from outside the Cardholder Data environment.

4.  Encrypt All Passwords. All passwords must be rendered unreadable during transmission and storage on all cardholder data environment system components using strong cryptography. PCI DSS Requirement 8.4.

5.  Ensure Proper User Identification and Authentication Management. The University must ensure proper user identification and authentication management for non-consumer users and administrators on all cardholder data environment system components as follows: PCI DSS Requirement 8.5.

a.  Control addition, deletion, and modification of user ID’s, credentials, and other identifier objects. PCI DSS Requirement 8.5.1.

b.  Verify user identity before performing password resets by phone, email, web, or other non-face-to-face methods. PCI DSS Requirement 8.5.2.

c.  Set passwords for first-time use and resets to a unique value for each user and change immediately after the first (1^st) use. PCI DSS Requirement 8.5.3.

d.  Immediately revoke access for any terminated users. PCI DSS Requirement 8.5.4.

e.  Remove/disable inactive user accounts at least every ninety (90) days. PCI DSS Requirement 8.5.5.

f.  Enable accounts used by vendors for remote access only during the time period needed. Monitor vendor remote access accounts when in use. PCI DSS Requirement 8.5.6.

g.  Communicate authentication procedures and policies to all users who have access to cardholder data. PCI DSS Requirement 8.5.7.

h.  Do not use group, shared, or generic accounts and passwords, or other authentication methods. PCI DSS Requirement 8.5.8.

i.  Change user passwords at least every ninety (90) days. PCI DSS Requirement 8.5.9.

j.  Require a minimum password length of at least seven (7) characters. PCI DSS Requirement 8.5.10.

k.  User passwords containing both numeric and alphanumeric characters. PCI DSS Requirement 8.5.11.

l.  Do not allow an individual to submit a new password that is the same as any of the last four (4) passwords he/she has used. PCI DSS Requirement 8.5.12.

m.  Limit repeated access attempts by locking out the user ID after not more than six (6) attempts. PCI DSS Requirement 8.5.13.

n.  Set the lockout duration to a minimum of thirty (30) minutes or until an administrator enables the user ID. PCI DSS Requirement 8.5.14.

o.  If a session has been idle for more than fifteen (15) minutes, require the user to re-authenticate to re-activate the terminal or session. PCI DSS Requirement 8.5.15.

C.  Restrict Physical Access to Cardholder Data

Any physical access to cardholder data or systems within the cardholder data environment provides the opportunity for individuals to access devices, data, systems, or hardcopies and should be appropriately restricted. The University must mitigate such risk using the following controls:

1.  Use Facility Entry Controls. Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment as follows: PCI DSS Requirement 9.1.

a.  Use video cameras and/or access control mechanisms to monitor individual physical access to sensitive areas. Review collected data and correlate with other entries. Store video for at least three months, unless otherwise restricted by law. PCI DSS Requirement 9.1.1. Note: Sensitive areas refers to any data center, server room or any area that houses systems that store, process, or transmit cardholder data. This excludes the areas where only point-of-sale terminals are present, such as the cashier areas in the Bursar’s Office.

b.  Restrict physical access to publicly accessible network jacks. For example, areas accessible to visitors should not have network ports enabled unless network access is explicitly authorized. PCI DSS Requirement 9.1.2.

c.  Restrict physical access to wireless access points, gateways, handheld devices, networking/communications hardware, and telecommunication lines. PCI DSS Requirement 9.1.3.

2.  Use Employee Identification

a.  Develop procedures to easily distinguish between onsite personnel and visitors, especially in areas where cardholder data is accessible. PCI DSS Requirement 9.2.

b.  Review processes and procedures for assigning badges to onsite personnel and visitors, and verify these processes include granting new badges, changing access requirements, and revoking terminated onsite personnel and expired visitor badges. PCI DSS Requirement 9.2.a.

c.  Verify that access to the badge systems is limited to authorized personnel. PCI DSS Requirement 9.2.b.

d.  Examine badges in use to verify that they clearly identify visitors and it is easy to distinguish between onsite personnel and visitors. PCI DSS Requirement 9.2.c.

3.  Badge All Visitors. All visitors must be handled as follows: PCI DSS Requirement 9.3.

a.  Authorized before entering areas where cardholder data is processed or maintained. PCI DSS Requirement 9.3.1.

b.  Given a physical token (for example, a badge or access device) that expires and that identifies the visitors as not onsite personnel. PCI DSS Requirement 9.3.2.

c.  Asked to surrender the physical token before leaving the facility or at the date of expiration. PCI DSS Requirement 9.3.3.

4.  Use a Visitor Log. Use a visitor log to maintain a physical audit trail of visitor (i.e., any person whether University employee or vendor without access permission) activity. Document the visitor’s name, the firm represented, and the onsite personnel authorizing physical access on the log. Retain this log for a minimum of three (3) months, unless otherwise restricted by law. PCI DSS Requirement 9.4.

5.  Store Paper Cardholder Data in a Secure Location. Store paper cardholder data in a secure location, preferably an off-site facility, such as an alternate or back-up site, or commercial storage facility. Review the location’s security at least annually. PCI DSS Requirement 9.5.

6. Physically Secure All Paper Cardholder Data. All stored paper cardholder data approved by the Office of Business and Finance must be stored in a locked enclosure, such as a locked drawer, locked box, or safe. Only employees with a business need to access paper cardholder data will have access to such locked enclosures

7.  Maintain Strict Control over Paper Cardholder Data Distribution. Maintain strict control over the internal or external distribution of any paper cardholder data, including the following: PCI DSS Requirement 9.7.

a.  Classify paper cardholder data so the sensitivity of the data can be determined. PCI DSS Requirement 9.7.1.

b.  Send the paper cardholder data by secured courier or other delivery method that can be accurately tracked. PCI DSS Requirement 9.7.2.

8.  Require Management Approval to Move Paper Cardholder Data. Employees must maintain logs documenting management approval prior to moving paper cardholder data. PCI DSS Requirement 9.7.1.

9.  Maintain Strict Control over Paper Cardholder Data Storage and Accessibility. Properly maintain inventory logs of all paper cardholder data and conduct media inventories at least annually. PCI DSS Requirement 9.9.1.

10.  Destroy Paper Cardholder Data When No Longer Needed. Destroy paper cardholder when no longer needed for business or legal reasons as follows: PCI DSS Requirement 9.10.

a.  Shred, incinerate, or pulp hardcopy materials so that cardholder data cannot be reconstructed. PCI DSS Requirement 9.10.1.

b.  Verify hardcopy materials are crosscut shredded, incinerated, or pulped such that there is reasonable assurance they cannot be reconstructed. PCI DSS Requirement 9.10.1.a.

XI. Regularly Monitor and Test Networks

Important components of overall system security for the cardholder data environment are the regular testing of networks for exposed vulnerabilities and the continuous monitoring of security indicators (logs, system events, etc.). The University must address system monitoring and vulnerability testing using the following policies:

A.  Track and Monitor Access to Network Resources and Cardholder Data

Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs, and the University will maintain such logs according to the following:

1.  Establish an Audit Process. Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user. PCI DSS Requirement 10.1.

2.  Implement User-Based Auditing. Implement automated audit trails for all system components to reconstruct the following events: PCI DSS Requirement 10.2.

a.  All individual accesses to cardholder data. PCI DSS Requirement 10.2.1.

b.  All actions taken by any individual with root or administrative privileges. PCI DSS Requirement 10.2.2.

c.  Access to audit trails. PCI DSS Requirement 10.2.3.

d.  Invalid logical access attempts. PCI DSS Requirement 10.2.4.

e.  Use of identification and authentication mechanisms. PCI DSS Requirement 10.2.5.

f.  Initialization of the audit logs. PCI DSS Requirement 10.2.6.

g.  Creation and deletion of system-level objects. PCI DSS Requirement 10.2.7.

3.  Log System Events. Record at least the following audit trail entries for all system components for each event: PCI DSS Requirement 10.3.

a.  User identification. PCI DSS Requirement 10.3.1.

b.  Type of event. PCI DSS Requirement 10.3.2.

c.  Date and time. PCI DSS Requirement 10.3.3.

d.  Success or failure indication. PCI DSS Requirement 10.3.4.

e.  Origination of event. PCI DSS Requirement 10.3.5.

f.  Identity or name of affected data, system component, or resource. PCI DSS Requirement 10.3.6.

4.  Synchronize System Clocks. Using time-synchronization technology (i.e., network time protocol), synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time: PCI DSS Requirement 10.4.

a.  Critical systems have the correct and consistent time. PCI DSS Requirement 4.1.

b.  Time data is protected. PCI DSS Requirement 4.2.

c.  Time settings are received from industry-accepted time sources. PCI DSS Requirement 4.3.

5.  Secure Audit Trails

a.  Secure audit trails so they cannot be altered. PCI DSS Requirement 10.5.

b.  Limit viewing of audit trails to those with a job-related need. PCI DSS Requirement 10.5.1.

c.  Protect audit trail files from unauthorized modifications. PCI DSS Requirement 10.5.2.

d.  Promptly back up audit trail files to a centralized log server or media that is difficult to alter. PCI DSS Requirement 10.5.3.

e.  Write logs for external facing technologies onto a log server on the internal LAN. PCI DSS Requirement 10.5.4.

f.  Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed with generating alerts (although new data being added should not cause an alert). PCI DSS Requirement 10.5.5.

6.  Review Audit Logs Daily. Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion-detection systems (IDS) and authentication, authorization, and accounting protocol (AAA) servers (i.e., RADIUS). PCI DSS Requirement 10.6. Note: Log harvesting, parsing, and alerting tools may be used to meet compliance with Requirement 10.6.

7.  Retain  Audit Trail History. Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (i.e., online, archived, or restored from back-up). PCI DSS Requirement 10.7.

B.  Regularly Test Security Systems and Processes. Vulnerabilities are being discovered continually by malicious individuals and researchers and introduced by new software. Cardholder data environment system components, processes, and custom software must be tested frequently to ensure security controls continue to reflect a changing environment.

1.  Rogue Wireless Network Detection. The Information Technology Division must test for the presence of wireless access points and detect unauthorized wireless access points on a quarterly basis using Enterasys wireless detection sensors. PCI DSS Requirement 11.1.

2.  Perform Internal and External Vulnerability Scans Quarterly

a.  Internal vulnerability assessment scans must be performed by the Information Technology Division at least quarterly and after any significant change in the cardholder data environment (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades). PCI DSS Requirement 11.2.1.

b.  External vulnerability scans must be performed at least quarterly by an Approved Scanning Vendor (ASV), approved by the Payment Card Industry Security Standards Council (PCI SSC). Scans must be run on all external IP addresses that could be used to gain access to the cardholder data environment. PCI DSS Requirement 11.2.2.

c.  Systems failing a vulnerability assessment scan (either internal or external) are to be remediated and retested until a passing scan is achieved. PCI DSS Requirement 11.2.

d.  Results of each quarter’s internal and external vulnerability assessments are to be documented and retained for review by the Office of Business and Finance and Information Technology Division. PCI DSS Requirement 11.2.

e.  The Information Technology Division must perform internal and external scans after any significant change. PCI DSS Requirement 11.2.3. Note: Scans conducted after changes may be performed by internal staff.

3.  Perform Internal and External Penetration Testing. Perform external and internal penetration testing at least once a year and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade or a sub-network or web server added to the environment). These penetration tests must include the following: PCI DSS Requirement 11.3.

a.  Network-layer penetration tests. PCI DSS Requirement 11.3.1.

b.  Application-layer penetration tests. PCI DSS Requirement 11.3.2.

4.  Use IDS and IPS. Use intrusion-detection systems and/or intrusion-prevention systems to monitor all traffic at the perimeter of, as well as at, critical points inside the cardholder data environment and alert personnel to suspected compromises. Keep all intrusion detection and prevention engines, baselines, and signatures up-to-date. PCI DSS Requirement 11.4.

5.  Deploy File Integrity Monitoring. Deploy file-integrity monitoring tools to alert personnel to unauthorized modification of critical system files, configuration files, or content files. Configure the software to perform critical file comparisons at least weekly. PCI DSS Requirement 11.5. Note: For file-integrity monitoring purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. File-integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is, the merchant or service provider).

XII. Maintain an Information Security Policy

Without strong security policies and procedures, many layers of security controls become ineffective at preventing data breaches.  Unless consistent policies and practices are adopted and followed at all times, security controls break down due to inattention and poor maintenance. The following policies address maintaining the University’s payment card security policies described above:

A.  Maintain an Information Security Policy for Employees

A strong security policy sets the security tone for the University and informs employees what is expected of them. All employees should be aware of the sensitivity of data and their responsibilities for protecting it.

Note: Employees refers to full-time and part-time employees, temporary employees and personnel, and contractors and consultants who are resident on the University’s site or otherwise have access to the cardholder data environment.

1.  Implement an Information Security Policy. The University must establish, publish, maintain, and disseminate a security policy that accomplished the following:

a.  Addresses all PCI DSS requirements. PCI DSS Requirement 12.1.1.

b.  Includes an annual process that identifies threats and vulnerabilities and results in a formal risk assessment. PCI DSS Requirement 12.1.2.

c.  Includes a review at least annually and updates when the environment changes. PCI DSS Requirement 12.1.3.

2.  Develop PCI DSS Operational Procedures. The University must develop daily operational security procedures that are consistent with the requirements in this specification (i.e., user account maintenance procedures and log review procedures). PCI DSS Requirement 12.2.

3.  Develop Usage Policies for Critical Technologies. The University must develop usage policies for critical technologies (i.e., remote access technologies, wireless technologies, removable electronic media, laptops, tablets, personal data/digital assistants (PDA’s), email usage and Internet usage) and define proper use of these technologies. The University must ensure these usage policies require the following: PCI DSS Requirement 12.3.

a.  Explicit approval by authorized parties. PCI DSS Requirement 12.3.1.

b.  Authentication for use of the technology. PCI DSS Requirement 12.3.2.

c.  A list of devices and personnel with access. PCI DSS Requirement 12.3.3.

d.  Labeling of devices to determine the owner, contact information, and purpose. PCI DSS Requirement 12.3.4.

e.  Acceptable uses of the technology. PCI DSS Requirement 12.3.5.

f.  Acceptable network locations for the technologies. PCI DSS Requirement 12.3.6.

g.  List of University-approved products. PCI DSS Requirement 12.3.7.

h.  Automatic disconnect of sessions for remote-access technologies after a specific period of inactivity. PCI DSS Requirement 12.3.8.

i.  Activation of remote-access technologies for vendors and business partners only when needed by vendors and business partners, with immediate deactivation after use. PCI DSS Requirement 12.3.9.

j.  For personnel accessing cardholder data via remote-access technologies, prohibit copy, move, and storage of cardholder data onto local hard drives and removable electronic media, unless explicitly authorized for a defined business need. PCI DSS Requirement 12.3.10.

4.  Define Security Responsibilities. The University must ensure the security policies and procedures clearly define information security responsibilities for all personnel. PCI DSS Requirement 12.4.

5.  Assign Security Management Responsibilities. The University must assign an individual or team the following information security management responsibilities: PCI DSS Requirement 12.5.

a.  Establish, document, and distribute security policies and procedures. PCI DSS Requirement 12.5.1.

b.  Monitor and analyze security alerts and information, and distribute to appropriate personnel. PCI DSS Requirement 12.5.2.

c.  Establish, document, and distribute security incident response and escalation procedures to ensure timely and effective handling of all situations. PCI DSS Requirement 12.5.3.

d.  Administer user accounts, including additions, deletions, and modifications. PCI DSS Requirement 12.5.4.

e.  Monitor and control all access to data. PCI DSS Requirement 12.5.5.

6.  Implement a Security Awareness Program. The University must implement a formal security awareness program to make all personnel aware of the importance of cardholder data security. The program must include the following: PCI DSS Requirement 12.6.

a.  Educate personnel upon hire and at least annually. PCI DSS Requirement 12.6.1. Note: Methods can vary depending on the role of the personnel and their level of access to cardholder data.

b.  Require personnel to acknowledge at least annually they have read and understood the security policy and procedures. PCI DSS Requirement 12.6.2.

7.  Screen Employees. The University must screen potential personnel prior to hire to minimize the risk of attacks from internal sources. (Examples of background checks include previous employment history, criminal record, credit history, and reference checks.) PCI DSS Requirement 12.7.

8.  Extend PCI DSS to Third Parties. If cardholder data is shared with service providers, the University must maintain and implement policies and procedures to manage service providers, to include the following: PCI DSS Requirement 12.8.

a.  Maintain a list of service providers. PCI DSS Requirement 12.8.1.

b.  Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess. PCI DSS Requirement 12.8.2.

c.  Ensure there is an established process for engaging service providers including proper due diligence prior to engagement. PCI DSS Requirement 12.8.3.

d.  Maintain a program to monitor service providers’ PCI DSS compliance status at least annually. PCI DSS Requirement 12.8.4.

9.  Implement an Incident Response Plan. The University must implement an incident response plan to be prepared to immediately respond to a system breach according to the following: PCI DSS Requirement 12.9.

a.  Create the incident response plan to be implemented in the event of a system breach. Ensure the plan addresses the following, at a minimum: PCI DSS Requirement 12.9.1.

(1)  Roles, responsibilities, and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum.

(2)  Specific incident response procedures.

(3)  Business recovery and continuity procedures.

(4)  Data back-up processes.

(5)  Analysis of legal requirements for reporting compromises.

(6)  Coverage and responses to all critical system components.

(7)  Reference or inclusion of incident response procedures from the payment brands.

b.  Test the plan at least annually. PCI DSS Requirement 12.9.2.

c.  Designate specific personnel to be available on a 24/7 basis to respond to alerts. PCI DSS Requirement 12.9.3.

d.  Provide appropriate training to staff with security breach response responsibilities. PCI DSS Requirement 12.9.4.

e.  Include alerts from intrusion-detection, intrusion-prevention, and file-integrity monitoring systems. PCI DSS Requirement 12.9.5.

f.  Develop a process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments. PCI DSS Requirement 12.9.6.

Forms: none.

Revisions: none.

Last Reviewed: April 2022.

References: Payment Card Industry Data Security Standard.