Version 1.2 of the Payment Card Industry Data Security Standard (PCI DSS) will clarify some points of contention that assessors, merchants and service providers have lived with for several years now. There will be more consistent use of language in the standard, more clarity on the interpretation of controls, as well as new updates designed to ensure that more merchants can meet the standard (while staying secure).
The PCI Security Standards Council has assured us in its summary document that there are no new major requirements in 1.2; the 12 familiar requirements remain. But merchants and service providers know that adjusting to small changes can arduous and costly. So it's wise for merchants, service providers, and assessors to think about and plan for the upcoming changes as soon as possible. Planning a strategy now can mean the difference between a smooth rollout and a last minute scramble. With that in mind, let's take a look at specifically where and how controls might have to change based on the preview of the council's updates.
Specificity: You asked for it, you got it
By contrast to some other regulations, like HIPAA and SOX, PCI DSS is prescriptive in nature, meaning it specifies particular technical controls that an enterprise needs to deploy and, in many cases, details how they should be implemented. Many merchants and service providers, however, feel that prior versions of the standard don't go far enough; there's too much "wiggle room" in how the controls are interpreted.
For example, Requirement 3.4 of the 1.1 standard mandates the use of "strong cryptography" to protect primary account numbers (PANs), but leaves open the question of what counts as "strong." Some assessors have interpreted "strong cryptography" to mean only cryptographic modules that have gone through FIPS 140-2 certification; others consider older algorithms like DES sufficient. Having a broad spectrum of interpretation makes it difficult f...
To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
or merchants and assessors to stay on the same page: a merchant might find itself in the position of having a control that passed last year, but could possibly fail a year later (or vice versa).
Version 1.2 of the standard promises to help clear up some of these gray areas. But this can mean additional work in areas where organizations may have misinterpreted controls.
For example, the council has clarified that Requirement 9 of the standard ("restrict physical access to cardholder data" ) applies to paper records containing payment instrument information -- cardholder data -- as well as electronic data.
This single change has wide-ranging implications. Imprints of cards made by taxi drivers, the written card number on a plumber's invoice, the discarded carbon copies made from offline impressions -- there's no question now that these all need to be protected and physically secured. Firms that are not currently protecting this data will find that they have numerous logistical challenges on the horizon. They'll need to track the life cycle of those paper documents, locate and document places where the forms are stored, and ensure that the proper physical-access restrictions are implemented. These firms will need to deploy the same types of controls as they would for a data center or electronic repository of data.
In situations that involve semi-public or constrained areas, implementing the appropriate physical access controls can prove difficult or impossible With a taxi company, for example, implementing robust physical protections for the impression documents is a tall order. Since compliance may require some significant work, the time to start thinking about this is now -- while budgets are still under discussion. Some firms may find that the cost of replacing paper-based transactions with electronic alternatives may be a cheaper long-term option than implementing the requisite physical controls. That taxi company might find it more cost-effective to implement payment terminals for passengers to use rather than trying to deploy physical controls to protect hard-copy documents.
Controls: Softening some, hardening others
Aside from the clarifications, there are also some notable changes to existing controls. Requirement 5, for example, is getting stronger; instead of mandating only Windows systems to use antimalware software (which was the practical implication of version 1.1 of the standard), the requirement has been expanded to include other systems as well.
For most merchants and service providers, the extension of Requirement 5 will require the installation of antimalware on back-end systems like Unix. Merchants that don't have an appropriate AV product for these platforms might want to consider carving out a niche in the 2009 budget to review a few tools that support the functionality. For many merchants, keep in mind, this requirement can also affect the point of sale. Merchants looking to follow this control should consider point-of-sale systems based on commercial OSes and establish where they do not have antimalware software currently installed.
On the other hand, some of the more difficult controls have been opened up to allow more flexibility. Take, for example, Requirement 9.1.1, which mandates the use of cameras and the retention of camera footage for areas where card data is in play. Organizations like restaurants and "mom and pop" shops, however, have found this control particularly challenging, as customers are not always happy about obvious cameras, not to mention the volume of space that would need to be monitored. Similarly, a small retail store may not have the funds to implement a camera at the point of sale.
The requirement now allows organizations the flexibility to select other access control methods where appropriate. The actual text of the requirement will likely clarify if there are additional constraints about acceptable alternative methods, but it's not difficult to imagine approved controls such as enhanced authentication for payment-accepting kiosks or for semi-public points of sale in restaurants.
Taken as a whole, the changes outlined by the PCI Security Standards Council for PCI DSS version 1.2 seem like they'll make life easier. That's not to say that there won't be a few logistical hiccups on the way, but it's clear from the summary of changes that the council is listening to the feedback from the trenches.
About the author:
Ed Moyle is currently a manager with CTG's Information Security Solutions practice, providing strategy, consulting, and solutions to clients worldwide as well as a founding partner of Security Curve. Prior to joining Security Curve, Moyle was vice president and information security officer for Merrill Lynch Investment Managers (MLIM,) where he was responsible for coordinating all aspects of information security within the business unit.
Before joining Merrill, Moyle worked within the federal sector for Computer Science Corporation (CSC,) where he consulted to the Department of Defense JCALS (Joint Service Computer Aided Acquisition and Logistics System) program. Moyle is co-author of "Cryptographic Libraries for Developers", and a frequent contributor to the Information Security industry as an author, public speaker, and analyst.
