As the Red Queen tells Alice in Lewis Carroll’s ‘Through the Looking-Glass‘: „Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!“
PCI DSS (Payment Card Industry Data Security Standard) was first created in 2004 to ensure companies employ the best and most advanced security practices to protect credit card sensitive data from leaking. As more data moves to the cloud, risks increase respectively, and “bad actors” continuously improve. To cope with the ever-growing threats, the PCI DSS is constantly updated, and for good reasons:
During Q3 of 2021, 160 million people were victims of data compromise, caused mainly due to unsecured cloud databases. While the number of attacks and cloud security breaches dramatically increases, so does the financial damage that comes with it. According to IBM’s Cost of a Data Breach report of 2021, the average cost of data breaches rose, particularly in companies heavily reliant on cloud technology. In recent years, we hear of more and more companies suffering from cloud data breaches, having to pay dozens and sometimes hundreds of millions in fines and legal compensations (not to mention losses taken from reputation damage, customer loss, and direct financial damage).
Just like you need a driver’s license to get permission to drive, you must comply with PCI DSS requirements to be permitted to use/ process payment cards (credit or debit). The PCI DSS stipulates 12 main security requirements (and more than 300 sub-requirements) to ensure the safe handling of sensitive data created during the use and processing of payment cards. Similar to the driving license analogy, non-compliance to PCI DSS can lead to fines, lawsuits, and in the worst case losing the privilege to use payment cards altogether.
The “Administered Payment Card Industry Security Standards Council” (PCI SSC) created the first version of PCI SSC in 2004, and since then, it has issued several updates; the last was v3.2.1 published in May 2018.
This post will discuss the changes made in v3.2.1, the reasons behind them, and most importantly, tools that help augment your employees‘ ability to cope with security threats and improve PCI DSS compliance.
Is the PCS DSS 3.2.1 a new standard?
The short answer is no. It is an update of previous versions and contains no new PCI DSS requirements. It includes mainly clarifications, intended to clear any misunderstanding regarding the effective dates for PCI DSS 3.2 published in February 2018.
The main reason for the change was described by PCI SSC’s Chief Technology Officer Tory Leach who said in the official press release: “It is critically important that organizations disable SSL/early TLS and upgrade to a secure alternative to safeguard their payment data”. He added that entities will have a six-month transition period between PCI DSS v3.2 and v3.2.1, beginning July 1, 2018, for completing all the necessary changes.
What changes have been in PCI DSS 3.2.1?
As mentioned, the changes aimed to clarify the intent behind the requirements presented in PCI SSC v3.2. V3.2.1 includes new subsections and changes to existing ones:
1. PCI Requirements 2.2.3, 2.3, and 4.1:
PCI DSS v3.2.1 removed the note regarding the need to complete Appendix A2 (reporting SSL/early TLS migration effort) from requirements 2.2.3, 2.3, and 4.1.
A new note has been added to each of these requirement’s guidance column stating that: “SSL/early TLS is not considered strong cryptography and may not be used as a security control, except by POS POI terminals that are verified as not being susceptible to known exploits and the termination points to which they connect as defined in Appendix A2.”
2. PCI Requirements 3.5.1, 6.4.6, 8.3.1, 10.8, 10.8.1, 11.3.4.1, 12.4.1, 12.11, and 12.11.1|
In v3.2 PCI Requirements 3.5.1, 6.4.6, 8.3.1, 10.8, 10.8.1, 11.3.4.1, 12.4.1, 12.11, and 12.11.1 went from being “best practices” to mandatory requirements on February 1, 2018 (for example: Implement a methodology for the timely identification of attack patterns/undesirable behavior across systems, implement PCI DSS requirements on all new or changed systems and networks, incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access, timely detection, reporting & response of failures of critical security control systems, performing penetration testing on segmentation controls at least every six months and after any changes to segmentation controls/methods, an additional requirement for service providers, perform documented reviews – at least quarterly to confirm personnel are following security policies and operational procedures).
Hence the note in PCI DSS v3.2 addressing the effective date of these requirements (that has already passed) was removed.
3. PCI Requirement 3.6.2
PCI DSS v3.2.1 addresses an error in the guidance. A reference was changed from PCI Requirement 3.5.1 to 3.5.2.
4. Appendix A2
As mentioned, In v3.2. Appendix A2 was updated to reflect the fact that the SSL/early TLS migration date has passed. Therefore requirements A2.1 – A2.3 were updated “to focus only on the allowance for POS POIs that are not susceptible to known exploits and their service provider termination points to continue using SSL/early TLS”.
I.e., Appendix A2 now only applies to entities using SSL/early TLS as a security control to protect Card Present Point of Sale (POS) Point of Interaction (POI) terminals (including service providers who provide connections into POS POI terminals).
5. Appendix B
Since PCI DSS requirement 8.3.1 had become mandatory (as mentioned above), the compensating control example included in the PCI DSS Appendix B of v3.2.1 was updated.
The change in v3.2.1 clarifies the intent of the requirement and also updates MFA (multi-factor authentication) rules. The new version replaced the reference to Navigating Guide with Guidance Column for understanding the intent of requirements. It also removed MFA from the compensating control example (as MFA is now required for all non-console administrative access) and added the use of one-time passwords as an alternative potential control for this scenario. For example, as section 8.3.1 is a password requirement, it cannot be used to compensate for an entity’s lack of fulfillment of other PCI DSS password requirements.
How to remain compliant in accordance with v3.2.1
As discussed, the changes in v3.2.1 mostly revolve around updating the dates of requirements and clarifying the fact that in v3.2 many sections went from being “best practices” to “mandatory requirements” (for example 3.5.1, 6.4.6, 8.3.1, 10.8, 10.8.1, 11.3.4.1, 12.4.1, 12.11, and 12.11.1 – see above). Therefore, the best way to ensure you are compliant is to ultimately fulfill and implement all the requirements (old and new) described in v3.2 in the strictest way possible.
Cybersecurity, data risks, and protections are constantly and rapidly evolving. Today, the speed at which bad actors are able to exploit weaknesses is growing by the minute. The newest version of PCI DSS is specifically designed to address this issue. For instance:
- Section 6.4.6 mandates all merchants to prove proper security is being utilized when there is a change in the cardholder data environment.
- Section 8.3.1 states that multi-factor authentication, or MFA, is required for ALL non-console access (in comparison to the earlier, less strict rule of only needing MFA for remote console access in cardholder data). In version 3.2.1, section 8.3 was expanded into 8.3, 8.3.1, and 8.3.2.
- Section 12.11 stipulates that service providers must perform quarterly reviews to ensure all personnel are following mandatory security procedures and policies.
- Section 10.8 – states that providers must report and remediate each and every failure of their security systems in a timely manner (firewalls, file integrity management, logical and physical access controls, antivirus, etc.).
It is important to remember that, like in all PCI DSS versions, v3.2 and 3.2.1 greatly emphasize managing and protecting the human factor. In other words, the PCI DSS requirements are all designed to ensure that personnel will continually act in full compliance with the best and most robust security technologies (systems and applications), protocols, and procedures.
Conclusion
PCI DSS compliance (like all cloud security) rises and falls on the organization’s employees‘ readiness and daily behavior. Even the best antivirus applications will not be able to stop new threats if they are not continually updated. Technologies like the ones provided by CybeReady are focused on solving precisely these problems.
CybeReady’s cyber security training platform allows you to change employees‘ behavior, helping them to dramatically improve security while complying with PCI DSS requirements. Unique tools such as security awareness training, phishing simulations and AuditReady, use fun and engaging practices to enhance employees‘ cyber security awareness and PCI DSS compliance.
These tools will help employees cope with security breach dangers and compliance issues while giving your InfoSec teams measurable KPIs that make their daily work more efficient and effective.
Remember the words of the Red Queen from Lewis Carroll’s “Through the Looking-Glass”? – Call today and let us in CybeReady to help you and your employees run twice as fast by improving the effectiveness of your security training program.
