CiviCRM Community Forums (archive)

Significant update as of 2012-07-11 to this thread I started years ago: see the comment below at http://forum.civicrm.org/index.php/topic,2930.msg106816.html#msg106816

Not sure if folks are aware of the new e-commerce compliance being rolled out this month by Visa, Mastercard, Amex, Discover, etc.: https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf
 
It includes 6.6:
 
Ensure that all web-facing applications are protected against known attacks by applying either of
the following methods:
• Having all custom application code reviewed for common vulnerabilities by an organization
that specializes in application security
• Installing an application layer firewall in front of web-facing applications.
Note: This method is considered a best practice until June 30, 2008, after which it becomes a
requirement.

Some online payment processors I use are indicating that although they set up accounts earlier for my clients to use with CiviCRM, they won't anymore unless they are certified as mentioned above.

I'm willing to contribute some money for a code review of the e-commerce parts of CiviCRM, eg. CiviContribute, CiviEvent, etc. but this seems like an area where there are benefits from doing this together with the community. I'm also willing to spearhead interactions with a quality assurance firm. Lobo has indicated his team would be happy to help / adapt the code to ensure it meets the guidelines.

Are there others who would be willing to pitch in in some capacity?

FYI, below are some additional points in the certification questionnaire that folks may find interesting:

 6.5a       Are all web applications developed based on secure coding guidelines such as the Open Web Application Security Project guidelines?  Help       TWQ1783
Hide Help    The application layer is high-risk and may be targeted by both internal and external threats. Without proper security, cardholder data and other confidential company information can be exposed, resulting in harm to a company, its customers, and its reputation.
     Yes       
     No       
     Not Applicable       
     Compensating Control (describe in comments)       
      
   6.5b      Is custom application code reviewed to identify coding vulnerabilities?    TWQ1784
     Yes       
     No       
     Not Applicable       
     Compensating Control (describe in comments)       
      
6.5c Is prevention of common coding vulnerabilities covered in software development processes, including the following?
    
   6.5.1      Unvalidated input? Help    TWQ1785
Hide Help    Information from web requests should be validated before being sent to the web application.for example, checks for all alpha characters, mix of alpha and numeric, etc., should be done. Without these checks, hackers can pass invalid information into an application and attack components inside the network through the application.
     Yes       
     No       
     Not Applicable       
     Compensating Control (describe in comments)       
      
   6.5.2      Broken access control (for example, malicious use of user IDs)? Help    TWQ1786
Hide Help    Malicious users often attempt to scan and enumerate existing user accounts on applications in order to find an attack entry point. Once an existing account is found, an attacker will try to use default passwords or brute force to access the application.
     Yes       
     No       
     Not Applicable       
     Compensating Control (describe in comments)       
      
   6.5.3      Broken authentication and session management (use of account credentials and session cookies)? Help    TWQ1787
Hide Help    Account credentials and session tokens should be properly protected. Attacks on passwords, keys, session cookies, or other tokens can defeat authentication restrictions and allow hackers to assume other users' identities. Additionally, cookies may store cardholder information and are by default stored in clear text.
     Yes       
     No       
     Not Applicable       
     Compensating Control (describe in comments)       
      
   6.5.4      Cross-site scripting (XSS) attacks? Help    TWQ1788
Hide Help    With these attacks, a web application is used to send an attack to an end user's browser and can result in disclosure of the end user's session token, an attack on the end user's machine, and a hacker's sending spoofed content to fool the user.
     Yes       
     No       
     Not Applicable       
     Compensating Control (describe in comments)       
      
   6.5.5      Buffer overflows? Help    TWQ1789
Hide Help    Hackers can crash web application components that do not properly validate input (see also 6.5.1 above), and may able to take control of processes on the related server.
     Yes       
     No       
     Not Applicable       
     Compensating Control (describe in comments)       
      
   6.5.6      Injection flaws (for example, structured query language (SQL) injection)? Help    TWQ1790
Hide Help    To speed up connectivity and reduce performance at the server end, clientside validation of input and manipulation of data is often required. It is often a relatively trivial exercise for hackers to bypass this checking and use the web application to send malicious commands to the server to initiate attacks such as buffer overflows, or to reveal both confidential information and server application functionality. This is also a popular means of conducting fraudulent transactions on commerce-enabled sites.
     Yes       
     No       
     Not Applicable       
     Compensating Control (describe in comments)       
      
   6.5.7      Improper error handling? Help    TWQ1791
Hide Help    Often, incorrect error handling provides information that helps a hacker compromise the system. If a hacker can create errors that the web application does not handle properly, they can gain detailed system information, create denial-of-service interruptions, cause security to fail, or crash the server. For example, the message "incorrect password provided" tells them the username provided was accurate and that they should focus their efforts only on the password. Use more generic error messages, like "data could not be verified."
     Yes       
     No       
     Not Applicable       
     Compensating Control (describe in comments)       
      
   6.5.8      Insecure storage? Help    TWQ1792
Hide Help    This relates to insecure use of cryptography. Since cryptography applications are difficult to code properly, this frequently results in weak protection of stored data and cryptography that is easier to break.
     Yes       
     No       
     Not Applicable       
     Compensating Control (describe in comments)       
      
   6.5.9      Denial of service? Help    TWQ1793
Hide Help    Hackers can consume web application resources to the point that other users can no longer use the application. Hackers can also lock users out of their accounts or cause the application to fail.
     Yes       
     No       
     Not Applicable       
     Compensating Control (describe in comments)       
      
   6.5.10      Insecure configuration management? Help    TWQ1794
Hide Help    Having a strong server configuration standard is critical to having secure web applications. Servers have many configuration options to control security and are not secure out of the box.
     Yes       
     No       
     Not Applicable       
     Compensating Control (describe in comments)       
      
   

 

Agreed.  IATS (Ticketmaster) just sent us and audit form. If we are not compliant they will either drop us, force us to use their system at a price and/or join SecurityMetrics.com.

Lobo or David, can you give some insight on this?  Is the payment processor in CiviCRM PCI DSS compliant given all the security principles are complete on the server?.

Any recent news on this?
I'm looking into payment options for a client and don't want to offer a solution that is either unworkable or impractical due to costs and complexity of achieving PCI-DSS compliance, if that is even possible with a Civi/Drupal install.

Hey folks. I'm bumping this topic.

I just had a client's IT consultant strongly discourage the use of CiviCRM in-house for accepting credit card transactions over SSL on a self-hosted cart, citing this very issue as the reason why it would open a can of worms that could cost the organization thousands in both development and auditing for compliance.

It's left my client and I looking for an alternative that accepts pass-through payments. We'll find one to finish the project, but certainly it's not the cleanest solution.

there was an org recently (past 3 months) which did a low level PCI DSS check of the code base (basically url scanning and probing). We did pretty well, there was a minor issue reported which was fixed fairly quickly

lobo

We are very interested in this topic as well. We have currently 3 clients who are setting up Moneris credit card payment processing within CiviCRM and I'm being bombarded with questions about CiviCRM PCI compliance. We are also interested in finding solution/chipping in to find definite answer.

I'm doing some research, and here some more information. There are two standards:
1. Payment Card Industry (PCI) Data Security Standard (DSS): The PCI DSS applies to any entity that stores, processes, and/or transmits cardholder data. It covers technical and operational system components included in or connected to cardholder data. If your business accepts or processes payment cards, it must comply with the PCI DSS.

2. Payment Application Data Security Standard (PCI PA-DSS): The PA-DSS is for software developers and integrators of applications that store, process or transmit cardholder data as part of authorization or settlement. It governs these applications that are sold, distributed or licensed to third parties.

3. PIN Transaction Security Requirements: The PCI PTS applies to manufacturers who specify and implement device characteristics and management for personal identification number (PIN) entry terminals used for payment card financial transactions.

References:
https://www.pcisecuritystandards.org/pdfs/pci_ssc_quick_guide.pdf
https://www.pcisecuritystandards.org/security_standards/documents.php?association=PA-DSS
Payment Card Industry Security Standards: https://www.pcisecuritystandards.org/documents/PCI%20SSC%20-%20Overview.pdf
Requirements and Security Assessment Procedures: https://www.pcisecuritystandards.org/documents/pa-dss_v2.pdf

More on Payment Application Data Security Standard for Developers
The PA-DSS minimizes vulnerabilities in payment applications. The goal is to prevent the compromise of full magnetic stripe data located on the back of a payment card or equivalent data from a chip. PA-DSS covers commercial payment applications, integrators and service providers. Merchants and service providers should use certified payment applications and should check with their acquiring financial institution to understand requirements and associated timeframes for compliance.
Payment Application DSS Requirements – Validated by PA-QSA Assessment
1. Do not retain full magnetic stripe, card verification code or value (CAV2, CID, CVC2, CVV2), or PIN block data
2. Protect stored cardholder data
3. Provide secure authentication features
4. Log payment application activity
5. Develop secure payment applications
6. Protect wireless transmissions
7. Test payment applications to address vulnerabilities
8. Facilitate secure network implementation
9. Cardholder data must never be stored on a server connected to the Internet
10. Facilitate secure remote access to payment application
11. Encrypt sensitive traffic over public networks
12. Encrypt all non-console administrative access
13. Maintain instructional documentation and training programs for customers, resellers, and
integrators
14. Maintain instructional documentation and training programs for customers, resellers and integrators

My understanding is that CiviCRM doesn't store or process the payment but does transmit it using payment processing module. Is that correct?

An update - after a long battle with Moneris about new CiviCRM installation for a new client:
Originally, Moneris was requiring quite high level PCI DSS and PCI PA-DSS certification to allow our client to even apply for Moneris merchant account to be used within CiviCRM pages for payment processing. When I finally explained to them that CiviCRM is a PHP application and all we do is to collect and send credit card information to Moneris for processing, the PCI compliance requirements were lowered but still, we were told that PCI Security Scanning is required (scan of network scan of web sites or IT infrastructures with Internet facing IP addresses). The network scan needs to be completed by an Approved Scanning Vendor (https://www.pcisecuritystandards.org/approved_companies_providers/approved_scanning_vendors.php)

Since this is time consuming and costly process (and I'm not convinced that the information we've received is correct), we've decided to go with IATS (http://www.iatspayments.com/english/index.html) to embed their payment processor in CiviCRM (Configuration: http://wiki.civicrm.org/confluence/display/CRMDOC40/IATS+Configuration). I spoke to IATS representative and they had no issue with CiviCRM and no additional requirements in regards to PCI compliance (at least not in Canada).

A summary of what I've learned: I believe that PCI Security Standard Council (https://www.pcisecuritystandards.org/index.php) will have to address issue with open source applications that are not "boxed" solution. Because anyone can modify the code and/or install additional modules, there may be no option to just certify CiviCRM, Drupal or Joomla to be PCI PA-DSS compliant - which means that maybe every single installation of such systems will have to be certified, if the payment processing is embedded on the site. This sounds ridiculous because of the costs and time to test each implementation, not mentioning repeated testing required yearly.
At the moment, we've only delayed finding answers to this problem ...