The Remote Worker Dilemma

We received the following question during the last PCI Dream Team session back in October.

“We have a call center that sometimes takes a credit card numbers from customers.  Our senior management keeps pushing us to come up with a work-from-home option for some of our call center employees in case of DR and Business Continuity.  We keep telling them that PCI says that all components of such a home setup is subject to PCI standards and thus is impossible, Have any of you seen any solution that would allow this?”

Since that session the Council released the new telephony information supplement that has created a stir in the PCI community.  I wrote about the new information supplement a few weeks back so I will not cover that here, but I will rely on it to answer this question.

First and foremost, remote workers are allowed under the PCI DSS as there are no requirements that prohibit it.  However, there are PCI-related considerations when you want to implement such an approach.

You will obviously need to develop PCI compliance policies, standards and procedures that will support remote working.  If your organization already has policies, standards and procedures for clean desks, secured work area, protection of information, proper handling of sensitive authentication data (SAD) or cardholder data (CHD), then you probably have the bulk of what you need.  You will need somewhere in your documentation to allow for your organization to conduct annual and spot inspections of remote working environments for compliance with organization policies, standards and procedures.

If you do not have those policies, standards and procedures, then you will need to get those published, approved and all employees and contractors to formally acknowledge them.  Most organizations’ policies, standards and procedures work just fine for corporate environments but do not consider the situation when workers are not in a corporate facility.  As a result, it is not unusual to see organizations develop policies, standards and procedures that take into account that the remote workers’ working environment might not necessarily be as secure as those at a corporate controlled office.

The annual inspection can consist of the remote worker taking a picture of their work environment and filling out a form that ensures the remote worker is complying with relevant organizational policies, standards and procedures as related to remote working.  I have clients that have remote workers fill out the relevant PCI SAQ depending on their remote worker environment.  In all cases, the employee signs the form/AOC stating that they are compliant with all relevant policies, standards and procedures.

It is when the organization has questions, issues or concern with a remote worker is when the spot inspection clause becomes useful.  The spot inspection capability allows organization management or an auditor to go to the remote worker’s location and personally examine the work area to ensure that it complies with all policies, standards and procedures.

With the paperwork out of the way, let us now discuss the technical challenges related to remote workers.  The goal here is to minimize the PCI scope of the remote worker’s configuration.

The easiest way to do this is using a point-to-point encryption (P2PE) validated solution or an end-to-end encryption (E2EE) solution for the keying of SAD/CHD.  Of course, this means that you will have to ensure that your application will work properly with a P2PE/E2EE solution which further means not allowing SAD/CHD to be keyed through anything other than a P2PE/E2EE validated terminal also referred to as the point of interaction (POI).  This can also mean pairing the P2PE/E2EE solution with tokenization if your application is expecting CHD back at the end of the transaction.

But P2PE/E2EE only addresses the transaction, not the conversation that results in the transaction.  To reduce costs of remote workers, organizations typically implement a softphone.  Softphones are great.  However, they result in a PCI scoping problem.  As a reminder, when a telephone system is used for having conversations involving SAD/CHD, it puts that system and networks in the cardholder data environment (CDE) also known as a Category 1 system.  As a result, any other system that connects to the telephone system is now also part of the CDE.  Since a soft phone cannot be readily logically or physically segmented from the workstation it connects, it drags the workstation into PCI scope regardless of whether or not SAD/CHD is discussed.

The solution to the softphone issue is to use a physical VoIP phone with a headset.  But it is not as simple as just swapping in a physical phone for the softphone.  That physical phone needs to be on a logically or physically segmented network that does not include any devices that you desire to be out of PCI scope.  It is that segmentation that drives up the cost of the remote worker configuration because you now need to have a managed network device to allow for separate VLANs or physically separate network connections.  Not impossible, just costlier than delivering a cable/DSL modem with four Ethernet ports to the remote worker’s location and being done.

As a result of all of this, it is not unusual for organizations that allow for remote workers that need to be PCI compliant to supply those remote workers with a US Department of Defense compliant document shredder, computer or workstation, router, network switch, display(s), keyboard(s), secure POI(s), telephone(s) and any other equipment necessary to ensure compliance with the PCI standards.

In addition to this, there may be other requirements due to the European Union’s General Data Protection Requirement (GDPR), Health Insurance Portability and Accountability Act (HIPAA) or other security or privacy regulations or requirements.

Advertisement

Requirement 12.9

I discussed requirement 12.8.2 in a prior post which applies to all organizations being PCI assessed.  Let us now turn our attention to requirement 12.9 which only applies to organizations that are service providers.  If you are unsure if you are a service provider, see this post and this post.

As a refresher, requirement 12.9 states:

“Service providers acknowledge in writing to customers that they are responsible for the security of cardholder data the service provider possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.

Note: The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgement does not have to include the exact wording provided in this requirement.”

The Guidance for 12.9 states:

“In conjunction with Requirement 12.8.2, this requirement is intended to promote a consistent level of understanding between service providers and their customers about their applicable PCI DSS responsibilities. The acknowledgement of the service providers evidences their commitment to maintaining proper security of cardholder data that it obtains from its clients.

The service provider’s internal policies and procedures related to their customer engagement process and any templates used for written agreements should include provision of an applicable PCI DSS acknowledgement to their customers. The method by which the service provider provides written acknowledgment should be agreed between the provider and their customers.”

As with 12.8.2, we are told in the requirement’s Note that “exact wording” is not required.  So those of you looking for “exact wording” need to move beyond that fact.

The key though to 12.9 is that the service provider’s contract, master service agreement or whatever other legal documents used need to ensure that they acknowledge their requirements to protect the payment card data they process, store, transmit or could affect the security of the payment card data.

It is that last statement that catches a lot of service providers.  Like it or not, even if a service provider does not directly come into contact with sensitive authentication data (SAD) or cardholder data (CHD), if they can affect the security of that data, they need to be PCI compliant.  This usually catches managed service providers (MSP) such as those that manage/monitor firewalls, network devices, servers and security incident and event management (SIEM) solutions and they will argue incessantly that they do not need to be PCI compliant.  Unfortunately for them, the Council, the card brands and QSAs will tell them otherwise.

In the end requirement 12.9 is all about service providers providing the necessary information and documentation such that the organizations they provide those services can comply with requirement 12.8.2.  To that end, there are two tests for 12.9 in the ROC Reporting Template and those tests state:

“Identify the service provider’s policies and procedures reviewed to verify that the service provider acknowledges in writing to customers that the service provider will maintain all applicable PCI DSS requirements to the extent the service provider possesses or otherwise stores, processes, or transmits cardholder data on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.” and

“Describe how the templates used for written agreement verified that the service provider acknowledges in writing to customers that the service provider will maintain all applicable PCI DSS requirements to the extent the service provider possesses or otherwise stores, processes, or transmits cardholder data on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.”

The first test is all about having some sort of legal agreement in place that the service provider acknowledges that they need to comply with all relevant PCI standards.  Where this test broke new ground is the addition of the statement:

“… or to the extent that they could impact the security of the customer’s cardholder data environment.”

This statement came in as part of v3.2 of the PCI DSS.  It was added to the test to clarify to QSAs/ISAs that service providers are also those that can influence the security of payment information (e.g., managed service providers with access to PCI in scope devices).

The second test is to ensure that service providers that rely on boilerplate agreements ensure that those boilerplates contain the necessary language that requires the service provider to maintain their PCI compliance.  The idea being that if it is in the boilerplate, it is less likely to be removed.

I am sure a lot of you are questioning who ensures that the boilerplate language does not get removed or modified?  That is one of the purposes of 12.8.2 on the customer’s side of the equation.  This is why the testing meshes with each other.  The service provider’s QSA/ISA makes sure that the language is in the standard agreements.  The customers’ QSA/ISA makes sure that the language still remains in the agreements.  Each are a check on the other.

I cannot stress enough the importance of QSAs/ISAs filling out the service provider’s AOC correctly let alone using the correct form and instructing their service provider clients to give the AOC to any customer that requests the AOC.  There is nothing more frustrating than service providers who refuse to provide their service provider AOC.  It is not a secret as many apparently believe.  And please, do not refer your customers to either the Visa or MasterCard service provider lists.  That is also not what your customer or their QSA/ISA needs for their assessment.  Yes, it does confirm that your organization is PCI compliant, but tells the customer nothing about their PCI compliance responsibilities when using your services.  That is the whole point of why customers need your AOC.  Get over it and put your service provider AOC in your customer portal like you do your SOC1 and SOC2 reports.

There you have it about requirements 12.8.2 and 12.9.