A strange statement popped out at me in an article called Top 10 PCI Compliance Mistakes.

“PCI DSS 2.0 mandates that even if one VM deals with cardholder data, your entire virtual infrastructure must comply with the standard. The challenge is — the wording in PCI DSS on virtualization is vague and it all depends on the interpretation of the auditors,”

First, your entire virtual infrastructure does not have to comply with the standard if just one VM deals with cardholder data. That must be a misquote. I think what was meant was that a VM with cardholder data brings into scope the infrastructure that supports it (e.g. connected to or hosted on, per the Virtualization Guidelines quoted below). An entire virtual infrastructure can obviously include areas that are unrelated and unconnected to the VM in question. Segmentation is possible.

Second, the PCI assessors (not the same as auditor, but the two terms seem to be interchanged now) always interpret regulations. I say PCI DSS is one of the most prescriptive and therefore least vague. Moreover, it does not all depend on interpretation of the assessors. That is like saying food safety all depends on the health inspector. The Security Standards Council (SSC) for example can clarify or otherwise overrule an assessor’s interpretation.

With that in mind, here are a couple relevant sections.

PCI DSS 2.0:

2.2.1.b If virtualization technologies are used, verify that only one primary function is implemented per virtual system component or device.

PCI DSS 2.0 Information Supplement: PCI DSS Virtualization Guidelines

If any virtual component connected to (or hosted on) the hypervisor is in scope for PCI DSS, the hypervisor itself will always be in scope.

I wrote last year a white paper on PCI compliance mistakes specific to virtual environments that you may find useful: 5 Mistakes Auditing Virtual Environments (You Don’t Want to Make)

I also wrote an earlier post on PCI scope errors.

My RSA Conference 2012 Podcast has been posted

Session DAS-302: Message in a Bottle – Finding Hope in a Sea of Security Breach Data

Breach data is now available from a wide variety of sources and perspectives. This session will explore issues like why some industries receive more attention yet see fewer breaches and how to re-frame the insider/outsider threat model given the rise of mules and hybrid attacks.

The CEO of Mocality, an online database in Kenya, has written a detailed report on why he believes his company has caught Google engaging in predatory and fraudulent practices.

It starts with a simple sting operation.

We made some changes to the site:

For visitors from the 41.203.221.138 address, we changed the code to serve slightly different content 10% of the time.

Instead of the real business phone number, we served a number that fed through to our call centre team, where the incoming calls would also be recorded. Our team were briefed to act like the business owners for the calls.

We switched the new code on December 21st.

When we listened to the calls, we were beyond astonished.

Basically when their servers saw access to their database coming from Google in Mountain View they swapped in special phone number that went to the Mocality call center. A call then would come from someone trying to sell a Getting Kenyan Businesses Online (GKBO) website. GKBO was just launched by Google last September.

Mocality says they thought this would be a rogue employee case when they started the investigation but their fear has become far more serious.

I did not expect to find a human-powered, systematic, months-long, fraudulent (falsely claiming to be collaborating with us, and worse) attempt to undermine our business, being perpetrated from call centres on 2 continents.

Google’s response, on Google+, has been vague

We were mortified to learn that a team of people working on a Google project improperly used Mocality’s data and misrepresented our relationship with Mocality to encourage customers to create new websites. We’ve already unreservedly apologised to Mocality. We’re still investigating exactly how this happened, and as soon as we have all the facts, we’ll be taking the appropriate action with the people involved.

Mocality’s CEO has updated his complaint to acknowledge the apology. But he is still asking questions. This might be the toughest one for the giant company to investigate

Apparently, the calls were made by a 3rd party vendor. I can see how this was the case for the activity we saw in Kenya, but the Indian activity seemed to come from Google’s own network. I know (from friends who are Googlers) how preciously that network is guarded. How was a 3rd party given access to it?

It begs the old question of Google complaints against attacks said to originate in China. Although the breaches were blamed on software flaws and human failure, it also was hinted in private that Aurora attacks first were related to weak VPN access controls in remote offices passing through a flat network. Mocality may have pulled a thread that will unravel more serious issues with the Google perimeter…