PCI DSS for Developers

Introduction

Developers dream of many things. They dream of clean code, good documentation and self-explanatory errors. (Soon, AI-assisted developers may even dream of electric sheep.) Developers don't dream of PCI compliance. That's because compliance can be confounding. It conjures images of complicated controls, endless spreadsheets and strict audits. Payment Card Industry Data Security Standard (PCI DSS) compliance involves over 300 controls, significant engineering lift (that would otherwise be devoted to product) and takes months to achieve. But while PCI compliance may never be dream-material, achieving it doesn't have to be nightmarish. It's possible to dramatically simplify the process, saving your organisation months and up to $100,000. This guide explains what PCI DSS is, why it is important, and how you can achieve it with minimal effort.

In short:

• PCI DSS is a global standard for organisations that touch cardholder data.
• PCI DSS exists to protect cardholder data from data breaches.
• Organisations that fail to achieve compliance or are breached are subject to costly fines.
• Methods to reduce your compliance burden include automation, reducing your CDE footprint and ensuring you never handle plaintext card data in your environment.
• The greatest reduction in burden is achieved by ensuring you never handle plaintext card data in your environment. Doing so reduces the number of controls you must follow from ~300 to 12.

What is PCI DSS?

The Payment Card Industry Data Security Standard (PCI DSS), published in 2005, is a global security standard which applies to any organisation that stores, processes, or transmits Cardholder Data (CHD). The standard was agreed upon between the major card brands to reduce the volume of fraud involving stolen cards. This primary piece of information to consider when protecting CHD and determining scope is the presence of the Primary Account Number (PAN). The PAN is the long (14+ digit) number on the card.

Organisations that fail to achieve compliance or are breached can be subject to fines, increased transaction fees and, in some extreme instances, termination of an acquiring contract. Fines can vary, however in a breach scenario, organisations should expect to:

• Pay between $3-$18 per card breached;
• Absorb the costs of the remediation effort to contain and eradicate the threat actor, and
• Lose access to the card networks, effectively shutting off the ability to process card payments until such time that the organisation can prove the threat is neutralised.

PCI DSS is a particularly rigorous security standard:a spend of $100k over 12 months is not uncommon. With that rigour comes a significant overhead required to manage and demonstrate the continuous security of card data. This is why organisations who handle CHD are wise to reduce contact with CHD, reducing the impact of a card data breach and the compliance burden from a human and financial perspective.

Why do we have to achieve PCI DSS?

PCI DSS is mandated by five major Card Brands (Visa, Mastercard, JCB, AmEx, Discover) and contractually enforced via acquiring banks.

If you are a merchant and have signed an acquiring contract with a bank since 2005, it is highly likely that you are contractually bound to be PCI DSS compliant.

It applies to service providers too. If you are a service provider, your merchants will likely ask for your Attestation of Compliance (AoC); its absence can often result in barriers to winning business.

Audit requirements, the rigour of audit and stakeholders differ based on the business model and volume of transactions, see table below:

Level	Service Provider	Merchant	External Audit Required	Attestation
1	>300k	>6m	Yes	Report on Compliance
2	<300k	1-6m	No	Self Assessment
3	-	20k-1m	No	Self Assessment
4	-	<20k	No	Self Assessment

Where do I start with PCI DSS?

Getting started can seem overwhelming as there is much content and nuance to decipher, but like any audit, the first task is determining the scope. The cardholder data environment comprises people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data. By mapping out your cardholder data flows, you can determine your scope.

PCI DSS requirements apply to all system components included in or connected to the cardholder data environment; in the simplified diagram below, all components are in scope for the ~300 PCI DSS Requirements, as they either directly store, process or transmit card data or connect to systems which store card data. More and more, as a full-stack developer, it's your job to secure the data, infrastructure and code.

What does this mean for the developer?

Developers may be responsible for the technical and management implementation of the following controls: network security (architecture, rules management, web app firewall, load balancing etc), system hardening and configuration, secure cryptographic implementation, encryption key management, algorithm selection and configuration, TLS configuration, anti-malware management, secure coding training, dependency assessment, app sec: web application scanning (DAST / SAST) and dependency analysis, training Owasp top 10, peer code review, software development change management, consistent implementation of defensive coding techniques, patching and vulnerability management, strict change management, segregation of cloud accounts, users and the implementation of least privilege, authentication security and MFA, physical security, logging, monitoring and alerting - 24x7 response, intrusion detection, vulnerability scanning and penetration testing, network segregation effectiveness, risk assessment, policy development, incident response, awareness training, threat landscape monitoring and phishing simulations.

Typically achieving and maintaining PCI requires an enormous uplift of engineering effort to apply the controls; this is often expensive and diverts engineering effort away from the core product. Achieving PCI compliance involves an opportunity cost - it takes precious resources (time and money) that would have otherwise been dedicated to product.

How can I reduce the burden?

There are three primary ways to reduce the burden of PCI DSS Compliance.

1) Configure and maintain a series of automations

Methods:

• Using IaS (Infrastructure as Code)
• Automated patching, vulnerability scanning and remediation
• Automated configuration analysis and change management
• Integrated governance management systems like Vanta or Secureframe

Effort Required:

• High
• 300+ controls will apply, however, where automation is leveraged to its fullest, the human capital required to manage compliance will be reduced.

2) Reduce cardholder data environment footprint

Method:

• Segment systems and people involved with card data processing from those that do not.

Effort Required:

• High
• 300+ controls may apply but applied to a smaller number of people, processes and systems.

3) Reduce scope and de-risk by never handling plaintext card data in your environment.

Methods:

• Embed iFrames from Level 1 Service Providers
• Leverage Network Encryption Proxies
• Completely outsource processing and application management to a compliant third-party

Effort Required:

• Low
• Reduced from ~300+ controls to ~12 basic security hygiene and policy-based controls. The technical controls can be managed through code centrally. (Authentication config, user account management and patching.)

Summary of Methods

Approach	Effort Required
Configure and maintain a series of automations	High
Reduce cardholder data environment footprint	High
Reduce scope and de-risk by never handling plaintext card data in your environment	Low

At Evervault, we provide complete solutions to help organisations achieve the highest reduction of effort, maintain compliance and de-risk their environments from cardholder data breaches.

Click here to read more about how Evervault can dramatically reduce the scope of your compliance burden by ensuring you never touch credit card data in plaintext.