Return to Policies
   Print Policy No: 2022
Return to Policies Print Policy No: 2022
University of South Alabama Logo     
Policy No: 2022
Responsible Office: Information Security
Last Review Date: 02/10/2022
Next Required Review: 02/10/2027
Policy No: 2022
Responsible Office: Information Security
Last Review Date: 02/10/2022
Next Required Review: 02/10/2027

Cardholder Data Environment

1. Purpose

The University of South Alabama (USA) Card Holder Data Environment will be implemented in such a manner to (at a minimum) ensure compliance to the Payment Card Industry Data Security Standards or PCI-DSS. These policies describe the technical controls and procedures required by PCI-DSS. These policies apply to all departments, faculty, staff, students, contractors, consultants, temporary, and other workers who:

  • Collect credit or debit card payments on behalf of USA or related foundations;
  • Support and/or maintain systems that store, transmit, or process credit or debit card transactions.

2. Applicability

This policy applies to Academic Affairs, Finance & Administration, Student Affairs, USA Health, Development & Alumni Relations and Athletics Divisions, as well as any employee or personnel who work with computer and system components (any network component, server or application included in or connected to the cardholder data environment) within the cardholder environment and for all computer users indirectly associated with the cardholder environment.

3. Definitions

Anti-virus: A security program that can run on a computer or mobile device that protects the system and data by identifying and stopping the spread of malware on the system.

Attestation of Compliance (AOC): Form used by merchants and service providers to attest to the results of a PCI DSS assessment.

Authentication Mechanisms: Any device that identifies a user with something only the user has, such as a physical security token or smart card.

Cardholder Data (CHD): Any personally identifiable information (PII) associated with a person who has a credit or debit card. Cardholder data includes the primary account number (PAN) along with any of the following data types: cardholder name, expiration date or service code. The term cardholder data is interchangeable with payment card data throughout this policy.

Cardholder Data Environment (CDE): Is a computer system or networked group of IT systems that processes, stores and/or transmits cardholder data or sensitive payment authentication data. A CDE also includes any component that directory connect to or supports this network.

Center for Internet Security (CIS): Global IT community to safeguard public and private organizations against cyber threats.

Common Weakness Enumeration/SysAdmin, Audit, Network and Security (CWE/SANS): Guidelines for dealing with the most critical software vulnerabilities.

Cross-shredding: Cutting into small "particle" pieces that renders the inability to reconstruct the document or media in readable form.

Cryptography: Cryptography involves creating written or generated codes that allow information to be kept secret. Cryptography converts data into a format that is unreadable for an unauthorized user, allowing it to be transmitted without unauthorized entities decoding it back into a readable format, thus compromising the data. Information security uses cryptography on several levels. The information cannot be read without a key to decrypt it. The information maintains its integrity during transit and while being stored. Cryptography also aids in non-repudiation. This means that the sender and the delivery of a message can be verified.

Digital Certificate: A digital certificate is an electronic document which uses a digital signature to bind together a public key with an identity — information such as the name of a person, organization, and other attributes which uniquely identify the entity and their role. The certificate can be used to verify that a public key belongs to the entity claiming that identity.

DMZ: In computer security, a DMZ or demilitarized zone is a physical or logical sub-network that contains and exposes an organization's external-facing services to an untrusted, usually larger, network such as the Internet. The purpose of a DMZ is to add an additional layer of security to an organization's local area network (LAN). An external network node can access only what is exposed in the DMZ, while the rest of the organization's network is fire-walled.

Encryption Key: Specifies the transformation of plain-text into cipher-text, and vice versa for decryption algorithms. Keys also specify transformations in other cryptographic algorithms, such as digital signature schemes and message authentication codes.

Firewall: Network security system that monitors and acts on incoming and outgoing network traffic based on predetermined security rules.

Generic/Shared user ID: Authentication credentials assigned for one specific role that can be used by more than one person.

Global System for Mobile (GSM): Standard that describes protocols for cellular network access.

International Organization for Standardization (ISO): International standard-setting body composed of representatives from various national standards organizations.

IP Address: Unique label assigned to each device that enables communication with other devices on a network.

Lightweight Directory Access Protocol (LDAP): Protocol for accessing and maintaining distributed directory information services over an Internet Protocol network.

Malware: Malicious code used to perform malicious actions.

Masked PAN: The first six and last four digits are the maximum number of digits to be displayed.

National Institute of Standards Technology (NIST): Non-regulatory U.S. federal agency that promotes advancing measurement science, standards, and technology in ways that enhance economic security and improve our quality of life.

Open Web Application Security Project (OWASP) Code of Ethics: Guidelines for professional, ethical behaviors for project life cycles.

Operation System (OS) injection: Shell injection that allows attacker to execute arbitrary code on an operating system.

Payment Card Industry (PCI) Workstations: Any device that is connected to the cardholder data environment and handles cardholder data.

Personal Firewall: Software on a computer, usually a standalone system, designed to limit inbound and outbound connections.

PIN Transaction Security (PTS) Devices: Device used by a merchant at the point-of-interaction for capturing payment card data and validating approval of its use for a transaction.

Point-to-point encryption (P2PE): Encryption standard that requires encryption of payment card data immediately upon use with the merchant’s point-of-sale terminal and cannot be decrypted until securely transported to and processed by the payment processor.

Primary Account Numbers (PAN): A 14, 15- or 16-digit number generated as a unique identifier designated for a primary account.

Pulping: Crushing paper into soft, shapeless mass.

Remediation: The three (3) primary methods of remediation are (1) installation of a software patch, (2) adjustment of a configuration setting and (3) removal of affected software.

Sanitization: Process for deleting sensitive data from a file, device or system or for rendering data useless if accessed by unauthorized or malicious parties.

Secure Wipe: Also called secure delete, this is a program utility used to delete specific files permanently from a computer system.

Simple Network Management Protocol (SNMP) community strings: User ID or password that allows access to system components.

Stateful Inspection: A firewall that tracks the operating state and characteristics of network connections traversing it. The firewall is configured to distinguish legitimate network packets for different types of connections. Only packets matching a known active connection are allowed to pass the firewall. In contrast a stateless firewall does not take context into account when determining whether to allow or block packets. 

Structured Query Language (SQL): The standard language for relational database management systems.

SysAdmin Audit Network Security Institute (SANS): Private U.S. for-profit company founded that specializes in information security, cyber-security training and selling certificates.

Threats: Threats are capabilities or methods of attack developed by malicious entities to exploit vulnerabilities and potentially cause harm to a computer system or network. Common examples are scripts, worms, viruses and Trojan horses.

Trusted Key: Provides consumers and organizations with a secure digital identity solution. It offers financial institutions with secure and frictionless know-your-client solutions, password-less authentication systems, and enhanced document signing procedures.

Untrusted Network: For purposes of PCI, an untrusted network is a network situated outside the security perimeter and control of the CDE.

VOIP: Voice over Internet Protocol, also called IP telephony, is a method and group of technologies for the delivery of voice communications and multimedia sessions over Internet Protocol networks, such as the Internet.

Vulnerabilities: Software flaws or a misconfiguration that may potentially result in the weakness in the security of a system within the system components directly associated with the cardholder data environment or any other IT resources.

Workstation: Any device such as a laptop or desktop computer that is used by an employee to complete work-related tasks.

4. Policy Guidelines

4.1  Technical

 4.1.1  Firewall Requirements Policy

Firewall configuration standards must include requirements for each connection between untrusted, outside networks with any DMZ and internal network zone. Firewall configuration standard must include illustrative drawing of logical and physical positioning of firewalls within the network topology. Documentation must be regularly reviewed to verify active configuration matches firewall configuration standard.

4.1.2  Router and Firewall Configuration Policy

Office of Information Security will ensure that firewall and router rules sets reviews adhere to the following conditions for purposes of complying with the Payment Card Industry Data Security Standards (PCI DSS) initiatives (PCI DSS Requirements and Security Assessment Procedures):

      • Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment;
      • Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic;
      • Appropriately configure, examine and confirm all firewalls and router settings for ensuring that all inbound and outbound traffic is limited to that which is necessary for the cardholder data environment;
      • Appropriately configure, examine and confirm all firewalls and router settings for ensuring that all other inbound and outbound traffic is specifically denied by using various configuration settings (i.e., deny all);
      • Secure and synchronize router configuration files;
      • Appropriately configure, examine, and confirm that router configuration files are secured from unauthorized access;
      • Appropriately configure, examine, and confirm that router configurations are synchronized, for example, the running (or active) configuration matches the start-up configuration;
      • Install perimeter firewalls between all wireless networks and the cardholder data environment, and configure these firewalls to deny or, if traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and the cardholder data environment;
      • Appropriately configure, examine and confirm examine firewall and router configurations for ensuring that there are perimeter firewalls installed between all wireless networks and the cardholder data environment;
      • Appropriately configure, examine and confirm that firewalls deny or, if traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and the cardholder data environment.

4.1.3  DMZ Configuration Policy

The Office of Information Security will ensure that the DMZ configuration and Internet access to the cardholder data environment policy adhere to the following conditions for purposes of complying with the Payment Card Industry Data Security Standards (PCI DSS) initiatives (PCI DSS Requirements and Security Assessment Procedures):

      • Prohibit direct public access between the Internet and any system component in the cardholder data environment;
      • Appropriately configure, examine, and confirm firewall and router configurations to ensure that there is no direct access between the Internet and system components in the internal cardholder network segments;
      • Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports;
      • Appropriately configure, examine, and confirm firewall and router configurations to ensure that a DMZ is implemented to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports;
      • Limit inbound Internet traffic to IP addresses within the DMZ;
      • Appropriately configure, examine, and confirm firewall and router configurations to ensure that inbound Internet traffic is limited to IP addresses within the DMZ;
      • Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment;
      • Appropriately configure, examine, and confirm firewall and router configurations to ensure that direct connections inbound or outbound are not allowed for traffic between the Internet and the cardholder data environment;
      • Implement anti-spoofing measures to detect and block forged source IP addresses from entering the network;
      • Appropriately configure, examine, and confirm firewall and router configurations to ensure that anti-spoofing measures are implemented, for example internal addresses cannot pass from the Internet into the DMZ;
      • Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet;
      • Appropriately configure, examine, and confirm firewall and router configurations to ensure that outbound traffic from the cardholder data environment to the Internet is explicitly authorized;
      • Implement stateful inspection, also known as dynamic packet filtering. (That is, only “established” connections are allowed into the network);
      • Appropriately configure, examine, and confirm firewall and router configurations to ensure that the firewall performs stateful inspection (dynamic packet filtering);
      • Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks;
      • Appropriately configure, examine, and confirm firewall and router configurations to ensure that system components that store cardholder data are on an internal network zone, segregated from the DMZ and other untrusted networks;
      • Do not disclose private IP addresses and routing information to unauthorized parties;
      • Appropriately configure, examine, and confirm firewall and router configurations to ensure that methods are in place to prevent the disclosure of private IP addresses and routing information from internal networks to the Internet;
      • Appropriately configure, examine, and confirm all applicable and necessary documentation to ensure that any disclosure of private IP addresses and routing information to external entities is authorized.

The exposure of cardholder data environment system components to direct public Internet access poses obvious security risks by allowing untrusted parties to make direct connections to an environment containing privileged information. The prohibition of direct public Internet access to system components within cardholder data environments helps to ensure that sensitive data, as well as the architecture where sensitive data resides, are insulated from external threats seeking to exploit information or resources.

4.1.4  Personal Firewall Policy

The Office of Information Security will ensure that the personal firewall on any computers in the PCI environment adheres to the following conditions for purposes of complying with the Payment Card Industry Data Security Standards (PCI DSS) initiatives (PCI DSS Requirements and Security Assessment Procedures):

      • Personal firewall is required for all devices that connect to the Internet (for example, laptops used by employees) when outside the company network, and which are also used to access the company network;
      • Specific configuration settings are defined for personal firewall;
      • Personal firewall software is to be configured to actively run on all such devices that are used within the PCI environment;
      • Personal firewall software is to be configured in such a way that is not alterable by users of any device.

4.1.5  Changing of Vendor Supplied Default Settings Policy

The Office of Information Security will ensure that the changing of vendor default settings for all system components and wireless environments adheres to the following conditions for purposes of complying with the Payment Card Industry Data Security Standards (PCI DSS) initiatives (PCI DSS Requirements and Security Assessment Procedures):

      • Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network. Note: This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, Simple Network Management Protocol (SNMP) community strings, etc.);
      • All vendor defaults (including default passwords on operating systems, software providing security services, application and system accounts, POS terminals, Simple Network Management Protocol (SNMP) community strings, etc.) are to be changed before a system is installed on the network;
      • Unnecessary default accounts (including accounts used by operating systems, security software, applications, systems, POS terminals, SNMP, etc.) are to be removed or disabled before a system is installed on the network;
      • Appropriately configure, examine, and confirm system settings and all necessary configurations to ensure that encryption keys are changed from default at installation;
      • Appropriately configure, examine, and confirm system settings and all necessary configurations to ensure that default SNMP community strings are changed upon installation;
      • Appropriately configure, examine, and confirm system settings and all necessary configurations to ensure that default SNMP community strings are not used.

4.1.6  Configuration Standards for  System Components Policy 

The Office of Information Security will develop configuration standards for system  components utilizing industry-accepted hardening standards for purposes of complying  with the Payment Card Industry Data Security Standards (PCI DSS) initiatives. The list  of industry-leading security standards, benchmarks and frameworks to utilize includes,  but is not limited to, the following (PCI DSS Requirements and Security Assessment  Procedures): 

      • Center for Internet Security (CIS);
      • International Organization for Standardization (ISO);
      • SysAdmin Audit Network Security (SANS) Institute;
      • National Institute of Standards Technology (NIST) vendor-specific tools and  checklists, along with general setup and hardening procedures.

Additionally, when configuring system components within the cardholder environment,  the following conditions must apply in order to ensure further compliance with the  Payment Card Industry (PCI) Data Security Standards (DSS) Initiatives (PCI DSS  Requirements and Security Assessment Procedures, Version 3.0):

      • Appropriately configure, examine, and confirm system settings and all necessary  configurations for system components to ensure that the system configuration  standards are consistent with industry-accepted hardening standards;
      • Appropriately develop, implement, and adhere to relevant policies and supporting  procedures to ensure that system configuration standards are updated as new  vulnerability issues are identified, as defined in Requirement 6.1;
      • Appropriately develop, implement, and adhere to relevant policies and supporting  procedures to ensure that system configuration standards are applied when new  systems are configured and verified as being in place before a system is installed  on the network.
      • System configuration standards used for general provisioning, hardening, securing and locking down of system components are to include the following  procedures:
        • Changing of all vendor-supplied defaults and elimination of unnecessary  default accounts;
        • Implementing only one primary application per server to prevent functions  that require different security levels on the same server;
        • Enabling only necessary services, protocols, daemons, etc. as required for  the function of the primary application on the system;
        • Implementing additional security features for any required services,  protocols or daemons that are considered to be insecure.  o Configuring system security parameters to prevent misuse;
        • Removing all unnecessary functionality, such as scripts, drivers, features,  subsystems, file systems, and unnecessary web servers that aren’t  required by the primary application on the system.
      • Appropriately configure, examine, and confirm system settings and all necessary  configurations for system components to ensure that only one primary function is  implemented per server;
      • If virtualization technologies are used, then appropriately configure, examine, and  confirm system settings and all necessary configurations for system components  to ensure that only one primary function is implemented per virtual system  component or device;
      • Appropriately configure, examine, and confirm system settings and all necessary  configurations for system components to ensure that only necessary services or  protocols are enabled;
      • For any required insecure services, daemons, or protocols implemented on  system components, ensure they are justified per documented configuration  standards;
      • Implement additional security features for any required services, protocols, or  daemons that are considered to be insecure;
      • Appropriately configure, examine, and confirm system settings and all necessary  configurations for system components to ensure that security features are  documented and implemented for all insecure services, daemons, or protocols;
      • Configure system security parameters to prevent misuse;
      • System administrators and/or security managers are to have relevant knowledge  of common security parameter settings for system components;
      • Appropriately configure, examine, and confirm system settings and all necessary  configurations for system components to ensure that common security parameter  settings are included;
      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that they are set appropriately  and in accordance with the configuration standards;
      • Appropriately configure, examine, and confirm system settings and all necessary  configurations for system components to ensure that all unnecessary functionality (for example, scripts, drivers, features, subsystems, file systems,  etc.) is removed;
      • Appropriately configure, examine, and confirm system settings and all necessary  configurations for system components to ensure that enabled functions are  documented and support secure configuration;
      • Appropriately configure, examine, and confirm system settings and all necessary  configurations for system components to ensure that only documented  functionality is present on the sampled system components. 

4.1.7  Non-Console Administrative Access Policy

The Office of Information Security will encrypt all non-console administrative access using strong cryptography for purposes of complying with the Payment Card Industry Data Security Standards (PCI DSS) initiatives. Many system components within the cardholder data environment are accessed through a non-console administrative function; thus, they must ensure that strong cryptography and other secure transmission methods are utilized at all times. The following is a list of protocols, secure data transmission elements, and tools that are used for accessing various system components:

      • Secure Shell (SSH);
      • Virtual Private Network (VPN);
      • Secure Socket Layer (SSL) I Transport Layer Security (TLS);
      • Secure File Transfer Protocol (sFTP);
      • Remote Desktop Protocol (RDP).

Additionally, regarding non-console administrative access, the following conditions must apply in order to ensure further compliance with the Payment Card Industry (PCI) Data Security Standards (DSS) Initiatives (PCI DSS Requirements and Security Assessment Procedures):

      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that a strong encryption method is invoked before the administrator's password is requested;
      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that Telnet and other insecure remote-login commands are not available for non-console access;
      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that administrator access to any web-based management interface is encrypted with strong cryptography;
      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that strong cryptography for the technology in use is implemented according to industry best practices and/or vendor recommendations.

4.1.8  Sensitive Authentication Data Storage Policy

The Office of Information Security will ensure that the storage of sensitive authentication data (SAD) adheres to the following conditions for purposes of complying with the Payment Card Industry Data Security Standards (PCI DSS) initiatives (PCI DSS Requirements and Security Assessment Procedures):

      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that the full contents of any track from the magnetic stripe on the back of card or equivalent data on a chip are not stored after authorization;
      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that the three-digit or four-digit card verification code or value printed on the front of the card or the signature panel (CVV2, CVC2, CID, CAV2 data) is not stored after authorization;
      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that PINs and encrypted PIN blocks are not stored after authorization.

4.1.9  Point-to-Point Encryption (P2PE), Wi-Fi, Analog and Global System for Mobile (GSM)

University of South Alabama will ensure that Point-to-point Encryption (P2PE), Wi-Fi, Analog and Global System for Mobile (GSM) usage adhere to and comply with the Payment Card Industry Data Security Standards (PCI DSS) initiatives (PCI DSS Requirements and Security Assessment Procedures):

      • Only Office of Information Security approved P2PE solutions are eligible for network scope reduction or removal. For implementation and eligibility verification, an advanced approval from the Office of Information Security is required;
      • If a PIN Transaction Security (PTS) device or a PCI workstation is connected with Wi-Fi, the PTS device or the PCI workstation must be implemented with a PCI SSC approved P2PE solution;
      • Wi-Fi connection alone is prohibited for cardholder data transactions and transmission in the university environment;
      • If a PTS device is connected with analog, it is permitted for cardholder data transactions and transmission in the university environment;
      • If a PTS device is connected with Global System for Mobile (GSM, also known as Cellular), it is permitted for cardholder data transactions and transmission in the university environment.

4.1.10  Custom Application Code Audit Policy

The Office of Information Security will ensure that the Custom Application Code Change Reviews policy adheres to the following conditions for purposes of complying with the Payment Card Industry Data Security Standards (PCI DSS) initiatives (PCI DSS Requirements and Security Assessment Procedures):

      • Code changes are reviewed by individuals other than the originating code author;
      • Code changes are reviewed by individuals who are knowledgeable in code review techniques and secure coding practices;
      • Code reviews ensure code is developed according to secure coding guidelines, such as the SEI CERT Top 10 Secure Coding Practices, and for any language specific platforms utilized to develop internal systems and applications;
      • Appropriate corrections are implemented prior to release of code;
      • Code review results are reviewed and approved by management prior to release.

4.1.11  Change Control Policy

Change control has become a critical issue due in large part to regulatory compliance purpose and the need to fully document the change control process for accountability and tracking changes. As a result, all system components directly associated with the cardholder data environment and other IT resources that undergo changes must be documented accordingly. The Office of Information Security will ensure that Change Control policy and procedures adhere to the following conditions for purposes of complying with the Payment Card Industry Data Security Standards (PCI DSS) initiatives (PCI DSS Requirements and Security Assessment Procedures):

      • Establishment of change control initiation, implementation and authorization directives;
      • Establishment of a change control lifecycle;
      • Establishment of minimum reporting criteria for change control documentation;
      • Separation of duties, roles and responsibilities exist between the development/test environment(s) and production environment(s), complete with access controls in place;
      • Production data with live Primary Account Numbers (PAN) are not to be used for testing or development;
      • Test data and all associated accounts are removed before a production system becomes active;
      • Documentation of impact is included in the change control documentation;
      • Management approval by appropriate parties, along with approval for all stages of the change control lifecycle, is required for each change;
      • Operational functionality testing is performed and must be documented for each change, where applicable so as to verify that the change does not adversely impact the security of the custom code changes;
      • For custom code changes made, all updates and releases are tested for compliance with Requirement 6.5 before being released to production;
      • Additionally, change controls policies, procedures, and supporting initiatives are to properly document the following:
        • Documentation of impact is included in the change control documentation for each sampled;
        • Documented approval by authorized parties is present for each sampled change.

4.1.12  Secure Coding Guidelines and Training Policy

The Office of Information Security will ensure that the software development and secure coding guidelines and training policy and procedures adhere to the following conditions for purposes of complying with the Payment Card Industry Data Security Standards (PCI DSS) initiatives (PCI DSS Requirements and Security Assessment Procedures):

      • Software developers and all other relevant personnel involved in the development of software for the University of South Alabama are required to undergo annual training in secure coding techniques for the software platforms(s) with which they work;
      • Software developers and all other relevant personnel involved in the development of software for the University of South Alabama are required to submit their Secure Coding Training checklist on an annual basis as evidence that they are knowledgeable in secure coding techniques;
      • Software developers involved in the software development process will adhere to professional guidelines, such as the Open Web Application Security Project (OWASP) Code of Ethics and CWE/SANS;
      • The Office of Information Security’s software development lifecycle includes policies, processes and procedures to ensure that internally developed applications are not vulnerable to the following threats:
        • Injection Flaws (SQL, OS and LDAP Injection);
        • Buffer Overflows;
        • Insecure Cryptographic Storage;
        • Insecure Communications
        • Improper Error Handling;
        • All high-risk vulnerabilities identified in the vulnerability identification process as found in the Risk Ranking Table within the Security Patch Management Installation Policy and Procedures document;
        • Cross-Site Scripting o Improper Access Control;
        • Cross Site Request Forgery;
        • Broken Authentication and Session Management;
        • All "High" vulnerabilities and threats as identified in the Risk Ranking Table found in the Security Patch Management Installation Policy and Procedures.

4.1.13  Database Access & Configuration Policy

The Office of Information Security will ensure that the Database Access & Configuration settings policy adheres to the following conditions for purposes of complying with the Payment Card Industry Data Security Standards (PCI DSS) initiatives (PCI DSS Requirements and Security Assessment Procedures):

      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that all users are authenticated prior to access;
      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that all user access, user queries, and user actions on (for example, move, copy, delete), the database is through programmatic methods only (for example, through stored procedures);
      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that user direct access to or queries of databases are restricted to database administrators;
      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that application IDs can only be used by the application (and not by individual users or other processes).

4.1.14  Secure Audit Trails Policy

The Office of Information Security will ensure that the time-synchronization technology policy adheres to the following conditions for purposes of complying with the Payment Card Industry Data Security Standards (PCI DSS) initiatives (PCI DSS Requirements and Security Assessment Procedures):

      • Only individuals with a job-related need can view audit trail files;
      • Current audit trail files are to be protected at all times from unauthorized modifications via access control mechanisms, physical segregation and/or network segregation;
      • Audit trail files are to be promptly backed up to a centralized log server or media that is difficult to alter;
      • Logs for external-facing technologies are to be written onto a secure, centralized, internal log server or media;
      • Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts;
      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that the use of file-integrity monitoring or change-detection software on logs.

4.1.15  Security Event Logs Policy

The Office of Information Security will ensure that the Security Logs & Events policy adheres to the following conditions for purposes of complying with the Payment Card Industry Data Security Standards (PCI DSS) initiatives (PCI DSS Requirements and Security Assessment Procedures):

      • Authorized personnel are to review logs and security events on a daily basis for all system components for the purposes of identifying anomalies or suspicious activity;
      • As such, the following items are to be reviewed by authorized personnel:
        • All security events;
        • Logs of all system components that store, process, or transmit CHD and/or SAD, or that could impact the security of CHD and/or SAD;
        • Logs of all critical system components;
        • Logs of all servers and system components that perform security functions.
      • Additionally, authorized personnel are to perform the following:
        • Review logs of all other system components periodically based on the organization’s policies and risk management strategy, as determined by the organization’s annual risk assessment;
        • Follow up on any exceptions and anomalies identified during the review process.
      • Furthermore, all audit trail history files are to be retained for at least one year, with a minimum of three months immediately available for analysis.

4.1.16  Secure Card Holder Data Transmission Policy

All departments must ensure that the use of strong cryptography and secure protocols adheres to the following conditions for purposes of complying with the Payment Card Industry Data Security Standards (PCI DSS) initiatives:

      • Use strong cryptography and security protocols for safeguarding sensitive cardholder data during transmission over open, public networks;
      • Comprehensively document all locations where cardholder data is transmitted or received over open, public networks;
      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that all cardholder data is encrypted with strong cryptography during transit;
      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that only trusted keys and/or certificates are accepted;
      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that the protocol is implemented to use only secure configurations and does not support insecure versions or configurations;
      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that the proper encryption strength is implemented for the encryption methodology in use;
      • Strong cryptography and secured protocols are defined and approved by PCI DSS;
      • For Voice over IP (VoIP) transmission, the following three requirements must be met:
        • All the VoIP data must be encrypted with strong cryptography and transmitted by secured protocols;
        • Network segregation must be implemented for the VoIP to transmit cardholder data;
        • VoIP with cardholder data is prohibited for storage in any of Stanford University's systems.
      • It is prohibited to transmit CHD via texting messages, instant messages, emails or voicemail.

4.2 Merchant

4.2.1  Data Retention & Disposal Policy

The Office of Information Security will ensure that the Data Retention and Disposal policy adheres to the following conditions for purposes of complying with the Payment Card Industry Data Security Standards (PCI DSS) initiatives (PCI DSS Requirements and Security Assessment Procedures):

      • Comprehensive policies, procedures, and processes are to be developed, implemented, and in place regarding the following:
        • All legal, regulatory, and business requirements for data retention;
        • Specifically, limiting data storage amount and retention time to that which is required for the applicable legal, regulatory, and business requirements;
        • Specific requirements for retention of cardholder data, such as why cardholder data needs to be held (i.e., time period) and the reasons why (i.e., business justification);
        • Secure deletion of cardholder data when no longer needed for legal, regulatory, or business reasons;
        • Coverage for all storage of cardholder data;
        • A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements;
        • Additionally, all locations of stored cardholder data are to be included in the data retention and disposal processes.
      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that the data stored does not exceed the requirements defined in the data retention policy;
      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that data is deleted securely.

4.2.2  Primary Account Number (PAN) Masking Policy

The Office of Information Security will ensure that the masking & displaying of the Primary Account Number (PAN) adheres to the following conditions for purposes of complying with the Payment Card Industry Data Security Standards (PCI DSS) initiatives (PCI DSS Requirements and Security Assessment Procedures):

      • Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see the full PAN;
      • A list of roles that need access to displays of full PAN is appropriately documented, along with a legitimate business need for each role having access to such information;
      • All other roles not specifically authorized to see the full PAN must only see the masked PAN;
      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that the full PAN is only displayed for users/roles with a documented business need, and that PAN is masked for all other requests;
      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that PANs are masked when displaying cardholder data, and that only those with a legitimate business need are able to see the full PAN.

4.2.3  Unencrypted Primary Account Number Numbers Policy

Office of Information Security will ensure that unencrypted Primary Account Numbers (PAN) are not sent via end-user messaging technologies and that they adhere to the following conditions for purposes of complying with the Payment Card Industry Data Security Standards (PCI DSS) initiatives (PCI DSS Requirements and Security Assessment Procedures):

      • Primary Account Numbers (PAN) will not be sent via email;
      • Primary Account Numbers (PAN) will not be sent via an instant messaging protocol;
      • Primary Account Numbers (PAN) will not be sent via a chat protocol or forum Sessions;
      • If for any reason, Primary Account Numbers (PAN) must be sent via end-user messaging technologies, they are to be sent using strong encryption, rendering the PAN unreadable.

4.2.4  Anti-Virus Policy

The Office of Information Security will ensure that the Anti-Virus policy adheres to the following conditions for purposes of complying with the Payment Card Industry Data Security Standards (PCI DSS) initiatives (PCI DSS Requirements and Security Assessment Procedures):

      • All computers and system components both within the cardholder environment and indirectly associated with the cardholder environment must have licensed, supported anti-virus software installed and up to date with the most current version available;
      • Anti-virus software must be active, must be enabled for automatic updates, must be scheduled to perform virus checks at regular intervals, and must have its virus definition and all other associated software files kept current;
      • For systems considered to be not commonly affected by malware, periodic evaluations must be performed to identify and evaluate evolving malware threats in order to confirm whether such systems continue to not require anti-virus software;
      • No user shall disable or tamper with the configuration of anti-virus software installed on any computers and system components either within the cardholder environment or indirectly associated with the cardholder environment;
      • Employees who attach workstations and employees who allow non-company employees to attach workstations to the network are responsible for ensuring that those workstations are running anti-virus software and that a current virus signature is installed.

4.2.5  Security Patch Management Installation Policy

Security patch management (patch management) has become a critical security issue due in large part to the exploitation of information technology systems from numerous external and internal sources. Consequently, all system components directly associated with the cardholder data environment must be securely hardened and configured with all necessary and appropriate patches and system updates for preventing the exploitation or disruption of mission-critical services as mandated (PCI DSS Requirements and Security Assessment Procedures).

Similarly, all IT resources not directly associated with the cardholder data environment must also be securely hardened and configured with all necessary and appropriate patches and system updates in order to prevent the exploitation or disruption of mission-critical services.

4.2.6  Data Control & Access Control Policy

The Office of Information Security will ensure that the Data Control & Access Control policy adheres to the following conditions for purposes of complying with the Payment Card Industry Data Security Standards (PCI DSS) initiatives (PCI DSS Requirements and Security Assessment Procedures):

      • Limit access to system components and cardholder data to only those individuals whose job requires such access;
      • Access needs are to be defined for each respective role, specifically:
        • System components and data resources that each role needs to access for their job function;
        • Level of privilege required for accessing resources.
      • Access rights for privileged users are restricted to the least privileges necessary to perform job responsibilities;
      • Privileges are assigned to individuals based on job classification and function, such as Role-Based Access Control (RBAC);
      • An authorization form is required for all access, which must specify required privileges, and must be signed by management;
      • Access control systems are in place on all system components;
      • Access control systems are configured to enforce privileges assigned to individuals based on job classification and function;
      • Access control systems have a default Deny All setting;
      • Security policies and operational procedures for restricting access to cardholder data are documented, in use, and known to all affected parties.

4.2.7  Unique ID & Authentication Methods Policy

The Office of Information Security will ensure that the Unique ID and Authentication Methods policy adheres to the following conditions for purposes of complying with the Payment Card Industry Data Security Standards (PCI DSS) initiatives (PCI DSS Requirements and Security Assessment Procedures):

      • All users are assigned a unique ID before allowing them to access system components or cardholder data;
      • Authorized personnel are to control addition, deletion, and modification of user IDs, credentials, and other identifier objects;
      • Terminated users are to have their access immediately revoked;
      • Inactive user accounts are to be disabled and/or removed every 90 days;

Authorized personnel are to manage IDs used by vendors to access, support, or maintain system components via remote access as follows:

      • Enable vendor access only during the time period needed and disabled when not in use;
      • Actively monitored when in use by all appropriate means;

Additionally, the following best practices are to be implemented regarding accepts attempts and system idle time:

      • Limit repeated access attempts by locking out the user ID after not more than five attempts, set the lockout duration to require an administrator re-enable the user ID;
      • If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session;
      • All users are to be assigned a unique ID for access to system components or cardholder data and must also utilize an approved authentication method;
      • Passwords/phrases must meet the following conditions in accordance with PCI DSS mandates as described in the Password Policy.

4.2.8  Authentication Methods Policy

The Office of Information Security will ensure that the Shared, Group, Generic, and Other Authentication Methods Policy adheres to the following conditions for purposes of complying with the Payment Card Industry Data Security Standards (PCI DSS) initiatives (PCI DSS Requirements and Security Assessment Procedures):

      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that Generic user IDs are disabled or removed;
      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that shared user IDs for system administration activities and other critical functions do not exist;
      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that shared and generic user IDs are not used to administer any system components;
      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that use of group and shared IDs and/or passwords or other authentication methods are explicitly prohibited;
      • Ensure that system administrators understand that group and shared IDs and/or passwords or other authentication methods are not distributed, even if requested.
      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that different authentication is used for access to each customer;
      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that procedures for using authentication mechanisms such as physical security tokens, smart cards, and certificates are defined and include authentication mechanisms that are assigned to an individual account and not shared among multiple accounts and that physical and/or logical controls are defined to ensure only the intended account can use that mechanism to gain access;
      • Appropriately configure, examine, and confirm system settings and all necessary configurations for system components to ensure that controls are implemented to ensure only the intended account can use that mechanism to gain access.

4.2.9  Media Storage and Classification Policy

The Office of Information Security will ensure that the Media Storage, Distribution and Classification Policy adheres to the following conditions for purposes of complying with the Payment Card Industry Data Security Standards (PCI DSS) initiatives (PCI DSS Requirements and Security Assessment Procedures):

      • Controls for physically securing all media (including but not limited to computers, removable electronic media, paper receipts, paper reports, and faxes) are to be in place for protecting cardholder data;
      • Media backups are to be stored in a secure location, preferably an off-site facility, such as an alternate or backup site, or a commercial storage facility. Review the location’s security at least annually;
      • All media is to be appropriately classified so the sensitivity of the data can be determined;
      • All media is to be sent by secure courier or other delivery method, so that it can be accurately tracked;
      • Management is to approve any and all media that is moved from a secured area (including when media is distributed to individuals);
      • Strict control is to be maintained over the storage and accessibility of media;
      • Inventory logs of all media are to be maintained, with media inventory procedures undertaken at least annually.

4.2.10  Media Destruction Policy

The Office of Information Security will ensure that the Media Destruction policy adheres to the following conditions for purposes of complying with the Payment Card Industry Data Security Standards (PCI DSS) initiatives (PCI DSS Requirements and Security Assessment Procedures):

      • Once the maximum retention period has been allotted for cardholder data, it must be removed from all electronic media, and any hardcopy edition must be disposed of accordingly;
      • All hard copy materials are to be cross-shredded, incinerated or pulped, such that there is reasonable assurance the hard copy materials cannot be reconstructed;
      • Storage containers for shredding hard copy materials are to be secured at all times, with appropriate physical controls such as locks on the storage bins;
      • Storage of cardholder data on electronic media is not permissible per the PCI Compliance policy;
      • All digital materials shall be destroyed when no longer needed.

4.2.11  Media Device Protection Policy

The Office of Information Security will ensure that the Media Device Protection policy adheres to the following conditions for purposes of complying with the Payment Card Industry Data Security Standards (PCI DSS) initiatives (PCI DSS Requirements and Security Assessment Procedures). Authorized personnel are to conduct the following:

      • Maintain a list of all devices that capture payment card data, for which the list is to include the following:
        • Make, model of device;
        • Location of device (for example, the address of the site or facility where the device is located);
        • Device serial number or other method of unique identification.
      • Periodically inspect all devices to ensure that they have not been tampered with or substituted;
      • Adequately train personnel to be aware of suspicious behavior and to report tampering or substitution of devices;
      • Ensure that the list of devices is updated when devices are added, relocated, decommissioned.

4.2.12  Physical Security Policy

Any physical location that is part of the Cardholder Data Environment (CDE) must have the following security controls:

      • Access is controlled with badge readers or other devices including authorized badges and lock and key;
      • Surveillance monitoring equipment and/or access control mechanisms must be in place to monitor the entry/exit points to sensitive areas;
      • Surveillance monitoring equipment and/or access control mechanisms must be protected from tampering or disabling;
      • Surveillance monitoring equipment and/or access control mechanisms must be monitored and data from equipment or other mechanisms must be stored for at least three (3) months;
      • Physical and/or logical controls must be in place to restrict access to publicly accessible network jacks;
      • Physical access to wireless access points, gateways, handheld devices, networking/communications hardware and telecommunication lines (i.e., "critical infrastructure hardware") must be appropriately restricted;
      • Processes and procedures must be in place for assigning badges to onsite personnel (i.e., employees) and visitors, which consist of granting new badges, changing access requirements and revoking access;
      • Processes and procedures must be in place for distinguishing between onsite personnel and visitors, with a mechanism to clearly identify visitors;
      • Access to the identification process (such as the badge system) must be limited to authorized personnel;
      • Appropriate authorization procedures must be followed before authorizing personnel to access the CDE;
      • Any terminated employee must have their access authorization removed immediately;
      • Visitors must be authorized before they are granted access to, and escorted at all times within, areas where cardholder data is processed or maintained;
      • A visitor log must be in place to record physical access to the facility as well as computer rooms and data centers where cardholder data is stored or transmitted;
      • The log should record key information:
        • The visitor’s name;
        • The firm represented;
        • The onsite personnel authorizing physical access.
      • The visitor log must be retained for at least three months;
      • Visitor identification (such as badges) must expire;
      • Visitors must surrender their badge or other authorization identification upon departure or expiration.

4.2.13  Workstation and Laptop Usage Policy

The Office of Information Security will ensure that PCI Workstation and laptop usage policy adhere to the following conditions for purposes of complying with the Payment Card Industry Data Security Standards (PCI DSS) initiatives (PCI DSS Requirements and Security Assessment Procedures):

      • A university employee or contractor can only use a dedicated PCI workstation or a dedicated PCI laptop to perform payment card transactions for university customers, clients or students;
      • For card-in-present, mail order, fax order and phone order, it is a violation to enter/process customers' card transactions by any devices with internet connection other than the dedicated PCI workstations or laptops;
      • The dedicated PCI workstations and laptops are provided and maintained by University IT;
      • This policy does not apply to the PCI P2PE devices and systems.

4.1.14  Payment Systems and Vendor Evaluation Policy

Payment System and Services Vendors include application system and service providers, and any external consulting services that involve PCI DSS compliance. For the evaluation and verification of payment card service providers, the following documents must be submitted to the Office of Information Security for review:

      • The AOC must be valid within twelve months;
      • Every vendor must submit the AOC as a service provider, unless an exception is granted by Treasury Office, ISO and UIT Compliance Office;
      • If the AOC is not signed by a PCI SSC certified QSA or ISA, the vendor must also submit their current quarter's Approved Scanning Vendor (ASV) report and the current year's penetration test report for external network;
      • In a twelve-month period, the PCI Compliance team will only accept a maximum of three versions of an AOC from the same vendor for review.

If needed at a later stage of the evaluation, the PCI Compliance team might request that the vendor provide a demo on payment processing workflow through its services.

Business engagements and formal purchase orders must not be involved with any prospective payment system and services before completing an initial vendor qualification assessment, PCI DSS compliance assessment, and vendor systems' feasibility for integration assessment.

4.2.15  PCI DSS Awareness Training Policy

The University of South Alabama has implemented a formal security awareness program to make all personnel aware of the cardholder data security policy and procedures:

      • All personnel, whose responsibility involves payment card processing, transmission or storage, are required by PCI DSS to be enrolled and complete the training on an annual basis;
      • For newly required personnel in the merchant departments, Merchant Services team shall notify the Office of Information Security for the initial enrollment;
      • Once personnel are enrolled in the PCI DSS Training, the centralized training system will send out notification on annual basis for training certification and subsequent recertification automatically;
      • If personnel are no longer required for the PCI DSS Training due to job changes, a notification with the manager’s approval or Merchant Services approval is required to send to the Office of Information Security so that the account may be disabled.

4.2.16  Online Merchant Card Policy

The responsible personnel will provide the web interface design for the Online Payment Card provider integration to fully comply with PCI DSS requirements:

      • The Online Payment Card service must only be available for an integration that is dedicated to a specific merchant department and MID;
      • The web interface can only be activated for the designated linked and active Online Payment Card provider account and MID.
        • Once the linked Online Payment Card provider account or MID is deactivated, the web page and associated supporting web servers will be immediately removed by IT for security and to meet PCI DSS requirements.

5. Procedures

Not Applicable.

6. Enforcement

Violation of this policy could put the University at risk to a security breach. Failure to comply with the PCI DSS can result in the University being assessed fines, penalties, loss of reputation, and payment card privileges. An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment. Alleged violations will be handled through USA disciplinary procedures applicable to the user. USA may suspend, block or restrict access to an account, independent of such procedures, when it reasonably appears necessary to do so in order to protect the integrity, security, or functionality of University or other computing resources or to protect USA from liability. USA may also refer suspected violations of applicable law to appropriate law enforcement agencies.

7. Related Documents

Payment Card Industry Data Security Standard: 

https://www.pcisecuritystandards.org 

USA PCI General Merchant Procedures:

https://www.southalabama.edu/departments/csc/informationsecurity/resources/34_usa_payment_card_industry_general_merchant_procedures.pdf