There's no doubt that the mere existence of a uniform policy -- adopted, recommended and even mandated by such firm rivals as American Express, Visa and MasterCard -- is a huge step forward.
Before the existence of PCI DSS, it was hard to find two banks that agreed on the same standards, or a merchant that could comply with (at times contradictory) requirements by the major payment industry players.
PCI does make things better, easier, and more understandable. Unfortunately, as is commonly the case on these electronic shores, it does the minimum needed -- and sometimes not even that -- in its approach.
I will discuss some of these requirements here, and how I see the failing cumulates in the document titled "PCI SSC New Self-Assessment Questionnaire (SAQ)." This column aims to seek ways to improve PCI and is meant as a suggestion to practitioners and to the PCI bodies. Where ideas are good, credit goes to my mentors in the industry, failures are wholly mine. [For other viewpoints, see PCI Shrugged: Debunking Criticisms of PCI DSS and Lightening the PCI Load: Solutions to Reduce PCI Scope]
Pragmatism
Current supporters of PCI hail it as a pragmatic standard and as a wakeup call. I could not agree more with the alarm-button function, and could not agree less about its pragmatism.
PCI DSS today is similar in both appearance and function to the SAS 70 (type 1) standard. Who can fail an audit when one of its tenets is that the audited organization gets to define its scope? Similarly, PCI DSS today gets away with the lack of definition of effected "systems" and lays within itself (section 12.1) the demand that a security policy be written which "addresses all PCI DSS requirements."
Also see an in-depth look at SAS70 Type 1
While many sections of PCI DSS do take the needed steps (for example, in defining firewall requirements), I believe they could, and should, go a step further. I believe PCI should tie down the concept of the "dirty" system (system that touches cardholder data) and "dirty networks."
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 audit functions to PCI -- a policy level function and a separate, technical audit function.
Real World and Stand Alone
Derived from what probably has been a desire to limit scope, and a reluctance to "step on toes," the current PCI DSS standard reads like a stand-alone wish list. A strict interpretation of PCI DSS today will almost necessitate the need to create separate environments: One for card-holder related data and a separate one for everything else.
Look for example at PCI DSS requirement 6.1: "Ensure that all system components and software have the latest vendor-supplied security patches installed. Install critical security patches within one month of release."
Why? What is the rationale? Why not three days? Why not 30 months? Why not "after exhaustive iterative testing?" Why would it be the same for a company with one server as it is for one with one thousand?
Suggestion 3: Rewrite these sections, within the proposed technical section, to clearly delineate that regular change control procedures apply here.
Making matters worse is section 2.2.1: "Implement only one primary function per server."
Not only do words like that hearken back to the old concept of "one mainframe, one mission" but it's also simply un-implantable.
Not that this should tip the scale, but every major operating system vendor touts how flexible and comprehensive the product offering for their server version is. Every CIO is not only touting the benefits of system flexibility for their server, but is probably immersed now in the magical ability to use virtualization tools like VMWare, Xen and others to squeeze further performance and better return on investment (ROI) in order to comply with funding guidelines, business reality and environmental costs. Further, for tools like "Web server" or "Exchange" (what is exactly their primary function?) dogma that is not practical will only serve to create confusion.
I am not aware of any research that proved that one function per server reduces or increases its security exposure. While this makes sense on paper, it is a blanket statement without cover. The current belief, which is debated, is that most security breaches occur by trusted people. This fact will not be changed by the number or type of functionality a server has.
Suggestion 4: Rewrite the relevant sections to adhere to today's and tomorrow's computing realties.
How (not) to say anything
The crafters and contributors of the current PCI practice took a bold step. They approached the perennial mine-field of data retention and included a section (PCI 3) which discusses data retention. Unfortunately, while starting with the well-lauded "Keep cardholder data storage to a minimum," that same section continues with the ever-so-ambiguous "Limit storage amount and retention time to that which is required for business, legal, and/or regulatory purposes."
Fine. You took a stand. You drew a line in the sand. Why not cross the threshold?
Suggestion 5: Since we are talking about credit-card data, either (a) tell us which rules apply (hard, but can be done) or (b) require a development of a program to define what is right for each organization.
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?
Second, why the term "public" here? I understand the applicability to the Internet, but what about wireless access point connecting wirelessly to a company owned laptop? This network is neither open nor public (we hope), and this example is incorporated in section 4.1, but the very definition here seems faulty.
Now please look at the further clarification to requirement 4, PCI 4.2: "Never send unencrypted PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat).
This requirement is too unclear and misleading. For example, why is it OK to send unencrypted PANs by other technologies likes FTP or automated tools? Further, why is it ok to send masked PANs via messaging tools? Does the second part not imply that one can send encrypted PANs and the decryption key via messaging tools? Here is my suggestion:
Suggestion 8: Rewrite requirement four to be more technically correct and include it in the new, recommend technical section.
Self Importance
A smarter man than I once said, "When an organization or organism grows complex enough, one of its goals will be to self-perpetuate". In the case of PCI DSS that led to statements like:
"A passing scan has been performed by a PCI SSC Approved Scan Vendor"
While I most certainly understand a need for a minimum bar, why not go with an industry-wide bar, such as the SANS GIAC GWAPT, or e-Council's CEH or LPT? For that matter, what is the minimum required tools and effort level to perform a scan?
Suggestion 9: As I believe that any standard should be as open as possible, open it to professionals not necessarily certified by the same body issuing the standard.
Checklists
As I promised, I see one of the biggest drawbacks to current PCI DSS guidelines in its overly simplistic Self-Assessment Form. While I understand that the desire is to reach as many non-technical people as possible, I believe a major disservice is done here. Security is NOT a check list. Audit, while sometimes involves a checklist, should be done with eyes wide open.
Currently, I believe it is possible to be 100 percent PCI compliant and have no real security. This is a term that others in the industry relate to as a "security theater." This compliancy achievement is a problem, and certainly not what the authors and contributors to the PCI DSS intended.
Conclusion
Quite a few more technical security points come up in any PCI DSS review. I do not intend for this paper to be a comprehensive technical discussion of PCI DSS.
While the PCI DSS is certainly a major step in the right direction, it is still anemic. I believe it needs to be clarified, broken into technical and non-technical parts, and generally be better discussed and reviewed before. I applaud the PCI contributors for their efforts. I am sure we all desire for PCI DSS to can become the tool we want -- a practical and useful Standard in payment industry protection. Let us have a real debate, and not wait for September 2010 to introduce a new version.
Ariel Silverstone is a former director of strategic consulting at Symantec and CISO at Temple University.