The following blog post outlining PCI DSS V3 in a nutshell has been submitted by two students from Glasgow Caledonian University. This is part of our approach to work closely with local universities to provide vital hands on experience for undergraduates.
What is PCI DSS and why is it required?
As many of you will be aware PCI DSS has recently been updated and a new version released. This article reviews the biggest changes in PCI DSS from version 2.0 to version 3.0 and is aimed at providing a brief overview of the changes of which you may want to be aware.
PCI DSS is the card industry’s standards for securing card data (see our previous blog here for more detail) and is applied to all entities involved in payment card processing (e.g. banks, supermarkets, retailers) and those who store, process or transmit cardholder data and/or sensitive authentication data. Payment card data has long been the target of attackers aiming to steal that information and PCI DSS introduces measures to defend against those attacks. Whilst PCI DSS is nothing new to those that process or deal with that data, the online threat landscape is rapidly evolving. The standards that protect against those attacks therefore need to keep pace with the threats, environments and organisations they are applied to. Version 3 has been released to encourage and enhance cardholder data security and promote consistent data security measures worldwide.
How v3 differs from v2 in order to address risks
In response to the developing threat landscape and driven by inputs from industry, PCI DSS has been revised to reflect methods of enhancing security and addressing perceived weaknesses in the standards. These include a lack of education and awareness, weak passwords and authentication, third-party security challenges, slow self-detection, malware, and inconsistency in assessments. The revisions and additions defined in version 3.0 are designed to assist organisations in adopting a proactive approach to the protection of cardholder data, focusing on the adoption of security mechanisms rather than promoting a compliance based approach.
Key Differences
While the twelve core security areas remain unaltered, there have been several new additions and implementation strategies devised for sub-requirements, of which we will highlight some of the main differences:
Requirement 1.1.3
To assist and ensure organisations understand and monitor the scope of their environment and identify the potential attack points where data could be breached, there is a new requirement for companies to devise an illustrative diagram which depicts how cardholder data is stored, processed, or transmitted across networks, between individual systems and devices. However, this valuable information (e.g. network layout, hardware and software employed, and security mechanisms in place) could be potentially employed maliciously and assist in the development of attack vectors if such diagrams became available. As such, organisations will need to take steps to ensure that the correct level of protection is afforded to these new diagrams.
Requirement 2.4
Similar to the previous requirement, this places an expectation on businesses to maintain an inventory of system components that impact PCI DSS in order to support the development of configuration standards. As this inventory is designed to provide a detailed list of all hardware and software components including descriptions of their function and use, there is a potential security impact if this information was to become available.
Requirement 5.1.2
In a reactive development to malicious threats, there is now a requirement to evaluate evolving malware threats for systems that presently do not require anti-virus protection. It is envisaged that this will raise awareness and encourage the monitoring of the current threat landscape.
Requirement 6.5.10
This focuses on broken authentication and session management by examining software development policies, procedures and coding techniques. These have been devised as a means of preventing unauthorised individuals from compromising legitimate account credentials and session tokens that would allow session hijacking.
Requirement 9.9.[1-3]
By concentrating on the physical protection of devices that have direct interaction with card data, this requirement promotes security awareness of the potential for fraudulent activity, tampering, substitution and identification of suspicious behaviour. This in turn places an emphasis on training and education.
Requirement 11.1.[1-2]
The increasing threat of rogue access points, potentially leading to man in the middle attacks, provides a new type of threat. To proactively minimise the exposure of the Cardholder Data Environment (CDE) and secure data transmission, this requirement aims to address this potential area of exploitation through the verification of trusted access points. Implementing an incident response procedure in the event unauthorised wireless access points are detected is also a key part of this requirement.
What is the impact of implementing PCI DSS?
A review of the requirements has highlighted that the transition and implementation of the new set of expectations will have a significant financial impact, particularly on SMEs.
The requirements that are likely to cause the greater financial burden are:
Requirement 5.3
In response to the ever changing threat landscape, there is now the requirement for companies to ensure they are actively implementing the most recent anti-virus solutions. This will have a significant financial implication as companies will have to invest in effective anti-virus software and ensure hardware has the capability to run the associated processes.
Requirement 11.3
Identifying that security mechanisms have to be tested to ensure effectiveness, there is now the requirement to implement a methodology for penetration testing to actively identify the weaknesses and threats within a system. For SMEs with limited or no in-house security team, this will require external assistance.
Requirement 11.3.3
This requirement reinforces that it is not only essential to implement penetration testing, but the outputs must have an active response. For example, identified vulnerabilities must be resolved, with confirmation achieved through retesting. This demonstrates a willingness by the company to improve their security through remediation, thus ensuring that their systems will be kept up to date and as secure as possible to reduce the risk of a breach.
Requirement 12.2
It has now become mandatory for companies to actively identify their assets and their associated threats and vulnerabilities, through the implementation of risk assessment exercises (e.g. ISO 27005, OCTAVE, etc.) both annually and at points of significant change. This encourages companies to adopt a more proactive stance rather than a reactive response to attacks. However, it should be questioned within a fast evolving landscape whether an annual approach to risk assessment is sufficient.
Clarification of PCI DSS services from providers is stated in the following two requirements:
Requirement 12.8.5
To establish transparency and responsibility between entities (e.g. service providers and organisations) this requirement dictates that each entity identifies their role within the process and that this is efficiently managed. This translates to assurance and awareness of the provider’s compliance status and whether their requirements comply with that of your organisation.
Requirement 12.9
In an extension of 12.8.5, there is also an expectation for the service provider to provide written communication informing their customers of the expectations that are to be placed on them and their personal responsibility, as part of the new `shared responsibility’ theme. The confirmation of the service provider’s responsibilities creates a consistent level of understanding between provider and customer by demonstrating their commitment and transparency to maintaining proper security of cardholder data that it obtains from its clients.
Recognising the scale of change between the different versions, some sub-requirements will be considered as best practices only until the 1st of July 2015, with version 2.0 remaining in operation until December 31st 2014 to allow for companies to plan ahead for a lengthy transition period in order to effectively adapt.
Considerations & Conclusion
This blog entry has highlighted only some of the perceived differences between the PCI DSS version 2.0 and 3.0. In doing so we have established that the adoption of the stronger framework will have a significant impact with many challenges for companies to overcome, especially as there has been a shift from ambiguous terms such as “should” towards the more definitive “must” with regard to the requirements. However, while some requirements are still debatable with weaknesses still existing, improvements have been established, such as unique authentication and promoting awareness of device tampering and substitution. Furthermore, additional guidance has been provided within the documentation to establish understanding of the different technologies at a foundation level.
By Ross Bingham & Steven MacFarlane
