In this tip, we'll examine five common myths surrounding PCI DSS compliance to help you set the record straight.
Myth 1 - PCI is hard
The No. 1 myth is that PCI is hard. It's not uncommon to find IT staff wringing their hands over where to start. With 12 requirement areas, it can be a daunting task just to make sense of the comprehensive guidelines.
But, in fact, PCI mostly calls for good, basic security. A diligent company should meet most of the requirements prior to even reviewing themselves for PCI compliance. Additionally, there are a number of products and services available to help meet almost any of the requirements. IT departments don't have to reinvent the wheel to meet PCI.
While many people say PCI compliance is hard, what they really mean is that it is not cheap. IT security professionals know there are glaring gaps in the security postures of their companies. Many make tremendous efforts to determine how best to plug those security holes, only to be thwarted by higher-ups because costs would be too high. In order to comply with PCI, organizations must realize that the requirements of a sound, basic enterprise security strategy can't be ignored, and that often means expanding the security budget.
So PCI may be expensive, but it is certainly not hard.
Myth 2 - PCI will make us secure
Myth No. 2 is a follow-up to Myth No. 1. Once a company is PCI compliant, it may become complacent, thinking that it is un-hackable. Again, PCI is designed to be a measure of basic, baseline security, not a security panacea. Like with all security paradigms, diligence is required. The PCI audit or assessment you conduct is a snapshot in time, but as time passes, it's easy to fall out of compliance and become less secure. PCI compliance is a continual process -- a great foundation to create information security awareness and build an increasingly strong fortress around an organization's sensitive data.
Myth 3 - Encryption is scary
The one requirement that most consistently frightens enterprises is encryption. There are two types of encryption specified by PCI: "data at rest," and "data in motion." Of the two, data in motion is far easier and more common. This is covered in Requirement 4: "Encrypt transmission of cardholder data across open, public networks." For most organizations, this means IPsec or SSL VPN tunnels when transmitting cardholder data across the Internet. This is standard stuff for most companies and poses little difficulty.
Where companies get a bit more jumpy is when they confront the concept of "data at rest." This essentially means encrypting data while it sits on a hard drive. Traditionally this level of crypto required a full public key infrastructure (PKI) deployment. As someone who has been involved in a number of complex PKI implementations, I can understand that apprehension. This fear is so pervasive that a credit card company executive reportedly hinted that PCI would relax the data-at-rest standards3, causing considerable consternation within the PCI community.
To that end, Requirement 3.4 has created a cryptographic explosion. There are many vendors who have invested in creating products that precisely meet the encryption needs of PCI. So the good news is that encryption is no longer scary. The bad news is that the laws of supply and demand have come into play, and encryption products have taken advantage of this capitalistic truth, becoming more expensive than they might otherwise be.
From a pure security standpoint, one credit card executive told me he believes there will be as much as an 80% reduction in breaches and fraud once data-at-rest encryption becomes widely deployed. If true, this will be a boon for both consumers and companies alike.
Myth 4 – "I don't take enough credit cards…
… to need to be compliant." This is a common and broad misunderstanding of the requirements. While PCI sorts credit card merchants and service providers into different categories or levels based on the number of transactions they process, there is no difference in compliance requirements. The fundamental confusion is between compliance and validation. PCI requires that any entity that stores, processes or transmits any credit card data to be in compliance with the PCI DSS. The amount of validation is the real differentiator.
Additionally, PCI assumes that each covered entity is always fully in compliance with PCI. Companies often take that to mean they must be compliant by such and such a date. That is wrong. Companies are assumed to be compliant right now, and there may be a date that they have to be validated as compliant. The fundamental difference between Level 1 and Level 4 PCI requirements is only regarding the amount of third-party validation that must be done to meet the certification process.
Myth 5 - Product X will make me compliant
Human nature is such that we look for the easy way out of problems. Product manufacturers understand this. Every product manufacturer worth its salt has a white paper on how they will make an organization compliant. Some of these white papers have good, comprehensive information that can help IT staff make responsible decisions related to mitigating gaps in their PCI status. Other vendors overstate their claims and promise much more than they can deliver.
PCI has 12 sections with many details within each requirement that must be met. Unfortunately, no single product -- or even a single vendor -- can supply all of the "stuff" needed to become fully compliant.
Instead of relying on products, a wiser tact for enterprises is one that emphasizes a holistic security strategy, focusing much more on the big picture related to the intent of the requirements. Focusing on point product will merely set the stage for a management nightmare in the future.
About the author:
John Kindervag is a 20-year veteran of the high-technology world. He has been involved with a variety of engineering projects ranging from basic LAN networking to sophisticated microwave and satellite technology. Kindervag is the resident expert on PCI compliance on our sister site, SearchSecurityChannel.com.
This was first published in August 2007