Security Essentials: What is PCI DSS?

Filed Under: Cryptography, Data loss, Featured, Privacy

Hardly a week goes by these days without news of one sort of data breach or another.

In fact, breaches seem so commonplace now that many people seem to have responded to last year's news - namely that over 800 million records were lost - with little more than a shoulder shrug.

Many of the associated news stories talk about how the breach might have been stopped if the company had only followed the guidelines outlined in the Payment Card Industry Data Security Standard (PCI DSS).

While many of us may be familiar with the abbreviation, how many have actually read the standard?

Until recently, I was one of those people.

I knew about the standard, understood why it existed, and even knew some of the specific elements, but I had never given it a full read.

So I decided to go through the document and attempt to summarize it for Naked Security readers.

→ On 2014-03-17, the PCI DSS is at Version 3.0, dated November 2013.

Introduction

At a high level, the PCI Data Security Standard consists of twelve requirements that aim to provide a "baseline of technical and operational requirements designed to protect cardholder data."

The requirements are as follows:

At first glance this list seems comprehensive but, as always, the devil is in the details, for example:

  • What kind of encryption should be used?
  • Is using anti-virus enough, or should HIPS and other proactive technologies be used?
  • What systems should be covered by my patching protocol?
  • Which networks do I need to control access to?

The next few sections will attempt to answer some of these questions.

Applicability

According to the document, the PCI DSS applies to "all entities involved in payment card processing - including merchants, processors, financial institutions [and] service providers, as well as all other entities that store, process, or transmit cardholder data and/or sensitive authentication data."

→ There are lots of three-letter acronyms in the PCI DSS, including PCI and DSS themselves. We introduce and define several of them below.

For this purpose, the standard defines cardholder data (CHD) and sensitive authentication data (SAD) as follows:

Cardholder Data

  • Primary Account Number (PAN)
  • Cardholder Name
  • Expiration Date
  • Service Code

Sensitive Authentication Data

  • Full track data (magnetic stripe data, or its equivalent on a chip)
  • CAV2/CVC2/CVV2/CID numbers
  • PINs/PIN blocks

→ In the list above, the abbreviations Cxx2 and CID are vendor-specific shorthand for Card Security Codes, or CSCs, the printed digits, on the front or back of your card, that you use over the phone or online, when you aren't able to present the physical card to the merchant.

The standard also makes it clear that the primary account number is the defining factor for cardholder data by bolding it, as I've done here.

If any of the other cardholder data factors are present in the cardholder data environment (CDE), all must be protected according to the standard.

Scope

As important as the applicability of the standard is the scope on which it acts.

The PCI DSS applies to all systems that are considered part of the CDE.

These systems cover an extensive list of components in the typical IT setup, including:

  • Systems that provide security services (e.g. authentication servers), facilitate segmentation (e.g. internal firewalls), or may impact the security of (e.g. name resolution or web redirection servers) the CDE.
  • Virtualization components such as virtual machines, virtual switches and routers, virtual appliances, virtual applications/desktops, and hypervisors.
  • Network components including but not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances.
  • Server types including but not limited to web, application, database, authentication, mail, proxy, Network Time Protocol (NTP), and Domain Name System (DNS) servers.
  • Applications including all purchased and custom applications, including internal and external (e.g. internet) applications.
  • Any other component or device located within or connected to the CDE.

Even with this lengthy list, it's important to note that the CDE is not strictly defined.

What this means is that companies must define it for themselves, and each is likely to do that differently.

The key to defining your own CDE is to remember that all systems and personnel that interact with, transact or store CHD are considered to be in scope.

So, a rule of thumb for whether part of your infrastructure should be included under PCI DSS or not is, "If in doubt, don't leave it out."

Interestingly, the PCI DSS mentions network segmentation and isolation hardware in its list of "in scope systems," and strongly recommends that you use this sort of technology.

But the standard does not require the segmentation or isolation of the CDE from other operational networks.

What about outsourcing?

The PCI DSS makes it clear that any reliance on third-party service providers is to be considered "in scope" of the standard.

These providers can validate their own compliance in one of two ways:

  1. They can undergo a PCI DSS assessment on their own and provide evidence to their customers to demonstrate their compliance, or
  2. They must have their services reviewed as part of each of their customers’ PCI DSS assessments.

Best practices

I think one of the strengths of the document is the suggestion (though I would have preferred them to have made it a requirement) that the implementation of the PCI DSS should be part of a "business as usual."

What this means is that implementation, monitoring, testing and reviewing of the controls you have in place should not be done "as and when," or as part of a special project.

Keeping up with PCI DSS should not be put off until security problems are already suspected, but included in the day-to-day operational activities of your business.

This ensures that the controls aren't outside the scope of normal operations, and are considered as important as any other business systems that are subject to routine monitoring, assessement and remediation.

In short, computer security should be a first class citizen in your IT ecosystem.

PA-DSS

There is an additional mention in the standard that focuses on another DSS: the Payment Application Data Security Standard, or PA-DSS for short. (PA-DSS has a hyphen, but PCI DSS does not.)

Specifically, the PCI DSS states - wordily but unambiguously - that the use "of PA-DSS compliant applications by itself does not make an entity PCI DSS compliant".

What this means is that if you are a merchant, you can't buy compliance with PCI DSS simply by buying compliant software, any more than you get a licence to drive simply by buying a roadworthy vehicle.

You have to pass the PCI DSS assessment as well, to ensure you are using the software to achieve the security it was intended to deliver.

What next?

In just the same way that buying PA-DSS compliant software isn't a shortcut to complying with the PCI DSS, so this article isn't a shortcut meant as an excuse for you to skip reading the standard itself.

If your business falls under the ambit of PCI DSS, or if your job involves managing systems that fall inside the scope of the standard, I urge you to go through it.

It's not a long read.

It provides a good starting point for protecting your customers' data.

And, if applied properly, it could help you stay out of the data breach headlines.

Image of faux credit cards courtesy of Shutterstock.

, , , , ,

You might like

11 Responses to Security Essentials: What is PCI DSS?

  1. Mike · 164 days ago

    I probably won't be the last QSA to jump on here and start nitpicking, but I feel like this one is important to note. You state "The PCI DSS applies to all systems that are considered part of the CDE.", but the DSS actually states "The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment." That statement "...or connected to..." has severe implications to many organizations. PCI Scope includes all system components that store, process, or transmit CHD, as well as any system connected thereto.
    Also, you may consider adding a direct link to the standard for those who are interested in giving it a read.
    https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf
    I sincerely thank you for calling attention to the DSS and encouraging people to read the standard. It's not silver bullet, it certainly isn't perfect, but it's a darn good place to start!

    • Paul Ducklin · 164 days ago

      Link (with version number and date) added to article.

      As for the "...or connected to..." rider of what's covered by the standard - John did list that in the section entitled "Scope".

    • John C. · 164 days ago

      And to make matters more complicated, one has to struggle with the question of defining "connected to". When one considers the Internet, it's not too much of a stretch to infer that this includes almost every computer on the planet. Clearly that is not the intent, but there is certainly room for debate about where the line is drawn.

      • Robert Burnett · 164 days ago

        One thing this article does not clearly delineate is the acceptable methods of separating an area of the network so that it can be excluded from the CDE. Obviously, physical firewall separation (with a rulebase that allows no traffic between the segments) should qualify, but what about the increasing trend of virtualization where something like a virtual device context (VDC) on a Cisco Nexus device is used. Is this sufficient separation, or is virtual separation not yet considered as trustworthy as a dedicated firewall appliance?

        • John Shier · 163 days ago

          You raise a valid point. The reasons I didn't get into many specifics are both practical and illustrative.

          I intended this to be a primer as opposed to a comprehensive post on the subject. Therefore it was more practical to leave out some specifics to keep the post length down to a manageable size.

          It was also intended to be illustrative of one criticism to the standard. Namely that the standard is open to interpretation. I wanted to see if anyone would comment on the inherent ambiguous nature of the standard. I'm happy to see that you picked up on this, as did others.

          I also intend to write some follow up posts discussing this so the omission is part of the narrative.

          To attempt a direct answer to your question, my opinion on this is that the segregation should be performed using trusted and proven technologies (e.g. physical firewalls) or architectures (e.g. air gaps) that provide the most restrictive set of access to and from the CDE. If one fully understands what makes up the CDE and the data flow (as described in requirement 1.1.3) it should be a fairly straightforward exercise to craft access rules allowing only required services.

          As for the technologies mentioned in your question, I'm unfortunately not familiar enough with them to comment either way..

  2. John,

    What a great article to start your education on the wonderful topic of PCI compliance. I completely agree with you on the fact that the term "security breach" is common in our vocabulary now when discussing large retailers and national news topics. Sadly though, PCI compliance is NOT a part of this society's vocabulary and I truly believe the more people educate themselves on compliance; especially those IT departments who are in charge of keeping their network secure with proper equipment, we can then begin moving forward with an educated society and in turn we can easier prevent large-scaled data breaches. The key is education on the topic, and the proper network security equipment to get the job done right.

  3. W. H. Hayes · 164 days ago

    PA-DSS compliant software should be thoroughly tested before fielding. A few years back I ran across one company's offering that left plain text temporary files containing credit card numbers. Very bad form, don't you think?

  4. Doug · 163 days ago

    Looking forward to some analysis/assessment of whether substantial PCI-DSS compliance could have prevented some of the recent breaches.

  5. Hal D · 157 days ago

    Great article. I periodically get folks that think the standard also requires encryption for data at rest.
    It may be a guideline, but not a requirement.
    You mention 'stored cardholder data must be protected', which is where I think folks are assuming this means encrypted. I believ the access control points 7,8,9 do the protection of stored cardholder data. In addition the other points about malware, network access, etc.
    thanks again for a good summarization.

    • Don T. · 114 days ago

      Your point about encryption is misleading and incorrect. PCI-DSS Requirement 3.4 states that the PAN *must* be unreadable in storage. Encryption is one of the approved methods while relying solely on requirements 7, 8 and 9 is not. Here is the basic text of 3.4, but there is lots of other documentation about this:

      3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:

      - One-way hashes based on strong cryptography, (hash must be of the entire PAN)

      - Truncation (hashing cannot be used to replace the truncated segment of PAN)

      - Index tokens and pads (pads must be securely stored)

      - Strong cryptography with associated key-management processes and procedures

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

John Shier is a Senior Security Expert at Sophos. John is a popular presenter at security events, and is well-known for the clarity of his advice, even on the most complex security topics. John doesn't just talk the talk: he also gives hands-on technical support and product education to Sophos partners and customers.