As a lot of people are finding out when they rolled out work from home (WFH) for COVID-19, it turned out that compliance with the PCI DSS was not in place and in some cases, not even possible. If the PCI Dream Team session last week is any example, I think a lot of QSAs got calls and emails from their clients asking what the Hell had happened?
What we are all experiencing is a shortcoming of the PCI DSS and a point that has been discussed off and on since it came into existence. The problem is that the PCI DSS does not worry about business continuity (BCP) or disaster recovery (DR) unless there is cardholder data (CHD) or sensitive authentication data (SAD) involved which typically only occurs when that data exists at hot/warm recovery sites. If the CHD/SAD is only there when recovery is occurring, then those locations are out of scope.
Unfortunately, the COVID-19 event is not your normal “disaster”. With the invocation of WFH, production data centers and offices were still fully operational which is typically the concern of BCP/DR. What changed was that the government enacted stay at home or shelter in place orders and the recovery site became an employee’s home, not your expected recovery location. Worse, since WFH would not involve CHD/SAD until it was invoked, QSAs had no reason to assess any plans for such recovery because they were not in-scope until activated.
That said, a lot of QSAs (myself included) usually did have a discussion with clients that, while their BCP/DR plans were not in-scope, clients should occasionally assess those plans to make sure that, when invoked, the plan maintained PCI compliance. Because when the BCP/DR was invoked, whatever was done had to be PCI compliant the moment it was used.
And there is the rub in all of this. There is no grace period with PCI compliance because of the invocation of BCP/DR. You are expected to be 100% PCI compliant regardless.
There are a number of lessons learned due to the COVID-19 disaster.
- BCP/DR will need to be updated for pandemic incidents including WFH capabilities. According to the World Health Organization (WHO) and the Centers for Disease Control (CDC), pandemics are not going to go away, so the ability to continue operations remotely is going to have to be part of an organization’s recovery options.
- WFH capabilities will have to be incorporated into normal production capabilities. This effort will need to address PCI compliance as well as HIPAA, CCPA, GDPR and any other relevant security and privacy programs your organization may have to comply with. I have had a number of organizations enact such capabilities, policies and procedures for various parts of their operations over the years due to changing work requirements of their personnel as WFH offers a number of flexible advantages for retaining employees.
- Implement virtual desktop infrastructure (VDI) to provide office as well as remote working capabilities. This can also potentially allow WFH to use an employee’s BYOD as long as they are not required to be PCI compliant. Use of VDI allows the use of thin clients and Chromebooks to be used as workstations making security of those workstations a bit easier as well as reducing the cost.
- Implement P2PE or end-to-end encryption (E2EE) solutions for the entry of CHD/SAD into applications. There are a number of USB and Bluetooth options available from the various point of interaction (POI) vendors such as Verifone and Ingenico as well as other third-party application vendors.
- Softphones create a larger scope by bringing the workstation they connect to into full scope for PCI compliance. The number of requirements that need to be assessed can be reduced by using VDI and connecting the softphone to the VDI through the workstation. Making such a connection though is not “plug and play”, so be prepared to have to work a lot with the VDI vendor to make that connection work. But do not be surprised if it does not provide a reliable and/or clear connection, so make sure you are prepared to have to place the full workstation into scope to have an acceptable working solution.
- If you are expecting to use The Cloud for your VDI or application, make sure that you conduct appropriate capacity planning so that you are not caught without the ability to expand that solution due to WFH. A lot of organizations have found with the COVID-19 event that their Cloud implementation did not scale as they thought it would. It turned out that Cloud providers have capacity limitations just like in-house data centers. While you are not using that capacity all of the time, you need to reserve it for those instances when you need it. While not free, that excess capacity can be reserved for such events as COVID-19 so that when you need it, it is available.
PCI Guru 
Guru,
I have a question/statement on your softphone bullet point. You identify that you may be able to lower the requirements of a softphone by utilizing a VDI solution. I understand where you are trying to go with this, but my question is: How can the end device not be considered CDE if CHD is being processed/transmitted on it?
I would think that the CHD being transmitted and put out in audio format would be the same as CHD being put out in Video format. And regardless of what level of VDI is being done (from application virtualization to “dumb” clients with complete virtualization), there is still processing (decoding) and transmission (audio) of CHD.
Am I just translating the requirements for processing and transmitting CHD wrong/too literal?
Thank you,
Craig Gillespie
Because the softphone software that connects the USB headset is installed on the VDI, not the workstation in my example (sadly, that does not always work though). The VDI is already in scope for connecting to the VoIP telephone system. So you only have to worry about interception of keystrokes, memory scraping and eavesdropping on conversations at the physical workstation.
Guru,
I’m sorry that I am pestering about this. I am trying to make sure that I get corrected in how I am thinking for the future. After all scoping can be a major issue and if done wrong will ensure non-compliance.
So, I have 2 more trains of thought on this. (assuming that the usb connections all work correctly and everything that can be offloaded to the server is.)
1.) VoIP is in scope because the CHD is sent through the systems and over the networks from the voice servers to the end-points. In most cases those end-points are telephones attached to the network. Right now we are discussing softphones which means the endpoints are computers. In your illustration the computer is a VDI server. However that is not the end of the data stream. The VDI server is running the softphone software, but it then repackages the information and sends it on to the users device for dispersal as audio. I guess there are 2 pieces here. First the users device is still processing this network feed into actual audio. Second the data stream (if unencrypted) could be used to re-create the audio. It would take a little more work because it is embedded in the protocol that the VDI system is using, but still do-able. In my mind this would make it CDE.
2.) Regardless, the user device would be considered in-scope because it connects to the CDE (the VDI server). So even if it isn’t considered CDE it still has to be protected as PCI.
I know that there is discussion about whether an end-point in a VDI solution is considered a “processing” point. But regardless of what kind of end-point it is or where the “program” is running, there is still a program running on hardware that can be compromised.
Again, thank you and I’m sorry for pestering about this.
Craig
No your are correct to pester me.
First, the virtual desktop is the endpoint for the call from a telephony standpoint, not the workstation. So any exploits against the softphone and its software would be at the virtual desktop and it would be assumed you would have hardened and would be monitoring that desktop accordingly. Think of the virtual desktop as similar to a bastion device where you are placing the majority of your controls.
Yes, the workstation would be a conduit for audio, but the connection between the VDI and workstation should be encrypted, so it would only be in the clear in workstation memory for delivery to the headset. It is assumed that would be an easier detection for local AV or other methods to detect and quarantine.
Second, yes the workstation is still in scope but with hopefully limited exposure to only memory scraping, screen scraping and audio grabbing. All things we would like to believe can be more readily managed and monitored versus the full on PCI compliance program.
Hopefully that clears things up.