PCI V1.2, a good start but still not enough

Blogger: Randall Gamby

Two weeks ago the PCI Security Standards Council released the preliminary details of the PCI Data Security Standard (DSS) V1.2 that’s due out in October.  While many Analysts and Reporters have already written on the topic (I’ll be releasing an extensive update on Burton Group’s PCI coverage around the October release date), they really haven’t commented on what’s still not been addressed by the standard for enterprises still working on attaining compliance.

While I applaud the PCI Security Standards Council in further clarifying and adjusting the standard, a lot of work still needs to be done.  I receive about one or two PCI questions a week from our clients and they seem to revolve around a couple of topics I’ve yet to see addressed:

• Guidelines for selecting a Qualified Security Assessor (QSA) – while there are a large number of QSA organizations listed on the PCI Security Standards Council web site; they can’t really recommend a particular QSA for an individual organization.  This leads a lot of organizations to struggle with determining what criteria they should use in selecting a QSA for their certification.
• The role of the QSA – organizations are also still trying to understand the role of a QSA.  Should they get a QSA involved in the gap and remediation process in advance of certification?  If so, should it be the same QSA that will do their certification (knowing there’s a risk that the QSA will be pre-disposed to only care about certain vulnerabilities)?
• Industry-specific best practices – while each organization may have different infrastructures, in general, most industries try to be consistent with the major functions they perform.  So are credit card transactions handled differently between say, a major retailer with 10,000 POS systems and an insurance company that has hundreds of independent agents receiving remittances? Probably, so what are best practices around these industry-specific configurations?
• Virtualized environments – while the PCI Security Standards Council recognizes that some organizations have moved to virtual services for consolidation and management, the DSS really doesn’t provide guidelines for QSAs to evaluate and certify these environments.
• Monitoring and audit – while the PCI DSS recommends minimum timeframes for scanning, doing pen tests, etc. what are the real levels of monitoring and audit needed for ensuring security?  With the Hannaford and Okemo breaches that occurred (both where PCI compliant), neither discovered the problem until months after the breaches had happened.  So identifying what should be scanned and tested and if some of this should be on a continuous basis still requires refinement.
• PCI as part of an overall security model – what are the best practices around merging PCI security requirements into an enterprise’s overall security model?  Should it be maintained separately? Should some components be integrated with similar security mechanisms?  Should PCI be at the top of the security model and other configurations be based upon its requirements?  There are really no answers coming forth on this topic and the other question is where will they come from? Surely enterprises won’t expect the PCI Security Standards Council to tell them how to run their security services.

I will be providing Burton Group’s perspective on most of these questions in my upcoming report, but rather than relying on third parties to resolve these, I’d hope that the PCI Security Standards Council will be able to continue to provide answers to the questions they can in future updates, and releases, of the PCI DSS.

Comments

[terri]

Do you have any suggestions on questions to ask a QSA to help in selecting one?
Thanks.

[Randall Gamby]

Hi Terri,

Sorry for the delayed response but I wanted to make sure this was going to be completed in time... I've recorded a podcast (free on our website) addressing your question which allows me to go in more detail than replying to the blog. Look for it soon on the Burton Group website.

[Andre Gironda]

Great points. Yet nothing revealing -- just the facts about your own gap analysis of PCI-DSS 1.2.

In terms of choosing which QSAC, this depends primarily on two factors: proximity to your business (a local QSA might be able to more easily dedicate more resources), and size/culture of their company compared to your own. If there are other factors, I'd like to help clients use them while considering their QSAC.

I'm not convinced of the usefulness of a "one-stop PCI shop" when the industry is still emerging. It's best to get as diverse outside help as possible for both compliance and compliance-readiness. Choosing an organization to help with gap analysis and other readiness initiatives is much more important than the QSA process itself to most organizations that I know.

Many merchants use these compliance-readiness strategy consulting companies to help choose a QSAC. This is the business of application security service companies that are well under-reported by Gartner, Burton Group, and Forrester.

There is no such thing as best-practices yet. There are compliance-specified controls (which could have alternate controls) and compensating controls. It's really up to the QSA to decide how compensating controls are used. In the past, compensating controls have been used to keep some organizations from out-of-compliance, but I think forward-looking "best-in-class" organizations will use compensating controls as differentiators to lower legal, insurance, and paper-compliance costs.

To speak to your question on virtualization, I think it's been set-in-stone that it's allowed as long as the virtual environment is fully checked. I have heard that host systems and administrative portals that can access the virtual environments have not been assessed in the past, but I think it's in the best interest that all host system and monitoring adheres to the same policy as the virtualized systems.

For Monitoring/Audit -- isn't this well-defined in 10.6? Scanning and pen-testing also seems well-defined. I think the problem isn't that these aren't defined -- it's that they aren't good enough. Scanning vendors such as Rapid7 and monitoring vendors such as ArcSight may need to take some blame for these issues. However, intelligent adversaries are far more capable than these products (or competing products) will allow for.

PCI-DSS makes no mandate for the real-time monitoring (or any monitoring outside of an alternate control in 6.6) of application security. There is no requirement to establish a central authority for application security. The measurements for expertise in risk assessment are based on faulty premises such as non-real-world testing environments.

Your identified strategic problems speak volumes, but I think PCI-DSS is especially weak at the operational and tactical levels. I would say more about PCI-DSS 1.2, but I'll wait until the final release before I say anything.