In January 2015, PCI DSS 3.0 was brought into effect in order to help bring about vital changes but many sources argue that it didn’t take encryption far enough.

Is this true? Maytech takes a look at what changes 3.0 has brought with it and whether it will create a significant impact.

What’s Changed with PCI DSS 3.0

In layman’s terms, loads. But not every change made is going to mark a significant change. A brief look at the changes between PCI DSS 2.0 and 3.0 shows that there are three change types – clarification, additional guidance and evolving requirements.

Clarification and additional guidance are simply changes to the wording, explanation, definition or instruction that makes the standards more understandable and clear. This is where the bulk of the changes lie, in little changes that tag on certain amendments, but there are a fair few ‘evolving requirements’, including:

  • Requirement 1.1.3 for a current diagram showing cardholder data flows
  • Maintaining an inventory of system components in the scope of PCI DSS to support development of configuration standards
  • Evaluation of evolving malware threats to any systems not considered to be commonly affected by malicious software
  • Ensuring that anti-virus solutions are actively running and cannot be disabled or altered by users unless specifically authorised by management on a per-case basis
  • Introduction of coding practices to protect against broken authentication and session management
  • Combined minimum password complexity and strength requirements into a single requirement with increased flexibility for alternatives meeting the equivalent complexity and strength
  • Service providers with remote access to customer premises must use unique authentication credentials for each customer
  • Where other authentication mechanisms are used – physical or logical security tokens, cards or certificates – they must be linked to an individual account that can only be used by the intended user with the mechanism
  • Requirement to control physical access to sensitive areas for onsite personal, including a process to authorise access which is revoked immediately upon termination
  • More to be done to protect devices that capture payment card data via direct physical interaction
  • Introduction of penetration testing

What Does This All Mean?

In short, a lot has been done in order to bolster the security measures used when gathering, handling and transferring payment information. The fact that the physical devices have been recognised as a weak point is good, as often these are left unattended and can be an easy target for criminals.

There has also been motions put in place to ensure that the software used to handle this information is properly protected and well suited to the task at hand. By enhancing the security measures used to gain access to the systems the data is better protected as it is harder for criminals to hack into the system.

However, the general consensus is right and not enough measures have been put in place to ensure that the data is properly encrypted and stored on PCI hosted solutions. But there is very little mention of encryption – in fact it is only mentioned once and that is to “encrypt transmission of cardholder data across open, public networks.”

How Much of an Improvement is Version 3.0?

Don’t get us wrong, 3.0 shows vast improvement upon previous versions as it includes many more guidelines surrounding security rather than focusing on best practices. This will mean that many vendors will have to make large-scale changes to their current practices in order to stay PCI compliant.

But compliance in this instance doesn’t fully translate to data security, but rather looks at the potential risk. While this security-led approach is a step in the right direction, it simply does not go far enough in terms of forcing the encryption of data and the use of secured data storage platforms.

Further Improvements Needed

One of the biggest changes to be made was a simple ‘clarification’ to item 3.4.1 which stated:

Logical access for disk encryption must be managed separately and independently of the native operating system authentication and access control mechanisms, and that decryption keys must not be associated with user accounts.

This means that any vendor using an encryption software that relied on an operating system for authentication would no longer be PCI compliant. The system needs to be able to work independently away from the OS in order to achieve compliance.

While this is a great step towards the sort of encryption that needs to be widely used, it simply isn’t enough and more needs to be done. Even vital information surrounding the encryption is weak at the moment, for example:

  • Where are the encryption keys stored?
  • Who has access?
  • How are the encryption keys protected?

These are all very important points that are not touched upon at all in version 3.0. Even with the most secure encryptions in place, if there is easy access to the keys then the whole system is rendered useless.

In updated versions, it is hoped that PCI starts to become aligned with basic principles that are already in place such as the ISO/IEC 27040:2015. This provides technical guidance on risk mitigation and planning, design, documentation and implementation of data storage security.

With these types of standards in place there will be far more guidelines in place regarding IT security, ensuring that the correct encryption software, PCI hosted solutions and data transfer system are being used. At Maytech we have a range of PCI compliant hosting and data transfer systems that allow you to safely, securely and quickly handle payment data in accordance to the latest guidelines in Version 3.0. Find out more about the solutions that we provide by getting in touch today or starting your free trial.

 

Read More: PCI Compliant File Sharing: Essential Requirements & Effective Compliance Strategies