19
Dec
18

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.

Advertisements

4 Responses to “The Remote Worker Dilemma”


  1. 1 Geiger
    February 14, 2019 at 2:46 PM

    In looking at the PCI document “Protecting_Telephone_Based_Payment_Card_Data_v3-0_nov_2018.pdf”, sections 3.2 and 4.2 has much discussion regarding remote/at home workers. I like your explanation in your article, but is the Council leaving a grey area here?

  2. 3 Mike
    January 23, 2019 at 12:15 PM

    Hi, good article, thanks .

    I have some questions:

    1- When you say ” As a result, any other system that connects to the telephone system is now also part of the CDE.” .
    I understand that CDE is only what store, transmit or process CHD, whatever connect to it ( without falling
    within CDE category) , is a “connected to (category 2)”, but not CDE. am I right? ,

    Now, if the device/laptop connecting to the phone system will also “transmit” or listen the call with CHD, then
    of course it would be part of CDE. Correct?

    2- Regarding softphone or physical phone, if the remote agent uses any of these but your phone system(VoIP) is already part of the scope, would it be an issue ?

    The laptop/computer with softphone may use a VPN or secure remote connection to corporate tools
    Or the physical VoIP phone could also have a VPN to the remote phone system.
    Is this a limitation?

    3- What physical security controls would be required or mandatory ?
    Video camera, cctv? and 3 months of recordings?
    Physical access to the room where the call take place?
    Use of badges needed?

    What other particular requirements would apply?

    • January 26, 2019 at 11:40 AM

      1. The CDE is the CDE. If there are systems that connect to systems in the CDE even though they do not process, store or transmit cardholder data (CHD) or sensitive authentication data (SAD) are part of the CDE if they are directly connected to the in scope system. In the case of telephones, they are directly connected and are typically NOT firewalled from the VoIP environment. Therefore, they are part of the CDE and not Category 2. But even with a firewall, they still end up as Category 2 and in scope for PCI compliance, so you are still not totally out of the woods.

      2. See my answer to number 1. A VPN connection just secures the communication, it does NOT reduce scope of the devices on that VPN.

      3. Take a look at section 9 of the PCI DSS and you have your answers.


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 )

Google photo

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

Twitter picture

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

Facebook photo

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

Connecting to %s


Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

December 2018
M T W T F S S
« Nov   Jan »
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 2,093 other followers

Advertisements

%d bloggers like this: