Being a responsible corporate citizen and member of the local community is at the core of Control Gap’s daily operations. We believe in making work a rewarding experience by incorporating fun team events within our corporate culture, and supporting cause-related and local organizations.

Blog

WP_Query Object ( [query] => Array ( [post_type] => post [post_status] => publish [cat] => 14, 134, 1 [orderby] => date [order] => desc [posts_per_page] => 3 [paged] => 4 [ignore_sticky_posts] => 1 ) [query_vars] => Array ( [post_type] => post [post_status] => publish [cat] => 14 [orderby] => date [order] => DESC [posts_per_page] => 3 [paged] => 4 [ignore_sticky_posts] => 1 [error] => [m] => [p] => 0 [post_parent] => [subpost] => [subpost_id] => [attachment] => [attachment_id] => 0 [name] => [static] => [pagename] => [page_id] => 0 [second] => [minute] => [hour] => [day] => 0 [monthnum] => 0 [year] => 0 [w] => 0 [category_name] => charity [tag] => [tag_id] => [author] => [author_name] => [feed] => [tb] => [meta_key] => [meta_value] => [preview] => [s] => [sentence] => [title] => [fields] => [menu_order] => [embed] => [category__in] => Array ( ) [category__not_in] => Array ( ) [category__and] => Array ( ) [post__in] => Array ( ) [post__not_in] => Array ( ) [post_name__in] => Array ( ) [tag__in] => Array ( ) [tag__not_in] => Array ( ) [tag__and] => Array ( ) [tag_slug__in] => Array ( ) [tag_slug__and] => Array ( ) [post_parent__in] => Array ( ) [post_parent__not_in] => Array ( ) [author__in] => Array ( ) [author__not_in] => Array ( ) [update_post_term_cache] => 1 [suppress_filters] => [cache_results] => [lazy_load_term_meta] => 1 [update_post_meta_cache] => 1 [nopaging] => [comments_per_page] => 50 [no_found_rows] => ) [tax_query] => WP_Tax_Query Object ( [queries] => Array ( [0] => Array ( [taxonomy] => category [terms] => Array ( [0] => 14 [1] => 134 [2] => 1 ) [field] => term_id [operator] => IN [include_children] => 1 ) ) [relation] => AND [table_aliases:protected] => Array ( [0] => wpcm_term_relationships ) [queried_terms] => Array ( [category] => Array ( [terms] => Array ( [0] => 14 [1] => 134 [2] => 1 ) [field] => term_id ) ) [primary_table] => wpcm_posts [primary_id_column] => ID ) [meta_query] => WP_Meta_Query Object ( [queries] => Array ( ) [relation] => [meta_table] => [meta_id_column] => [primary_table] => [primary_id_column] => [table_aliases:protected] => Array ( ) [clauses:protected] => Array ( ) [has_or_relation:protected] => ) [date_query] => [request] => SELECT SQL_CALC_FOUND_ROWS wpcm_posts.ID FROM wpcm_posts LEFT JOIN wpcm_term_relationships ON (wpcm_posts.ID = wpcm_term_relationships.object_id) WHERE 1=1 AND ( wpcm_term_relationships.term_taxonomy_id IN (1,14,134) ) AND wpcm_posts.post_type = 'post' AND ((wpcm_posts.post_status = 'publish')) GROUP BY wpcm_posts.ID ORDER BY wpcm_posts.menu_order, wpcm_posts.post_date DESC LIMIT 9, 3 [posts] => Array ( [0] => WP_Post Object ( [ID] => 1497 [post_author] => 2 [post_date] => 2017-06-27 17:13:21 [post_date_gmt] => 2017-06-27 17:13:21 [post_content] => Compliance simplification, what most people call “scope reduction”, can have huge benefits in terms of saving time, effort, headaches, and money. Merchants desire ways to simplify their PCI compliance as do the card brands, acquirers, and processors. When the PCI Council announced P2PE in 2011, there was an immediate and huge demand for approved P2PE solutions. It wasn’t that merchants wanted P2PE, rather they wanted the massive compliance simplification and risk reduction that P2PE promised to provide. QSAs and ISAs hoped for clear assessment requirements to make their merchant PCI DSS assessments simpler and less ambiguous. Late in 2016, the PCI Council announced NESA (Non-listed Encryption Assessments) and there was again an immediate and huge demand for this. The problem is that the demand is based on perception not understanding. Let’s be clear there is only one PCI approved and promoted class of solutions that provides the simplicity and clarity to simplify compliance through encryption. That is P2PE, but that isn’t the whole story. This article will look at the differences between these three types of solutions and how they can be handled under PCI. In many ways, a P2PE solution can feel like the “holy grail” of PCI, reducing the scope to only the device.  In reality, P2PE solutions reduce the applicable requirements on connected-to devices to nothing. Before we get started, the PCI Council’s guidance is clear that it is possible to simplify compliance in a justifiable and defensible fashion and this applies to several different types of encryption solutions.  However, the guidance is not well understood, as it matters how you go about it. For non-P2PE, the Acquirer or Card Brands must agree to any compliance simplification. In practice, this is almost always the Acquirer's call.

Merchants and Encryption Solutions

When merchants invest in encryption solutions, there are a number of factors that need consideration, such as availability of P2PE, cost of the solution, projected end of life, support, local or regional factors, functionality, existing contracts and more. The challenge is that the entire landscape for encryption solutions is changing rapidly. Full transition to P2PE will take time. Merchants want to ensure they are compliant with PCI DSS, but need to balance the cost of investing in technology solutions, with maintaining their day-to-day business, ensuring that there is a positive return on investment (ROI). Acquirers and Processors understand the demand of the market and their merchants as they strive to provide viable options for their customers. They are all acutely aware of market demand and risks. As merchants evaluate P2PE, Acquirers and processors are too preparing to evolve their offerings because of demand and because it is the right thing to do. Many are reviewing their own investment requirements to support P2PE, while others are actively pursuing P2PE solutions to be able to support the market demand.

The Long Road to P2PE

Most people don’t appreciate how big a job it is to build a P2PE solution. It isn’t just about the initial and ongoing investment, there can be significant challenges. P2PE v1 lacked flexibility. P2PE v2 improved on that significantly. The situation is evolving and will continue to do so. While not only the P2PE standard evolves, the market itself is transforming producing a mixture of solutions. All stakeholders in this space need to understand that and learn how to deal with these changes. To illustrate this, the following charts show the current and historical state of P2PE approved solutions including the gaps between changes to the P2PE standard and emergence of the first solutions. Clearly, launching a P2PE solution is easily a one to two-year project. Merchants and assessors want to have the best solution possible, but let us also be clear, leveraging good encryption technology today is better than waiting to leverage the best encryption technology two or three years from now.    

Point-to-Point Encryption (P2PE)

P2PE is an official program of the PCI Standards Council and it is the only class of solution promoted by the council that permits automatic compliance simplification (aka scope reduction). However, the use of P2PE solutions is not mandatory.

Benefits:

  • Designed to address complex scenarios like third party processors and decryption environments, multiple acquirers, multiple co-resident applications, loyalty and other non-financial cards, supply chain attacks, and more
  • Clear merchant assessment process that provides qualifying (i.e. eligible) merchants a small compliance footprint. This includes having a dedicated Self-Assessment Questionnaire SAQ-P2PE. It is easy for QSAs and ISAs to assess
  • Extremely tightly locked down with little wiggle room for an attacker to exploit
  • Places more of the compliance burden on the solution, application, and component providers
  • Very high assurance of encryption capability and continued operation
  • Follows the P2PE architecture
  • Well supported by PCI SSC including approved solution, component, and application listings vetted through quality assurance process
  • There are incentives available from the card brands that may provide additional benefits

Other Observations:

  • Still limited in availability
  • Lengthy for solution providers to implement and complete a successful assessment
  • May pay a premium for solutions and/or transaction cost
  • Merchant still has responsibilities including for anti-skimming
If you want an analogy for P2PE, this is the DeathStar, a shiny new Battleship, or the BatMobile. All with a bumper to bumper warranty. But you still have to change the oil.

Non-Listed Encryption Security Assessment (NESA)

NESA is a tool created by the P2PE program to provide improved clarity and ease the PCI DSS assessment process for merchants, ISAs and QSAs when encountering solutions that are in the process of attaining P2PE validation but haven’t yet crossed the finish line. It is not promoted by the PCI SSC, nor is it a certification or approval. It is not P2PE-lite, P2PE-junior, or P2PE-anything-else. Its use is most certainly not mandated. However, in the absence of a fully validated P2PE solution, this is a good measuring stick to use.

Benefits:

  • Useful for those on the path to P2PE certification to show work in progress to their merchants and their QSAs
  • Provides QSAs and ISAs with recommendations from P2PE QSAs on the potential for compliance simplification in a standardized deliverable
  • High assurance of encryption capability and continued operation
  • Shows potential to reach P2PE and its benefits
  • It may help overcome the problem that P2PE developers have had negotiating access to enable SRED from some terminal manufacturers
  • Follows the P2PE architecture
  • Requires the same quality and attention to assessment detail as P2PE
  • Provides Acquirers with a standardized way to evaluate if they will take the risk for third-party compliance simplification
  • Clear merchant assessment process that may provide qualifying (i.e. eligible) merchants a small compliance footprint.

Other Observations:

  • Unknown availability, no listings or tracking of solutions
  • Still lengthy for solution providers to implement and assess
  • May pay a premium for solutions and/or transaction cost
  • Cannot use the P2PE Self-Assessment Questionnaire SAQ-P2PE.
  • Merchant still has responsibilities including for anti-skimming
  • Solutions don’t require SRED to be enabled.
  • Slightly more complicated for QSAs and ISAs to assess
The NESA template report summarizes the results of a non-compliant P2PE assessment. It’s divided into three main sections:
  • An informational and assessor acknowledgement section
  • A summary of how the solution deviates from P2PE
    • Deviations are currently only permitted in the actual device, application, and management of the solution. (i.e. domains 1-3)
    • All of the back end decryption environment and key injection (i.e. domains 5-6)must be fully compliant with P2PE
  • Recommendations of how the solution works with PCI DSS and where compliance can be simplified
If you want an analogy for NESA, this is the DeathStar under construction, a new Frigate during trials, or a cool armored car prototype. All without a warranty. And you still have to change the oil.

End-to-End Encryption (E2EE)

This is a catch all term for other approaches to providing encryption solutions. E2EE solutions are not standardized or necessarily consistent. Sometimes the term is totally misapplied or is misrepresented as P2PE. By nature, since these solutions do not provide automatic compliance simplification like P2PE, they require more due diligence and may be more limited than P2PE or NESA. Many of these solutions are an excellent alternative for merchants and are supported with documentation to give merchants, assessors, and implementers confidence that the solution is not simply good marketing, but that the solution provider has invested some due diligence in validating the solution, sometimes with significant rigor. The questions are how to know which solutions are good and how to safely achieve compliance footprints similar to P2PE. For purposes of this article, a good E2EE solution resides inside a PTS approved payment terminal, doesn’t release or leak cardholder or sensitive authentication data, doesn’t share or expose keys, and protects the encryption mechanism. A good solution minimizes the attack surface and wiggle room for an attacker.

Benefits:

  • Useful to merchants when P2PE and NESA solutions weren’t available or feasible.
  • Useful to acquirers with pre-existing encrypting solutions with a non-P2PE architecture (e.g. software encryption or a different back-end)
  • More beneficial if offered by an acquirer who controls and understands solution and has accepted risk
  • Potential to simplify merchant compliance

Other Observations:

  • More due diligence required on merchant side
  • Third party solution providers may be challenged to gain acquirer acceptance
  • More complicated for QSAs and ISAs to assess
  • Requires more understanding of the solution
  • What constitutes suitable validation steps
  • Solutions don’t require SRED to be enabled
  • Cannot use the P2PE Self-Assessment Questionnaire SAQ-P2PE.
  • Merchant still has responsibilities including for anti-skimming
  • Your mileage may vary
If you want an analogy for a good E2EE solution, this is a serviceable but slightly rusty Destroyer. No warranty. The oil still needs changing.

Legacy Integrated POS

For completeness, these systems are connected, and typically see cardholder and sensitive authentication data, and are fully in-scope for all applicable PCI DSS requirements. Unfortunately, that means most PCI DSS requirements will apply. They are tricky to secure and configure and they leave a lot of wiggle room for attack. The vast majority of payment breaches happen at the POS with ever increasing malware sophistication. Many merchants and service providers will reduce their PCI compliance scope by leveraging a PA-DSS compliant application. But it does not completely remove PCI scope, rather, it helps fast track many of the PCI requirements by transferring the responsibility to a third party. The analogy here is a leaky long boat with all hands bailing frantically and pirates on the horizon.

Assessment Aids for E2EE

When examining E2EE solutions there is a clear requirement to validate. Ultimately the merchant QSA/ISA will need to be comfortable with the solution and determine what validation steps they must perform, and which they can rely upon. They will also need to comfortable that the acquirer (or brands) support any simplification. Here we describe some of the aids and resources you may encounter.

PTS

PTS is the PCI program and standard that applies to the hardware payment terminal itself. It’s the bedrock on which P2PE, NESA, and good E2EE solutions are built. PTS approvals provide assurance that the device is resistant to tampering, supports good key management, and includes controls such as cryptographic key signing. PTS is modular and has functions that cover things like the display and various card reader components, Open Protocols (OP) (e.g. TCP/IP, WiFi, Bluetooth), and Secure Reading and Exchange of Data (SRED) which covers encryption including the use of hardware, firmware, configuration, and APIs used inside the terminal. PTS may also cover aspects of the payment application and what are referred to as firmware applications. PTS can be relied upon with minimal validation by confirming the device approval and functionality. It is worth nothing that confirming if a device is SRED is enabled vs capable is not straight forward. Due to this, most E2EE solutions will not have SRED enabled.

PA-DSS and Payment Terminals

Validation options for terminal payment applications can be a bit confusing because there are many of them. Payment applications in terminals need to be covered by some kind of PCI validation. It can be P2PE, PA-DSS, DSS, or even PTS (firmware). A couple of points are worth noting. First, PA-DSS is not required for P2PE applications as that is part of P2PE. And secondly, while PA-DSS is valuable to DSS it does not by itself provide any validation or guarantee that it can simplify compliance or reduce a merchant compliance footprint. That requires additional validation. PA-DSS can be relied upon for the device DSS. The PCI Implementation Guide (IG) must be followed by the merchant. It can prove invaluable in gaining understanding of the solution. The IG will help in determining what additional validation is needed to support compliance simplification.

Whitepapers

Many solution providers have whitepapers about their E2EE solution and make claims about the ability to simplify compliance. It is important to remember that these aren’t official attestations and cannot be relied upon by themselves. As there is no standard for these, the quality and completeness can vary significantly. However, good whitepapers can be invaluable in E2EE validation. The good ones will have characteristics such as:
  • Detailed explanation of the solution and how it operates
  • Involve actual testing of the solution and explanations of how it was tested, not just that the solution can encrypt sometimes
  • Explain how all the key objectives were met
  • Provide sufficient information that the merchant assessor can link solutions in the field to the whitepaper
  • Allow the merchant assessor to determine an appropriate level of validation
  • References including Solution provider documents and PCI guidance

Acquirer Acceptance

Acquirers are ultimately responsible for monitoring and accepting merchant risk. They can accept compliance simplification for E2EE solutions. They may or may not accept the risk of a breach.

Validation

A merchant and assessor equipped with good validation aids should be able to determine an appropriate series of validation steps. They should consider all available aids, such as:
  • Evidence of PTS
  • Evidence of Solution provider DSS
  • Evidence of PA-DSS
  • Formal guidance such as P2PE Implementation Manuals (PIMs) and PA-DSS PCI Implementation Guides (IGs)
  • Acquirer Acceptance
  • Whitepapers and solution provider documentation
  • Acquirer support to gain comfort and with some validation efforts where necessary

Reporting

SAQ merchants can’t use SAQ-P2PE. Instead they will need to use the most appropriate form (e.g. SAQ B-IP, SAQ-D, etc.) that they are eligible for and justify any non-applicability.

Due Diligence and Red Flags

With any encryption solution, due diligence is important. It’s easy enough for even an honest and diligent salesperson to get it wrong. You will need formal documentation. And you’ll need to confirm if your Acquirer supports you. This is clearest with P2PE. Over the years we’ve heard a lot of things that raised some obvious red flags, here are a few paraphrased examples (and our reaction):
  • Our application is P2PE certified (But is the Solution? So, back to E2EE then)
  • We’re using the same solution as _______ (But their gateway is in Europe, so how is yours certified?)
  • Our third party E2EE gateway and application supports scope-reduction (But does the merchant’s acquirer accept that? Does your gateway take the risk?)
  • We have a P2PE application (And? Is it certified? And the solution?)
  • Our PC based POS application provides E2EE functionality and facilitates scope reduction. (Do you even understand the first thing about PCI scope?)
  • Our E2EE solution encrypts from the terminal to the POS and our middleware re-encrypts for the bank (How does end-to-middle-to-end qualify as end-to-end?
  • In case of problems the solution can be reset to legacy by the POS? (You do know that security impacting systems are in scope too. Don’t you?)

Breaches

No one wants a breach. And no-one wants to have a breach because they oversimplified their compliance. So what can go wrong in these scenarios?
  • In any of these, even P2PE, there could be overlooked merchant scope. A reservoir of old legacy systems or some ad-hoc flow developed by a customer service focused employee. Or shadow IT. This is why documented validated flows and accurate inventories are critical.
  • Also with any of these things, there could be compliance lapses. Usually things like this happen in processes rather than technology.
  • But what could happen in non-P2PE
    • Probably one of the most likely scenarios would be cases where the terminals are deployed before encryption is enabled and they have the capability to operate in a legacy mode.
    • Failure to use SRED is possible but less likely as many terminals this is essentially a configuration option and the core encryption for SRED and non-SRED are shared.
    • Changes in host generated receipts could result in cardholder data leakage.
    • Poorly controlled loyalty card read-back.
    • The ability to make unauthorized key changes.

Learn More:

If you are at a critical point in your technology or solution design decision process and would like a second opinion, give Control Gap a call, we are happy to help. [post_title] => Understanding P2PE, NESA, E2EE, and PCI Compliance [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => understanding-encryption-and-pci-compliance [to_ping] => [pinged] => https://controlgap.com/blog/pci-nesa-2/ https://controlgap.com/blog/pci-compliance-footprints/ [post_modified] => 2017-07-06 15:33:29 [post_modified_gmt] => 2017-07-06 15:33:29 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1497 [menu_order] => 73 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [1] => WP_Post Object ( [ID] => 1469 [post_author] => 2 [post_date] => 2017-05-15 19:58:47 [post_date_gmt] => 2017-05-15 19:58:47 [post_content] => On May 1st a critical new and possibly unprecedented vulnerability was announced.  The flaw in Intel's Active Management Technology (AMT) firmware will be difficult to deal with, in part, because most organizations are not setup to rapidly deploy firmware updates across large numbers of systems.  The feature is supported by almost a decades worth of Intel chip sets, firmware, and OEM customization. We expect the vulnerability will have significant impact on organization's security and compliance programs. It is imperative for organizations to ensure they carefully manage the risk from AMT. We've been closely monitoring developments with this and are including reference links to articles and resources.  We highly recommend a number of Must Reads (below) that include Intel's guidance and SSH's tracking page that contains a wealth of information relating to this.

Understanding this Vulnerability

Systems that are most at risk have a) vulnerable chip set and firmware; and b) the AMT functionality provisioned on the hardware. Intel's diagnostics answers part a). There are a number of diagnostic tools available to assess part b) including commercial vulnerability scanners such as Nessus, Rapid 7, and Qualys.  Even Nmap can identify systems that may be at risk. We were curious about the vulnerability and set out to demonstrate it so that we could get the feel of it.  We selected a laptop with a vulnerable chip set that had not been provisioned for AMT.  Next we set out to provision it for testing. Once enabled, we were able to easily reproduce the exploit and observe it in operation. As expected, host based firewalls provided no protection and we were able to remote into running systems.  We were also able to remote into systems that had been shutdown. This last capability is both powerful and disturbing. Even though this functionality is documented, on a gut level it is still somewhat unexpected. Because the vulnerability lives in the firmware and chip set, organizations must assess the risk more broadly than they are used to with most software bugs.  Additionally because patches will need to come from the OEMs, organizations will have a more complex task of coordinating, prioritizing, and implementing updates which may not be available for weeks and may not be available for all systems. Many organizations will need to consider interim mitigation measures. Affected systems could include VM Host systems, non-windows systems, and even some appliances in addition to Windows servers, workstations, and laptops. Organizations that under estimate these characteristics could be in for some unpleasant surprises.

What to do Now

Organizations need to immediately asses their exposure and risk and then follow-up with a prioritized plan.
  • Undertake a focused discovery exercise to identify all of your vulnerable and potentially vulnerable systems. Don't exclude systems based on assumptions.
  • Analyze and prioritize the results based on risk factors such as visibility (internal/external), system sensitivity, etc. Perform this exercise for both the vulnerable and potentially vulnerable groups.
  • Develop specific remediation/mitigation strategies for each group and risk factor. Roll these out on a priority basis. Ensure you loop back to further investigate systems that show signs of potential vulnerability.
  • Consider stop-gap measures including specific IDS monitoring and additional network firewall level firewall rules.
  • Monitor and confirm remediation.
  • Keep records of these activities.

Don't Worry About the Future

We'd be surprised if this is the only security bug in the Intel Management Engine. And we're certain that this will be the focus of much new security research. Going forward, organizations should
  • Make sure AMT and ME are on their vulnerability management radar
  • Strongly consider turning AMT off and putting in place processes to ensure it doesn't creep back in
  • If AMT is needed, implement best practices to secure it and consider other mitigation to limit risk

Will Systems Need to be Replaced?

While this is possible, for most organizations we wouldn't expect this drastic an action will be required for most of their systems. The specifics will depend on many factors including equipment age, OEM, exposure/risk of individual systems, and mitigation applied. You should expect that your mileage may vary.

What about PCI Compliance?

Do NOT try and explain AMT away by arguing that PCI doesn't apply to server hardware just because it it doesn't explicitly call it out. Nor should you justify lack of action by assumptions. These approaches will not hold up to scrutiny. If AMT leads to a breach, the forensic investigation will conclude the organization was not compliant. Do have an active risk management plan active and in play supported by evidence (e.g. inventories/discoveries, analysis, decisions, recommendations, progress, etc.).  The plan needs to be risk based and prioritized. If there are constraints on patch availability or patching logistics, implement other mitigation. Preventative controls are great if they're available, if not, ensure you can detect and react.  And lastly, if you need this functionality going forward, you will need to figure out how to ensure it's compliant with applicable requirements (e.g. changing default credentials). This is the best response.

References

Must Reads

Intel Resources

Technical Articles

Online Articles, Explanations, and How-To's

Unrelated / Thanks

[post_title] => PCI Compliance and the Intel AMT Vulnerability [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => pci-compliance-intel-amt-vulnerability [to_ping] => [pinged] => https://mattermedia.com/blog/disabling-intel-amt/ [post_modified] => 2017-05-15 20:01:47 [post_modified_gmt] => 2017-05-15 20:01:47 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1469 [menu_order] => 80 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [2] => WP_Post Object ( [ID] => 1466 [post_author] => 2 [post_date] => 2017-05-10 17:33:27 [post_date_gmt] => 2017-05-10 17:33:27 [post_content] => Last month we wrote this article about issues arising from the addition of new BIN ranges and the lack of clear guidance specifically with 16-digit PAN that have 8-digit BINs. Today, the PCI Council just updated FAQ#1091 "What are acceptable formats for truncation of primary account numbers?" to specifically address the issue of how to truncate 16-digit PAN with 8-digit BIN. The short answer is that PCI's first six and last 4 truncation rule applies (see below) .  But, and there is a but here, not all of the issues we identified will go away. This clarification on acceptable truncation is very welcome as it provides stability to the payments ecosystem.  However, organizations will still need to understand the impact of these changes on their payment systems. Guidance from the brands is also clear that relying on truncation alone will not be sufficient to protect the data if more digits are kept.
  • For organizations that do not need to keep the full BIN, there should be little if any impact and should be able to continue to use 6&4 truncation. They should however validate this to ensure there are no unpleasant surprises. We expect the majority of merchants will be in this group.
  • Some organizations will need to keep the full BIN.  They will need to take additional steps (e.g. encryption, tokenization, etc.) to protect that information while stored. In many cases this could introduce additional data elements that impact PCI DSS scope or the number of applicable requirements within their scope. Organizations need to carefully evaluate the impact and implement changes to ensure they stay compliant.  These are changes that, if implemented without considering compliance,  could require substantial remediation.
Lastly, we urge caution if you are using 6&4 truncation when these new PAN/BIN ranges go live. Specifically, we recommend that you monitor the risk of correlating truncated data to PAN considering both internal and external factors. Why? Because, we believe there may be additional risk here depending on how the Card Brands and Issuers allocate these BIN ranges.  And while these are primarily risk questions for those organizations, you should also be aware of the risk. If you can live with more aggressively truncated PAN that will help to address this risk. For example, consider the following approach which assumes an attacker can get 6&4 truncated PAN from your organization and a separate list of 8-digit BINs that are allocated and/or in use.  The correlation risk will depend on how many of these BIN ranges match in the first six digits. If the BIN ranges are sparsely allocated there will be fewer 8-digit BINs with the same first 6-digits and correlation will be much easier than if the 6-digit ranges are densely allocated. Using fictitious examples from the previous article to bound the risk:
PAN Rule Truncation Strength Compliance
9234567890123455 6-4/16 923456xxxxxx3455 1 : 100,000 PCI 3.2
9234567890123455 8-4/16 92345678xxxx3455 1 : 1,000 Not PCI 3.2 compliant
As you can see, depending on how sparsely the 8-digit BINs beginning 923456 are allocated, the strength will vary considerably. It is also clear, that anything less than full allocation reduces the strength.
Number of BINs in 923456xx Strength
100 1 : 100,000
50 1 : 50,000
25 1 : 25,000
10 1 : 10,000
1 1 : 1,000
For a more detailed discussion of the issues please read our original article. _______________________________________________________________ Becoming PCI Compliant can be difficult, so why not let Control Gap guide you. We are the largest dedicated PCI compliance company in Canada. Contact us today and learn more about how we can help you: Get PCI Compliant. Stay PCI Compliant. [post_title] => 8-digit BIN Issues and Risks Remain after PCI Truncation Rules Clarified [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => pci-truncation-rules-clarified [to_ping] => [pinged] => https://controlgap.com/blog/new-bin-ranges-and-pci-truncation/ [post_modified] => 2018-05-02 02:48:05 [post_modified_gmt] => 2018-05-02 02:48:05 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1466 [menu_order] => 82 [post_type] => post [post_mime_type] => [comment_count] => 1 [filter] => raw ) ) [post_count] => 3 [current_post] => -1 [in_the_loop] => [post] => WP_Post Object ( [ID] => 1497 [post_author] => 2 [post_date] => 2017-06-27 17:13:21 [post_date_gmt] => 2017-06-27 17:13:21 [post_content] => Compliance simplification, what most people call “scope reduction”, can have huge benefits in terms of saving time, effort, headaches, and money. Merchants desire ways to simplify their PCI compliance as do the card brands, acquirers, and processors. When the PCI Council announced P2PE in 2011, there was an immediate and huge demand for approved P2PE solutions. It wasn’t that merchants wanted P2PE, rather they wanted the massive compliance simplification and risk reduction that P2PE promised to provide. QSAs and ISAs hoped for clear assessment requirements to make their merchant PCI DSS assessments simpler and less ambiguous. Late in 2016, the PCI Council announced NESA (Non-listed Encryption Assessments) and there was again an immediate and huge demand for this. The problem is that the demand is based on perception not understanding. Let’s be clear there is only one PCI approved and promoted class of solutions that provides the simplicity and clarity to simplify compliance through encryption. That is P2PE, but that isn’t the whole story. This article will look at the differences between these three types of solutions and how they can be handled under PCI. In many ways, a P2PE solution can feel like the “holy grail” of PCI, reducing the scope to only the device.  In reality, P2PE solutions reduce the applicable requirements on connected-to devices to nothing. Before we get started, the PCI Council’s guidance is clear that it is possible to simplify compliance in a justifiable and defensible fashion and this applies to several different types of encryption solutions.  However, the guidance is not well understood, as it matters how you go about it. For non-P2PE, the Acquirer or Card Brands must agree to any compliance simplification. In practice, this is almost always the Acquirer's call.

Merchants and Encryption Solutions

When merchants invest in encryption solutions, there are a number of factors that need consideration, such as availability of P2PE, cost of the solution, projected end of life, support, local or regional factors, functionality, existing contracts and more. The challenge is that the entire landscape for encryption solutions is changing rapidly. Full transition to P2PE will take time. Merchants want to ensure they are compliant with PCI DSS, but need to balance the cost of investing in technology solutions, with maintaining their day-to-day business, ensuring that there is a positive return on investment (ROI). Acquirers and Processors understand the demand of the market and their merchants as they strive to provide viable options for their customers. They are all acutely aware of market demand and risks. As merchants evaluate P2PE, Acquirers and processors are too preparing to evolve their offerings because of demand and because it is the right thing to do. Many are reviewing their own investment requirements to support P2PE, while others are actively pursuing P2PE solutions to be able to support the market demand.

The Long Road to P2PE

Most people don’t appreciate how big a job it is to build a P2PE solution. It isn’t just about the initial and ongoing investment, there can be significant challenges. P2PE v1 lacked flexibility. P2PE v2 improved on that significantly. The situation is evolving and will continue to do so. While not only the P2PE standard evolves, the market itself is transforming producing a mixture of solutions. All stakeholders in this space need to understand that and learn how to deal with these changes. To illustrate this, the following charts show the current and historical state of P2PE approved solutions including the gaps between changes to the P2PE standard and emergence of the first solutions. Clearly, launching a P2PE solution is easily a one to two-year project. Merchants and assessors want to have the best solution possible, but let us also be clear, leveraging good encryption technology today is better than waiting to leverage the best encryption technology two or three years from now.    

Point-to-Point Encryption (P2PE)

P2PE is an official program of the PCI Standards Council and it is the only class of solution promoted by the council that permits automatic compliance simplification (aka scope reduction). However, the use of P2PE solutions is not mandatory.

Benefits:

  • Designed to address complex scenarios like third party processors and decryption environments, multiple acquirers, multiple co-resident applications, loyalty and other non-financial cards, supply chain attacks, and more
  • Clear merchant assessment process that provides qualifying (i.e. eligible) merchants a small compliance footprint. This includes having a dedicated Self-Assessment Questionnaire SAQ-P2PE. It is easy for QSAs and ISAs to assess
  • Extremely tightly locked down with little wiggle room for an attacker to exploit
  • Places more of the compliance burden on the solution, application, and component providers
  • Very high assurance of encryption capability and continued operation
  • Follows the P2PE architecture
  • Well supported by PCI SSC including approved solution, component, and application listings vetted through quality assurance process
  • There are incentives available from the card brands that may provide additional benefits

Other Observations:

  • Still limited in availability
  • Lengthy for solution providers to implement and complete a successful assessment
  • May pay a premium for solutions and/or transaction cost
  • Merchant still has responsibilities including for anti-skimming
If you want an analogy for P2PE, this is the DeathStar, a shiny new Battleship, or the BatMobile. All with a bumper to bumper warranty. But you still have to change the oil.

Non-Listed Encryption Security Assessment (NESA)

NESA is a tool created by the P2PE program to provide improved clarity and ease the PCI DSS assessment process for merchants, ISAs and QSAs when encountering solutions that are in the process of attaining P2PE validation but haven’t yet crossed the finish line. It is not promoted by the PCI SSC, nor is it a certification or approval. It is not P2PE-lite, P2PE-junior, or P2PE-anything-else. Its use is most certainly not mandated. However, in the absence of a fully validated P2PE solution, this is a good measuring stick to use.

Benefits:

  • Useful for those on the path to P2PE certification to show work in progress to their merchants and their QSAs
  • Provides QSAs and ISAs with recommendations from P2PE QSAs on the potential for compliance simplification in a standardized deliverable
  • High assurance of encryption capability and continued operation
  • Shows potential to reach P2PE and its benefits
  • It may help overcome the problem that P2PE developers have had negotiating access to enable SRED from some terminal manufacturers
  • Follows the P2PE architecture
  • Requires the same quality and attention to assessment detail as P2PE
  • Provides Acquirers with a standardized way to evaluate if they will take the risk for third-party compliance simplification
  • Clear merchant assessment process that may provide qualifying (i.e. eligible) merchants a small compliance footprint.

Other Observations:

  • Unknown availability, no listings or tracking of solutions
  • Still lengthy for solution providers to implement and assess
  • May pay a premium for solutions and/or transaction cost
  • Cannot use the P2PE Self-Assessment Questionnaire SAQ-P2PE.
  • Merchant still has responsibilities including for anti-skimming
  • Solutions don’t require SRED to be enabled.
  • Slightly more complicated for QSAs and ISAs to assess
The NESA template report summarizes the results of a non-compliant P2PE assessment. It’s divided into three main sections:
  • An informational and assessor acknowledgement section
  • A summary of how the solution deviates from P2PE
    • Deviations are currently only permitted in the actual device, application, and management of the solution. (i.e. domains 1-3)
    • All of the back end decryption environment and key injection (i.e. domains 5-6)must be fully compliant with P2PE
  • Recommendations of how the solution works with PCI DSS and where compliance can be simplified
If you want an analogy for NESA, this is the DeathStar under construction, a new Frigate during trials, or a cool armored car prototype. All without a warranty. And you still have to change the oil.

End-to-End Encryption (E2EE)

This is a catch all term for other approaches to providing encryption solutions. E2EE solutions are not standardized or necessarily consistent. Sometimes the term is totally misapplied or is misrepresented as P2PE. By nature, since these solutions do not provide automatic compliance simplification like P2PE, they require more due diligence and may be more limited than P2PE or NESA. Many of these solutions are an excellent alternative for merchants and are supported with documentation to give merchants, assessors, and implementers confidence that the solution is not simply good marketing, but that the solution provider has invested some due diligence in validating the solution, sometimes with significant rigor. The questions are how to know which solutions are good and how to safely achieve compliance footprints similar to P2PE. For purposes of this article, a good E2EE solution resides inside a PTS approved payment terminal, doesn’t release or leak cardholder or sensitive authentication data, doesn’t share or expose keys, and protects the encryption mechanism. A good solution minimizes the attack surface and wiggle room for an attacker.

Benefits:

  • Useful to merchants when P2PE and NESA solutions weren’t available or feasible.
  • Useful to acquirers with pre-existing encrypting solutions with a non-P2PE architecture (e.g. software encryption or a different back-end)
  • More beneficial if offered by an acquirer who controls and understands solution and has accepted risk
  • Potential to simplify merchant compliance

Other Observations:

  • More due diligence required on merchant side
  • Third party solution providers may be challenged to gain acquirer acceptance
  • More complicated for QSAs and ISAs to assess
  • Requires more understanding of the solution
  • What constitutes suitable validation steps
  • Solutions don’t require SRED to be enabled
  • Cannot use the P2PE Self-Assessment Questionnaire SAQ-P2PE.
  • Merchant still has responsibilities including for anti-skimming
  • Your mileage may vary
If you want an analogy for a good E2EE solution, this is a serviceable but slightly rusty Destroyer. No warranty. The oil still needs changing.

Legacy Integrated POS

For completeness, these systems are connected, and typically see cardholder and sensitive authentication data, and are fully in-scope for all applicable PCI DSS requirements. Unfortunately, that means most PCI DSS requirements will apply. They are tricky to secure and configure and they leave a lot of wiggle room for attack. The vast majority of payment breaches happen at the POS with ever increasing malware sophistication. Many merchants and service providers will reduce their PCI compliance scope by leveraging a PA-DSS compliant application. But it does not completely remove PCI scope, rather, it helps fast track many of the PCI requirements by transferring the responsibility to a third party. The analogy here is a leaky long boat with all hands bailing frantically and pirates on the horizon.

Assessment Aids for E2EE

When examining E2EE solutions there is a clear requirement to validate. Ultimately the merchant QSA/ISA will need to be comfortable with the solution and determine what validation steps they must perform, and which they can rely upon. They will also need to comfortable that the acquirer (or brands) support any simplification. Here we describe some of the aids and resources you may encounter.

PTS

PTS is the PCI program and standard that applies to the hardware payment terminal itself. It’s the bedrock on which P2PE, NESA, and good E2EE solutions are built. PTS approvals provide assurance that the device is resistant to tampering, supports good key management, and includes controls such as cryptographic key signing. PTS is modular and has functions that cover things like the display and various card reader components, Open Protocols (OP) (e.g. TCP/IP, WiFi, Bluetooth), and Secure Reading and Exchange of Data (SRED) which covers encryption including the use of hardware, firmware, configuration, and APIs used inside the terminal. PTS may also cover aspects of the payment application and what are referred to as firmware applications. PTS can be relied upon with minimal validation by confirming the device approval and functionality. It is worth nothing that confirming if a device is SRED is enabled vs capable is not straight forward. Due to this, most E2EE solutions will not have SRED enabled.

PA-DSS and Payment Terminals

Validation options for terminal payment applications can be a bit confusing because there are many of them. Payment applications in terminals need to be covered by some kind of PCI validation. It can be P2PE, PA-DSS, DSS, or even PTS (firmware). A couple of points are worth noting. First, PA-DSS is not required for P2PE applications as that is part of P2PE. And secondly, while PA-DSS is valuable to DSS it does not by itself provide any validation or guarantee that it can simplify compliance or reduce a merchant compliance footprint. That requires additional validation. PA-DSS can be relied upon for the device DSS. The PCI Implementation Guide (IG) must be followed by the merchant. It can prove invaluable in gaining understanding of the solution. The IG will help in determining what additional validation is needed to support compliance simplification.

Whitepapers

Many solution providers have whitepapers about their E2EE solution and make claims about the ability to simplify compliance. It is important to remember that these aren’t official attestations and cannot be relied upon by themselves. As there is no standard for these, the quality and completeness can vary significantly. However, good whitepapers can be invaluable in E2EE validation. The good ones will have characteristics such as:
  • Detailed explanation of the solution and how it operates
  • Involve actual testing of the solution and explanations of how it was tested, not just that the solution can encrypt sometimes
  • Explain how all the key objectives were met
  • Provide sufficient information that the merchant assessor can link solutions in the field to the whitepaper
  • Allow the merchant assessor to determine an appropriate level of validation
  • References including Solution provider documents and PCI guidance

Acquirer Acceptance

Acquirers are ultimately responsible for monitoring and accepting merchant risk. They can accept compliance simplification for E2EE solutions. They may or may not accept the risk of a breach.

Validation

A merchant and assessor equipped with good validation aids should be able to determine an appropriate series of validation steps. They should consider all available aids, such as:
  • Evidence of PTS
  • Evidence of Solution provider DSS
  • Evidence of PA-DSS
  • Formal guidance such as P2PE Implementation Manuals (PIMs) and PA-DSS PCI Implementation Guides (IGs)
  • Acquirer Acceptance
  • Whitepapers and solution provider documentation
  • Acquirer support to gain comfort and with some validation efforts where necessary

Reporting

SAQ merchants can’t use SAQ-P2PE. Instead they will need to use the most appropriate form (e.g. SAQ B-IP, SAQ-D, etc.) that they are eligible for and justify any non-applicability.

Due Diligence and Red Flags

With any encryption solution, due diligence is important. It’s easy enough for even an honest and diligent salesperson to get it wrong. You will need formal documentation. And you’ll need to confirm if your Acquirer supports you. This is clearest with P2PE. Over the years we’ve heard a lot of things that raised some obvious red flags, here are a few paraphrased examples (and our reaction):
  • Our application is P2PE certified (But is the Solution? So, back to E2EE then)
  • We’re using the same solution as _______ (But their gateway is in Europe, so how is yours certified?)
  • Our third party E2EE gateway and application supports scope-reduction (But does the merchant’s acquirer accept that? Does your gateway take the risk?)
  • We have a P2PE application (And? Is it certified? And the solution?)
  • Our PC based POS application provides E2EE functionality and facilitates scope reduction. (Do you even understand the first thing about PCI scope?)
  • Our E2EE solution encrypts from the terminal to the POS and our middleware re-encrypts for the bank (How does end-to-middle-to-end qualify as end-to-end?
  • In case of problems the solution can be reset to legacy by the POS? (You do know that security impacting systems are in scope too. Don’t you?)

Breaches

No one wants a breach. And no-one wants to have a breach because they oversimplified their compliance. So what can go wrong in these scenarios?
  • In any of these, even P2PE, there could be overlooked merchant scope. A reservoir of old legacy systems or some ad-hoc flow developed by a customer service focused employee. Or shadow IT. This is why documented validated flows and accurate inventories are critical.
  • Also with any of these things, there could be compliance lapses. Usually things like this happen in processes rather than technology.
  • But what could happen in non-P2PE
    • Probably one of the most likely scenarios would be cases where the terminals are deployed before encryption is enabled and they have the capability to operate in a legacy mode.
    • Failure to use SRED is possible but less likely as many terminals this is essentially a configuration option and the core encryption for SRED and non-SRED are shared.
    • Changes in host generated receipts could result in cardholder data leakage.
    • Poorly controlled loyalty card read-back.
    • The ability to make unauthorized key changes.

Learn More:

If you are at a critical point in your technology or solution design decision process and would like a second opinion, give Control Gap a call, we are happy to help. [post_title] => Understanding P2PE, NESA, E2EE, and PCI Compliance [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => understanding-encryption-and-pci-compliance [to_ping] => [pinged] => https://controlgap.com/blog/pci-nesa-2/ https://controlgap.com/blog/pci-compliance-footprints/ [post_modified] => 2017-07-06 15:33:29 [post_modified_gmt] => 2017-07-06 15:33:29 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1497 [menu_order] => 73 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [comment_count] => 0 [current_comment] => -1 [found_posts] => 45 [max_num_pages] => 15 [max_num_comment_pages] => 0 [is_single] => [is_preview] => [is_page] => [is_archive] => 1 [is_date] => [is_year] => [is_month] => [is_day] => [is_time] => [is_author] => [is_category] => 1 [is_tag] => [is_tax] => [is_search] => [is_feed] => [is_comment_feed] => [is_trackback] => [is_home] => [is_404] => [is_embed] => [is_paged] => 1 [is_admin] => [is_attachment] => [is_singular] => [is_robots] => [is_posts_page] => [is_post_type_archive] => [query_vars_hash:WP_Query:private] => 5dd470a23edaaa8b28d3af543c8bea0d [query_vars_changed:WP_Query:private] => 1 [thumbnails_cached] => [stopwords:WP_Query:private] => [compat_fields:WP_Query:private] => Array ( [0] => query_vars_hash [1] => query_vars_changed ) [compat_methods:WP_Query:private] => Array ( [0] => init_query_flags [1] => parse_tax_query ) )
WP_Query Object ( [query] => Array ( [post_type] => post [post_status] => publish [cat] => 14, 134, 1 [orderby] => date [order] => desc [posts_per_page] => 3 [paged] => 4 [ignore_sticky_posts] => 1 ) [query_vars] => Array ( [post_type] => post [post_status] => publish [cat] => 14 [orderby] => date [order] => DESC [posts_per_page] => 3 [paged] => 4 [ignore_sticky_posts] => 1 [error] => [m] => [p] => 0 [post_parent] => [subpost] => [subpost_id] => [attachment] => [attachment_id] => 0 [name] => [static] => [pagename] => [page_id] => 0 [second] => [minute] => [hour] => [day] => 0 [monthnum] => 0 [year] => 0 [w] => 0 [category_name] => charity [tag] => [tag_id] => [author] => [author_name] => [feed] => [tb] => [meta_key] => [meta_value] => [preview] => [s] => [sentence] => [title] => [fields] => [menu_order] => [embed] => [category__in] => Array ( ) [category__not_in] => Array ( ) [category__and] => Array ( ) [post__in] => Array ( ) [post__not_in] => Array ( ) [post_name__in] => Array ( ) [tag__in] => Array ( ) [tag__not_in] => Array ( ) [tag__and] => Array ( ) [tag_slug__in] => Array ( ) [tag_slug__and] => Array ( ) [post_parent__in] => Array ( ) [post_parent__not_in] => Array ( ) [author__in] => Array ( ) [author__not_in] => Array ( ) [update_post_term_cache] => 1 [suppress_filters] => [cache_results] => [lazy_load_term_meta] => 1 [update_post_meta_cache] => 1 [nopaging] => [comments_per_page] => 50 [no_found_rows] => ) [tax_query] => WP_Tax_Query Object ( [queries] => Array ( [0] => Array ( [taxonomy] => category [terms] => Array ( [0] => 14 [1] => 134 [2] => 1 ) [field] => term_id [operator] => IN [include_children] => 1 ) ) [relation] => AND [table_aliases:protected] => Array ( [0] => wpcm_term_relationships ) [queried_terms] => Array ( [category] => Array ( [terms] => Array ( [0] => 14 [1] => 134 [2] => 1 ) [field] => term_id ) ) [primary_table] => wpcm_posts [primary_id_column] => ID ) [meta_query] => WP_Meta_Query Object ( [queries] => Array ( ) [relation] => [meta_table] => [meta_id_column] => [primary_table] => [primary_id_column] => [table_aliases:protected] => Array ( ) [clauses:protected] => Array ( ) [has_or_relation:protected] => ) [date_query] => [request] => SELECT SQL_CALC_FOUND_ROWS wpcm_posts.ID FROM wpcm_posts LEFT JOIN wpcm_term_relationships ON (wpcm_posts.ID = wpcm_term_relationships.object_id) WHERE 1=1 AND ( wpcm_term_relationships.term_taxonomy_id IN (1,14,134) ) AND wpcm_posts.post_type = 'post' AND ((wpcm_posts.post_status = 'publish')) GROUP BY wpcm_posts.ID ORDER BY wpcm_posts.menu_order, wpcm_posts.post_date DESC LIMIT 9, 3 [posts] => Array ( [0] => WP_Post Object ( [ID] => 1497 [post_author] => 2 [post_date] => 2017-06-27 17:13:21 [post_date_gmt] => 2017-06-27 17:13:21 [post_content] => Compliance simplification, what most people call “scope reduction”, can have huge benefits in terms of saving time, effort, headaches, and money. Merchants desire ways to simplify their PCI compliance as do the card brands, acquirers, and processors. When the PCI Council announced P2PE in 2011, there was an immediate and huge demand for approved P2PE solutions. It wasn’t that merchants wanted P2PE, rather they wanted the massive compliance simplification and risk reduction that P2PE promised to provide. QSAs and ISAs hoped for clear assessment requirements to make their merchant PCI DSS assessments simpler and less ambiguous. Late in 2016, the PCI Council announced NESA (Non-listed Encryption Assessments) and there was again an immediate and huge demand for this. The problem is that the demand is based on perception not understanding. Let’s be clear there is only one PCI approved and promoted class of solutions that provides the simplicity and clarity to simplify compliance through encryption. That is P2PE, but that isn’t the whole story. This article will look at the differences between these three types of solutions and how they can be handled under PCI. In many ways, a P2PE solution can feel like the “holy grail” of PCI, reducing the scope to only the device.  In reality, P2PE solutions reduce the applicable requirements on connected-to devices to nothing. Before we get started, the PCI Council’s guidance is clear that it is possible to simplify compliance in a justifiable and defensible fashion and this applies to several different types of encryption solutions.  However, the guidance is not well understood, as it matters how you go about it. For non-P2PE, the Acquirer or Card Brands must agree to any compliance simplification. In practice, this is almost always the Acquirer's call.

Merchants and Encryption Solutions

When merchants invest in encryption solutions, there are a number of factors that need consideration, such as availability of P2PE, cost of the solution, projected end of life, support, local or regional factors, functionality, existing contracts and more. The challenge is that the entire landscape for encryption solutions is changing rapidly. Full transition to P2PE will take time. Merchants want to ensure they are compliant with PCI DSS, but need to balance the cost of investing in technology solutions, with maintaining their day-to-day business, ensuring that there is a positive return on investment (ROI). Acquirers and Processors understand the demand of the market and their merchants as they strive to provide viable options for their customers. They are all acutely aware of market demand and risks. As merchants evaluate P2PE, Acquirers and processors are too preparing to evolve their offerings because of demand and because it is the right thing to do. Many are reviewing their own investment requirements to support P2PE, while others are actively pursuing P2PE solutions to be able to support the market demand.

The Long Road to P2PE

Most people don’t appreciate how big a job it is to build a P2PE solution. It isn’t just about the initial and ongoing investment, there can be significant challenges. P2PE v1 lacked flexibility. P2PE v2 improved on that significantly. The situation is evolving and will continue to do so. While not only the P2PE standard evolves, the market itself is transforming producing a mixture of solutions. All stakeholders in this space need to understand that and learn how to deal with these changes. To illustrate this, the following charts show the current and historical state of P2PE approved solutions including the gaps between changes to the P2PE standard and emergence of the first solutions. Clearly, launching a P2PE solution is easily a one to two-year project. Merchants and assessors want to have the best solution possible, but let us also be clear, leveraging good encryption technology today is better than waiting to leverage the best encryption technology two or three years from now.    

Point-to-Point Encryption (P2PE)

P2PE is an official program of the PCI Standards Council and it is the only class of solution promoted by the council that permits automatic compliance simplification (aka scope reduction). However, the use of P2PE solutions is not mandatory.

Benefits:

  • Designed to address complex scenarios like third party processors and decryption environments, multiple acquirers, multiple co-resident applications, loyalty and other non-financial cards, supply chain attacks, and more
  • Clear merchant assessment process that provides qualifying (i.e. eligible) merchants a small compliance footprint. This includes having a dedicated Self-Assessment Questionnaire SAQ-P2PE. It is easy for QSAs and ISAs to assess
  • Extremely tightly locked down with little wiggle room for an attacker to exploit
  • Places more of the compliance burden on the solution, application, and component providers
  • Very high assurance of encryption capability and continued operation
  • Follows the P2PE architecture
  • Well supported by PCI SSC including approved solution, component, and application listings vetted through quality assurance process
  • There are incentives available from the card brands that may provide additional benefits

Other Observations:

  • Still limited in availability
  • Lengthy for solution providers to implement and complete a successful assessment
  • May pay a premium for solutions and/or transaction cost
  • Merchant still has responsibilities including for anti-skimming
If you want an analogy for P2PE, this is the DeathStar, a shiny new Battleship, or the BatMobile. All with a bumper to bumper warranty. But you still have to change the oil.

Non-Listed Encryption Security Assessment (NESA)

NESA is a tool created by the P2PE program to provide improved clarity and ease the PCI DSS assessment process for merchants, ISAs and QSAs when encountering solutions that are in the process of attaining P2PE validation but haven’t yet crossed the finish line. It is not promoted by the PCI SSC, nor is it a certification or approval. It is not P2PE-lite, P2PE-junior, or P2PE-anything-else. Its use is most certainly not mandated. However, in the absence of a fully validated P2PE solution, this is a good measuring stick to use.

Benefits:

  • Useful for those on the path to P2PE certification to show work in progress to their merchants and their QSAs
  • Provides QSAs and ISAs with recommendations from P2PE QSAs on the potential for compliance simplification in a standardized deliverable
  • High assurance of encryption capability and continued operation
  • Shows potential to reach P2PE and its benefits
  • It may help overcome the problem that P2PE developers have had negotiating access to enable SRED from some terminal manufacturers
  • Follows the P2PE architecture
  • Requires the same quality and attention to assessment detail as P2PE
  • Provides Acquirers with a standardized way to evaluate if they will take the risk for third-party compliance simplification
  • Clear merchant assessment process that may provide qualifying (i.e. eligible) merchants a small compliance footprint.

Other Observations:

  • Unknown availability, no listings or tracking of solutions
  • Still lengthy for solution providers to implement and assess
  • May pay a premium for solutions and/or transaction cost
  • Cannot use the P2PE Self-Assessment Questionnaire SAQ-P2PE.
  • Merchant still has responsibilities including for anti-skimming
  • Solutions don’t require SRED to be enabled.
  • Slightly more complicated for QSAs and ISAs to assess
The NESA template report summarizes the results of a non-compliant P2PE assessment. It’s divided into three main sections:
  • An informational and assessor acknowledgement section
  • A summary of how the solution deviates from P2PE
    • Deviations are currently only permitted in the actual device, application, and management of the solution. (i.e. domains 1-3)
    • All of the back end decryption environment and key injection (i.e. domains 5-6)must be fully compliant with P2PE
  • Recommendations of how the solution works with PCI DSS and where compliance can be simplified
If you want an analogy for NESA, this is the DeathStar under construction, a new Frigate during trials, or a cool armored car prototype. All without a warranty. And you still have to change the oil.

End-to-End Encryption (E2EE)

This is a catch all term for other approaches to providing encryption solutions. E2EE solutions are not standardized or necessarily consistent. Sometimes the term is totally misapplied or is misrepresented as P2PE. By nature, since these solutions do not provide automatic compliance simplification like P2PE, they require more due diligence and may be more limited than P2PE or NESA. Many of these solutions are an excellent alternative for merchants and are supported with documentation to give merchants, assessors, and implementers confidence that the solution is not simply good marketing, but that the solution provider has invested some due diligence in validating the solution, sometimes with significant rigor. The questions are how to know which solutions are good and how to safely achieve compliance footprints similar to P2PE. For purposes of this article, a good E2EE solution resides inside a PTS approved payment terminal, doesn’t release or leak cardholder or sensitive authentication data, doesn’t share or expose keys, and protects the encryption mechanism. A good solution minimizes the attack surface and wiggle room for an attacker.

Benefits:

  • Useful to merchants when P2PE and NESA solutions weren’t available or feasible.
  • Useful to acquirers with pre-existing encrypting solutions with a non-P2PE architecture (e.g. software encryption or a different back-end)
  • More beneficial if offered by an acquirer who controls and understands solution and has accepted risk
  • Potential to simplify merchant compliance

Other Observations:

  • More due diligence required on merchant side
  • Third party solution providers may be challenged to gain acquirer acceptance
  • More complicated for QSAs and ISAs to assess
  • Requires more understanding of the solution
  • What constitutes suitable validation steps
  • Solutions don’t require SRED to be enabled
  • Cannot use the P2PE Self-Assessment Questionnaire SAQ-P2PE.
  • Merchant still has responsibilities including for anti-skimming
  • Your mileage may vary
If you want an analogy for a good E2EE solution, this is a serviceable but slightly rusty Destroyer. No warranty. The oil still needs changing.

Legacy Integrated POS

For completeness, these systems are connected, and typically see cardholder and sensitive authentication data, and are fully in-scope for all applicable PCI DSS requirements. Unfortunately, that means most PCI DSS requirements will apply. They are tricky to secure and configure and they leave a lot of wiggle room for attack. The vast majority of payment breaches happen at the POS with ever increasing malware sophistication. Many merchants and service providers will reduce their PCI compliance scope by leveraging a PA-DSS compliant application. But it does not completely remove PCI scope, rather, it helps fast track many of the PCI requirements by transferring the responsibility to a third party. The analogy here is a leaky long boat with all hands bailing frantically and pirates on the horizon.

Assessment Aids for E2EE

When examining E2EE solutions there is a clear requirement to validate. Ultimately the merchant QSA/ISA will need to be comfortable with the solution and determine what validation steps they must perform, and which they can rely upon. They will also need to comfortable that the acquirer (or brands) support any simplification. Here we describe some of the aids and resources you may encounter.

PTS

PTS is the PCI program and standard that applies to the hardware payment terminal itself. It’s the bedrock on which P2PE, NESA, and good E2EE solutions are built. PTS approvals provide assurance that the device is resistant to tampering, supports good key management, and includes controls such as cryptographic key signing. PTS is modular and has functions that cover things like the display and various card reader components, Open Protocols (OP) (e.g. TCP/IP, WiFi, Bluetooth), and Secure Reading and Exchange of Data (SRED) which covers encryption including the use of hardware, firmware, configuration, and APIs used inside the terminal. PTS may also cover aspects of the payment application and what are referred to as firmware applications. PTS can be relied upon with minimal validation by confirming the device approval and functionality. It is worth nothing that confirming if a device is SRED is enabled vs capable is not straight forward. Due to this, most E2EE solutions will not have SRED enabled.

PA-DSS and Payment Terminals

Validation options for terminal payment applications can be a bit confusing because there are many of them. Payment applications in terminals need to be covered by some kind of PCI validation. It can be P2PE, PA-DSS, DSS, or even PTS (firmware). A couple of points are worth noting. First, PA-DSS is not required for P2PE applications as that is part of P2PE. And secondly, while PA-DSS is valuable to DSS it does not by itself provide any validation or guarantee that it can simplify compliance or reduce a merchant compliance footprint. That requires additional validation. PA-DSS can be relied upon for the device DSS. The PCI Implementation Guide (IG) must be followed by the merchant. It can prove invaluable in gaining understanding of the solution. The IG will help in determining what additional validation is needed to support compliance simplification.

Whitepapers

Many solution providers have whitepapers about their E2EE solution and make claims about the ability to simplify compliance. It is important to remember that these aren’t official attestations and cannot be relied upon by themselves. As there is no standard for these, the quality and completeness can vary significantly. However, good whitepapers can be invaluable in E2EE validation. The good ones will have characteristics such as:
  • Detailed explanation of the solution and how it operates
  • Involve actual testing of the solution and explanations of how it was tested, not just that the solution can encrypt sometimes
  • Explain how all the key objectives were met
  • Provide sufficient information that the merchant assessor can link solutions in the field to the whitepaper
  • Allow the merchant assessor to determine an appropriate level of validation
  • References including Solution provider documents and PCI guidance

Acquirer Acceptance

Acquirers are ultimately responsible for monitoring and accepting merchant risk. They can accept compliance simplification for E2EE solutions. They may or may not accept the risk of a breach.

Validation

A merchant and assessor equipped with good validation aids should be able to determine an appropriate series of validation steps. They should consider all available aids, such as:
  • Evidence of PTS
  • Evidence of Solution provider DSS
  • Evidence of PA-DSS
  • Formal guidance such as P2PE Implementation Manuals (PIMs) and PA-DSS PCI Implementation Guides (IGs)
  • Acquirer Acceptance
  • Whitepapers and solution provider documentation
  • Acquirer support to gain comfort and with some validation efforts where necessary

Reporting

SAQ merchants can’t use SAQ-P2PE. Instead they will need to use the most appropriate form (e.g. SAQ B-IP, SAQ-D, etc.) that they are eligible for and justify any non-applicability.

Due Diligence and Red Flags

With any encryption solution, due diligence is important. It’s easy enough for even an honest and diligent salesperson to get it wrong. You will need formal documentation. And you’ll need to confirm if your Acquirer supports you. This is clearest with P2PE. Over the years we’ve heard a lot of things that raised some obvious red flags, here are a few paraphrased examples (and our reaction):
  • Our application is P2PE certified (But is the Solution? So, back to E2EE then)
  • We’re using the same solution as _______ (But their gateway is in Europe, so how is yours certified?)
  • Our third party E2EE gateway and application supports scope-reduction (But does the merchant’s acquirer accept that? Does your gateway take the risk?)
  • We have a P2PE application (And? Is it certified? And the solution?)
  • Our PC based POS application provides E2EE functionality and facilitates scope reduction. (Do you even understand the first thing about PCI scope?)
  • Our E2EE solution encrypts from the terminal to the POS and our middleware re-encrypts for the bank (How does end-to-middle-to-end qualify as end-to-end?
  • In case of problems the solution can be reset to legacy by the POS? (You do know that security impacting systems are in scope too. Don’t you?)

Breaches

No one wants a breach. And no-one wants to have a breach because they oversimplified their compliance. So what can go wrong in these scenarios?
  • In any of these, even P2PE, there could be overlooked merchant scope. A reservoir of old legacy systems or some ad-hoc flow developed by a customer service focused employee. Or shadow IT. This is why documented validated flows and accurate inventories are critical.
  • Also with any of these things, there could be compliance lapses. Usually things like this happen in processes rather than technology.
  • But what could happen in non-P2PE
    • Probably one of the most likely scenarios would be cases where the terminals are deployed before encryption is enabled and they have the capability to operate in a legacy mode.
    • Failure to use SRED is possible but less likely as many terminals this is essentially a configuration option and the core encryption for SRED and non-SRED are shared.
    • Changes in host generated receipts could result in cardholder data leakage.
    • Poorly controlled loyalty card read-back.
    • The ability to make unauthorized key changes.

Learn More:

If you are at a critical point in your technology or solution design decision process and would like a second opinion, give Control Gap a call, we are happy to help. [post_title] => Understanding P2PE, NESA, E2EE, and PCI Compliance [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => understanding-encryption-and-pci-compliance [to_ping] => [pinged] => https://controlgap.com/blog/pci-nesa-2/ https://controlgap.com/blog/pci-compliance-footprints/ [post_modified] => 2017-07-06 15:33:29 [post_modified_gmt] => 2017-07-06 15:33:29 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1497 [menu_order] => 73 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [1] => WP_Post Object ( [ID] => 1469 [post_author] => 2 [post_date] => 2017-05-15 19:58:47 [post_date_gmt] => 2017-05-15 19:58:47 [post_content] => On May 1st a critical new and possibly unprecedented vulnerability was announced.  The flaw in Intel's Active Management Technology (AMT) firmware will be difficult to deal with, in part, because most organizations are not setup to rapidly deploy firmware updates across large numbers of systems.  The feature is supported by almost a decades worth of Intel chip sets, firmware, and OEM customization. We expect the vulnerability will have significant impact on organization's security and compliance programs. It is imperative for organizations to ensure they carefully manage the risk from AMT. We've been closely monitoring developments with this and are including reference links to articles and resources.  We highly recommend a number of Must Reads (below) that include Intel's guidance and SSH's tracking page that contains a wealth of information relating to this.

Understanding this Vulnerability

Systems that are most at risk have a) vulnerable chip set and firmware; and b) the AMT functionality provisioned on the hardware. Intel's diagnostics answers part a). There are a number of diagnostic tools available to assess part b) including commercial vulnerability scanners such as Nessus, Rapid 7, and Qualys.  Even Nmap can identify systems that may be at risk. We were curious about the vulnerability and set out to demonstrate it so that we could get the feel of it.  We selected a laptop with a vulnerable chip set that had not been provisioned for AMT.  Next we set out to provision it for testing. Once enabled, we were able to easily reproduce the exploit and observe it in operation. As expected, host based firewalls provided no protection and we were able to remote into running systems.  We were also able to remote into systems that had been shutdown. This last capability is both powerful and disturbing. Even though this functionality is documented, on a gut level it is still somewhat unexpected. Because the vulnerability lives in the firmware and chip set, organizations must assess the risk more broadly than they are used to with most software bugs.  Additionally because patches will need to come from the OEMs, organizations will have a more complex task of coordinating, prioritizing, and implementing updates which may not be available for weeks and may not be available for all systems. Many organizations will need to consider interim mitigation measures. Affected systems could include VM Host systems, non-windows systems, and even some appliances in addition to Windows servers, workstations, and laptops. Organizations that under estimate these characteristics could be in for some unpleasant surprises.

What to do Now

Organizations need to immediately asses their exposure and risk and then follow-up with a prioritized plan.
  • Undertake a focused discovery exercise to identify all of your vulnerable and potentially vulnerable systems. Don't exclude systems based on assumptions.
  • Analyze and prioritize the results based on risk factors such as visibility (internal/external), system sensitivity, etc. Perform this exercise for both the vulnerable and potentially vulnerable groups.
  • Develop specific remediation/mitigation strategies for each group and risk factor. Roll these out on a priority basis. Ensure you loop back to further investigate systems that show signs of potential vulnerability.
  • Consider stop-gap measures including specific IDS monitoring and additional network firewall level firewall rules.
  • Monitor and confirm remediation.
  • Keep records of these activities.

Don't Worry About the Future

We'd be surprised if this is the only security bug in the Intel Management Engine. And we're certain that this will be the focus of much new security research. Going forward, organizations should
  • Make sure AMT and ME are on their vulnerability management radar
  • Strongly consider turning AMT off and putting in place processes to ensure it doesn't creep back in
  • If AMT is needed, implement best practices to secure it and consider other mitigation to limit risk

Will Systems Need to be Replaced?

While this is possible, for most organizations we wouldn't expect this drastic an action will be required for most of their systems. The specifics will depend on many factors including equipment age, OEM, exposure/risk of individual systems, and mitigation applied. You should expect that your mileage may vary.

What about PCI Compliance?

Do NOT try and explain AMT away by arguing that PCI doesn't apply to server hardware just because it it doesn't explicitly call it out. Nor should you justify lack of action by assumptions. These approaches will not hold up to scrutiny. If AMT leads to a breach, the forensic investigation will conclude the organization was not compliant. Do have an active risk management plan active and in play supported by evidence (e.g. inventories/discoveries, analysis, decisions, recommendations, progress, etc.).  The plan needs to be risk based and prioritized. If there are constraints on patch availability or patching logistics, implement other mitigation. Preventative controls are great if they're available, if not, ensure you can detect and react.  And lastly, if you need this functionality going forward, you will need to figure out how to ensure it's compliant with applicable requirements (e.g. changing default credentials). This is the best response.

References

Must Reads

Intel Resources

Technical Articles

Online Articles, Explanations, and How-To's

Unrelated / Thanks

[post_title] => PCI Compliance and the Intel AMT Vulnerability [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => pci-compliance-intel-amt-vulnerability [to_ping] => [pinged] => https://mattermedia.com/blog/disabling-intel-amt/ [post_modified] => 2017-05-15 20:01:47 [post_modified_gmt] => 2017-05-15 20:01:47 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1469 [menu_order] => 80 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [2] => WP_Post Object ( [ID] => 1466 [post_author] => 2 [post_date] => 2017-05-10 17:33:27 [post_date_gmt] => 2017-05-10 17:33:27 [post_content] => Last month we wrote this article about issues arising from the addition of new BIN ranges and the lack of clear guidance specifically with 16-digit PAN that have 8-digit BINs. Today, the PCI Council just updated FAQ#1091 "What are acceptable formats for truncation of primary account numbers?" to specifically address the issue of how to truncate 16-digit PAN with 8-digit BIN. The short answer is that PCI's first six and last 4 truncation rule applies (see below) .  But, and there is a but here, not all of the issues we identified will go away. This clarification on acceptable truncation is very welcome as it provides stability to the payments ecosystem.  However, organizations will still need to understand the impact of these changes on their payment systems. Guidance from the brands is also clear that relying on truncation alone will not be sufficient to protect the data if more digits are kept.
  • For organizations that do not need to keep the full BIN, there should be little if any impact and should be able to continue to use 6&4 truncation. They should however validate this to ensure there are no unpleasant surprises. We expect the majority of merchants will be in this group.
  • Some organizations will need to keep the full BIN.  They will need to take additional steps (e.g. encryption, tokenization, etc.) to protect that information while stored. In many cases this could introduce additional data elements that impact PCI DSS scope or the number of applicable requirements within their scope. Organizations need to carefully evaluate the impact and implement changes to ensure they stay compliant.  These are changes that, if implemented without considering compliance,  could require substantial remediation.
Lastly, we urge caution if you are using 6&4 truncation when these new PAN/BIN ranges go live. Specifically, we recommend that you monitor the risk of correlating truncated data to PAN considering both internal and external factors. Why? Because, we believe there may be additional risk here depending on how the Card Brands and Issuers allocate these BIN ranges.  And while these are primarily risk questions for those organizations, you should also be aware of the risk. If you can live with more aggressively truncated PAN that will help to address this risk. For example, consider the following approach which assumes an attacker can get 6&4 truncated PAN from your organization and a separate list of 8-digit BINs that are allocated and/or in use.  The correlation risk will depend on how many of these BIN ranges match in the first six digits. If the BIN ranges are sparsely allocated there will be fewer 8-digit BINs with the same first 6-digits and correlation will be much easier than if the 6-digit ranges are densely allocated. Using fictitious examples from the previous article to bound the risk:
PAN Rule Truncation Strength Compliance
9234567890123455 6-4/16 923456xxxxxx3455 1 : 100,000 PCI 3.2
9234567890123455 8-4/16 92345678xxxx3455 1 : 1,000 Not PCI 3.2 compliant
As you can see, depending on how sparsely the 8-digit BINs beginning 923456 are allocated, the strength will vary considerably. It is also clear, that anything less than full allocation reduces the strength.
Number of BINs in 923456xx Strength
100 1 : 100,000
50 1 : 50,000
25 1 : 25,000
10 1 : 10,000
1 1 : 1,000
For a more detailed discussion of the issues please read our original article. _______________________________________________________________ Becoming PCI Compliant can be difficult, so why not let Control Gap guide you. We are the largest dedicated PCI compliance company in Canada. Contact us today and learn more about how we can help you: Get PCI Compliant. Stay PCI Compliant. [post_title] => 8-digit BIN Issues and Risks Remain after PCI Truncation Rules Clarified [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => pci-truncation-rules-clarified [to_ping] => [pinged] => https://controlgap.com/blog/new-bin-ranges-and-pci-truncation/ [post_modified] => 2018-05-02 02:48:05 [post_modified_gmt] => 2018-05-02 02:48:05 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1466 [menu_order] => 82 [post_type] => post [post_mime_type] => [comment_count] => 1 [filter] => raw ) ) [post_count] => 3 [current_post] => -1 [in_the_loop] => [post] => WP_Post Object ( [ID] => 1497 [post_author] => 2 [post_date] => 2017-06-27 17:13:21 [post_date_gmt] => 2017-06-27 17:13:21 [post_content] => Compliance simplification, what most people call “scope reduction”, can have huge benefits in terms of saving time, effort, headaches, and money. Merchants desire ways to simplify their PCI compliance as do the card brands, acquirers, and processors. When the PCI Council announced P2PE in 2011, there was an immediate and huge demand for approved P2PE solutions. It wasn’t that merchants wanted P2PE, rather they wanted the massive compliance simplification and risk reduction that P2PE promised to provide. QSAs and ISAs hoped for clear assessment requirements to make their merchant PCI DSS assessments simpler and less ambiguous. Late in 2016, the PCI Council announced NESA (Non-listed Encryption Assessments) and there was again an immediate and huge demand for this. The problem is that the demand is based on perception not understanding. Let’s be clear there is only one PCI approved and promoted class of solutions that provides the simplicity and clarity to simplify compliance through encryption. That is P2PE, but that isn’t the whole story. This article will look at the differences between these three types of solutions and how they can be handled under PCI. In many ways, a P2PE solution can feel like the “holy grail” of PCI, reducing the scope to only the device.  In reality, P2PE solutions reduce the applicable requirements on connected-to devices to nothing. Before we get started, the PCI Council’s guidance is clear that it is possible to simplify compliance in a justifiable and defensible fashion and this applies to several different types of encryption solutions.  However, the guidance is not well understood, as it matters how you go about it. For non-P2PE, the Acquirer or Card Brands must agree to any compliance simplification. In practice, this is almost always the Acquirer's call.

Merchants and Encryption Solutions

When merchants invest in encryption solutions, there are a number of factors that need consideration, such as availability of P2PE, cost of the solution, projected end of life, support, local or regional factors, functionality, existing contracts and more. The challenge is that the entire landscape for encryption solutions is changing rapidly. Full transition to P2PE will take time. Merchants want to ensure they are compliant with PCI DSS, but need to balance the cost of investing in technology solutions, with maintaining their day-to-day business, ensuring that there is a positive return on investment (ROI). Acquirers and Processors understand the demand of the market and their merchants as they strive to provide viable options for their customers. They are all acutely aware of market demand and risks. As merchants evaluate P2PE, Acquirers and processors are too preparing to evolve their offerings because of demand and because it is the right thing to do. Many are reviewing their own investment requirements to support P2PE, while others are actively pursuing P2PE solutions to be able to support the market demand.

The Long Road to P2PE

Most people don’t appreciate how big a job it is to build a P2PE solution. It isn’t just about the initial and ongoing investment, there can be significant challenges. P2PE v1 lacked flexibility. P2PE v2 improved on that significantly. The situation is evolving and will continue to do so. While not only the P2PE standard evolves, the market itself is transforming producing a mixture of solutions. All stakeholders in this space need to understand that and learn how to deal with these changes. To illustrate this, the following charts show the current and historical state of P2PE approved solutions including the gaps between changes to the P2PE standard and emergence of the first solutions. Clearly, launching a P2PE solution is easily a one to two-year project. Merchants and assessors want to have the best solution possible, but let us also be clear, leveraging good encryption technology today is better than waiting to leverage the best encryption technology two or three years from now.    

Point-to-Point Encryption (P2PE)

P2PE is an official program of the PCI Standards Council and it is the only class of solution promoted by the council that permits automatic compliance simplification (aka scope reduction). However, the use of P2PE solutions is not mandatory.

Benefits:

  • Designed to address complex scenarios like third party processors and decryption environments, multiple acquirers, multiple co-resident applications, loyalty and other non-financial cards, supply chain attacks, and more
  • Clear merchant assessment process that provides qualifying (i.e. eligible) merchants a small compliance footprint. This includes having a dedicated Self-Assessment Questionnaire SAQ-P2PE. It is easy for QSAs and ISAs to assess
  • Extremely tightly locked down with little wiggle room for an attacker to exploit
  • Places more of the compliance burden on the solution, application, and component providers
  • Very high assurance of encryption capability and continued operation
  • Follows the P2PE architecture
  • Well supported by PCI SSC including approved solution, component, and application listings vetted through quality assurance process
  • There are incentives available from the card brands that may provide additional benefits

Other Observations:

  • Still limited in availability
  • Lengthy for solution providers to implement and complete a successful assessment
  • May pay a premium for solutions and/or transaction cost
  • Merchant still has responsibilities including for anti-skimming
If you want an analogy for P2PE, this is the DeathStar, a shiny new Battleship, or the BatMobile. All with a bumper to bumper warranty. But you still have to change the oil.

Non-Listed Encryption Security Assessment (NESA)

NESA is a tool created by the P2PE program to provide improved clarity and ease the PCI DSS assessment process for merchants, ISAs and QSAs when encountering solutions that are in the process of attaining P2PE validation but haven’t yet crossed the finish line. It is not promoted by the PCI SSC, nor is it a certification or approval. It is not P2PE-lite, P2PE-junior, or P2PE-anything-else. Its use is most certainly not mandated. However, in the absence of a fully validated P2PE solution, this is a good measuring stick to use.

Benefits:

  • Useful for those on the path to P2PE certification to show work in progress to their merchants and their QSAs
  • Provides QSAs and ISAs with recommendations from P2PE QSAs on the potential for compliance simplification in a standardized deliverable
  • High assurance of encryption capability and continued operation
  • Shows potential to reach P2PE and its benefits
  • It may help overcome the problem that P2PE developers have had negotiating access to enable SRED from some terminal manufacturers
  • Follows the P2PE architecture
  • Requires the same quality and attention to assessment detail as P2PE
  • Provides Acquirers with a standardized way to evaluate if they will take the risk for third-party compliance simplification
  • Clear merchant assessment process that may provide qualifying (i.e. eligible) merchants a small compliance footprint.

Other Observations:

  • Unknown availability, no listings or tracking of solutions
  • Still lengthy for solution providers to implement and assess
  • May pay a premium for solutions and/or transaction cost
  • Cannot use the P2PE Self-Assessment Questionnaire SAQ-P2PE.
  • Merchant still has responsibilities including for anti-skimming
  • Solutions don’t require SRED to be enabled.
  • Slightly more complicated for QSAs and ISAs to assess
The NESA template report summarizes the results of a non-compliant P2PE assessment. It’s divided into three main sections:
  • An informational and assessor acknowledgement section
  • A summary of how the solution deviates from P2PE
    • Deviations are currently only permitted in the actual device, application, and management of the solution. (i.e. domains 1-3)
    • All of the back end decryption environment and key injection (i.e. domains 5-6)must be fully compliant with P2PE
  • Recommendations of how the solution works with PCI DSS and where compliance can be simplified
If you want an analogy for NESA, this is the DeathStar under construction, a new Frigate during trials, or a cool armored car prototype. All without a warranty. And you still have to change the oil.

End-to-End Encryption (E2EE)

This is a catch all term for other approaches to providing encryption solutions. E2EE solutions are not standardized or necessarily consistent. Sometimes the term is totally misapplied or is misrepresented as P2PE. By nature, since these solutions do not provide automatic compliance simplification like P2PE, they require more due diligence and may be more limited than P2PE or NESA. Many of these solutions are an excellent alternative for merchants and are supported with documentation to give merchants, assessors, and implementers confidence that the solution is not simply good marketing, but that the solution provider has invested some due diligence in validating the solution, sometimes with significant rigor. The questions are how to know which solutions are good and how to safely achieve compliance footprints similar to P2PE. For purposes of this article, a good E2EE solution resides inside a PTS approved payment terminal, doesn’t release or leak cardholder or sensitive authentication data, doesn’t share or expose keys, and protects the encryption mechanism. A good solution minimizes the attack surface and wiggle room for an attacker.

Benefits:

  • Useful to merchants when P2PE and NESA solutions weren’t available or feasible.
  • Useful to acquirers with pre-existing encrypting solutions with a non-P2PE architecture (e.g. software encryption or a different back-end)
  • More beneficial if offered by an acquirer who controls and understands solution and has accepted risk
  • Potential to simplify merchant compliance

Other Observations:

  • More due diligence required on merchant side
  • Third party solution providers may be challenged to gain acquirer acceptance
  • More complicated for QSAs and ISAs to assess
  • Requires more understanding of the solution
  • What constitutes suitable validation steps
  • Solutions don’t require SRED to be enabled
  • Cannot use the P2PE Self-Assessment Questionnaire SAQ-P2PE.
  • Merchant still has responsibilities including for anti-skimming
  • Your mileage may vary
If you want an analogy for a good E2EE solution, this is a serviceable but slightly rusty Destroyer. No warranty. The oil still needs changing.

Legacy Integrated POS

For completeness, these systems are connected, and typically see cardholder and sensitive authentication data, and are fully in-scope for all applicable PCI DSS requirements. Unfortunately, that means most PCI DSS requirements will apply. They are tricky to secure and configure and they leave a lot of wiggle room for attack. The vast majority of payment breaches happen at the POS with ever increasing malware sophistication. Many merchants and service providers will reduce their PCI compliance scope by leveraging a PA-DSS compliant application. But it does not completely remove PCI scope, rather, it helps fast track many of the PCI requirements by transferring the responsibility to a third party. The analogy here is a leaky long boat with all hands bailing frantically and pirates on the horizon.

Assessment Aids for E2EE

When examining E2EE solutions there is a clear requirement to validate. Ultimately the merchant QSA/ISA will need to be comfortable with the solution and determine what validation steps they must perform, and which they can rely upon. They will also need to comfortable that the acquirer (or brands) support any simplification. Here we describe some of the aids and resources you may encounter.

PTS

PTS is the PCI program and standard that applies to the hardware payment terminal itself. It’s the bedrock on which P2PE, NESA, and good E2EE solutions are built. PTS approvals provide assurance that the device is resistant to tampering, supports good key management, and includes controls such as cryptographic key signing. PTS is modular and has functions that cover things like the display and various card reader components, Open Protocols (OP) (e.g. TCP/IP, WiFi, Bluetooth), and Secure Reading and Exchange of Data (SRED) which covers encryption including the use of hardware, firmware, configuration, and APIs used inside the terminal. PTS may also cover aspects of the payment application and what are referred to as firmware applications. PTS can be relied upon with minimal validation by confirming the device approval and functionality. It is worth nothing that confirming if a device is SRED is enabled vs capable is not straight forward. Due to this, most E2EE solutions will not have SRED enabled.

PA-DSS and Payment Terminals

Validation options for terminal payment applications can be a bit confusing because there are many of them. Payment applications in terminals need to be covered by some kind of PCI validation. It can be P2PE, PA-DSS, DSS, or even PTS (firmware). A couple of points are worth noting. First, PA-DSS is not required for P2PE applications as that is part of P2PE. And secondly, while PA-DSS is valuable to DSS it does not by itself provide any validation or guarantee that it can simplify compliance or reduce a merchant compliance footprint. That requires additional validation. PA-DSS can be relied upon for the device DSS. The PCI Implementation Guide (IG) must be followed by the merchant. It can prove invaluable in gaining understanding of the solution. The IG will help in determining what additional validation is needed to support compliance simplification.

Whitepapers

Many solution providers have whitepapers about their E2EE solution and make claims about the ability to simplify compliance. It is important to remember that these aren’t official attestations and cannot be relied upon by themselves. As there is no standard for these, the quality and completeness can vary significantly. However, good whitepapers can be invaluable in E2EE validation. The good ones will have characteristics such as:
  • Detailed explanation of the solution and how it operates
  • Involve actual testing of the solution and explanations of how it was tested, not just that the solution can encrypt sometimes
  • Explain how all the key objectives were met
  • Provide sufficient information that the merchant assessor can link solutions in the field to the whitepaper
  • Allow the merchant assessor to determine an appropriate level of validation
  • References including Solution provider documents and PCI guidance

Acquirer Acceptance

Acquirers are ultimately responsible for monitoring and accepting merchant risk. They can accept compliance simplification for E2EE solutions. They may or may not accept the risk of a breach.

Validation

A merchant and assessor equipped with good validation aids should be able to determine an appropriate series of validation steps. They should consider all available aids, such as:
  • Evidence of PTS
  • Evidence of Solution provider DSS
  • Evidence of PA-DSS
  • Formal guidance such as P2PE Implementation Manuals (PIMs) and PA-DSS PCI Implementation Guides (IGs)
  • Acquirer Acceptance
  • Whitepapers and solution provider documentation
  • Acquirer support to gain comfort and with some validation efforts where necessary

Reporting

SAQ merchants can’t use SAQ-P2PE. Instead they will need to use the most appropriate form (e.g. SAQ B-IP, SAQ-D, etc.) that they are eligible for and justify any non-applicability.

Due Diligence and Red Flags

With any encryption solution, due diligence is important. It’s easy enough for even an honest and diligent salesperson to get it wrong. You will need formal documentation. And you’ll need to confirm if your Acquirer supports you. This is clearest with P2PE. Over the years we’ve heard a lot of things that raised some obvious red flags, here are a few paraphrased examples (and our reaction):
  • Our application is P2PE certified (But is the Solution? So, back to E2EE then)
  • We’re using the same solution as _______ (But their gateway is in Europe, so how is yours certified?)
  • Our third party E2EE gateway and application supports scope-reduction (But does the merchant’s acquirer accept that? Does your gateway take the risk?)
  • We have a P2PE application (And? Is it certified? And the solution?)
  • Our PC based POS application provides E2EE functionality and facilitates scope reduction. (Do you even understand the first thing about PCI scope?)
  • Our E2EE solution encrypts from the terminal to the POS and our middleware re-encrypts for the bank (How does end-to-middle-to-end qualify as end-to-end?
  • In case of problems the solution can be reset to legacy by the POS? (You do know that security impacting systems are in scope too. Don’t you?)

Breaches

No one wants a breach. And no-one wants to have a breach because they oversimplified their compliance. So what can go wrong in these scenarios?
  • In any of these, even P2PE, there could be overlooked merchant scope. A reservoir of old legacy systems or some ad-hoc flow developed by a customer service focused employee. Or shadow IT. This is why documented validated flows and accurate inventories are critical.
  • Also with any of these things, there could be compliance lapses. Usually things like this happen in processes rather than technology.
  • But what could happen in non-P2PE
    • Probably one of the most likely scenarios would be cases where the terminals are deployed before encryption is enabled and they have the capability to operate in a legacy mode.
    • Failure to use SRED is possible but less likely as many terminals this is essentially a configuration option and the core encryption for SRED and non-SRED are shared.
    • Changes in host generated receipts could result in cardholder data leakage.
    • Poorly controlled loyalty card read-back.
    • The ability to make unauthorized key changes.

Learn More:

If you are at a critical point in your technology or solution design decision process and would like a second opinion, give Control Gap a call, we are happy to help. [post_title] => Understanding P2PE, NESA, E2EE, and PCI Compliance [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => understanding-encryption-and-pci-compliance [to_ping] => [pinged] => https://controlgap.com/blog/pci-nesa-2/ https://controlgap.com/blog/pci-compliance-footprints/ [post_modified] => 2017-07-06 15:33:29 [post_modified_gmt] => 2017-07-06 15:33:29 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1497 [menu_order] => 73 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [comment_count] => 0 [current_comment] => -1 [found_posts] => 45 [max_num_pages] => 15 [max_num_comment_pages] => 0 [is_single] => [is_preview] => [is_page] => [is_archive] => 1 [is_date] => [is_year] => [is_month] => [is_day] => [is_time] => [is_author] => [is_category] => 1 [is_tag] => [is_tax] => [is_search] => [is_feed] => [is_comment_feed] => [is_trackback] => [is_home] => [is_404] => [is_embed] => [is_paged] => 1 [is_admin] => [is_attachment] => [is_singular] => [is_robots] => [is_posts_page] => [is_post_type_archive] => [query_vars_hash:WP_Query:private] => 5dd470a23edaaa8b28d3af543c8bea0d [query_vars_changed:WP_Query:private] => 1 [thumbnails_cached] => [stopwords:WP_Query:private] => [compat_fields:WP_Query:private] => Array ( [0] => query_vars_hash [1] => query_vars_changed ) [compat_methods:WP_Query:private] => Array ( [0] => init_query_flags [1] => parse_tax_query ) )
Understanding P2PE, NESA, E2EE, and PCI Compliance
June 27 2017

Compliance simplification, what most people call “scope reduction”, can have huge benefits in terms of saving time, effort, headaches, and money. Merchants desire ways to simplify their PCI compliance as do the card brands, acquirers, and processors. When the PCI Council announced P2PE in 2011, there was an immediate and huge demand for approved P2PE

Read More
PCI Compliance and the Intel AMT Vulnerability
May 15 2017

On May 1st a critical new and possibly unprecedented vulnerability was announced.  The flaw in Intel’s Active Management Technology (AMT) firmware will be difficult to deal with, in part, because most organizations are not setup to rapidly deploy firmware updates across large numbers of systems.  The feature is supported by almost a decades worth of

Read More
8-digit BIN Issues and Risks Remain after PCI Truncation Rules Clarified
May 10 2017

Last month we wrote this article about issues arising from the addition of new BIN ranges and the lack of clear guidance specifically with 16-digit PAN that have 8-digit BINs. Today, the PCI Council just updated FAQ#1091 “What are acceptable formats for truncation of primary account numbers?” to specifically address the issue of how to

Read More

e-newsletter

Want important PCI information delivered to you? Sign-up to our e-newsletter and be the first one to know about industry news and trend, offers and promotions.

×

Contact

×

PCI Pilot™ is coming soon!

Our highly-anticipated online tool will be launching very soon to make your PCI SAQ process quick and seamless.

Sign-up today and be among the first to know when PCI Pilot™ is live!