March 2008
Special Report: PCI Compliance
Once Is Not Enough
Linda Punch
With a dozen main requirements and more than 200 subrequirements, the PCI standard is
expensive and complex. If you haven’t achieved compliance yet, here’s what you’re facing. If
you have, congrats—but your work is far from over.
In 1999, when a hacker stole credit card numbers from CDUniverse.com and posted them on a
Web site, securing stored cardholder data took on a new urgency for the payments industry.
While the major card brands had been focusing on protecting cardholder account numbers
transmitted during e-commerce transactions, they gave little thought to protecting databases of
confidential information.
But all that changed with the CDUniverse incident and several other data breaches that followed
within a period of a few months. At first, the individual card brands tried to set their own datasecurity rules. But after complaints from merchants and other industry participants trying to meet
these multiple—and often varying—requirements, the brands joined together to publish a single
standard. In January 2005 Visa International, MasterCard Worldwide, American Express Co.,
Discover Financial Services LLC and other card networks introduced the Payment Card Industry
data-security standard (PCI DSS).
PCI DSS applies not only to merchants but to any entity that touches a card transaction,
including card processors, independent sales organizations, and banks. It requires annual security
audits to ensure the merchant remains in compliance. Meeting the requirements once is not
enough. Merchants and service providers can face multiple assessments during the year to ensure
ongoing compliance.
The industry in 2006 formed a consortium—the PCI Security Standards Council—to oversee and
update PCI DSS and later a related standard for point-of-sale software, the Payment Application
Data Security Standard (PA-DSS). However, the individual brands are still responsible for
enforcing the standards.
Complex Standard
The PCI standard is nothing if not complex. It comprises 12 requirements, but these are further
broken down into more than 200 subrequirements, which provide detail on the steps needed to
reach compliance. The requirements address not only technology but also security practices, such
as limiting employee access to confidential data:

Requirement 1: Install and maintain a firewall configuration to protect cardholder data.
Subrequirements include: establishing firewall configurations that deny all traffic from
“untrusted” networks and hosts and restricting connections between publicly accessible
servers and any system component storing cardholder data.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other
security parameters. Subrequirements include: always changing vendor-supplied defaults
before installing a system on the network.

Requirement 3: Protect stored cardholder data. Subrequirements include: deleting
sensitive authentication data subsequent to authorization even if encrypted and masking
the first six and last four digits of an account number when displayed.

Requirement 4: Encrypt transmission of cardholder data across open, public networks.
Subrequirements include: using strong cryptography and security protocols such as
secure sockets layer (SSL).

Requirement 5: Using and regularly updating anti-virus software or programs.
Subrequirements include: ensuring that all anti-virus mechanisms are current, actively
running, and capable of generating audit logs.

Requirement 6: Developing and maintaining secure systems and applications.
Subrequirements include: ensuring that all system components and software have the
latest vendor-supplied security patches installed within one month of release.

Requirement 7: Restrict access to cardholder data by business need-to-know.
Subrequirements include: establishing a mechanism for systems with multiple users that
restricts access based on a user’s need to know and is set to “deny all” unless specifically
allowed.

Requirement 8: Assign a unique ID to each person with computer access:
Subrequirements include: implementing two-factor authentication for remote access to
the network by employees, administrators and third parties, and encrypting all passwords
during transmission and storage on all system components.

Requirement 9: Restrict physical access to cardholder data. Subrequirements include:
using appropriate facility entry controls to limit and monitor physical access to systems
that store, process, or transmit cardholder data.

Requirement 10: Track and monitor all access to network resources and cardholder data.
Subrequirements include: establishing a process for linking all access to system
components to each individual user and implementing automated audit trails for all
system components.

Requirement 11: Regularly test security systems and processes. Subrequirements include:
running internal and external network vulnerability scans at least quarterly and after any
significant change in the network and performing penetration testing at least once a year
and after any significant infrastructure or application upgrade or modification.

Requirement 12: Maintain a policy that addresses information security for employees and
contractors. Subrequirements include: ensuring that the security policy and procedures
clearly define information security responsibilities for all employees and contractors.
The PCI standard allows retailers to substitute less costly and more practical alternative methods
if those alternatives achieve the same goal. For example, a merchant could substitute activity
monitoring—watching the use of financial information in its database—for encryption.
Deadlines And Penalties
The industry set separate deadlines for PCI compliance for four categories of merchants, grouped
by the number of Visa and MasterCard transactions they submit annually. The deadline for Level
1 merchants, those that process 6 million Visa or MasterCard transactions per year, regardless of
acceptance channel, was Sept. 30, 2007. Level 1 merchants identified in 2007 must validate
compliance by Sept. 30, 2008.
Merchants that have suffered an attack resulting in account data being compromised also are
required to meet Level 1 requirements. Level 1 merchants account for about 50% of Visa
transactions annually.
Level 2 merchants, those that process 1 million to 6 million Visa or MasterCard transactions per
year, regardless of acceptance channel, faced a Dec. 31, 2007, deadline. Level 2 merchants
identified in 2007 must validate compliance by Dec. 31, 2008. Level 2 merchants account for
about 13% of Visa transactions annually.
Because they account for such a small portion of annual card transactions, no deadlines were set
for Level 3 and Level 4 merchants. However, they are expected to be compliant and will be
penalized for violations of the PCI standard. Newly booked Level 3 and Level 4 merchants must
be PCI-compliant or use PA-DSS-compliant applications by Oct. 1.
Level 3 merchants process 20,000 to 1 million Visa or MasterCard e-commerce transactions per
year. Level 3 merchants account for less than 5% of Visa’s annual transactions. Level 4
merchants process fewer than 20,000 Visa or MasterCard e-commerce transactions a year or less
than 1 million Visa or MasterCard transactions, regardless of acceptance channel.
The requirements for validating data-security protection vary in stringency, depending on
merchant size. They range from an annual on-site security audit and quarterly network scan for
Level 1 merchants to a recommended self-assessment questionnaire and recommended annual
network scan for Level 4 merchants.
Acquirers whose merchants aren’t PCI compliant face monthly fines of $5,000 to $25,000,
penalties the acquirers likely would pass on to non-compliant merchants. Although Visa won’t
comment on fines, some industry observers believe Visa won’t levy fines in cases where the
merchant can at least show it is not improperly storing card numbers or PIN blocks.
It can take anywhere from 45 days to up to two years for merchants to reach compliance,
depending upon whether a merchant sells only online or through catalogs and brick-and-mortar
stores or a combination of channels, says Robert Russo, general manager of the Wakefield,
Mass.-based PCI Council.
For example, a large brick-and-mortar retailer that has used the same store operating system for
15 years likely will need more time to become PCI compliant than an online retailer just starting
a business. “It’s a lot more difficult to retrofit security into some of these older applications than
it is to build a new application with security already in it,” Russo says.
Compliance Picks up
Despite deadlines for compliance set by the individual card associations that go back more than
three years, merchants were slow to adopt the data-security standard. But merchant compliance
picked up dramatically in the past year, Russo says.
“As little as a year ago we were hearing, ‘Why do I have to do this?’” Russo says. “Now we’re
hearing, ‘Help me do it. How can I do it faster? What do I need to do?’”
As of Sept. 30, 2007, 65% of those identified as Level 1 merchants between 2004 and 2006,
were PCI compliant, according to statistics posted on Visa’s Web site. Another 35% have
submitted plans but need to make so-called remediations before getting final validation.
Among Level 2 merchants, 43% were PCI compliant and another 42% had submitted plans but
needed to make remediations before final validation. In addition, 15% were working on initial
validation.
In July, Visa also reported that 88% of VisaNet processors and 65% of third-party agents, such
as ISOs, had validated compliance with the PCI DSS and the remaining entities were actively
working to do so.
This increased interest in compliance is due to several factors, including a December 2006
incentive program for merchant acquirers that serve the 1,200 largest Visa-accepting merchants.
Part of the program called for Visa to pour up to $20 million into a fund that paid cash rewards to
acquirers for large merchants that had already validated compliance by Aug. 31, 2007.
Qualifying merchants must not have been involved in a data breach.
The payments represented the first incentives Visa or any other major card network offered for
compliance with data-security rules.
Under another part of the Visa program—which it calls the Compliance Acceleration Program,
or CAP—acquirers enjoying volume-based tiered interchange rates can be downgraded one tier
on transactions from any non-compliant merchant. Interchange is a fee on each bank card sale
assessed to the acquirer and paid to the card issuer, with acquirers typically passing all of the cost
to the merchant. With a one-tier downgrade, merchants could face higher interchange rates
totaling millions of dollars.
Fear of fines and the threat of higher interchange rates were the major motivations for larger
merchants to become PCI compliant, says Branden Williams, director of VeriSign Inc.’s PCI
practice. “During the last half of the year, there was a substantial amount of demand for PCI
consulting services because the fines have started, and tiered merchants were in an exceptionally
bad spot because they couldn’t qualify for the best available tier,” he says.
Merchants that lose their best interchange rates have some recourse. A merchant that certifies it
tried its best to meet the Sept. 30, 2007, deadline but needed more time can qualify for a rebate
worth up to three months of the difference between the two tiers if it comes into PCI compliance
by Sept. 30, 2008.
In a related move, the industry also is working to ensure that merchants’ point-of-sale systems
are secure. Alarmed by an increased number of security breaches tied to the point of sale, the
industry is in the process of finalizing PA-DSS, an industrywide standard based on Visa’s
Payment Application Best Practices guidelines. PA-DSS outlines steps software vendors and
others must take to ensure that point-of-sale applications don’t store prohibited information, such
as a card’s full magnetic-stripe track data, card verification security codes, and PINs.
A preliminary draft of the PA-DSS is circulating among the PCI Council’s board of advisors,
participating organizations and others such as qualified security assessors. Other components of
the PA-DSS program will be rolled out following publication of the standard, including
publication of a list of validated payment applications. About 200 products used by many
merchants worldwide have been validated as meeting Visa’s PABP criteria. The list is available
on the Visa Web site.
In November, Visa set five deadlines for merchant acquirers and processors to remove
vulnerable old applications and ensure that newly signed card-accepting merchants are using
secure software by 2010. Acquirers failing to meet the mandates could face PCI fines.
However, the PCI Council’s Russo cautions that merchants shouldn’t assume they are PCIcompliant because they’re using an approved POS application. “That’s only one piece of being
compliant,” he says. “There are 12 other things that you’ve got to do to become compliant. It’s
pretty much all or nothing at all. You’re either secure or you’re not secure.”
Installing a payment application that’s been certified as compliant is only a first step, Russo
says, adding “if you use that application in a way that isn’t secure, then you’ve got a problem.”
Costs of Non-Compliance
Indeed, PCI compliance goes beyond technology, addressing issues such as how information
flows through a business and who has access to that information, says James DeLuccia, an IT
management expert and founder of Intellection Strategies.
“A lot of people initially looked at PCI and said this is an information-security or informationtechnology infrastructure,” DeLuccia says. “Quite the contrary. Really, it’s the business process
and the flows of information in the organization that make an organization PCI compliant.”
That requires the involvement of not only IT personnel, but also of others within a business, such
as employees familiar with the POS system and back-office personnel knowledgeable about how
information is distributed throughout the organization.
“Maybe the organization has a process that exposes massive amounts of data to several areas of
the business that don’t require it any more,” DeLuccia says. “It’s an artifact that’s just there.”
While implementing the PCI standard can be time-consuming and expensive, the failure to
secure data can be even costlier. In addition to fines and penalties, merchants hit by a data breach
face the expense of auditing the system to find the point of compromise and remediating the
situation. They also could face class-action lawsuits and loss of reputation.
“The penalties of non-compliance are burdensome to the point where they’re sufficient to really
bankrupt any small or mid-tier business, and materially impact the largest retailers,” DeLuccia
says.
The cost of a data breach can easily be 20 times the cost of PCI compliance for Level 1
merchants, according to a recent joint analysis from information-technology security firms
Solidcore Systems Inc., Emagined Security, and Fortrex Technologies Inc.
The analysis estimates a Level 1 merchant spends $2 million to $10 million over a one-to-two
year period to upgrade its payment systems and security infrastructure, $250,000 to $3 million
annually on security audits by a qualified security assessor, and $1 million to $5 million annually
on sustaining compliance.
In comparison, based on interviews with retailers and information from TJX Cos.’ public filings
related to its highly publicized data breach, the cost-per-record following a data breach can be as
high as $200, according to the analysis. That means the total cost of a data breach could range
between $100 million and $250 million.
With data compromises on the rise—the San Diego-based Identity Theft Resource Center listed
more than 79 million records compromised in the U.S. last year, up from 20 million in 2006—
compliance with the PCI standard is even more crucial, observers say.
“The fines are absolutely the least of it,” Russo says. “What happens to your brand? What
happens to your customers?”
The Most Common Reasons for Failing a
PCI Audit
With 12 requirements and more than 200 sub-requirements in the Payment Card Industry Data
Security Standard, there could be hundreds of reasons for a merchant to fail an audit for PCI
compliance. But industry analysts say they are finding that a handful of rules account for the
majority of audit failures.
When looking for PCI compliance, an auditor will review system logs or look at the IT
environment that handles credit card information, says Mike Petitti, chief marketing officer of
TrustWave, an information-security and compliance firm that conducts PCI audits. But auditors
also will do a document check to see what security policies a merchant has in place. “That’s
nothing that you’re necessarily going to find on the IT portion of the credit card processing
environment,” he says. “Someone may actually have to produce it, print it out, and give it to
you.”
Auditors also will talk with people involved in the merchant’s credit card processing area,
including IT personnel. “It’s everything from talking to people, document examination,
understanding processes and procedures, and actually taking a look at the technology itself,”
Petitti says. “Those are the things from an audit standpoint that you don’t get when you’re
simply doing a vulnerability scan or just a check of the technology.”
As the audits are wide-ranging, so are the reasons that merchants fail those audits. The most
common PCI requirements not met during audits are:
Requirement 11: Regularly test security systems and processes. Merchants most often fail two
subsections of this requirement, according to VeriSign Inc., a payment-processing technology
and security firm: to run internal and external network vulnerability scans at least quarterly and
after any significant change in the network; and to deploy file-integrity monitoring software to
alert personnel to unauthorized modification of critical system or content files.
The merchant must configure the software to perform critical file comparisons at least weekly.
“A company can have strong policies and state-of-the-art technology, but it must also regularly
test its network, firewalls, and applications to ensure that those security measures are working
properly and data is secure,” VeriSign says in a white paper entitled “More Lessons Learned—
Practical Tips for Avoiding Payment Card Industry (PCI) Audit Failure.”
Requirement 1: Install and maintain a firewall to protect cardholder data. “We have noticed that
merchants may not have a firewall, and in some cases, if they do have a firewall, it may not be
properly configured,” Petitti says. “A firewall is like having a lock on your front door. If it’s not
locked or maintained, it’s really of no use.”
Requirement 6: Develop and maintain secure systems and applications. Merchants frequently
haven’t installed the latest vendor-supplied security patches on system components and software,
VeriSign says.
Requirement 3: Protect stored data. Merchants typically fail three subsections of this
requirement, according to VeriSign: making the primary account number (PAN) unreadable,
anywhere it is stored; protecting encryption keys used for encryption of cardholder data against
both disclosure and misuse; and fully documenting and implementing all key-management
processes and procedures. Failure to meet this requirement leaves the merchant vulnerable to
compromise, for example, if a laptop computer is lost or stolen.
Requirement 8: Assign a unique ID to each person with computer access. Merchants often don’t
have processes in place to ensure that employees don’t share passwords with unauthorized
personnel, says Khalid Kark, analyst with Forrester Consulting Inc. And VeriSign found that
many small retailers run stock POS systems that have default or blank passwords, leaving them
vulnerable to compromise.
Requirement 10: Track and monitor access to network and card data. Merchants typically don’t
meet the subsection that requires automated audit trails that track individual access to cardholder
data, all actions taken by any individual with root or administrative privileges, access to all audit
trails, and invalid attempts to access the data.
One of the most common mistakes merchants make is not having a data-flow diagram, which is
essential to locating weak points in data security, says Branden Williams, director of the PCI
practice of Mountain View, Calif.-based VeriSign. “There’s really not one person in a company
that can write down their entire data flow from acquisition of a card from a customer all the way
to disposal or long-term storage or handing off the data to a service provider,” he says.
Requirement 12: Failure to maintain a policy that addresses information security. “They may
not understand what a good information-security policy is, and that’s not because they don’t
want to understand,” Petitti says. “That’s because if they’re running a restaurant, they’re
concerned about clearing tables, seating people, and serving the next meal. Their primary
concern isn’t information security.”
Retailers, in particular, often find it difficult to achieve PCI compliance because they are
generally geographically dispersed, says James DeLuccia, an IT management expert and founder
of Intellection Strategies.
“Retail stores are located around the world and each one of those individual locations is
receiving sensitive data,” he says, adding that the POS devices that capture the sensitive
cardholder information typically are in high-traffic areas, presenting a security challenge to
retailers.
In addition, each retail location typically sends sensitive information back to the home office,
creating another opportunity for hackers to gain access to the system, DeLuccia says. “The
solution really is to evaluate how that information flows to the organization and then go through
a process of limit, encrypt, and restrict on that information,” he says.
One of the reasons that merchants fail to maintain compliance is the constant turnover of staff
positions typical of most retailers, Williams says. “That’s not people leaving the company,
they’re just changing what they do,” he says. “One of my guys commented that we’re talking all
the same people, but they don’t do the same thing any more, making things pretty challenging
trying to get the right information.”
Bringing merchants into PCI compliance has been an uphill battle, says Forrester analyst Kark.
“You can put technology in, you can provide those additional layers of protection, but you also
need to ensure that those practices and processes that you have within your organization are
really addressing the security issues,” he says.
—Linda Punch
The Storm over Storage
Discussions about the storage of payment card data in computers and the attendant security
issues can quickly get bogged down in techno-speak. There’s a much easier way to get to the
heart of the matter, however. Just borrow a phrase from your teenager: “Everybody does it.”
“Everybody” in this case refers to merchants that accept credit and debit cards. And what they’re
doing is storing card data, often in violation of the Payment Card Industry Data Security
Standard, or PCI, the card networks’ comprehensive set of security rules. According to a 2007
Forrester Consulting study commissioned by EMC Corp.’s RSA security division, more than half
of 677 U.S. and European Union information-technology security executives working for
retailers and hospitality-industry firms, as well as financial institutions, say their companies keep
at least some credit card data, much of it in seeming violation of PCI rules (chart). “Merchants
typically keep too much data,” says the report.
The massive computer breach at off-price retailer TJX Cos. Inc. that potentially exposed
anywhere from 45 million to nearly 100 million improperly stored card numbers, depending on
who’s doing the explaining, to unauthorized eyes brought the issue of card-number storage to the
front pages in 2007. The TJX fiasco was just the biggest in a series of 21st Century hacks that
raised alarms among consumer groups, pubic officials, and the payment card industry itself.
This practice of storing anything that comes into the system, some experts explain, is the mindset
of many technical and operations people, a mindset that springs naturally from one of the
computer’s key strengths: the ability to hold massive amounts of data. And it’s not just
mainframes that hold central data repositories; point-of-sale payment-processing systems have
proven to be frequent culprits in storing card data, often unbeknownst to their merchant owners.
Plus, some merchants have found that card numbers are handy tools upon which to base
identification and tracking systems for customers in their loyalty programs, according to Scott
Laliberte, a director at Menlo Park, Calif.-based IT security firm Protiviti Inc. who works out of
Philadelphia. “I think it’s a legacy thing,” he says. “You had a lot of legacy programs and
databases that relied on these things that [now] need to be changed.”
Indeed, this widespread storage of payment card data is raising questions about alternatives,
which include so-called electronic tokens that replace actual card numbers and the outsourcing of
data to highly secure third parties. It’s too soon to say how it will all shake out, but for now, it
seems anyone with a credible alternative to the old ways and good marketing skills can expect
brisk business.
The current version, 1.1, of the PCI standards permits storage of four cardholder data elements:
card number (in PCI lingo, the primary account number, or PAN), name, card expiration date,
and the service code, which is a three- or four-digit number in the magnetic stripe that specifies
transaction requirements and limitations.
Merchants like to have cardholder data on hand to resolve post-transaction disputes and
chargebacks. But some also have built loyalty programs whose databases draw to some degree
on the payment card data they collect, while others use card numbers in their internal fraudcontrol systems.
Merchants that keep a PAN must encrypt or otherwise render it unreadable. Merchants also must
apply protections to cardholder names, expiration dates, and service codes if they store them with
PANs.
Besides full encryption, protection of stored cardholder data using existing technologies can
include truncation, usually in which the middle numbers of a 16-digit account number are
removed, showing the viewer only, say, the first six and last four digits. Truncation is not to be
confused with masking, Protiviti’s Laliberte notes. In masking, only the first and last few
numbers are visible, but the full PAN remains behind in the database, potentially accessible to
hackers.
With another protection method, called hashing, a string of card numbers is run through an
algorithm, and as long as the numbers are not stored with the algorithm, the resulting values are
not considered card numbers. “If you captured the hashing theoretically you couldn’t do anything
with it,” Laliberte says.
Beyond these cardholder data, PCI prohibits storage of what the rules call “sensitive
authentication data.” Such data include so-called track data, which are the full encoded contents
of the magnetic stripe. Besides cardholder information, track data will include a validation code
intended to reveal counterfeiting of or alteration to a card, and may also contain an issuer’s
discretionary or proprietary data.
The two other types of banned authentication data are a second type of validation code, which is
printed, and the personal identification number. PINs in the U.S. are found almost exclusively on
debit cards. Besides individual PINs, merchants must not store encrypted groupings of PINs
called PIN blocks.
Validation codes are usually three-digit numbers (four for American Express) and are most often
printed in the signature panel (AmEx again the exception). They go by acronyms such as CVV2,
for Visa’s Card Verification Value 2, or CVC2, for MasterCard’s Card Validation Code 2.
American Express and Discover use the code CID, for Card Identification Value, while JCB
cards use CAV2, for Card Authentication Value 2. These codes are used in card-not-present
transactions and link each account number to a particular card.
TJX was not compliant with PCI at the time of the intrusions into its data files, and court
documents reveal the company was trying to delay security upgrades as long as possible to save
money. (In the wake of the breach, TJX is now PCI-compliant and has agreed to a take on a
public-relations advocacy role for the standards.) But the whole TJX affair and other breaches
have raised the question of whether merchants should store card numbers at all, even if they do
so in accordance with PCI rules.
While many of today’s data-protection technologies, are very strong, they are not invulnerable.
For instance, some experts say certain hashing algorithms have flaws that potentially make them
vulnerable to reversal.
Visa and MasterCard can fine acquirers whose merchants violate PCI, fines the acquirers most
likely would pass on to the offending merchants. (Visa fined TJX’s U.S. acquirer, Fifth Third
Bancorp, an undetermined amount, but will rescind a $500,000 “egregious-violation” fine and
suspend collection of $225,000 in pending fines under a settlement disclosed in December.) But
some critics say industry fines don’t provide enough deterrence and assert that companies will
not deploy the strongest defenses until they become subject to damages for failing to protect
cardholder data.
“The economic incentives here are all screwed up,” says Bruce Schneier, an author of security
books and founder and chief technology officer of Santa Clara, Calif.-based security-technology
firm BT Counterpane. “Companies need to be liable.”
Minnesota last year passed a data-protection law that mirrors PCI, but no other state or the
federal government has yet followed. California’s legislature in 2007 passed a data-protection
bill, but Gov. Arnold Schwarzenegger vetoed it.
Some security experts nonetheless believe the market is becoming more receptive to new
approaches to data storage. The forces for change include new technology and retailers’ fear of
bad publicity. “Retailers are really very interested,” says Avivah Litan, an analyst with Stamford,
Conn.-based technology consulting firm Gartner Inc. “There are some new solutions that will be
getting some very good traction in 2008.”
Solutions generating high interest include a variety of systems for transferring payment-related
data to outsourcers, entirely relieving the merchant of the need to store any card data. Some of
these outsourcers will translate card data into tokens, or aliases, that can be retrieved and linked
to the relevant transaction should a chargeback arise. “It’s really easy for them to outsource the
record of that,” Litan says.
According to Litan, some of the companies offering variations on that theme include Merchant
Link, a gateway owned by Chase Paymentech Solutions LLC, Electronic Payment Exchange,
CyberSource Corp., and Shift4 Corp.
Las Vegas-based Shift4, a transaction-security provider and gateway service used by 17,000
merchants, promotes what it calls its “data-replacement technology” in its 4Go suite of security
services. The technology encrypts card data and stores them at Shift4’s two, soon to be three,
redundant data centers. “Our goal is to move all of the credit card data from the merchant
endpoint,” says Randy Carr, director of marketing, who adds that removal of the card number
“is, by definition, real security.”
The resulting tokens can be retrieved and linked to the relevant card number in the event of a
chargeback. Any time the data are touched, such as in a chargeback retrieval, the token changes.
According to Carr, if a hacker ever intercepted one of Shift4’s tokens and managed to decrypt it,
the resulting card number theoretically would be good only one time and at one merchant.
Of course, the outsourcing of card data requires that the outsourcers be PCI-compliant. John
Mann, vice president of sales, says Shift4 uses 320-bit encryption and is PCI-compliant. “We are
actually double what the standard is to ensure we have protection for our clients,” he says.
The Shift4 executives and others interviewed by Digital Transactions raise a question likely to be
heard as outsourcing grows: If a retailer doesn’t store payment card data, need it spend the time
and money to become and stay PCI-compliant? “If they don’t transmit, store, or process credit
card data, approximately half of PCI becomes moot,” says Carr.
The National Retail Federation is pushing for transaction identifiers to take the place of card data
(“Remove Hackers’ Motives To Attack Retailers,” January). And Gartner’s Litan also is calling
for greater use of alternative identifiers. But the card networks have given no indication they’re
going to change who must comply with PCI any time soon.
The question of storage aside, even the use of PINs for all card authorizations would reduce
fraud, according to Litan. But then, the trade-off between security and profit would take center
stage. In the U.S., PIN-debit transactions generate less interchange for card issuers than
signature-based debit transactions.
“It all comes down to money,” says Litan. “The banks don’t want to lose revenue. They get less
money with PINs.”
—Jim Daly
Scanning for Security
It may be dry reading, but it’s all there in Requirement 11 of the so-called “Dirty Dozen”—the
major dictates of the Payment Card Industry data-security standard, or PCI. Requirement 11
deals with regular tests of security systems and processes, and one of its five subsections
specifically requires entities handling payment card information to “run internal and external
network vulnerability scans at least quarterly and after any significant change in the network …”
A notation further explains that such quarterly scans are to be performed by a vendor approved
by the payment card industry. That means the PCI Security Standards Council, the non-profit
entity set up by the major card networks to oversee and upgrade, but not enforce, the PCI
standards.
Industry experts say recent scans show merchants and payment processors are becoming more
serious about the security of their credit and debit card platforms that connect to the Internet. But
they also say a passing grade in one quarter is no guarantee a hacker won’t succeed the next
quarter. “It’s a constant struggle,” says Scott Laliberte, a director in the Philadelphia office of
Menlo Park, Calif.-based Protiviti Inc., a PCI Council approved scanning vendor (ASV) and
qualified security assessor (QSA). “Even once you get a fully compliant scan, the client still
needs to stay on top.”
The rules themselves have soft spots that could give enterprising hackers using the Web extra
time to find an unlocked door into a merchant’s payment-processing systems, even if that
merchant had passed its most recent scan, some observers say.
Failure to do regular testing as mandated by Requirement 11 is the most common factor in PCI
audit failures, according to VeriSign Inc., a Mountain View, Calif.-based payment-processing
technology and security firm. In a 2007 white paper about PCI, VeriSign analyzed results from
60 recent PCI audits involving 50 different companies and made a list of the top 10 reasons for
failure. Not meeting the regular-testing rule was a factor in 48% of audit failures, more than any
other factor.
Ranked by the PCI rules’ 61 subsections, not meeting Requirement 11.2, which mandates
internal and external network vulnerability scans at least quarterly and after major network
changes, was a factor in 43% of failures, again No. 1.
The approximately 130 ASVs listed on the PCI Council’s Web site as of late December must
meet criteria spelled out in a 47-page council document. Vendors use an eight-page checklist as
the basis of their scans. Scanners deploy software systems for their probes, with Redwood City,
Calif.-based Qualys Inc. providing the most widely used applications—products that many
providers use as the foundation of private-label variants. “There are several engines out there, but
Qualys is the 800-pound gorilla,” says Branden Williams, PCI-practice director at VeriSign.
Scanners check Internet Protocol (IP) addresses, server ports, operating systems and any
computer system accessible from the outside for vulnerabilities. “It’s almost like walking around
your house making sure your doors and windows are locked,” says Michael Petitti, chief
marketing officer at Trustwave, a Chicago-based AVS and QSA.
Scanners frequently find misconfigured firewalls that leave ports open to unauthorized Internet
traffic. “Some ports aren’t well known and may be, as a result, unguarded,” says Petitti.
Two other common vulnerabilities that can cause a merchant to fail a quarterly scan are exposure
to so-called cross-site scripting and sequel or SQL injection attacks. (SQL refers to structured
query language, a textual computer language for interacting with databases).
In cross-site scripting, which according to Williams is the more frequent of the two, a hacker
breaks into and introduces malicious code behind a legitimate Web site—think of a bank’s
online-banking site or an e-commerce merchant’s checkout page. Once in, the hacker could
capture a cardholder’s sensitive data or make unauthorized purchases. It’s a higher form for
phishing, a cybercrime that steers unsuspecting consumers to fake Web sites. “It makes phishing
a lot more powerful because you’re actually using the legitimate site,” says Protiviti’s Laliberte.
SQL injection attacks have some technical similarities to cross-site scripting. Their goal is to
gain access to a database by using certain coding to trick the database into opening access even
though the hacker doesn’t have a valid user name or password. “If I am not giving it data that it
doesn’t expect, it should not accept that data,” says Williams. “But if it’s vulnerable, it will pass
it right on.”
SQL injections and cross-site scripting aren’t new, but it has taken many merchants some time to
mount adequate defenses against these and less common forms of Internet-based attacks. PCIcompliance executives say they’re seeing steady improvements over the past few years. “A lot of
our clients have been progressing toward getting fully compliant scans,” says Laliberte. “They
started out with only 30, 40% of their systems compliant. Now we’re finding most of our clients
are fully complaint.”
Failure to pass a scan can start a penalty process that, if the problems aren’t corrected quickly,
could include fines or even revocation of a merchant’s card-acceptance privileges. Trustwave’s
Petitti says his firm’s clients are making the needed fixes to their networks. “The service
providers and the merchants don’t want to be in the newspaper,” he says. “The awareness is there
and the willingness to act is there.”
Yet even if merchants and processors are becoming more enlightened about network security, the
scanning rules themselves need more muscle, some experts say. Certain vulnerabilities behind
log-in screens that are checked in annual PCI audits are not part of a typical quarterly scan, but
should be, according to VeriSign’s Williams. “I think the scan guidelines are a little weak” in
that regard, he says.
In fact, he says, laws requiring stronger network security may prove to be better motivators for
many merchants and processors than industry rules, he adds.
—Jim Daly