Every retailer still storing credit-card numbers or handling cardholder data has a challenge ahead to manage its business through cost implications, technology deadline dates, changes to the Payment Card Industry Data Security Standard (PCI DSS), and increased pressure from fraudsters and the company’s own management.
PCI DSS 2.0 Changes
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, that emerging technologies have been acknowledged as playing a role in achieving compliance.
Further, PCI DSS continues to mature and is becoming more widely adopted across the globe. The PCI Security Standards Council (Council) has established a three-year change lifecycle 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 lifecycle 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)—the 14 or 16 digit number embossed on the front of credit and debit cards—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.
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 standard. Nonetheless, the Council has made its first steps towards acknowledging that technologies can play a role in helping organisations comply with PCI DSS. These technologies may include:
1. Point-to-point encryption
This is a method of encrypting data across networks. 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.
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 is stored and processed. Without effective system controls, this initiative may undermine what the organisation is trying to achieve in protecting cardholder data.
This offers a great promise to take security problems away from the company’s environment. However, risks of credit-card losses 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 tokenisation 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.
Reducing PCI scope
Before embarking on a scope-reducing project, it is important to ensure that 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 PCI DSS 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 PCI assessor and retained for evidence purposes. The Council will be introducing a tool later this year to assist organisations in scoping out their cardholder environment based on three different types of model environments.
Before introducing any new technologies, organisations that store cardholder data will need to undertake a cleansing exercise to remove historical data from their cardholder environments, including application history files, customer databases, email and fax systems. But remember, even when scope reduction strategies are followed, staff may still need to manually access cardholder data to process a transaction, for example to accept a payment, support reconciliations, handle chargebacks, analyse reports or support general enquiries.
Then there is the system cost to take into account. 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 rollout 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.
Finally, it is important that the infrastructure and processes supporting scope-reducing technologies are also PCI DSS compliant.
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.
Ryan Rubin is a director at business consultancy Protiviti. He is also a speaker at the upcoming IT security event EuroCACS.
*Mandatory fields your email address will not be published. All comments are moderated and may be edited. Comments do not necessarily reflect the views of the Catalogue Development Centre Ltd.