PCI DSS Requirement 9: MSPs Must Trust, and Verify

Don MacVittie
For those eyeing credit card transactions and related data storage as low-hanging fruit waiting to be plucked, requirement 9 of the Payment Card Industry (PCI) Data Security Standard’s 12 requirements to protect card holder data for those businesses that store, handle or transmit said data is looking at you.
PCI DSS requirement 9 is the one that deals with the physical access limits to that data. Controlling who has physical access to servers hosting credit card data is (correctly) seen as a key component of PCI, keeping those who might have ill intent away by affirmative corporate action. This is a simple step with some great technologies available to the average enterprise.
In an MSSP environment it is more difficult, because there are many customers, and physical access limitations have to be controlled more granularly – because rack A may have no PCI data on it, but it might after all. When on-demand containers (or VMs, for that matter) are introduced into the hosting environment, though, which servers have PCI data becomes even more uncertain. Sales records can tell what is where, but unless there are specified zones set down and never violated, it is unlikely an admin knows at the time he opens a cabinet if credit card data is contained within. Then there is the topic of visitors. Technically, every customer that comes to the data center is a visitor — because their systems are not the only ones in the data center.
Most MSSPs deal with this concern by the same standards they would use if every machine had credit card data – controlling access at the data center level, because employees are employees. Customers are logged as visitors straightaway in this scenario, and accompanied into the data center. This is certainly the easiest method of controlling access, and the easiest to maintain — we either trust you around customer systems including those that have credit card data, or we don’t. The problem is that some customers are uncomfortable with this level of compliance, because they don’t know the employee in question enough to trust them.
This is where relationship building is king. Convincing wary prospects that your service is safe because you as an organization are trustworthy is what business development and sales staff do — or at least a part of what they do. Yes, the customer will have a check box with “Independent Audit” next to it — that is a compliance requirement. But they’re going to sign with the MSSP that they checked that box for and that they trust.
An Informed Decision
There are options for snagging those most careful of customers who insist on more granular control, including rack-level access controls, login access controls with segregated servers, etc. The question is whether that segment of the market is worth the expense and effort required. That is a question only an individual service provider can answer, but it is a question worth answering, before a great deal rests upon the answer.
Another piece of this puzzle is that the fallout of a breach at a service provider is more far-reaching than the effects of a breach at a single corporation. Having generalized access and then having someone take advantage of it can undermine …
- Page 1
- Page 2