Townsend Security Data Privacy Blog

VMware and PCI DSS Compliance: Taking the right steps in a virtualized environment

As of vSphere 6.5, AES encryption has been added to VMware. With VMWare encryption, complying with PCI DSS, requirement 3 is even easier. And executives are taking note as they look to conserve resources by moving their organizations databases and IT environments to virtualized platforms and to the cloud.

Security best practices and compliance regulations call for sensitive data to be protected with encryption and that data-encrypting keys (DEK) be physically or logically separated from the sensitive data and protected with strong key-encrypting keys (KEK). Depending on what type of information is being stored and what industry guidance your project/company falls under, compliance regulations in addition to PCI DSS may apply.

The Payment Card Industry Data Security Standard (PCI DSS) is one of the most rigorous and specific set of standards established to date and is used by many organizations as a standard to secure their systems. PCI DSS applies to all organizations that store, process, or transmit cardholder data, regardless of volume. This includes merchants, service providers, payment gateways, data centers, and outsourced service providers.

Here is a high level look at all twelve items that must be met in order to be compliant, with three new requirements in PCI DSS 3.0 (**) that warrant mentioning as being most relevant to the use of VMware and cloud technologies in a PCI-regulated infrastructure:

Build and Maintain a Secure Network and Systems
Requirement 1: Install and maintain a firewall configuration to protect cardholder data


(3.0) **Req. 1.1.3: "[Maintain a] current diagram that shows all cardholder data flows across systems and networks."

Requirement 2: Do Not use vendor-supplied defaults for system passwords and other security parameters

(3.0)** Req. 2.4: "Maintain an inventory of system components that are in scope for PCI DSS."

Protect Cardholder Data

Requirement 3: Protect stored cardholder data*


* Requirement 3 specifically addresses the need for encryption and key management, stating:

“Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should also be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.”

Requirement 4: Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs


Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know


Requirement 8: Identify and authenticate access to system components


Requirement 9: Restrict physical access to cardholder data

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data


Requirement 11: Regularly test security systems and processes

Maintain an Information Security Policy

Requirement 12: Maintain a policy that address information security for all personnel

(3.0) ** Req. 12.8.5: "Maintain information about which PCI DSS requirements are managed by each service provider and which are managed by the entity."

It can seem overwhelming at first, but the PCI Security Standards Council (PCI SSC) website contains this documentation along with a number of additional resources to assist organizations with their PCI DSS assessments and validations. Within the latest documentation by the PCI Security Standards Council (v3.0 released November 2013) specific testing procedures and guidance is given for Requirement 3 on pages 34-43.

Fortunately, there are also standards and published guidance on running payment applications in a virtualized environment:

Payment Card Industry Data Security Standard: Virtualization Guidelines and Cloud Computing Guidelines

NIST SP 800-144: Guidelines on Security and Privacy in Cloud Computing

Cloud Security Alliance: Security Guidance for Critical Areas of Focus in Cloud Computing

While virtual technology is not limited to VMware, it is one of the most commonly used and supported architectures by many cloud service providers. In addition to the PCI compliance and cloud guidelines above, VMware worked with CoalFire, a QSA auditing firm, to create guidance on how to specifically deploy payment applications in a VMware environment. You can access the CoalFire document  here.

As platform virtualization becomes a more popular solution, executives need to remain vigilant with their data security and meeting compliance requirements. We can help make the transition to VMware easy with our Alliance Key Manager for VMware solution, which meets the PCI recommendations when deployed properly in a VMware environment. We are committed to helping businesses protect sensitive data with industry standard NIST compliant AES encryption and FIPS 140-2 compliant encryption key management solutions.

Every few years since its inception in 2006 the Payment Card Industry Security Standards Council (PCI SSC) has revised and updated the the Payment Card Industry Data Security Standards (PCI DSS) and Payment Application Data Security Standards (PA DSS) to improve security for the payment card industry worldwide. These revisions, clarifications, and new points of guidance are based on considerations and recommendations by experts in the field of data security as well as over 700 organizations that process cardholder data. At the end of their review period, the PCI SSC concluded that revisions needed to be made based on these problematic themes in the payment card industry:

• Lack of education and awareness of how to implement and maintain PCI standards - a major problem since the improper implementation of PCI standards leads to data loss and breaches
• Weak passwords and authentication
• Lack of consistency of responsibility when implementing necessary third party security features
• Slow detection of threats
• Inconsistency of PCI assessments¹

Since the release of v3.0 in November 2013, many organizations affected by PCI DSS and PA DSS are asking: Are there new revisions regarding encryption and key management in v3.0, and what do I need to do in order to meet new recommendations, regulations, and best practices? Luckily, much of version 3.0 hasn’t changed from 2.0. However, many important clarifications have been made. In section 3 of PCI DSS (the section pertaining to encryption and management of encryption keys), version 3.0 makes clarifications regarding these aspects of encryption and key management²:

• Stricter controls around the protection and deletion of authentication data
• Key management procedures must be both implemented and documented
• The requirement of PAN masking
• The critical use of dual control and split knowledge
• The mandate that logical access for disk encryption must be managed separately and independently of the native operating system authentication and access control mechanisms, and that decryption keys must not be associated with user accounts.

Version 3.0 has also split requirement 3.5.2 into two separate requirements to emphasize the importance of both storing encryption keys in a secure location (3.5.2) as well as in the fewest possible locations (3.5.3)²

Based on the themes they found and the revisions made, it is clear that the PCI SSC is moving toward making their regulations stricter. What’s even more interesting is that in this last review, more than half of the recommendations were taken from experts and organizations outside of the United States. This is likely because the United States is farther behind other countries such as the European Union in terms of credit card data security, and since the PCI SSC sets worldwide regulations, they must set standards that meet the highest expectations.

We recommend all organizations worldwide look to the highest standards and follow best practices and recommendations (whether they are required or not) since these evolving requirements are based on current conditions and threats in the data security world and indicate future hardened regulations.

To learn more about encryption key management best practices download NIST Special Publication 800-57 “Recommendations for Key Management: Parts 1, 2 & 3” 

¹ PA-DSS & PCI DSS change highlights

² PCI DSS 3.0 summary of changes

Secure system logging on the IBM i (AS/400) can not only help you meet compliance requirements, it can help you stop a data breach before it happens!  Intruders may start with a password hack that gives them access deeper into the system.  There is usually a long trail, visible within system logs. Everything from the original breach can be detected and identified with proper monitoring of the system logs.  What really is driving the need to collect and monitor system logs centers around how often breaches are easily detected with log management.  For example:

• Less than 1% of the breaches were discovered through active log analysis
• Forensics showed 69% of these breaches were detectable via log evidence

PCI Section 10 requires logging for anyone who collects credit card data

Requirement 10:  
 “Track and monitor all access to network resources and cardholder data”

• 10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.
• 10.2 Implement automated audit trails for all system components to reconstruct the following events:
• 10.3 Record at least the following audit trail entries for all system components for each event:
• 10.4 Using time-synchronization technology, synchronize all critical system clocks and times
• 10.5 Secure audit trails so they cannot be altered.
• 10.6 Review logs for all system components at least daily.
• 10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis.

GLBA / FFIEC recommends data security logs of actions that could affect financial reporting or fraud for financial institutions.

• Network and host activities typically are recorded on the host and sent across the network to a central logging facility.
• The logging facility may process the logging data into a common format. That process is called normalization. Normalized data frequently enables timely and effective log analysis.

(This Link provides more information about FFIEC recommendations for logging)

HIPAA / HITECH ACT requires system logs of access to Protected Health Information (PHI) in the medical sector

• LOG-IN MONITORING (A) - § 164.308(a)(5)(ii)©

…the covered entity must implement: “Procedures for monitoring log-in attempts and reporting discrepancies.”

• Access controls - § 164.312(b)

(section b) Standard: Audit controls. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic PHI.

There are other compliance regulations and protocols that apply, but they all say about the same thing … you should be collecting system logs, you should be monitoring them, and you should take action based on anomalies that you find in them.  It is not enough to assert that you are doing the right thing; you have to be able to prove it with system logs that are independent from the original system files and verifiable.

System logging is important across all operating systems, but we are going to look at IBM i with greater detail due to it’s complexity.  Because the IBM i system can handle multiple applications, it doesn’t log information like others do.  The IBM i collects logs simultaneously from multiple sources and deal with large volumes: Up to 3,500 events per second…250 Million of events per day!  The essence of good reporting is externalizing the systems logs and collecting them in a central repository which helps remove the risk of tampering. Compliance regulations recognize the need to watch all users – including the most powerful users, because network originated threats to the IBM i are often not noticed or quickly responded to by IT security professionals without close monitoring of system logs.

Creating the QAUDJRN (Security Audit Journal) on the IBM i

QAUDJRN is not created or enabled by default on the IBM i platform.  If you have not set it up, you are not yet collecting system logs.  To implement system logging you create the journal and journal receiver, then set system values that control options about what information is collected. Once the values are set, the collection process begins.  QAUDJRN is non-modifiable and date-stamped and a large amount of useful information can be collected in each event.  However just running system log reports on the security audit journal are not enough. Centralizing events and monitoring them off the IBM i platform are crucial. The events need to be consolidated and correlated in a separate location (usually a SIEM Console) in order to see the whole picture and understand potential attacks on your system.  

Take Away:
If you are properly collecting and monitoring your system logs, you can detect a breach before data is lost.

To delve deeper into this topic, we are sharing this newly recorded webinar in which, security expert Patrick Townsend talks about system logging on the IBM i today and how the capabilities of Alliance LogAgent can provide you with a high performance, affordable solution that will communicate system logs securely between your IBM i and Security Information and Event Management (SIEM) Console.

As always, we welcome your questions and comments posted here!

What Standards for PCI Encryption You Need To Know and Why They Matter

Payment Card Industry - Data Security Standards (PCI-DSS) require you to encrypt credit card account numbers stored in your database and ensure data stays secure when transferred outside your company.

In order to understand these PCI encryption requirements, we first should know the source of industry best practices for encryption key management. Here in the US, the National Institute for Standards and Technology (NIST) is the most common source for guidance on best practices. The NIST special publication SP-800-57 provides specific pointers on how best practices for both procedurally managing encryption keys, and what to look for in key management systems. In these documents you will find the genesis of most standards regarding encryption key management, including the following concepts in PCI DSS 2.0 Section 3.  Next, it is important to understand the security best practices concepts of Dual Control, Separation of Duties, and Split Knowledge. I’ll simplify them here from the point of view of encryption key management:

1. Dual Control means that no one person alone should be able to manage your encryption keys. Creating, distributing, and defining access controls should require at least two individuals working together to accomplish the task.
    
2. Separation of Duties means that different people should control different aspects of your data protection strategy. This is the old adage “don’t put your eggs in one basket”. The person who creates and manages the keys should not have access to the data they protect. And, the person with access to protected data, should not be able to manage encryption keys.
    
3. Split Knowledge applies to the manual generation of encryption keys, or at any point where encryption keys are available in the clear. More than one person should be required to constitute or re-constitute a key in this situation.

In order to meet standards for PCI encryption, you need to make sure you protect these three things properly:

1. Protect your data at rest with AES Encryption
   Advanced Encryption Standard (AES) has been adopted as a format standard (FIPS -197) by the US government and many state and local agencies when it comes to encrypting data in a database. AES is the recommended encryption method for PCI-DSS, HIPAA/HITECH, GLBA/FFIEC and individual state privacy regulations. Encryption methods approved and certified by the National Institute of Standards and Technology (NIST) provide assurance that your data is secured to the highest standards.  
    
2. Protect your data in motion with PGP Encryption
   PGP encryption is the standard when it comes to encrypting files that need to be transferred.  Pretty Good Privacy (PGP) is the standard for encrypted file exchange among the world’s largest retail, finance, medical, industrial, and services companies.  Also know that when encrypting a file with PGP, you may be using AES encryption.  Transmit sensitive files over the internet using trusted encryption technologies. (AES, SSH, SSL, and PGP). Encryption solutions work together to ensure that all your sensitive data is secure even after the transmission is complete.  AES will protect data at rest within your organization and PGP keeps it secure when it is sent outside your company.
    
3. Protect your encryption keys and your data by keeping them apart!
   Leaving your encrypted data and keys in the same place is like leaving the key to your house under your welcome mat.  Security best practices require that you store encryption keys separately from your encrypted data and managed with an encryption key manager. It is also important to note that. In regards to the cloud, PCI SSC recently offered this guidance:
   In a public cloud environment, one Customer’s data is typically stored with data belonging to multiple other Customers. This makes a public cloud an attractive target for attackers, as the potential gain may be greater than that to be attained from attacking a number of organizations individually. Strong data-level encryption should be enforced on all sensitive or potentially sensitive data stored in a public cloud. Because compromise of a Provider could result in unauthorized access to multiple data stores, it is recommended that cryptographic keys used to encrypt/decrypt sensitive data be stored and managed independently from the cloud service where the data is located.

Download the whitepaper Meet the Challenges of PCI Compliance and learn more about protecting sensitive data to meet PCI compliance requirements.

At Townsend Security, we ensure our customers data is secured to the highest level for compliance. Our AES encryption solutions are NIST validated and our encryption key management solutions are FIPS 140-2 certified.  Our HSM appliances integrate seamlessly with Windows, Linux, UNIX, IBM Power Systems and Microsoft SQL Server 2008/2012 (enterprise edition) and can also work with earlier/non-enterprise editions of SQL Server.

As always, if you have comments or questions about PCI encryption, please list them here

I went to my first ever kickboxing class the other night, and it kicked my butt, LITERALLY.  I thought that because I work out on a daily basis and recently ran a 10K, that a 1-hour kickboxing class would be a nice cardio day for me.  Boy was I wrong.
I can imagine that PCI audits can be like this for others, maybe even you.  You think you have nothing to worry about (after all, you have been investing heavily for this day) and then WHAM, your auditor/kickboxing instructor knocks you down flat!

We hear this from companies as they go through their audits: “We thought we were doing everything correct.  All our cardholder data was encrypted!”

What these companies fail to realize, and what the auditor will quickly point out, is that proper encryption requires encryption key management!

“But wait, we are a level two merchant and you want us to do what?  Manage our encryption keys?  Since when do you have to manage your encryption keys separate from your appliance?  Doesn’t IBM offer a key store on your IBM i (AS/400, iSeries)?"  I was shocked the exact same way when my instructor said, “We’re going to do 2 punches, 1 hook, and a roundhouse kick to the bag, and you need to repeat this for the next 2 minutes!”  Are you kidding me?

Townsend Security works with you to meet PCI audit requirements.  We assist organizations both large and small obtain compliance in sections 3 & 4 with our AES encryption and encryption key management solutions.  We also address issues of section 10 by providing customers our Alliance LogAgent, the system logging solution for the IBM i.

Passing an audit, like kickboxing, is a lot of work and not something you can just wake up and do well.  They both take an investment of time and resources - and at the end of the day, you will be stronger and able to defend yourself.

If it weren’t for the great support and expertise of my teachers, I would not have survived my first class.  Cheers to them and cheers to Townsend Security helping companies of all sizes meet their PCI audits.

For more information on passing your PCI audit, download our white paper “Meeting the Challenges of PCI Compliance” and learn what will your auditor look for, how you can ensure your PII is secure, and why auditors are looking specifically at encryption key management.

Customers moving to a hosting provider or cloud provider are often confused about PCI DSS compliance regulations, and what their responsibilities are in that environment. Some companies feel that they can avoid compliance concerns by moving to a cloud service. Some feel that they are no longer under compliance regulations at all in that environment. I heard this comment just this week:

“I don’t need to worry about compliance because my hosting provider says they are PCI compliant.”

This is dangerously wrong.  Let’s sort this out.

First, hosting providers who say they are PCI compliant are usually talking about their own systems, not about yours. Their credit card payment application is PCI compliant, they run the required vulnerability assessments on their payment processing applications, they collect system logs, and so forth. All of these things are required by the hosting or cloud provider for their own systems to be PCI compliant. They aren’t talking about your applications and data.

This does not make you automatically PCI compliant when you use their platforms or applications. You still bear the responsibility for meeting PCI compliance in your applications. Regardless of the hosting or cloud implementation (Infrastructure-as-a-Service, Platform-as-a-Service, Software-as-a-Service, or a hybrid approach), you are always responsible for PCI compliance of your data.

What does the PCI Security Standards Council (PCI SSC) say about cloud environment?

The hosted entity (you) should be fully aware of any and all aspects of the cloud service, including specific system components and security controls, which are not covered by the provider and are therefore the entity’s responsibility to manage and assess.

And,

These challenges may make it impossible for some cloud-based services to operate in a PCI DSS compliant manner. Consequently, the burden for providing proof of PCI DSS compliance for a cloud-based service falls heavily on the cloud provider, and such proof should be accepted (by you) only based on rigorous evidence of adequate controls.

As with all hosted services in scope for PCI DSS, the hosted entity (you) should request sufficient assurance from their cloud provider that the scope of the provider’s PCI DSS review is sufficient, and that all controls relevant to the hosted entity’s environment have been assessed and determined to be PCI DSS compliant.

Simply put, you are responsible for understanding which parts of PCI compliance a cloud vendor can help you with, and which parts they can’t.

There is no cloud implementation that relieves you of the responsibility of protecting your data. See section 4.3 in this PCI guidance.

What does this mean from a practical point of view?

This means that you must meet all of the PCI DSS requirements for your cloud implementation. You may be able to take advantage of some PCI compliant services provided by the hosting or cloud vendor, but you must have the cloud vendor provide you with guidance, documentation, and certification.  You are not off the hook for responsibility in these areas.

Please note the chart on page 23 of the PCI cloud guidance. There is no hosting or cloud implementation that covers your data. You are always responsible for protecting your customer’s cardholder data. This means complying with PCI DSS Section 3 requirements to encrypt the data and protect the encryption keys.

There is no magic bullet. You have to do this work.

Living through a data breach is no fun, and I would not wish this experience on anyone. In hosted and cloud environments, ignorance is not bliss.

Stay safe.  For more information, download our whitepaper Meet the Challenges of PCI Compliance and learn more about protecting sensitive data to meet PCI compliance requirements.

Patrick

At Townsend, we have a lot of conversations with customers and prospects about data privacy, compliance requirements and best practices for IT security in general.  We have written numerous articles on these topics and posted them on our blog.  As the end of 2011 quickly approaches, we thought it would be worthwhile to list out our most read articles of the year.

Listed below are the top five read articles from the past year:

• AES Encryption Flaw - Calm Down
  
• PCI DSS 2.0 and Encryption Key Management
  
• Encryption and Key Management in a .NET World
  
• IBM i FIELDPROC Surprises
  
• RSA Encryption Key Size Requirements Change in 2011

We aren’t surprised that the articles on these topics; encryption, key management and PCI compliance are some of the most read on the blog.  We spend the majority of our days talking to people about these topics and helping them solve challenges around data privacy and compliance.  In fact, many of the conversations we have lead to new products and product enhancements.    

In 2012, we encourage you to talk to us about what you need and what you are doing at your company to protect sensitive data.  Subscribe to our blog, like us on Facebook, follow us on Twitter or join us on LinkedIn.

We hope you find the articles listed useful and that it inspires you to think of topics you would like us to write on for 2012. Thank you for your readership in 2011!

We are already preparing and looking forward to sharing more about data privacy in 2012.  

Happy Holidays!!

Lately we are seeing an increase in questions around PCI requirements for encryption key management.  We are hearing from Level 2 merchants who are preparing for the June 30, 2012 deadline for companies that accept Mastercard. These companies are beginning to realize that they can’t just encrypt data to meet PCI requirements, they also need to securely manage their encryption keys.

To summarize the deadline, which is effective June 30, 2012, MasterCard Level 2 merchants have 2 choices for complying with PCI-DSS requirements.   

Option 1: They can complete an annual self-assessment questionnaire AND prove that a member of their organization has attended and successfully passed PCI SSC-offered merchant training program. 

Option 2: Businesses can elect to complete an annual onsite assessment conducted by a PCI SSC approved QSA.

Whether a business elects to certify a member of their team or undergo a PCI audit by a QSA auditor, they are becoming better educated about PCI-DSS requirements. Additionally, they are asking questions internally about how to meet requirements and seeking out answers to questions they can’t answer themselves. These Level 2 merchants are now starting to understand the NEED to be PCI complaint and realize how much they need to do. Townsend Security can help answer questions businesses have about data privacy and security because we focus on encryption and key management, which are discussed in section 3 and 3.5 of the PCI-DSS.

I talk to merchants on a daily basis around this topic and people understand the importance of encrypting data, but many don’t understand the need to securely manage their encryption keys. Storing your encryption keys on the same server as your data is problematic.  Before these new regulations Level 2 merchants weren't aware that PCI DSS requires separation of duties and dual control.  Quite simply, you don’t want the same person who has access to the encrypted data to have access to the encryption keys. Think of your encryption key as the figurative “key to the kingdom” - it unlocks the data that you have secured with encryption.  You wouldn’t lock your front door and leave a note saying the key is under the mat. You take your keys with you and only give keys to trusted people – the same philosophy should apply to the way you secure your encryption keys.

Level 2 merchants are realizing they need a secure server to protect their keys. They are researching encryption key management solutions and discovering our FIPS 140-2 certified Alliance Key Manager may be the solution they need.  

If your company is struggling with understanding PCI requirements for key management, download this whitepaper to learn more.  If you need a solution for key management and want to talk to a security advisor about the specifics in your IT environment, send us an email.  We are happy to answer your questions and schedule a 15 minute technical overview. 

I'll also be at the PCI Conference next week in Scottsdale, AZ so make sure to stop by our booth and say "hi".

As “The Encryption Company,” we often blog about meeting PCI DSS with encryption and key management.  Our NIST-certified technologies will help your organization satisfy Section 3 of PCI DSS, as well as other privacy regulations.  But there is another section of PCI DSS that Townsend Security can help you with – Section 10.

Section 10 states the requirements for tracking and monitoring access to network resources and cardholder data.  Some things that this section speaks on is procedural – daily reviewing logs for all system components and retaining an audit trail history for at least one year.  Section 10 also specifies how your logging solution needs to perform.  This includes automating audit trails for all system components and securing audit trails so that they cannot be altered.

This regulation is especially important for organizations using IBM i’s.  The state of logging on most IBM i’s is not good.  The IBM i doesn’t log information like your other systems and the security logs that it does produce are often an enclave inside the IT organization.

So what does this mean?  Only the IBM i administrators can know what is happening on that machine – all the valuable logging information is sequestered on the IBM i.  Network originated threats to the IBM i are often not noticed or responded to by the security team.  This puts a lot of sensitive data at risk and your organization not meeting compliance regulations.

There is an answer.  Townsend Security has been helping customers meet section 10 of PCI DSS with Alliance LogAgent.

Alliance LogAgent

• A complete solution that can capture and forward all IBM i security events
• Built by IBM i experts specifically for SIEM integration
• Robust filtering capability minimizes network impact
• Strong encryption between IBM i and SIEM console
• Seamless integration with ANY SIEM console
• Integrated User Monitoring and log forwarding 

To learn more, we recently recorded a webinar titled “Understanding Log Management on the IBM i.”  View this 30-minute webinar and learn how to meet compliance requirements with real-time security event logging across your Enterprise.

The generation of tokens is an important part of the new PCI SSC guidance on tokenization. Tokens can be generated using a number of techniques including random number generation, encryption, sequential assignment, and indexes. Using tokens to recover the original credit card number must be “computationally infeasible” according to the new guidance.

In this area, I think the tokenization guidance could be much stronger. To the cryptographic community it is well understood how encryption and proper random number generation can produce results that can’t be feasibly reversed using computational methods. The use of indexes and sequential assignment is a lot more “iffy” in my mind. Here is an example: I have a table sorted by the credit card number that contains 100,000 rows. I read the table and assign tokens in a sequential manner.  Are these tokens as strong as tokens generated by a random number generator? Obviously not. Merchants and QSA auditors need to be very careful about a tokenization solution that uses indexes or sequence numbers for token assignment.

The use of encryption to generate tokens should also give merchants some pause for extra thought. First, using encryption may produce tokens that are indistinguishable from normal credit card numbers. The guidance discusses distinguishability of tokens, and if you use encryption to generate tokens you are probably going to have additional work in this area. Secondly, it is not clear yet if tokens generated in this manner will be subject to additional encryption and PCI SSC guidance. The work released today holds open the likelihood that there will be additional guidance for these types of tokens. In other words, the jury is still out on the use of tokens generated by encryption. Lastly, tokens generated by an encryption method almost certainly have to meet all of the PCI DSS requirements for encrypted PAN. It is hard to imagine any other outcome. Merchants will want to be extra careful when deploying a solution that uses encryption to generate tokens.

Lastly, we can expect to see an increase in the number of cloud based tokenization solutions coming to market. The new guidance only touches on this in a tangential way when it discusses the need to carefully review all aspects of a tokenization solution. Since most clouds are based on virtualized environments, I suggest that you read the PCI SSC virtualization guidance from the PCI SSC. It is very hard to see how any of the most popular cloud environments can meet the recommendations of that guidance.

Big kudos to Troy Leach and the members of the tokenization SIG and Working Group who’ve been laboring on this document! The council and advisory committees also deserve praise in nurturing this process. The stakeholders are a diverse community with sometimes conflicting interests. The result speaks well to the management team. I know that we’ll be seeing more work from this group in the future.

Click here for more information on Alliance Token Manager, our tokenization solution and learn how we can help your organization with a certified and comprehensive tokenization technology.

-Patrick