What is PCI DSS?
PCI DSS - Payment Card Industry Data Security Standard, Version 3.0 as
of November 2013 is the latest regulation set forth by the PCI SSC (Security
Standards Council) [pcisecuritystandards.org]. PCI requirements apply to any
entity that touches Credit Card Data.
The intent of PCI is to provide guidelines to companies that process credit card
transactions.
There are 12 PCI Requirements and Assessment Procedures for PCI v3. The
official 112 page regulation can be found here:
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf
Below are the PCI requirements and where Data
Security applies*
PCI Regulation Overview

Who does the PCI regulation apply to?
- PCI requirements apply to any entity that touches Credit Card Data.
- Organizations that outsource their CDE or payment operations to third
parties are responsible for ensuring that the account data is protected by
the third party per the applicable PCI DSS requirements.
- Security services such as authentication servers
- Virtual systems (servers, computers, network components)
- Network components (firewalls, switches, routes, wireless access points,
etc)
- Servers
- Applications
- Any other component or devices located within or connected to the CDE
A good Data Security solution will integrate and work with all of
the above.
What Data does PCI apply to?
- Primary Account Number -Can
be stored *must be encrypted
- Cardholder Name -Can
be stored
- Expiration Date -Can
be stored
- Service Code -Cannot
store
- Magnetic Track Data -Cannot
store
- CAV2/CVC2/CVV2/CID -Cannot
store
- PINs/PIN Blocks -Cannot store
A good Data Security solution should be able to detect
account numbers, magnetic track data, security codes , and PINs.
Yearly assessment requirements
- Identify Cardholder Data Flow -many unknown data flows can be
discovered with a good Data Security tool
- Identify and Document the existence of Cardholder Data -Data
Security tools should be able to detect and report on the existence of PCI
data
- Maintain Documentation of how the PCI DSS scope was determined. (Scope =
Cardholder data flow and storage)
- Network Segmentation/ isolation of the CDE environment is
recommended but not required. If there is no segmentation then the entire
network is considered part of the CDE -a good Data Security too will be able
to help keep cardholder data from entering the non CDE network
- Outsourced service providers are required to undergo an annual onsite
assessment
Recommended Best Practices as listed in the regulation
- Monitor Security Controls -firewalls, IDS/IPS, Antivirus, file
integrity, access controls
- Detecting failures in security controls are detected and responded to in
a timely manner
- Review changes to the environment -new or changed systems and configs
- Formal Review of Org Changes -impact to PCI DSS due to changes in Org
Structure changes like mergers & acquisitions
- Periodic reviews of practices and procedures -audit logs, vulnerability
scan reports, firewall reviews, etc.
- Annually review hardware and software technologies for security
compliance
A good Data Security solution will perform numbers 2 and
5.
In Greater detail;
PCI DSS Requirements that apply to Data Security
solutions
Requirement 1; Install and maintain a firewall configuration to
protect cardholder data
Requirement |
Testing Procedure |
How Data Security Can Help |
1.13 Current
diagram that shows all cardholder data flows across the system and
networks |
Examine data flow diagram
and interview personnel to verify the diagram shows all data flows
and is kept current |
Use Network or Endpoint Data
Protection to uncover and validate data use & business processes |
Requirement 2; Do not use vendor-supplied defaults for system
passwords and other security parameters
Requirement 3; Protect stored cardholder data
3.1 Keep cardholder
data storage to a minimum by implementing data retention and disposal
policies, procedures, and processes that include at least the following
for all cardholder data (CHD) storage:
- Limiting data storage amount and retention time to that which is
required for legal, regulatory, and business requirements.
- Process for secure deletion of data when no longer needed
- Specific retention requirements for cardholder data
- Quarterly process for identifying and securely deleting stored
cardholder data that exceeds defined retention
|
3.1a Examine the data
retention and disposal policies, procedures, and processes to verify
they include at least the following:
- Legal, regulatory, and business requirements for data retention
including
- Specific requirements for retention of cardholder data for (for
example, cardholder data needs to be held for X period for Y
business reasons)
- 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
card holder data that exceeds defined retention requirements
3.1b Interview personnel to identify that
- All location of stored cardholder data are included in the data
retention and disposal process
- Either a quarterly automatic or manual process is in place to
identify and securely delete stored cardholder data
- The quarterly automatic or manual process is performed for all
locations of cardholder data
3.1c For a sample of system components that store cardholder
data:
- Examine files and system records to verify that the data stored
does not exceed the requirements defined in the data retention
policy
- Observer the deletion mechanism to verify data is deleted
securely
|
A Data Security Data at Rest (DAR) crawler
can be used to find Cardholder data and either move, change permissions,
encrypt, or secure delete. |
3.2 Do not store
sensitive authentication data after authorization (even if encrypted).
If sensitive authentication data is received, render all data
unrecoverable upon completion of the authorization process. It is
permissible for issuers and companies that support issuing services to
store sensitive authentication data if:
Sensitive
authentication data includes the data as cited in the following
Requirements 3.2.1 through 3.2.3:
|
3.2.a
For issuers and/or companies that support issuing services and store
sensitive authentication data, review policies and interview personnel
to verify there is a documented business justification for the storage
of sensitive authentication data.
3.2.b
For issuers and/or companies that support issuing services and store
sensitive authentication data, examine data stores and system
configurations to verify that the sensitive authentication data is
secured
3.2.c
For all other entities, if sensitive authentication data is received,
review policies and procedures, and examine system configurations to
verify the data is not retained after authorization
3.2.d
For all other entities, if sensitive authentication data is received,
review procedures and examine the processes for securely deleting the
data to verify that the data is unrecoverable.
|
Data Security tools can find
Authentication Data if it is being stored (DAR, or Data at Rest). Most
products can watch and block web transactions (Data in Motion) as well
as control how the data is used at the Endpoint (DIU, or Data in Use) |
3.2.1
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.
Note: In
the normal course of business, the following data elements from the
magnetic stripe may need to be retained:
To
minimize risk, store only these data elements as needed for business.
|
3.2.1
For a sample of system components, examine data sources including but
not limited to the following, and verify 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:
-
Incoming
transaction data
-
All logs
(for example, transaction, history, debugging, error)
-
History
files
-
Trace
files
-
Several
database schemas
-
Database
contents
|
Data Security tools can find Track Data if
it is being stored (DAR, or Data at Rest). Most products can watch and
block web transactions (Data in Motion) as well as control how the data
is used at the Endpoint (DIU, or Data in Use) |
3.2.2
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.
|
3.2.2
For a sample of system components, examine data sources, including but
not limited to the following, and verify 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, AV2 data) is not stored
after authorization:
-
Incoming
transaction data
-
All logs
(for example, transaction, history, debugging, error)
-
History
files
-
Trace
files
-
Several
database schemas
-
Database
contents
|
Data Security tools can find verification
codes, account numbers and PINs if they are being stored (DAR, or Data
at Rest). Most products can watch and block web transactions (Data in
Motion) as well as control how the data is used at the Endpoint (DIU, or
Data in Use) |
3.2.3
Do not store the personal identification number (PIN) or the encrypted
PIN block
|
3.2.3
For a sample of system components, examine data sources, including but
not limited to the following and verify that PINs and encrypted PIN
blocks are not stored after authorization:
-
Incoming
transaction data
-
All logs
(for example, transaction, history, debugging, error)
-
History
files
-
Trace
files
-
Several
database schemas
-
Database
contents
|
Data Security tools can find verification
codes, account numbers and PINs if they are being stored (DAR, or Data
at Rest). Most products can watch and block web transactions (Data in
Motion) as well as control how the data is used at the Endpoint (DIU, or
Data in Use) |
3.4
Render PAN unreadable anywhere it is stored (including on portable
digital media, backup media, and in logs) by using any of the following
approaches:
-
One-way
hashes based on strong cryptography, (hash must be of the entire
PAN)
-
Truncation (hashing cannot be used to replace the truncated segment
of
-
PAN)
-
Index
tokens and pads (pads must be securely stored)
-
Strong
cryptography with associated key-management processes and procedures
Note: It
is a relatively trivial effort for a malicious individual to reconstruct
original PAN data if they have access to both the truncated and hashed
version of a PAN. Where hashed and truncated versions of the same PAN
are present in an entity’s environment, additional controls should be in
place to ensure that the hashed and truncated versions cannot be
correlated to reconstruct the original PAN
|
3.4.a
Examine documentation about the system used to protect the PAN,
including the vendor, type of system/process, and the encryption
algorithms (if applicable) to verify that the PAN is rendered unreadable
using any of the following methods:
-
One-way
hashes based on strong cryptography,
-
Truncation
-
Index
tokens and pads, with the pads being securely stored
-
Strong
cryptography, with associated key-management processes and
procedures
3.4.b
Examine several tables or files from a sample of data repositories to
verify the PAN is rendered unreadable (that is, not stored in
plain-text)
3.4.c
Examine a sample of removable media (for example, back-up tapes) to
confirm that the PAN is rendered unreadable.
3.4.d
Examine a sample of audit logs to confirm that the PAN is rendered
unreadable or removed from the logs.
|
|
3.4.1
If disk encryption is used (rather than file-or column-level database
encryption), logical access must be managed separately and independently
of native operating system authentication and access control mechanisms
(for example, by not using local user account databases or general
network login credentials).
Decryption keys must not be associated with user accounts.
|
3.4.1.a If disk encryption is used, inspect the configuration and
observe the authentication process to verify that logical access to
encrypted file systems is implemented via a mechanism that is separate
from the native operating system’s authentication mechanism (for
example, not using local user account databases or general network login
credentials).
3.4.1.b Observe processes and interview personnel to verify that
cryptographic keys are stored securely (for example, stored on removable
media that is adequately protected with strong access controls)
3.4.1.c Examine the configurations and observe the processes to
verify that cardholder data on removable media is encrypted wherever
stored
Note: If
disk encryption is not used to encrypt removable media, the data stored
on this media will need to be rendered unreadable through some other
method
|
|
Requirement 4; Encrypt transmission of cardholder data across open,
public networks
4.1
Use strong cryptography and security protocols (for example, SSL/TLS,
IPSEC, SSH, etc.) to safeguard sensitive cardholder data during
transmission over open, public networks, including the following:
-
Only
trusted keys and certificates are accepted.
-
The
protocol in use only supports secure versions or configurations.
-
The
encryption strength is appropriate for the encryption methodology in
use
Examples
of open, public networks include but are not limited to:
-
The
Internet
-
Wireless
technologies, including 802.11 and Bluetooth
-
Cellular
technologies, for example, Global System for Mobile communications (GSM),
Code division multiple access (CDMA)
-
General
Packet Radio Service (GPRS).
-
Satellite communications
|
4.1.1
Identify all wireless networks transmitting cardholder data or connected
to the cardholder data environment. Examine documented standards and
compare to system configuration settings to verify the following for all
wireless networks identified:
-
Industry
best practices (for example, IEEE 802.11i) are used to implement
strong encryption for authentication and transmission.
-
Weak
encryption (for example, WEP, SSL version 2.0 or older) is not used
as a security control for authentication or transmission.
|
|
4.2
Never send unprotected PANs by end-user messaging technologies (for
example, e-mail, instant messaging, chat, etc.).
|
4.2.a
If end-user messaging technologies are used to send cardholder data,
observe processes for sending PAN and examine a sample of outbound
transmissions as they occur to verify that PAN is rendered unreadable or
secured with strong cryptography whenever it is sent via end-user
messaging technologies
4.2.b
Review written policies to verify the existence of a policy stating
that unprotected PANs are not to be sent via end-user messaging
technologies
|
|
4.3
Ensure that security policies and operational procedures for encrypting
transmissions of cardholder data are documented, in use, and known to
all affected parties.
|
4.3
Examine documentation interview personnel to verify that security
policies and operational procedures for encrypting transmissions of
cardholder data are:
|
|
Requirement 5; Protect all systems against malware and regularly
update antivirus software
Requirement 6; Develop and maintain secure systems and applications
6.5.4
Insecure communications |
6.5.4
Examine software-development policies and procedures and interview
responsible personnel to verify that insecure communications are
addressed by coding techniques that properly authenticate and encrypt
all sensitive communications |
|
Requirement 7; Restrict access to cardholder data by business need
to know
7.1
Limit access to system components and cardholder data to only those
individuals whose job requires such access
|
7.1
Examine written policy for access control, and verify that the policy
incorporates 7.1.1 through 7.1.4 as follows:
-
Defining
access needs and privilege assignments for each role
-
Restriction of access to privileged user IDs to least privileges
necessary to perform job responsibilities
-
Assignment of access based on individual personnel’s job
classification and function
-
Documented approval (electronically or in writing) by authorized
parties for all access, including listing of specific privileges
approved
|
|
7.1.3
Assign access based on individual personnel’s job classification and
function
|
7.1.3
Select a sample of user IDs and interview responsible management
personnel to verify that privileges assigned are based on that
individual’s job classification and function
|
|
7.2
Establish an access control system for systems components that
restricts access based on a user’s need to know, and is set to “deny
all” unless specifically allowed.
This
access control system must include the following
7.2.1
Coverage of all system components
7.2.2
Assignment of privileges to individuals based on job classification
and function
7.2.3
Default “deny-all” setting
|
7.2
Examine system settings and vendor documentation to verify that an
access control system is implemented as follows
7.2.1
Confirm that access control systems are in place on all system
components.
7.2.2
Confirm that access control systems are configured to enforce
privileges assigned to individuals based on job classification and
function
7.2.3
Confirm that the access control systems have a default “deny-all”
setting.
|
|
Requirement 8; Identify and authenticate access to system
components
8.1.3
Immediately revoke access for any terminated users
|
8.1.3.a Select a sample of users terminated in the past six months,
and review current user access lists—for both local and remote access—to
verify that their IDs have been deactivated or removed from the access
lists
8.1.3.b Verify all physical authentication methods—such as, smart
cards, tokens, etc.—have been returned or deactivated
|
|
8.7
All access to any database containing cardholder data (including access
by applications, administrators, and all other users) is restricted as
follows:
-
All user
access to, user queries of, and user actions on databases are
through programmatic methods.
-
Only
database administrators have the ability to directly access or query
databases
-
Application IDs for database applications can only be used by the
applications (and not by individual users or other non-application
processes)
|
8.7.a
Review database and application configuration settings and verify that
all users are authenticated prior to access
8.7.b
Examine database and application configuration settings to verify that
all user access to, user queries of, and user actions on (for example,
move, copy, delete), the database are through programmatic methods only
(for example, through stored procedures)
8.7.c
Examine database access control settings and database application
configuration settings to verify that user direct access to or queries
of databases are restricted to database administrators.
8.7.d
Examine database access control settings, database application
configuration settings, and the related application IDs to verify that
application IDs can only be used by the applications (and not by
individual users or other processes)
|
|
Requirement 9; Restrict physical access to cardholder data
Requirement 10; Track and monitor all access to network resources
and cardholder data
10.1
Implement audit trails to link all access to system components to each
individual user.
|
10.1
Verify, through observation and interviewing the system
administrator, that:
|
|
10.2
Implement automated audit trails for all system components to
reconstruct the following events
|
10.2
Through interviews of responsible personnel, observation of audit
logs, and examination of audit log settings, perform the following
|
|
10.2.1
All individual user accesses to cardholder data
|
10.2.1
Verify all individual access to cardholder data is logged.
|
|
10.3
Record at least the following audit trail entries for all system
components for each event:
10.3.1
User identification
10.3.2
Type of event
10.3.3
Date and time
10.3.4
Success or failure indication
10.3.5
Origination of event
10.3.6
Identity or name of affected data, system component, or resource
|
10.3
Through interviews and observation of audit logs, for each auditable
event (from 10.2), perform the following:
10.3.1
Verify user identification is included in log entries
10.3.2
Verify type of event is included in log entries
10.3.3
Verify date and time stamp is included in log entries
10.3.4
Verify success or failure indication is included in log entries
10.3.5
Verify origination of event is included in log entries
10.3.6
Verify identity or name of affected data, system component, or
resources is included in log entries
|
|
10.6.1
Review the following at least daily
10.6.1
Review the following at least daily:
-
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
(for example, firewalls, intrusion-detection
systems/intrusion-prevention systems (IDS/IPS), authentication
servers, e-commerce redirection servers, etc.)
|
10.6.1.a Examine security policies and procedures to verify that
procedures are defined for reviewing the following at least daily,
either manually or via log tools:
-
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
(for example, firewalls, intrusion-detection
systems/intrusion-prevention systems (IDS/IPS), authentication
servers, e-commerce redirection servers, etc.)
10.6.1.b Observe processes and interview personnel to verify that
the following are reviewed at least daily:
-
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
(for example, firewalls, intrusion-detection
systems/intrusion-prevention systems (IDS/IPS), authentication
servers, e-commerce redirection servers, etc.)
|
|
10.8
Ensure that security policies and operational procedures for monitoring
all access to network resources and cardholder data are documented, in
use, and known to all affected parties
|
10.8
Examine documentation interview personnel to verify that security
policies and operational procedures for monitoring all access to network
resources and cardholder data are:
|
|
Requirement 11; Regularly test security systems and process
Requirement 12; Maintain a policy that addresses information
security for all personnel
12.5.5
Monitor and control all access to data
|
12.5.5
Verify that responsibility for monitoring and controlling all access to
data is formally assigned.
|
|
12.6
Implement a formal security awareness program to make all personnel
aware of the importance of cardholder data security.
|
12.6.a
Review the security awareness program to verify it provides awareness to
all personnel about the importance of cardholder data security.
|
|
*Content pulled directly from the PCI_DSS_V3.pdf from
pcisecuritystandards.org
|