Salesforce.com and PCI Compliance

• Stumble This
• Digg This
• Share on Delicious
• Share on Facebook
• Tweet This
• Tags: force.com, payments, PCI-DSS

I wrote this in response to a query from a prospective client who needs a payment application developed for their Salesforce.com org. I thought it might be useful to share with the world in general. I welcome any comments and conflicting opinions, as this is an important discussion.

2 documents referenced in my original email are:

• PCI Data Security Standards Quick Reference Guide v2.0
• Payment Application Data Security Standard

Additional documents, including self-assessment procedures, can be found at pcisecuritystandards.org.

The rest is from the email:

The Quick Reference especially useful for anyone needing an overview of the standards. From these documents one can easily see that end to end compliance depends on a number of factors, many of which are the merchant’s responsibility (such as controlling user access and maintaining a secure network).

Now, back to Salesforce:

First, Salesforce.com is not an application, it’s a platform (technically, the platform is referred to as Force.com). As such, it would not normally be subject to PCI compliance, except as it enables the creation of PCI compliant applications and processes. Microsoft Windows is not PCI compliant, neither is Mac OS, Google Android, Apple iOS, etc. It’s the application that matters.

The determination of PCI compliance of any application can be approached one of two ways. For a widely available mass-market application, the vendor could pay a QSA (Qualified Security Assessor) to determine whether the application is PCI compliant. I have no idea how much this costs, but I’m sure it’s not cheap. For a custom application used by one organization, a self-assessment is not difficult. Despite the plethora of documentation associated with the PCI standards, the standards are really very straightforward and easy to understand.

The primary factors in a secure payment application are the storage and transmission of payment information. Additional key factors include logging of activity and access to systems and data.

1. Storage – This one’s easy: Just don’t do it. Payment information should not be stored on the Force.com platform. Although encrypted fields are available, it’s my opinion that access to encrypted data is not sufficiently restricted to comply with PCI standards. So we simply don’t store the information. NOTE: I did discover that it’s possible to set the Force.com debug log to a high enough level that it stores all data entered in a form. This feature is turned off by default and is under the control of the organization’s system administrator. It would normally only be turned on for a specific developer or tester who is testing an application that is being developed. It is also very easy to “turn down” the logging level so that it does not store data entered on a form.
2. Transmission – As required by [the payment gateway], we use SSL (https) for web service calls. This encrypts the data that is transmitted across the Internet. The same process is used by most other payment applications, including eCommerce web sites.
3. Logging – Salesforce automatically logs the date, time and user when a record (such as a payment record) is created or modified.
4. Access – If we’re not storing payment information, access is not much of an issue. In any case, system administrator access should be restricted to a very small number of people. Also, Salesforce has many tools for controlling access to an organization’s data, such as restricting logins by IP address or time of day.