4

This is connection to my previous question: Shared Database and PCI Compliance

However, this question relates to the requirement "Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers".

If we are a service provider, is there any requirement (or recommendation) to:

  • Keep the Shared Database separate per client? i.e. a separate instance of the DB service running on a different port.
  • Have separate processes on our service where we decrypt data that may contain CHD? e.g. for our first client we use port 443, for our second client we use port 444, etc.

We do not store or process card data, we only decrypt it, analyse it and then re encrypt it for transmission. The Shared Database contains configuration information for certain parameters for our service, but it is not possible for a client to configure it in such a way that it will affect other clients.

Also, the processes for our service do not run client code. It is our own application. I mention this as the A.1.1 states:

A.1.1 Ensure that each entity only runs processes that have access to that entity’s cardholder data environment.

Although the guidance states:

If a merchant or service provider is allowed to run their own applications on the shared server, these should run with the user ID of the merchant or service provider, rather than as a privileged user

As our applications run only our code (not any code by our clients), how does this affect the interpretation of A.1.1? The definition in the Testing Procedure is:

If a shared hosting provider allows entities (for example, merchants or service providers) to run their own applications, verify these application processes run using the unique ID of the entity.

and my interpretation was that the running code was not a merchant's "own application", however our QSA believes that this requirement applies.

My question comprises of the two closely related questions above (in bold) relating to how much separation is required.

Improve this question
3
  • Reading the above it sounds like the business is a service provider performing data analysis on cardholder data (and perhaps other data) received from third parties. It sounds like the business is a service provider but is not a shared hosting provider. It really doesn't sound like Appendix A of the standard is applicable.
    – AndyMac
    Dec 2, 2014 at 15:28
  • @AndyMac: Depending on the state of the system and the analysed data we may want to redirect traffic to pages served from our system. There won't be any card processing or storage on these pages though, but it could be this that is defining the system as a "hosting provider" even though at that point it is not processing, transmitting or storing card data.
    – SilverlightFox
    Dec 2, 2014 at 15:59
  • Even if you're serving Hosted Payment Pages, you'd still be a service provider. Being a Shared Hosting Provider would mean you are providing shared physical infrastructure to clients upon which they and other clients handling cardholder data are hosted. i.e. physical and virtual resources are shared between clients and you provide this infrastructure and host their applications and systems which handle cardholder data. It doesn't sounds like this is what you're doing.
    – AndyMac
    Dec 2, 2014 at 16:02

2 Answers 2

Reset to default
1
+50

I'm agreeing with AndyMac that you are in fact not a shared hosting provider, you are just offering a platform, so I think your QSA is wrong. So what do you do if you are not sure about his opinion? Then you get a second opinion where you explain your concerns! Ensure that you challenge your QSA first to explain why he believes you are a shared hosting provider even though you aren't running code of your clients but your own.

But remember that PCI-DSS is about implementing a security baseline. Now you can make it yourself really complex and start building complex network segragation and implementing seperate processes etc... In my opionion, what you should do is use a system where you template an OS with your application + seperate database and just deploy one per client in an isolated trust zone. Then you can forward from a dedicated IP on a per port basis or if you run it through a VPN only provide 1-to-1 connectivity for a certain IP address based on the login credentials.

Improve this answer
1

Let's break this down to a logical view of what you state you are doing without getting lost in the weeds on the definition of a service provider, hosting provider, Tier 1, Tier 2, etc.. You state:

"We do not store or process card data, we only decrypt it, analyse it and then re encrypt it for transmission."

While you may not be a PROCESSOR you are putting the data through a process (decrypting, then analyzing, then encrypting). How does this process work. For example, how does data get to you, so you could perform what it is you need to do?

What PCI is primarily looking for is proof that when data is PROCESSED (goes from one place to another, whether or not it is stored) it is done so in a secure fashion. When you mention "we only decrypt it, analyze it" a function (process) is happening somewhere on a system. How does this occur, does data get stored somewhere? The reality is, it would have to. Whether it's in memory, in a temporary file, at some point you need the decrypted output (CC data) in order to analyze it. Even if for a split second, you need to document what occurs, how it occurs, and how this is segmented from possibly being disclosed.

Improve this answer
2
  • Thanks. This question states that storage in memory does not count as storage from a PCI point of view. To answer your other questions, the data gets to us directly from the card holder. So if our client Bob's Widgets uses our service, the card data flow is Customer -> Our Service --> Bob's Widgets. We do not store any CHD, just specific state information regarding the HTTP connection that is either inherent to the TCP connection, or under our control.
    – SilverlightFox
    Dec 6, 2014 at 11:45
  • Then your goal would be to document the process(es) you go through in detail illustrating it step by step. If you look at the page you linked, AJ Henderson's answer summarizes it for you. You keep stating you don't store, but when you run a process against data it gets stored as an ARGV even if only for a temporary time. You need to document what occurs to demonstrate that nothing is PERMANENTLY on your systems. You did state you decrypt, do something, then re-encrypt. Data is stored no matter how you cut it (even if its temporary)
    – munkeyoto
    Dec 7, 2014 at 0:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .