The Third Party Dilemma

I am starting to see more and more of this situation with my mid-size and larger clients, the third party that is using the client’s network to process and transmit cardholder data (CHD).

Where I consistently encounter this are at internal cafeterias where a third party operates the cafeteria and is providing their own point of sale (POS) solution to process card transactions. Another example where this is common are mailrooms that are operated by third parties and employees can buy stamps and ship personal packages with the third party taking cards for payment. Finally, another place where this is common is health care facilities, particularly hospitals, where the cafeteria is operated by a third party, the gift shop is operated by another third party, the pharmacy is operated by a third party and so on. As we go forward, I would expect that this situation will become more and more commonplace as organizations outsource more and more back office functions to third parties and focus on their core business.

A lot of these third parties have ended up on clients’ networks. They may or may not have been segmented away from the rest of the client’s network, but they typically sit behind the clients’ firewalls and other security measures. With the focus on requirements 12.8 and 12.9 regarding the management of third parties, these outsourcing environments are receiving new scrutiny as clients begin reassessing how these third parties are provided network and Internet access as well as PCI compliance, contract and other regulatory and legal issues.

So what are your options if you are involved in such arrangements? Here are some thoughts.

  • Ignore the problem and hope it goes away. Yes, believe it or not there are a lot of organizations that have found out that their organization is chock full of such situations and have just tossed up their hands and have decided to put off addressing the issue. Unfortunately, if the organization is required to perform a PCI assessment, this is not an option and they end up having to address it as part of their own assessment. Unfortunately, the problem does not go away because the third parties ask for an AOC of the organization for the network services they are providing.
  • Wide Area Ethernet. In this scenario, your organization becomes a telecommunications carrier providing Internet access to any third party over a separate WAN. This requires Ethernet WAN or Metro Ethernet equipment that support WAN grade service versus LAN grade service. Third parties are provided access to the Internet but must provide their own infrastructure such as firewalls and switches. The bottom line is that your organization becomes no different than any other carrier such as Verizon or AT&T and will be out of scope.
  • Wide Area Wi-Fi. Similar to Wide Area Ethernet using the same WAN infrastructure equipment but using Wi-Fi (802.11a/b/g/n/ac) to deliver network access. While this avoids installation of wiring infrastructure, it means a separate secured Wi-Fi network from your existing Wi-Fi. In addition, depending on how it is engineered, it could suffer from device overload if all of your third parties are in the same general area of your facility. But as with Wide Area Ethernet, your organization is considered a carrier and out of scope.
  • Another wireless alternative is putting your third parties on cellular connections. Where this can be problematic is in facilities that have poor cellular connectivity. In these situations, the organization may have installed cellular repeaters for carriers throughout the facility to improve cellular signals. However, not all of the facility may have repeater coverage where the third parties are located so there could be additional costs involved to get the coverage needed. Like Wi-Fi, cellular repeaters have limitations on the total number of connected devices, so areas where employees and the third parties congregate such as cafeterias could have issues with cellular access at breakfast, lunch and dinner times. This can be mitigated, but could create service issues for all users at heavy usage times.
  • P2PE or E2EE. Use of either of these solutions depends on your third party’s ability to use such a solution with their POS. With these solutions, you can create a separate VLAN for your third parties and they can all attached their points of interaction (POI, aka card terminals) to that VLAN and the traffic will be encrypted out to their respective processors. Where this solution does not work is when the third party uses a POS solution that does not support P2PE/E2EE. In addition, if all your third parties do not support P2PE/E2EE you may have to have a second solution for them. So it may be simpler to use one of the other solutions for consistency.
  • Physically Separate Third Party Network. This is a feasible option if you want to avoid the Wide Area equipment costs and requirements. However, the equipment used must be physically separate from your existing LAN equipment so as to qualify as being considered a carrier versus a service provider. As with the Wide Area solutions, you will not be providing firewalls or any other security services, just access to the Internet. Any security measures on this network would be the responsibility of each third party.
  • Separate Third Party VLAN. This is the option I typically encounter in most organizations. The organization’s network has a VLAN separate from its other networks but still relying on the organization’s infrastructure. The problem here is that this is not a carrier network because it is not physically separate from the internal network. Yes, there are ACLs in place that isolate the VLAN from others, but the infrastructure is shared and could come into scope if changes cause that to happen. This can still be acceptable if all third party traffic is encrypted such as with a VPN or P2PE/E2EE. But where this solution gets into trouble is when the organization providing the VLAN is also doing the encryption on behalf of the third parties. In the end, a VLAN solution will have to be assessed as a service provider because the organization is providing network access as a service not as a carrier.
  • Contract with their own carriers. This is an option, but potentially a rather messy option. That is because your third parties will need to contract with their own carrier which could create a wiring nightmare in your facilities. Particularly when new third parties come in or change carriers. There are ways to manage this but it requires planning and working with your third parties to make this effort successful.

These approaches all have their pluses and minuses, but hopefully you now have some ideas as to how to handle this issue.


12 Responses to “The Third Party Dilemma”

  1. May 17, 2016 at 1:47 PM

    Hi, I’m doing SAQ-Q. Req 12.8.2 requires a written statement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process, or transmit on behalf of the customers. Now I have got a copy of AOC from our service provider, should I still ask for that written statement? Thanks.

    • May 17, 2016 at 2:05 PM

      The AOC would be sufficient evidence that they are responsible for the security of cardholder data. That said, I also like to ensure that any service provider contracts also have provisions for protection of their customers’ data in the contract (most have such language). It is up to you as to if you want to take it that far.

  2. 4 Owen
    August 19, 2015 at 8:42 AM

    Where does responsibility lie if a third party on our network decides for themselves to take card payments without informing us?

    Are they ultimately liable for any breaches? It seems a bit harsh if we got fined for losing card details we never knew we had.

    I’m guessing a breach would be their fault if we had no contract with them saying we would manage it and then either make them remove the payment mechanism or they would have to pay us to make whatever changes are needed?

    • August 21, 2015 at 5:32 AM

      Good question and one for the courts to decide.

      That said, it is your network and it is your responsibility to know what is going on over your network. So you should periodically be inquiring of your third parties as to what they are doing on your network.

  3. 6 mtcjayne
    August 14, 2015 at 2:54 PM

    I just recently started looking into InnGenius. The company behind it claims it is PCI compliant (though I haven’t verified this.) The “cloud” based software that uses a web interface can use PCI compliant card swipe machines with for both driver’s licenses and payment cards. It also allows online bookings through another product they offer called InnConnect, which can store customer credit card data when reservations are made and make it available through InnGenius.

    I don’t know, however, what requirements I’m exposed to if I decide to use it on a machine at work. How do I go about assessing whether or not the machine and network used to access the web interface has to be treated as in-scope?

    • August 17, 2015 at 6:17 AM

      They are a service provider and should be able to provide you their PCI Attestation Of Compliance (AOC) that should explain what they are responsible for and what your organization is responsible for. If they refuse, I would move on to another service provider.

      • 8 mtcjayne
        August 20, 2015 at 5:27 PM

        I think the question was more “Is the tablet or computer used to access the web interface in scope?” because if it is that opens the organization up to about 10x the work to be compliant. It would probably just be better to have the booking engine use PayPal and make the service provider deal with the PCI compliance.

      • August 21, 2015 at 5:29 AM

        Yes, the devices used by a merchant to enter cardholder data (CHD) are always in scope for PCI compliance.

        That said, the level of compliance is what is in question and that is based on the risk the device presents. Using HTTPS to enter data means that the risk to the device is that a keyboard logger or similar collects the data entered and then transmits it to an attacker. For most devices, that means implementing “Security 101” which is basic security of keeping patched and anti-virus. However, with tablets, they remember EVERYTHING keyed into them because of their builtin keyboard logger with Windows, Android and iOS, so they are insecure from the start and probably should not be used.

  4. August 11, 2015 at 8:21 AM

    This article got me thinking. If there are outsourced entities providing services and accepting credit cards as payment but whose traffic does not traverse the organizations network or is in any way connected to it, does the organization need to prove that?

  5. 12 Daniel Moen
    August 8, 2015 at 8:32 AM

    Good article.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

August 2015

%d bloggers like this: