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.
