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 Brief June 2010
20
Embed
RSA Security Brief - HotelNewsNow.com...2010/09/15 · Dr. Anton Chuvakin Principal, Security Warrior Consulting Sam Curry Chief Technology Officer, Global Marketing RSA, The Security
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
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
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
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.