Compliance
Prove PCI DSS Compliance with Automation
Meet PCI DSS compliance needs without interrupting your workflow.
Save to Folio
Related articles in the Compliance for DevOps Teams series:
If your application processes, stores, or has anything else to do with payment cards, add maintaining the Payment Card Industry Data Security Standard (PCI DSS) compliance to your list. As we discussed in previous articles, continuous compliance is critical to avoiding data breaches. The benefits of meeting compliance aren’t just for the organisation—developers like yourself can gain back valuable time via automated guardrails.
This article will take a look at the key factors of PCI DSS, examples of related breaches, and what steps to take to satisfy the requirements so you can reap the benefits.
What is PCI DSS?
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. In 2019, payment card fraud losses totalled $28.65 billion worldwide, with the US claiming more than a third of the total amount. And as more people turned to online shopping and apps during the pandemic, credit/debit card fraud only continued to increase.
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 organisation 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.
There are 12 rules categorised under six broader goals:
There are also four compliance levels, depending on the annual number of credit/debit card transactions processed. The classification determines what the organisation needs to do in order to remain compliant:
- Level 1: Over 6 million transactions/year
- Requirement: Annual internal audit conducted by an authorised 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.
PCI DSS in action
The first breach that may come to mind is the Capital One hack that exposed 106 million credit card applications and led to a $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.
Why this matters to you
Everyone in the organisation 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 organisation, 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 a security or compliance whizz, 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.
Automate continuous compliance with Trend Micro Cloud One™ – Conformity
Conformity provides cloud best practices to empower cloud builders to innovate in the cloud with confidence. Customers leveraging this service can build secure and compliant cloud architecture and avoid misconfigurations, such as critical identity access management (IAM) for a secure and compliant cloud environment.
With Conformity’s real-time cloud service configurations cheques are run against your infrastructure to get a complete view of their security and compliance baseline and provides actionable intelligence to remediate misconfigurations to begin improving your posture.
Don’t just take our word for it. Try it yourself with a free 30-day trial.
