|Is it worth writing a custom cart software if PCI compliance is coming|
I believe PCI compliance will be coming very soon, so is it worth writing your own custom cart?
I really want to write my own custom cart (for many reasons I don't want to get into), but my one big concern I have is being compliant.
I know commercial carts pay big bucks to get the compliance certificate.
It isn't that much to get, the last time I did PCI for a site I think the client paid $600.
All my carts are custom, as are my checkout processes.
Most of the PCI stuff has to do with the host server. What OS, along with what version of SSH, FTP, what remote accesses their are, webdav and remote desktop stuff.
You believe PCI compliance is coming very soon? ;)
It is here already! Trust me, I fight month after month with this with my merchant provider.
As Demaestro stated, PCI is more about the server/network/processes and less about the software. Yes, the software need to meet the standards, but that is a very small part.
What about Visa Approved / PA-DSS Certified?
A PCI compliance is usually just a questionaire, but they don't look at the software level.
Why are these commercial carts saying they pay 40K/year to be certified, and other carts are not?
|but they don't look at the software level. |
For services that use Security Metrics, it **does** look at the software level from an external point of view. S.M. passes potential malicious XSS, SQL injection, and other queries to the site, and if the data is not filtered properly, adds to the risk score.
Sometimes it's an internal server software, not your cart. For example, some versions of PHP contain security holes and if found, this will add to the risk score. You fix it by upgrading to the suggested version of PHP.
**Most** of the scripting risks are managed by properly filtering input. The upshot of this is it makes your programs more secure, you learn to properly filter input, and this can't be anything but a good thing.
|Why are these commercial carts saying they pay 40K/year to be certified, and other carts are not? |
Don't know the direct answer to that, but I do know that sites that actually store credit card info are required to be PCI compliant on a higher level. The questionnaire is used to determine what level of PCI compliance you are required to meet as a vendor.
I'm beginning to think Security Metrics is not "perfect" and is giving some false positives based on unrelated non-security issues. Here's an example [webmasterworld.com], the basic question asked there is still unanswered.
Even so, it's helped my clients to have more secure environments and made me a better programmer, at least, a little. :-)
To answer your question though, yes it is worth having a custom cart.
I may be wrong, or this may be just in Canada, but....
Isn't it the case you only need PCI cert if you are storing the credit cards on one of your servers?
If you don't store or record the CC numbers are you required to have a PCI cert? I thought no but could be wrong.
@Demaestro - if your website processes CC numbers you need to be PCI DSS compliant.
but there is no compliance that actually looks at your source code right? (unless ofcourse you are doing ten's of millions per year I believe).
Jack, just wondering who requires this if you process CC numbers?
I just checked with my gateway and they only want me to have one if I store numbers, they don't require it otherwise, and they are very strict.
I am just wondering if there is some other body that is requiring it of me.
dreamer -> there are third party services that do code review. Applications and Websites that use those code reviews are usually in a position of high trust.
For example, banks and some poker/gambling sites have code audits. These are expensive though. Most e-comm vulnerabilities come in the form of sql injections and cross scripting stuff which can be checked using brute force methods, so getting a full code review isn't required.
There are various levels of PCI compliance. The lack of storing CC data does not relieve you from being PCI compliant. Simply the act of taking cc info and transmitting it requires PCI.
The only way to NOT need PCI is if you use a proxy payment provider (ie paypal, google, etc) where the customer leaves your site to complete payment.
Also, it is not the gateway that requires PCI, it stems initially from Visa/MC and is required by your merchant provider.
|just wondering who requires this if you process CC numbers? |
The credit card companies require the gateway to require PCI compliance of their web site clients. So if your gateway hasn't required this of you yet, they will . . . eventually. Not sure if this is just U.S. only or not.
EDIT: what ssgumby said . . .
It may be in the USA only at this point.
I just finished a gateway for a client about 3 months ago and it says specifically we only need PCI cert if we store the numbers ourselves. It may have even changed since then.
Our only requirement was an SSL.
I will be watching for a change though.
Again, its not really the gateway, its the merchant provider. It may or may not be different in the US, but here is an example.
Gateway = authorize.net (they do not require me to be PCI compliant)
Merchant Provider = First Data (they DO require me to be PCI compliant).
Also, the wording is quite tricky. When I first read this I thought too that as long as I did not store the number then I was safe. After a full analysis, it is simply if I store "credit card data". Credit Card Data is defined as ANY info on the credit card. (ie. First, Last, CC#, Expire Date). Of course I store first/last and this in and of itself forces PCI compliance.
I wonder if they really consider first and last names as credit card data if it isn't accompanied by some other card information.
I would consider that customer information, even part of the shipping information, but if no other card data is there not sure how they could consider just the names as such.
I don't have the specific document with me, but card holder data is ANY data on the card. I use First Data and was fined as I wasn't using the proper PCI questionairre. After arguing with them over and over that I didn't "store card holder data" they asked point blank if I stored first and last, without storing cc#. I said yes, of course I do. Their response was that first and last, as printed on the card, is card holder data even if I only transmit the cc#.
I too would consider it customer info, but my provider anyway sees it differently.
Trust me, I have been working on PCI and fighting with FD since Jan 1 2009 to get this all worked out. My cart scans fine, the questionairre and specific level is what is hard to pinpoint. They have me at the second to the highest which is nuts in my opinion.
ss, I guess that makes sense from where they are sitting, from where I am sitting that just sounds stupid.
But you know what they say, to be in security you have to be paranoid. And paranoid people often don't make decisions based on reasonable logic.
Here is the document, and here is an excerpt
Q: What is defined as ‘cardholder data’?
A: Cardholder data is any personally identifiable data associated with a cardholder. This could be an account number, expiration date, name, address, social security number, etc. All personally identifiable information associated with the cardholder that is stored, processed, or transmitted is also considered cardholder data.
I agree, it seems totally nuts!
ssgumby is correct in all his post. Demaestro they just haven't sent the site owner the PCI compliance steps they/you will have to go through.
I went through it about a year ago and know the pains ssgumby is talking about.
@Demaestro - from my reading of the PCI DSS requirements, if your site takes credit cards, or indeed if you take them over the phone, you need ot be PCI DSS compliant. By processing I mean your site actually has a form that accepts credit card numbers. If you just send them off to a processor and they do the form for taking the credit cards then you're fine you don't process the cards. Storing cards is not the sole prerequisite for PCI DSS.
I have been through the PCI process before, and I have helped secure several merchant accounts for clients.
It really isn't that big of a pain.
Putting on my programmer hat for a second and playing devil's advocate.... I wonder to myself technically what the difference is between doing a POST from my SSL'd page to the payment gateway, and the POST coming from the processor's page itself?
Especially if I am not storing any of that form data on my server. As long as the SSL cert has good encryption, what difference does it make which page POSTs the data?
I am not saying PCI isn't a good thing to have in either case, I just wonder what the difference is technically when you host the form yourself from when you don't, that would cause them to say that if you host the form you need to be PCI compliant?
Both scenarios POST form data from an SSL'd page to the same place and both scenarios end with the processor POSTing back the results of the transaction to the website's server.
I guess the difference is that your site can be targeted and hacked to capture the credit cards if you are taking the CC number whereas if some other site is doing that then their site needs to be targeted. Hence the requirement for sites that process cards (but don't necessarily store the numbers) to be PCI DSS compliant. The good news is that if you don't store the cards you don't need to deal with a lot of the database server separation issues that you would need to handle if you did.
We have a custom cart and went through this about a year ago. You are allowed to store the first 6 digits and last 4 of the credit card. You are not allowed to store the expiration date or cvv. We must have quarterly scans done on our website and our local firewall. It's all doable but the initial outlay of time was not small. If we had wanted to store actual cc numbers the cost and time involved would have been prohibitive.
If you are starting out you might want to use something like Paypal that processes the card off site. If you are established, go for it but don't plan on storing full credit card numbers or expiration dates.
That isn't the case though. I am not sure you understand the how transmission of data occurs.
Again, I am not storing the form data so hacking my site wouldn't yield anything. The form is filled out client side so the only way to intercept the data is at time of POST.
If a proper SSL encryption is applied to the POSTed data, then I don't see the difference in which page POST's it. It still gets transmitted from the user's computer to the gateway regardless of who hosts the page.
Again don't get me wrong, I am not suggesting that we shouldn't have it.
I just don't see the difference between hosting a form yourself or having them host the form.
If anything I think it is less secure to send the user to the host page because then they don't require an SSL and the site may transmit order details and shipping info which could be intercepted, not CC info, but some other customer and order info.
PCI is a real fun topic - as the regulations are so wide open and everyone seems to interpret the rules in a different way - even without reading them and based on what others are writing - who usually haven't read the rules either.
PCI applies to anyone who accepts credit cards - not just online. But for online your systems and your custom written software will have to comply with PCI regulations - even if you only transmit credit card details and don't store them. If you don't deal with credit card details on your server, you don't have to worry.
So for example if you create your own shopping cart solution and you want to integrate with Payment gateways using an API which you run on the server hosting your shopping cart server, then systems and companies using your solution will have to be PCI compliant.
There are number of references in regards to programming code in the PCI regulations - mainly to do with verification of input and some basic training of programmers - so it would be worthwhile for you to review them (It's not as scary as you may think).
Keep in mind that quite a number of very popular open source solutions actually use the API integration with payment gateways - making PCI compliance a requirement for their users.
In regards to $600 PCI compliance - no one can provide PCI compliance for $600. This is why:
PCI defines a number of regulations and procedures you have to comply with.
These require you to not only set up your firewalls, servers and databases in a certain way - they also define how you connect to your servers, who has what kind of access, how you deal with passwords, what kind of intrusion control and logging processes you use, how long you store logs, how access to the data enter you host in is secured, how you encrypt credit card details (if you store them) and many other procedures which you have to implement.
The $600 option can only deal with the server side setup - and in most cases they will not even set up intrusion control and PCI compliant logging - they simply make sure the server passes an external PCI scanning test. The onus of complying with many procedures is on you.
Most people who store or transfer credit cards believe they are okay, if they sign up with a company scanning their server for PCI compliance. This however is only one small part of PCI compliance.
PCI compliance is a huge pain in the proverbial - and unfortunately it is made a lot more difficult by people who don't read the rules or who choose to interpret the rules in certain ways rather than the way they are written down (usually so they can charge you more for becoming compliant).
A whole industry has developed around this, from special intrusion detection software to logging software and companies verifying your compliance.
Software for PCI compliance can quickly add up to more than $20,000 in yearly license fees, depending on the number of servers your system uses. Prices are absolutely horrendous. Although this isn't required at all. There are a number of open source solutions you can use to meet compliance, such as Ossec and Snort (but you need to know how to set them up and you have to use multiple servers). You can also host servers on Amazon EC2 cloud, so long as you don't require Level 1 PCI compliancy (more than 6 million transactions per year).
Really your best option is to go to the PCI website https://www.pcisecuritystandards.org/ and download the questionnaire applicable to you and you customers. Just read it - that will give you the clearest understanding of what you are getting yourself into.
|I don't see the difference in which page POST's it. |
Take a scenario. You've bought the best 256 bit encryption cert you can buy, high user trust, whatever. Let's say it's perfect.
Your server has failed a PCI compliance scan due to some security flaw, whatever it is, doesn't matter - let's say it's an old PHP version with a flaw.
Some hacker has made use of that flaw and can access your data in some way, or maybe has even rooted your box without your knowing it.
User submits data. Hacker logs all data submitted.
So even though your cert encrypts the data, the server decrypts it on receipt. When it's received, hacker is sniffing/storing it, after decryption.
This is the difference, although it's a simplistic scenario, it demonstrates you are responsible for the environment you create.