THE OFFICIAL BLOG OF THE SBS DIVA

2.2.1 also means you can't be compliant using EBS as your infrastructure either.

However DSS 1.2 doesn't make mention of virtualisation, so you could potentially implement a DSS 1.2 compliant system logically but not physically. Not sure how these systems are validated by an auditor.

Maybe DSS 1.3 will cover virtualisation techniques?

I am not sure we disagree too much. Your assertion that storing cc numbers on an SBS is a PCI infraction is correct.

When I read your post I thought that for you to say "you need separation of duties that SBS 2003 and SBS 2008 can't muster" implies that clients cannot use SBS. When in fact it would be more accurate to have said a company can't use THE SBS SERVER for storing credit card data.

I think companies with a Small Business Server network can still accept credit cards, and meet the PCI standard they just cannot put certain data on the SBS Standard "first server".

John

PS: My reply leaves aside the question of "What constitutes a standard a company should adhere to?" or "Is PCI-DSS a good standard for protecting my client's customers' personal data?" When you said 'standard' I was thinking federal government like HIPAA, SOX, or 55MPH national speed limit.

"I think we should question ANY company's storage of credit card data for any reason, regardless if it's on a SBS server or not."

Here, to get you started, are some valid reasons <grin>:

1. For mail order/telephone order (MOTO) transactions, payment card information is required in order to take payment.

2. For returned goods (some mail order companies have a returns rate in excess of 50%), the payment card number is required in order to make a refund.

3. For reconciling payments received from the card services provider (can take up to 14 days for the money to arrive) ideally the last four digits of the payment card number and the name shown on the payment card; must know transaction value, time and date.

4. For tracing and dealing with chargebacks, ideally the last four digits of the payment card number; must know the name shown on the payment card, cardholder's address, transaction value, time and date.

5. For audit purposes, in the United Kingdom an independent annual audit is required for all businesses whose turnover exceeds a certain value. The auditors will wish to know that all income and expenditure can be reconciled to individual transactions and may wish to obtain evidence that the transaction did, in fact, take place.

6. For customs and revenue purposes, in the United Kingdom certain details of all sales and purchases have by law to be retained for a minumum of seven years.

Obviously certain data elements that may be required for payment card processing (e.g. the CV2 card verification number printed on the back of the card) won't be needed again once the card has been authorised, but certain elements of sensitive payment card data will be.

--

Graham Smith

(in a personal capacity)

@Graham -- In general I agree, but I am aware of some other cases where for various reasons card data is retained, and I am not sure how the client gets around the requirement. I am also interested in what you say because you are  commenting from outside the US. I think other countries take a different and perhaps more cautious regulatory approach to protecting consumer privacy. (Does this work?)

1) Recuring transactions. Say I pay my phone bill by credit card. My phone company has to charge my card every month, they need to store enough data to make the transaction happen. (Say I use SBS for my business server, I am an independent web host. What am I to do in a case like this?)

2) High volume sales. (High volume, relative to small business of course.) I have a client whose processor wants them to send all the transactions in a batch, once per day. Between the time of purchase and the batch transaction, the data is stored. (Again, say I use SBS to run the office of this high volume retail organization and there are a few Point of Sales machines attached to the network.)

In my world, it is not enough to tell clients they can't store card data and walk away. I have to either find an acceptable solution or turn a blind eye to the client doing something even more dangerous. (Such as storing the data on a domain controller that has a web server and mail server attached.)

I think the solution is to find some other place (server?) to store data, that we can secure more tightly than the SBS main server. (Especially considering I fell like the alternative is to turn a blind eye and really let the clients place themselves at significant risk.

PCI or other arbitrary standards notwithstanding, I do not have to run faster than the bear. I only have to run faster than the guys storing credit card data in the clear on SMB shares on SBS.

olzak.wordpress.com/.../you-just-have-to-run-faster-than-the-bear

spiresecurity.typepad.com/.../you-dont-have-to-run-faster-than-the-bear.html

www.google.com/search

etc...

John