Separation of duties the PCI DSS way

 

“For a firm to be compliant with some parts of regulations these days you need separation of duties that SBS 2003 and SBS 2008 can’t muster.”

Susan,

Maybe I am missing the whole point here.

I think your statement is FUD. MS sells additional licenses to Windows 2008 server separately; you may add as many as you need to your SBS domain for isolation of services. What regulation requires more than that?

John

Honestly it’s not FUD.  And I’m specifically referring to SBS 2003 and SBS 2008 standard. It’s PCI-DSS requirements that I don’t think SBS can pass, but I don’t think we should be trying to pass them honestly, because I don’t think any server should be storing credit card data.

Check out the PCI-DSS requirements. 2.2.1 requires — “Implement only one primary function per server” among other requirements including DMZs and isolation of the data.  Mind you they aren’t just about storage of credit card data but if you haven’t read them before, do so.

https://www.pcisecuritystandards.org/security_standards/pci_dss_download.html

That’s why in cases where you transacting credit card data I’d ask if it truly needs to be stored on that server in the first place.  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.

4 Thoughts on “Separation of duties the PCI DSS way

  1. 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?

  2. 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.

  3. Graham Smith on March 31, 2009 at 10:42 am said:

    “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 :

    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)

  4. @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.

    http://olzak.wordpress.com/2009/03/23/you-just-have-to-run-faster-than-the-bear/

    http://spiresecurity.typepad.com/spire_security_viewpoint/2008/10/you-dont-have-to-run-faster-than-the-bear.html

    http://www.google.com/search?q=security+run+faster+than+the+bear

    etc…

    John

Post Navigation