Home » Data Protection » PCI and Compliance

In Depth

Where PCI DSS Still Falls Short (and How to Make it Better)

Former CISO and Symantec strategic consulting director Ariel Silverstone goes through PCI DSS line by line and offers suggestions to make it more effective

By Ariel Silverstone, CISSP

Page 3

Confuse the cryptos
Another fine example is the section about cryptography. I applaud the vision to include it here, and highly recommend reading it. Many times over. There are several issues I take with the policy as it stands now:

First, at PCI section 3.5 the statement is made: "Protect cryptographic keys used for encryption of cardholder data against both disclosure and misuse."

Great! Oh, by the way, what ARE cryptographic keys? Which are appropriate to use while protecting cardholder data?

The, there is section 3.6.1: "Generation of strong cryptographic keys."

What defines strong? Is AES strong? Is a-b cipher? What is even LEGAL to use?

Please do not laugh at the last statement. As Phil Zimmerman, the mind behind PGP, will attest, exporting of too-strong-a-key can land U.S. citizenss in very hot water with the federal government.

Suggestion 6: In the technical section, define cryptography better. Include a section on what is and what is not allowed, how to implement cryptography, and the major laws governing Cryptographic usage.

My next comment is tied to a very technically interesting debate. I find it practically hysterical that no two cryptographic experts I spoke with see this section as meaning the same exact thing:

Section 3.6.6: "Split knowledge and establishment of dual control of cryptographic keys."

Allow me to expand a bit: Generally, cryptography involves mathematics. It is a field in which I am no expert, but the wordings here require one to scratch their head.

Just two of the examples of the meaning are:

Take a big cryptographic key and break it in half, for example at block 512, and give each 512 bytes (if 1,024) to a different individual. Or take a big cryptographic key and break and derive two mathematically independent, yet required complement of one another to generate such key.

Of course, taking suggestion 1 literally will make life miserable to any CIO. Taking suggestion 2 is more doable, but still requires understanding of crypto procedures.

Suggestion 7: Simply and clearly spell out what the meaning of this subsection is.

Not Far Enough
One of my least favorite sections is the section on Transmittal Encryption (PCI 4). I find this section to be no more than a window dressing to a real problem. Here's why:

The requirement is titled: "Requirement 4: Encrypt transmission of cardholder data across open, public networks."

Whoa. Houston (or San Mateo, in this case,) we have a problem.

Security professionals will notice two major flaws in this statement:

First, why not encrypt cardholder data in our closed network? Knowing that the majority of breaches occur by insiders, would that not make sense?