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.