The Coming Storm: PCI DSS 2.0

Welcome! Please comment and leave me a note telling me what you like and what you'd like to see more of. Sign up to my RSS Feed!

On January 1, 2012 ce, the next version of PCI DSS, 2.0, will come into effect. Are you ready?

The Coming Storm: PCI DSS 2.0

I have always felt that PCI-DSS was no more than a lip service to proper security. Some HP employees will recall me saying that I think that PCI has as much to do with security as a monkey has to do with blueberry juice. I slay myself.

While I do not believe PCI-DSS is prescriptive or a panacea to whatever ails your organization, I have to admit that more money and effort has been spent on security and privacy due to PCI.

On January 1st, the new version of PCI DSS will become effective.  What’s the big deal, you ask?

Some of us had to deal with the 12 current requirements of PCI:

Continue reading


Open Letter to the PCI Council || Suggestions to Improve PCI DSS


Dear Readers,

I sent this letter to the PCI Council three weeks ago to put in my two cents’ about improvement to PCI DSS.   Please let me know what you think:



Security Standards Council,

LLC 401 Edgewater Place Suite 600

Wakefield, MA USA 01880


                                                                                                 Thursday, August 27, 2009


Dear Council Members,

As we are within phase 2 of the PCI Lifecycle, please find below my suggestions to enhance PCI DSS version 1.2.  I would be willing to discuss further.


Suggestion 1: Create a new, technical, attachment to PCI DSS, and discuss elements from current PCI 1, 2, 3, 4, 5, 6, 7, 10 and 11 in it.

Suggestion 2: Create TWO separate and distinct audit functions to PCI — a policy level function and a separate, technical audit function.

Suggestion 3: Rewrite these sections, within the proposed technical section, to clearly delineate that regular change control procedures apply here.

Suggestion 4: Rewrite sections to 2.2.1 et al to allow virtualization and cloud computing, as these are today’s and tomorrow’s computing realties.

Suggestion 5: Decide which rules apply to data preservation.   If that is too hard, require a development of a written program to define what is right for each organization and jurisditction

Suggestion 6: In the technical section (proposed above, #1), define cryptography better. style="">  Include a section on what is and what is not allowed; what are the minimum requirments; how to implement cryptography, and referehce the major laws governing Cryptographic usage.

Suggestion 7: Simply and clearly spell out Section 3.6.6 ("Split knowledge and establishment of dual control of cryptographic keys.").   What do you mean by split knowledge?   What by dual control?

Suggestion 8: Rewrite requirement four   (“") to be more technically correct and include it in the new, recommended (#1) technical section.   Further, I strongly suggest that ALL cardholder data be encrypted, whether at rest or on the move.

Suggestion 9: As I believe that any standard should be as open as possible, open “A passing scan has been performed by a PCI SSC Approved Scan Vendor”   to professionals not necessarily certified by the same body issuing the standard.   I know this is a money-making, or at least –recouping, mechanism for you.   Still, you should accept certifications like SANS’ GIAC-related, and others.



Thank you,

Ariel Silverstone, CISSP