Where PCI DSS Still Falls Short and How to Improve it
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.
Wed, April 29, 2009
CSO — 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]
PragmatismCurrent 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."
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 AloneDerived 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.
