Documentation You are here: start » primer » security

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
primer:security [2011/05/26 22:16] – fixing UOE link foxybrettprimer:security [2020/10/09 20:36] (current) – [One of my customers reported their card was stolen!] foxybrett
Line 26: Line 26:
  
 ==== What Are Your Compliance Requirements? ==== ==== What Are Your Compliance Requirements? ====
-Though we cannot tell you with certainty what your compliance requirements may be, we can offer a set of guidelines that may help you discern when you do actually need to pay for a service to become compliant (and conversely, when you're being sold misinformation or FUD). This is not an exhaustive list of scenarios, and [[http://www.pcicomplianceguide.org/pcifaqs.php#6|more information is available]] at the PCI DSS site if you need clarification.+Though we cannot tell you with certainty what your compliance requirements may be, we can offer a set of guidelines that may help you discern when you do actually need to pay for a service to become compliant (and conversely, when you're being sold misinformation or FUD). 
  
 <wrap tip>If you're being told by your merchant account provider or gateway that you need to pay a fee</wrap> to become compliant, be sure to understand the actual requirements. In many cases you may not need a scan at all, and your SAQ requirements may be quickly and easily completed without paying any additional fees. <wrap tip>If you're being told by your merchant account provider or gateway that you need to pay a fee</wrap> to become compliant, be sure to understand the actual requirements. In many cases you may not need a scan at all, and your SAQ requirements may be quickly and easily completed without paying any additional fees.
  
-SAQ Required Scan Required ^ How you collect payments ^+SAQ_Level Scan_Required ^ How you collect payments ^//Italic Text//
 | None | No | <WRAP> | None | No | <WRAP>
-  * Payments are //only// handled on a 3rd party system such as through PayPal Express Checkout or Google Checkout through FoxyCart. (These types of payment methods are fundamentally different than a "real" gateway in that the funds are transferred first to the 3rd party (ie. PayPal), then transferred to you. PCI DSS generally only applies to merchants with a Merchant ID, receiving payments directly.)+  * Payments are //only// handled on a 3rd party system such as through PayPal Express Checkout or Pay with Amazon through FoxyCart. (These types of payment methods are fundamentally different than a "real" gateway in that the funds are transferred first to the 3rd party (ie. PayPal), then transferred to you. PCI DSS generally only applies to merchants with a Merchant ID, receiving payments directly.)
 </WRAP> | </WRAP> |
 | SAQ A | No | <WRAP> | SAQ A | No | <WRAP>
-  * Payments are handled through your store's FoxyCart checkout using a "real" gateway (ie. a gateway that doesn't redirect the customer to their own hosted payment page).+  * Payments are **fully outsourced** handled through your store's FoxyCart checkout using a "real" gateway (ie. a gateway that doesn't redirect the customer to their own hosted payment page).
   * Payment card details are never handled on the phone or using FoxyCart's [[:static:redirect:unified_order_entry|Unified Order Entry]] or with any other virtual terminal.    * Payment card details are never handled on the phone or using FoxyCart's [[:static:redirect:unified_order_entry|Unified Order Entry]] or with any other virtual terminal. 
 +  * No cardholder data transmission, ever. (ie. No computer or server under your control ever touches card numbers, anywhere, ever, at all. Not even getting the numbers POSTed and immediately sending them off to a 3rd party.)
   * No cardholder data storage, ever. (ie. You never store card numbers, anywhere, ever, at all.)   * No cardholder data storage, ever. (ie. You never store card numbers, anywhere, ever, at all.)
 +  * <wrap tip>No fees</wrap> should be charged by your merchant account provider if you fall under PCI SAQ A (unless breach insurance is required, which is discussed below).
 </WRAP> | </WRAP> |
-| SAQ | No | <WRAP> +| SAQ A-EP | No | <WRAP> 
-  * Payments are handled through standalone terminals or are swiped using a machine+  * Payments are  **partially outsourced**. This gets a little technical, but this applies if you're doing a direct post or javascript-based (non-iframe) implementation. In general, using FoxyCart avoids this
-  * No cardholder data storage, ever(ieYou never store card numbers, anywhere, ever, at all.)+  * <wrap tip>Fees</wrap> may be required for a security scan for PCI DSS §6.6
 </WRAP> | </WRAP> |
-| SAQ C | Yes... | <WRAP> +SAQ B \\ SAQ B-IP \\ SAQ C \\ SAQ C-VT No | <WRAP> 
-  * Payments are entered with a virtual terminal connected to the internet. Systems used to access the virtual terminal may need to be scanned by an ASV+  * These SAQs aren't applicable to ecommerce merchants
-  * No cardholder data storageever. (ie. You never store card numbersanywhere, everat all.)+  * Payments are handled through standalone terminalsare swiped using a dedicated machineprocessed manually on an internet-connected virtual terminaletc.
 </WRAP> | </WRAP> |
 | SAQ D | Yes, on applicable systems | <WRAP> | SAQ D | Yes, on applicable systems | <WRAP>
-  * Cardholder data is stored on systems you control, regardless the payment methods. Systems that store cardholder data will need to be fully PCI compliant and scanned by an ASV.+  * If you don't fit under the above SAQs, SAQ D is what you fall under. 
 +  * Cardholder data is transmitted or stored on systems you control, regardless of the payment methods. Systems that transmit or store cardholder data will need to be fully PCI compliant and scanned by an ASV
 +  * If you have servers or hosting that touches credit cards at all (//even if it's just a POST to your website that then sends it to the gateway//), you fall under the SAQ D. Just because you don't store card numbers doesn't mean anything. 
 +  * This is full PCI DSS compliance, 200+ requirements, though some of them may not apply. If you //can// avoid this, you //should//. There are many solutions (including FoxyCart) that give flexibility without exposing your systems to cardholder data.
 </WRAP> | </WRAP> |
  
-Additionally, there are different [[http://www.pcicomplianceguide.org/pcifaqs.php#5|merchant 'levels']] that you should be aware of if you're doing more than 20,000 Visa transactions per year.+Additionally, there are different [[https://www.mastercard.us/en-us/merchants/safety-security/security-recommendations/merchants-need-to-know.html|merchant 'levels']] that you should be aware of if you're doing more than 20,000 Visa transactions per year.
  
-<wrap tip>If you can limit your exposure to PCI DSS, we recommend it.</wrap> Because there is no way to get a fully branded checkout experience without at least some level of PCI compliance, we generally recommend not using any virtual terminal functionality and completing the very short [[https://www.pcisecuritystandards.org/security_standards/documents.php?category=saqs|SAQ A]]. If you do need to use a virtual terminal, you'll likely be required to do the [[https://www.pcisecuritystandards.org/security_standards/documents.php?category=saqs|SAQ C]]. The one thing you really (really) don't want to do is store credit cards on your end, as the requirements become //very// complex and costly. And since FoxyCart handles this storage for you, there's little reason to spend the months or years and many thousands of dollars on becoming compliant at that level.+<wrap tip>If you can limit your exposure to PCI DSS, we recommend it.</wrap> Because there is no way to get a fully branded checkout experience without at least some level of PCI compliance, we generally recommend not using any virtual terminal functionality and completing the very manageable SAQ A. If you do need to use a virtual terminal, you'll likely be required to get a bit more advanced (possibly the SAQ D, though if you're using Foxy, many of the requirements won't actually apply). The one thing you really (really) don't want to do is store credit cards on your end, as the requirements become //very// complex and costly. And since FoxyCart handles this storage for you, there's little reason to spend the months or years and many thousands of dollars on becoming compliant at that level
 + 
 +==== Becoming PCI Compliant ==== 
 +Your PCI DSS compliance will most likely be addressed when you set up a [[.:the_pieces#all_the_piecesthe_traditional_approach|merchant account]], though sometimes it will happen after the initial setup. As mentioned above, some processors have converted PCI DSS compliance into a profit point by tacking more onto the fees. 
 +  * Some processors charge $149 annual PCI compliance fee plus another $99 annual fee. (This is generally pure profit for the provider.) 
 +  * Others charge up to $19.95 per month on PCI compliance fees. 
 +Again: <wrap tip>Simply paying for a service will not make you PCI compliant</wrap>, as compliance can involve things like security training, paper shredding, and business policies and procedures that simply cannot be addressed by paying a 3rd party a monthly fee. So if your merchant account provider or gateway tries to sell you on any services, make sure you actually need them (per the table above). 
 + 
 +==== Breach Insurance ==== 
 + 
 +Breach insurance covers the merchant and processor in the event the merchant is PCI compliant but a breach occurs nonetheless. An example is a gas station with pay at the pump. Some people go into the convenience store to buy munchies and then leave the credit card at the counter to fill up the tank. That exposes the merchant to credit card number theft by any employees working behind the counter. This type of CC theft also happens very often in restaurants when waiter/waitresses carry the cards back to the cash register. 
 + 
 +If you are concerned about this type of issue, your merchant account provider may be able to provide this for you. [[http://www.foxycart.com/features/feature/payment-methods/payment-gateways|Our recommended gateway partner]] provides breach insurance included at no extra cost (so long as you keep your SAQ up to date, which they provide a tool to assist with as well).
  
 ==== So What About FoxyCart's Compliance? ==== ==== So What About FoxyCart's Compliance? ====
Line 59: Line 76:
  
  
 +==== Summary: What to do if you're being told you need to be compliant ====
 +If you're being told you need to be compliant and you don't have time to read all of the above, and //**assuming you don't process cards outside of your FoxyCart setup**//, here's the rundown:
 +  - Copy/paste this to your provider: <code>
 +We've outsourced our card handling to FoxyCart, which is a Level 1 PCI Compliant Service Provider listed on both Visa and MasterCard's registries. You can see their AOC here:
 +
 +https://wiki.foxycart.com/static/foxycart_security
 +http://www.visa.com/splisting/
 +http://www.mastercard.com/us/company/en/whatwedo/compliant_providers.html
 +
 +Do you still require that we provide proof of our own compliance? If so, do you have your own tool that we should use, or will providing the SAQ A be sufficient?</code>
 +  - If they respond that they have their own tool, you should be able to fill that out. Otherwise, complete and send to them the PCI SAQ A. (Get the latest version from [[https://www.pcisecuritystandards.org/|PCISecurityStandards.org]] directly.)
 +  - If they respond that you must be compliant at a higher level, or that they need proof of a passing security scan, or something else, please let us know.
 +===== One of my customers reported their card was stolen! =====
 +
 +We occasionally get emails like the following from FoxyCart users:
 +
 +<blockquote>We got a call a day ago from a customer who stated that his AMEX had $4K of fraudulent charges. He said that after a purchase on our FoxyCart-powered site, his credit card details were taken and then used elsewhere.</blockquote>
 +
 +FoxyCart goes through extensive security reviews and audits constantly. We have intrusion prevention and detection. We monitor the logs. We're proactive about security. We handle millions of transactions for thousands of merchants all over the world. We receive only one or two reports of a compromised card each year.
 +
 +Though it's certainly possible we have a security breach on our end, it's far more likely that your customer's computer is compromised. The customer should wipe their computer, and/or toss it and get a new one. 
 +
 +Where FoxyCart has numerous safeguards in place, your customer's computer is a personal computer that may or may not be running antivirus and anti-malware. The customer uses it to browse the web and may not have the latest OS and browser security updates installed. The customer uses the computer to receive email, possibly on an older or unpatched email client. The customer's computer may be available to others (partners, spouses, children, friends) who visit questionable websites, download pirated software, clicked on an email attachment they shouldn't have, etc. There are myriad ways for the customer's computer to be compromised. Once that happens, as soon as they enter a credit card number anywhere (whether that's FoxyCart, Amazon, or their gas company's website), a keylogger can grab that, send it to the attacker, and their card is immediately compromised. 
 +
 +If this has happened to you or your customer and you'd like to loop us in to discussions, feel free. We take this extremely seriously. It's theoretically possible that FoxyCart had a security breach, and only one single customer was impacted, but the far more likely scenario is that the customer's computer has a virus or other malware. (We once had this happen where the customer said, "I never shop online because //every time// I buy something online, my card gets stolen." The problem is obvious to those of us who've spent time scrubbing malware off friends' and family's computers, but the average computer user places far too much trust in their own computer's security.)
  
 ===== Bad Ideas: Email and Sensitive Information ===== ===== Bad Ideas: Email and Sensitive Information =====

Site Tools