I have just read a couple of articles as well as attended a couple of meetings where the topic du jour was the PCI standards. They were a bash fest of the highest order. Frustrated, I asked the participants at my last meeting, “If not the PCI standards, then what standard do you want to follow to ensure the security of cardholder data?” Roaring silence.
This is the frustration that I and others have with people who complain about the PCI standards or any standards. People complain and complain, yet they offer no solutions to address their complaints. One thing I have always stressed with and required of people who work with me, if you are going to complain about something, you better have an idea for a solution. Constructive criticism is fine, but if you do not have any ideas on how to make things better, then all you are doing is whining. Children whine, adults have solutions.
But then you have the complainers who do offer a solution but that solution is to allow the marketplace to address the problem. Hello! How long was it going to take before merchants and service providers got a clue about securing cardholder data? If it was such a priority, why did it take the card brands to come out with the standards? For merchants and service providers, cardholder data security was not a priority, it was some other merchants’ or service providers’ problem.
The other problem with the marketplace approach is that each organization learns from its own incidents and possibly from incidents suffered by their business partners, not from the incidents experienced by all. Under the marketplace approach, security protection only improves as each individual institution suffers a particular incident. As a result, organizations reinvent the wheel with the majority of incidents.
Standards allow organizations to learn from the collective experience of all organizations, not just their own organization. For example, if your organization does not have wireless networking but decides to implement wireless, a standard provides a guideline as to how to implement wireless securely. Without a standard, you are on your own to do the best you can. On your own you will likely get some things right, but you will also get some things wrong. It is those mistakes due to lack of experience that come back to bite organizations. With a standard to follow, the chance of getting bitten after the fact is often greatly minimized.
However, standards are not a guarantee. Going back to wireless, just look at how things went wrong with WEP. WEP is a standard and was well documented on how to implement it; supposedly securely. WEP was also known to have the potential for security problems, but those problems were not widely publicized until organization began to have security incidents. So a stop gap standard was provided called WPA which turned out to have its own security issues. Ultimately, WPA was replaced by WPA2 which is the secure, permanent solution.
This is why early adopters of technology can end up getting burned. When an organization decides to hop onboard the latest and greatest technology, there is a high risk that the security learning curve is not very far advanced. As a result, the organization will be at a higher risk of suffering a security incident than an organization using a more tried and true approach. As a new technology matures, typically its security posture matures and with a more mature security posture, the lower the likelihood that a security incident will occur. However, the time it takes for that security maturity to occur can take quite a while and it is where things take quite a while where organizations are at the highest risk.
Unfortunately, in some instances, a new technology gets quickly usurped by an even newer technology and the original new technology never matures. The bad news is that the early adopters get stuck with a solution that will never have its security shortcomings addressed, leaving the early adopters to either convert to the newer technology or find another alternative. Many a career has been ended over such technology leap frogging events.
The PCI standards were not developed in a vacuum. They are a consolidation of a lot of other security standards and guidance gained through root cause analysis of security incidents gathered over the years with the express purpose of protecting cardholder data. If you follow another security standard such as ISO 27K or FISMA, a lot of what is in those standards is also in the PCI standards. But there are also a lot of requirements in the PCI standards that are not in other standards as well.
The bottom line is if you do not like the PCI standards, then get involved in the process to make things better and stop whining.
