Payment Card Industry Data Security Standard - version 3.2 (2017)
This is my personal summary based on the following materials:
- Payment Card Industry Security Standard Council (PCI SSC) - Internal Security Assessor (ISA) training
- SANS LEG 523 - Law of Data Security and Investigations - training and case studies
- PCI DSS awareness training with an accredited auditor at my company (2016)
- last but not least my professional experience, also with attesting PCI DSS compliance
This summary does not reflect the position of the PCI SSC and is provided as an archive and a personal reference only.
IT compliance management
Generally IT compliance and Information Security are two different domains. Ideally your IT security strategy for eCommerce systems, which are under PCI DSS compliance, is made to archive both. My general rule of thumb is:
Do not sugar coat the mandatory with what is wise.
That means that I do not recommend to mix information security objectives with PCI compliance objectives. Instead the synergy should be surfaced by a project plan. But the domains should remain clearly distinguishable. The reason is, that it is much easier to manage and measure the process objectives, if it's transparent what they archive for the business.
The crucial tool for reducing risk of in-compliance is to establish and maintain an ongoing process for implementing, reviewing and improving compliance with a standard.
If there is one thing you can take away from this wiki post, it's that. Without a process, compliance matters create a lot of un-managed risks. Un-managed risks are always critical. Critical findings in an internal assessment, and critical findings in an external security audit.
PCI DSS compliance as a process
Generally it is easy to become compliant. Staying compliant is a continuous matter. That means a compliance management project does not end once compliance is attested.
The risk of in-compliance introduces other risks via a domino effect (see this white-paper for more infos):
- brand damage, in case you did not protect your customer's credit cards while being in-compliant
- credit cards brands can prevent you from using their cards
- non-compliance fines, which are rumored to range between 5 000 and 500 000 USD.
- litigation expenses, in case of data breaches. You would have to defend against negligence, and maybe against the FTC or your local equivalents
In short: it is sound advice to avoid legal issues with courts, federal institutions and banks.
General advice for engineers on dealing with legal matters
When you work with legal matters (such as compliance):
- Chose words carefully
- Apply critical thinking, while managing the risk of in-compliance
- When the requirements are unclear, proportionality is a responsible standard
Where does PCI compliance come from?
It exists since the end of 2004, and was formulated by a foundation known as the PCI SSC. The founding members are Visa (EU and US), Mastercard, American Express and JCB. Their mission is to secure the payment ecosystem. Some of the requirements of the PCI standard require you to write policies.
The standards council does not write the policies for you, because these need to comply with the standard (which is not a law) and the laws. The laws your enterprise has to follow. That can be anything from federal tax law about record retention to national or inter-national data privacy standards.
One good strategy for such policies is to make sure the language of these policies is well chosen. Policies can open a company up to litigation, if the words aren't chosen carefully.
What is important for 2017
The standard got extended since 3.1, especially for the SAQ A and SAQ AE. The new requirements include Physical Access Control for co-location sites. which are often provided by a data-center service provider which hosts the racks. This service provider has to supply an AoC (Attestation of Compliance).
PCI DSS 3.2 - SAQ A project example
PCI DSS 3.2 is in effect since October 2016 (when 3.1 retired), and the current standard at the time of this post.
Systemsl, which are part of the payment card ecosystem, have to be compliant. There are different compliance levels and different compliance requirements (and standards), depending on the device and interaction with Credit Card data. This wiki entry is about PCI DSS only.
There are Self-Assessment Questionnaires (SAQs) in PCI DSS 3.2. On the lower compliance levels there are SAQ A and SAQ A-EP.
The focus of the following sections is to define the requirements for an SAQ A, and to document a workflow to build processes to support PCI DSS compliance. This is a minimal example.
The intention of this example is to allow an expanding project strategy: if the compliance level goes up, that means the project grows. But its structure remains. This is a the workflow driven approach.
Note that in case you have more than 6 million credit card transaction per year, you will need to get a RoC (Report of Compliance) from a QSA.
6 goals for PCI DSS
- Remove sensitive authentication data and limit data retention.
- Protect systems and networks, and be prepared to respond to a system breach.
- Secure payment card applications.
- Monitor and control access to your systems.
- Protect stored cardholder data.
- Finalize remaining compliance efforts, and ensure all controls are in place.
Ref: The Prioritized Approach to Pursue PCI DSS Compliance - PCI SSC 2016, page 2
This document from the PCI SSC gives a reasonable suggestion to lay out a project plan for PCI compliance in a company. It also helps to understand PCI compliance and its objectives. The 6 goals here are the Milestones.
PCI DSS SAQ A - project plan outline
The SAQ A has the least amount of requirements. This should be easy to manage.
Let's visualize the objectives:
That doesn't look insane, does it? We have 4 (or 5 with the TLS part, which I mention later) requirements in this project, and they contribute to the 6 PCI DSS goals. As they are defined by the PCI SSC.
So, enough visualizations... let's start: what do these requirements mean? I won't describe then in their entire detail, but highlight the aspects which can cause the most amount of work.
PCI DSS 3.2 SAQ A - Req 2: Build and Maintain a Secure Network and Systems
Do not use vendor-supplied defaults for system passwords and other security parameters
The magic word here is "network separation", in order to isolate the CDE network from the other in-use networks. You might ask: why? This requirement does not mandate this directly.
In my opinion network separation allows a scoped PCI assessment and a project scope.
A flat network means that all servers within the network are to be in PCI scope. - That all servers in a flat network need to be compliant to PCI DSS requirements, including Req 2. You have to account for that, document this, assess this regularly and report this. My point is, that this is a huge overhead, since this is mandated.
2.2. mentions configuration standards, such as CIS, ISO, SANS or NIST standards. The choice should be depending on the organization, which is subject to reporting compliance.
Of course other systems, such as DNS servers should be secured based on these best practice standards as well. But that constitutes an information security objective, and not a PCI DSS compliance objective in my opinion. My recommendation is to incorporate
2.2 although it's not in an SAQ A, because it makes it much easier to account for the change of vendor supplied defaults this way.
This requirement tangents the PCI DSS goals 2.) and 3.).
PCI DSS 3.2 SAQ A - Req 8: Implement Strong Access Control Measures
Assign a unique ID to each person with computer access
The magic word here is "multi-factor authentication". Again, my recommendation is to do this for an isolated network. That means that according to PCI DSS you do not have to report and assess requirement 8 continuously for all the systems in that
/24. I know there are many flat network advocates out there though.
Typically this is addressed with Smart Card authentication methods. The solution of choice should be well evaluated. Especially the fallback strategies matter to operational staff members.
This requirement tangents the PCI DSS goals 2.) and 4.).
PCI DSS 3.2 SAQ A - Req 9: Restrict physical access to cardholder data
Now, here you might be inclined to state: "I do not have cardholder data." That is correct, but you still need to do this, for the physical systems in scope.
For an SAQ A this is most likely a web server in a rack, maybe even a VM on a virtualization system. If this VM migrates between hardware systems, like on a VMware ESX, that matters here.
In many cases the co-location data-center / service provider has to provide the AoC for the physical security controls. Whether it is Amazon AWS, Microsoft Azure, GCP or any other service provider, who runs this. In many cases these service providers have their AoC available for customers, who are paying for this as an extra service.
In context of an SAQ A you have a PCI compliant third party - the Acquirer. You may get reports from the Acquirer into the ERP system (check with the Finance department), there are refunds (usually accounting or Customer Support)... You might want to create data-flow diagrams to account for all the incoming and outgoing interfaces. None of these should transmit cardholder data.
A challenge here might be, that you need to account for procedures and policies. As an internal assessor you are a liaison to PCI SSC. So you should have access to your company's internal policies, which are supported by principal level staff members at your company. You need to conduct an independant gap analysis for these policies. This leads to requirements 12.
This requirement tangents the PCI DSS goals 1.), 2.) and 5.).
PCI DSS 3.2 SAQ A - Req 12: Maintain a policy that addresses information security for all personnel
Here you need to have these requirements reflected in the documentation. You - as always - need policies and procedures.
12.2 defines that you need to do a risk assessments, based on a methodology like OCTAVE, ISO 27005, NIST SP 800-30 or COBIT 5 for Risk.
That can be easy to do, because an SAQ A means that you do not store or transmit cardholder data. You most likely have an iFrame redirect solution and relay customers to the Acquirer. That means, given that you have a separate network, this is a tightly scoped risk assessment. If you don't have that, this is hard work. This technically isn't a requirement for an SAQ A but I'd do it anyways. To be sure that you have evidence for a good security posture.
This requirement tangents the PCI DSS goals 1.), 2.) and 6.).
Appendix A2: Additional PCI DSS Requirements for Entities using SSL/early TLS
Ref: PCI SSC paper - Migrating from SSL and Early TLS
You at least need to offer TLS 1.1 or higher.
Having TLS 1.0 and / or SSLv3 as the one and only options is a compliance violation, which will surface to you and the Acquirer if you run your ASV scan. Now you might say, that the SAQ A does not mandate ASV scans. And that the iFrame, which you use to redirect your customers, leads to the Acquirer's endpoint. - Which in short means that the Acquirer will have to setup for appropriate cryptography, and not you.
That all doesn't matter in PCI DSS, because what you need to do is up to the Acquirer. Many Acquirers want ASV scans, and have their own compliance portals. And ASV scans also check TLS. Thus you may need to have appropriate TLS support. Or have a good reason, why you don't have that.
It is possible to dispute findings from an ASV scan, given that you do not transmit or relay cardholder data. So you using TLS 1.0 has no effect on the CDE. It is also possible to argument that you only support strong ciphers within TLS 1.0 (if that is the case). However I advice against that, unless you have a profound business reason and know what you are doing here. And how to setup controls for this.
Most assessors are not familiar enough with cryptography to back this up. And at the end of the day the Acquirer has the final word. It is unlikely that you encounter a cryptography expert, who will attest that what you do is reasonably secure.
In web site statistics, such as Google Analytics you will most likely see, that no paying customer uses a browser that isn't capable to support TLS 1.1 or higher.
If marketing or any other department is concerned about this kind of change, because of the possible implication on traffic loss of the web sites, there is a solution. You can put up a risk assessment and make sure that you can phase it out in time, as part of the risk mitigation plan. But a risk assessment is hard work, and it's probably not worth it.
This requirement tangents the PCI DSS goals 2.), which means your risk assessment needs to define mitigating controls for system and network protection.
PCI DSS compliance project management: to become and remain compliant
For PCI DSS process management you should enumerate the cyclical tasks, and set dates until when you provide reviews and risk assessments. Of course you also need to manage the compliance attestation and the deadline until when you have to submit the SAQ document.
After becoming compliant it is important that you oversee the change and configuration management for the environment in scope. Some companies have process landscapes for this, in which you need to define this as a service. This might be where ITIL (Planing, Protection, Optimization) matters to you in information security.
This ties back to the 6 PCI DSS requirements, which you might need to measure. Measuring compliance control objectives is relatively simple in practice. Because you assess frequently, and that is a measurement
My strategy usually is to do the network separation first, to have the project scope. Then the policies, to have the executive or principal level backup and then the configuration management. But that is always company specific, and therefore the final word is: there is no magic compliance medicine.