Comment: Still searching for a silver bullet for PCI DSS Compliance?
Everyone still storing credit card numbers or handling cardholder data has a challenge ahead to manage their business through cost implications, technology deadline dates, changes to the Payment Card Industry Data Security Standard (PCI DSS) standard and increased pressure from brands, fraudsters and their own management.
By Ryan Rubin
PCI DSS 2.0 was released in October 2010. Although there were no major changes to the existing version of the standard (PCI DSS 1.2), some noteworthy developments have taken place. In particular:
• The standard is maturing and becoming more stable.
• Further clarity has been provided for key control areas.
• Specific technical changes have been made.
• Emerging technologies have been acknowledged as playing a role in achieving compliance.
PCI DSS continues to mature and is becoming more widely adopted across the globe. The PCI Security Standards Council (Council) has consolidated ownership of payment application security (PA DSS) and payment terminal security (PTS). In addition the Council has established a three-year change life cycle under its governance, ensuring that those already planning PCI DSS compliance activities have time to respond to the changes.
The Council has provided flexibility for organisations by giving them options for when they need to comply with PCI DSS 2.0. Organisations can either continue to validate compliance to 1.2 until the end of 2012, or, alternatively, starting in January 2011, organisations willing to take the plunge to 2.0 can do so immediately. This is one of the key benefits of the three-year life cycle as it provides further flexibility to organisations already in the middle of their compliance activities.
The Council’s View
PCI DSS 2.0 makes it clear that the primary account number (PAN) is the defining factor in the applicability of PCI DSS requirements. If organisations are not storing, processing or transmitting PAN data, they will be out of scope for PCI compliance.
With the release of 2.0, the Council has started to take the first steps towards a risk-based approach to security management, thereby leaving organizations to take risk-based decisions regarding security remediation activities. However, this approach is limited to a few processes such as key management, patch management and vulnerability testing. Meanwhile, the prioritised approacha method of allocating a weighting of importance to control requirementswas not identified as a formal approach that can be adopted for compliance. This is in contrast to the European card brands view that encourages the use of this as a practical approach to focus their remediation efforts.
The Council also recognises that emerging technologies, if implemented appropriately, may play a role in reducing the scope of the cardholder environment. It did not, however, include specific scope reducing technologies in the new version of the standarda move seen as wise because such requirements should not be present within a standards framework. Nonetheless, the Council has made its first steps towards acknowledging that technologies such as point-to-point encryption and tokenization can play a role in helping organisations comply with PCI DSS. Further guidance on this will be issued later in 2011.
So, what scope reduction solutions are available?
1. Point-to-point encryption
This relies heavily on key management processes and policies that the organisation implements. Most organisations tend to struggle with these control requirements and should take care to ensure that this is a focus area. Areas of interest will be the ownership, creation, maintenance, updates and destruction of keys used to support the point-to-point process.
2. Tokenization
This relies heavily on appropriate database, network, platform and application security controls. Without them, although reducing the surface area for attack, these solutions have only shifted where the cardholder data will be stored and processed. Without effective system controls, this initiative may undermine what the organisation is trying to achieve in protecting cardholder data.
3. Outsourcing
This offers a great promise to take security problems away from the company’s environment. However, risks of credit card loss will still reside with the company, despite the transfer of responsibility to a third party. Therefore, choosing the right partner and gaining the appropriate level of assurance from third parties, on a regular basis, will be an important factor in adopting this strategy successfully.
Point-to-point encryption, outsourcing and tokenization clearly show great promise for those looking to cut down their compliance costs and reduce overall risk of credit card data loss. However, they may introduce their own risks, and don’t fully address wider PCI DSS or other compliance requirements. These strategies should continue to be explored and adopted, in conjunction with other compliance regimes.
Does this remove the need for PCI compliance?
Even though innovative solutions are available to remove credit card data from IT systems and business processes, many organisations still have not closed the chapter on PCI. Unfortunately, however promising strategies such as point-to-point encryption, card data processing outsourcing and tokenization are, they still don’t always address the full problem.
Some enterprises have viewed these solutions as silver bullets to address their PCI compliance gaps. These organisations are encouraged to see them as a part of their overall compliance efforts but not lose sight of the continuous security controls improvement required. Even if a solution is implemented, there are still many considerations that should not be overlooked:
– Ensure an accurate PCI DSS scope is defined for the cardholder environment.
– Maintain visibility of where cardholder data is stored, processed and transmitted.- Maintain a suitable cost / benefit ratio for future solutions.
– Protect data adequately whilst remediation projects are in progress.
– Cleanse the current cardholder data environment.
– Align business processes and policies for handling cardholder data to PCI DSS.
– Implement adequate controls to protect the tokenization / encryption systems.
– Ensure that key management activities are formally managed.- Ensure that network, database, system and application controls are adequate.- Gain adequate assurance from third party suppliers.
Accurate scoping and data mapping
Before embarking on a scope-reducing remediation project, it is important to ensure that card data mapping and adequate scoping exercises are undertaken because remediation projects may overlook business processes, applications and databases containing cardholder data. If these are not in scope for the target remediation project, the full objectives may not be met.
Documenting card data flows on an annual basis is a still a key requirement in 2.0. Moreover, this requirement must now be undertaken by the merchant before any assessment takes place. Additionally, information on scoping should be shared with the assessor and retained for evidence purposes. The Council will be introducing a tool in 2011 to assist organizations in scoping out their cardholder environment based three different types of model environments.
Data cleansing
Where organisations already store cardholder data, they will still need to undertake a cleansing exercise to remove historical data from their cardholder environments, including application history files, customer databases, e-mail and fax systems.
Infrastructure cost implications
Changes to support innovative solutions may require upgrades to underlying technologies such as point-of-service (POS) devices, payment applications, network infrastructure and databases. Some projects may require a technology refresh, integration and roll out that will take time to mature. The costs of these technology updates can be high and should be evaluated to ensure the cost/benefit ratio is still appropriate.
Keeping credit card processes in scope
Even when scope reduction strategies are followed, staff may still need to manually access cardholder data to process a transaction (e.g., accept a payment), support reconciliations, handle chargebacks, analyse reports or support general enquiries.
Maintaining PCI DSS compliance
Finally, it is important that the infrastructure and processes supporting scope-reducing technologies are also PCI DSS compliant. It is expected that since the footprint of such solutions will be much smaller, the effort required for compliance should also be less. Companies should ensure that adequate controls are implemented as part of the overall solution proposed.
Conclusion
Depending on where your organisation is along the PCI journey, there are definite opportunities to reduce the scope of PCI compliance and take advantage of emerging technologies. However, there will never be a silver bullet to complying with PCI DSS requirements.
With the recent changes to the standard, there may be benefits of moving straight to PCI DSS 2.0 if, for example, an organisation is still in the gap assessment phase or in the middle of remediation. If the organisation is under pressure to validate compliance, a sensible approach may be to validate compliance to 1.2 and start a parallel activity to gap assess and remediate to 2.0 during 2011.
In closing, the standard continues to mature. The proposed changes will not have a major impact on organisations that already comply with 1.2. They do, however, provide further guidance and clarity that will make PCI DSS compliance more achievable going forward.
There is now the opportunity for those involved in PCI DSS compliance to provide feedback for the next version before it is released in 2013.
Ryan Rubin is Director in Protiviti’s London office and leads Protiviti’s PCI DSS service offering for the CEMEA region. Additionally he co-ordinates European security, privacy and computer forensic services. Ryan has spoken at several conferences including those at ISACA, PCI Europe, I4, Infosec, MIS training, IIA, Gartner, and will also be speaking at the upcoming ISACA event, EuroCACS 2011, 21-23 March. The European Computer Audit, Control and Security (EuroCACS) Conference will take place at The Midland-Manchester Hotel, Manchester.
