In our last blog, we discussed understanding Payment Card Industry Data Security Standard (PCI DSS) and the misconception that moving to a cloud-based infrastructure for commerce sites will lack security when it comes to cardholder data. As we alluded to, the reality is that this type of approach can enhance security, thus saving your business and your customers the money and the headaches caused by a security breach.
No matter how you host your commerce site, when searching for information on PCI DSS compliance, sources other than the PCI Security Council, such as individual blogs and technical sources can propagate old information, misconceptions, and misinformation related to providing commerce security within the cloud.
For instance, TechTarget published a series of articles on the topic in 2010 which do not consider the characteristics of modern cloud solutions. Though inaccurate, these articles still come up as a top hit when searching on the subject of PCI and Cloud Computing, making it difficult for organizations to find reliable and up-to-date information.
This method of information gathering has created many falsehoods like the insecurity of cloud-based solutions; therefore, we’d like to dive into a few more of the most commonly encountered falsehoods that when understood, can aid in awareness around PCI DSS compliance for your organization.
For many, the fear of PCI and the consequences of making a mistake lead organizations to search for a way to avoid the issue completely. We’ll tackle some of the most popular methods of avoidance including tokenization and hosted credit card capture, as well as system assumptions for compliance and a narrow focus on credit card security. We will consider each of these separately.
Misconception: Adding Tokenization means PCI no longer Applies
Tokenization is the process of sending credit card data to a third-party which stores actual customer data but provides site owners with a reference token. The token itself is no longer considered credit card information. When tokenization of credit card data first started gaining popularity about 10 years ago, many considered their PCI concerns addressed. However, tokenization still sends credit card data from the cardholder’s browser to the system running the e-commerce site, which in turn contacts a tokenization server with card data. With the exception of requirement 3, which deals explicitly with card data storage, every other aspect of PCI would still apply.
Further, many commerce organizations and even security advisers focus only on credit card data associated with orders. Other use cases such as registered customers storing credit cards and customer service systems are at risk of being completely ignored. Because some credit card data is still stored on the systems, even PCI DSS requirement 3 would still apply.
There is still great value in tokenization, particularly in mitigating risks, such as not having historical credit card data stored, or limiing the damage if there is an incident. However, due diligence related to the other 11 requirements is still necessary even when using tokenization. The goal is to prevent an incident and not just limit the damage if one does occur.
Misconception: Hosted Credit Card Capture is all that is needed for PCI
Hosted Credit Card Capture is when a third-party collects credit card data directly from the customer on their servers. Hosted Credit Card Capture comes in a few different forms. The credit card data forms can be completely served by another site, either through a redirect or a frame or in the form of credit card data that can be sent directly from the cardholder’s browser to a third-party site.
In each case, the goal is not only to avoid storing actual credit card data but also to prevent any credit card data from ever reaching company servers. This approach is a marked improvement over simply using tokenization; which, still requires a site’s servers to access raw credit card data. However, it does not exclude commerce sites from PCI DSS requirements, particularly those around requirement 6 and 12. The web site still requires the application of secure development and other security processes.
Consider for example, one of the oldest and most popular solutions which hosts credit card data, PayPal. Sources look to dispel the misconception that PCI is not necessary when PayPal is in use. While PayPal is PCI Compliant and their cloud-hosted site are PCI compliant, it is still important that development practices maintain security on the bridge between these two entities. A cross-site scripting vulnerability could result in a card holder entering data on a site they think is PayPal, but is not. In this example, a malicious internal entity such as a disgruntled developer could collect sensitive data without the proper oversight and checks, increasing risk.
Assessing where your systems interacts with credit card data, both directly and indirectly, and responding appropriately based on PCI DSS requirements is still necessary. Technology solutions will continue to limit PCI related risks but constant diligence is still required.
Misconception: It is not possible to enforce an appropriate level of technical process in the Cloud.
When considering cloud-based commerce, some feel that they cannot apply their development process in such a way to ensure compliance with PCI DSS development requirements.
The reality is that the cloud offers many advantages to typical on-premise development which make it easier to enforce security. Consider again Salesforce Commerce Cloud. As a leader in cloud-based commerce, they offer many advantages to on-premise development. First, the platform and API is secured and exclusively controlled by Salesforce Commerce Cloud. Because development is done on sandboxes within the cloud environment and a developer never has direct access, it is impossible to inject or manipulate core platform code. This is not the case with on-premise platforms, where developers are required to access and therefore potentially manipulate core code, regardless of malicious or benign intentions.
Further, the platform offers robust capabilities related to customization. Therefore, development process must be sufficient to enforce PCI requirements such as code reviews, separation of duties, appropriate access levels, etc. Salesforce Commerce Cloud provides capabilities built into the platform including two-factor authentication for code deployment, inability to deploy code directly to production, and existing ‘build’ processes to easily integrate static code analysis and enforce organizational security policies.
Enforcing a technical process for PCI Compliance is in fact much easier with platforms like Salesforce Commerce Cloud.
Misconception: Systems will remain PCI Compliant if they are not Changed
Unfortunately, in our ever changing world of technology nothing remains set for long. PCI requirements change, and with them come new requirements on how to comply. Further, technology changes bring with them more security and compliance. Vulnerabilities can be discovered in existing technologies. All of these factors lead to higher levels of maintenance just to maintain PCI Compliance.
Fortunately, a cloud based platform helps address many aspects of this maintenance. In addition to the overall security benefit of the cloud described previously, the ability to continuously update the platform for new PCI requirements takes away much of the technical burden. Changes such as restriction of SSL and TLS 1.0 can be made by the cloud provider as part of their infrastructure, as well as API without intervention or effort.
Even with static systems in the cloud it is important to be aware of new requirements. An analysis of how changes will impact existing code should be done with each release. The PCI Security Council provides a summary of changes to help facilitate this analysis and should be referenced often.
Misconception: Credit Card Data should be the only Focus of Security
PCI specifically deals with credit card data and its handling. With a focus on securing credit card data, it may be easy to forget that this is not the only data which should be protected. Other data deserves equal care including personal identifiable information (PII) and medical data (HIPAA) and other data which may need to be protected for business reasons, including intellectual property, promotional information, and future product information.
When considering securing data and secure development practices, make sure to apply the same principles and best practices to any data which could be compromised. Fortunately, the cloud-based security benefits mentioned for PCI also apply for other data stored in the cloud.
Through awareness and attention on the standards as well as best-practices, you can ensure PCI compliance and overall security for your customers. When in doubt, it is recommended that you begin by reviewing the latest standards and by seeking PCI consultation from experts.
VP, Salesforce Commerce Cloud Practice