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 4

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.