Now that you’ve been introduced to service providers (see “Addressing the Magic Bullet – Part 1” from our “Common Misconceptions around the Payment Card Industry Data Security Standard (PCI DSS)” blog series) and what you should look when involving them in PCI DSS compliance, let’s make things a little more complicated. If your use of a service provider includes one that provides any type of PCI DSS compliant software as a service (SaaS), backend applications and hosted data, or full environment hosting, or if you choose to utilize those services from a service provider, determining shared responsibilities around the security of the application of these environments is one area where cutting corners can be detrimental and bring a company to their knees in the event of a breach.
“Why?” you may ask. “I’ve done all you said about picking a PCI DSS compliant vendor and I check all the boxes on my own PCI DSS attestation. I’m covered.”
When thinking about the use of a hosted application or environment, there’s a lot to consider across each of the PCI DSS controls. This is where some of the complexity with control responsibility comes into play and why it’s important to take a close look at the responsibility matrix from a vendor. As mentioned in Part 1, the responsibility matrix is a document that will clearly lay out what controls you are responsible for and what controls the service provider is responsible for. In working with a service provider who provides a hosted application or application environment, there are three key types of shared responsibility models when it comes to application deployment and access:
- Service provider hosted applications (SaaS model) – Service providers who provide a web-based frontend to users to access an application that interacts with cardholder data. The application is both developed and hosted on the service provider’s infrastructure.
Ex: a vendor website that provides a portal login to process and review transactions that have been performed within the organization.
- Integrated applications – Applications, either service provider or company developed, that use API calls from a customer’s environment to integrate with the service provider’s environment.
Ex: a company utilizes a desktop application that provides credit checks by integrating with service provider’s application servers and databases.
- Hosted infrastructure – Applications developed or maintained by the customer that are deployed onto infrastructure hosted within a third party data center. The customer may have some level of access to the underlying infrastructure and may be responsible for PCI DSS controls outside of application development.
Ex: a company hosts a custom web-facing application and backend database that is run on service provider infrastructure.
Each of these shared responsibility models has a unique set of challenges when determining who is responsible for management of access to applications and the data they contain, and we will explain some of those in more detail below. For an overview of how West Monroe Partners approached this challenge for a recent client, see the blog post “Controlling Inbound and Outbound Traffic Flow in an Azure-based Cardholder Data Environment.”
Service Provider Hosted Applications
Within service provider hosted applications, the majority of PCI DSS control responsibility falls onto the service provider, so the shared responsibilities in this scenario are the most straightforward for a customer. Per newly introduced clarification around PCI DSS version 3.2 Requirement 8, the controls around user access to applications only applies to accounts that have access to view cardholder data or the ability to impact the security of cardholder data. Cardholder accounts (e.g., consumer accounts) do not have to adhere to the same application access controls.
In the hosted application model, it’s important to understand specifically which controls your organization is responsible for when it comes to your employee’s accounts, as the application may allow you to maintain specific account controls.
Within the integrated applications service provider model, the company may have use of an API, vendor provided application, or other means to interact with customer data. This method relies on the secure use of that API key within applications, but increases the amount of PCI DSS controls that fall back onto your organization. While the service provider may be responsible for the security of any data once sent to their systems, additional controls such as user account provisioning may be your responsibility as the customer. Controls around data encryption and logging and monitoring may also apply to your organization, depending on the specific application used and the design of the business process by both the service provider and you as the customer.
Hosted infrastructure gathers the most amount of scrutiny from the PCI Security Standards Council, to the point where they’ve added an additional appendix within the PCI DSS for Shared Hosting providers. The tools used for securing access to application data and whom the maintenance of those controls falls on to can vary greatly between service providers and what services they offer. When engaging with a vendor that provides access to OS-level resources, or provisions those resources out to your customers, ensure there is a very clear delineation of controls between each party. Some of the common areas that get overlooked are determining the answers to questions like:
- Who is responsible for encrypting application credentials?
- Who is responsible for logging and monitoring / review?
- Who is responsible for performing penetration testing and vulnerability scanning?
Each of these areas impacts the security of the application, and assists with establishing controls around how access to an application, or its underlying data, in a secure manner. Additionally, you as the customer would need to be provided a method to enforce controls that the service provider claims are the customer’s responsibility.
Utilizing a service provider is a great way to alleviate some of the stress around the increasingly rigorous PCI DSS controls; however, it’s important to understand exactly what PCI DSS controls are maintained by the vendor to properly understand the scope of those PCI DSS controls.
Are you ready to go back and review that responsibility matrix? While there are many different approaches to application and environment security, should you choose a service provider who provides the application, or allows the business to host their own, a crucial part of the process is determining which party is responsible for what PCI DSS controls. If this process has already been performed with a service provider that’s currently engaged, ensure they are keeping up with the PCI DSS standard. An explanation of the changes that are included in PCI DSS version 3.2 are covered further in a previous blog post, “What PCI DSS Version 3.2 Means For You.”