The PCI Guru got a question regarding PCI compliance for service providers in today’s emergency work from home (WFH) environment from a blog reader and it got The PCI Dream Team thinking about how does that work? So, thanks to David Mundhenk of Herjavec Group, Art “Coop” Cooper of NuArx, Ben Rothke of Tapad and Jeff Hall of Online Business Systems for contributing to this list.
Ben & David wrote a piece on the topic last week, and the Dream Team has a webinar on Dealing with PCI DSS Compliance During the COVID-19 Crisis on March 25.
Thanks to the Coronavirus crisis, organizations are now scrambling to get their employees working from home. This is presenting a whole new series of challenges to their compliance, technology and information security teams as these employees are now operating in a potentially less secure and definitely less private environment.
Home networks are going to be less controlled and secure. Making matters worse is that most home networks today are Wi-Fi based, not wired, so data is flowing over untrusted networks because everyone in the house knows the Wi-Fi password (assuming there is one and it is not the default).
Bring Your Own Device (BYOD)
The biggest issue we are encountering is those organizations that need to rely on workstations owned by employees because they do not have company-owned and configured equipment to provide. I have seen many a Tweet and LinkedIn post discussing the shortages of equipment for work from home and what options do they have. The problem stems from most business continuity plans focusing on events that affect a business location or a community, not the entire country. As a result, the idea of a pandemic forcing people to work from home was not thought of as a realistic threat.
As a result, bring your own device (BYOD) is the only answer in the near term to getting people working from home. In discussions not only amongst the Dream Team but with other QSAs, there just do not seem to be any good answers for using BYOD and maintaining PCI compliance. None of us can come up with ways to maintain compliance with BYOD because there are just too many factors involved from anti-virus (many varieties), limited or non-existent central monitoring and management, vulnerability scanning, penetration testing, patching, differing hardware, differing operating systems and a host of other issues that make it impossible to verify compliance let alone maintain compliance.
One potential option to reduce risk and gain better control with BYOD is using virtual desktop infrastructure (VDI) solutions such as Citrix Workspace, VMware Horizon or Windows Remote Desktop Services. If you have that infrastructure in place, then we would recommend expanding it for WFH remote access. If you do not have that infrastructure, you may be able to use Amazon Web Services (AWS), Microsoft Azure, Google Cloud or similar cloud environments to stand it up quickly. That would allow you to reduce the risk of the BYOD being used but there still would be the risk of memory scraping and keyboard logging on the BYOD that must be managed.
That is not to say that you should not use BYOD as you need to keep your business running. What it does mean is that you need to have a serious talk to your acquirer to determine how to handle this situation, what the risks are to your solution and then communicate the results of that discussion formally to your QSA. You may even want to have your QSA on those calls with your acquirer to assist. In these desperate times, I doubt that any bank is going to say you cannot stay in business as long as you can provide some controls and do your best to manage the risk.
We view BYOD though as a short term solution and that a longer-term solution needs to be developed as current estimates seem to indicate that the crisis will likely extend past the original estimate of four weeks. That longer-term solution would involve acquiring the necessary hardware and software to implement a managed, secured and controlled environment that can be tested to ensure PCI compliance.
Company Provided Hardware and Software
For those companies that do have the equipment to send home with their employees, this is not a complete list, but a set of bullet points of ideas for how to address PCI compliance in our “new normal”.
- The easiest topic is remote access. The PCI DSS explicitly calls out that a secure VPN (i.e., encrypted) with multi-factor authentication (MFA) for users to obtain access to the service provider network (8.3.2.a). But where things can go sideways is complying with 8.3.1.a which requires MFA for non-console access to systems/devices in the cardholder data environment (CDE). It goes awry because people think that the first MFA covers the MFA into the CDE and it does not. The reason is that 8.3.1.a was designed to stop the phishing of Administrators to gain access to the cardholder data environment (CDE). To stop that, you need additional MFA to access the CDE. That does not mean a separate MFA solution (which would be ideal), but it does mean enforcing a delay in the single MFA so that the same MFA code cannot be used to access the internal network and then also the CDE. A lot of organizations implement the delay in their remote logon script by invoking a timer delay that expires after the longest time a code can be active (usually 30 seconds).
- A secure VPN is necessary to remove the home network from scope. Ideally, the VPN should be required to always be in use so that the workstation cannot get to the internet other than over the VPN. For those that do allow the home network and internet to be accessible, you will need to ensure that the firewall on the workstation appropriately protects the workstation as well as implementing a host intrusion detection solution (HIDS).
- VDI is also a solution because it allows for the use of thin-client and devices such as Chromebooks to be used to connect. Most VDI solutions also embed a secure remote connection via HTTPS or similar secure connectivity solutions. If not then you will need to use a secure VPN as documented above. However, even a thin client runs the risk of memory scraping and keyboard logging so you need to manage those risks.
- Review all automated workflows to make sure that they are producing the necessary audit trails that will provide evidence for you PCI assessment of what is happening. Where this becomes problematic is when the workflows are developed only for PCI compliance and with the changes for remote operations, those workflows are not picking up new users, devices and other changes that were made to allow for remote work.
- People that typically work together but now are remote will start using Microsoft Teams, Slack, Skype and other collaboration platforms to communicate and that may include sharing cardholder data (CHD) or sensitive authentication data (SAD) at times. You will need to train and quickly remediate situations if CHD/SAD enters these applications as well as periodically reminding these people that the use of these communication systems for transmitting SAD/CHD is not allowed. If possible, enable data loss prevention (DLP) or similar capabilities to identify and then redact SAD/CHD in any of these communications.
- If you are pushing out call center operations, remember that softphones will bring the workstation they connect into scope for PCI compliance because the workstation is now directly connected to the CDE which is, of course, the VoIP telephone system. That means an increase in scope and that those workstations need to be hardened, managed, logged and controlled for PCI compliance. Call center operations may also require additional network segmentation to be put in place to ensure the size of your CDE does not exponentially grow.
- While not entirely PCI related but needs to be noted are some other remote call center operation issues to consider that could make compliance with contractual obligations regarding privacy and confidentiality of data discussed or processed by the operator. You may need to supply operators with shredders, printers, additional monitors and other equipment to ensure privacy and productivity. You may also have to instruct people to locate their work area to a bedroom or other room where a door can isolate the operator while they work so that family members do not come into contact with information or documents they should not view.
- Ensure that you have ways to document changes happening, their review and approval. A lot of organizations have paper forms, Excel spreadsheets, email forms, etc. they use that sometimes can get lost in people’s inboxes, archives and folders or just lost, period. You need to make sure that the change management system will work in the remote mode and that change evidence, reviews and approvals are maintained.
- Logging should not be an issue unless your organization was not logging the VPN or other devices because they were not in scope for PCI compliance but now are in scope. So, you need to review your new workflows to ensure all devices and systems are logging to your SIEM or logging solution so that you comply with PCI requirement 10.
- Encryption key management could become an issue particularly if your process does not support remote management. This can happen with some hardware security modules (HSM) and systems that require that the key custodians physically input their seed values into the device’s console. So, going on-site may be required for encryption key changes and that may require formal approval from local authorities to occur.
These are the top of mind ideas that we were able to come up with for this discussion. However, every environment is different so not everything discussed may be possible for your organization to use and maintain compliance. We would recommend you work with a QSA to make sure that what you are attempting to do is not creating risks you are unwilling to accept or if you cannot manage appropriately.
We wish all of you the best of luck during this crisis. We will get through this, but it will likely take some ingenuity in how that happens.
Also, be aware that the Council and the Card Brands are working on this topic as well and I expect more from them in the coming weeks.
Stay safe and healthy.
Other WFH resources:
CISA Coronavirus Guidance – https://www.cisa.gov/coronavirus
NIST Teleworking Guidance – https://csrc.nist.gov/publications/detail/sp/800-46/rev-2/final
SANS Work From Home Webcast – https://www.sans.org/webcasts/archive/2020
PCI Guru 
As far as MFA for VPN into the CDE, my company is implementing Microsoft MFA and removing a RSA solution. The MS solution allows a user to login to the VPN with no password or MFA code if they were already signed into office 365 in the last 14 days,
I’m trying to point out that does not meet the PCI MFA requirements as I understand them. As I understand it there needs to be a separation of authentication methods as well as it doesn’t meet the “something you know, something you have “ requirement for every VPN login. Am I off base with my thinking?
Nope! You are spot on!
“You have to be willing to trust your personnel in WFH”. I disagree. If card data is processed, the controls in requirement 9 will continue to apply, even in an exceptional situation such as this related to the pandemic
We never said the requirements in 9 would NOT apply but there still has to be some amount of trust involved because you do not have the same surveillance capabilities you would have in a work space.
Ok, thanks. But when you say “the same surveillance capabilities” does that include physical access controls? (9.1.1)
It could. All depends on your customer contracts though, not so much regarding PCI.
When you say “the same surveillance capabilities” does that include physical access controls? (9.1.1). According to PCI DSS, I know I must apply an access control system. But I must admit that I cannot imagine applying a physical access control at home. I find difficult to implement badge systems or locking a room at home. Even in that case should the worker manually record every time anyone access to? (9.1.1)? How would you manage this in practice?
Not so much for PCI, but I have seen client contracts mandate physical security controls which in turn require personnel to have a secure area to work from such as a bedroom or den with a locking door.
Thanks for the reply. Sorry to insist but I would like to clarify. You mean, if I don’t misunderstand, that with respect to the standard, these controls may not apply, but will apply if contractually required. But aside from contractual issues, I think the standard is clear and I don’t understand what would change if we talk about a call center in the entity’s office or at home. The standard is the same and it is required to protect the cardholder’s data in both cases. From what I understand, the same controls should be applied or compensatory controls should be used if it is not feasible to apply the standard as it is, to minimize the level of risk at least as the original PCI DSS control would do.
You explain to me HOW you can enforce those controls in work from home other than under trusting that they have a shredder for example unless your organization supplies it. Same with video monitoring on how would you implement and collect that? In some cases you may need compensating controls, but a lot of the physical controls you speak of are not necessarily required if you have structured your procedures and practices properly to get rid of paper and stick to only digital. You do NOT require people to maintain a visitor log for their home or their work area do you? If you do, you really need to rethink what you are trying to achieve here.
Hi, the pci council clarified it some weeks ago in this FAQ:
https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/For-personnel-working-from-home-is-the-work-from-home-environment-considered-a-sensitive-area-for-PCI-DSS-Requirement-9/
An individual’s private work-from-home (WFH) environment is not considered a “sensitive area,” and personnel working from home are not required to meet PCI DSS Requirements 9.1.1 or 9.3 for their WFH environments. So it is not expected that video cameras and/or access control mechanisms are in place to monitor or physically restrict access within these environments.
Yes they did. But that has been the case for a couple of years. Someone asked about it at the CM in 2018 and QSAs were told that they were not expected to go onsite to virtual organizations.
I’m surprised there’s no discussion of PCI Validated P2PE here? Wouldn’t it be easier and less expensive to leverage P2PE virtual terminals, P2PE stand-alone terminals or P2PE mobile devices rather than hardening computers and setting up VDI or VPN?
The problem with a lot of P2PE (and E2EE) solutions is that they are not portable so moving them to a different location or machine is difficult if not impossible. A lot of organizations found out the hard way that they would have to re-register and/or re-configure their P2PE/E2EE devices and that would not be possible for their end users to complete.
There are plug & play P2PE SRED Key devices for $170 that connect via USB for virtual terminal use. These devices are hot swappable and sharable across users, computers and merchant accounts without any device setup, software installation or configurations.
There are also stand alone mobile P3PE options like the Clover Flex which are $400 and can connect via cellular or wifi.
Remote workers could also plug stand alone P2PE terminals into ethernet ports without any configuration and those start at $200 each.
Each of these options can be ordered, delivered and processing within a few business days.
Yes, I get that fact.
However, all of the implementations I have been involved do not use such solutions because no one considered the need for such flexibility until COVID hit. At that point, it was too late never mind the fact that their acquiring banks or processors could not support such solutions.
There are also financial considerations in that the solutions you mention carry much higher processing fees that the merchants and call centers I deal with have negotiated to be much lower to be profitable.
We have been setting up these solutions in a gateway only mode for SMBs, universities, hospitals and governments where they can keep their existing processing or set up new processing depending on what options are most cost-effective for them. To be clear, I’m not recommending any specific solutions, and we don’t offer any of our own technology. We help merchants select and set-up the best options for them like Bluefin, CardConnect, FreedomPay, TrustCommerce, Windcave and others depending on their specific situation. In all cases, they’re simplifying compliance and reducing their overall costs. I just wanted to be sure everyone knows those options exist without long or expensive setups.
Good to know.
But I am talking tens of thousands of seat call centers, not SMBs. The cost to temporarily outfit such operations far exceeds the value of doing so.
Thanks for the great content. In this article you mention “A secure VPN is necessary to remove the home network from scope.” Is there an advantage if the VPN is installed on the workstation (part of the CDE) or if it is a hardware-based ipsec tunnel that the workstation connects to?
It is all about scope. When the endpoint is for example a router, switch or firewall, everything after that device is in scope because they have potential access to the clear text data stream. When the VPN terminates at the workstation, then only the workstation is in scope because the data stream is never decrypted until it gets to the workstation.
I have been trying to decide if VPN is needed even, as opposed to an SSL/TLS connection made by an MDM managed workstation to transmit the CHD. It would seem that VPN is a preferred technology for segmentation, probably due to the separated subnet and adapter, but it seems that SSL is logically separated connection private to the endpoint and the terminating host. Assuming the workstation is controlled (in terms of configuration), firewalled, patched, and monitored, and the terminating host is as well, the VPN is not particularly advantageous.
Just to be clear, SSL is no longer allowed. Only TLS v1.2 or greater are allowed for secure encryption of communications. Otherwise, you are correct.
Hi PCI Guru, I agree with the approach of using the VDI or other similar solution in order to reduce the scope and avoid to include personal computers in-scope.
However, if you review this SSC supplemental document (Guidance-PCI-DSS-Scoping-and-Segmentation_v1_1) pages 18 to 23, the PCI Council states that even using “jump servers” the admin workstation always be in-scope. I do not agree with this SSC point of view, since we have several technical controls to avoid impact in the scope and CDE assets, even if the admin workstation is compromised. But it is an official document and a source that we can use to support our decisions and my concern is to allow this scope reduction using a practice not totally shared by the Council.
What´s your opinion about it?
A jump server would be part of the CDE even though it does not (or should not anyway) process, store or transmit CHD because it has direct connectivity to systems in the CDE. That is why the jump server needs to fully comply with the PCI requirements like any other device. Do all of those requirements apply? It depends on the controls you have surrounding that jump server, but it is highly likely that the vast majority do apply.
Workstations that connect to the jump server are part of the “Connected To” or “Shared Services” environment which is why they are included in the PCI assessment. That said, I would agree that if one of these workstations were compromised, what is the risk given the controls on the jump server? With MFA in place, I would argue that the risk is likely limited but I would still require basic security hygiene (current OS, patching, AV, etc.) to ensure that the workstation remains secure. If the workstation is portable, I would further require something beyond AV to ensure that usage on untrusted networks does not infect the device.
Extending this to a VDI environment, is similar to the jump server. The only difference is that we now have introduced the potential use of a device we do not necessarily have control over. As a result, we need to ensure that the VDI environment manages as much of the risks as possible and we reduce the risks presented by the use of an uncontrolled/unmanaged device as best we can.
Agree that the risk to connect-to the jump server or VDI is low, due to a several controls implemented, such as MFA, VPN, etc.
However my main concern is about the PCI SSC guide, that states that all admin workstations are part of the scope. In my opinion, this guide should be update to the new scenario and includes some criterias, where is possible to remove admin workstations from scope (for example, different user accounts).
I´ve seen a lot of webinars, last month, going against this guide related the use of the VDI or Jump Server, and allowing to remove admin workstations from scope. But, this could be dangerous without properly criterias.
Same workstation but different accounts? Really? How does that change anything when it’s the same device? If the device is compromised, I don’t care how many accounts you use because I can see them all because I own the device.
The bottom line from the Council is, if the device can affect the security of the CDE, it is in scope. Admin workstations can definitely affect the security even through VDI. Granted, the risks are fewer, but they are still risks and must be mitigated or eliminated.
In the end, the only way I know to keep admin workstations out of scope is to never allow them to admin any in scope device. That situation is never going to happen.
Are there issues with WFH agents accepting card numbers over the phone and entering for the customer? In my mind there are, but I didn’t see it specifically called out above. Although it was mentioned that the agent should be instructed to go to a separate room in the house to not be disturbed. Of course, there is no control over that. Am I being to rigid with this? I’ve been looking at de-scoping tech but naturally we’d not make the spend if not really necessary. Just trying to keep us out of trouble.
I have written about the issues related to voice over IP (VoIP) before and the fact that spoken SAD/CHD is considered no different by the PCI DSS than digital SAD/CHD over an IP network. Add in a softphone and you have put the workstation into scope because the SAD/CHD flows through the softphone application on the workstation making the workstation part of the CDE (i.e., transmitted).
Even without the telephony, you have data entry of SAD/CHD through the workstation keyboard which brings the workstation into scope because the workstation is part of the CDE because the data is entered through the keyboard (i.e., processed and transmitted).
Locating people in a private area is more of a contractual issue not a PCI issue. Having done a lot of work with call centers, I have encountered situations where customers require a physical separation between operators for security and privacy reasons. That requirement extends to WFH even before COVID-19.
Thank you for the quick feedback, I’m new to this forum. So while I understand that the WFH would be in-scope (softphones) I get hung up on the idea that there is no supervision in the agent’s home. We use Pause and Resume (automatically engaged once agent places cursor into card field) and mask the numbers as they are typed into the card field, whether they are onsite or at home, but I am stuck on the idea that they can accept card numbers with nothing other than policy to tell them not to copy anything or to let anyone else listen and copy. These are also our machines, not BYOD. But our overseas CC is looking at BYOD. At any rate, a DTMF/Voice-masking de-scoping solution is not necessary in order to be compliant with a WFH model. More of a question I guess. We have just about everything else in place to protect the systems. So it seems the right controls and a lot of trust.
You have to be willing to trust your personnel in WFH. But no matter what you do, there will be people that commit fraud but that is usually a very small percentage (i.e., < 2%). What you need are controls to best detect those that commit fraud. You are not going to catch everyone, but all you need to do is catch a few and word gets around fast and will also serve as a deterrent.
that’s where the rub is for me…controls to best detect those that commit fraud, which is pretty tight for on-site agents, not as much for WFH. again, thank you for your reply!
I agree. I have some call center clients that are requiring cameras that record what they do in addition to the controls provided by the call center agent application. In the end though, you are limited on oversight because of the situation.
Have you had to get on the phone with acquirers and clients to talk through WFH and the gaps in Reqt.7& 9? Given the forced nature of WFH, have they been lenient (for lack of a better word)?
I have not had that pleasure yet. However, in other discussions most banks just want organizations to stay in business and generate revenue while managing the risks. It’s the risk management piece that they are most interested in.