Read to learn about the major requirement changes in PCI versions 3.2 and 3.2.1.
This post contains the text from the White Paper: How to Become Compliant with PCI DSS 3.2 and 3.2.1.
Payment Card Industry Data Security Standard (PCI DSS) version 3.2 received minimal changes (and future versions will likely contain similar incremental changes), which were specifically related to security threats rather than large-scale updates. Many of the 3.2 updates were minor clarifications to existing requirements or geared towards testing procedures.
PCI DSS 3.2 and supporting documents were released on April 28, 2016. On October 31, 2016, PCI DSS 3.1 retired, and all assessments needed to use version 3.2 self-assessment questionnaires (SAQs). Since February 1, 2018, organizations have needed to implement all new 3.2 requirements. PCI DSS 3.2.1 was released on May 17, 2018, replacing version 3.2. Click here to learn more.
Key changes in PCI DSS 3.2 were:
In this white paper, you will learn about these and other key PCI DSS 3.2 changes as well as tips to help you understand and implement PCI compliance.
In December 2015, the migration dates for organizations to move from SSL and early TLS to the latest version of TLS (e.g., TLS 1.2 or better) were moved back from June 2016 to June 2018. Because as of June 30, 2016, service providers are required to provide a secure service offering, the PCI Council wanted to reflect that date change in the latest version of PCI DSS.
Many businesses are opting to stick to the original 2016 date so they don’t have to deal with the extra exposure. Using SSL encryption is very risky to security since it has many exploitable vulnerabilities. So even though the deadline has been extended, it’s a good idea to update to TLS 1.2 as soon as possible.
If you use SSL and early TLS and need to continue using these tools, remember not to add any new systems or technologies that use SSL and early TLS. If you need to continue them for regular business operations, the following examples explain some options:
You need to establish a formal Risk Mitigation and Migration Plan, where you detail your plans to migrate to TLS 1.2 (or better) and describe controls in place to reduce the risk associated with SSL/early TLS until the migration is complete. For example, new vulnerabilities could emerge at any time, and it’s up to you to remain up-to-date with vulnerability trends and determine if your organization is susceptible to any known exploits.
For Point of Sale (POS) Point of Interaction (POI) terminals using SSL and/or early TLS, you need to verify that the terminals (and the SSL/TLS termination points to which they connect) are not susceptible to any known exploits (see appendix A of PCI DSS 3.2.1 for additional requirements). If you find vulnerabilities in your POS POI environment, plan for migration to the latest version of TLS immediately. Although you are allowed to use SSL/early TLS for POIs after June 30, 2018, you should consider upgrading your POI environments to the latest version of TLS.
PCI DSS 3.2 incorporates some extra validation procedures in the Appendix. An entity is required to undergo an assessment according to this Appendix ONLY if instructed to do so by an acquirer or a payment brand. Designated entities are those who:
If you’re unsure if you’re a designated entity, you likely aren’t one. Acquirers and payments brands should notify you if you are and what you are required to do. For example, in addition to full PCI DSS validation, designated entities must have some additional validation that determines whether a business’s day-to-day practices are reflective of their compliance.
The additional validation procedures are for designated entities to ensure they are PCI compliant on a day-to-day basis.
An example would be looking at a list of all the change controls in a merchant’s environment for the past year. These procedures could include anything that shows the day-to-day compliance.
PCI DSS 3.2 clarifies masking criteria for primary account numbers (PAN) when displayed. Masking is described as hiding information from view; this is not the same as encryption. When displaying a credit card number or bank identification number (BIN), you are allowed to display, at a maximum, the first 6 and last 4 numbers.
Although you can display the first 6 and last 4 numbers of sensitive data, only display what is necessary to perform a specific business function. For example, if a job only needs the last 4 digits, mask the rest of the information.
Additionally, you’re required to document who needs access to more than the first six/last four numbers of sensitive data (including full PAN). You must log all access to cardholder data, specially what data was viewed by which user.
REMEMBER, IF YOUR BUSINESS STORES PAN, YOU’RE ALSO REQUIRED TO ENCRYPT AND PROPERLY SECURE IT.
PCI DSS 3.2 explains that you need to have a change management process to ensure that all new or changed systems and networks implement all relevant PCI DSS requirements, upon completion of a significant change. Your documentation should include what qualifies as a ‘significant change’ and these process updates.
Examples of possible requirements that could be impacted:
PCI DSS 3.2 requires additional multi-factor authentication for administrators within a Cardholder Data Environment (CDE). Multi-factor authentication is an effective way to secure your CDE, and is a requirement under PCI DSS. To properly configure multi-factor authentication, you must have at least two of three things:
Prior to PCI DSS 3.2, multi-factor authentication was previously required for remote access to the network (e.g., external network access) by employees, administrators, and third parties. But now, all non-console administrative access into the CDE requires multi-factor authentication. As with all PCI DSS requirements, this is a reflection of the current threat landscape. This change helps strengthen security within your CDE as well as outside it.
Additionally, make sure you “incorporate multi-factor authentication for all remote network access (both user and administrator, and including third-party access for support or maintenance) originating from outside the entity’s network.”
ALL NON-CONSOLE ADMINISTRATIVE ACCESS TO CDE REQUIRES MULTI-FACTOR AUTHENTICATION.
PCI DSS 3.2 has further explained that “the extent to which the service provider is responsible for the security of cardholder data will depend on the particular service and the agreement between the provider and assessed entity.” You should obtain a written security acknowledgement from the service provider, where they acknowledge their responsibility to protect cardholder data that they’re storing, processing, transmitting, or can affect your organization’s security.
This section contains the most important new and revised requirements specifically for service providers. A service provider is an organization that’s not a payment brand, but is directly involved in the processing, storage, or transmission of cardholder data on behalf of another organization (e.g., managed firewalls, merchant processor).
Before January 31, 2018, these new/revised service provider requirements were considered best practice and became requirements after February 1, 2018.
Service providers need to maintain a documented description of cryptographic architectures, including:
You need to keep pace with evolving threats to your architecture by planning for and documenting updates (e.g., different algorithms/key strengths changes). Maintaining such documentation helps you detect lost or missing keys or key-management devices, and identify unauthorized additions to your cryptographic architecture.
Service providers are required to “implement a process for the timely detection and reporting of failures of crucial security control systems,” including, but not limited to, failure of:
Service providers need to respond to failures of any critical security controls in a timely manner. Processes for responding to failures in security controls must include:
Document that processes and procedures are in place to respond to security failures. Make sure staff are aware of their responsibilities in the event of a failure. If you are breached, document your organization’s actions and responses to the security failure.
IF SECURITY FAILURES ARE NOT QUICKLY AND EFFECTIVELY RESPONDED TO, ATTACKERS MAY USE THIS TIME TO INSERT MALWARE, TAKE SYSTEM CONTROL, AND/OR STEAL DATA FROM YOUR ENVIRONMENT.
Since February 1, 2018, service providers who use segmentation are required to perform penetration testing on segmentation controls at least every six months and after any changes to segmentation controls/methods.
Validation of PCI DSS scope should be performed as frequently as possible to ensure PCI DSS scope remains up to date and aligned with changing business objectives.
This penetration testing should be performed by a qualified internal resource or third party and, if applicable, organizational independence of the tester exists (not required to be a QSA or ASV). The purpose of the penetration testing is to test segmentation controls/methods in use to verify whether segmentation controls/methods are operational and effective.
Although this requirement only applies to service providers, any organization can request a penetration test whenever they wish to measure their business security. Helping you find security weaknesses, penetration testers analyze network environments, identify potential vulnerabilities, and try to exploit those vulnerabilities (or coding errors) just like a hacker would.
The time it takes to conduct a penetration test varies based on network size, network complexity, and the individual penetration test staff members assigned. A small environment can be completed in a few days, but a large environment can take several weeks.
Penetration testers should be well versed in:
Typically, penetration test reports contain a detailed description of attacks used, testing methodologies, and suggestions for remediation.
AS A SERVICE PROVIDER, IF YOU USE SEGMENTATION, PERFORM PENETRATION TESTING ON SEGMENTATION CONTROLS AT LEAST EVERY SIX MONTHS AND AFTER ANY CHANGES.
Executive management needs to establish responsibility for the protection of cardholder data and a PCI DSS compliance program to include:
Smaller organizations should add these roles to an individual’s job responsibilities, while larger organizations might need to establish a PCI compliance team (e.g., a compliance team made up of IT, accounting, and management). Whichever is the case, management should give their PCI officer/team power to act and implement necessary changes to become PCI compliant, as well as have monthly (or weekly) meetings with executive management.
Service providers need to perform reviews at least quarterly to confirm personnel are following security policies and operational procedures. Reviews must cover the following processes:
In addition, you need to maintain documentation of quarterly review process, including:
Here are the basic changes:
SAQ
Description
# of
Questions
Vulnerability Scan
Penetration Testing
A
E-commerce website (third party)
24
N
N
A-EP
E-commerce website (direct post)
191
Y
N
B
Processes cards via:
41
N
N
B-IP
Processes cards via:
86
Y
N
C-VT
Processes cards:
83
N
N
C
Payment application systems connected to the Internet:
160
Y
N
D
E-commerce website
Electronic storage of card data
329
Y
Y
P2PE
Point-to-point encryption
33
N
N
PCI DSS 3.2 emphasizes the importance of documentation throughout the PCI process. You need to have your policies and procedures physically documented.
Documenting your policies is important because it helps employees and management comprehend what has been done, what still needs to be done, and where problems exist in your environment. It’s the failsafe that keeps your security efforts organized. If you don’t document your plan for PCI DSS, it will never happen.
Not only does documentation simplify your PCI DSS process, it also provides a great baseline for security training materials. Use your plan to educate employees on important security principles and procedures that apply to them.
If you document throughout your PCI DSS process, you’ll save time and maintain a greater level of security.
Although PCI DSS 3.2 (and 3.2.1) didn’t add new scoping requirements, it’s vital for organizations to know and regularly assess what is ‘in-scope.’ In-scope means if a particular person/process/technology/component stores, processes, handles, or transmits payment card data, or is connected to systems that do, they must be PCI DSS compliant.
For instance, if your call center agents take credit card payments via phone, enter that data in a computer, and if that information is captured in call recordings, your recordings, the servers that hold the recordings, your call center computers, your call center wireless network, and your call center agents may all be individually in scope.
System components most likely in scope for your environment may include:
Understanding your PCI DSS scope can save you a lot of trouble. If you understand which pieces of your environment fall under the standard’s requirements, you won’t unnecessarily work towards compliance on systems that don’t need to be compliant or leaving something out.
The only true way to understand your scope is to document it. PCI DSS Requirement 1.1.3 requires the creation of a cardholder data flow diagram for all in scope networks. Data flow diagrams are simply the graphical representations of cardholder data flow throughout your business.
Once you know your flows and know what systems they interact with, you can easily create a card flow diagram of how card data moves within your network.
Segmentation is not required to be compliant with PCI DSS 3.2 (or 3.2.1). However, if you’re looking for the easiest way to reduce cost, effort, and time spent on getting in-scope systems compliant, you may want to consider segmentation.
Network segmentation can be achieved by physically or virtually separating environment systems that store, process, or transmit cardholder data from those that don’t via firewalls or physical gaps.
For example, you install and configure a multi-interface firewall at the edge of your network. From there, you create one interface on the firewall dedicated just to the systems that store/process/transmit cardholder data. If that interface doesn’t allow any other traffic into or out of any other zones, this is proper network segmentation.
Segmentation can be extremely tricky, especially for those without a technical security background. Consider having a security professional double check all your segmentation work. For some SAQ types (e.g., SAQ D service providers), you will have additional requirements, such as Requirement 11.3.4.1 requiring penetration testing on segmentation controls at least every six months and after any changes.
Most individuals believe bad technology causes data breaches. However, according to PwC, employees and corporate partners are responsible for 60% of data breaches.
Employees are normal people. They haven’t had years of cyber security training (let alone are up-to-date with PCI DSS 3.2 or 3.2.1), and are therefore more likely to be vulnerable than most technologies, so educate your employees.
Create tailored data security training to individual employee roles. For example, your IT director requires different training than your front desk manager. Your IT director must be trained on how to protect cardholder data within your firewalls and servers, and what to do in the event of a breach. Your front desk manager who processes credit cards should be taught security awareness, how to identify a tampered point of sale system, and the acceptable use of technology.
To help employees retain what you’ve taught them, train monthly instead of yearly. Remember to require policy documentation signatures annually, and consistently enforce the policy with strict and appropriate sanctions. You only protect your business and customers if you hold employees accountable.
With any updates to PCI DSS (e.g., PCI DSS 3.2, 3.2.1), you should always consult with a security professional. You or your IT guys are not the experts on PCI compliance. PCI DSS Qualified Security Assessors (QSAs) are.
QSAs go through very intense training to understand everything there is to know about PCI DSS and the best ways to comply with many unique and different environments. They have the technical expertise to assist you through the process and to let you know if and how certain requirements apply to your evolving environment and business.
If you’re a small business, you probably won’t need a PCI DSS audit, but you should still talk to a PCI security professional to verify that you’re on the right compliance path for PCI DSS 3.2 (and future versions of the PCI DSS). Although this requires money up front, it may save you in the long run.
The deadline for PCI DSS 3.2 is getting closer. After October 31, 2016, organizations will need to use version 3.2 for all assessments. By February 1, 2018, all new 3.2 requirements need to be implemented. While you have some time to prepare, you should implement the new standard as soon as possible to ensure your organization’s security and compliance.
Start by creating and working through your PCI compliance program; you’ll also want to add the new and revised requirements to your new/existing program. Keep contact with a trained security professional to help you with compliance throughout the year, especially when you’re making changes to your PCI program and cardholder data environment.
By updating your PCI program to comply with 3.2.1, you help avoid fines and better secure your business’s data. The longer you wait, the longer your business could be vulnerable.
We help customers close security and compliance gaps to avoid data breaches. Our forensic, penetration testing, and audit teams identify best security practices and simplify compliance mandates (PCI DSS, HIPAA, HITRUST, GDPR). As an Approved Scanning Vendor, Qualified Security Assessor, Certified Forensic Investigator, we have tested over 1 million systems for security.
.svg)
