« On Response | Main | The Sky is Falling on SCADA! »

September 03, 2008



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

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.

The comments to this entry are closed.

  • Burton Group Free Resources Stay Connected Stay Connected Stay Connected Stay Connected

Blog powered by Typepad