Technical Standard

Technical Standard for Card Processing Systems

Note: These standards apply to systems in the CCSP environment and virtual terminals.

Computer Requirements

Configuration

All devices must be properly labeled with information that can be correlated to owner and contact information.
Any vendor-supplied defaults (e.g. passwords, SNMP strings, unnecessary accounts) must be changed before connecting any system to the network.
Each system must serve only one primary function and all unnecessary functionality must be removed.
Systems must be configured to meet the applicable Notre Dame security standard as a baseline.  In cases where this standard and the Notre Dame standard conflict, this standard takes precedence.
Any non-console administrative access to a system must be encrypted.
Systems commonly affected by malware must have antivirus software installed and configured to log to the central log server.  This software must retrieve updates daily. 
 Personal firewall software must be installed on all Notre Dame owned and maintained computers with direct connectivity to the Internet which are used to access the cardholder data environment.
Only Notre Dame owned and maintained computers are allowed to connect to CCSP environment.
Any changes to system configuration must be completed through the OIT Change Control Process.

The change request must include:

 

  • Documentation of impact
  • Management approval
  • Information Security approval
  • Test documentation
  • Back-out procedures

System firewalls must be configured to allow only traffic required for documented business purposes.
 

Authentication

System authentication should use centralized authentication, where possible.  Unless documented, the only local account should be an administrator account for emergency use.  The password to that account must be stored in the OIT safe in a sealed envelope.
All users must complete an authorization form explicitly approved by management that specifies required privileges.  Service Now is one tool that may be used to meet this requirement.
All system users must be identified with a unique username and all accounts must be protected by passwords that meet the following requirements (in addition to the University Strong Password Policy Requirements):

 

  • Accounts that are inactive for more than 90 days must be automatically disabled
  • No password may be shared by multiple users
  • Accounts must be locked out for 30 minutes after six unsuccessful login attempts

Systems must be configured to use a password-protected screen saver after 15 minutes of inactivity.
Passwords must be encrypted during transmission and storage on all system components.
Any remote access to the system must take place through the PCI environment VPN using two-factor (SafeWord) authentication. VPN connections must be immediately deactivated when work is completed. It is prohibited for the copying, moving, or storing of cardholder data onto local hard drives and removable electronic media when remote accessing the PCI environment.


Monitoring
The following events must be logged to the central log server:

  • Access to cardholder data by an individual
  • Actions taken by users with administrative privileges
  • Access to audit trails
  • Invalid logical access attempts
  • Use of identification and authentication mechanisms
  • Initialization of the audit logs
  • Creation and deletion of system-level objects

Every event logged to the central log server must include the following details:

  • User identification
  • Type of event
  • Date and time
  • Success or failure indication
  • Origination of event
  • Identity or name of affected data, system component or resource

Logs must be reviewed daily with review of all exceptions.

  • Audit logs must be retained for one year
  • The last three months of audit logs must be immediately available for analysis

All system clocks must be synchronized with the PCI environment’s NTP servers.
Systems must run Tripwire with the policy configured to:

  • Ensure that logs may not be altered without generating an alert (new data being added should not generate an alert)
  • Alert on any changes to critical files, the modification of which could indicate a system compromise or risk of compromise

Reviews of tripwire reports should be performed weekly with discrepancies being reconciled by OIT- EIS staff.

Updates

  • Ensure that all system components and software have the latest vendor-supplied security patches installed.  Install relevant security patches within one month of release. Terminal downloads will be authorized through the Merchant Card Coordinator.
  • Follow the Change Control Procedure for all applicable changes.

 

Firewall and Network Device Requirements

Configuration
Firewalls and network devices must be configured to meet the applicable Notre Dame security standard as a baseline.  In cases where this standard and the other Notre Dame security standards conflict, this standard takes precedence.
Security administrators shall conduct a review of all firewall and router rule sets every six months. (The OIT Information Security staff is responsible for the maintenance, management and configuration of the main CCSP firewalls. OIT Network Services is responsible for the maintenance, management and configuration of network switches, remote site VPN endpoints and the VPN concentrators.) 
Firewalls and network devices shall be configured to implement IP masquerading to prevent internal addresses from being translated and revealed on the Internet.
Firewalls will be used at each Internet connection and between any demilitarized zone and the internal network zone. Firewalls shall be configured to:

  • Implement a DMZ to filter and screen all traffic and prohibit direct routes for inbound and outbound Internet traffic
  • Deny all traffic from untrusted networks and hosts except for protocols necessary for the cardholder data environment
  • Restrict inbound Internet traffic to IP addresses within the DMZ
  • Not allow internal addresses to pass from the Internet into the DMZ
  • Implement stateful inspection
  • Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment
  • Prohibit direct public access between external networks and any system component that stores cardholder data
  • Restrict outbound traffic from payment card applications to IP addresses within the DMZ

Network device configuration files shall be secured and synchronized.  Running configuration files and start-up configuration files should have the same secure configuration.
Administrators of firewalls and network devices in the card processing network are responsible for maintaining the following:

  • Current network diagram with all connections to cardholder data, including any wireless networks
  • Documented list of services and ports necessary for business
  • Justification and documentation for any available protocols besides HTTP, SSL, SSH and VPN
  • Justification and documentation for any risky protocols allowed (e.g. FTP, telnet) which includes reason for use of protocol and security features implemented

Authentication
Any vendor-supplied defaults (e.g. passwords, SNMP community strings, unnecessary accounts) must be changed before connecting any system to the network.
Each system must serve only one primary function and all unnecessary functionality must be removed.
Any non-console administrative access to a system must be encrypted.
Any external network connections or changes to system configuration must be completed through the OIT Change Control Process.  The change request must include:

  • Documentation of impact
  • Management approval (The Director, Information Security is responsible for approving changes to the Sidewinder firewalls.)
  • Information Security approval
  • Test documentation
  • Back-out procedures

System authentication should use centralized authentication, where possible.  Unless documented extraordinary circumstances exist, the only local account should be an administrator account for emergency use.  The password to that account must be stored in the OIT safe in a sealed envelope.
All system users must be identified with a unique username and all accounts must be protected by passwords that meet the following requirements (in addition to the University Strong Password Policy Requirements):

  • Accounts that are inactive for more than 90 days must be automatically disabled
  • No password may be shared by multiple users
  • Accounts must be locked out for 30 minutes after six unsuccessful login attempts

Passwords must be encrypted during transmission and storage on all system components.
Any remote access to the system must take place through the PCI environment VPN using two-factor (SafeWord) authentication.  VPN time out setting must be set to  240 minutes.

Monitoring

The following events must be logged to the central log server:

 

  • Access to cardholder data by an individual
  • Actions taken by users with administrative privileges
  • Access to audit trails
  • Invalid logical access attempts
  • Use of identification and authentication mechanisms
  • Initialization of the audit logs
  • Creation and deletion of system-level objects

Every event logged to the central log server must include the following details:

  • User identification
  • Type of event
  • Date and time
  • Success or failure indication
  • Origination of event
  • Identity or name of affected data, system component or resource

Logs must be reviewed daily with review of all exceptions.

All clocks must be synchronized with the PCI environment’s NTP servers.

Payment Application Requirements

Any payment application that is installed in the Notre Dame Payment Card Environment must be PA-DSS certified and must be implemented in accordance with the vendors implementation guide.

System Defaults

Vendor-supplied defaults must be changed before installing an application system on the network.  For instance, change default usernames and passwords and eliminate unnecessary accounts.

System Functions

The server housing the application shall have no unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.

System Access

All non-console administrative access to the application must be encrypted. Use technologies such as SSH, VPN, or SSL/TLS (transport layer security) for web-based management and other non-console administrative access.

Storage of Sensitive Data

Any sensitive data that is stored as a result of the trouble shooting process must be securely deleted at the end of the trouble shooting process. 
The application must not be configured to store sensitive authentication data subsequent to authorization (even if encrypted), including:

  • The full contents of any track from the magnetic stripe (that is on the back of a card, in a chip or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic stripe data.
  • The card-validation code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions
  • The personal identification number (PIN) or the encrypted PIN block.

Note: In the normal course of business, the following data elements from the magnetic stripe may need to be retained: the cardholder’s name, primary account number (PAN), expiration date, and service code. To minimize risk, store only those data elements needed for business. NEVER store the card verification code or value or PIN verification value data elements.
For applications that display the PAN, user privileges must be varied such that the application must mask the PAN for employees without a specific need to see the full PAN.  In such cases, the first six and last four digits are the maximum number of digits to be displayed.

Key Management

Encryption keys should be managed in accordance with the vendors implementation guide

Security Patches

All system components must have the most recently released, appropriate software patches to protect against exploitation by employees, external hackers, and viruses. 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.  Patches may be applied using a risk-based approach to prioritize patch installation to ensure high priority systems and devices are addressed within one month, while less critical devices and systems are addressed within three months.

 

Software Development

In-house developed payment applications are prohibited by the University. 

Web Applications

In house hosted web hosting applications are prohibited by the University.  Third party hosted web applications must be determined to PCI DSS compliant by the vendor.

Least Privilege

In keeping with the University of Notre Dame Payment Card Business Standard, the application must support limitation of user access to cardholder information only to those individuals whose job requires such access.  By default, the application should set access to “deny all” unless specifically allowed.

Authentication and Password Protection

Assigning a unique identification (ID) to each person with access ensures that actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.  Therefore, the application must identify all users with a unique user name before allowing them to access application components or cardholder data.  In addition to assigning a unique IDemploy at least one of the following methods to authenticate all users:

  • Password
  • Token devices (e.g., SecureID, certificates, or public key)
  • Biometrics

The application must require two-factor authentication for remote access by employees, administrators, and third parties. Use technologies such as remote authentication and dial-in service (RADIUS) or terminal access controller access control system (TACACS) with tokens; or VPN (based on SSL/TLS or IPSEC) with individual certificates.
Exceptions to this include Bomguard/ WebX support style technologies when used to provide real-time support from approved vendor and the specific implementation is reviewed and approved by the CCSP.
Applications must encrypt all passwords during transmission and storage.  In addition, the application and/or application administrator must ensure proper user authentication and password management for non-consumer users and administrators as follows:

  • Control addition, deletion, and modification of user IDs, credentials, and other identifier objects
  • Verify user identity before performing password resets
  • Set first-time passwords to a unique value for each user and require change immediately after the first use
  • Immediately revoke access for any terminated users
  • Remove inactive user accounts at least every 90 days
  • Enable accounts used by vendors for remote maintenance only during the time period needed
  • Communicate password procedures and policies to all users who have access to cardholder data
  • Do not use group, shared, or generic accounts and passwords
  • Require change of user passwords at least every 90 days
  • Require a minimum password length of at least seven characters
  • Use passwords containing both numeric and alphabetic characters
  • Do not allow an individual to submit a new password that is the same as any of the last four passwords he or she has used
  • Limit repeated access attempts by locking out the user ID after not more than six attempts
  • Set the lockout duration to thirty minutes or until administrator enables the user ID
  • If a session has been idle for more than 15 minutes, require the user to re-enter the password to re-activate the session
  • Authenticate all access to any database containing cardholder data. This includes access by applications, administrators, and all other users

Monitoring

The application must enable or the application administrator must establish a process for linking all access to application components to each individual user.  
Automated audit trails are required to reconstruct the following events:

  • All individual user accesses to cardholder data
  • All actions taken by any individual with root or administrative privileges
  • Access to all audit trails
  • Invalid logical access attempts
  • Use of identification and authentication mechanisms
  • Initialization of the audit logs
  • Creation and deletion of system-level objects.

Record at least the following audit trail entries for all system components for each event:

  • User identification
  • Type of event
  • Date and time
  • Success or failure indication
  • Origination of event
  • Identity or name of affected data, system component, or resource.

In accordance with PCI, audit logs must be maintained for one year, with a minimum of three months immediately available for analysis.
For log integrity, application and/or application server clocks must be synchronized with the NTP server.  Further, audit trails must be secured so they cannot be altered.  To do so, the application administrator must:

  • Limit viewing of audit trails to those with a job-related need
  • Protect audit trail files from unauthorized modifications
  • Promptly back-up audit trail files to a centralized log server or media that is difficult to alter.
  • Copy logs for wireless networks onto a log server on the internal LAN.
  • Use file integrity monitoring and change detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).

 

POS “Swipe” terminal Requirements

This standard applies to all land line, IP based and cellular based point-of-sale card processing devices.

Setup

  • Always change vendor-supplied defaults before installing a system
  • IP based physical terminals must reside on an isolated  payment network
  • Disable all unnecessary and insecure services and protocols
  • Keep cardholder data storage to a minimum; following the prescribed time period and process in the Payment Card Data Handling Procedures.
  • Mask the card number when displayed (the first six and last four digits are the maximum number of digits to be displayed).  Terminals must be programmed to mask the payment card number on the customer and merchant receipt.
  • Password protect all detail reports.
  • Follow the Terminal Configuration Procedure for the terminal type in question.

Operations

  • Restrict physical access to terminals to authorized users of the terminal. When unattended, terminals must be stored in a locked area.
  • Terminals must be settled daily, although they may be settled more frequently.  Generate Totals Reports prior to settlement
  • Terminals and terminal supplies will be ordered through the campus Merchant Card Coordinator

Wireless and End User Technologies

In accordance with the University of Notre Dame Payment Card Policy, cardholder data will not be transmitted using Wireless Technology, unless specifically approved and tunneled through a VPN. CHD will not be transmitted via email or other end user technologies.

 

Anti-Virus, Anti-Adware, and Anti-Spyware Protection

Anti-virus software must be deployed on all systems commonly affected by malicious software (particularly personal computers and servers).  Anti-virus programs must be capable of detecting, removing, and protecting against other forms of malicious software, including spyware and adware.  All anti-virus mechanisms must be kept current, actively running, and capable of generating audit logs.

Virtual Terminal Requirements

This standard applies to standalone as well as VM-based virtual terminals. Only PCs running Windows XP or Windows 7 may be used as virtual terminals. All systems must meet the following requirements


Basic System Configuration

  • Systems must be joined to the CCSP domain.
  • Systems must be connected the Cardholder data environment through an approved virtual terminal network connection.
  • Systems must:
    • receive GPO that applies Tripwire PCI Policy.
    • be connected to EPO for auditing/updating.
    • accept patches via SCCM.
    • configured to log to Q-Radar.
  • Auto logon is permissible for virtual terminal end users if access is only to an approved payment applications.

 

VM based Virtual Terminal Configurations

  • End users are restricted to only launching Virtual Machines(VM’s) (productivity and Credit Card VM’s)
  • VMware is configured to provide strong isolation between the VM’s.
    • No cutting and pasting between VMs.
    • No file sharing between VMs.
  • Separate physical network interface for in scope out of scope OS’s.
  • Host and credit card VMs are in scope and productivity VM is out of scope.
  • Auto logon with specifically configured CCSP account is permissible on host.

Payment Network Configurations

  •  Virtual Terminals will be shielded from the internet by the PCI central firewall through dedicated interfaces.
    • Firewall policy restricts access to approved OIT infrastructure and business partners.
  • Distributed using only applicable network hardware.
  • Virtual Terminal network jacks are configured to only recognize MAC addresses of approved payment devices.
  • Devices must be statically IP'ed with addresses assigned via the approved CCSP RFC process.

Applicability

This policy applies to all University of Notre Dame employees and students.