What Is PCI DSS?
PCI DSS Meaning
PCI DSS is a set of security standards established in 2004 by major credit card firms because, unsurprisingly, applications that process payments are highly attractive targets for hackers and malicious actors.
The mission of PCI DSS is to secure credit and debit card transactions not only to curb losses for banks and the payment card industry, but to increase consumer trust and safety. This is achieved through a set of security controls that protect confidentiality, integrity, and accuracy of the card data. This compliance standard applies to every organization that stores, processes, and transmits credit card data. Unlike NIST, which is a framework you are strongly encouraged but not obligated to follow, you absolutely must comply with PCI DSS.
PCI DSS Requirements
PCI DSS consists of 12 requirements grouped into six control objectives, ensuring organizations that process, store, or transmit credit card data maintain a secure environment. Compliance helps protect cardholder information and strengthen overall security measures.
Goal #1: Building a maintain a secure network
Rule #1: Install and maintain a firewall
Rule #2: Do not use vendor default passwords or configurations
Goal #2: Protect cardholder data
Rule #3: Protect stored cardholder data
Rule #4: Encrypt transmitted cardholder data
Goal #3: Maintain a vulnerability management program
Rule #5: Protect from malware
Rule #6: Develop and maintain secure systems
Goal #4: Manage access control
Rule #7: Restrict access to cardholder data
Rule #8: Uniquely identify everyone who has access to cardholder data
Rule #9: Restrict physical access to cardholder data
Goal #5: Monitor and test networks
Rule #10: Track and monitor all access to cardholder data
Rule #11: Test system security
Goal #6: Maintain an information security policy
- Rule #12: Create and enforce an information security policy within the organization
There are also four compliance levels, depending on the annual number of credit/debit card transactions processed. The classification determines what the organization needs to do to remain compliant:
Level 1: Over 6 million transactions/year - Requirement: Annual internal audit conducted by an authorized PCI auditor. Additionally, they must complete PCI scan by an Approved Scanning Vendor (ASV) once a quarter.
Level 2: 1-6 million transactions/year - Requirement: Complete an annual assessment using a Self-Assessment Questionnaire (SAQ). A quarterly PCI scan may be required.
Level 3: 20,000-1 million transactions/year - Requirement: Annual self-assessment and potentially a quarterly PCI scan.
- Level 4: Less than 20,000 transactions/year - Requirement: Annual self-assessment and potentially a quarterly PCI scan.
Why PCI DSS Compliance Is Important
Everyone in the organization plays a part in maintaining compliance. It starts at the top with the CISOs and then trickles down to SecOps and DevOps teams. In an ideal DevSecOps world, there is no hierarchy in security responsibility between both teams—they work in concert with each other. SecOps must help DevOps teams understand what they need to do to, and developers must execute this at the application level.
Following the 12 PCI DSS requirements, here’s a few examples of how continuous compliance is a team effort:
Rule #6: Developers must build systems with security in mind
Rule #8: Identity and access management must assign every user a unique user id-requirement eight
Rule #9: The physical security department must ensure that access to the building and server rooms is controlled
Rule #10: Security operations must ensure that logs are created to record and track access to cardholder data
Rule #11: Operations and development teams must work together to test servers and software
Rule #12: Management must develop policies and associated documents to detail the level of information security and compliance that must be achieved in their business
All this to say—everyone plays a role in staying compliant. Not only for the greater good of the organization, but so you can build and deploy efficiently and with confidence that you’re not going to get 10,000 SOS Slack alerts after your app launches.
As we said, your responsibility mainly lies at the application level. This includes using safe source code, ensuring proper configurations for your CI/CD pipeline, and more. You may be thinking: Okay, but how am I supposed to know how to do that? The good news is, you don’t have to be a security or compliance whiz, just like you don’t have to be a neurosurgeon to put a Band-Aid on a cut. It’s all about knowing and applying the proper resources (like a Band-Aid instead of taping a napkin over the wound).
To avoid misconfigurations, you can check out the documentation site for your cloud service provider (CSP). However, reading all this information may be too time-consuming. If that’s the case for you, then we suggest (rather highly recommend) using a security solution with automation.
PCI DSS Related Breaches
The first breach that may come to mind is the Capital One hack that exposed 106 million credit card applications and led to an $80 million fine from US regulators. Let’s take a look at some other breaches and how they could’ve been avoided by referencing the PCI DSS rules and goals.
Hobby Lobby
In early 2021, Hobby Lobby was hacked. An independent researcher that uses the handle Boogeyman identified the breach. He discovered a publicly accessible database on Amazon Web Services (AWS) that contained sensitive information from over 300,000 Hobby Lobby customers. The database was 138GB in size and had customer names, addresses, phone numbers, and partial card details. Oddly in the same database was the source code for the company's app, which is another issue altogether.
The breach was the result of a misconfigured cloud database that was publicly accessible. This is a clear violation of PCI DSS rules #3, #7, and #9, because the payment card data was being stored on an open server. Hobby Lobby also failed to comply with rule #10, which states that access to cardholder data and relevant network resources must be tracked and monitored. This clearly wasn’t happening, otherwise the misconfiguration would have been remediated and the entire ordeal ultimately avoided.
Macy’s
The major retailer suffered a breach in October 2019, which exposed the payment card numbers, security codes, and expiration dates of customers who used the online check out system with the My Account wallet page. While Macy’s did not reveal the number of customers impacted, the retailer clocked 55.7 million monthly online visits through April of that year. And to be frank, stealing the information of just one customer is enough of a concern.
The breach occurred due to a targeted Magecart attack that injected malware into the checkout and wallet pages. Macy’s was evidently in breach of a slew of PCI DSS rules, and what’s more concerning is the fact that Magecart is well known. In fact, Macy’s was just one of many victims that year, including FILA, Ticketmaster, British Airways, and others. Previous attacks on other major retailers should’ve motivated Macy’s to run security audits and remediate any vulnerabilities as required by PCI DSS.