We just received the drafts of version 3.0 of PCI DSS and PA DSS today as they were officially released to all QSA Companies and Participating Organisations… and we are very excited about it!

pci-qsa.png
We had a chance to have a look at them and even though they are presented as draft versions, we would not be surprised if they were accepted as final documents, hence we are not foreseeing a lot of modifications out of the discussions that will be held during the upcoming PCI DSS Community Meetings next month.

But let’s get to the point, we are glad to be in a position to share with you what we believe are the most important changes coming to the PCI DSS… This list below is certainly not exhaustive but stay tuned and we will come back with some more details on both the new versions of PCI DSS and PA DSS.

Scope of PCI DSS

It is now clear that systems that provide security services, facilitate segmentation or may impact the security of cardholder data are part of the scope. Think about our Active Directory authentication servers that may be outside of the defined Cardholder Data Environment and other security related systems such as the antivirus, etc.

A new requirement has also been introduced to ensure that an inventory of all system components in scope is maintained up to date.

Use of third-party service providers / Outsourcing

This section becomes clearer, highlighting that a service provider should produce sufficient evidence to demonstrate that services applicable to a specific customer have been covered by a PCI DSS assessment. Additional requirements have also been introduced in order to ensure that responsibilities for the various areas of PCI DSS have been clearly defined between customers and service providers.

Encryption and Key Management (section 3)

A lot of clarifications have been introduced in this part of the standard in order to ensure adequate protection of all encryption material. As an example of this, an additional emphasis has been put on testing procedures to specifically enforce things such as secure storage of the keys (HSM, etc.), separation of Key Encrypting Keys and Data Encrypting Keys, and to enforce Split Knowledge and Dual Control of the keys.

Secure Developments (section 6)

Again a lot of clarifications such as developers must be properly trained in secure coding techniques, developing secure applications also applies to applications developed by third parties and more stringent requirement on the use of a Web Application Firewall (WAF).It is also interesting to note that a new requirement will involve specifically protecting attacks again the PAN and SAD when insecurely handled in memory! This last requirement will be considered as best practice for the time being, before becoming mandatory on the 30th June 2015.

Role-base Access Control and User Management (sections 7 & 8)

Regarding access to systems, it is now made clear that each role must be clearly defined with all levels of privilege required for the role. We are also happy to see that an additional emphasis has been put on user IDs managed by vendors and third parties when they access their customer’s environment, yes, those account must be disabled when not in use. Also guidance on how to select strong authentication credentials (such as passwords!) must now be provided to users.

Physical Security… now including POS devices! (section 9)

It is clearly making sense to include the protection of POS devices within the PCI DSS standard and things such as maintaining a list of such devices and training personnel on detecting tampering and substitution have now been included in the standard.

Penetration Testing (section 11)

The PCI community will be glad to know that a proper penetration testing methodology is now required. As per other requirements, it is now mandatory to ensure that those penetration tests follow industry-accepted best practices in order to ensure that their results are actually useful in evaluating the security of an environment. Interestingly, a number of new requirements are now enforcing things such as testing the efficiency of the controls used for segmentation, when segmentation is in place. 

And more..

But again folks, stay tuned to this blog, we are currently reviewing the details of the official drafts and we will be able to provide you with a more precise overview, focusing on the already-compliant entity perspective, as we understand you all are willing to understand and calculate the overhead caused by the incoming transitions. Next week we'll publish downloadable item with the specific content related with the new version PCI DSS 3.0, reported to be released in November 2013.

Marco Borza

Written by Marco Borza

I am the Founder of Advantio.
Technology has been my passion since I was a kid; when I first heard the handshake of an old 300bps modem I realised security would be key in an interconnected world. Since then it has become my passion and primary focus.
The reason why I've started my own business is to make IT Security simple.

Certifications: CISSP / CCSA (Checkpoint) / ITIL Foundations / ACSA (ArcSight)/ Linux+/ PCI-QSA / PA-QSA