2022 North American Community Meeting

I am looking forward to physically seeing people at this year’s PCI North American Community Meeting.

Sadly, only two of the four PCI Dream Team members will be in attendance.

Ben Rothke is being forced to stay home and manage audits that are occurring during the Community Meeting. David Mundhenk is also going to be otherwise engaged that week as well.

While we will miss not having the Dream Team together in person, Art “Coop” Cooper and I will struggle along without them.

This year the Council will have a lot to discuss regarding PCI DSS v4 and we are anticipating a good exchange of information and clarifications.

If you are coming to Toronto, safe travels. We cannot wait to see you all there.

Advertisement

The Next PCI Battleground – The Customized Approach

Flexibility is how the Council and their spokespeople tout PCI DSS v4 and the Customized Approach.  The Customized Approach will allow your organization to make the PCI DSS your own and similar comments are made. 

While those are all very true statements, the Council is wrapping the Customized Approach with some caveats that are not necessarily being broadcast to the general public. 

The first caveat that comes through loud and strong during the PCI DSS v4 Transition Training that QSAs are required to take in order to use v4.  That caveat is that the Customized Approach is really only for organizations that have a mature controls environment.  The Council’s rationale for this is that the Customized Approach is not for organizations that have anything but strong and mature control environments because the Customized Approach requires mature and functioning controls that can be tested to show they are always functioning.  This point was repeatedly pointed out whenever the Customized Approach was discussed.  When you look at the documentation being required to use the Customized Approach it is very clear that only organizations that have strong control environments are going to be able to provide the documentation and evidence necessary to meet the Customized Approach documentation and evidence standards. 

The next caveat is that much of the documentation and evidence that an organization needs to provide for the Customized Approach MUST BE developed by the organization, not their QSA.  This goes back and reinforces the idea that only organizations with strong and mature control environments are going to be able to use the Customized Approach because such organizations are going to be the only ones that have their act together to be able to produce the necessary documentation and evidence.   

If your organization does need assistance developing a Customized Approach, do not expect your QSA to be able to help you because they cannot and still maintain their assessor independence.  So, organizations will have to get assistance from a different QSA if they need such help.  While that QSA can be from the same QSAC, I am guessing that a lot of QSACs will want to have a different QSAC provide such assistance so that they ensure they are independent. 

The final caveat is that the Customized Approach is not a new compensating control worksheet (CCW) exercise.  Not even close and far from it!  The Customized Approach is going to require organizations to not only provide documentation of the approach and how it works, but that it manages the risk at or below the PCI DSS approach, and evidence that the approach works and works consistently by conducting their own testing (hopefully independent, i.e., internal audit) and providing complete documentation of that testing.  From all of that your QSA reviews the documentation, develops their own testing procedures and validates that the Customized Approach is functioning as designed.  Better yet, the Council has been very, very clear to QSAs that this is not something an organization can just toss together when they figure out, they have a PCI compliance problem.  This needs to have been implemented and thought out long before the organization got to conducting their PCI assessment. 

All of which leads to why this will be the next battleground. 

At any point in the PCI assessment, the QSA can reject the proposed Customized Approach for a number of reasons.  Some of which could be: 

• Inability of the organization to provide evidence that they have a mature and strong controls environment, 

• A lack of complete documentation for the Customized Approach, 
• Failure of the proposed controls to meet the PCI DSS requirements addressed by the Customized Approach, 
• Lack of adequate organizational testing (i.e., testing not performed over a period of time), and  
• Failure of the QSA to prove that the Customized Approach works through their own testing. 

Keep in mind that QSACs are going to be on the hook for approving these Customized Approaches.  If they blow up and result in a breach, this will put not only the organization on a legal hook, but also the QSAC that approved the Customized Approach.  In these days of risk mitigation and management, most QSACs are going to be very, very careful as to what Customized Approaches get approved.  I would not be surprised if QSAC senior management and their legal counsels will be involved in that approval process.  All of which will most likely stretch out getting a finalized ROC out the door. 

As someone that runs a PCI practice, while implied by the Council in their guidance on this subject, I would require documentation that an organization’s controls environment is mature and strong.  First thing that fails that test is if the organization has had any control failures since their last PCI assessment.  In my very humble opinion, if you have any reason to need a CCW, you do not get to use the Customized Approach.  Nothing says your controls are not mature and strong is that you cannot execute required PCI controls 99% of the time.  All of this starts to indicate to me that business as usual (BAU) and that an organization monitors those BAUs is going to become a requirement of QSAs to sign off on Customized Approaches.  If an organization has not integrated PCI controls into their business processes and is not monitoring their compliance on a near real time basis, then do not expect your QSA to sign off on using a Customized Approach.  Yes, control environments are not perfect, and mistakes/errors happen.  But if you cannot prove that you knew almost immediately that the control failed and that you took action to correct the situation when you found the failure, then I really have difficulty judging your environment as mature and strong. 

Who does the organization appeal to if they do not like the QSA’s assessment of their Customized Approach?  While not clearly articulated by the Council, I am assuming it will be the acquiring banks or even the Card Brands. 

The lesson here is, be very careful what you wish for.  While you now have a way to customize the PCI DSS, it is not a panacea nor is it going to be available to everyone.  Time will tell how this experiment works out. 

PCI DSS v4 First Blush Comments

All I can say is Wow!  WOW! 

There is a LOT of “busy work” in this version. 

For any QSA that does not have access to some form of tool for filling this bad boy out, heaven help you.  It seems that the Council has declared war on the QSACs and QSAs.  I would venture a guess that the number of hours required to fill out and ticking and tying things will be twice the amount of time a QSA spends on actually doing the assessment. 

Sadly, it is painfully obvious as to why this has happened. 

I am sure it is to get back at all of the “ROC Mills” out there (you know who you are) that conduct PCI assessments by essentially licking a finger, putting it in the air and sensing which way the wind is blowing, i.e., “you are compliant!” 

But sadder still are the poor merchants and service providers that are now collateral damage in this “war”.  I would not be surprised that, if after reviewing this Albatross of a standard, those merchants and service providers revolt.  That constituency is not going to pay for the overhead in this new version.  Even those that have done the correct thing and minimized their scope are going to get screwed over because of all of the “busy work” required to even complete their assessments. 

If the Council wanted to find a way to put themselves out of business, I think they have found that in v4. 

I thought I was only joking in my April Fool’s Day post about “Miserable Edition”.  But I was apparently spot on.  I cannot wait to attend training on this abomination to understand their justification for making a PCI assessment even more miserable than it already was. 

PCI DSS v4

I wrote this for my new employer’s, Truvantis, blog so I figured why not point you to it here. Just my thoughts on the subject and all of you are concerned about: what is in the new coming release of the PCI DSS?

https://www.truvantis.com/blog/pci-dss-v4-2022-how-to-be-prepared

Enjoy!

Updated PAN Truncation FAQ

As part of the holiday giving tradition, the PCI SSC has given us an updated FAQ (#1091) on the subject of PAN truncation and it will likely go down as the most confusing FAQ ever.

The FAQ starts out simple enough with the statement:

“A maximum of the first 6 and last 4 digits of the PAN is the starting baseline for entities to retain after truncation, considering the business needs and purposes for which the PAN is used.”

But it is the table that follows that gets messy.

It seems that each of the card brands has their own take on PAN truncation based on PAN length and other factors. Only American Express has stayed the course.

Based on the guidance for UnionPay, Visa, Mastercard, JCB and Discover, the idea of first six/eight and ANY OTHER four is a bit bizarre not to mention risky.

Never mind the obvious warning note at the end of the FAQ that states:

“Access to different truncation formats of the same PAN greatly increases the ability to reconstruct full PAN, and the security value provided by an individual truncated PAN is significantly reduced. If the same PAN is truncated using more than one truncation format (for example, different truncation formats are used on different systems), additional controls should be in place to ensure that the truncated versions cannot be correlated to reconstruct additional digits of the original PAN.”

Personally, I would stick with the good old first six, last four and avoid any of these other formats as you are likely setting yourself up for problems and PCI non-compliance.

Happy holidays to all!

Remote PCI Assessment Guidance Issued

At the end of September 2021, the PCI Council released a Guidelines and Procedures document on conducting Remote Assessments for PCI and card brand assessments.  Most of this document is a rehash of previous Council statements and guidance.  However, there is one new element in this document that all QSAs will need to read and comply with and that is the requirement of documenting a feasibility analysis to justify conducting a remote assessment.

Some of the examples the Council gives as valid reasons that an on-site assessment may not be feasible includes:

• Restrictions on the ability to travel or meet in person due to health and safety concerns or government advisories.  We are all familiar with the COVID-19 pandemic and its impact on travel, particularly international travel.  However, I encountered this a while back due to a volcanic eruption in Iceland that cancelled my trip to Europe.  Since we had no way of knowing how long the eruption would cause travel disruptions and we were on a tight timeline, we conducted video conferences rather than travel.
• Geographic locations that are physically inaccessible or difficult to reach.  I personally ran into this situation one several years ago when a data center in Europe that was supposed to be decommissioned before the next assessment remained operational.  The company I worked for had shut down their EU operations and there was no way to justify 16 hours of flight time for a two-hour data center walk through.  We held meetings with the data center operator via video conference and did a virtual walk through.
• Testing required at a location is limited to documentation and interviews and no observations of processes, systems or physical environment apply.
• The entity operates a virtual environment without physical premises or facilities.  This has become more and more common with entities that operate in The Cloud.  Why rent expensive office space when there is not need for it?  This situation only got more prevalent with the pandemic and will likely only increase in the future.

As the Council states in their guidance,

“For many assessments, a combination of onsite and remote testing may provide a suitable balance, as it allows for increased efficiencies in the assessment process while enabling an appropriate level of assurance to be achieved in the assessment result.  For example, documentation reviews can often be performed remotely without significant loss of assurance, whereas observations of processes and environmental characteristics will generally require an onsite review.”

Regardless of whether the assessment fits into one of the bullets above, the Council wants QSAs to formally document their analyses of why the onsite assessment cannot be performed and the risks that may present to meeting the assessment objectives.  This analysis needs to be completed prior to starting any testing and is supposed to be a joint effort between the assessor and the client.

Topics that the Council recommends be addressed include, but are not limited to:

• Confidentiality, security, and data protection requirements.
• Availability and effectiveness of the remote assessment technologies.
• Effects on entity’s personnel.
• Effects on operation support.
• Assessment scope and completeness.
• Quality and reliability of digital evidence.

The Council further states:

“During the analysis, the entity and assessor should identify any challenges and potential risks associated with the remote testing and determine whether it is feasible for testing to be thoroughly completed to produce a high level of confidence in the assessment results.

The results of the feasibility analysis—including the risks and challenges associated with use of the remote testing methods, and any mitigating controls for overcoming the risks and challenges—should be documented and agreed upon by both the entity and assessor. A copy of the feasibility analysis results should be included with the applicable ROC/ROV. Entities and assessors may be required to produce the analysis upon request by the PCI SSC or applicable compliance-accepting entity.”

The key points from that statement above is that: (1) the feasibility analysis needs to be submitted with the ROC/ROV and, (2) if requested by the PCI SSC or compliance accepting entity (i.e., Brand or bank), the QSA is required to produce the analysis.  As a result, this is a non-optional exercise.

The feasibility analyses must document that:

• The assessment is feasible to be fully completed at this time using onsite methods, remote methods, or a combination of onsite and remote methods.
• The assessment is only feasible to be partially completed at this time.
• The assessment is not feasible currently.

According to the guidance, it is only those assessments that are completely feasible that can be conducted.

The Council includes a very important note regarding the analyses.

“The feasibility analysis determines whether the use of remote testing methods is feasible for a particular assessment.  Determining that a remote testing method is feasible does not guarantee that use of the testing method will produce the level of assurance needed for the assessor to reach a finding; this will depend on how the remote testing method is implemented and used, whether the testing can be completed for all applicable components and areas, and whether sufficient evidence is provided for the assessor to make a determination.  Assessors and entities should continue to monitor and evaluate the effectiveness of the remote testing methods throughout the assessment to confirm whether the testing methods are performing as intended and whether additional testing may be needed.”

This concept of “assurance” appears to all be in the eye of the beholder.  Meaning, if the Council, Brands or Banks determine, in their opinion, that the remote methods are not providing appropriate levels of assurance, the ROC/ROV can be rejected.  Not that a lot of banks are going to reject ROCs/ROVs on this, but I can see the Council’s AQM reviews and Card Brands rejecting ROCs/ROVs on analyses that they deem flawed or incomplete.  The AQM process is the most concerning because a QSAC could end up in remediation due to a failure to appropriately document the remote assessment feasibility.

As with most edicts issued by the Council, they should have produced a form for this feasibility analysis so that everyone understands what is required from these feasibility analyses.  Can the feasibility analysis be documented in section 1.2 of the reporting template or is a separate document required?  I would recommend this for the obvious remote assessments of COVID and everything in The Cloud.  I would recommend a separate document for feasibility analyses that are longer in discussion.

Sadly, I foresee a lot of confusion and heartache in the QSAC community as we move through this new requirement.  That is because I see a lot of assessments that are blocked due to COVID travel restrictions or the assessed entity having no physical offices being rejected for “flawed” feasibility analyses when it should just be allowed with no further documentation or discussion.

It will take time to see how this shakes out.

UPDATE 11/29/2021 – I received a comment on this post (see below) and the confusion is beginning. A service provider has had one of their customers request the documentation regarding what is provided in Appendix A of the remote assessment guidance document as well as the remote assessment feasibility study. Since these are ROC documents, there is no requirement from the Council that requires any organization to turn over their ROC to any third party other than their acquiring bank or the card brands. The AOC is the communication document to third parties. If an organization wishes to turn over Appendix A from the guidance, that is the organization’s decision, but it is NOT mandatory nor it is required by the Council.

The PCI DSS Is Not The Only Relevant Payment Security Standard

One of the more lively discussions at our past PCI Dream Team session involved a discussion of requirement 12.8 and third party management (i.e., service providers).  What got the discussion started was when Art (Coop) Cooper made the comment that only SAQ A states that all third parties must be PCI compliant.  All of the other SAQs and even the ROC does not state that third parties need to be PCI compliant.

All of this is very true and has been this way since the beginning of the PCI DSS.

But …  That is not the whole story.

In this instance, the PCI DSS is not the only game in town.

People forget that Visa, Mastercard, Discover, American Express and JCB (aka “The Brands”) still have their own security programs and requirements in addition to the PCI DSS.  Some of these requirements are in their Operating Rules or similar documents.  In this case, Visa, Mastercard and Discover all require that service providers be PCI compliant as defined on their respective Web sites.  In the case of Visa and Mastercard, they maintain lists of PCI compliant service providers.  That said, those lists are marketing ploys that generate revenue for Visa and Mastercard as those service providers listed pay them to be on those lists. 

While Coop’s statement is accurate that the PCI DSS does not require service providers to be PCI compliant, it is shortsighted.  The Brands do require service providers to be PCI compliant and will enforce it through the merchant agreement/contract all organizations sign in order to accept those cards for payment.

The bottom line is that, if any service provider can provide you a current PCI Service Provider Attestation Of Compliance (AOC), you can use their services and comply with the Visa, Mastercard and Discover contracts.

Coop also stated that he has never seen the Brands enforce the contractual obligation when reviewing organizations’ ROCs and SAQs.  That is also a true statement but again not the complete story.  Based on what I have been told by lawyers that have been involved in breach litigation, it is the merchant agreement/contract that is used to hold breached merchants legally responsible and enforce fines, not PCI compliance or what is in any PCI document.  The PCI documents are used to influence fines and penalties, but the actual enforcement is through the contracts with the Brands.  If it is found that an organization was using non-PCI compliant service providers that just adds fuel to the fire.

As famous radio personality Paul Harvey used to say, “And that, is the rest of the story.”

The Joke That Is SAQ A

This week another outbreak of Magecart was detected in at least 19 eCommerce sites.  It is using a new way to obfuscate and gather cardholder data (CHD).  As I read through the latest description, it brought to mind SAQ A.

But before I launch into that diatribe, first a little bit of history so that everyone understands why SAQ A even exists.

In the early wild, wild west days of payment card security on the internet, enterprising solution providers were pandering “outsourced” solutions that would “avoid” compliance with the then Visa Cardholder Information Security Program (CISP) and MasterCard Site Data Protection (SDP) compliance efforts.  What they were selling was a solution that used a variety of Web site techniques to keep the CHD away from the merchant’s Web site.  These solutions sold themselves because they took the merchant out of scope from the very onerous Visa and MasterCard security programs.

Then along came the PCI DSS and the self-assessment questionnaires (SAQ).  As part of that process, the Council and the Brands realized that these so-called out of scope solutions were not really “out of scope”.  The result was SAQ A which covers these outsourced solutions.  For years they had kept their solutions out of the card brands’ compliance programs and now they were included.  SAQ A was good news, bad news moment for the solution providers.  The bad news was that there was no escaping the fact that their customers were now in scope for PCI compliance.  However, the good news was that to placate these solution providers who were lobbying loudly for no scope, the Council and Brands minimized the number of requirements in SAQ A to a very, very bare minimum so that these outsourced solutions would not scare their customer bases off due to PCI compliance.

Just for the record.  SAQ A is the absolute bare minimum number of requirements any merchant can comply with and be considered PCI compliant.  There is nothing less.

And Now The Jokes – Bad As They Are

The first joke is that SAQ A is the absolute prime example of compliance does not equal security, bar none.

Anyone that thinks compliance with SAQ A keeps their customer payments secure is seriously lying to themselves.  Magecart in all of its forms is exhibit number 1 as to why SAQ A is a joke and should be retired.

I have told my clients since SAQ A was published that if they thought compliance with SAQ A would keep them out of trouble to think again.  Yes, SAQ A keeps the processors, banks and brands happy, but it does nothing to manage the risk presented by any web site.  That is because if the code/executable/script on their server that invokes the redirect or iFrame is ever tampered with (as with Magecart), it will not be the processor or bank held legally responsible, it will be the merchant that operates that web site that is legally on the hook.

That is the second joke of SAQ A.  Merchants think they have pushed the payment card processing risk of their eCommerce operation off to a service provider and they have not.  Unknowingly, they still have a lot of skin in the game.  More than they realize or want to realize.

Yet time and again, I encounter merchants following SAQ A that blindly go about life without regularly patching, maintaining or monitoring their web site because “SAQ A says I do not need to do that”.  All of this under the mistaken belief that SAQ A’s requirements create security for that web site which they do not.  Sadly, I have also encountered a number of merchants over the years that have been caught in the SAQ A trap and found out the hard way the monetary and business costs of their beliefs in SAQ A protecting them from bad actors.

SAQ A Is Compliance Not Security

In the last update of the SAQs in 2018, the Council did address a minor shortcoming in SAQ A.  That addition was to require organizations to ensure that their Web server was patched current for critical vulnerabilities.  However, from a risk perspective for an internet-facing system, that did very little to ensure the security of merchant Web sites used for directing payment processing.

Notably, SAQ A does not require at least any of the following:

• Only one major service running, i.e., Web server with eCommerce application.
• External and internal vulnerability scanning.
• External and internal penetration testing.
• Critical file monitoring to identify if the redirect or iFrame invocation method has been tampered with.
• Logging and monitoring of the Web server and Web applications.

Most information security professionals would still likely consider even these aforementioned requirements inadequate.  These are all items I have told my clients I recommend, but even these absolute bare minimum steps for securing a Web server are not required for SAQ A compliance.

As a result, is it any surprise that most information security professionals and most QSAs consider SAQ A worthless for anything other than PCI compliance?  Organizations that truly understand information security also realize that SAQ A is not security and follow SAQ A-EP for ensuring the security of their out of scope Web servers.

The bottom line is that we in the payment security industry need to lobby the PCI SSC, banks and card brands to get rid of SAQ A before even more organizations get hurt.

Surprise! PCI Largely Ignores Disaster Recovery

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.

Work From Home PCI Considerations

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