A lot has changed since Visa, Mastercard and a few other major international payment card players identified the need for a common data security standard, and PCI DSS was born.
That was 2006, and now the Payment Card Industry Data Security Standard (or just ‘PCI’ to its friends) has evolved to become arguably the most business-critical compliance requirement of them all.
PCI can be frightening. The pragmatic view is that organisations with good corporate governance and an enlightened approach to technology have little to fear. PCI is nothing more than a framework of guidelines for implementing good data security practice. What’s makes it tough is the pace of technological change, both from the perspective of new payment practices, customer preferences etc. and in light of rapidly evolving malware threats and hacking techniques. This means that new versions of the standard emerge quite frequently.
Since 2004, PCI has had to evolve in response to many such changes including:
- Hackers attacking web applications to exploit credit card information
- The rise of m-payments and m-wallets
- The introduction of token-based security authentication to make card payments
- Increasing use of contactless payments
- Development of malware programs designed to steal credit card credentials
Released in April this year, the latest version of PCI DSS is v3.2. As of October 31st 2016, all new compliance validations will need to be made to this version. Here are the most important new developments to be aware of:
You need to act now on SSL encryption
One of the key technologies enshrined within PCI DSS is the encryption of data in transit and data at rest. A popular form of encryption is SSL (Secure Sockets Layer), which even the biggest organisations in the world have been using for years. However, there are some serious security concerns about SSL and early versions of another encryption protocol called TLS (Transport Layer Security). PCI 3.2 sets out a timetable for replacing these by July 2018 at the latest. Until then, any implementations using SSL and/or TLS 1.0 and 1.1 must follow a formal Risk Mitigation and Migration Plan.
Employees with password-only access to cardholder data will be non-compliant
Analysis of the most recent spate of high-profile data breaches has revealed an alarming number perpetrated by weak password protection. Verizon’s 2016 Data Breach Investigations Report puts the figure at 63%. According to PCI 3.2, employees given access to systems containing cardholder data (the PCI parlance is a CDE, or Cardholder Data Environment) should henceforth be equipped with multiple forms of authentication to prove their identity/credentials, rather than just a password. Organisations have until February 2018 to comply with this new measure by implementing a multi-factor authentication (MFA) technology. MFA typically combines elements of what the user knows (i.e. a password, passnumber or qualification answer), what the user has (i.e. a security token, much like those generated by the token devices commonly used in online banking) and what the user is (i.e. a biometric signature such as a fingerprint, voice recognition or retinal scan).
Apply better change management to shut security loopholes before they open
Organisations now need to ensure that any change impacting their CDE is verified to meet ongoing PCI requirements. What this means in practice is better protection against unintended consequences. For example, a new piece of hardware or software is introduced to make order processing more efficient. Under the new regime, the unseen vulnerabilities that this could create are captured by a change control process. This is good data governance in action. It also encourages organisations to treat PCI compliance as a continual process rather than a calendarised obstacle they only need to think about once a year.
There has to be a very good reason to use the full 16-digit card number
A subtle but important change, this goes to the heart of a core data field in cardholder information: the PAN (Primary Account Number). Like much of PCI DSS, it’s common sense. The revised mandate states that: “…any displays of PAN greater than the first six/last four digits… requires a legitimate business need.” Fortunately there are various ways in which erroneous digits can be masked and better, more secure uses of data applied.
PCI is a great example of the industry regulating itself. There are no governmental interventions; a failure to comply breaks no laws. However, any business that receives card payments for its goods and services takes it very seriously indeed. Mess up on PCI and you risk:
- Having the ability to accept card payments taken away from your organisation, wherever in the world it does business
- Amassing significant fines; potentially running into hundreds of thousands of pounds
- Suffering a significant data breach because of lax security measures, and paying out large repair and remediation costs to put it right
- Losing your reputation as a trustworthy brand
The trick with PCI compliance is to focus on continual adherence to the standard rather than as an annual box-ticking exercise. Achieving this is made harder by the reams of technical detail contained in some of the PCI paperwork. These considerations are the domain of qualified technical experts who can advise on the implications for your IT systems, and ensure they keep pace with the evolving market – and threat – landscapes.
Instead, pour the majority of your focus into the people and processes that engage with customer data, and your PCI experience will be a great deal more successful.
