SQL 2005 Instances for physical separation?

[Julia]

I'm trying to design a new, cost-effective, architecture for our SQL 2005 environment that will pass a PCI compliance audit.

My first task is to reduce the scope of our auditable environment by separating out card data and card processes from our other business processes.

We have one table in SQL Server of card data which is currently encrypted using a 3rd party tool (ChilKat). This is going to be split away from the remaining stock/customer management database to isolate it. We are then going to isolate the card processing applications so they are the only applications able to communicate with the card data.

My question is what is considered suitable physical separation of this data? Could I, for example, have one physical server with two Instances of SQL Server installed and have the main database on one Instance and the card data on another. Card data applications communicte with the Card Data Instance and all other business operations communicate with the Main Data Instance? Having two SQL instances on one server would reduce the licensing, hardware and hosting costs.

My fall-back, worst case scenario is to have a separate server (or virtualised server) with SQL installed with one table on it. This seems such a ridiculously expensive option (server + server OS license + SQL license + hosting service cost) all for one table of encrypted data. Sledgehammer and nut springs to mind!

I have a costly QSA I've been working with but it seems that all solutions I put forward are rejected but the QSA doesn't seem able to suggest something that WOULD be compliant! Any suggestions that WOULD be compliant would be very much appreciated.

[jbhall56]

My question is what is considered suitable physical separation of this data? Could I, for example, have one physical server with two Instances of SQL Server installed and have the main database on one Instance and the card data on another. Card data applications communicte with the Card Data Instance and all other business operations communicate with the Main Data Instance? Having two SQL instances on one server would reduce the licensing, hardware and hosting costs.

Using two instances does not server segregation /separation make. You will need to separate the instances on separate servers. The reason is that if one of the instances is compromised, the other instance could also be compromised. Requirement 2.2.1 states that the server needs to run one and only one major service. Just because the services are the same does not mean that they are also separated appropriately.

There are ways to use the same server and then rely on compensating controls. However, at the end of the day, it's those additional steps to get 'above and beyond' the requirement in 2.2.1 that would be much more onerous and expensive than a new server, OS license and DB license. Let alone what they would introduce into the process that would also likely introduce a certain amount of human error into the equation that would be unacceptable.

My fall-back, worst case scenario is to have a separate server (or virtualised server) with SQL installed with one table on it. This seems such a ridiculously expensive option (server + server OS license + SQL license + hosting service cost) all for one table of encrypted data. Sledgehammer and nut springs to mind!

Whether or not you use virtualization or not is up to you. However, unless you already have virtualization running in your shop, I would recommend that you stay away from using it in this instance as your first project.

I appreciate the fact that you want to have a cost effective solution, however you need to find other ways to save money than trying to short cut certain PCI requirements.

I know for a lot of people it's hard to believe, but at times, it's a lot cheaper to just do what the PCI DSS wants you to do than to try and build some 'Rube Goldberg' contraption and the necessary compensating controls and then hope and pray that it stays together and performs the way you think it should. It may work for a while, but ultimately, the 'rubber bands and hair pins' that hold the thing together start falling out faster than you can replace them and your compensating controls no longer function appropriately and you're back where you started.