Archive for the 'Card Brands' Category

02
Jan
22

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!

19
Dec
21

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!

24
Oct
21

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.

12
Dec
20

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.”

05
Apr
20

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.

31
Mar
20

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.
23
Mar
20

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

08
Dec
19

Are You A Level 2 Merchant? Beware The MasterCard Trap

I had a discussion with a prospective client and as things usually go you want to determine their merchant level.  As it turned out, they were confused about the differences between Level 3 and Level 4 and their bank was just as confused.  The merchant had a 2 to 1 advantage in Visa transactions (around 800K) over MasterCard and, in total, had more than one million transactions across all card brands.

When their bank couldn’t decide their merchant level, the bank referred them to Visa since the bank was affiliated with Visa.  Visa informed the merchant that they were considering them a Level 2 merchant because of the high volume of eCommerce transactions (80%+) and their total transaction count for all payment cards (around 1.3M).

With this information in hand I said, “Well, it looks like you’ll be doing a ROC.”

The CFO at the other end of the WebEx exclaimed, “Say what!  Why do we need to do a ROC?  The standard says we can do a self-assessment!”

Sadly, another merchant gets caught flatfooted by the card brand rules.  People think that the PCI DSS and other PCI standards are all they have to worry about for card payment compliance.  However, the card brands (i.e., Visa, MasterCard, American Express, Discover and JCB) also have their own security programs in addition to the PCI standards and those also need to be followed.  Think that is not the case?  That Merchant Agreement from the bank that someone in the merchant’s organization signed calls out that not only do PCI standards need to be followed but also the rules from the card brands the merchant has agreed to accept for payment (almost always Visa and MasterCard with one or more of the others) also need to be followed.

One of those “quirks” in the card brands’ programs that comes up is this one regarding Level 2 merchants and MasterCard.

The first thing everyone needs to remember is that if a merchant is at a certain merchant level for one card brand, they are at that merchant level for ALL the card brands.  The second thing to remember about merchant levels is that any of the card brands can set the merchant level for a merchant regardless of transaction volume.  I have had merchants end up as a Level 1 merchant with fewer than 30K transactions all because the dollar value per transaction was extremely high as with business to business (B2B) transactions.

With that information, a merchant now needs to go to the card brands’ Web sites for the brands you accept and review their rules.  If you go to the MasterCard Web site to the page titled ‘What merchants need to know about securing transactions’ and scroll down to the merchant level requirements for Level 2, you will see footnote 3 next to the requirement “Onsite Assessment at Merchant Discretion”.  That footnote states the following:

“Level 2 merchants that choose to complete an annual self-assessment questionnaire must ensure that staff engaged in the self-assessment attend PCI SSC ISA Training and pass the associated accreditation program annually in order to continue the option of self-assessment for compliance validation. Alternatively, Level 2 merchants may, at their own discretion, complete an annual onsite assessment conducted by a PCI SSC approved Qualified Security Assessor (QSA) rather than complete an annual self-assessment questionnaire.”

For an organization to get an employee trained as an ISA, you need an employee with backgrounds in compliance and technology.  Typically, this would be someone in the internal audit department that a lot of Level 2 organizations do not have or if they do have, the people do not have the time to take on PCI. Then there is the cost which is $3,100 USD plus travel expenses since most ISA training is not done locally unless you are lucky. And finally, there is the employee retention issue after such an investment.

In the end, most Level 2 organizations do not see the cost benefit of training one of their employees to be an ISA in order to do an SAQ.  As a result, that is why I get to my comment about Level 2 merchants doing a ROC.

Oh, and for the record, the PCI standards do not dictate which organizations can fill out a self-assessment questionnaire (SAQ) and which fill out a Report On Compliance (ROC).  The card brands dictate that based on merchant and service provider levels.  In this case, MasterCard has its own ideas in that regard when it came to Level 2 merchants.

21
May
19

An Inadvertent Service Provider

A discussion came up on the last PCI Dream Team session regarding situations at universities that have bookstores and cafeterias operated by third parties on their networks and those vendors processing payment card transactions.  QSAs encounter this situation not only at universities and colleges, but also with hospitals, health clinics and large corporations.

The Situation

As organizations focus on customer and employee perks, QSAs encounter third parties operating business outlets within a variety of organizations.  These businesses include coffee shops, convenience stores, dry cleaners, bookstores, restaurants, cafeterias, parking ramps, travel agencies, pharmacies, health clubs and a whole host of other businesses.  Of course, all of these third parties accept payment cards for their services and need a way to process those cards.  Organizations offering these perks have existing wired and wireless infrastructure that get leveraged to connect these third parties to the internet and their payment processors.  Thus, bringing that network and everything attached to that network into scope for PCI compliance.

As a result, this situation creates a PCI compliance problem because the organization is now a service provider as well as a merchant.  The organization thought by outsourcing these businesses it was reducing PCI scope not increasing scope.  But scope increases because since they are now considered a service provider, they must provide each of these third parties with a Service Provider Attestation Of Compliance (AOC) for that network connectivity.

But it can and does get worse.  I have encountered situations where the outsourcing organization provides help desk, firewalls and other support services for these third parties, further complicating their PCI compliance responsibilities.

What Do You Do? Option 1 – Get Out Of Scope

There are some ways to get out of scope, but these can be complex and/or expensive.

The first way to get out of scope is to force all of your third parties to get their own network connectivity from their own internet service provider (ISP).  The problem with this is that an ISP will likely have to run wire into your facilities to make those connections.  That can be disruptive as well as expensive and complicated due to locations within existing buildings.  And what if each business wants their own ISP because of a contract relationship?  That will mean multiple ISPs tearing up your facilities.  Not necessarily the best situation.

The most extreme solution to get out of scope is for the outsourcing organization to implement carrier equipment and become a “carrier” to these third parties.  I have had a few clients go down this road, but it is not cheap and can also be more trouble than it is worth.  However, for a university or large hospital/clinic complex with lots of third parties, this solution can actually be a cheaper route to implement and operate.

But the beauty of these solutions is that your organization is totally out of scope so there are no service provider PCI assessment requirements.

What Do You Do? Option 2 – Reduce Scope

There are also a couple of ways to reduce scope.  But reducing scope requires at a minimum the creation of a Service Provider SAQ D and AOC.

The quickest and easiest way to reduce scope is that the outsourcing organization can implement end-to-end encryption between the third party’s connection and the internet.  However, this adds the requirements in section 4 to the assessment as well as keeps the endpoints in scope for PCI compliance.

Another option to reduce scope is to require these third parties to implement encryption from their operation to anyone outside of the outsourcing organization.  While this seems simple, it usually never is simple.  Never mind the fact that if that encryption is ever stopped (most times without your knowledge), the outsourcing organization’s network is back in scope.  Typically, when this gets brought up as a solution, a lot of the third parties balk or say they do not know how to encrypt their connections.  Never mind the fact of the complexity of proving that the outsourcing organization does not have encryption keys and that every third party connection is encrypted becomes problematic.  It ends up more trouble than it is worth.

The only good news about reduced scope is that you only need to fill out a Service Provider SAQ D and AOC because you have no idea the transaction volumes being processed by any of these third parties.  That said though, it is additional paperwork that needs to be filled out annually and given to all your third parties.

Heaven help you though if you offer firewall, help desk and other support services in addition to connectivity.  Those just complicate your compliance and reporting efforts.  All I can say is, if you can stop offering those services, stop.  If you cannot stop those services, then be prepared to document and report on the PCI compliance of each of those services.  That can be done in a single assessment, but the AOC must cover each of those services provided individually in a separate section 2g.

Never mind the fact that if some of those services offered give your organization insight into the number of transactions processed by your third parties such as you provide payment processing under one or more of your merchant identifiers, you may end up having to conduct a Service Provider Report On Compliance (ROC) because the transaction volume exceeds one of the card brands’ annual service provider transaction volumes.

There you have it on third parties and their payments on your network.

22
Apr
19

More On The NIST Password Standard

Apparently, I touched a nerve with my post on the National Institute of Standards and Technology (NIST) password standards discussed in Special Publication (SP) 800-63B.  As a result, I thought I would walk you through my logic by using a compensating control worksheet (CCW) approach since this is what you will have to do for your PCI assessment if you chose to rely on the NIST guidance.

[SPOILER ALERT: It is possible, but I doubt it is worth all the effort.]

First, let us review all of what a CCW needs to comply with the Council’s requirements.  From Appendix B of the Report On Compliance (ROC) Reporting Template.

“Compensating controls must satisfy the following criteria:

  1. Meet the intent and rigor of the original PCI DSS requirement.

  2. Provide a similar level of defense as the original PCI DSS requirement, such that the compensating control sufficiently offsets the risk that the original PCI DSS requirement was designed to defend against. (See Guidance Column for the intent of each PCI DSS requirement.)

  3. Be “above and beyond” other PCI DSS requirements. (Simply being in compliance with other PCI DSS requirements is not a compensating control.)

  4. Be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement.”

QSAs can get stuck on the third point because the Council also seems to focus on that point in their Assessor Quality Management (AQM) reviews because QSAs miss that point so often.  However, the other three are also very important to apply to the compensating controls being discussed.

Now let us focus on is section 4 of the CCW where the organization being assessed is required to describe the controls they have in place that go “above and beyond” the requirement being compensating which in this case is requirement 8.2.4 which requires password changes every 90 days or less.  I pick that requirement because that is the one most often cited by clients as why they want to use the NIST standard.  Most want to go to a 12-month password change interval.  These controls are going to come from pages 13 through 15 of the SP800-63B.

  • All passwords are required to be [value greater than eight] characters or greater in length.
  • When passwords are modified, they are assessed against [name of credential verification source/service], [name of dictionary word list used], repetitive or sequential characters and context specific words are checked and rejected if found.
  • Authentication is only conducted using [encrypted authentication protocol(s)].
  • Passwords are hashed and salted for storage using [hash algorithm and appropriate salting technique].
  • [Name of password vault solution] is used to securely store and generate strong passwords that meet the aforementioned criteria.
  • A password strength meter is provided to assess the password against these aforementioned criteria to indicate to the user when they have met all of the criteria.

To comply with the NIST guidelines for passwords an organization needs to implement all of these controls.

So how do they match up with the four criteria for a CCW?

Above and Beyond

This is the easiest one to tackle because almost all of the controls are above and beyond.  What?  Almost?

There are a couple of controls that do not meet the above and beyond test.

The first is the easiest to discuss and that is “Authentication is only conducted using [encrypted authentication protocol(s)].”.  That control does not pass above and beyond because it is required by requirement 8.2.1 under transmission must use strong cryptography.  As such, that control cannot be relied upon in the CCW and must be removed.

The second one is the “Passwords are hashed and salted for storage using [hash algorithm and appropriate salting technique]” control.  This discussion gets sticky because requirement 8.2.1 states that storage of credentials must also use strong cryptography which is not very specific.  I would argue that any sort of reasonable response here would be required by requirement 8.2.1 and therefore this requirement would also be ineligible to be used.

Only the password length is specified by the PCI DSS and as long as a value greater than eight is picked, that meets above and beyond.  However, we need to discuss this value further under intent and rigor.

All of the remaining controls are not specified in the PCI DSS, so those are all considered above and beyond.

Intent and Rigor

For intent and rigor, we need to look to the guidance provided for requirement 8.2.4.

“Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to work on breaking the password/phrase.”

Remember, we are looking at a 12 month password change interval, so we need to consider intent and rigor under that concept that we need controls that will allow a password to remain unchanged for 12 months.

So let us look at the length attribute again.  Nine characters in today’s world without any complexity requirements can result in passwords able to be cracked in minutes.  Ten characters can be done in hours.  Only when we get to 12 characters and above do we get a value of at least 12 months or greater to crack.  As such, I would argue that you need 12 character long passwords or greater to pass the rigor requirement for justifying a 12 month change interval.

Passwords are assessed against a dictionary word list, context specific words and repetitive/sequential characters.  The key to this part of the second bullet is the extent of the dictionary word list.  The dictionary needs to be sufficiently large to provide the control that NIST desires.  The QSA is going to need to know how large the dictionary is, what is used as a reference to ensure that the dictionary has the appropriate words in its list and how often is the dictionary updated.  That would likely mean that these controls would need to be separated from the credential breach service control so that those aforementioned additional controls can be documented in the CCW. This would all have to be backed up by a proper risk assessment that documents that the review and updatee intervals of the dicutionary are appropriate and mitigate the risks.

Passwords being assessed to some credentialed breach source/service introduces an interesting twist to ensuring the security of a password.  But it also introduces an interesting discussion into the intent of requirement 8.2.4 which is to ensure the security of credentials.  NIST is only requiring that credentials be tested at the point they are changed.  But what happens if sometime during the 12 month interval that those credentials are compromised?  The intent of requiring a 90 day change interval was to reduce the risk of credentials becoming compromised for an extended length of time by changing one of those credentials at least every 90 days.

But NIST does not require monitoring of the credentials other than when they change.  Without constant monitoring of the credentials from a compromise service, how do you know when they need to be changed which is the intent of the change interval?

The PCI DSS does provide a bit of guidance on how the Council would likely approach this issue.  For reference I point you to requirement 3.6.5 which discusses this in regard to encryption keys that are suspected to have been compromised.  The reason I believe this is relevant here is that the PCI DSS does not require specific change intervals for encryption keys.  I would argue that the PCI DSS would view passwords changing at long intervals as requiring the same sort of control.  If the credentials are ever suspected of being compromised, then they should be changed.

Which brings up an interesting dilemma.  How do you monitor something that you have hashed and cannot recover?  Do we really want to have encrypted passwords in our authentication systems so that we can monitor them for compromise?  I seriously doubt that would be a good practice.

So with that said, we would need some sort of monitoring and alerting capability to warn if credentials do appear to be compromised such as monitoring for excessive logons, logons when the user is out of the office, logons from systems outside of the user’s area or building or other characteristics that would provide some sort of indication of credential compromise.  These controls would have to be added to the monitoring of the credential breach source to show that the credentials are changed when suspected of being compromised.

Similar Level of Defense and Be Commensurate

At this point, I think we have covered these two requirements for a CCW with our discussions about above and beyond and intent and rigor.

Where Are We With The CCW Controls?

Based on our discussion, here is what I think section 4 of the CCW would now have to look like.

  • All passwords are required to be [value of 12+] characters or greater in length.
  • When passwords are modified, they are assessed against [name of credential verification source/service]
  • Passwords are monitored for excessive logons, excessive failed logon attempts, logons when the user is out of the office and logons that occur from systems outside of the user’s area or building to provide an indication of credential compromise.
  • When passwords are modified, [name of dictionary word list/source used], repetitive or sequential characters and context specific words are checked, and the password is rejected if any of these characteristics are found. The dictionary is updated every [month/quarter/six months] and reviewed [semi-annually/annually] to ensure the dictionary contains an appropriate list of words.
  • [Name of password vault solution] is used to securely store and generate strong passwords that meet the aforementioned criteria.
  • A password strength meter is provided to assess the password against these aforementioned criteria to indicate to the user when they have met all of the criteria.

After looking at these controls, I would venture to say it is simpler and easier to meet the PCI DSS requirements than to implement these controls and make them work consistently and effectively.  Because remember, this is just section 4 of the CCW.  For section 5, you have to produce evidence that all of these controls are in place and working as designed.  Never mind section 6 where you explain how you maintain all of these controls.

So for those of you bent on using NIST, there you have it but I doubt it is worth the effort you think it is.  And this does not address the CCWs you will also need to write for 8.2.3 because you no longer enforce complexity and 8.2.5 because you no longer track the last four passwords used.  But those could be another post.  Yeah, I do not think so.  Not worth the effort because those CCWs will revolve around the controls in this one.

As I said in my original post, it might be better to wait for the Council to issue their guidance in v4 of the PCI DSS.

UPDATE: The PCI Council has created an FAQ to address this situation. https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Can-organizations-use-alternative-password-management-methods-to-meet-PCI-DSS-Requirement-8




January 2022
M T W T F S S
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Months