Dr. Anton Chuvakin

Principal, Security Warrior Consulting

Sam Curry

Chief Technology Officer, Global Marketing

RSA, The Security Division of EMC

Robert Griffin

Director of Solution Design, Data Security Group

RSA, The Security Division of EMC

Craig Tieken

Vice President, Merchant Products

First Data

Branden Williams

Director, Security Consulting

RSA Security Practice of EMC Consulting

Steven Wilson

Vice President, Payment Security and Reputational Compliance

Visa Europe

Secure Payment Services Card Data Security Transformed

Authors

RSA Security BriefJune 2010

RSA Security Briefs provide security leaders and other executives

with essential guidance on today’s most pressing information,

security risks and opportunities. Each Brief is created by a select

response team of security and technology experts who mobilize

across companies to share specialized knowledge on a critical

emerging topic. Offering both big-picture insight and practical

technology advice, RSA Security Briefs are vital reading for today’s

forward-thinking security practitioners.

Contents

Executive Overview 1

The Arms Race between Merchants and Data Thieves 1

From Risk Protection to Risk Removal: A Major Shift in the Doctrine of Data Protection 3

From Risk Protection to Risk Removal: A Major Shift in the Doctrine of Data Protection 4

Encryption 4

Format-preserving encryption 5

In-house tokenization 6

Looking Forward: New Opportunities Created by Tokenization 7

PCI-compliant cloud computing 7

A new model for risk consolidation and transference 8

Outsourced Payment Card Security 9

Lower risk of fraud resulting from electronic card data theft 9

Reduced PCI scope 10

Reduced time, effort and cost for PCI remediation, maintenance and review 10

Less attractive target for data theft 10

More efficient allocation of IT resources 10

Practitioner Guidance: What to Look for in Secure Payment Service Providers 10

Summary & Conclusions 13

About the Authors 14

Solutions for Secure Payment Processing 15

RSA Security Brief, June 2010

1

Executive Overview

The next generation of secure payment services will transform the way retailers and other merchants

process credit, debit and other payment card transactions. This emerging category of services uses

data encryption and a newer technology called “tokenization” to dramatically lower the risk of

processing card payments for merchants.

This Security Brief examines the external conditions fueling the need to rethink traditional payment

paradigms, the innovative technologies that are enabling new approaches within the enterprise and

the opportunities driving the rise of outsourced secure payment services.

The Arms Race between Merchants and Data Thieves

Most people use their debit and credit cards without much thought to security. They expect the

companies they’re doing business with are processing payments in a secure way and safeguarding

card numbers – an expectation businesses find increasingly difficult to fulfill. The Verizon 2009 Data

Breach Investigations Report1 estimates 285 million payment card records were breached in 2008

alone. Today’s credit card thieves are extraordinarily aggressive and sophisticated in stealing card

numbers. In fact, the thieves have gone professional. The Verizon study found that 91 percent of all

compromised records were linked to organized crime groups.

Professional data thieves logically target payment cards, which yield large payoffs and can be stolen

for a reasonable amount of effort.2 Today’s criminals have moved well beyond stealing individual card

numbers from cardholders. Instead, to maximize their payoff, they’ve automated the theft process with

stealthy malware that intercepts payment information online. They’ve also taken to breaking into the

computer systems of large retailers and payment processors to steal huge quantities of card numbers

at once. Data thieves then sell these treasure troves of card numbers for others to use in fraudulent

transactions. The aggregated damage from this fraud is severe. The 2009 LexisNexis True Cost of Fraud

Study3 found that merchants lost $100 billion from

fraudulent transactions and from fees and interest costs

associated with charge-backs. In turn, banks lost $11

billion and consumers, $4.8 billion.

In the face of this organized onslaught, merchants

worldwide have progressively advanced their data security

practices. They’ve deployed point of sale security

technologies such as chip and PIN (EMV) and magnetic

stripe imaging. They’re using encryption technologies to

store and transmit card numbers more safely. The

approaches and technologies for securing payment card

data can vary widely among geographic regions, between

different industries and even from store to store within the

same retail chain. The result is a patchwork of data security

practices that still leaves many potential points of

vulnerability.

RSA, The Security Division of EMC

RSA Security Brief, June 2010

Professional data thieves

logically target payment cards,

which yield large payoffs and can

be stolen for a reasonable

amount of effort. Today’s

criminals have moved well

beyond stealing individual card

numbers from cardholders.

1 2009 Data Breach Investigations Report, a study conducted by the Verizon Business RISK Team2 For a provocative discussion on the financial case for data theft, read about a cost-value

equation devised by Sam Curry and Amrit Williams to assess the likelihood information securityattacks.

3 2009 LexisNexis True Cost of Fraud Benchmark Study, from LexisNexis Risk Solutions andJavelin Strategy & Research

2 RSA, The Security Division of EMC

To create a more consistent, reliable approach to securing card data, many merchants have adopted the

Payment Card Industry Data Security Standards (PCI DSS). PCI DSS describes a set of global best

practices for processing, storing and transmitting sensitive payment data. The standards spell out basic

security management policies, network architecture requirements, software features, information access

restrictions and other security measures intended to help organizations protect customer account data.

PCI DSS defines minimum requirements for card data security, not the ceiling by which security

programs should be judged. Compliance with PCI DSS does not guarantee the safety of payment card

information. It definitely does not guarantee the safety of other sensitive data and critical systems. In

fact, numerous large companies claim they passed compliance assessments (though they may not have

been compliant at the time of the breach) only to have their customers’ cardholder data compromised.

Nevertheless, PCI DSS is universally regarded as the singular, global standard for assessing card data

security. The standards compel businesses to track cardholder data within their organizations and to

take precautions to safeguard that data. The very process of finding cardholder data often presents a

huge challenge to large, distributed companies, which typically maintain many data silos that are each

tapped by dozens of applications and frequently backed up in distant locations. Also, the PCI

standards, which are updated every two years, do not always address newer IT architectural and

security options, which can leave aspects of compliance up to interpretation.

The intensifying focus on payment card security and the PCI standards – propelled by the prospect of

contractual penalties such as fees and loss of card processing privileges for non-compliance – has no

doubt helped merchants reduce opportunities for data theft and improve security for customers’ card

numbers. The improved security, however, comes at a significant cost: the National Retail Federation

estimates its member businesses have spent more than $1 billion on PCI DSS compliance to date.

Unfortunately, the burden and cost of PCI compliance will likely grow at an ever-faster rate in the coming

years. For one thing, major payment card brands such as American Express, Discover, JCB, MasterCard

and Visa have mandated merchants and their banks to adopt PCI DSS to improve security for their

cardholders. The process of meeting and sustaining PCI requirements presents an enormous challenge

to many merchants for three reasons:

1. Expanding PCI scope – The number of systems, applications and devices handling protected payment

card data within the often-distributed enterprise is expanding. Cardholder information has escaped

from secure databases, proliferating in a range of business applications, backup and archival

systems, seeping as well as into employees’ computers, handheld devices and Excel spreadsheets.

To pass PCI assessments, merchants must prove all IT components handling sensitive card data (and

those directly connected to them) conform to PCI DSS. Assessing all these systems and files can be

incredibly time-consuming and costly, especially considering PCI assessments must be performed at

least annually.

2. Skyrocketing costs of establishing and maintaining PCI compliance – Large retailers spend millions

each year on PCI DSS remediation and compliance, even after the initial assessment. Costs

sometimes escalate exponentially as a merchant's PCI scope expands.

3. Rising complexity requires specialized knowledge – The expertise needed to mount an effective

defense against data intrusion is becoming highly specialized and hard-to-find. Many merchants are

hard-pressed to keep pace with the rapidly changing landscape of payment card security and to

develop the in-house talent needed to keep the organization one step ahead of security threats.

Meeting these challenges often requires merchants to hire armies of consultants.

RSA Security Brief, June 2010

3RSA, The Security Division of EMC

In addition to taking the minimum baseline steps to meet PCI standards, companies are forced to

make continual, incremental investments to keep ahead of the data thieves, who are constantly

evolving their tactics to penetrate IT systems. In many cases, merchants’ investments simply buy them

time as data thieves identify and move to new points of vulnerability. The net result is that merchants

must spend more time and money each year to maintain and prove a constant level of security.

This security arms race distracts merchants from their core business of selling products and serving

customers, but as long as attackers seek to misuse payment data, companies must invest in data

security. However, organizations have an emerging opportunity to minimize the cost of this arms race

by simply reducing the time and space in which they’re vulnerable to attack.

From Risk Protection to Risk Removal: A Major Shift in the Doctrine of Data Protection

Merchants typically aim to safeguard payment card information by setting up a defensive perimeter

around the data: keeping it within secure, designated databases and limiting access to sensitive

information. However, sensitive card data often escapes from merchants’ secure payment processing

systems into non-payment business applications (e.g., CRM, ERP, marketing analytics), which use card

numbers as look-up values for tracking transactions, shipments and customer behaviors.

RSA Security Brief, June 2010

Glossary

– Encryption – A cryptographic process

for disguising data by applying a series

of complex mathematical operations to

data to render it unreadable to anyone

without the proper decryption key.

Encrypted values are reversible.

– End-to-end encryption – An encryption

approach for payment cards in which

PANs are encrypted from the point it’s

captured, usually at the point of sale

terminal, all the way through the

payment processing cycle. Cardholder

data is always stored and transmitted

as ciphertext, never in the clear.

– Format-preserving encryption – This

type of encryption encodes information

in such a way that the character length

of the encrypted data set is the same

as the original. In other words, format-

preserving encryption generates a 16-

digit value for a 16-digit PAN. This form

of encryption enables merchants to use

encrypted values, instead of plaintext,

in the legacy systems and software

supporting business processes built

around PAN-size data.

– PAN – A payment industry acronym for

Primary Account Number, which is the

14- tor 16-digit number embossed on

the front of payment cards and

encoded in a card’s magnetic strip

– Tokenization – A data security

technology in which strings of random

characters called tokens can be used in

lieu of other, more valuable data, such

as PANs

– For definitions of the security

terminology included in this paper,

please consult the glossary available

on the RSA website:

http://www.rsa.com/glossary/

Traditional data security practices are primarily based on a doctrine of protection where data is

protected like a VIP in a hostile crowd, surrounded by bodyguards on the lookout for potential threats.

The doctrine of data protection requires constant vigilance and is resource-intensive, involving firewalls,

strong authentication, data loss protection and network scanning, to name a few core elements.

Continuing the analogy of the VIP in a crowd, what if, instead of protecting the VIP, the VIP’s presence

could be concealed? Or, wouldn’t it be better if a double replaced the real VIP, removing that individual

from the threat of harm? Now, instead of a pursuing a defense doctrine based on protection, you could

focus instead on removing the high-risk target altogether.

Some of the latest approaches in payment card security take this second approach: they remove the

high-value target and make it unrewarding for attackers to stick around.

Key Technologies for Making Cardholder Data Disappear

A number of technologies have surfaced as leading contenders for making valuable cardholder data

disappear. These technologies aren’t new; in fact, some merchants with very high transaction volumes

have already deployed these technologies to secure their in-house card data environments.

Encryption

Encryption is a reliable and broadly used method for concealing data. Encryption applies an algorithm

or series of mathematical operations to unaltered “plaintext” data to render the data unreadable to

anyone without the proper decryption key. Obviously, the keys must be safeguarded to keep sensitive

data from being compromised.

The basic premise of encryption is that even if storage systems are compromised or data is siphoned off

a network, the stolen data is worthless without the decryption key. Encrypted data looks like the digital

equivalent of static. Underlying the apparent noise, however, is a consistent mathematical relationship

to the original data. Encrypted data can theoretically be hacked, particularly if hackers can steal

sufficiently large numbers of encrypted files with a few known correlations to unencrypted data to

analyze what the shared mathematical relationship might

be. Breaking an encryption scheme based on industry vetted

algorithms with appropriate key sizes is extraordinarily

difficult. Nevertheless, faster computing technologies have

made code-breaking more efficient and feasible.

While encryption effectively hides the value of data, there

are practical impediments to its use. Encryption solutions

based on the Advanced Encryption Standard (AES) or Triple

Data Encryption Standard (3DES or TDES) generate encrypted

data many characters longer than its original plaintext

counterpart, sometimes up to twice as long. (See Figure 1.)

Most applications and systems within an organization’s

payment processing infrastructure are programmed to work

only with the same number of digits found in the primary

account number (PAN) of a credit or debit card, requiring

extensive recoding of system software and business

applications, a complex and expensive proposition.

4 RSA, The Security Division of EMC

RSA Security Brief, June 2010

The basic premise of encryption

is that even if storage systems

are compromised or data is

siphoned off a network, the

stolen data is worthless without

the decryption key. Encrypted

data looks like the digital

equivalent of static. Underlying

the apparent noise, however, is a

consistent mathematical

relationship to the original data.

Furthermore, encrypted card numbers, as well as all the merchant’s systems, software and devices

storing, transmitting and accessing those card numbers, are still governed by PCI restrictions. The PCI

Security Standards Council issued a formal clarification in late 2009 stating, “Encrypted data may be

deemed out of scope if, and only if, it has been validated that the entity that possesses encrypted

cardholder data does not have the means to decrypt it.”4 So, merchants cannot have access to their

own keys if they want to exempt their encrypted card data environment from PCI assessments.

Merchants operating in-house encryption systems for payment card data don’t benefit from reduced

PCI scope. To take their encrypted card data environments outside the scope of PCI review, merchants

must contract key management to an outside party, which, in turn, must prove it’s able to protect

cryptographic keys in accordance with industry best practices such as those specified by the NIST or in

the PCI DSS.

Format-preserving encryption

Some technology vendors have introduced “format-preserving encryption” to obscure information in

such a way that the character length of the encrypted data set is the same as the original. In other

words, format-preserving encryption generates a 16-digit value for a 16-digit PAN. Preserving

compatible data formats eliminates the need to rewrite applications and databases that rely on PAN-

size data to perform their functions.

Format-preserving encryption is potentially more attractive to organizations because it’s compatible

with their existing infrastructure. IT systems and software designed to use PANs don’t need to be

reprogrammed: they can use encrypted data formatted to resemble a PAN just as readily as an actual

PAN.

Even though format-preserving encrypted values are compatible with existing business processes and

systems, some business processes – particularly those relying on continuity in payment card numbers

such as marketing analytics and customer loyalty programs – may not work well with encrypted PANs

because of key rotation. PCI DSS requires keys for encrypted PANs to be changed at least annually.

When keys are rotated, they automatically generate different encrypted values. So, this year’s

encrypted PAN will look completely different from last year’s encrypted PAN, even though both are

5RSA, The Security Division of EMC

RSA Security Brief, June 2010

Card Number 5647 8377 8388 2299

Encrypted Card Number (PAN)The encrypted value has more characters than the cardnumber and is structurally different.

Ojr73h3d^&hh#&HFH&##ED*HD#*

Format-preserving EncryptionThe encrypted value has the same number of charactersand is structurally similar, but it’s still mathematicallyrelated to the card number.

8734 6392 8581 9284

TokensThe token is structurally similar to the card number, bothin length and character type, but is randomly derived.

9483 7266 3928 9819

Figure 1Encryption and Tokenization Examples

4 “PCI SSC Issues Statement On Scope of Encrypted Data via FAQ 10359,” issued 10 Nov. 2009

6 RSA, The Security Division of EMC

based on the same payment card number. Consequently, merchants’ business applications will treat the

same encrypted PANs as different cards, breaking continuity for that card customer and affecting

business logic for applications that reply on a unique, unchanging customer identifier. Some format-

preserving encryption systems can link multiple encrypted values, such as those generated annually

through key rotation, to the same original card number. Merchants interested in preserving the

continuity of their PAN-based business processes should look for solutions with these translation

capabilities.

Format-preserving encryption shares a point of vulnerability with conventional encryption. Namely,

values generated through format-preserving encryption still preserve their underlying mathematical

relationship to the original data. This means that even though the value of the data is very well

concealed, the value nevertheless is still present and thus recoverable by anyone who can steal the key

or reverse-engineer the algorithm. Because of this, systems, software, processes and devices

processing format-preserved encrypted data still fall under the scope of PCI DSS and are subject to

review.

In-house tokenization

Tokenization is a process in which a random number generator creates strings of characters, or tokens,

that can be used in lieu of other, more valuable data. Unlike encrypted data, tokens have no inherent

mathematical relationship to the numbers for which they’re serving as safe proxies.

In payment card processing environments, tokens are random numbers that resemble and can be

substituted for PANs in a merchant’s databases, applications and business processes. Tokens can be

either transaction-based or card-based. Transaction-based tokens reference individual transactions,

whereas card-based tokens reference individual card numbers and are reused every time the

corresponding cards are used. Although merchants may choose to employ either type of token, most

merchants seem to favor card-based tokens, as they’re compatible with business processes requiring a

constant reference point, such as customer loyalty programs or behavioral analytics.

In a tokenized IT environment, tokens are matched to PANs in a central look-up database or

“codebook,” where the PANs are typically stored in encrypted form. This secure repository is the only

place where tokens and their PANs are correlated. Because the tokenization system relies on a central

database to match encrypted PANs with tokens, database availability and data latency are critical

considerations. The tokenization system must be designed,

constructed and tested to minimize the risk of outages,

slowdowns and other performance problems. Also, some

legacy applications that rely on the local storage of card data

will need to be modified to submit a token to the secure

central database.

Despite these challenges, tokenization has emerged as one

of the most promising data security technologies for the

payment processing space. We’ve seen very strong interest in

the merchant community to tokenize PANs, even among

companies that have already been validated as PCI-

compliant. Merchants view tokenization as an effective way

to reduce their PCI scope, as well as counter the mounting

costs of PCI compliance.

RSA Security Brief, June 2010

In payment card processing

environments, tokens are random

numbers that resemble and can

be substituted for PANs in a

merchant’s databases,

applications and business

processes. Tokens can be either

transaction-based or card-based.

7RSA, The Security Division of EMC

Some large organizations have already deployed in-house tokenization systems to substitute for high-

value data in their IT environments. They’re using tokens not only as aliases for PANs, but also as

substitutes for other sensitive data, such as social security numbers and bank account numbers. For

these companies, tokens reduce the number of points where sensitive information is handled and can

potentially be exploited. As a result, these companies have realized a dramatic reduction in the time,

cost and resources necessary to maintain (PCI) compliance while preserving the utility of their

information.

To put these benefits in context, it helps to understand that many merchants today store and use PANs

for reasons wholly unrelated to payment processing. They use PANs to lookup purchase histories,

transaction details and other card-based information. What merchants actually want aren’t the PANs,

but their function as away to uniquely identify a customer. Merchants should use tokens for these

types of business functions, instead. Tokens reduce the number of points in the merchant’s IT

environment where sensitive card numbers are stored and can be potentially stolen. If attackers

manage to infiltrate a merchant’s tokenized systems, only tokens can be stolen, not actual payment

card numbers that could be used for fraudulent transactions. Furthermore, if the merchant limits its

use of PANs to payment processing, then only those systems and the master look-up database need to

be PCI compliant. This would greatly reduce the infrastructure to be scrutinized under the scope of PCI

DSS.

Some merchants use tokens to safeguard card numbers kept for recurring online payments such as

“payment wallets.” Payment wallets allow customers to store credit card numbers to expedite repeat

purchases with favorite merchants. (One well-known example of a payment wallet is Amazon 1-Click.)

Merchants with payment wallets substitute a customer card number with a token. For subsequent

transactions, the token stored in the wallet serves as a look-up value for the original card number,

which is kept as encrypted ciphertext in the secure token vault. If attackers broke into the merchant’s

web servers and stole wallet data, they’d get nothing but worthless tokens, because purchases can

only be initiated through an authorized merchant account.

Looking Forward: New Opportunities Created by Tokenization

Tokenization creates an interesting condition in which the utility of data can be separated from the

data itself. In separating the PAN from its possible business applications and benefits, we not only

minimize the risks of using payment information, but we also open up entirely new business models

for PCI-compliant cloud computing and unprecedented risk transference.

PCI-compliant cloud computing

Cloud architectures are usually impractical for applications using payment card data: the high

investment needed to build a PCI DSS-compliant environment in the cloud exceeds the cloud’s

efficient resource allocation benefits in most cases. Consequently, merchants have been limited in the

types of business processes and applications they can move to the cloud, because many non-

payment-related systems use card numbers for look-up values. Tokenization enables merchants to

shift a greater range of IT-based services to the cloud by allowing many business applications that

previously used PANs (and were thus governed by PCI DSS) to use tokens instead. The ability to take

many business processes and IT systems out of PCI scope enables merchants to better leverage the

cloud to achieve significant advantages in IT efficiency, cost and flexibility.

A previous RSA Security Brief on cloud infrastructure security discusses additional technology

approaches that may also be helpful to companies seeking to tap the full benefits of the cloud while

remaining PCI-compliant.

RSA Security Brief, June 2010

8 RSA, The Security Division of EMC

RSA Security Brief, June 2010

A new model for risk consolidation and transference

In essence, tokenization enables the merchant to transfer the risk of having payment card data from

dozens (or hundreds) of systems, databases and networks to just a couple consolidated points: the

merchant’s in-house card processing infrastructure (point of sale systems, store network) and the

secure vault storing PANs. Consolidating risk into a few places – creating centralized risk repositories –

provides significant security and cost benefits. Companies can focus security resources on safeguarding

a small number of high-risk points, making it easier to protect against and monitor for intrusions.

However, the potential for risk transference and consolidation doesn’t need to stop there. Taking the

idea one step further, what if each merchant currently maintaining its own payment systems, PAN vaults

and tokenization servers could transfer these valuable IT components to central risk repositories

maintained by trusted third-parties?

In this new model, rather than relying on individual merchants to shoulder the risk associated with

payment card data, secure payment services shift that risk to service providers in the payment

processing value chain, such as gateways, acquirers, card brands or other industry organizations with

proven capabilities for securing card data. These companies become centralized “repositories of risk”

for payment card data, reducing the number of points where card data can be accidentally exposed or

stolen. Just as bank accounts insured by the FDIC provided a better way for people to save cash rather

than stashing it inside their mattresses, outsourced secure payment card services will provide a vastly

superior way for merchants to save and use payment card data within the enterprise.

We predict most merchants will move to a data security

service in the next five years that transfers payment card risk

to outside service providers. The implications of this new

business model are profound:

– The companies serving as risk repositories for payment

card data are essentially providing data security to

merchants as an outsourced service. The burdens of

security are transferred from merchants to service

providers, which must maintain and prove full compliance

with PCI DSS.

– Merchants keep the value of using PANs in business

applications without having to keep the PANs themselves.

They enjoy the benefits of use while minimizing the risk of

“owning” the data.

– Even though merchants’ security obligations don’t vanish

completely – for instance, they’re still responsible for

securing their in-house payment processing environment –

the bulk of their PCI DSS scope is transferred to service

providers.

– Investments in data security will become concentrated at

the service provider, where the high-value data resides.

Concurrently, merchants’ data security investments can

decrease, as they won’t have any payment card data to

secure.

In this new model, rather than

relying on individual merchants

to shoulder the risk associated

with payment card data, secure

payment services shift that risk

to service providers in the

payment processing value chain,

such as gateways, acquirers,

card brands or other industry

organizations with proven

capabilities for securing card

data.

9RSA, The Security Division of EMC

RSA Security Brief, June 2010

This unprecedented risk transference will result in fewer security breaches of payment card numbers,

safer card data for consumers and a new norm in which merchants preserve all the operational and

marketing benefits of tracking payment card information without having to manage the risks of

keeping actual card numbers. (See Figure 2)

Outsourced Payment Card Security

In the next two years, many companies will introduce outsourced secure payment services to manage

card data risks on behalf of merchants. These service offerings will vary widely in their approach to

security, but most will likely employ either some form of encryption or tokenization. We believe the

most effective secure payment services will use encryption and tokenization in tandem.

While in-house implementations of encryption and tokenization systems offer many benefits, which

we described in a previous section of this paper, the benefits for merchants are compounded when

those technologies are deployed as part of an outsourced secure payment service.

Lower risk of fraud resulting from electronic card data theft

Merchants subscribing to secure payment services don’t hold customers’ card data; instead, service

providers outside the enterprise safeguard card numbers on their behalf. In lieu of card numbers,

merchants use tokens for their internal business processes. If attackers break into the IT systems of a

merchant using a secure payment service, they’ll only be able to steal tokens, which have no

transaction capabilities outside the merchant. The net result is a dramatic decrease in unauthorized

transactions resulting from data security breaches, which significantly lowers merchants’ fraud-related

costs.

Risk repositoriesMerchants

Business value

Card data risk

PCI Burdens

Security investments

Figure 2

Secure Payment Services willchange how industry players sharevalue and risk. Value/risk transfer-ence patterns show that benefitsclearly accrue to the merchant.

10 RSA, The Security Division of EMC

RSA Security Brief, June 2010

Reduced PCI scope

In a secure payment services environment, most of the merchant’s IT environment is exempt from PCI

compliance because the card data environment uses tokens. The central database storing PANs and the

systems with access to that database all reside outside the merchant’s environment, meaning the

service provider, not the merchant, bears the burden of proving adequate security for those systems.

The resulting impact on merchants’ PCI assessments can be dramatic. In a recently published case

study featuring NCR, which processes tens of thousands of e-commerce transactions per year, the

company outsourced card payments to a processor that furnished tokens to substitute for card numbers

within NCR’s internal systems. By doing this, NCR reduced its PCI compliance burden from addressing

the full set of 226 questions laid out in PCI DSS to a mere 11 questions on PCI Self-Assessment

Questionnaire A.

Reduced time, effort and cost for PCI remediation, maintenance and review

In using secure payment services to minimize PCI scope, merchants also lower the time, effort and cost

of achieving and proving PCI compliance. In various published reports, merchants implementing

tokenization as part of an outsourced service reported saving up to 85% in PCI-related costs.

Less attractive target for data theft

Data thieves are unlikely to steal where they know they won’t profit from a potential theft. Companies

employing secure payment services make far less profitable targets than companies that haven’t

deployed such technologies, because even in the event of a breach, it’s unlikely attackers will be able to

monetize the data.

More efficient allocation of IT resources

Secure payment services offload much of the burden and cost of PCI compliance from merchants while

improving data security. In many instances, merchants more than offset their costs for moving to secure

payment services by not having to remediate their infrastructure to meet PCI DSS or to prove annual

compliance with the full set of PCI requirements. Moreover, as companies reduce their PCI scope, they’ll

be able to redirect internal IT resources from compliance activities to more productive activities that

drive business growth.

Practitioner Guidance: What to Look for in Secure Payment Service Providers

Companies offering secure payment services will most likely be gateways, payment processors or card

associations – companies with vast experience securing electronic payment card data. These companies

already house huge repositories of payment card information, so the incremental burden to them of

assuming the data security risks for large numbers of merchants is manageable compared to the ramp-

up required for other types of companies attempting to aggregate payment card security risks.

Entrusting card data security to an outsider requires merchants to take a leap of faith. It shouldn’t be a

blind leap, however. Merchants can assess the quality of service providers by conducting thorough

technology and risk assessments, looking at track records within the industry and evaluating the

performance guarantees and liability protections offered in service level agreements.

11

RSA Security Brief, June 2010

Following are some basic questions that merchants should ask when evaluating prospective solution

providers:

1 Does the solution provider have a track record you can trust?

The risk consolidator must be a known entity with an established track record for safely managing

payment card data. Many vendors today have few implementations under their belts, but it’s

essential that merchants be able to trust the service provider’s ability to protect against data

breaches, system failures and other quality lapses.

2. What precautions has the solutions provider taken to minimize service outages and ensure service

reliability?

Any downtime to a payment processing service makes it hugely inconvenient, if not impossible, for

merchants to handle sales using debit or credit cards. Solution providers must have redundant or

auxiliary systems that can handle transactions in the event of a fault in the primary secure payment

processing system. Also, solution providers should specify a guaranteed level of service availability

and be prepared to compensate merchants for failing to meet minimum performance requirements.

3. Can you rely on the security technologies used in your secure payment service?

Because so much is at stake, merchants must be able to trust the security technologies of any

organization offering secure payment services. Merchants should ensure all commercial solutions

(both products and services) have undergone extensive external security review.

For encryption technologies, industry testing and validation can often take years. Encryption

approaches certified by organizations such as the National Institute of Standards and Technology

(NIST) are generally regarded as strong and secure.

They’re time-tested and transparent: people know the ins

and outs. Newer encryption methods, which are usually

vendor-specific, present more uncertainties.

As for tokens, the numbers should be randomly

generated and not cryptographically based. Strong

random number generators produce spontaneous

numeric sequences that are impossible to predict. Ask

service providers about how their tokens are generated.

If you get the sense that tokens aren’t created randomly,

consider other options.

In short, be sure you understand and feel confident in

the security technologies underlying your service

provider’s solution. Don’t trust “security by obscurity.”

4. How difficult will it be to implement the proposed

solution within your IT environment?

Reducing the cost of achieving, maintaining and proving

PCI compliance won’t mean much if those gains are

nullified by large up-front implementation costs.

Solutions providers should be willing to help assess

what steps would be needed to adapt each merchant’s

unique payment processing and IT environments to

accept the service providers’ tokens. Will significant

investments be needed to recode existing applications or

upgrade systems to support the new service? Will new

point of sale hardware be needed or can existing point of

sale systems be integrated into the secure payment

service with minimal business disruption?

Entrusting card data security to

an outsider requires merchants

to take a leap of faith. It

shouldn’t be a blind leap,

however. Merchants can assess

the quality of service providers

by conducting thorough

technology and risk

assessments, looking at track

records within the industry and

evaluating the performance

guarantees and liability

protections offered in service

level agreements.

RSA, The Security Division of EMC

12 RSA, The Security Division of EMC

RSA Security Brief, June 2010

5. Are the PAN substitutes provided by the service provider compatible with your existing business

processes?

Some solutions providers furnish PAN substitutes in data formats that don’t work with a merchant’s

business applications and IT systems. For instance, legacy databases coded to work with PANs may

natively accept only 16-digit, all-numeric sequences as substitute values. If the solution provider’s

substituted value isn’t in this format, it won’t work in the merchant’s database without a rewrite of

the database software. If the format is incompatible with the merchant’s pivotal IT systems, can the

service provider modify its data format? For instance, can the data substitute be reformatted to fit

within 14 or 16 characters? Can the last four digits of the original PAN be preserved for use as the last

four digits of the substituted value for look-up purposes?

Merchants should check the data format of the PAN substitute provided by a prospective vendor. This

is a particular concern for vendors proposing to encrypt the PAN and give it back to the merchant for

use as a “token.” Encrypted PANs often are much longer than actual PANs, creating format

incompatibilities. Moreover, the keys for encrypted PANs must be rotated at least annually to comply

with PCI DSS. Merchants will have to plan for key rotation, as the keys will generate a new set of

encrypted PANs, disrupting business processes based on the previous set of encrypted PANs based

on old encryption keys.

6. Does the solution provider’s approach ease the burden of PCI compliance?

Potential PCI scope reduction is an important consideration in assessing the true cost and

convenience of secure payment services. Some vendors refer to the encrypted PANs they provide to

merchants as “tokens.” These encrypted values are only tokens in the sense that the word means

“alias” or “substitute.” They’re not random values generated by a secure tokenization system. This is

an important distinction, because it may have significant ramifications on an organization’s liabilities

under PCI DSS.

When assessing prospective service providers, ask how they generate tokens. Are they derived

through encryption? If so, merchants must surrender access to the keys to realize any benefit in PCI

scope reduction. If the service provider’s tokens are randomly derived, however, the merchants’

business processes and systems using those tokens will not be subject to PCI requirements.

7. Does the cost of the service make sense?

Pricing scenarios for these new solutions may vary considerably, especially as many secure payment

services are new and untested. Regardless, the initial and recurring costs of secure payment services

must not upset the merchant’s value equation. Offloading the risk of storing payment card data will

result in lower costs associated with lengthy PCI DSS assessments and remediation activities. It may

also provide certain financial protections in the event of a security breach. Do the cost savings and

risk reduction benefits outweigh the implementation costs and service fees of using a new secure

payment services solution? The value equation will vary for every merchant, depending on unique

factors such as the merchant’s existing point of sale infrastructure, card payment transaction volume,

and the ability of in-house IT departments to develop sound, proprietary alternatives.

A few companies now offer the type of secure payment services described in this paper. A leading-edge

example is First Data’s TransArmor™ solution, which we describe in our Solutions section.

13RSA, The Security Division of EMC

RSA Security Brief, June 2010

Summary & Conclusions

We predict most merchants will switch to secure payment services in the next five years. The

widespread adoption of secure payment services will transfer the bulk of card data risk and PCI

compliance activities from merchants to outside services providers. As a result, merchants will be able

to redirect some internal IT resources from compliance activities to more productive activities that

drive business growth.

Merchants considering the use of secure payment services will have to evaluate service providers’

track record for securing payment card data, their technology architecture for data security and their

limitations and requirements for integrating the service into the merchant’s existing processes and

payments infrastructure. In the coming months, as a wide variety of companies introduce solutions for

secure payment services, merchants will likely find at least one commercial offering that suits their

needs. For most merchants, we anticipate that the benefits of moving to an outsourced secure

payment service will far outweigh any advantages of preserving card data in-house.

14 RSA, The Security Division of EMC

RSA Security Brief, June 2010

About the Authors

Anton Chuvakin, Principal, Security Warrior Consulting

Dr. Anton Chuvakin is a recognized security expert in the field of log management and PCI DSS compliance. He

authored Security Warrior and PCI Compliance and contributed to many other books, including Know Your

Enemy II and Information Security Management Handbook. Dr. Chuvakin has published dozens of papers on log

management, correlation, data analysis, PCI DSS and security management. His Security Warrior blog is one of

the most popular in the industry. In addition, Dr. Chuvakin teaches classes and presents at many security

conferences across the world. Recently, he has addressed audiences in the United States, the United Kingdom,

Singapore, Spain and Russia. Dr. Chuvakin works on emerging security standards and serves on the advisory

boards of several security start-ups. Currently, he is developing his security consulting practice, focusing on

logging and PCI DSS compliance for security vendors and Fortune 500 organizations.

Sam Curry, Chief Technology Officer, Global Marketing, RSA, the Security Division of EMC

Sam Curry leads and sets the strategic direction for all aspects of product management for RSA solutions. He

has more than 16 years of experience in security product management, marketing, product development,

quality assurance, customer support and sales and marketing. He has also been a cryptographer, researcher

and writer. Prior to RSA, Mr. Curry held various executive roles at CA and at McAfee.

Robert Griffin, Director of Technical Marketing, RSA, The Security Division of EMC

Bob Griffin is a frequent contributor to technical publications and industry conferences. He also represents

EMC to several standards organizations, including as co-chair of the OASIS Key Management Interoperability

Committee (KMIP). Mr. Griffin has extensive experience in security strategy, corporate governance, business

process transformation and software development. During his 30 years in the computer industry, he has had

architectural responsibility for a number of production systems and software engineering projects, including as

architect for one of the first production implementations of tokenization for the retail industry.

Craig Tieken, Vice President, Merchant Products, First Data

Craig Tieken oversees First Data’s TransArmor™ secure transaction management solution. TransArmor is a

secure payment service for merchants offering a multilayered approach to data security – encryption and

tokenization. Prior to his current role, Mr. Tieken was the product family manager for credit acceptance, debit

acceptance, Fleet Card acceptance and ATM reseller product offerings. Mr. Tieken joined First Data in 1991,

focusing his career activities on the acquiring side of the payments industry.

Branden Williams, Director, Security Consulting, RSA Security Practice of EMC Consulting

Branden Williams is an information risk and security professional with more than 15 years of experience in

technology and information security. From digging into technical requirements of various solutions to

recommending compensating controls for compliance – saving companies more than $250 million in the

process – Mr. Williams has practical experience working with global clients. Currently, he owns responsibility

for Security Consulting inside the RSA Security Practice of EMC Consulting. Mr. Williams is a CISSP, CISM,

CPISM, CPISA and former QSA. He is also an Adjunct Professor at the University of Dallas’s Graduate School of

Management, where he teaches in their NSA Certified Information Assurance program.

Steve Wilson, Vice President, Payment Security and Reputational Compliance, Visa Europe

Steve Wilson is responsible for payment security and reputational compliance for Visa Europe. He hasmore than 14 years’ experience in the card payments industry, firstly with JCB and then 10 years withVisa. While at Visa, he has managed a variety of responsibilities in both marketing and riskmanagement. Mr. Wilson’s current position brings him into regular contact with banks, merchants,software vendors and security companies. Mr. Wilson and his team of technical and accountmanagement staff are responsible for minimizing the risk of financial and reputational damage to allparties within the payment chain. Mr. Smith presents regularly at conferences within Europe and acrossthe world and runs training on PCI DSS.

Solutions for Secure Payment Processing

Card payment security solutions are evolving rapidly,

driven by an escalating threat environment, shifting

customer requirements and market needs. The products

and services described below align with the

recommendations described in this RSA Security Brief, but

they are not the only applicable solutions available in the

marketplace. Rather, this list is intended to serve as a

starting point for compliance officers and security

technology practitioners wanting to learn about some of

the options available to them.

EMC Consulting Services

EMC® Consulting provides strategic guidance and

technology expertise to help organizations exploit

information to its maximum potential. With worldwide

expertise across organizations’ business, applications and

infrastructure, as well as deep industry understanding,

EMC Consulting guides and delivers revolutionary thinking

to help clients realize their ambitions in an information

economy. EMC Consulting drives execution for its clients,

including more than half of the Global Fortune 500

companies, to transform information into actionable

strategies and tangible business results. For more

information, please visit the consulting and IT services

page on EMC’s website.

First Data TransArmor

Secure Transaction Management Solution

The First Data® TransArmor secure transaction management

solution delivers payment card processing and strong data

security as an easy-to-use service. It protects and removes

payment card data completely from the merchant

environment, so your systems never hold the actual card

numbers from the transactions you process. The solution

removes the need to store card data by replacing it with a

randomly assigned number, called a “token. ”In doing so,

TransArmor management minimizes risk by reducing the

scope of PCI compliance, reduces the burden of protecting

cardholder data by removing it from your systems and

allows the token to be used for other business and sales

functions, such as returns, sales reports, and analysis.

Following is an overview of how the TransArmor secure

transaction management service works:

15RSA, The Security Division of EMC

RSA Security Brief, June 2010

12

3 4

4

5

6

6

6

Issuer

First Data switch

PKI encryption

Financial token

First Data DatacenterMerchant Environment

Transaction logsettlement data

warehouse

Merchant POS

Analytics Anti-fraud

RSASafeProxy™

architecture

Figure 3

First Data® TransArmor™

secure transactionmanagement service:how it works.

16 RSA, The Security Division of EMC

1. When a purchase is made, the payment card number is

captured and encrypted at the merchant’s point of sale

(POS) terminal. TransArmor software on the merchant’s

POS terminal handles the encryption, which is

asymmetric, meaning different keys are used for

encryption than for decryption.

2. The encrypted card data is transmitted over secure

networks to First Data.

3. First Data decrypts the PAN using a secure private key.

4. First Data presents the merchant’s transaction to the

payment card brands (i.e., Visa, MasterCard, MAC, etc.)

for authorization. Simultaneously, First Data checks the

PAN against a table of previously processed credit cards

to see if a token has already been assigned to the card

number. If so, the token is reused. If the payment card

hasn’t been previously presented to First Data, then a

new token is randomly assigned to the PAN, and First

Data logs which token corresponds to the new PAN for

future transactions. First Data re-encrypts the PAN and is

stores it as ciphertext within a highly secure data vault.

5. First Data returns the payment authorization and the

token for the card to the merchant’s POS, where the

information is stored with related transaction and

cardholder data (i.e., SKUs for items purchased,

cardholder name).

6. The merchant uses the token in other business

processes, such as sales auditing, marketing analytics,

loss prevention auditing and customer loyalty programs.

Subsequent payment transactions, such as adjustments,

refunds, “card not present” payments and delayed

settlement, can also use the token in place of the card

number.

For more information, please visit the TransArmor page on

First Data’s website.

RSA Key Manager

The RSA® Key Manager is designed to simplify enterprise

key management by managing encryption keys across

multiple encryption points in the enterprise, including

tape/virtual tape, disk, databases, and applications. It can

help lower the costs associated with encryption by giving

administrators strong control over the storage and

management of keys from one central location. It is a critical

piece of any encryption or tokenization environment,

reducing the cost of ownership while ensuring compliance.

For more information, please visit the RSA Key Manager and

Tokenization page on the RSA website.

RSA Tokenization Server

RSA SafeProxy™ architecture includes the RSA Tokenization

Server, which combines encryption, tokenization and key

management solutions to provide end-to-end data security.

The RSA Tokenization Server protects high-risk information

such as payment card numbers, social security numbers,

driver's license numbers or PIN numbers by substituting the

sensitive data with randomized token values. Instead of

maintaining encrypted data and an associated key (ID)

within the organization’s data stores, a single tokenized

value is stored and used as a pointer to the encrypted

value. A secure, cross-reference table is established to

allow authorized look-up of the original value, using the

token as the index. The token can be used within the

enterprise’s business processes and applications just like

the original number, preserving the utility of the data while

minimizing the risk of keeping it. For more information,

please visit the RSA SafeProxy Architecture page on RSA’s

website.

RSA Security Practice of EMC Consulting

The RSA Security Practice of EMC Consulting helps

organizations define security strategies and implement

solutions to mitigate risk, ensure compliance and accelerate

business objectives. A comprehensive set of services are

available to help companies integrate secure encryption

and tokenization solutions into their IT environments. For

more information, please visit the RSA Security Services

page on RSA’s website.

RSA Security Brief, June 2010

17RSA, The Security Division of EMC

RSA Security Brief, June 2010

RSA Security Brief, June 2010

www.rsa.com

EMC, RSA, RSA Security, SafeProxy and the RSA logo are registered trademarks or trademarks of EMC Corporation in the UnitedStates and/or other countries. All other products or services mentioned are trademarks of their respective owners. ©2010 EMC Corporation. All rights reserved.

CDS BRF 0610