topic Re: Question on PCI Compliance ... in Integration and Testing

Question on PCI Compliance ...

focuswebtech — Thu, 17 Sep 2009 01:33:05 GMT

Hello. I have a question on PCI compliance for my clients. Auth.net recommend using the AIM connection method. They claim this is the most secure method. However, after reading the PCI self-assessment questionnaire (OHHH BOY), I am not so sure. Basically, the AIM method seems to leave my clients more vulnerable since they are capturing the cc on their server. Since the client server captures the cc information, doesn't the server have to be PCI compliant? This doesn't just mean running a scan -- PCI compliant servers cost hundreds of dollars per month (per client)!

Maybe I am missing something. As I read the PCI paperwork and self-assessment questionnaire, I get the feeling the cc companies are putting so many requirements on small e-commerce businesses.

What do you think?

Mona

Re: Question on PCI Compliance ...

Nichiren — Thu, 17 Sep 2009 03:32:23 GMT

I'm not so sure Auth.net actually claims AIM to be the most secure. The SIM method would be more secure (assuming a sloppy developer using the AIM method) since all the client details (i.e. credit card info, etc) are being entered on Auth.net's servers directly instead of going through your servers first.

And someone correct me if I'm wrong but I would think that if you have no real reason to capture and record a client's CC number in your own DB, it would be best not to since it increases your risk and liability. This would at least obviate the need for you to secure credit card info since you don't store it. If you then send all the client details to Auth.net right after the client submits the info, I would think that all you would need is an SSL connection (also assuming due diligence made by the developer in terms of securing the form) to secure the data in transit and the checkout process should be solid.

Re: Question on PCI Compliance ...

focuswebtech — Thu, 17 Sep 2009 03:57:41 GMT

I am hoping to get some good opinions here so thanks so much for your input. This PCI compliance issue doesn't seem very straight forward.

Auth.net absolutely says AIM is recommended and most secure. Check it out here: http://developer.authorize.net/api/aim/

"AIM is Authorize.Net's recommended connection method and offers the most secure and flexible integration. AIM allows merchants to host their own secure payment form and send transactions to the payment gateway using an end-to-end secure sockets layer (SSL) connection. AIM is the required connection method for shopping cart developers participating in the Authorize.Net Shopping Cart Certification (SCC) program."

So, I agree that ANY method CAN be bad if the developer doesn't use proper methods. But, EVEN IF a developer uses https for the check out form, purchases an SSL, and scans their site daily, that is NOT enough to be PCI compliant (according to the PCI self-assessment questionnaire). And, those are the only things that auth.net seems to be saying are necessary. If you read the questionnaire (or do a search for pci compliant servers), you will see that it takes ALOT of work to have a PCI compliant server. We got a quote from www.rackspace.com of $500+ per month!

So ... why does it cost so much to get a "PCI compliant server," while shared hosting sites seem to think they just need an SSL and daily scanning?

Confusing ...

Mona

Re: Question on PCI Compliance ...

focuswebtech — Thu, 17 Sep 2009 04:03:46 GMT

Here is a blog post with a much better (more detailed) description of my concerns:

http://skeptikal.org/2009/05/is-mass-hosting-pci-compliant-biting.html.

Mona

Re: Question on PCI Compliance ...

hotslots132 — Thu, 17 Sep 2009 09:54:14 GMT

A properly coded site never records the CC in the site's database. The CC is passed along from page to page as a form POST parameter over a (I hope!) SSL encrypted connection. It will be in the server's memory for a time, but not in any place that an attacker could get at without a great deal of difficulty, and if they could do that, you're toast anyway.

One thing to watch out for, though, that recently tripped me up, is if you use a PHP cart with the default "register_globals" feature on, the POST parameters WILL be stored in the database, temporarily, in the session table. This potentially exposes all the CC information "in the clear" to anyone who can open the database, though it is only while the customer is on a page where the CC number was passed to it as a POST parameter. You should ensure that register_globals is off - you may need to make changes to your cart software if it depends on it being on.

Re: Question on PCI Compliance ...

stymiee — Thu, 17 Sep 2009 13:11:12 GMT

@focuswebtech wrote:

So ... why does it cost so much to get a "PCI compliant server," while shared hosting sites seem to think they just need an SSL and daily scanning?

Confusing ...
Mona

Shared hosting sites don't give a flying cow about PCI compliance. They'll do the absolute minimum amount of work to be able to say they are compliant and even then they probably aren't. Shared hosts are trying to make as much money as they can by cramming as many sites on to one server as possible. They're not really concerned about the websites any further then they need to make sure they are up so they can get paid.

Oh, and rackspace is way too expensive. I just migrated away all 40+ clients of ours and are now saving over $800 a month and have a server that is at least four times as powerful. I'd avoid them and look at Hostgator instead.

Re: Question on PCI Compliance ...

hotslots132 — Thu, 17 Sep 2009 13:44:35 GMT

I don't know that shared hosting, itself, is the issue. The key with PCI compliance, at least as far as this community is concerned, is that your e-commerce site should not store any of the data that is required to be protected - primarily the Personal Account Number (credit card number, etc.) and CVV value. If all you do is pass those values (over a SSL-protected link) to authorize.net, and make sure they are not stored on your server anywhere, ever, then you're probably ok. (I think you need to have some protection against unauthorized access to the server and its files, but that can be done even on a shared host, unless they have serious bugs.)

I will agree, though, that shared hosting creates some risks. I once used a shared host that had security holes that allowed files to be written to other user's directories. I no longer use that host. My client uses a managed server at 1&1, where they are the only user of that server, and that has worked well for them. All things considered, I'd rather be on a separate server than a shared host. Some services offer virtual hosting which, if properly done, should be ok.

Re: Question on PCI Compliance ...

Webguys2 — Thu, 17 Sep 2009 15:31:41 GMT

I agree with Hotslots. We have talked with PCI consultants about all of this PCI. We were using AIM but decided to switch to the SIM method to get rid of some of the liability. The SIM is limiting for us but we are PCI compliant now. On our website, when it comes to capturing the CC info, we put ANET's page in an IFrame to submit the payment then the thank you page goes back to our website. But if you are using AIM, the rule is you can have the CC and CVV numbers just long enough to complete the transaction, so like a split second. If you HAVE to store anything, store the last four of the CC number not the whole thing. But if that is the case, they want you to have your CC server AS WELL AS all other servers and networks that are connected PCI compliant also! The thinking is that if they break into a different server on your network then they could potentially reach your server with the CC info on it. HUGE pain. That is why we switched to SIM and let ANET store it all. If you can make it work without capturing it you are much better off. If fraud happens, the credit card company will go after the bank then the bank will come after you. If you are PCI compliant, you have a great defense.

Re: Question on PCI Compliance ...

Webguys2 — Thu, 17 Sep 2009 16:00:17 GMT

We also use McAfee (formerly HackerSafe) for our daily scans, they are reasonably priced and can aid in finding some of your vulnerabilities. If you have to host your site and use the SIM method along with a scan, you should be well on your way.

Re: Question on PCI Compliance ...

focuswebtech — Thu, 17 Sep 2009 19:55:16 GMT

Webguys2 wrote:
We have talked with PCI consultants about all of this PCI. We were using AIM but decided to switch to the SIM method to get rid of some of the liability. The SIM is limiting for us but we are PCI compliant now.

Right! That is exactly what I was trying to get at in my original post. I totally agree that it makes sense to use AIM so the liability is put on auth.net, not our clients. However, auth.net says in its documentation that they recommend AIM as the more secure method! Unless the client is on a PCI-compliant server in a PCI-compliant data center, that is not true.
---
But if you are using AIM, the rule is you can have the CC and CVV numbers just long enough to complete the transaction, so like a split second.

Where did you see this information? The information I read in the PCI compliance documentation and the Self-Assessment questionnaire says that any merchant that captures, stores, or transmits credit card information (even over an SSL) must be PCI compliant. I would guess that many IT security people would say that a split second is all it takes for a hacker script to pick up the cc info.
---
If you HAVE to store anything, store the last four of the CC number not the whole thing. But if that is the case, they want you to have your CC server AS WELL AS all other servers and networks that are connected PCI compliant also! The thinking is that if they break into a different server on your network then they could potentially reach your server with the CC info on it. HUGE pain.

Yes, that is why I don't think you can get PCI compliance with shared hosting. Too many vulnerabilities

I think many people think that an e-commerce store only needs to worry about PCI compliance if they store CC info. I think that is a huge misconception. Take a look here for the top 10 misconceptions:

http://www.neospire.net/business.solutions/pci.dss.misconceptions.php

MC is not starting to fine some level 1, 2, and 3 merchants for non-compliance. There doesn't even have to be a breach! Check it out here:

http://www.storefrontbacktalk.com/securityfraud/mastercard-becomes-the-first-card-brand-to-publish-pci-fines/

I really believe that on-line merchants using AIM are very vulnerable for fines. Would love to hear what auth.net has to say about that.

Mona

Re: Question on PCI Compliance ...

hotslots132 — Thu, 17 Sep 2009 20:39:14 GMT

You have to worry about PCI compliance if you handle credit card data. But if you use AIM properly, you can comply. I disagree that using AIM, in and of itself, leaves a merchant vulnerable.

Re: Question on PCI Compliance ...

focuswebtech — Thu, 17 Sep 2009 23:11:57 GMT

After reading and researching, my understanding (and what I am telling my clients) is if you use AIM and your web server/hosting is NOT PCI compliant, you are vulnerable. Even if use an SSL to transfer the data, that is NOT enough. To remove the requirement for a server to be PCI compliant, you must send the consumer to a third-party site for the entire checkout process.

Per http://www.neospire.net/business.solutions/pci.dss.misconceptions.php, here are a few of the biggest misconceptions about PCI compliance:

Since I don't store credit card information, I don't have to be PCI compliant

FALSE. The PCI DSS does not just apply to the storage of credit card data but also to the handling of data while it is processed or transmitted over networks, phone lines, faxes, etc. While not storing credit card data does eliminate some compliance requirements the majority of the controls dictated by the DSS remain in effect. The only way to avoid PCI compliance is to transfer the risk entirely to someone else, such as PayPal’s Website Payments Standard service where customers interact with the PayPal software directly and credit card information never traverses your own servers.

PCI Compliance Guide- Legal rights and responsibilities
PayPal PCI Applicability - https://www.paypal.com/pcicompliance
I use PayPal/Authorize.NET therefore I don't have to be PCI complaint

There are certain payment products that do transfer the burden of PCI compliance to the payment services provider (e.g. PayPal’s Website Payments Pro) however they require that a consumer be forwarded to the payment provider’s servers to complete their order. If your website integrates with PayPal via an API then you are still liable for PCI compliance since your servers capture and transmit the credit card data first.

PayPal PCI Applicability - https://www.paypal.com/pcicompliance

Re: Question on PCI Compliance ...

hotslots132 — Thu, 17 Sep 2009 23:22:39 GMT

That list of misconceptions is from a hosting provider which has a vested interest in scaring you away from other hosts.

Get the information from the horse's mouth PCI Security Standard Quick Guide and pcisecuritystandards.org

Re: Question on PCI Compliance ...

focuswebtech — Thu, 17 Sep 2009 23:48:22 GMT

Actually, that same list is printed on many different sites. Here it is again on this site:

http://www.focusonpci.com/site/index.php/Articles/pci-misconceptions.html.

Also, I have read the PCI standards and the SAQ. My understanding is that what I state above (AIM is NOT compliant if your host is not compliant). I guess that is why I am asking the question. Do you have any specific resources that contradict that? I would LOVE to be wrong here -- it would make things much easier. But, I can not find a way around the host being PCI compliant, running in a PCI compliant data center, if you want to use AIM.

Where does it say otherwise?

Mona

Re: Question on PCI Compliance ...

hotslots132 — Fri, 18 Sep 2009 00:10:53 GMT

Mona,

I agree that if a host's environment doesn't meet the requirements of PCI, then you're not in compliance. But I don't agree that using AIM is risky just because the host doesn't make a statement of PCI compliance. Most commercial hosts do meet the requirements, such as establishing a firewall, having secure physical access, etc. The PCI standard has an appendix A addressing shared hosting.

I will comment that I do not claim to be a PCI expert, but I do think that a merchant using AIM can claim conformance to PCI on most hosting services (assuming reasonable care is taken.) At least as far as my client is concerned, the PCI standard highlights areas I know we still have to address before we can claim, with a straight face, that we conform. My work in that area is not done yet.

Re: Question on PCI Compliance ...

focuswebtech — Sat, 19 Sep 2009 06:17:26 GMT

Is anyone here from auth.net that can shed some light on this issue? Is AIM compliant on a shared server?

Mona

Re: Question on PCI Compliance ...

SteveMay — Sat, 19 Sep 2009 18:20:58 GMT

I think I'm with hotslots here.

From the PCI:

PCI DSS Applicability Information

(table, other information)

then towards the bottom of the page:

PCI DSS, however, does not apply if PANs are not stored, processed, or transmitted.

Ok, we're not (hopefully) talking about storing credit card data when using AIM, and Authorize.Net is doing the processing once they get the data, AND they are the ones storing any sensitive authentication data.

Transmitting? Well, perhaps, but if you try to make the argument that any transmission of the CC data in and of itself triggers the need for PCI DSS then every single piece of equipment involved ( the customer's machine, routers, backbones, each 'hop' machine in the path, etc.) needs to be PCI compliant...So even SIM is not compliant because the customers machine is 'transmitting' data over the net and that process is (almost certainly) not PCI compliant.

That's a bit far fetched, and reading through the PCI guidelines it seems clear (to me) that their focus is on servers/machines that actually store and process the information, not the incoming feeds.

If I'm wrong, and transmission of data means ANY transmission of sensitive data, then e-commerce on the web is effectively dead and we might as well do something else to make a living... :-)

my $.02

Steve

Re: Question on PCI Compliance ...

armandofox — Wed, 16 Jun 2010 01:30:05 GMT

I know this is an older thread, but I've had some of the same questions and after reading a lot of documentation on PCI-DSS and PA-DSS, I've found the helpful clarification below (this is from https://www.pcisecuritystandards.org/pdfs/pci_pa_dss.pdf). From this excerpt and the text surrounding it in the document, I conclude:

- If you are the developer *and sole operator* of a SaaS-based integrated payment application - see in particular point 1 below, which distinguishes SaaS from shrink-wrapped software (SwS?)

- And your application does NOT store sensitive cardholder data (though it may transiently receive and retransmit such data to a payment gateway like Authorize.net, as long as it destroys/does not persist the data after the transaction is processed)

- And your application IS NOT sold/licensed to any other entity to deploy or operate it

- And your application and its hosting/networking/security environment is PCI-DSS compliant (there are various compliance levels depending on your transaction volume, etc., but many compliance levels can be achieved thru a self-assessment questionnaire that is not too onerous)

- THEN PA-DSS does not apply to you.

however, you still are on the hook for PCI -DSS compliance, though for most small businesses that will probably put them in the category that allows them to fill out the self assessment questionnaire and possibly require external network scans.

anyone getting a different reading from this?

armando

PA-DSS does NOT apply to payment applications offered by application or service providers only as a service (unless such applications

are also sold, licensed, or distributed to third parties) because:

1) The application is a service offered to customers (typically merchants) and the customers do not have the ability to manage, install,

or control the application or its environment;

2) The application is covered by the application or service provider’s own PCI DSS review (this coverage should be confirmed by the

customer); and/or

3) The application is not sold, distributed, or licensed to third parties.

Examples of these “software as a service” payment applications include:

1) Those offered by Application Service Providers (ASP) who host a payment application on their site for their customers’ use. Note that

PA-DSS would apply, however, if the ASP’s payment application is also sold to, and implemented on, a third-party site, and the

application was not covered by the ASP’s PCI DSS review.

2) Virtual terminal applications that reside on a service providers’ site and are used by merchants to enter their payment transactions.

Note that PA-DSS would apply if the virtual terminal application has a portion that is distributed to, and implemented on, the

merchant’s site, and was not covered by the virtual terminal provider’s PCI DSS review.

Re: Question on PCI Compliance ...

bethshady — Wed, 30 Jun 2010 23:43:23 GMT

You are right. The server or computer you are working on needs to be PCI compliant.

Re: Question on PCI Compliance ...

larrykluger — Wed, 17 Aug 2011 18:08:24 GMT

If you use AIM, you're in scope for PCI. Many many developers (including several on this thread) wishfully think that they won't be in scope if they merely transmit the card data onward to Authorize.net using the AIM api.

All of those developers are wrong under the current PCI rules. Since the card info is transiting your server, a bad guy could break into your server or into your software and steal the card info as it flys by. Doesn't matter how unlikely it is, you're now in the scope of PCI.

To use Authorize.Net and stay out of the PCI Scope, use integration methods SIM or the new DPM - Direct Post Method. Both keep your server out of scope.