The Payment Card Industry Data Security Standard (PCI DSS) is a living set of requirements, and as new security threats emerge seemingly every day, the Standard continually evolves to meet the demands of the ever-changing cybersecurity landscape. When the PCI SSC introduced PCI DSS version 3.2.1 on October 31, 2016, it gave merchants fifteen months to put the new requirements into effect, considering them as best practice until they became effective on February 1, 2018. Now that that has occurred, every merchant accepting credit card payments must now comply with all of the tenets in version 3.2.1.
In a previous post, we wrote on a new mandatory obligation for service providers that was added to the PCI DSS, requiring them to regularly conduct penetration testing on their networks. The update also details the requirements for creating, maintaining and testing proper network segmentation practices. Some people may have been caught by surprise by that one. However, that was just one of four updated requirements affecting service providers. In fact, within the 12 core requirements of the PCI DSS, there are five new sub-requirements for service providers. The affected requirements include requirement 3, 10, 11 (previously discussed) and 12.
Of course, there are other changes to the PCI DSS that are not limited to service providers. These other changes will affect everyone that accepts or processes payment card transactions and include new sub-requirements to ensure multi-factor authentication is used for all non-console administrative access and all remote access in the cardholder data environment and the removal of Secure Sockets Layer (SSL) /early Transport Layer Security (TLS) as a security control. We will help you explore these in a future article.
As a service provider, we first wanted to explore these changes and share how we have met or exceeded these standards in our operations, so that our customers don’t have to concern themselves worrying about how we handle their sensitive payment card data.
Four Key PCI DSS Updates for Service Providers
First, the new requirement for service providers in Standard 3 (3.5.1) instructs that they maintain a documented description of the cryptographic architecture. This is of fundamental importance, as the cryptography used by a number of providers has been found to be inadequate for protecting payment card data. This means that the encryption can be broken by modern hacking methodology. QSAs will be looking at the key strength of all solutions-based cryptography and identifying the methodology for managing the encryption keys. At Semafone, we follow industry best practice and use some of the strongest modern encryption methods.
Second, within requirement 8 of the PCI DSS, new requirement for service providers in 10.8, 10.8.1 looks to ensure that any failures of critical security control systems must be documented and shared with a QSA and that service providers must have a security team respond to any failures in a timely manner.
While we have never had a failure of our critical controls, we do have multiple systems in place for identifying, investigating and addressing any vulnerabilities or inadequate controls. In addition, Semafone has gone further than just planning – we have also taken the step of having our data centre certified under the ISO 27001 standard. This important standard requires that we systematically examine our security risks; implement a coherent and comprehensive suite of security controls; and adopt an overarching management process to ensure that the controls continue to meet our security needs on an ongoing basis. This has prepared us well for complying with the requirements of PCI DSS 10.8 and 10.8.1.
We have already addressed how we meet and exceed the new standards in requirement 126.96.36.199 for penetration testing on segmentation controls. We highly recommend more advanced penetration testing for any organisation that handles payment card transactions.
Next, new requirement 12.4 connects executive staff to the responsibilities for the protection of cardholder data and a PCI DSS compliance programme. The requirement maintains that the executive team keep a direct line of communication with the compliance team, and that executives understand PCI DSS compliance. At Semafone we have deep experience in call and contact centre and compliance, which has been instrumental in not only understanding, but in leading our own compliance efforts.
Lastly, in new requirement 12.11, 12.11.1, the PCI Council is aiming to ensure personnel are up to date, trained and accountable for compliance activities. Service providers must perform quarterly reviews to confirm personnel are following security policies and operational procedures. While this may be a challenge for service providers only tangentially associated with payment card security, because Semafone was founded to solve payment card challenges in contact centres specifically, the Standards, payment card security and the sanctity of personally identifiable information (PII) are at the very core of our foundation. Our old-timers are payment security stalwarts, and new hires to Semafone are immersed in a culture that holds data privacy and information security paramount to our success.
Why wait to put PCI DSS updates into practice?
Generally, the Standards have always been a collection of common sense, best practices. We feel that these new changes represent a continuation of that philosophy. We hope that these new requirements help to increase the security of other service providers, as many recent notable data breaches occurred by attacking a vulnerable supply chain. We are taking these new requirements seriously and hope to encourage any organisation within the payment process to review and implement the new requirements as quickly as possible. While the deadline for implementing these new requirements was 1 February 2018, if you haven’t yet implemented, it is truly better to do it late than never. So, why wait?