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 2

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.