In ancient times, before social media’s pervasiveness, when chat rooms and forums ruled the Internet, the five largest credit card companies (Mastercard, Visa, American Express, Discovery, and JCB) handled their security programs independently – until the fateful year of 2005: the year of Chuck Norris jokes.
More importantly, 2005 was the year the “Big Five” came together to consolidate their policies and form the Payment Card Industry Security Standards Council or, the PCI SSC. The PCI SSC set the standards for companies (read: anyone handling credit card data) to secure credit card data. Those standards are better known as the Payment Card Industry Data Security Standards, or PCI DSS for short.
PCI DSS is a creation of logic, order, and many, many requirements nested under twelve main requirement branches. Naturally, the image of a super computer or advanced robot came to mind as an analogy. It’s a tool of defense against the kaijus of fraud, security breaches, and theft. In other words, the Council made a Jaeger.
Non-sequitur: Pacific Rim is, in the words of the Honest Trailer people, “The most awesome dumb movie ever made or the dumbest awesome movie ever made.” You should definitely watch it if you haven’t already.
So what allows an organization to be PCI DSS compliant?
From what I’ve read, PCI DSS is a construct with many tools designed to combat a wide variety of specific threats. The documentation associated with it, or the “manuals”, are extensive; however, there are three main guidelines that outline what merchants are responsible for doing:
1) Customer credit card data are collected and transmitted securely.
2) Storing data securely with tools such as encryption, security testing, and monitoring.
3) Annual validation that the proper controls are in place and functional, enforced by audits, and requested by
customers and/or partners.
As mentioned before, PCI DSS has twelve main requirements for its components. There are many sub-requirements, but they fall under the three main guidelines:
1) Firewall configuration to protect data.
2) Customized passwords for the interface (no vendor defaults).
3) Protections for stored cardholder data.
4) A method of encryption when transferring that data across systems or over public networks.
5) Regularly updated malware and anti-virus software.
6) Maintained and secure systems, tools and applications.
7) Restricted access to cardholder data.
8) Monitoring of access to the system and proper authentication.
9) Limit physical access to cardholder data.
10) Tracking and monitoring of all access to networks and data.
11) Regular testing of systems, controls and processes in place.
12) Maintaining a policy and ensuring all parties interacting with sensitive data know the rules.
There are also multiple levels for different types of organizations that determine what security requirements are needed for compliance, much like how a threat level would be met by different responses in a kaiju vs. giant robots scenario. The level is determined by the size of the organization and risks posed, as well as types of tools available to that organization.
While much of this can appear overwhelming, just remember that PCI DSS is designed to be a standardized construct with a wide set of tools at its disposal to combat the various threats lurking below the waters. The key is bringing the right tool to the fight.
As this is such a complex topic, I’ve only barely scratched the surface of information available on PCI DSS. Keep an eye out for a follow-up to this blog that will contain helpful tips, tricks, and information on how to do PCI DSS self-audits.
Image Credits: Legendary Pictures and Warner Bros. Studio