Hi All,

I am currently using CRE Loaded6 v6.2 Pro[12.1 (SP1)] for my site.

Questions are:

1. If I create a subdomain, i.e., taylor.brooklyngigcenter.com, do I need another license and install for CRE?

2. Am I storing personal data other than name and address on my server? Am I storing credit card numbers, and do I need to purge them occasionally?

3. Is this version of software PCI compliant for July 2010?

Thanks in advance,

Alan

well you are certainly going to want to update to the latest version

1. no

2. those questions depend on the payment module you are using

3. this has more to do with your hosting environment than the cart itself

I beg to differ with that last point, Jason.

The 2010 requirements include, among others that the passwords used to access cart areas which display customer payment data must be not less than 7 characters long, be of mixed case, include one number and one special character.

The server does not control that.

David

if they are using lets say paypal, 2checkout, or any other payment method where they have no payment info entered on site.. pci compliance does not apply

If you think it does.. who is going to enforce it

Whether or not anyone is going to enforce it is moot. If the software doesn't meet the standards, it is, itself, not compliant.

David

I should jump back in here....I do appreciate the comments.

I use authorize.net. I just took an order through my site, and checked to see if there were any cc's populated in the "purge cc data" menu....but there were none. So I assume I'm fine, I guess.

With regard to upgrading my cart, my developer added some mods that I think he said were incompatible with later versions of the software, which is why I'm not eager to upgrade.....it ain't broke now, and could only break on me.

I think it is interesting that anyone evens asks the question as to whether the software is compliant with one payment processor installed vs another.

The nature of the beast is that anyone who accepts cards is responsible for enforcement as well. So, if Paypal (for example) has enough problems with a particular cart, they will eventually start rolling the problem down hill themselves - and cut off access to their services as necessary in order to preserve their own ability to process cards.

David

LMAO

You think paypal.. who takes all payment details outside of the shopping cart, would/will require the store they were sent from to be PCI compliant??

with that logic.. they would also require anyone logging in to their site to be PCI compliant.. and every network connected

People who use 3rd party off site processors have no way from the lack of security on their site/software running to even come close to compromising the processors PCI compliance

to sum it up.. the only ones who even have to think about PCI compliance are the ones who store or transmit those details.. which puts more burden on the SERVER and less on the software.. which is exactly why I said MORE to do with hosting environment than the software.. as if the server doesn't pass.. it doesn't matter what software you have on it

If you think otherwise.. please enlighten the world

Hmm. Seems to me that "payment data" is being used to fulfill the transaction. Cart does that, not so?

David

it depends 100% on the module being used

lets say I only used check/money order

who is going to enforce that my site/server is pci compliant

same would go with any of the other payment methods.. if nothing is stored/transmitted you do not fall under pci compliance (order total and such doesn't apply)

just like the people who do mail order.. take credit card info over the phone.. and enter that data directly into a virtual terminal

nothing stored or transmitted.. they do not fit the list

You are going to lose this argument.. First and foremost.. if the server is not PCI compliant.. nothing else matters.. But even before that, you have to qualify to be PCI compliant.. if you are not.. even the server doesn't matter.. but it does make 100% perfect sense to be on a hardened and secure server..

You will see the same thing though.. once pci compliance is spooned down our throats.. servers/banks will still be compromised.. and they will continue to be bigger and bigger hits.. same applies to spam and such

Anyone can get the "generic" pci compliance scan passed.. as all those scanners out there do not use the same rules.. nor are the perfect (I know of one company when it fails during scanning.. gives you the passing grade)

Jason,

Your approach to this seems awfully cynical. "You have to qualify to be PCI Compliant?" So, some of us can be and others will never be? Bullshit.

Sure, both the server and the software must be compliant. But neither is more important than the other. Compliant software hosted on an insecure server is non-compliant.

Sure, the extent to which a particular merchant is responsible for PCI Compliance varies depending on a number of factors including transactions per year processed, and the processing modality. But the standard itself is quite clear that it applies to everyone who accepts cards. Period.

"It depends 100% on the module being used?" You're sadly deluded.

"Anyone can get the "generic" pci compliance scan passed.. as all those scanners out there do not use the same rules.. nor are the perfect (I know of one company when it fails during scanning.. gives you the passing grade)"

It sounds to me Jason, as though you are arguing that since anyone can lie, every piece of software is automatically compliant and any site can be compliant just by lying, so they automatically are. Under this set of circumstances I'd say your assumption that sites will continue to be hacked is guaranteed.

What I will say is that I believe that sites that make honest efforts to be PCI Compliant will be hacked at a significantly lower rate than those who don't. Enough said.

David

Nice to see a spirited discussion on PCI Compliance.

I and CRE have not said much on the issue in the community until now, because we have been busy learning and then creating a solution, that until we tested and tested again, we did not want to announce it. Now after testing, and Validation by an authorized PCI QSA, Coalfire, Inc. We have something to say on the matter.

#1 PCI applies to the any merchant that has a Merchant Service agreement (a merchant that directly takes credit cards as payments)

It does not apply if you do not take credit card payments. Based on the poll on the forums, (a small sampling indeed) PCI would seem to apply to 40 - 50% of our merchants.

#2 PCI compliance states that all the ways you take card holder data must be compliant. This includes your website, and any physcial terminal boxes. It even extends to your manual processes, what you do with written or printed card data.

#3 At this point we have validated and soon it will be Certified by Visa the entire CRE Loaded shopping line of products. From B2B down to the free CE (formerly Standard).

#4 Having PA-DSS software still requires PCI compliant hosting environment.

#5 Hosting that passes scans DOES NOT alone mean that hosting PCI Compliant.

#6 There are 4 LEVELs of merchant PCI compliance based on volume of Card Data processed, most of you are level 4 (under 20,000 cards processed a year)

#7 For anyone that is level 2 - 4 you can Self-Assess your PCI, but you have to fill out and legally sign the Self-Assessment document, and they are separated into four documents called SAQ's Self-Assessment Questionaires, based on your HANDLING of credit card data.
https://www.pcisecuritystandards.org/saq/index.shtml

#8 If you use authorize.net your site is processing and transmitting credit card data (this is also known as being IN SCOPE of PCI). You will have to use SAQ C or worse D. SAQ C ask you to attest that your are complying with 11 out of the 12 regulations of PCI.

#9 Don't sign the SAQ until you read and checked off the Actual PCI DSS regulation, which is pretty massive.
https://www.pcisecuritystandards.org/se ... ement.html

#10 It is highly unlikely to achieve PCI compliance and reduce the risk of a compromise and or fees and fines if you process or transmit credit cards on commodity shared hosting.

So what are you to do.

Use CRE Secure.

With 6.4 and the journey of PCI compliance we found that merchants needed to get credit card processing off their site. So we created a new service backed solid payment network companies and in partnership with Chase Paymentech and others.

Our new service is offers a FREE hosted payment page that solves two problems, one you know you have PCI, and one created by moving to a Hosted payment page... user experience. To avoid the disjointed user experence, our hosted payment page is not branded by us, it is instead an EXACT replica of your site design.

Using new patent pending technology called HTML Clone(tm) when a customer pays with Credit Card by CRE Secure they are taken to our actual Level 1 certified PCI compliant datacenter but the page looks like its from your site.

You can learn more about it at http://www.cresecure.com

The Hosted Payment Page service itself is free. It works with most existing merchant service accounts from 80% of the major acquiring banks, Chase, First Data, etc. You only have to switch your payment gateway to one of our partners.

For level 4 merchants that use CRE Secure, you can take credit card payments, be PCI compliant, and even avoid the addtional cost of ASV Scans (known as PCI scans) since you can use the SAQ A which does not require the scans, since you are outsourcing your CC handling.

When upgrading to CRE Loaded PCI 6.4 there is a tool to purge any card data you have in the system.

Also please note that we no longer pre-ship with any live payment modules due to Validating the core cart. All the payment existing modules are available for free download at http://www.creloaded.org - in the new Extensions directory.

The reason we took the modules is many fold. I will start with the most obvious. We have invested in the CRE Secure payment system and are offering it free of additional direct fees, for all who want it. Even our free version of CRE Loaded is PCI Validated - the first in the industry.

We cannot maintain other payment solutions in our validated core because now all our development efforts are expanded under regulation to be more rigorous and include more testing and annual third party audits.

We can now focus on the core and the integrated payment solution to make it as solid and robust for merchants and keep it compliant ongoing.

Also we have validated a separate payment module for CRE Secure that works with all previous CRE Loaded carts. So you dont have to upgrade to 6.4 to get PCI Compliance with CRE Secure. You can do use CRE Secure with any CRE Loaded release.

This is going to be an ongoing discussion. I look forward to your comments and feedback.

According to the PCI Standards Organization, Sal :

"What is the definition of "merchant"?

For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard or Visa) as payment for goods and/or services."

This can be found at "http://selfservice.talisma.com/display/2n/kb/article.aspx?aid=5378" and is available from "http://selfservice.talisma.com/display/2n/index.aspx?searchtype=allwords&searchstring=merchant&searchby=keywords&tab=search&search=1" -- talisma.com provides FAQ/Glossary support for the PCI Standards Organization and those pages are reached from the FAQ link at "https://www.pcisecuritystandards.org/".

The FAQ's also state:

"I’m a small merchant who has limited payment card transaction volume. Do I need to be compliant with PCI DSS? If so, what is the deadline?
All merchants, whether small or large, need to be PCI compliant. The payment brands have collectively adopted PCI DSS as the requirement for organizations that process, store or transmit payment cardholder data. PCI SSC is responsible for managing the security standards while each individual payment brand is responsible for managing and enforcing compliance to these standards. For questions regarding compliance validation requirements and deadlines as well as compliance reporting requirements, we recommend that you contact your acquirer. For more information regarding the PCI security standards and supporting documentation, including the “Navigating the PCI DSS” as well as targeted Self Assessment Questionnaires to assist small and medium merchants, please visit the PCI SSC website at: www.pcisecuritystandards.org.

This is the basis on which I stated earlier in this thread that all merchants who accept card payments have to meet PCI Standards. Note that since that was written Discover at least has acquired one more major international card firm. So, its not just those 5 cards, it is ANY CARD THEY OWN.

You might note that the phrase "Merchant Service agreement" was not mentioned in either of those quotes. To reiterate - it don't matter how you get to accept the card, if you took the money, you are responsible for assuring data security. Is this all that hard? Not really.

The first segment of the rules is Build and Maintain a Secure Network and there are only two basic requirements to meet this standard. Thou Shalt Firewall Protect Cardholder Data And Keep It FireWalled and Thou Shalt Not Use Vendor Supplied Default Passwords.

Neither of those is especially hard. Vendor supplied default passwords have been under control for CRE Loaded users since at least the 6.15 release when I had password creation embedded in the installer and pulled all admin side default passwords. (Say thank you, Sal - I TOLD you so!). Any user who doesn't have a firewall on their server is a fool whether they take cards or not. If your customers data means nothing to you, the security of your own business software and data should.

The second segment of the rules is Protect Cardholder Data and there are two requirements. Thou Shalt Protect Stored Cardholder Data and Thou Shalt Encrypt Transmission Of Cardholder Data Across Open, Public Networks. There are a number of approaches to doing this and most of them have been around since Bill Gates was writing assembly language based software on 8 bit machines. Again, it ain't that hard, and it gets even easier if you follow the rest of the rules.

But, that is as many as I've time for tonight.

David

Yes, if you take credit cards your under PCI Compliance regulations.

My specificity on the Merchant Services is due to the availability of pseudo payment solutions, such as 2Checkout which are the merchant service account holder but disperse funds to the store owner. In that case the store owner may not be under PCI because they cannot take a credit card payments directly.

But I do agree that if you need to be aware of PCI and practice compliance if credit cards are a part of your payment options.

Also do not be fooled into thinking that signing the SAQ C means you are actually fullfilling the SAQ C. One breach and you become treated as Level 1 merchant, and have to go through an Audit as well as face the fines of a breach.

Sal,
I have been watching with great interest as you have rolled out CRE Secure. Since I need to become PCI compliant, I am now determining which method of processing cards will do that most effectively for our business. I have a couple of questions based on your post above:



Truly ANY release? Even the old versions? It is not necessary for me to upgrade to a specific version in order to use CRE Secure? Currently we are still running v6.1a.

(I want to upgrade anyway, but don't have time to do that AND become PCI compliant within the month..)




Ok, I have a merchant account with Elavon. BUT, we have only manual terminals right now. So, I assume I have to set up an internet gateway to be able to start processing through our store via CRE Secure. Where do I determine which gateway services will work for me? I really don't know much about the gateways and how they work, can you point me in the right direction of one that will work with Elavon and with CRE Secure? Do you have any customers using Elavon right now?

If this works, I will be very happy indeed that I chose CRE Loaded so long ago....