Knowledgebase

A Data Security Standard for the Payment Card Industry

Unlike many things in life, the Payment Card Industry Data Security Standard, PCI DSS, does what its name suggests.
It's a data security standard for the payment card industry.

The standard is developed and maintained by the Payment Card Industry Security Standards Council, the PCI SSC, which was formed by the five main card brands. That's American Express, Discover, JCB, MasterCard, and Visa. It's one of about 15 PCI security standards, which are designed to protect all stages of a payment card transaction, which includes making cards, how cards are sent to people, how the payment terminals are secured, and how payment card data, such as account numbers and pins, are kept secure.
The Data Security Standard, PCI DSS, is designed to protect cardholder data. That's the data that's on a payment card, essentially the long number on the front of the card, which people in the payment industry call the primary account number, or PAN, the data on the chip, the data encoded on the magnetic stripe on the back of the card, and the security code printed on the card. PCI DSS is designed to apply to organizations that store, process, or transmit this cardholder data. PCI DSS was one of the first comprehensive security standards, and because of this, it is prescriptive with very detailed testing procedures to validate compliance. Let me give you an example.
One of the demands of PCI DSS is that all systems should be protected with antivirus software.
The standard doesn't say which antivirus software.
It takes three pages with six separate detailed requirements and eight individual tests that the assessor would have to carry out to confirm that a requirement was in place. As well as being prescriptive, the standard is also very comprehensive.
It runs to just over 130 pages and has just under 300 individual requirements that the organization has to comply with. These requirements are broken down in 12 main sections that deal with people, process, and technology that could affect the security of payment card data.
Running through these 12 sections very quickly:

1. the first is concerned with network security and how the organization protects itself from the internet,
2. the second with how systems are initially installed and configured and that they're configured securely,
3. the third and
4. fourth with the encryption of cardholder data at rest and in transit.
5. The fifth we saw earlier and is concerned with antivirus protection.
6. The sixth on the development and maintenance of secure systems and applications.
7. The seventh and
8. eighth are requirements dealing with user identification, authentication, and authorization.
9. The ninth is concerned with the physical security that's around the protection of cardholder data.
10. And the tenth is mostly focused on collecting and maintaining logs of what happens on all the systems that store, process, or transmit cardholder data. These logs could be used to detect attackers and also in forensic investigations after a data breach has happened.
11. The eleventh section is primarily focused on assurance activities, such as vulnerability scanning and penetration testing.
12. And finally, the twelfth contains requirements to ensure good governance of all payment card data security activities. If you're personally involved in applying these requirements in an organization, there are four Pluralsight courses that together look at every single one of the 300 or so requirements from a theoretical and a practical perspective. On its own, PCI DSS is a highly prescriptive and comprehensive data security standard. The next module looks at why organizations have to comply with it and how that compliance is validated.

What Does Compliance with PCI DSS Mean?

Why Organizations Comply with PCI DSS?
There are three reasons why an organization may decide it needs to comply with PCI DSS.

1. The first and most common is that the organization is part the payment ecosystem. It could be a merchant that accepts payment cards or a financial institution that processes them.
2. The second reason is that the organization provides services to merchants or to financial institutions involved in payment card processing.
3. And the final reason is that it believes it's subject to a regulation or a law that specifies the organization must comply with PCI DSS.
   

This briefing considers compliance with PCI DSS in the context of the payment system rather than laws and regulations. And within the payment system, the real reason any organization is asked to comply with PCI DSS is because it has signed a contract that requires it.

If the organizations are merging to a retailer which accept payment by cards, then their contract with an acquiring bank or a card brand, such as American Express, will require the merchant to be PCI DSS‑compliant.

If the organization is the financial institution that issues payment cards or acquires payment transactions, then its contract with the card brands, such as Visa or MasterCard, will require it to be PCI DSS‑compliant.

Finally, if the organization provides services to either merchants or financial institutions, then the contract between the organizations will require the service provider to comply with PCI DSS.
And that is because in the course of providing the service, it either stores, processes, or transmits the cardholder data on behalf of the organization it is providing the service to or that the services provided can affect the security of cardholder data.
Additionally, some of the card brands have rules which mandate that organizations that supply services to financial institutions are also required to establish a relationship directly with the card brand who will separately demand evidence of PCI DSS compliance. What's really important is that any organization contemplating PCI DSS compliance knows the answer to these five questions.

Who is asking it to comply with PCI DSS? Why are they asking it to be compliant? What happens if it doesn't comply? And how will it need to provide evidence of its compliance? And is there a deadline? Because the answers to these individual questions will help the organization to answer the real question it should be addressing, which is not exactly do we really have to do this, but what flexibility is there in being compliant? Because it's really useful to remember that on the one hand, PCI DSS is a written security standard and, on the other, compliance with PCI DSS is mandated by contractual relations that originate from card brand rules. And therefore, like all contractual elements, some aspects of compliance, such as the date an organization will be compliant by, may be negotiable. There are, of course, benefits to complying with the standard, aside from the fact it might be something agreed to in a contract. The first is that it's a good security standard. The chance of an organization which is properly compliant suffering a data breach is really small. The second is that if it does have a data breach, an organization's compliance status will be taken into account by the card brands when they levy data breach penalties. Compliant organizations have lower or waived penalties.

Validating Compliance: Onsite Assessment or Self Assessment?
There are two different ways that an organization can be asked to demonstrate its compliance with PCI DSS.
Large merchants, merchants that have previously suffered a data breach, and service providers will be required to have an annual independent assessment of their compliance.
This is called an on‑site assessment, although, of course, it can be carried out remotely as dictated by health and safety requirements. In the course of this type of assessment, an assessor, trained and certified by the Payment Card Industry Security Standards Council, will carry out the testing procedures specified in the standard for each of the 300 or so PCI DSS requirements. The assessor will interview people, look at documentation, observe technical system settings, and validate the records that PCI DSS requires an organization to maintain. At the end of this exercise, if the assessor was able to find evidence that all of the requirements are in place, the organization undergoing the assessment will receive two documents. Firstly, a Report on Compliance, a ROC, which constructs the many hundreds of pages and which details the evidence seen by the assessor that demonstrates that the organization was in compliance with all the requirements. And, secondly, an attestation of compliance, an AOC, which is a shorter document summarizing the organization's compliant state and which is signed by the assessor. It's this AOC, which is used by the organization to provide evidence of its compliance to anyone that asks. Onsite assessments are comprehensive and typically take between one and three weeks.

The other way an organization may demonstrate its compliance with PCI DSS is to complete a self‑assessment questionnaire, or SAQ. These are typically used by smaller merchants.

There are nine different types of SAQs, which are tailored to the way that merchants typically accept payments such as face‑to‑face retail, processing telephone orders, or via an e‑commerce website The SAQs just contain a subset of the PCI DSS requirements, the ones that are most important to deal with a threat specific to the way that that merchant processes transactions.
Completion of a self‑assessment questionnaire requires the organization to look at the testing procedures associated with each requirement and determine whether it's compliant or not.
The completion of a self‑assessment questionnaire can therefore be as rigorous and onerous as the organization wants it to be.

We're going to focus on the onsite assessment.
There are two types of assessors certified by the PCI SSC to carry out onsite assessments.

1. The first are Internal Security Assessors, ISAs, who work for the organization being assessed.
2. The second and more common type of an assessor is a Qualified Security Assessor, a QSA, who works for an external professional services company, which is licensed by the PCI SSC to undertake onsite assessments.

Now here's where PCI DSS does get a bit confusing and why I've been particular about saying that there's a security standard, and then there are card brand compliance programs, which require organizations to evidence their compliance with the standard.
These card brand compliance programs are enforced by the merchant's acquiring bank. Because when it comes to merchant compliance, some card brands allow ISAs to complete onsite assessments for certain types of merchants, and other card brands only allow QSAs to do this work. So it is vitally important that any merchant, which is being asked to demonstrate its compliance with PCI DSS talks to its acquiring bank to ask how the merchant should do this. Does it need to provide a self assessment or must it arrange for an onsite assessment? And if it needs an onsite assessment, can it use an ISA or must it use a QSA?

Choosing an Assessor
If an organization is required to have an on‑site assessment by a QSA, one of the most important tasks it faces is to choose the QSA. Just as with the every profession, there are highly competent and skilled QSAs, and there are some that are less so. The two things I look for when hiring a QSA are previous experience within the industry or vertical that the organization operates in. If you're a retail merchant, you don't want a QSA that's never assessed a retail merchant and has only assessed E‑commerce. And the second thing is a non‑dogmatic attitude to the standard because although the standard itself is prescriptive, the way each organization's unique combination of technology and payment processing, the way they're assessed against the standard, could be subjective. There could be a number of different ways of interpreting how the standard applies in a particular circumstance. An experienced QSA will be confident enough with the standard, with the PCI SSC guidance, and the industry to be able to be pragmatic. They'll be happy to use compensating controls when there's a technical or business constraint that means the organization being assessed cannot comply with the requirements.

Compliance Strategies and Business Impacts
Determining the Scope of PCI DSS
You may be surprised that my strategic advice to any organization faced with the challenge of PCI DSS compliance is to aim to do as little PCI DSS as possible. Let me explain what I mean by that. Those 300 or so prescriptive PCI DSS requirements apply to all people, processes, and technology that store process or transmit cardholder data. The PCI DSS term for everything that stores, processes, or transmits cardholder data is the cardholder data environment, or CDE. The PCI DSS requirements also apply to all people, processes, or technology that are connected to the cardholder data environment or that can affect its security. What this means for most organizations when they start looking at PCI DSS is that the hundreds of prescriptive requirements will apply to the entire organization. Even organizations that do security well will find achieving the standard that PCI DSS requires challenging. Organizations that have not previously experienced regulated security before will find it extremely challenging. And it's not only achieving PCI DSS compliance that will be a challenge for most organizations, but maintaining that compliance on an‑ongoing year‑on‑year basis. So, having a small cardholder data environment and minimizing the number of systems that are connected to it means doing less PCI DSS, which will result in a lower financial cost and smaller business impact in the long term.

A Typical Compliance Program
A typical PCI DSS compliance program consists of five phases.

1. The first phase is the preparation phase where the organization makes sure it understands what compliance means, who is asking you to be compliant, how does it need to provide evidence of its compliance, and how long does it have to achieve compliance?
2. In the second discovery phase, the organization needs to understand the current footprint of payment card data across the organization. It will map out the way that the payment card data passes through the organization so it can understand which systems, processes, and people will be in or be connected to the cardholder data environment, and therefore, which will need to comply with the requirements contained within PCI DSS. This process of understanding this scope of systems, people, and processes that the PCI DSS requirements will apply to in an organization is commonly called scoping.
3. The third phase is dominated by business analysis and architecture. The aim is to determine whether the number of people, processes, and systems in or connected to the CDE could be reduced. And there are typically three workstreams in this phase.
   The first workstream looks at how the organization accepts payment transactions and how it processes payment card data. The aim is to see if changing business processes or outsourcing some of those business processes would not only reduce the scope of PCI DSS in the organization, but also produce a tangible business benefit.
   The second workstream is the more technical one, looking at the organization's networks and systems to determine whether it can segment the cardholder data environment from the rest of the organization's IT infrastructure. The aim is to try to get all systems, processes, and applications that are not related to the processing of cardholder data out of the scope of PCI DSS by ensuring that they're not connected to the cardholder data environment.
   The third workstream determines what new technical solutions are required to meet the PCI DSS requirements. After that, business process reengineering and a network segmentation has been completed. You might hear this referred to as a gap assessment to determine the technological gap between the organization's current security posture and that demanded by PCI DSS.
4. The fourth phase of a PCI DSS program is where most of the actual work in the program takes place. This is where the technical and business solutions that were designed in the third phase are actually put into place within the organization. And in a large organization, it's not untypical for this phase to span a number of years.
5. The fifth and final phase of the program is the assessment phase, and this will generally also require some technical remediation where the assessor wasn't able to determine a requirement was in place; however, once all requirements are in place and the assessors said, yep, you're good, the organization will receive its report on compliance and the accompanying attestation of compliance. My strong advice is that any program that aims to make an organization compliant with PCI DSS should be led from outside of IT because it's an issue for the whole business. To look at the way that cards are accepted to optimize these and then to minimize the number of systems internally that store, process, or transmit cardholder data requires lots of departments across the organization to cooperate with each other.

Maintaining PCI DSS Compliance

Once an organization is compliant with the standard and has received its first assessment, it then needs to stay compliant.
There are three aspects to this.

1. Firstly, all technical controls decay over time, and without proactive management, when it comes time for the second assessment 12 months later, the assessment will find that typically between 20 and 40% of requirements that were in place at the time of the first assessment are no longer in place.
2. Secondly, PCI DSS has a number of scheduled tasks that have to be completed on a daily, quarterly, and annual basis. If these tests are not completed to the schedule contained in the standard, the organization falls out of compliance.
3. The third aspect of maintaining compliance is managing change. Technological changes, business changes, system changes, and people changes can all affect whether the scope of PCI DSS remains the same and also that the PCI DSS requirements are in place. To remain compliant, all change in the organization has to be assessed to determine its impact on the PCI DSS environment. Staying compliant is really hard, and most organizations struggle with it. This is frequently because there's a big organizational initiative to get compliance, and then success is measured in terms of passing that first onsite assessment. However, the best way to ensure PCI DSS gets embedded into an organization as a business as usual processes is to make any program designed to achieve PCI DSS compliance finish at the end of the second PCI DSS assessment and not the first.