Keeping financial data secure is becoming a top challenge for businesses of every kind and every size. If your business stores, processes, or transmits credit card information, you are required to maintain a secure IT environment—and to be compliant with PCI regulations.
Earlier this year the Payment Cards Industry (PCI) Security Standards Council mandated new data security guidelines to address increased security threats, more sophisticated attacks targeting customer payment data and—in some cases—lax internal controls and focus by merchants and service providers. PCI Data Security Standard (DSS) 3.2 replaces version 3.1, which will expire on Oct. 31, 2016.
When is Adoption of the New Standard Required?
The question on every businesses’ mind: when is the adoption of this new standard required? The good news is that all of the new regulations are considered best practices until Feb. 1, 2018, which gives businesses an opportunity to prepare to implement these changes. However, it’s important to note that the PCI Security Standards Council recommends adoption of the new standard as soon as possible.
It makes sense, since, with the rapidly growing increase in cybercrime, compliance with PCI-DSS is only a first step in detecting, and responding to cyberattacks. Businesses can put off adopting the new standard, but the reality is that the longer the road to adoption, the greater the risk. Equally important is the push by the council to help merchants and service providers view the implementation and maintenance of PCI DSS as an ongoing process—instead of basic adherence to assessment deadlines.
Update to Payment Application Data Security Standard (PA DSS 3.2)
Also important to note is that a month after releasing PCI DSS 3.2, the Council also released an update to the Payment Application Data Security Standard (PA DSS 3.2). PA-DSS 3.2 is used by vendors to ensure their software products will help protect cardholder data from theft. Such PA-DSS validated software is required under the more comprehensive PCI DSS, and the majority of changes are simply to support those in PCI DSS 3.2.
According to Council General Manager Stephen Orfei, “The primary changes in version 3.2 are clarifications on requirements that help organizations confirm that critical data security controls remain in place throughout the year, and that they are effectively tested as part of the ongoing security monitoring process. PCI DSS 3.2 advocates that organizations focus on people, process, and policy, with technology playing an important role in reducing the overall cardholder data footprint.”
Key Changes in PCI DSS 3.2
Now that we’ve covered the basics about these changes, let’s take a closer look at the key changes in PCI DSS 3.2.
- Expansion of Requirement 8.3 to Include Use of Multi-Factor Authentication for Administrators Accessing the Cardholder Data Environment
As Verizon’s 2016 Data Breach Investigations Report reveals, 63 percent of confirmed breaches involved weak, default, or stolen passwords. The report recommends that companies avoid single-factor authentication. According to Troy Leach, the council’s chief technology officer, this trend toward the use of weak and stolen passwords is the reason PCI DSS 3.2 requires multi-factor authentication for system administrators working internally who access a Cardholder Data Environment (CDE). Multi-factor authentication for remote access to a CDE has been a part of the PCI DSS standard from the outset.
“The most important point is that the change to the requirement is intended for all administrative access into the cardholder data environment, even from within a company’s own network,” Leach says. “This applies to any administrator, whether it be a third party or internal, that has the ability to change systems and other credentials within that network to potentially compromise the security of the environment.”
- Upgraded Service Provider Requirements
PCI DSS 3.2 will incorporate some of the Designated Entities Supplemental Validation (DESV) criteria for service providers, which previously had been housed in a separate document. Service providers must demonstrate that they have a detection mechanism in place to respond to a failure of critical security controls.
Also among the upgraded service provider requirements are fundamental changes to the frequency of checks and tests. Service providers must now conduct penetration tests on the segmentation of the network at least twice a year, and they must run quarterly checks to ensure that their personnel is following security policies and procedures. In addition, top executives at service providers must demonstrate an understanding of PCI DSS compliance.
“Service providers play an important role in securing cardholder data for their customers,” Leach stated. “An organization could go to great lengths to protect their internal network, only to see a third party negate all of their effort as indicated in data breach reports. That is why several new requirements were identified for service providers in PCI DSS 3.2.”
- Extended Migration Dates for SSL/Early TLS
Because there were serious vulnerabilities in Secure Sockets Layer (SSL), and early Transport Layer Security (TLS), the Council removed SSL as an example of strong encryption from the PCI Data Security Standard. SSL is the industry standard that encrypts the channel between a web browser and web server and TLS is replacing SSL.
According to InformationWeek’s, DarkReading.com, this change necessitates migration from SSL and TLS 1.0 to a secure version of TLS (currently v1.1 or higher) by July 1, 2016. However, to provide more time for the transition, the PCI Council has pushed back the migration deadline to July 1, 2018. PCI DSS 3.2 also includes a migration appendix to help companies make the transition in a logical manner.
Why Adopt PCI DSS Changes Sooner Rather Than Later?
There are other important changes in the new PCI DSS version 3.2 that are important for businesses to note. Two that are particularly important for IT teams to consider implementing as quickly as possible include:
Requirement 3.51, which compels service providers to maintain a documented description of their encryption architecture; and
Requirement 10.8.1, which requires service providers to implement a process for the detection and reporting of failures of critical security control systems (defined, in part, as firewalls, anti-virus systems, physical and logical access controls, audit mechanisms, and segmentation controls).
These are key operational directives for IT personnel and getting systems in place to develop these processes definitely falls in the “better sooner than later” approach to implementing these requirements.
This is a lot of information, and a lot of important changes. No matter how limited your resources, how overwhelming the amount of data you need to monitor, or how confusing you find the entire process—you must be in compliance with PCI DSS regulations. It is the cost of doing business. You also must be vigilant and maintain PCI DSS standards year-round, which includes understanding the changes in PCI-DSS version 3.2 and how they will impact your operations. Although not fully required until February 1, 2018, the Council recommends adopting the new standards as early as possible, and, with the increase in data breaches worldwide, this is good advice.
Need help understanding the changes to the PCI DSS 3.2 requirements? Our team at OnRamp are experts in PCI-compliant hosting and related issues. We can help take the pressure off of you and your team, provide the technical assistance and systems needed, and make PCI compliance for your organization something you can mark as done. Give us a call. We’ll be glad to help.
photo credit: Information Security Wordle: PCI Data Security Standard via photopin (license)