Copyright 2014, Faulkner Information
Services. All Rights Reserved.
Docid: 00011448
Publication Date: 1404
Report Type: STANDARD
Preview
According to the annual report on US General Purpose Credit Cards, consumer
and commercial credit, debit, and prepaid cards issued in the United States combined to
generate $4.077 trillion in spending at merchants in 2013, up 7.9 percent from 2012.
The Payment Card Industry has long recognized the importance of protecting personal information and personal
data, and continues to evolve standards and applications designed to meet new
threats and challenges. PCI Data Security Standards address the concerns of consumers
and merchants to maintain the authenticity and integrity of payment card
information with guidelines that protect the vital interests of
their customers.
When consumers offer their bank card at the point of sale, over the Internet, on the phone, or through
the mail, they want assurance their account information is safe.
Unlike the medical industry where regulations to
ensure the privacy of medical
information are common place, the nature of e-Commerce
as a ubiquitous and free market phenomena supports an incentive for the entire
e-Commerce and payment card industry to remain unfettered by
government-imposed oversight.
As a result, the Payment Card Industry Security Standards Council (PCI
SSC),
founded by American Express, Discover Financial Services, JCB (formerly know
as
the Japan Credit Bureau), MasterCard Worldwide, and Visa International, was
formed with all five payment brands sharing equally in the council’s
governance.
Each entity has equal input to the PCI SSC while also maintaining
independent control for compliance and validation of standards to their respective
service
providers and merchants.
PCI Data
Security Standards (DSS) v.3.0, outline the current guidelines for the
deployment of PCI data over the
Wireless LAN (WLAN).
The PCI SSC incorporated into PCI DSS the
recommendation
for Intrusion Detection Systems/Wireless Intrusion Prevention System
(IDS/WIPS) to automate wireless scanning for
large organizations. Wireless guidelines clearly define how wireless
security
applies to PCI DSS v2.0 compliance. In addition, PCI
DSS v3.0 provides additional clarification, guidance, and information of
evolving standards not included in the previous v2.0 standard.
Exponential growth and adoption of mobile and cloud computing applications
is creating
new
areas of security risks for merchants and the payment card industry. PCI SSC
began addressing this with the release of PCI Mobile Payment Acceptance Security
Guidelines v 1.0 in February 2013. While not yet fully mandated by PCI SSC, the
guidelines and best practices published in the v 1.0 documents are produced to
help
educate and create awareness of the challenges faced by the payment industry. However, the best of security practices and procedures can never replace
a
"buyer beware" mentality. Using caution and common sense in
providing personal
and financial information can mitigate the occurrences of fraud and
malfeasance.
In addition, a Cloud Special Interest Group has been formed by PCI SSC to
address emerging security issues related to cloud computing. There are a number
of factors to be considered when migrating to cloud services, and organizations
need to clearly understand their needs before they can determine if and how they
will be met by a particular solution or provider. Evaluations of risks and benefits may change as
cloud
technology becomes more established and its implications become better
understood .
Build and
Maintain a Secure Network
(requirements 1 and 2)
Protect
Cardholder Data
(requirements 3 and 4)
Maintain a
Vulnerability Management Program (requirements 5 and 6)
Implement
Strong Access Control Measures
(requirements 7, 8 and 9)
Regularly
Monitor and Test Networks
(requirements 10 and 11)
Maintain an
Information Security Policy
(requirement 12)
PCI Security Standard Framework
The latest version of the PCI DSS is Version 3.0 released in November 2013 and is active from January 1, 2014 to
December 31, 2016. In general, PCI DSS v3.0 provides
additional clarification, guidance, and information of evolving standards not
included in v2.0. Table 2 provides a summary of the changes from PCI DSS v2.0 to
PCI DSS v3.0.
Table 2. Summary of the Changes from PCI DSS v2.0 to PCI DSS v3.0
Table 2. Summary of the Changes from PCI DSS v2.0 to PCI DSS v3.0
Section PCI DSS v2.0
Section PCI DSS v3.0
Change
Type
PCI DSS
Applicability
Information
PCI DSS
Applicability
Information
Clarified that SAD must not be
stored after authorization
even if there is no PAN in the
environment
Clarification
Relationship
between PCI
DSS and PA
– DSS
Relationship
between PCI
DSS and PA –
DSS
Clarified that all applications
that store, process, or transmit
cardholder data are in scope for
an entity’s PCI DSS assessment,
even if PA – DSS validated.
Clarified PCI DSS applicability
to payment application vendors.
Clarification
Scope of
Assessment for
Compliance with
PCI DSS
Requirements
Scope of PCI
DSS
Requirements
Added examples of system
components, and added guidance
about how to accurately
determine the scope of the
assessment. Clarified the intent
of segmentation. Clarified
responsibilities of both the
third party and their customers
for scoping and coverage of PCI
DSS requirements, and clarified
the evidence that third parties
are expected to provide for
their customers to be able to
verify the scope of the third
party’s PCI DSS assessment.
Additional Guidance
Implementing
PCI DSS into
Business – as –
Usual Processes
New section to provide “business
as usual” guidance for
implementing security into
business – as –
usual (BAU) activities to
maintain on – going PCI DSS
compliance. Note that this
section includes recommendations
and guidance only, not new PCI
DSS requirements.
Additional Guidance
Assessment
Procedures
Added new heading to separate
PCI DSS scoping section from
sampling section
Clarification
Sampling of
Business
Facilities/
System
Components
For Assessors:
Sampling of
Business
Facilities/
System
Components
Enhanced sampling guidance for
assessors
Additional Guidance
Instructions and
Content for
Report on
Compliance
Instructions and
Content for
Report on
Compliance
Former content relocated to
separate documents – PCI DSS
ROC Template and PCI DSS ROC
Reporting Instructions
Clarification
PCI DSS
Compliance –
Completion Steps
PCI DSS
Assessment
Process
Updated section to focus on
assessment process rather than
documentation.
Clarification
Detailed
PCI DSS
Requirements
and Security
Assessment
Procedures
Detailed
PCI DSS
Requirements
and Security
Assessment
Procedures
At the start of this section,
added language to define the
column headings in this section,
and
removed references to “In
Place,” “Not In Place” and
“Target Date/Comments” columns.
Clarification
Continued in v3.0, there are no less that 64
descriptors containing 200 sub-descriptors. The PCI DSS framework, at a
minimum,
helps to categorize the process of PCI DSS compliance so that even the
smallest
of merchant or payment processors can have an intelligible and understandable
compliance guideline. The PCI DSS framework and descriptor general
definitions
are as follows:
Build and Maintain a Secure Network
Requirement 2: Do not use vendor-supplied defaults for
system passwords and
other security parameters
Hackers often use vendor
default passwords and other vendor default settings to compromise systems.
These passwords and settings are well known in hacker communities and
easily
determined via public information.
Protect Cardholder Data
Minimizing risk due to
interception of protected data is the intent of requirement 3. Encryption
is a
critical component of cardholder data protection. With encryption
cryptography, data is rendered unreadable and unusable unless the proper
decrypting key is known. All methods of protecting stored data should be
considered as potential risk mitigation opportunities. Examples include,
storing cardholder data unless absolutely necessary, truncating cardholder
data if full PAN is not needed, and not sending PAN in unencrypted
e-mails.
Requirement 5: Use and regularly update anti-virus
software
Many vulnerabilities and malicious viruses enter the
network
via e-mail activities, file transfers and other employee activities.
Anti-virus software must be used on all systems commonly affected by
viruses
to protect systems from malicious software.
Many system
vulnerabilities are fixed by vendor-provided security patches. All systems
must have the most recently released and appropriate software patches to
protect against exploitation by employees, external hackers, and viruses.
For
in-house developed applications, numerous vulnerabilities can be avoided
by
using standard system development processes and secure coding
techniques.
Implement Strong Access Control Measures
Requirement 8: Assign a unique ID to each person with
computer access
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.
Requirement 10: Track and monitor all access to network
resources and cardholder data
The presence of logs in all environments allows thorough
tracking, analysis and audits in the event that something does go wrong.
Determining the cause of a compromise is very difficult without system
activity logs.
Requirement 12: Maintain a policy that addresses
information
security
Security policy establishes a strong baseline for
organizations and informs employees what is expected of them. All
employees
should be aware of the sensitivity of data and their responsibilities for
protecting it as well as changes to and updates applying to all policy
activity.
In addition to the twelve requirements in the PCI DSS, the PCI Security
Standards
also include:
PIN Entry Device (PED) Security Requirements- PCI PED applies to
manufacturers who specify and implement device characteristics and
management
for personal identification number (PIN) entry terminals used for payment
card
financial transactions. Merchants should use only PIN entry devices that
are
tested and approved by the PCI SSC. As of April 2014, 751 PEDs from
over
150
vendors have been
authorized by the PCI SSC are listed at:
PCI Approved PIN Entry Devices.
Payment Application Data Security Standard (PA-DSS) – The PA-DSS is
for
software developers and integrators of payment applications that store,
process or transmit cardholder data as part of authorization or settlement
when these applications are sold, distributed or licensed to third
parties.
Most card brands encourage merchants and third party agents to use payment
applications that are validated independently by a PA-QSA company and
accepted
for listing by the PCI SSC. As of April 2014, a validated list of 884 payment
applications for new deployments and 2108 payment applications for existing
deployments from over 400 vendors are listed at:
PA-DSS Validated Payment Applications.
Point-to-point Encryption (P2PE) v1.1:
Introduced at the end of 2011 as P2PE v1.0, P2PE was updated to v1.1 and
published in April 2012. P2PE is an optional program to provide a
comprehensive set of security requirements for P2PE solution providers to
validate their hardware-based solutions, and may help reduce the PCI DSS
scope of merchants using such solutions. P2PE is a cross-functional program
that results in validated solutions incorporating the PTS Standards,
PA-DSS,
PCI DSS, and the PCI PIN Security Standard.
Merchant Compliance
Merchants who store, process, or transmit cardholder data are required
through their acquirers (e.g. banks or other collecting/processing/scanning
institutions) to validate compliance with the PCI DSS. Acquirers are
responsible for ensuring that all of their merchants comply with the PCI DSS
requirements. However, there are differing levels of collection
activity
depending of the size and type of merchant which can impact the merchant’s
ability to comply with the PCI DSS. Knowing this, the PCI SSC, has
established a
methodology of merchant levels through which merchants can identify their
level
of activity and an associated level of compliance validation and compliance
timelines.
All merchants will fall into one of the four merchant levels based on
payment
card transaction volume over a 12-month period. Transaction volume is based
on
the aggregate number of payment card transactions (credit, debit and
prepaid) from the merchant. Merchant levels designated and identified as
either
one of four different levels. Table 3 depicts the PCI DSS Merchant Levels.
Table 3. PCI DSS Merchant
Levels
Table 3. PCI DSS Merchant
Levels
Merchant Level
Level Definition
1
Any merchant,
"regardless of acceptance channel, processing over
6,000,000 Visa transactions per year.
Any merchant that has suffered a hack or an
attack that resulted
in an account data compromise.
Any
merchant that Visa, at its sole discretion, determines should meet the
Level 1 merchant requirements to minimize risk to the Visa system.
Any merchant identified by any other payment
card brand.
2
Any merchant-regardless of acceptance
channel-processing
1,000,000 to 6,000,000 Visa transactions per year.
3
Any merchant processing 20,000 to
1,000,000 Visa e-commerce
transactions per year.
4
Any merchant processing fewer than 20,000
Visa e-commerce
transactions per year, and all other merchants-regardless of
acceptance
channel-processing up to 1,000,000 Visa transactions per
year.
In addition to adhering to the PCI DSS, compliance validation is
required for
Level 1, Level 2, and Level 3 merchants, and may be required for Level 4
merchants. It is the expectation of the card issuer, for all acquirers and
merchant levels 1, 2, 3, existing and new, to be compliant within the set
due
dates as established by the PCI CCS and that level 4 merchants follow within
the
due date of guidelines of their representative acquirer. Table 4 lists
the
PCI
DSS Compliance Requirements.
Table 4. PCI
DSS Compliance Requirements
Table 4. PCI
DSS Compliance Requirements
Level
Validation Action
Validated By
1
Annual
On-site PCI Data Security Assessment and
Quarterly
Network Scan
Qualified
Security Assessor or Internal Audit if signed by Officer of the
company
Approved
Scanning Vendor
2
Annual PCI
Self-Assessment Questionnaire and
Quarterly
Network Scan
Merchant
Approved Scanning Vendor
3
Annual PCI
Self-Assessment Questionnaire and
Quarterly
Network Scan
Merchant
Approved
Scanning Vendor
4
Annual PCI
Self-Assessment Questionnaire and
Quarterly
Network Scan
Merchant
Approved
Scanning Vendor
In December 2013, Visa released statistics on merchant compliance with the
Payment Card Industry (PCI) Data Security Standard (DSS). Visa reported that as
of the end of 2013, 97 percent of large merchants (more than 6 million transactions)
were PCI DSS-compliant (unchanged from December 2012) and 83 percent of midsize merchants (1 – 6 million
transactions) were PCI DSS-compliant
(compared
with 90 percent at the end of 2011). These two merchant categories continue to
represent
approximately 63 percent of Visa’s total transaction volume. In addition 100
percent of both
Level 1 and 2 Visa merchants were validated as to not storing prohibited data in
their systems.
Visa has also
developed
the PCI Compliance Acceleration Program to provide financial incentives and
establish enforcement provisions for acquirers to ensure their merchants
validate PCI DSS compliance. To keep up pressure for meeting compliance and validation due dates, card
issuers
are levying fines to and through acquirers to force the respective
merchants into compliances. Payment card companies are steadily increasing
fines
on banks that process transactions for noncompliant merchants. Visa will
fine
acquirers between $5,000 and $25,000 a month for each Level 1 and 2 merchant
who
has not validated. Acquirers failing to provide confirmation that their
Level 1
and 2 merchants are not storing full track data, CVV2, or PIN data face
fines up
to $10,000 a month per merchant, subject to escalation.
Call Center Compliance Issues
PCI DSS standards define requirements for the back end storage of
personal
information, however, the
PCI SSC does not have the same level of definition for front end data,
whether through Web sites,
Interactive Voice Response (IVR) systems or call center agents. In a
call
center, customers read their credit card information,
CVV codes, and
expiration dates to call center agents. There are few controls which prevent
the
agent from
skimming (credit card fraud) this information with a recording device or
a
computer or physical note pad. Home-based telephone agents pose an
additional
level of challenges, requiring the company to secure the channel from the
home-based agent through the call center hub to the retailer applications.
To address some of these concerns, on January 22, 2010 the
PCI SSC issued a revised FAQ about call center recordings. It is a
violation
of PCI DSS requirement 3.2 to store any sensitive authentication data,
including
card validation codes and values, after authorization even if encrypted. It
is
therefore prohibited to use any form of digital audio recording (using
formats
such as wav, mp3 etc) for storing CAV2, CVC2, CVV2 or CID codes after
authorization if that data can be queried; recognizing that multiple tools
exist
that potentially could query a variety of digital recordings.
PCI DSS Wireless/Mobile/Cloud Guidelines
The current wireless guidelines for PCI DSS
recommend the use of Wireless Intrusion
Prevention System (WIPS) to automate wireless scanning for large
organizations.
Wireless guidelines clearly define how wireless security applies to PCI DSS
v3.0
compliance.
PCI DSS wireless requirements can be broken down into the
following two primary categories.
Generally applicable wireless requirements: These are
requirements that all organizations should have in place to protect their
networks from attacks via rogue or unknown wireless access points (APs)
and
clients.
Requirements applicable for in-scope wireless networks: These are
requirements that all organizations that transmit payment card information
over wireless technology should have in place to protect those systems.
The DSS Wireless guidelines apply to the
deployment of
Wireless LAN (WLAN) in cardholder data environments (CDE). A CDE is defined
as a
network environment that possesses or transmits credit card data. WLANs are
highly susceptible to eavesdropping and intrusion. The DSS Wireless
Guidelines
provide recommendation to configurations and policies that include the
following:
Secure Deployment
Requirements
Change default passwords and SSIDs on
wireless devices.
Enable WiFi Protected Access (WPA) or WPA2
security. Set up APs in WPA or
WPA2 mode with 802.1X authentication and AES encryption. Use of Wired
Equivalent Privacy (WEP) in CDE is
not allowed after June 30, 2010.
Restrict physical access to known wireless
devices.
Archive wireless access centrally using a
WIPS for 1 year.
Review wireless access logs daily.
Develop usage policies to list all
wireless devices
regularly. Develop usage policies for the use of wireless devices.
Minimum Scanning Requirements for Wireless
LANs
Scan all sites with CDEs whether or not
they have known
WLAN Access Points (AP) in the CDE. Sampling of sites is not allowed. A
WIPS
is recommended for large organizations since it is not possible to
manually
scan or conduct a walk-around wireless security audit[11] of all sites on
a
quarterly basis
Enable automatic WIPS alerts to instantly
notify personnel
of rogue devices and unauthorized wireless connections into the CDE.
Prepare an incident response plan to
monitor and respond to
alerts from the WIPS. Enable automatic containment mechanism on WIPS to
block
rogues and unauthorized wireless connections.
Intrusion Detection Systems/Wireless Intrusion
Prevention System (WIPS) Implementations
Use a centrally controlled wireless IDS/WIPS to monitor for
unauthorized access and detect rogues and misconfigured wireless
devices.
Enable historical logging of wireless access that can provide
granular wireless device information and store event logs and statistics
for
at least 90 days.
Enable WIPS features that automatically disable rogue wireless
devices connecting to the CDE as well as accidental or malicious
associations
of wireless clients.
Ensure the WIPS signature set is regularly updated as new
threats are discovered.
Coordinate logging events with other networking devices within
the organization.
Add processes and policies that will regularly read and act on
the data provided by the WIPS.
Maintain a current topology of all physical locations of access
points.
Mobile Payment Acceptance Security Guidelines
Preventing unauthorized physical device and
logical device access
Installing malware protection
Vulnerability scanning of
mobile devices for secure state verification
Disable unnecessary device
functions
Response policies and
procedures for loss, theft, or disposal of
decommissioned devices
Secure payment acceptance solutions
Ensure the secure use of the
payment-acceptance solution
Using online acceptance
solutions versus offline solutions
Secure authentication to
prevent unauthorized use
Provide the ability for
cardholders to confirm that a merchant is a
legitimate customer of their solution
PCI DSS is considered
a universal standard within the payment card issuer industry. Issuers such
as Visa, MasterCard, American Express
and Discover Card each monitor acquirer and merchant compliance with
tailored
programs of applicability that addresses any nuances of their respective
acquirers and merchants. Additionally, each issuer defines its own set of
rules
and any penalties for non-compliances.
Discover Card
PCI DSS requirements are similar to the requirements established by the
Discover Information Security and Compliance
(DISC) program. The DISC program is designed specifically for Discover Card
service providers and merchants to support the mandatory requirements set
forth by PCI DSS by safeguarding cardholder information and limiting data
compromises. Quality management security services provided through DISC help
merchants and service providers prevent information system security events
and attacks leading to identity theft and payment card fraud.
Merchant Risk Council
While not a competing entity to PCI SSC, The Merchant Risk Council is a
non-profit organization of e-Commerce service providers and merchant to
provide
a community of interest for making the Internet a preferred place to shop
and
sell.
PCI compliance is
working. According to the Ponemon Institute a full 64% of
organizations that are compliant with PCI DSS had no breaches involving
credit
card data over the past two years, compared to only 38 percent of non-compliant
organizations. In the light of the successes for PCI SSC and PCI DSS, in
order for the PCI SSC and other organization such as the MRC to remain
independent, it will be imperative for each organizations and associated
members
to press forward with wider compliance and validation. The sovereignty of
service
providers and merchants outside the span of control from regulatory
oversight is
tantamount to the health of the Internet and e-Commerce. This will take the
concept of self-rule and self-regulation to a level not before seen in an
unregulated market. By the implementation of fines and restrictions of
access to
card resources, the industry will be able to keeps its affairs out of the
hands
of federal, state and local controls.
Fines and penalties for non-compliance are beginning to
take hold. If a member knows or suspects a security breach with a merchant
or
service provider, the member must take immediate action to investigate the
incident and limit the exposure of cardholder data. As an example, if a Visa
member fails to immediately notify Visa Fraud Control of the suspected or
confirmed loss or theft of any Visa transaction information, the member will
be
subject to a penalty of $100,000 per incident. Members are subject to fines,
up
to $500,000 per incident, for any merchant or service provider that is
compromised and not compliant at the time of the incident.
Focus on Mobile
In February 2013, PCI Mobile Payment Acceptance Security
Guidelines v 1.0 was published to address the unique and emerging uses of
mobile
payment system hardware and applications. Though not currently mandated by
PCI
SSC, the guidelines and best practices published in v 1.0 documents are
produced
to help educate and create awareness of challenges faced by the payment
industry. This document focuses on guidance for merchants that plan to
accept
payments with a mobile device.
Where merchants‘ mobile device hardware and software
implementation cannot currently meet the guidelines documented v 1.0, those
merchants may choose to implement a PCI-validated, Point-to-Point Encryption
(PCI P2PE) solution. Implementing such a solution would include the addition
of
a PCI-approved Point of Interaction (POI) device. With the use of a
validated
solution, account data is encrypted by the POI, and the mobile device would
simply act as the conduit through which the encrypted payment transaction is
transmitted.
A modicum of caution and common sense can also
supplement
payment card security for Business to Consumer (B2C) and Business to
Business to
Business (B2B) transactions. Giving credit card and personal information to
un-trusted sources is never recommended. For online transactions only use
sites
that implement standard security protocols Hypertext Transfer Protocol
Secure
(HTTPS) with the Secure Sockets Layer (SSL) v2 and v3 and Transport Layer
Security (TLS) protocol to provide encrypted communication and secure
identification of a network
Web
server.
Also checking the credentials of the transacting organization through
accreditation agencies such as the Better Business Bureau is a recommend
practice.
Cloud Computing
Cloud computing is a form of distributed computing with evolving
standards.
The evolving technical aspects of cloud computing from a PCI DSS
perspective,
requires evaluating risks and benefits paradigms as the technology becomes
more
established and its implications and applicability to PCI DSS security
become
better understood. From a foundational perspective, cloud security is a
shared
responsibility between the cloud service provider (CSP) and its clients. If
payment card data is stored, processed or transmitted in a cloud
environment,
PCI DSS will apply to that environment, and will typically involve
validation of
both the CSP’s infrastructure and the client’s usage of that environment.
The allocation of responsibility between client and provider for managing
security controls does not exempt a client from the responsibly of ensuring
that
their cardholder data is properly secured according to applicable PCI DSS
requirements. Given the current state of cloud technology, it is important
to
note that all cloud services are not created equal. Emerging policies and
procedures should be agreed between client and cloud provider for all
security
requirements, and responsibilities for operation, management and reporting
should be clearly defined and understood for each requirement.
Paul Ulasien is President and Senior Partner for Business Training
Consultants.
He is a seasoned IT/Networking professional with more than 25 years of
experience in telecommunications, consulting, IT management, and teaching –
as
an undergraduate and graduate professor in Business, IT, and Networking
technologies. He writes frequently for Faulkner Information Services
and
is the author of
The Corporate Rat Race: The Rats Are Winning and The Power of a Grace
Perspective. Mr. Ulasien resides in
Marana, AZ, USA.