PCI-DSS - one application per server?

Question

How do I interpret the 2.2.1 point for PCI-DSS? Is "application server" 'one primary function' or does it need to be "program x server", "program y server" etc?

I have a collection of applications that run server side within my environment. Some of these interact indirectly with the application that the cardholder data resides in, others not. These applications also have varying groups roles, and permissions assigned within them and serve different departments.

2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)

For example:

A database, which needs to have strong security measures in place, would be at risk sharing a server with a web application, which needs to be open and directly face the Internet. Failure to apply a patch to a seemingly minor function could result in a compromise that impacts other, more important functions (such as a database) on the same server.

This requirement is meant for all servers within the cardholder data environment (usually Unix, Linux, or Windows based). This requirement may not apply to systems which have the ability to natively implement security levels on a single server (e.g. mainframe).

Answer 1

So basically what the requirement is saying is that you need to assign one primary function per server.

The server you've described sounds like it runs a few applications for production users to utilize. This would be classified as an "application" server. However, you've also mentioned that there are multiple applications on that server, some touch the CDE indirectly and others do not. While this server would be considered to have one primary role, it brings the controls of the applications that don't touch the CDE into consideration.

If it were me, I would move the applications that don't interact with the CDE off of that box and move them to a different server, in a different segment if possible. If you don't have a segmented network (which you should really, really do) then everything is in scope anyway, so this advice doesn't matter.

Answer 2

The one truism of PCI-DSS compliance is this:

You are PCI-DSS compliant if your QSA says you are PSI-DSS compliant.

I'm of the opinion that the PCI council did a pretty stinking good job of giving us a very clear and to the point standard to follow, at least as far as standards go. That being said, this is one of those interesting cases where the requirement seems to be slightly out of whack with the intent.

Take the literal text from the requirement:

2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)

That right there says, primary function which could open you up to some disagreements. One could say the primary purpose of a given server is to store the database for the processor, whereas it is also configured to run the reporting engine as a secondary function.

The Council also produces another document called "Navigating the PCI DSS v2.0", available for download at the same location as the standard itself. This document goes into much greater detail bout each requirement and attempts to explain the intent behind them.

This is intended to ensure your organization's system configuration standards and related processes address server functions that need to have different security levels, or that may introduce security weaknesses to other functions on the same server.

Ok, cool, I like that. It tells us that they're trying to segregate based on the security level of the data in question. So, in theory, if you have a web application that allows direct access to the database containing card holder data, and the only people that have access to that highest sensitivity of data have access to the webapp, one might be able to host them both on the same system while maintaining compliance. However, if there exists a reporting tool that provides statistical data about transactions, but not the cardholder data itself, and a different set of people have access to it? Yeah, you're going to want to split that off.

Very likely the last thing you want to be doing, however, is slicing hairs into smaller and smaller slivers with your QSA. So the typically held opinion is:

---

The information provided above is in no way intended to be taken as official advice and is provided without warrant, guarantee, good faith, or adequate morning coffee intake. The statements provided do not represent the views of the PCI council, any QSA/ASV, my employer, your employer, this site, any other site, nor the ISP on which you are viewing this message.

Answer 3

Since PCI doesn't apply to a specific application, rather to an entire environment, it could be said that it considers all applications as parts of the same system.

That is to say - the application server layer is a "single primary function", for all parts of the system (i.e. applications), no matter how many there are - assuming they are all part of the applicable system, and all at the same trust level.

So if you have some internal applications, or e.g. your public website, that have nothing to do with credit cards - you should move them to a different environment (i.e. server, network, etc.) Otherwise, at best they would be in scope for the PCI requirements - and you don't want that. At worst, you would fail this requirement.

That said, NOTE that you need to consult with your QSA anyway. You would need him/her to sign off on it, and there is still some room for interpretation based on your specific context.

Answer 4

Is "application server" 'one primary function' or does it need to be "program x server", "program y server" etc?

That's up for interpretation based on how related and similar programs X and Y are. This sort of question tends towards a grey area where QSAs differ and you're fishing around for compensating controls.

But look at the intent of the rule - it wants you to keep different 'security levels' separate.

So if you've got a bunch of applications that all talk to the same web services or database (on another server with its own controls) using the same credentials, it could make sense to consider them one function. If an attacker compromised program X and that allowed them to compromise program Y which was on the same server, does that get them anything they didn't already have by compromising program X?

These applications also have varying groups roles, and permissions assigned within them and serve different departments.

This makes it sound like you do indeed have different functions and different security levels on the server.

Some of these interact indirectly with the application that the cardholder data resides in, others not.

What is the nature of the indirect interaction? If the interaction goes through a gateway (something acting as an effective control point) that is not in the CDE, you can keep the server out of PCI scope entirely.

If you can't avoid having the server in scope, I'd strongly recommend moving the applications on it that don't need to interact with CDE off to another server which won't be in scope.