PCI DSS Requirement 9: MSPs Must Trust, and Verify

By Don MacVittie

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 …

… several customer businesses and make the service providers’ future untenable as word spreads. Add to this that there are a fair number of companies in the granular security PCI compliance space already, and it’s not an easy topic to settle.

Theoretically, since customer data is on containers or VMs that are above the hardware, systems access to racks shouldn’t pose a particular threat unless the user has access to login credentials for the VM/container. But we all know that, in the end, the data is stored on physical disks that the admin does have access to if they are logged into the hardware. Hence the reason physical access control of one kind or another is still required.

If your organization hasn’t considered the options in a while, it is well worth having the discussion. I’m not here to give you answers, only to suggest you consider it (or possibly reconsider it), and decide what makes the most sense for your organization.

Don MacVittie is the founder of Ingrained Technology, and has worked in every facet of IT from entry-level programmer to CIO, from network operations to storage and database analysis. He currently works in DevOps while running a successful technical evangelism consultancy. Don has contributed to projects his company worked on for organizations in DevOps, DevOps leadership, data protection, network security, global file systems and non-IP communications spaces, along with several international publications and PR firms. His MSSP background is in communications and utilities. Follow him on LinkedIn or Twitter @dmacvittie.