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

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:

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.

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.

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

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

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.

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

2. 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
  • Issuance of secure receipts

Competing Standards

[return to top of this report]

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.

Future Directions

[return to top of this report]

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.

Web
Links

[return to top of this report]

• American Express Data Security:
  
  https://www209.americanexpress.com/merchant/services/en_US/data-security
• ClearCommerce:
  http://www.clearcommerce.com/
• Expedia: http://www.expedia.com
• Discover Information Security and Compliance:
  
  http://www.discovernetwork.com/merchants/data-security/disc.html
• HP: http://www.hp.com
• PCI DSS Wireless Guidelines:
  https://www.pcisecuritystandards.org/pdfs/PCI_DSS_Wireless_Guidelines.p
  df
• PCI Security Standards Council: https://www.pcisecurit
  ystandards.org/index.htm
• PCI Security Standard PDF:
  
  https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf
• Ponemon Institute:
  http://www.ponemon.org/index.php
• Visa Cardholder Information Security Program:
  
  http://usa.visa.com/merchants/risk_management/cisp_service_providers.html

About the Author

[return to top of this report]

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.

[return to top of this report]