Implementation Guide for UCSD Departments Accepting Credit Card Payments

Accepting credit card payments comes with a significant security risk.  Departments considering this method of payment must be willing to accept certain system and configuration restrictions to protect the security of the UC network as a whole.  Alternatively, departments may elect to shift the responsibility for compliance by using a UCSD-approved third party to manage their accounts.

The UCSD rules for accepting credit card payments are modeled after the Payment Card Industry (PCI) Security Standards created by the Visa, MasterCard, American Express and Discover corporations.  Failure to comply with these rules may result in compromised security, on-site audits by independent auditors, and significant monetary fines for the individual department and University at large.  Since the consequences for the entire UCSD community are severe if a department receives a fine or citation due to non-compliance, departments should strongly consider using a third party to process credit card payments or a simple, offline system. 

Recommendations

The UCSD Bookstore (contact John Turk, Bookstore Director, jturk@ucsd.edu, (858) 534-7323) is the recommended place from which to sell tangible goods.

All Machines

All machines on the campus network, whether or not they are involved in credit card sales, must comply with the following set of requirements. You will also need to comply with the appropriate set of requirements below, depending on which of the credit card payment models you select.

Machines must:

• Meet Minimum Network Security Standards.
• Be registered with Network Operations with an up-to-date technical contact.

Redirecting Server (formerly known as a "Type 3")

A Web server uses a gateway application such as a Web page to collect, store, and transmit data instead of retaining it on the server itself.  The gateway application may be managed by a third party who retains responsibility for compliance, taking the burden from the department itself.  Most departments should use this method.

• Must configure host firewall to at most allow SSH, HTTP, HTTPS, and VPN incoming.
• The gateway provider must be PCI compliant.
• The vendor should supply documentation of their PCI compliance.
• This documentation should be reviewed and updated annually.
• Must use software that has security patches and must apply them within a week of availability.
• Must have anti-spyware software if it is available for the platform.
• Must enable verbose OS, Web server and application logging.
• Logs must be able to show user, type of event, date and time with time zone, success or failure origination of event, and identity system component, affected data, or resource.
• Clocks must be synchronized using NTP (Network Time Protocol — server can be set to ntp.ucsd.edu).
• Logs should be archived to a central log server or read-only media.
• Logs should have access control to restrict access to only those with a true business need.
• Archived logs should be monitored with Tripwire.
• Logs must be reviewed regularly, at least three times a week.
• Logs should be retained for at least three months.
• Must be registered with Network Operations as a "redirecting credit card machine" and have an up-to-date technical contact.
• Registration must be reviewed and updated annually at least.
• Must supply Network Operations Security with OS user credentials for scanning.
• Must allow for comprehensive scanning from Network Operations.
• Scanning will occur on a regular scheduled basis.
• Reports will be made available to technical contacts.
• Must allow for emergency blocking on vulnerability.
• Any hint that a machine is compromised will invoke the CIRT process.
• Active use of exploits in the wild for a vulnerability on a machine are grounds for immediate blocking.
• No unauthorized or unnecessary software allowed, such as P2P software, instant messaging software, or e-mail software.
• Must use Tripwire to monitor Web content and Web server configuration for unauthorized changes.
• Must have network ACLs or VLAN and network firewall to back up host firewall.
• Must not be used for multiple purposes or as a client workstation.
• Should be physically secure. See Payment Card Industry's Data Security Standards (note: this is a downloadable PDF document from usa.visa.com) for guidelines.
• Services should run with the least privilege necessary.
• Change passwords after any employee turnover.
• Identify all users with a unique username.

Offline System

A terminal or computer delivers data to the credit card processor over analog telephone lines.  Information is not retained in the system so this method requires fewer security precautions.  This is the simplest method but it is also the slowest and least flexible.

This activity is characterized by a terminal or computer that is never connected to a network and uses a dial-out mechanism to transmit credit card information to the processor.

Client Processor (formerly known as a "Type 2")

A terminal or computer transmits data to the credit card processor but does not offer any network services or store data.  The terminal must be physically isolated and accessible only to authorized personnel.

• Must configure host firewall to prevent incoming connections to all ports.
• Must apply security patches within two weeks of availability.
• Must have anti-spyware software if it is available for the platform.
• Must enable verbose logging at the operating system level — logs must be able to show user, type of event, date and time with time zone, success or failure origination of event, and must identify system component, affected data, or resource.
• Clocks must be synchronized using NTP (Network Time Protocol — server can be set to ntp.ucsd.edu).
• Logs must be stored for at least two months .
• Must be registered with Network Operations as a "client processor credit card machine" and have an up-to-date technical contact.
• Registration should be reviewed and updated annually at minimum.
• Should be part of campus Active Directory.
• Should use Network Operations Active Directory Policy for Client Processors.  (Note: this policy is currently being developed).
• If not part of campus Active Directory, Network Operations Active Directory Policy for Client Processors should be imported and kept up to date for client processor hosts.  (Note: this policy is currently being developed).
• Must supply Network Operations Security with OS user credentials for scanning.
• Must allow for comprehensive scanning from Network Operations.
• Scanning will occur on a regularly scheduled basis.
• Reports will be made available to technical contacts.
• Must allow for emergency blocking on vulnerability.
• Any hint that a machine is compromised will invoke the forensic mechanism.
• Active use of exploits in the wild for a vulnerability on a machine are grounds for immediate blocking.
• No unauthorized or unnecessary software allowed, such as P2P software or instant messaging software.
• E-mail clients are permitted but file attachments must be virus scanned and risky file types must be blocked.
• Must live in special VLAN (cordoned-off network area) for client processor machines (file a CSR with ACT to make this request).
• User accounts should not be administrative users, and administrative access should only be used when required.

Secure Infrastructure (formerly known as a "Type 4")

An internal database or system (Web application, mail system, and file server, etc.) that collects, stores, and transmits credit card data.  Security prerequisites for this type of system are extremely strict and the compliance requirements are not negotiable.  Departments considering using this method must have the technical personnel and equipment required to comply with the security restrictions, annual checks, and regular updates as needed.

• Must uninstall software for unnecessary services.
• Hosts must be organized into two firewalled VLANs: one VLAN for externally accessible servers, and one VLAN for servers accessible only to the externally accessible servers. 
• Firewall rules at the host and network levels must be created to limit traffic flow to only necessary hosts and services between the external and internal VLANs.
• Must configure host firewall to allow at most SSH, HTTP, HTTPS, and VPN.
• All configurations and changes to firewall rules must be documented and approved by the designated technical contact.
• Only store credit card data when absolutely required by the business.
• Never store full contents of any track on the magnetic stripe.
• Never store the card validation code.
• Never store the card's PIN Verification Value.
• Must mask card number display.
• Stored card data must be rendered unreadable by one of the methods below.
• One-Way Hashes (that is, credit card numbers are converted into a fixed string of digits/text, and it's not possible to derive the original card number from the string). SHA-256 is the preferred mechanism.
• Truncation (only a portion of the card number is stored)
• Strong Encryption, with documented and strong key management practices.
• Never send credit card information over e-mail.
• Must use software that has security patches and must apply them within a week of availability.
• No use of wireless communication or wireless transmission of card data.
• All administrative communication with systems must be encrypted over the network.
• Must use at least 128bit SSL, PPTP or IPSEC to encrypt cardholder data over the network.
• Must enable verbose OS, Web server and application logging; logs must be able to show user, type of event, date and time with time zone, success or failure origination of event, and identity system component, affected data, or resource.
• Clocks must be synchronized using NTP (Network Time Protocol — server can be set to ntp.ucsd.edu).
• Logs should be archived to a central log server or read only media.
• Logs should have access control to restrict access to only those with a true business need.
• Archived logs should be monitored with Tripwire.
• Logs must be reviewed daily.
• Logs should be retained for at least three months.
• Must be registered with Network Operations as a "secure infrastructure" credit card machine and must have an up-to-date technical contact.
• Must allow for comprehensive scanning from Network Operations.
• Must allow for emergency blocking on vulnerability.
• Must use Tripwire to monitor OS and application binaries and configuration as well as Web server content.
• Must not be used for multiple purposes or as a client workstation.
• Must have a network IDS.
• Must have log, Tripwire and IDS review practices in place.
• Services should run with the least privilege necessary.
• Servers must implement only one primary function. (e.g., Web Servers, Database Servers and DNS should be implemented on separate servers)
• Unusual activity or suspected breach will invoke CIRT team immediately.
• If the host is part of an Active Directory or a domain, that infrastructure must also be PCI compliant.
• These hosts shouldn’t be part of campus Active Directory.
• Any hosts that connect to the domain or directory must be PCI compliant.
• Must be physically secure. See Payment Card Industry's Data Security Standards (note: this is a downloadable PDF document from usa.visa.com) for guidelines.
• Develop applications using industry best practices
• Test all security patches, system software and configuration changes before deployment.
• Separate development, test and production environments.
• No use of production data (real credit card numbers) in test or development.
• Remove test data and accounts before moving to production.
• Remove test backdoor accounts and capabilities before moving to production.
• Test code for security issues (see OWASP top ten at www.owasp.org).
• Use a change control procedure.
• Document reason, scope and functionality of any changes.
• Test and verify any changes.
• Sign off on changes by appropriate parties before moving to production.
• Document and have back out procedures.
• Implement strong access control for administrative users.
• All users must identify themselves with a unique username
• Must use either a password, token device or biometric to identify users.
• Two-factor authentication must be used for remote access.
• First-time passwords must be a unique value for all new users and must be changed upon first use.
• Remove inactive user accounts.
• Enable vendor accounts only when needed.
• Change passwords at least every 90 days.
• Lock out user IDs for at least 30 minutes after six failed attempts.
• Time out idle sessions after 15 minutes.