Take the right steps to meet compliance in a virtualized environment
With executives looking to conserve resources by moving their organizations databases and IT environments to virtualized platforms and to the cloud, there are concerns around virtualized environments. 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 from the VMware website 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.
To learn more about enterprise key management for VMware and vCloud, download our podcast "Virtualized Encryption Key Management".
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 assessments1
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 management2:
- 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)2
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”
1 PA-DSS & PCI DSS change highlights
2 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.
- Less than 1% of the breaches were discovered through active log analysis
- Forensics showed 69% of these breaches were detectable via log evidence
Compliance regulations require (or strongly recommend) system logging. Do you know which of these apply to you and your company?
PCI Section 10 requires logging for anyone who collects credit card data
“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.
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:
- 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.
- 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.
- 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:
- 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.
- 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.
- 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 on a certified encryption key management appliance known as a hardware security module (HSM). The most important part of a data encryption strategy is the protection of the encryption keys you use. Encryption keys safeguard your encrypted data and represent the keys to the kingdom. If someone has access to your keys, they have access to your encrypted data.
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
Download the white paper "Meet the Challenges of PCI Compliance" and learn more about ensuring the data you are protecting meets PCI compliance.
Click Here to Download Now
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.
Download the white paper "Meet the Challenges of PCI Compliance" and learn more about ensuring the data you are protecting meets PCI compliance.
Click Here to Download Now
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.
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.
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:
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.
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.
Download the white paper "Meet the Challenges of PCI Compliance" and learn more about ensuring the data you are protecting meets PCI compliance.
Click Here to Download Now
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 me an email. I am 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".
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.
Today the Payment Card Industry Security Standards Council issued some long awaited guidance on tokenization as a method of protecting credit card information (“PAN”, or Primary Account Number in PCI language). This guidance has taken a number of months to produce, and will be very helpful to merchants who want to deploy tokenization solutions to reduce the scope of PCI compliance efforts, for those who have already deployed solutions and need to assess if they meet minimum requirements, and for QSA auditors who have been looking for some guidance in this area.
The link to the guidance is here.
Here are some first thoughts on reading the guidance.
As I’ve been saying here before, a tokenization solution is always in scope for PCI DSS compliance. This means the merchant is responsible for insuring that a tokenization solution itself meets all of the PCI DSS requirements. Whether you create your own tokenization application, or you acquire one from a vendor, it is in scope for PCI DSS compliance and you are responsible for it. The guidance makes this point very clearly. In fact, the guidance makes the observation that tokenization solutions are likely to be the targets of attack because they become a centralized repository of credit card information. Merchants should be very careful that their tokenization solutions meet all PCI DSS requirements and are sufficiently hardened. In my opinion, there are very few merchants who would be up to the task of creating such a solution in-house.
Following on the previous point, a tokenization solution must have encryption and key management capabilities that meet PCI DSS requirements. This means special care in the deployment and implementation of key management. You should be very sure that your key management solution implements proper Dual Control, Separation of Duties, Split Knowledge, and separation of keys from protected data. When acquiring a vendor solution for tokenization look for FIPS-140-2 certification of the key management system – that should be a minimum requirement to indicate the proper implementation of encryption and controls.
Download a recent webcast I recorded that discusses the importance of tokenization and PCI compliance.
Today’s announcement by the PCI Security Standards Council on tokenization is certain to raise awareness about the importance of selecting the right tokenization solution for your organization and ensuring it meets the PCI DSS requirements. I will be post another article Tuesday that will discuss more thoughts on this new guidance.
I hope you find this helpful.