Demystifying PCI DSS Compliance
1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading...

Demystifying PCI DSS Compliance

As far as compliance goes, PCI DSS isn’t as onerous as it seems

Compliance is, without a doubt, the biggest concern for most organizations when they’re handling their certificate and key management duties. Whether it’s PCI DSS compliance, GDPR, HIPAA or any other regulatory framework, non-compliance is anathema to most companies, it can result in lost trust and massive financial penalties.

And frankly, if I had to guess I’d say that’s why compliance ranks so highly amongst enterprise concerns. Other ramifications of poor security or certificate/key management don’t have as obvious an effect. A data breach or a compromised key can cause a ton of damage, but that damage is harder to quantify in real time. Compliance penalties are known quantities, “if we don’t do X, we get fined Y.”

That’s easy to understand, and it’s easy to explain to the C-suite and upper management. If I come into your office and try to explain what could happen if a certificate expires it requires a much longer explanation – and more attention from the person you’re explaining it to – than simply stating we’ll get fined $10,000 for not doing something.

Anyway, today we’re going to talk about Payment Card Industry Data Security Standards (PCI DSS) and try to demystify it a little bit. As far as compliance goes, PCI DSS compliance really isn’t all that onerous. In fact, it’s actually pretty straightforward. So let’s talk about PCI DSS, how you can make compliance with PCI DSS easy and what happens if you decide it’s too much trouble.

Let’s hash it out.

PCI DSS: Protecting Payment Card Information

When we talk about sensitive data, payment card information is among the most valuable. That’s for pretty obvious reasons. So, it makes a lot of sense that the payment card industry would want to put certain requirements in place to safeguard it. We’ve seen what can happen when payment card info gets compromised thanks to breaches like Equifax’s.

The Payment Card Industry’s Security Standards Council is comprised of all the biggest creditors in the world:

  • Visa
  • American Express
  • Mastercard
  • Discover
  • JCB International

Basically all the major credit card companies. It’s the PCI SSC that determines the PCI DSS compliance requirements (today we dine on acronym soup). And that’s what makes these rules binding, if you want to accept payment cards from these companies you’ll need to follow their rules. They’ve all incorporated PCI DSS into the technical requirements for each of their respective compliance programs and expect any company that accepts payment through their cards to follow them.

We’ll get into the penalties for non-compliance with PCI DSS later, but suffice it to say in addition to fines you’ll likely have your relationship with these creditors downgraded or possibly even fully severed.

Now, it’s worth pointing out that while the council sets the rules, it doesn’t enforce them. That is incumbent upon the individual payment brands. So, non-compliance isn’t necessarily met with a single monolithic fine or penalty – each of these companies will enforce penalties using their own proprietary guidelines. So you may actually end up with four or five fines, depending on how badly you run afoul of the rules.

This is arguably the biggest misconception about PCI DSS.

PCI DSS compliance requirements are really just a bunch of security best practices

Here’s the thing, most of the 12 PCI DSS requirements are just common sense steps you should already be taking. It’s not like PCI DSS is asking you to reinvent the wheel or anything. There are 12 different requirements that fall into six different categories:

PCI DSS Compliance Requirements

When you actually look at the requirements, you’ll see nothing is all that onerous. Again, most of this is stuff you’re ideally already doing. Firewalls, antivirus programs, access management, encryption – this is all low-hanging fruit. You just need to document it. And even the things that sound difficult can be addressed fairly quickly.

This is as straightforward as regulations get.

And part of that is borne out of the unique position the PCI SSC operates in. Not unlike the CAB Forum, where the browsers basically rule by edict and you have to follow what they say to continue operating on their platforms, the PCI SSC can create and enforce these rules because they occupy a position of strength in their industry. If you want to accept their payment cards, you have to play by their rules.

Compare that to other regulations like GDPR, which have to operate within the context of state governments, and it’s a lot easier to be clear and concise. The EU has to write GDPR in a way that it can be assimilated into the various national laws of its member states. That can lead to some ambiguity and confusion as companies around the world attempt to interpret it.

Both regulations actually contain a lot of the same things, PCI DSS is just a lot more clear about it.

Who needs to follow PCI DSS?

Anyone that accepts payment cards from the aforementioned brands needs to comply with PCI DSS. That’s true with pretty much any payment platform you use, even PayPal has terms of service that must be followed.

PCI DSS is divided into four different compliance levels. Rather unintuitively, they don’t ascend – Level 1 is strictest and level 4 is the most lax.

Still, the requirements are largely the same across all four levels, with the biggest difference being that Level 1 organizations require an on-site audit in addition to their other responsibilities.

PCI DSS Levels

Each level must complete a yearly self-assessment and submit quarterly scanning reports, but level ones also need to have that on-site data security assessment performed once per year, too.

Now let’s go through each of the various PCI DSS compliance requirements.

PCI DSS Compliance Requirements

As we just touched on, you can group these requirements into six different categories. We’ll go through each one individually just for clarity’s sake, but you may sometimes see things categorized this way by other organizations. They’re not wrong, they’re simply painting with broader strokes.

1 – Install and Maintain a Firewall

PCI DSS Compliance Requirement 1

Firewalls monitor and control traffic as it comes in and out of your network. Installing one is considered best practice. Generally speaking, there are two different kinds of firewall, network-based and host-based. You can inspect on the application level or do deep packet inspection. You have plenty of options, however, what’s most appropriate is going to vary based on your organization’s size and needs. But make no mistake about it, shopping for a good firewall isn’t exactly a difficult task. Just perform your due diligence before picking a vendor. Not all firewalls are created equal.

Specifics:

  • Establish and implement firewall and router configuration standards
  • Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment
  • Block direct public access between the Internet and any system component in the cardholder data environment
  • Install personal firewall software (or something equivalent)on any portable connected devices that connect to the Internet from outside the network
  • Ensure that your security policies and operational procedures for managing firewalls are documented, in use, and known to the key stakeholders

2 – Change vendor defaults (IDs and passwords)

PCi DSS Compliance Requirement 2

When you purchase a new device (or even some software) it’s typically configured to use a vendor default for its password and login ID. This is to ensure the device is accessible, but these vendor defaults are published online and easy for criminals to find. Now consider 95% of people never change their default settings. That’s bad on an individual level, worse on an organizational level. We’ve demonstrated in the past how trivial hacking into a device is using vendor defaults and Shodan.io is. You can see why the PCI DSS compliance documentation is explicit about changing these defaults. Neglecting to do so isn’t that different from leaving a key under your doormat – you’re just inviting unwanted guests.

Specifics:

  • Always change vendor-supplied default credentials and remove or disable unnecessary default accounts before installing a system on the network
  • Develop configuration standards for all system components. Make sure these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards
  • Encrypt all non-console administrative access using strong cryptography (we’ll get to what this means later)
  • Maintain an inventory of system components that are relevant for PCI DSS
  • Make sure that your security policies and operational procedures for managing vendor defaults and other security parameters are documented, in use, and known to the key stakeholders
  • Shared hosting providers must protect each entity’s hosted environment and cardholder data

3 – Protect cardholder data at-rest

PCi DSS Compliance Requirement 3

The next two PCI DSS compliance requirements can both be categorized as encryption requirements. You should already be encrypting all personal information both at-rest and in-transit. Almost every compliance framework includes this requirement. Encrypting data at-rest protects it even in the event of a network intrusion. That data is useless to criminals and hackers if they can’t decrypt it. Obviously, this makes key security a major concern, but as long as the proper precautions are taken finding and fielding at-rest encryption solutions should be no problem.

Specifics:

  • Keep cardholder data storage to a minimum by designing and implementing data retention and disposal policies, procedures and processes
  • Don’t store sensitive authentication data after authorization (even if it’s encrypted)
  • Mask Primary Account Numbers when displayed (the first six and last four digits are the maximum number of digits that are allowed to be displayed), make sure only personnel with a legitimate business need can see more than the first six/last four digits of the PAN
  • Render PAN unreadable using hashing, encryption or truncation
  • Document and implement the procedures you use to protect and manage encryption keys

4 – Protect cardholder data in-transit

PCI DSS Compliance Requirement 4

This PCI DSS compliance requirement could be re-written simply as use SSL/TLS and HTTPS. Not to toot our own horn, but SSL is kind of our thing. As of July 2018 it’s mandatory for all websites, so you should already be meeting this requirement. But its importance can’t be understated. Internet connections are not 1:1, they get routed through dozens of different points on their way to their destination. Remember how we just discussed that for every 20 people, 19 didn’t change the factory defaults on their routers and webcams? Well, that comes back to bite us here, because if any one of those points you connection gets routed through is compromised – again, not difficult to pull off – any information that passes through it can be intercepted and stolen. Or even manipulated. SSL/TLS protects against this, rather than data traversing its path in plaintext, it gets encrypted and becomes useless to attackers – even if they’ve compromised one of the devices it routes through.

Specifics:

  • Use strong cryptography and security protocols
  • Don’t send cardholder information via unsecure channels like text messages or unencrypted messenger apps
  • Make sure that security policies and operational procedures for encrypting data in-transit are documented, in use, and known to all key stakeholders

5 – Use antivirus software and update it regularly

PCI DSS Compliance Requirement 5

This is kind of a two-part requirement, because simply having an antivirus program isn’t enough. Each and every day more and more malware is discovered and documented. These antivirus programs receive regular updates so they can sniff out even the most up-to-date malware. So, not updating your antivirus program regularly literally makes it less effective by the day. Remember, cybercrime is a game of cat and mouse. While you occasionally see criminals dust off a decade’s old exploit, they generally try to stay ahead of the security community by continually evolving. Put it this way, Comodo uses over 30,000 different tests from known malware samples when it runs a scan. You need every single one of those tests, too. And you need to keep them current. Failing to update can lead to disaster – just ask Equifax.

Specifics:

  • Deploy your antivirus software on any system that can be affected by malware
  • Make sure to keep your antivirus programs up-to-date, run regular scans and document them in audit logs
  • Make sure your antivirus programs are always running and can’t be disabled by non-privileged users
  • Make sure that security policies and operational procedures for administering your antivirus program are documented, in use, and known to all key stakeholders

6 – Develop and maintain secure systems and applications

PCi DSS Compliance Requirement 6

The word that confuses people in this requirement is “develop.” Most companies aren’t developing their own security systems, they’re leveraging products from trusted security vendors. Really all this requirement is asking you to do is maintain a good patching cadence and put in place a diagnostic system that can find vulnerabilities and rank them in terms of severity. Again, you can find a solution for this that involves zero development. And, not to belabor the point, this is just following best practices. Much like with updating your antivirus, the programs you use are finding and disclosing vulnerabilities all the time. When this happens they issue a patch to protect against it. Not installing these patches regularly leaves your systems vulnerable. So, just make sure you’ve got a system for identifying vulnerabilities and patching or remediating them.

Now, quickly, if you are in developing a system, you need to do it with a security focus. That means designing it to comply with the PCI DSS compliance requirements and following industry best practices. But again, this requirement really isn’t as complicated as it may appear at first blush.

Specifics:

  • Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking
  • Make sure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches
  • If you are developing programs or systems, make sure to abide PCI DSS standards and industry best practices
  • Follow change control processes and procedures for all changes to system components
  • Address common coding vulnerabilities in formal software-development processes
  • For public-facing web applications, address new threats and vulnerabilities on an ongoing basis
  • Make sure that security policies and operational procedures for maintaining secure systems and applications are documented, in use, and known to all key stakeholders

7 – Restrict access to data on a need-to-know basis

PCi DSS Compliance Requirement 7

This PCI DSS compliance requirement comes down to assigning privileges to users on your network and documenting those decisions. But, once again, this is just best practice. Your network and its servers store all kinds of information. Allowing employees complete access to everything just invites trouble. Employees should only have permission to access data that’s germane to their job functions.  For instance, within our own organization I have access to the marketing and production servers, but if I try to get into our customer experience server my computer emits a jolt of electricity that practically knocks me out of my chair (that’s actually an improvement, at first we misconfigured the zapper and had a Green Mile moment with an intern). These types of access controls make sense and help you to silo off information, which limits damage in the event an employee goes rogue.

Specifics:

  • Limit access to system components and cardholder data to only those who need it
  • Establish an access control system(s) for systems components that restricts access based on a user’s need to know
  • Make sure that security policies and operational procedures for access control are documented, in use, and known to all key stakeholders

8 – Assign everyone on your network a unique ID and authenticate them

PCi DSS Compliance Requirement 8

This is just common sense. In fact, it’s so closely associated with the previous item that you could probably just combine them. It’s tough to enforce access control if the people using your network don’t have unique IDs and can’t be authenticated. This extends beyond just assigning IDs though, this is about creating a policy that governs the assignment and deletion of employee IDs, authentication methods, how you handle inactive accounts, what gets done when an employee is terminated, how long can an account idle before it’s locked out, how to recover a password, etc. You’re also going to want to use multi-factor authentication to add an extra layer of security. Again, this PCI DSS compliance requirement is just best practice.

Specifics:

  • Define and implement policies and procedures to ensure proper user identification management for employees and administrators
  • In addition to assigning a unique ID, ensure proper user-authentication management for employees and administrators
  • Secure all individual non-console administrative access and all remote access with multi-factor authentication
  • Document and communicate authentication policies and procedures to all users
  • Do not use group, shared, or generic IDs, passwords, or other authentication methods
  • All access to any database containing cardholder data should be restricted to administrators on a need-to-know basis
  • Make sure that security policies and operational procedures for identification and authentication are documented, in use, and known to all key stakeholders

9 – Restrict physical access to data

PCi DSS Compliance Requirement 9

This PCI DSS compliance requirement is really less of a cybersecurity concern than it is a physical security concern with a cybersecurity impact. It’s also another dose of common sense. The hardware that’s storing your data is expensive and likely requires a lot of effort to maintain. You wouldn’t want your employees going near it even independent of your security concerns. I’m not saying you need to air gap all of your computers, but you do need to ensure you have physical safeguards preventing unauthorized access to hardware. This extends to other critical items, too. Like encryption keys. Storing them on a physical hardware token is a great way to enhance security. Just make sure only authorized personnel can physically access them.

One more thing, the PCI DSS compliance documentation refers to “media,” here’s a working definition of that term:

Paper and electronic media (including computers, electronic media, networking and communications hardware, telecommunication lines, paper receipts, paper reports, and faxes) that contain cardholder data

Specifics:

  • Use “appropriate facility entry controls” (locks, security systems) to monitor physical access to systems storing cardholder data
  • Develop procedures to help quickly distinguish between employees and visitors
  • Restrict employee access to sensitive areas
  • Create and implement procedures for identifying and authorizing visitors
  • Physically secure all devices and media
  • Maintain strict controls over internal and external distribution of any kind of media
  • Maintain strict controls over the storing and accessibility of media
  • Destroy media when it is no longer required for business
  • Protect devices that capture payment card data via direct physical interaction with the card from “tampering and substitution”
  • Make sure that security policies and operational procedures for physical security safeguards are documented, in use, and known to all key stakeholders

10 – Track and monitor all access to network data

PCi DSS Compliance Requirement 10

Monitoring traffic on your network is something most organizations are already doing. It’s important to see what’s leaving your network and how the people on it are behaving. Lately we’ve seen machine learning start dominating this conversation. Whereas it would be prohibitively difficult for a human to monitor everything in real time (you can see all the requirements below), a machine learning-backed monitoring solution (I wouldn’t go so far as to label it AI yet, though some do) can maintain complete visibility while also discerning usage patterns that can indicate when something is amiss. For instance, it knows when employees are accessing the network, what they’re typically accessing and where they’re logging in from. If that employee suddenly logs in at an odd time from a far-away location and tries access something they normally don’t, it’s easy to identify it as an anomaly and then investigate it. Monitoring solutions are readily available, all you need to do is pick the one that best fits your needs.

Specifics:

  • Implement audit trails that track network access from each individual, they should be able to reconstruct what was accessed and what actions were taken, audits should include:
    • User ID
    • Type of Event
    • Date
    • Time
    • Success or failure
    • Origination of event
    • Identity/Name of data, system or component affected
  • Synchronize time across all parts of your network
  • Secure your audit logs so that they cannot be altered (potential application for hashing)
  • Review logs regularly to look for major system events and anomalies
  • Keep all audit logs for at least one year and keep the last three months of logs readily available
  • Make sure that security policies and operational procedures for network monitoring are documented, in use, and known to all key stakeholders

11 – Scan systems and review processes regularly

PCi DSS Compliance Requirement 11

This is the so-called scanning and reporting requirement, which is not nearly as complicated as it may seem at first blush. All you need to do to satisfy this requirement is purchase a PCI DSS compliance scanning product. We use HackerGuardian from Comodo CA/Sectigo. It leverages Comodo’s antivirus patterns and works quickly – it’s also about $200 cheaper than the next closest scanner. Running scans is simple, after you’ve configured it to run on your network you just use the client to start the scan. It provides you with actionable intel on remediating anything it kicks up. Once you take care of that, the scan runs again and produces a ready-to-submit report. Send it in to your acquiring bank once per quarter and you’re good to go. Again, this isn’t as difficult as it sounds once you have the right PCI scanner.

Specifics:

  • Implement processes to test for the presence of wireless access points (802.11), and detect and identify all authorized and unauthorized wireless access points on a quarterly basis
  • Run internal and external network vulnerability scans at least quarterly andafter any significant change in the network
  • Implement and document a method for penetration testing
  • Use intrusion-detection and/or intrusion-prevention techniques to detect and/or prevent unauthorized access to the network
  • Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert your organization to unauthorized modifications
  • Make sure that security policies and operational procedures for quarterly scanning are documented, in use, and known to all key stakeholders

12 – Maintain a policy that addresses security

PCi DSS Compliance Requirement 12

Ok, take the last 11 steps and document them. Everything. From how you administer your network IDs to the patching process to the scanning – document it all. If you need help creating a security policy, we’ve actually covered it at length before. It’s not difficult, you just need to be comprehensive. Once you’ve written everything down, save a copy of it and then revisit it annually to update anything that’s changed. Should you ever be audited you’ll need to show that your security policy is a living, breathing document that guides your organization’s security.

Specifics:

  • Establish, publish, maintain, and disseminate a security policy
  • Create and document a risk assessment process
  • Develop usage policies for critical infrastructure and systems
  • Make sure that security policies and operational procedures are clearly defined for all affected personnel
  • Implement formal security awareness and training programs that are mandatory for all employees
  • Screen potential hires to minimize the risk of internal attacks or sabotage
  • Maintain data processing agreements and other requisite contracts with any partner you share cardholder data with
  • Create an incident response plan and educate your organizations on the steps that must be taken

PCI DSS – What is strong cryptography?

Encryption key

Ah yes, “strong cryptography,” what does that mean? The actual PCI DSS compliance documents only allude to “strong cryptography” because what constitutes “strong” is going to change at a quicker pace than the PCI DSS compliance requirements will be updated. Unfortunately, that means organizations are forced to either figure out what that means on their own or try to find a definition elsewhere.

PCI DSS’ definition of strong cryptography is basically using encryption based on industry-tested and accepted algorithms, at key lengths with requisite computational hardness and then managing it all with certificate and key management best practices.

Specifically, that means:

  • AES – 128-bit key length or higher
  • TDES/TDEA – Triple-length keys
  • RSA – 2048-bit key length or higher
  • ECC – 224-bit key length or higher
  • DSA/DH – 2048-bit/224-bit key length or higher

As we’ve stated in the past, we recommend using elliptic curve-based cryptosystems for SSL/TLS.

PCI DSS Compliance Requirements for SSL/TLS

We mentioned earlier that you’re required to secure cardholder data as it’s in transit. That means using SSL/TLS. And while it was mentioned in passing earlier we wanted to be explicit about this next point.

With one exception (which will be covered in the next section), PCI DSS suggests that you use TLS 1.2 or TLS 1.3 – you absolutely cannot use SSL or TLS 1.0. It’s also strongly advised you deprecate support for TLS 1.1, too.

We tell our customers to stick to TLS 1.2 and TLS 1.3. It will save you some work when the PCI SSC inevitably mandates its deprecation.

Additional PCI DSS Requirement for SSL/TLS on older POS POI terminal connections

POS POI PCI DSS Requirement

Legacy devices and systems pose a special problem because many are no longer being actively supported, which means there’s no way to support new protocol versions. This is especially true of point of sale (POS) or point of interaction (POI) terminals. Stuff like cash registers. If you’re an organization using legacy technology that simply can’t be updated to support newer protocols and algorithms, there are some additional safeguards you’ll need to put in place.

  • Organizations using POS POI terminals that only support SSL and older TLS versions must have formal Risk Mitigation and Risk Migration plans.
  • Legacy devices located in “card-present” environments must be verified as not being susceptible to known exploits affecting SSL and early TLS versions.

You verify this by providing the requisite documentation, either from the vendor or from your own remediation efforts.

Bear in mind, any new terminals need to be capable of supporting TLS 1.2 and TLS 1.3. These legacy devices are being grandfathered in, moving forward they should be phased out.

What are the PCI DSS penalties for non-compliance?

Let’s start with how the penalties are handed down, then we’ll get to what can happen. First of all, PCI DSS compliance penalties are like Fight Club, they don’t talk about them. PCI DSS penalties aren’t openly discussed and rarely even made public.

That doesn’t mean they aren’t catastrophic though.

For starters, the PCI SSC doesn’t administer the fines, the credit companies do. Individually. So, if you accept Visa, Mastercard and American Express when you run afoul of PCI DSS compliance, you aren’t looking at one fine. You’re potentially looking at three.

Next, they don’t fine you directly. They fine your acquiring bank. Then your acquiring bank passes the fine on to you. Oftentimes with additional fees and penalties.

Now let’s talk about what can happen.

There are going to be two impacts: an immediate one and a longer-term one.

Each payment brand can fine non-compliant organizations between $5,000-$100,000 per month for as long as the problem persists. Obviously, if you’re getting penalized by multiple payment brands those numbers can go as high as $25,000-$500,000. That’s an immediate impact. It’s coming right out of your bottom line.

Then there’s the longer-term impact. At best, you may be required to submit to an assessment or undergo additional audits. At worst, your acquiring bank will sever ties, you won’t be able to accept payment cards and you’ll spend your golden years living under an overpass, offering to squeegee windshields for cupholder change.

PCI DSS Compliance is just formalized common sense

Nothing asked of your organization from the payment card industry is really off-base. These are things every organization should already be doing.

If anything, PCI DSS compliance can be a boon to your organization because it basically forces you to follow security best practices. That’s a good thing. We write all the time about how expensive data breaches and security incidents are. They can cast small-and-medium businesses into existential peril and can even manage to crater the bottom lines of enterprise companies.

Anything you can do to fend off that threat is just good business.

PCI DSS compliance really isn’t all that complicated if you don’t overthink it. Just follow the steps the PCI SSC have laid out and document everything you do. That second part is almost as important as the first – this is one time you want to leave a paper trail.

As always, leave any comments or questions below…

Hashed Out by The SSL Store is the voice of record in the SSL/TLS industry.

Author

Patrick Nohe

Patrick started his career as a beat reporter and columnist for the Miami Herald before moving into the cybersecurity industry a few years ago. Patrick covers encryption, hashing, browser UI/UX and general cyber security in a way that’s relatable for everyone.