PCI-DSS Programming Guidelines

Objective

The objective of this document is to define programming guidelines for implementing PCI DSS standards.

Overview

The Payment Card Industry (PCI) Data Security Standard (DSS) provides a baseline of technical and operational requirements designed to protect cardholder data. PCI DSS applies to all entities involved in payment card processing – including merchants, processors, acquirers, issuers, and service providers, as well as all other entities that store, process or transmit cardholder data.

Below is a high-level overview of the 12 PCI DSS requirements.

Build and Maintain a Secure Network	1.     Install and maintain a firewall configuration to protect cardholder data 2.     Do not use vendor supplied defaults for system passwords and other security parameters
Protect Cardholder Data	3.     Protect stored cardholder data 4.     Encrypt transmission of cardholder data across open, public networks
Maintain a Vulnerability Management Program	5.     Use and regularly update anti-virus software or programs. 6.     Develop and maintain secure systems and applications.
Implement Strong Access and Control Measures	7.     Restrict access to cardholder data by business need to know 8.     Assign a unique ID to each person with computer access 9.     Restrict physical access to cardholder data
Regularly Monitor and Test Networks	10.  Track and monitor all access to network resources and cardholder data 11.  Regularly test security systems and processes
Maintain and Information Security Policy	12.  Maintain a policy that addresses information security for all personnel

PCI DSS Programing Guidelines

1.     Do not store sensitive authentication data after authorization (even if encrypted).

i)      Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data.

ii)     Do not store the card verification 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.

iii)    Do not store the personal identification number (PIN) or the encrypted PIN block.

	Data Element	Storage Permitted	Render Stored Account Data Unreadable?
Cardholder Data	Primary Account Number (PAN)	Yes	Yes
	Cardholder Name	Yes	No
	Service Code	Yes	No
	Expiration Date	Yes	No
Sensitive Authentication Data	Full Magnetic Stripe Data 2	No	Cannot store
	CAV2/CVC2/CVV2/CID	No	Cannot store
	PIN/PIN Block	No	Cannot store

2.     Mask PAN when displayed anywhere including portable digital media, backup files and in logs. (The first six and last four digits are the maximum number of digits to be displayed).

3.     Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks.

4.     Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.).

5.     Remove any custom application accounts, user IDs, and passwords before applications become active or are released to customers.

6.     Implement Role based security levels for user IDs and confirm that access rights for privileged user IDs are restricted to least privileges necessary to perform job responsibilities.

7.     Set passwords for first-time use and resets to a unique value for each user and change immediately after the first use.

8.     Immediately revoke access for any terminated users.

9.     Remove/disable inactive user accounts at least every 90 days.

10.  Change user passwords at least every 90 days.

11.  Require a minimum password length of at least seven characters.

12.  Use passwords containing both numeric and alphabetic characters.

13.  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.

14.  Limit repeated access attempts by locking out the user ID after not more than six attempts.

15.  If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

16.  Authenticate all access to any database containing cardholder data. This includes access by applications, administrators, and all other users.

17.  Restrict user direct access or queries to databases to database administrators.

18.  Logging requirements:

i)      All logs must be stored in database and flat file.

ii)     Data to store in log file:

·         User identification (Username and User IP Address)

·         Type of event

·         Date and time

·         Success or failure indication

·         Origination of event (URL, Server IP Address, Server Name, Request Method [get, head, post, etc.])

iii)    All state changing actions must be logged. Examples of state changing actions are transaction creation, data modification, etc.

iv)    All changes to user account access must be logged.

v)     All log in's, log outs, log in attempts must be logged.