The 1st of January 2015 was the date the current version of the PCI DSS came into effect. The only version to comply with now is version 3. In this blog I will outline the main challenges organisations will face when implementing this new version of the PCI DSS.
There are a number of changes from version 2 to 3. In fact there were 98 changes to version 2, with 74 of those being clarifications, 19 evolving requirements and five additional guidance notes. 18 new requirements were added to version 3.
With the new requirements added it is envisaged that the organisations will encounter the following challenges.
Additional guidance was included in version 3 to help organisations implement PCI DSS as business as usual (BAU). The message in this new section is for organisations to ensure their compliance between assessments. The section suggests a framework / strategy of how this can be achieved through six examples.
Figure 1 – Implementing PCI DSS into BAU
Organisations are now expected to show how the PCI DSS scope is managed. This means there will need to be a method to show where Cardholder Data (CHD) is held and where it is not. For example using a tool like FScout to scan both the in-scope and out-of-scope segments of the network would provide the necessary evidence to show scope management.
Pivotal to implementing and complying with PCI DSS is the need to have a comprehensive and accurate inventory of assets owned and controlled by the organisation. As the old security saying goes, "What do you want to protect?" - If you don't know what you have, you will not be able to implement an effective strategy to protect it. Having accurately listed all your assets, you will be better placed to conduct meaningful and value-adding risk assessments which is not only a pre-requisite for PCI compliance but also the foundation of any IT security strategy.
Other challenging areas in version 3 are:
- Organisations need to now evaluate evolving malware threats for any system not considered to be commonly affected by malware. For example, Linux and Mac systems should be considered for anti-malware controls.
- The need to ensure coding practices, development policies and procedures address broken authentication and session management. This may need recoding and/or review of web application. This is a best practice until 1st July, 2015 when it becomes mandatory.
- Service providers with remote access to customer networks must use separate credentials for each customer (effective 1st July, 2015).
- Protect devices from tampering and substitution (effective 1st July, 2015). This requirement includes maintaining a list of all these devices, physically inspecting the devices and training personnel on how to protect the devices. This requirement will mostly impact, for example, retail/merchants organisations with physical shops with PED and PDQ devices.
- New requirement effective 1st July, 2015, that requires the implementation of an industry recognised methodology for penetration testing. Further, there is now a requirement to ensure penetration testing findings are remediated and retested to verify corrections to findings AND there is now the need to conduct penetration tests to verify segmentation methods
- A process to respond to alerts generated by change-detection mechanisms
- Risk assessments must be conducted at least annually and after significant changes
- Organisations must now maintain information about which PCI DSS requirements are managed by each Service Provider and those which are managed by the organisation.
- And finally, effective from 1st July, 2015, Services Providers must acknowledge in writing to their customers that they are responsible for the security of any CHD they store, process or transmit on-behalf their customers.
The above is by no means the complete changes or all the challenges organisations will face when implementing PCI DSS version 3 but it does outline the significant challenge areas that may require additional steps to be taken by most organisations.