X-Cart forums

[BritSteve]

Originally Posted by xplorer

Since X-Payments will be isolated from X-Cart and other web applications installed on your server, hackers won't be able to hack X-Payments via a bug in other applications.

How can x-payments be isolated from x-cart and still be safe? If someone hacks into the webserver through an exploit in any application running on the server, then they can potentially change x-payments to do anything they want. This could include capturing the payment details and sending them somewhere else?

It is not impossible for some of these exploits to give root access.

Steve

[geckoday]

Originally Posted by cflsystems

Then why not just make X-Cart PCI-DSS instead of developing a new application to handle this? Originally I was under the impression XPayments will be integrated part of xcart store not almost like payment gateway

For PA-DSS compliance it is best to separate out the payment functions as a module to reduce the scope of what you have to pay a PA-QSA to validate and minimize the code you have to ensure meets PA-DSS requirements. That doesn't mean it must be turned into the equivalent of a payment gateway firewalled away from your application on a separate server or VPS. In fact, the category X-Cart would fall into in the PCI-SSC list of PA-DSS validated applications is "Shopping Cart & Store Front". There are two direct competitors to X-Cart on that list and neither forces you to split the payment process out to a separate server or VPS.

X-Payments, if designed properly, could easily be a separate module from the core of X-Cart, be PA-DSS validated without having to validate the core of X-Cart and fit transparently into the existing X-Cart checkout process.

[Duramax 6.6L]

Originally Posted by BritSteve

How can x-payments be isolated from x-cart and still be safe? If someone hacks into the webserver through an exploit in any application running on the server, then they can potentially change x-payments to do anything they want. This could include capturing the payment details and sending them somewhere else?

It is not impossible for some of these exploits to give root access.

Steve

That's what I thought, but I'm no expert. I would have thought that xcart would be made compliant, not add a seperate module, that cost more money to run.

[xplorer]

Thanks for the information!

If so, I guess it is allowed to install X-Payments on the same server with X-Cart provided the shared server satisfies the requirements listed in Appendix A.

As far as I understand, it will put all web applications installed on the server into PCI DSS scope. So, you will have to satisfy the requirements listed under "Requirement 6: Develop and maintain secure systems and applications" section:

1. Ensure that all system components and software have the latest vendor-supplied security patches installed. Install critical security patches
2. Establish a process to identify newly discovered security vulnerabilities (for example, subscribe to alert services freely available on the Internet)
3. Develop software applications in accordance with PCI DSS (for example,
   secure authentication and logging) and based on industry best practices, and
   incorporate information security throughout the software development life cycle
4. Follow change control procedures for all changes to system components
5. Develop all web applications (internal and external, and including web administrative access to application) based on secure coding guidelines such as the Open Web ApplicatioN Security Project Guide
6. For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:
   • Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes
   • Installing a web-application firewall in front of public-facing web applications

I believe the 3rd and the 5th requirements apply to all custom modifications to X-Cart and other web applications installed on the server.

[cflsystems]

Originally Posted by geckoday

For PA-DSS compliance it is best to separate out the payment functions as a module to reduce the scope of what you have to pay a PA-QSA to validate and minimize the code you have to ensure meets PA-DSS requirements. That doesn't mean it must be turned into the equivalent of a payment gateway firewalled away from your application on a separate server or VPS. In fact, the category X-Cart would fall into in the PCI-SSC list of PA-DSS validated applications is "Shopping Cart & Store Front". There are two direct competitors to X-Cart on that list and neither forces you to split the payment process out to a separate server or VPS.

X-Payments, if designed properly, could easily be a separate module from the core of X-Cart, be PA-DSS validated without having to validate the core of X-Cart and fit transparently into the existing X-Cart checkout process.

Thanks for the clarification. I understand better now why all the trouble with separate module.

[geckoday]

Originally Posted by xplorer

Thanks for the information!

If so, I guess it is allowed to install X-Payments on the same server with X-Cart provided the shared server satisfies the requirements listed in Appendix A.

As far as I understand, it will put all web applications installed on the server into PCI DSS scope. So, you will have to satisfy the requirements listed under "Requirement 6: Develop and maintain secure systems and applications" section:

1. Ensure that all system components and software have the latest vendor-supplied security patches installed. Install critical security patches
2. Establish a process to identify newly discovered security vulnerabilities (for example, subscribe to alert services freely available on the Internet)
3. Develop software applications in accordance with PCI DSS (for example,
   secure authentication and logging) and based on industry best practices, and
   incorporate information security throughout the software development life cycle
4. Follow change control procedures for all changes to system components
5. Develop all web applications (internal and external, and including web administrative access to application) based on secure coding guidelines such as the Open Web ApplicatioN Security Project Guide
6. For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:
   • Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes
   • Installing a web-application firewall in front of public-facing web applications

I believe the 3rd and the 5th requirements apply to all custom modifications to X-Cart and other web applications installed on the server.

Yes and no. It depends on your merchant level and implementation. If a merchant storing card numbers or otherwise is required to fill out SAQ D or is level 1 or 2 and therefore has an assessment done by a QSA then yes, all of requirement 6 applies. But if a merchant is level 3 or 4, is not storing card data and the web server has no connection to any other systems in the merchant environment then no. In this case the merchant is eligible for SAQ C. Under SAQ C the only requirement 6 subrequirement that is listed as applicable is 6.1 - applying security patches.

For the small internet merchant, SAQ A & C are your friends. SAQ D is a nasty tar pit you don't want to step in with 238 complex requirements that a small merchant can't realistically meet. If you are OK with 100% outsourcing (Paypal, Authorize.Net SIM, etc.) and never handling card numbers yourself then SAQ A is the way to go as you have virtually no requirements to meet (11 simple requirements). But the more normal situation is you want the payment integrated into your web site and have a need to take phone orders, etc. Then you should target SAQ C by not storing card numbers. SAQ C has 38 requirements without all of the hard stuff for a small merchant to meet. These merchants are the typical X-Cart customer. For these customers only 6.1 applies.

[Steel]

Originally Posted by geckoday

For the small internet merchant, SAQ A & C are your friends. SAQ D is a nasty tar pit you don't want to step in with 238 complex requirements that a small merchant can't realistically meet. If you are OK with 100% outsourcing (Paypal, Authorize.Net SIM, etc.) and never handling card numbers yourself then SAQ A is the way to go as you have virtually no requirements to meet (11 simple requirements). But the more normal situation is you want the payment integrated into your web site and have a need to take phone orders, etc. Then you should target SAQ C by not storing card numbers. SAQ C has 38 requirements without all of the hard stuff for a small merchant to meet. These merchants are the typical X-Cart customer. For these customers only 6.1 applies.

Hello Ralph,

It seems that X-Payments amounts to a gateway, and it seems logical that whoever manages it will have to deal with the "nasty tar pit" SAQ.

In studying other compliant shopping carts, it seems that X-Cart is already employing security features that would allow users to meet SAQ Validation Type 4 / SAQ C with a 3rd party gateway, and may only be a matter of certification, which could just amount to a set of instructions that describe X-Cart user settings/code removal/monitoring/etc. for the various PCI Data Security Standard requirements 1-12 and A1.

Can anyone confirm if some type of 3rd party gateway is required to qualify for SAQ Validation Type 4 / SAQ C compliance?

[geckoday]

Originally Posted by Steel

Hello Ralph,

It seems that X-Payments amounts to a gateway, and it seems logical that whoever manages it will have to deal with the "nasty tar pit" SAQ.

Nope. From the description of X-Payments it sounds like its designed like a gateway to modularize it away from the core X-Cart code - sort of a gateway to gateways. But it shouldn't have the requirement of storing card numbers that a third party gateway does. If X-Payments doesn't store card numbers or can be configured not to store card numbers and you are a level 3 or 4 merchant you could host X-Payments on your own server and fill out SAQ C.

Originally Posted by Steel

In studying other compliant shopping carts, it seems that X-Cart is already employing security features that would allow users to meet SAQ Validation Type 4 / SAQ C with a 3rd party gateway, and may only be a matter of certification, which could just amount to a set of instructions that describe X-Cart user settings/code removal/monitoring/etc. for the various PCI Data Security Standard requirements 1-12 and A1.

Mostly true but you really have to put X-Cart up against the PA-DSS standard. I haven't looked at X-Cart 4.3 yet but earlier versions are missing a few requirements particularly around key management. PA-DSS requires documented software development processes and other behind the scenes processes that Qualiteam may or may not have in place. Certification is quite a bit more extensive than just providing an implementation guide. It requires a review by a PA-QSA including validating development processes, penetration testing and forensic testing and costs tens of thousands of dollars.

Originally Posted by Steel

Can anyone confirm if some type of 3rd party gateway is required to qualify for SAQ Validation Type 4 / SAQ C compliance?

Not required by PCI-DSS, but anyone small enough to fill out an SAQ will never get certified to go direct to the big payment networks like Visanet. That's the whole reason gateways exist - to insulate the big processing networks from the small fry.

[neal]

Hi,

Since XC5 is going to be delayed till Summer 2010, what about us LiteCommerce Users??

Will QT make LiteCommerce PCI-DSS / PA-DSS compliant as well?

Please make this clear!!!


Thanks!

[Steel]

Originally Posted by geckoday

If X-Payments doesn't store card numbers or can be configured not to store card numbers and you are a level 3 or 4 merchant you could host X-Payments on your own server and fill out SAQ C.

Just so I understand what you are saying, only in the event that you physically host your own server will you be able to avoid the SAQ "tar pit". If someone hosts this server for you, then they will be considered a service provider, and in scope, and in the "tar pit"?