STE WILLIAMS

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.

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.

Follow @nakedsecurity

Image of faux credit cards courtesy of Shutterstock.

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/634zBiqevAI/