PCI Compliance Simplified
Posted on February 24, 2010 | No Comments
Colleen Dick asked:
If your internet business accepts credit cards directly through your website, you will find yourself facing Payment Card Industry (PCI) compliance issues. The reason for this is to cut down on internet fraud. Many many articles, webinars, and materials have been published on PCI compliance, and most business owners find the subject dense, painful, technical and complex. Naturally there are a whole lot of consultants who will, (for a hefty fee) audit your business and tell you how you can meet the PCI guidelines, with warnings of dire consequences if you don’t.
I recommend that every business owner download the PCI DSS document and at least skim through it. A very small business can get by with just a self-audit. More importantly, if you don’t store primary account numbers (PANs) on any of your own servers, you can completely ignore most of the guidelines because they only apply to servers that store PANs. The only guideline that applies to businesses that don’t store PANs is #4 — the one concerning security of PANs in transit. The beauty of it is that the responsibility for the remaining guidelines is shifted onto your credit card gateway because they are the ones that keep track of the PANs on your behalf. Presumably all major credit card gateways are PCI compliant because they would be such an obvious target.
Here are my much simplified PCI security guidelines for small businesses, to make PCI compliance an order of magnitude less complex and expensive.
Obviously, do not store customer PANs in your database, even encrypted. This makes your database server a much less attractive target. It inconveniences your customers a bit, because you can not pull up and autofill their credit card number, but you should tout this as a positive security measure rather than an inconvenience. Do not store PANs (even in so-called ‘temporary’ session variables) on your web server, encrypted or otherwise. This will inconvenience your customers a little if they have to detour off the pages in that you can’t restore the credit card number. It is best to minimize the chances of this happening by clever engineering of your purchase funnel, but if they do lose a credit card number in a page refresh or something, tout it as a security feature, not a weakness. Encrypt pages that collect credit card numbers to ship off to your credit card gateway with SSL (https:) and a security certificate (Any gateway worth its salt will not even process data from an insecure URL.) Be vigilant that your webserver does not get rooted. Other lesser hacks without the hackers gaining root access to your webserver can be annoying, but will not allow the hackers to intercept and decode your secure transmissions. However, if you get rooted they potentially can.
There you have it — from a 12 page document to four simple guidelines. Further information on PCI compliance may be found from PCI Compliance. org and you may also download the PCI DSS in English .
Caffeinated Content
If your internet business accepts credit cards directly through your website, you will find yourself facing Payment Card Industry (PCI) compliance issues. The reason for this is to cut down on internet fraud. Many many articles, webinars, and materials have been published on PCI compliance, and most business owners find the subject dense, painful, technical and complex. Naturally there are a whole lot of consultants who will, (for a hefty fee) audit your business and tell you how you can meet the PCI guidelines, with warnings of dire consequences if you don’t.
I recommend that every business owner download the PCI DSS document and at least skim through it. A very small business can get by with just a self-audit. More importantly, if you don’t store primary account numbers (PANs) on any of your own servers, you can completely ignore most of the guidelines because they only apply to servers that store PANs. The only guideline that applies to businesses that don’t store PANs is #4 — the one concerning security of PANs in transit. The beauty of it is that the responsibility for the remaining guidelines is shifted onto your credit card gateway because they are the ones that keep track of the PANs on your behalf. Presumably all major credit card gateways are PCI compliant because they would be such an obvious target.
Here are my much simplified PCI security guidelines for small businesses, to make PCI compliance an order of magnitude less complex and expensive.
Obviously, do not store customer PANs in your database, even encrypted. This makes your database server a much less attractive target. It inconveniences your customers a bit, because you can not pull up and autofill their credit card number, but you should tout this as a positive security measure rather than an inconvenience. Do not store PANs (even in so-called ‘temporary’ session variables) on your web server, encrypted or otherwise. This will inconvenience your customers a little if they have to detour off the pages in that you can’t restore the credit card number. It is best to minimize the chances of this happening by clever engineering of your purchase funnel, but if they do lose a credit card number in a page refresh or something, tout it as a security feature, not a weakness. Encrypt pages that collect credit card numbers to ship off to your credit card gateway with SSL (https:) and a security certificate (Any gateway worth its salt will not even process data from an insecure URL.) Be vigilant that your webserver does not get rooted. Other lesser hacks without the hackers gaining root access to your webserver can be annoying, but will not allow the hackers to intercept and decode your secure transmissions. However, if you get rooted they potentially can.
There you have it — from a 12 page document to four simple guidelines. Further information on PCI compliance may be found from PCI Compliance. org and you may also download the PCI DSS in English .
Caffeinated Content