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] => 1545 [post_author] => 7 [post_date] => 2017-08-31 14:09:13 [post_date_gmt] => 2017-08-31 14:09:13 [post_content] => It's hard to imagine a natural disaster until it starts happening in your own backyard. Unfortunately, the people of Texas have experienced and continue to experience the unimaginable over the course of the last several days. The scale and magnitude of flooding, damage, and tragedy from Hurricane Harvey is still ongoing - many people have lost their lives, and many more have lost their homes and possessions. Canadians can recall our own flooding disasters in Toronto, Calgary, and Canmore in 2013, as well as the repeated flooding of Winnipeg over the years. As devastating as these were, they were but a tiny fraction of what Houston is now enduring. From past and present experiences of cities that have endured a natural disaster, it is known that the cleanup and rebuilding will take years. As many people near and far may want to help, but can't participate, they will donate their money or goods to charities helping the cause. During this time of community outreach through donations and services, it is important to remember the important to take some basic precautions.

Making Sure Your Contributions Count

It important to note that the first call of security is the protection of people. For this reason, we shine light on the fact that disasters bring out both the best and the worst in people. The best can be reflected through the TexasNavy and CajunNavy volunteers, businesses on the ground who've pitched in to open their doors or helped where they can, the emergency service personnel working around the clock to exhaustion, as well as the neighbors and strangers who help along the way. The worst in people, however, can be reflected in the scams that take place from those seeking to gain profit from a tragedy such as this. Therefore, before you give, please take a few moments to research the charity you plan on donating to and avoid any charities that don't check out. You may also refer to Brian Kreb's article warning of hurricane relief scams and how to check out charities. CNN has posted an article on legitimate ways to help those effected by the storm. The plight of the people of Texas is deeply felt. Our deepest sympathies, prayers, and hope go out to you all.   [post_title] => Hurricane Harvey: How To Avoid Scams When Donating To Natural Disaster Charity Groups [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => security-hurricane-harvey [to_ping] => [pinged] => [post_modified] => 2017-08-31 14:39:12 [post_modified_gmt] => 2017-08-31 14:39:12 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1545 [menu_order] => 80 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [1] => WP_Post Object ( [ID] => 1465 [post_author] => 2 [post_date] => 2017-07-19 13:43:27 [post_date_gmt] => 2017-07-19 13:43:27 [post_content] => Now is the time to stop using 64-bit block length ciphers such as 3DES (TDEA) and Blowfish in general purpose applications of cryptography. In 2016, an attack was demonstrated that affects all ciphers using 64-bit block lengths, including the most commonly used ciphers 3DES (TDEA), Blowfish, and IDEA; and specialized ciphers such as KASUMI, PRESENT, and HIGHT used in cellular, low power, and low resource applications. The attack is novel, at least for the public, in that it does not hinge on the cipher algorithm, the key length, or the way the cipher is used. Before people panic, there are some use-cases that remain safe. There are, however, many unsafe use-cases that need to be addressed. The weakness stems from the fact that ciphers cannot use their keys indefinitely and keys must be changed before a critical volume of material is encrypted. Block length determines this frequency and modern ciphers like AES moved to 128-bit block lengths specifically to address this risk. Naturally, you may be wondering why this hasn't been bigger news? Or why NIST or ISO hasn't deprecated 64-bit block ciphers earlier? All good questions. Perhaps they should have. We can only speculate, but it may be because this vulnerability is just a bit different, that it isn't related to key strength, protocol design, or implementation flaws. It may also be because there are mitigating strategies. However, the better question is are you at risk? And if so, how to make sense out of this and know what to do? Note: NIST just announced their intent to deprecate TDEA (3DES). They are open for comments and feedback until October 1st, 2017. The announcement focuses on 3DES as the other ciphers were not promoted by NIST.

The State of Strong Cryptography

Before we look at this development, let's review recent history of cryptographic vulnerabilities.
  • The strongest form of 3DES (aka TDEA) uses 3 rounds of DES with 3 different keys (i.e. 168-bits of keys). Well known weaknesses in 3DES mean that the effective strength is only 112-bits not 168-bits. Two key 3DES is too weak for general purpose applications; however, there are some special use-cases such as in payments and banking where 2-key 3DES can be used safely with constructs such as Derived Unique Key Per Transaction (DUKPT).
  • Most Internet security protocols were developed before AES at a time when 64-bit block ciphers were standard. Many of these protocols were designed to be "agile" supporting multiple configurable ciphers and protocol versions. This flexibility facilitated both security upgrades and support of diverse client systems that were nearly seamless. In recent years, most of these protocols have been upgraded, enhanced, or outright replaced. Unfortunately, old crypto is often left lingering around for years past it's prime.
  • Over the last 20 years, key strengths have increased from 56 to 128 bits (symmetric keys) and from 768 to 2048 bits (RSA keys).
  • Hash algorithms like MD5 and SHA-1 are no longer secure.
  • SSL and early TLS were deprecated due to a steady stream of attacks.
  • Cipher Block Chaining (CBC) modes are showing weaknesses.

Summary of Recent Cryptographic Vulnerabilities

Recent years have seen a flood of attacks and bugs that affect Internet security. Many of these took a decade or more of research to develop after the discoveries of the original weaknesses:
  • Implementation bugs (e.g. HeartBleed, or Virtual Host Confusion) are unrelated to the cryptography. Basically, these aren't design problems but are coding blunders that can be found and fixed. They tend to be widespread only if the library or solution is also widespread.
  • Weaknesses in cryptographic algorithms (i.e. RC4, SHA1, MD5 , and Diffie-Hellman Key Exchange) as have been demonstrated in NOMORE, LogJam, SLOTH, and other attacks.
  • Protocol downgrade attacks (e.g. DROWN, FREAK) force fallback to insecure methods.
  • Attacks exploiting timing issues and compression (e.g. TIME, CRIME, BREACH).
  • Padding Oracle problems with CBC mode ciphers (e.g. BEAST, POODLE, Lucky13).

The Weakness

The problem resulting from not changing keys often enough is known to cryptographers as the "Birthday Bound". It's related to the Birthday Paradox, where you only need about 23 people in a room to have a 50% chance of two of them having the same birthday. The weakness arises because of "collisions" in the cipher output. By XOR'ing the collisions an attacker can get close to the plain text. If they also know some of the plain text or can predict it, then they can begin peeling back the encryption. And the more collisions and known plain text they have, the more they can decrypt. The chance of collisions grows with the volume of encrypted data and becomes significant as volumes near the birthday bound. For 64-bit block ciphers this is 232 or about 4 billion blocks.

The Attack

Attackers have a much easier time when they can control more of the plain text and when interesting data repeats. The attack framework used in BEAST and POODLE does an excellent job here. The attack, called "Sweet32", was demonstrated last summer. It used the BEAST framework to significant advantage by forcing re-transmission of high volumes of valuable secrets. It succeeded in a surprisingly short time, specifically:
  • 19 hours and 705GB of traffic to retrieve an HTTP session cookie protected by TLS / 3DES
  • 30 hours and 610GB of traffic to retrieve an HTTP basic authentication credential protected by  OpenVPN / Blowfish

The Risks

The main risk factors for 64-bit block collision attacks are:
  • Lengthy transmissions or transmissions than can be lengthened
  • Connections where the attacker can inject large amounts of known plain text
  • Connections that re-key traffic infrequently
  • End-points susceptible to malware
  • Connections that relay content
Given these factors, some 64-bit block use-cases are clearly unsafe
  • Browsers and web-sites
  • Site-to-site VPNs
  • Encrypted email links
  • Large file transfers
  • Older legacy systems
Safe use-cases will have characteristics such as:
  • Non-interactive / programmed
  • Short / burst transmissions
  • Frequent re-keying of transmissions
  • Locked down endpoints

Impact on PCI Compliance Standards

Historically, PCI has taken its lead on cryptography matters from NIST. One only has to look at the deprecation of SSLv2, RSA 1024, and SSL/early TLS for examples. NIST's move to begin the deprecation of TDEA will inevitably result in PCI following suit. It's a fair question to ask: what will the this process will look like? There is some good news in this as an excellent example of a safe use-case would be a hardware payment terminal connecting to a processors payment gateway for a credit/debit transaction. Consider:
  • PTS approved terminals have a code signing mechanism that effectively locks down the end-point
  • Many hardware payment terminals start new connections and re-key every transaction
  • Limited opportunities for chosen plain text injection exist and these typically need manual interaction
These are typically payments based use-cases and these are precisely the same reasons that, despite POODLE, hardware terminals running SSL 3.0 can often get a pass under PCI DSS.  Additionally, other cases such as small cryptograms in databases and message fields shouldn't be affected. If there were no safer use cases and it were just the case of the cipher's use by individual organizations, there would likely be no modification of DSS as it would be covered by the general deference to NIST's position on strong cryptography. However, a major concern will be the impact on companion standards and the large world-wide installed base of payment devices, such as POS terminals, and ATMs. Final replacement of 3DES will take time and cost billions in upgrades and replacements. This is our prediction as to how this process will unfold:
  • The PCI SSC will begin to look at this issue and will publish interim guidance in preparation to update the DSS
  • A final position will wait until NIST makes its recommendations which is expected in late 2017Q3.
  • There will be a deprecation process and supporting requirements similar to, possibly an extension of,  PCI DSS 3.2's Appendix A2: Additional PCI DSS Requirements for Entities using SSL/early TLS
  • The process will similarly be three phased, firstly targeting short blocked ciphers in general use cases, then software use cases, and finally approved hardware use cases with set time frames for the first two phases
  • There will need to be significant industry consultations to help set the time lines
  • In addition to the DSS changes several of the other PCI standards, such as PA-DSS, PTS, P2PE, etc., will need adjustments as the world moves away from 3DES.
We would hope, that to maintain an even playing field, any changes to the PA-DSS will allow for the continued use of 3DES in hardware terminal based applications only where the encryption is provided by the PTS approved mechanism until those are deprecated. Finally, we would expect to see a PCI DSS revision (possibly v3.3) in 2018 coming into effect after June 30th when all current future dated requirements become locked in.

What To Do?

Getting rid of 64-bit block ciphers should be easier than eliminating SSL. Still it will require planning including impact analysis. In each case consider:
  • How easily can the cipher be replaced? Fortunately, most Internet security protocols are agile and can be configured to support or drop support for specific algorithms. Unfortunately, some legacy end-points may not support stronger ciphers. And while the prospect of losing a few customers with ancient browsers runs counter to most businesses philosophy, the real challenges will be internal legacy and B2B systems.
  • It may be possible to force re-keying long before you get near a risky volume of data. The challenge is that this typically needs application modifications since protocols such as TLS only support but don't enforce re-keying.
Organizations should begin planning today:
  • Understand where they are using legacy ciphers both externally and internally
  • Prioritize the unsafe and at-risk use-cases
  • Determine options to permanently replace the legacy ciphers or to mitigate their use in the short term
  • Understand and document your use-cases and their associated risks
Vulnerability scanners will flag these legacy ciphers when used in a protocol. If you run scans as part of a compliance program such as PCI's ASV, the existence of these legacy ciphers will become a compliance issue. The scanners won't know if your use-case is safe and the documentation of those cases will be invaluable to show the finding is a false alarm and obtaining an exemption. As for applications using small cryptograms, while they remain safe for now, industry and individual organizations need to start thinking about how they will replace them in the long term so that it doesn't become an emergency. This effort will eventually address the use of 3DES in financial systems such as ATMs and POS terminals.

Learn More

_______________________________________________________________ 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] => NIST Moves on Sweet32 - 3DES, Blowfish, and Others - Mostly Unsafe [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => nist-moves-on-sweet32 [to_ping] => [pinged] => https://controlgap.com/blog/sha-1-is-dead/ https://controlgap.com/blog/pci-dss-3-1-updates/ [post_modified] => 2017-07-19 22:54:31 [post_modified_gmt] => 2017-07-19 22:54:31 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1465 [menu_order] => 87 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [2] => 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] => 91 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) ) [post_count] => 3 [current_post] => -1 [in_the_loop] => [post] => WP_Post Object ( [ID] => 1545 [post_author] => 7 [post_date] => 2017-08-31 14:09:13 [post_date_gmt] => 2017-08-31 14:09:13 [post_content] => It's hard to imagine a natural disaster until it starts happening in your own backyard. Unfortunately, the people of Texas have experienced and continue to experience the unimaginable over the course of the last several days. The scale and magnitude of flooding, damage, and tragedy from Hurricane Harvey is still ongoing - many people have lost their lives, and many more have lost their homes and possessions. Canadians can recall our own flooding disasters in Toronto, Calgary, and Canmore in 2013, as well as the repeated flooding of Winnipeg over the years. As devastating as these were, they were but a tiny fraction of what Houston is now enduring. From past and present experiences of cities that have endured a natural disaster, it is known that the cleanup and rebuilding will take years. As many people near and far may want to help, but can't participate, they will donate their money or goods to charities helping the cause. During this time of community outreach through donations and services, it is important to remember the important to take some basic precautions.

Making Sure Your Contributions Count

It important to note that the first call of security is the protection of people. For this reason, we shine light on the fact that disasters bring out both the best and the worst in people. The best can be reflected through the TexasNavy and CajunNavy volunteers, businesses on the ground who've pitched in to open their doors or helped where they can, the emergency service personnel working around the clock to exhaustion, as well as the neighbors and strangers who help along the way. The worst in people, however, can be reflected in the scams that take place from those seeking to gain profit from a tragedy such as this. Therefore, before you give, please take a few moments to research the charity you plan on donating to and avoid any charities that don't check out. You may also refer to Brian Kreb's article warning of hurricane relief scams and how to check out charities. CNN has posted an article on legitimate ways to help those effected by the storm. The plight of the people of Texas is deeply felt. Our deepest sympathies, prayers, and hope go out to you all.   [post_title] => Hurricane Harvey: How To Avoid Scams When Donating To Natural Disaster Charity Groups [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => security-hurricane-harvey [to_ping] => [pinged] => [post_modified] => 2017-08-31 14:39:12 [post_modified_gmt] => 2017-08-31 14:39:12 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1545 [menu_order] => 80 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [comment_count] => 0 [current_comment] => -1 [found_posts] => 47 [max_num_pages] => 16 [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] => 1545 [post_author] => 7 [post_date] => 2017-08-31 14:09:13 [post_date_gmt] => 2017-08-31 14:09:13 [post_content] => It's hard to imagine a natural disaster until it starts happening in your own backyard. Unfortunately, the people of Texas have experienced and continue to experience the unimaginable over the course of the last several days. The scale and magnitude of flooding, damage, and tragedy from Hurricane Harvey is still ongoing - many people have lost their lives, and many more have lost their homes and possessions. Canadians can recall our own flooding disasters in Toronto, Calgary, and Canmore in 2013, as well as the repeated flooding of Winnipeg over the years. As devastating as these were, they were but a tiny fraction of what Houston is now enduring. From past and present experiences of cities that have endured a natural disaster, it is known that the cleanup and rebuilding will take years. As many people near and far may want to help, but can't participate, they will donate their money or goods to charities helping the cause. During this time of community outreach through donations and services, it is important to remember the important to take some basic precautions.

Making Sure Your Contributions Count

It important to note that the first call of security is the protection of people. For this reason, we shine light on the fact that disasters bring out both the best and the worst in people. The best can be reflected through the TexasNavy and CajunNavy volunteers, businesses on the ground who've pitched in to open their doors or helped where they can, the emergency service personnel working around the clock to exhaustion, as well as the neighbors and strangers who help along the way. The worst in people, however, can be reflected in the scams that take place from those seeking to gain profit from a tragedy such as this. Therefore, before you give, please take a few moments to research the charity you plan on donating to and avoid any charities that don't check out. You may also refer to Brian Kreb's article warning of hurricane relief scams and how to check out charities. CNN has posted an article on legitimate ways to help those effected by the storm. The plight of the people of Texas is deeply felt. Our deepest sympathies, prayers, and hope go out to you all.   [post_title] => Hurricane Harvey: How To Avoid Scams When Donating To Natural Disaster Charity Groups [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => security-hurricane-harvey [to_ping] => [pinged] => [post_modified] => 2017-08-31 14:39:12 [post_modified_gmt] => 2017-08-31 14:39:12 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1545 [menu_order] => 80 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [1] => WP_Post Object ( [ID] => 1465 [post_author] => 2 [post_date] => 2017-07-19 13:43:27 [post_date_gmt] => 2017-07-19 13:43:27 [post_content] => Now is the time to stop using 64-bit block length ciphers such as 3DES (TDEA) and Blowfish in general purpose applications of cryptography. In 2016, an attack was demonstrated that affects all ciphers using 64-bit block lengths, including the most commonly used ciphers 3DES (TDEA), Blowfish, and IDEA; and specialized ciphers such as KASUMI, PRESENT, and HIGHT used in cellular, low power, and low resource applications. The attack is novel, at least for the public, in that it does not hinge on the cipher algorithm, the key length, or the way the cipher is used. Before people panic, there are some use-cases that remain safe. There are, however, many unsafe use-cases that need to be addressed. The weakness stems from the fact that ciphers cannot use their keys indefinitely and keys must be changed before a critical volume of material is encrypted. Block length determines this frequency and modern ciphers like AES moved to 128-bit block lengths specifically to address this risk. Naturally, you may be wondering why this hasn't been bigger news? Or why NIST or ISO hasn't deprecated 64-bit block ciphers earlier? All good questions. Perhaps they should have. We can only speculate, but it may be because this vulnerability is just a bit different, that it isn't related to key strength, protocol design, or implementation flaws. It may also be because there are mitigating strategies. However, the better question is are you at risk? And if so, how to make sense out of this and know what to do? Note: NIST just announced their intent to deprecate TDEA (3DES). They are open for comments and feedback until October 1st, 2017. The announcement focuses on 3DES as the other ciphers were not promoted by NIST.

The State of Strong Cryptography

Before we look at this development, let's review recent history of cryptographic vulnerabilities.
  • The strongest form of 3DES (aka TDEA) uses 3 rounds of DES with 3 different keys (i.e. 168-bits of keys). Well known weaknesses in 3DES mean that the effective strength is only 112-bits not 168-bits. Two key 3DES is too weak for general purpose applications; however, there are some special use-cases such as in payments and banking where 2-key 3DES can be used safely with constructs such as Derived Unique Key Per Transaction (DUKPT).
  • Most Internet security protocols were developed before AES at a time when 64-bit block ciphers were standard. Many of these protocols were designed to be "agile" supporting multiple configurable ciphers and protocol versions. This flexibility facilitated both security upgrades and support of diverse client systems that were nearly seamless. In recent years, most of these protocols have been upgraded, enhanced, or outright replaced. Unfortunately, old crypto is often left lingering around for years past it's prime.
  • Over the last 20 years, key strengths have increased from 56 to 128 bits (symmetric keys) and from 768 to 2048 bits (RSA keys).
  • Hash algorithms like MD5 and SHA-1 are no longer secure.
  • SSL and early TLS were deprecated due to a steady stream of attacks.
  • Cipher Block Chaining (CBC) modes are showing weaknesses.

Summary of Recent Cryptographic Vulnerabilities

Recent years have seen a flood of attacks and bugs that affect Internet security. Many of these took a decade or more of research to develop after the discoveries of the original weaknesses:
  • Implementation bugs (e.g. HeartBleed, or Virtual Host Confusion) are unrelated to the cryptography. Basically, these aren't design problems but are coding blunders that can be found and fixed. They tend to be widespread only if the library or solution is also widespread.
  • Weaknesses in cryptographic algorithms (i.e. RC4, SHA1, MD5 , and Diffie-Hellman Key Exchange) as have been demonstrated in NOMORE, LogJam, SLOTH, and other attacks.
  • Protocol downgrade attacks (e.g. DROWN, FREAK) force fallback to insecure methods.
  • Attacks exploiting timing issues and compression (e.g. TIME, CRIME, BREACH).
  • Padding Oracle problems with CBC mode ciphers (e.g. BEAST, POODLE, Lucky13).

The Weakness

The problem resulting from not changing keys often enough is known to cryptographers as the "Birthday Bound". It's related to the Birthday Paradox, where you only need about 23 people in a room to have a 50% chance of two of them having the same birthday. The weakness arises because of "collisions" in the cipher output. By XOR'ing the collisions an attacker can get close to the plain text. If they also know some of the plain text or can predict it, then they can begin peeling back the encryption. And the more collisions and known plain text they have, the more they can decrypt. The chance of collisions grows with the volume of encrypted data and becomes significant as volumes near the birthday bound. For 64-bit block ciphers this is 232 or about 4 billion blocks.

The Attack

Attackers have a much easier time when they can control more of the plain text and when interesting data repeats. The attack framework used in BEAST and POODLE does an excellent job here. The attack, called "Sweet32", was demonstrated last summer. It used the BEAST framework to significant advantage by forcing re-transmission of high volumes of valuable secrets. It succeeded in a surprisingly short time, specifically:
  • 19 hours and 705GB of traffic to retrieve an HTTP session cookie protected by TLS / 3DES
  • 30 hours and 610GB of traffic to retrieve an HTTP basic authentication credential protected by  OpenVPN / Blowfish

The Risks

The main risk factors for 64-bit block collision attacks are:
  • Lengthy transmissions or transmissions than can be lengthened
  • Connections where the attacker can inject large amounts of known plain text
  • Connections that re-key traffic infrequently
  • End-points susceptible to malware
  • Connections that relay content
Given these factors, some 64-bit block use-cases are clearly unsafe
  • Browsers and web-sites
  • Site-to-site VPNs
  • Encrypted email links
  • Large file transfers
  • Older legacy systems
Safe use-cases will have characteristics such as:
  • Non-interactive / programmed
  • Short / burst transmissions
  • Frequent re-keying of transmissions
  • Locked down endpoints

Impact on PCI Compliance Standards

Historically, PCI has taken its lead on cryptography matters from NIST. One only has to look at the deprecation of SSLv2, RSA 1024, and SSL/early TLS for examples. NIST's move to begin the deprecation of TDEA will inevitably result in PCI following suit. It's a fair question to ask: what will the this process will look like? There is some good news in this as an excellent example of a safe use-case would be a hardware payment terminal connecting to a processors payment gateway for a credit/debit transaction. Consider:
  • PTS approved terminals have a code signing mechanism that effectively locks down the end-point
  • Many hardware payment terminals start new connections and re-key every transaction
  • Limited opportunities for chosen plain text injection exist and these typically need manual interaction
These are typically payments based use-cases and these are precisely the same reasons that, despite POODLE, hardware terminals running SSL 3.0 can often get a pass under PCI DSS.  Additionally, other cases such as small cryptograms in databases and message fields shouldn't be affected. If there were no safer use cases and it were just the case of the cipher's use by individual organizations, there would likely be no modification of DSS as it would be covered by the general deference to NIST's position on strong cryptography. However, a major concern will be the impact on companion standards and the large world-wide installed base of payment devices, such as POS terminals, and ATMs. Final replacement of 3DES will take time and cost billions in upgrades and replacements. This is our prediction as to how this process will unfold:
  • The PCI SSC will begin to look at this issue and will publish interim guidance in preparation to update the DSS
  • A final position will wait until NIST makes its recommendations which is expected in late 2017Q3.
  • There will be a deprecation process and supporting requirements similar to, possibly an extension of,  PCI DSS 3.2's Appendix A2: Additional PCI DSS Requirements for Entities using SSL/early TLS
  • The process will similarly be three phased, firstly targeting short blocked ciphers in general use cases, then software use cases, and finally approved hardware use cases with set time frames for the first two phases
  • There will need to be significant industry consultations to help set the time lines
  • In addition to the DSS changes several of the other PCI standards, such as PA-DSS, PTS, P2PE, etc., will need adjustments as the world moves away from 3DES.
We would hope, that to maintain an even playing field, any changes to the PA-DSS will allow for the continued use of 3DES in hardware terminal based applications only where the encryption is provided by the PTS approved mechanism until those are deprecated. Finally, we would expect to see a PCI DSS revision (possibly v3.3) in 2018 coming into effect after June 30th when all current future dated requirements become locked in.

What To Do?

Getting rid of 64-bit block ciphers should be easier than eliminating SSL. Still it will require planning including impact analysis. In each case consider:
  • How easily can the cipher be replaced? Fortunately, most Internet security protocols are agile and can be configured to support or drop support for specific algorithms. Unfortunately, some legacy end-points may not support stronger ciphers. And while the prospect of losing a few customers with ancient browsers runs counter to most businesses philosophy, the real challenges will be internal legacy and B2B systems.
  • It may be possible to force re-keying long before you get near a risky volume of data. The challenge is that this typically needs application modifications since protocols such as TLS only support but don't enforce re-keying.
Organizations should begin planning today:
  • Understand where they are using legacy ciphers both externally and internally
  • Prioritize the unsafe and at-risk use-cases
  • Determine options to permanently replace the legacy ciphers or to mitigate their use in the short term
  • Understand and document your use-cases and their associated risks
Vulnerability scanners will flag these legacy ciphers when used in a protocol. If you run scans as part of a compliance program such as PCI's ASV, the existence of these legacy ciphers will become a compliance issue. The scanners won't know if your use-case is safe and the documentation of those cases will be invaluable to show the finding is a false alarm and obtaining an exemption. As for applications using small cryptograms, while they remain safe for now, industry and individual organizations need to start thinking about how they will replace them in the long term so that it doesn't become an emergency. This effort will eventually address the use of 3DES in financial systems such as ATMs and POS terminals.

Learn More

_______________________________________________________________ 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] => NIST Moves on Sweet32 - 3DES, Blowfish, and Others - Mostly Unsafe [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => nist-moves-on-sweet32 [to_ping] => [pinged] => https://controlgap.com/blog/sha-1-is-dead/ https://controlgap.com/blog/pci-dss-3-1-updates/ [post_modified] => 2017-07-19 22:54:31 [post_modified_gmt] => 2017-07-19 22:54:31 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1465 [menu_order] => 87 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [2] => 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] => 91 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) ) [post_count] => 3 [current_post] => -1 [in_the_loop] => [post] => WP_Post Object ( [ID] => 1545 [post_author] => 7 [post_date] => 2017-08-31 14:09:13 [post_date_gmt] => 2017-08-31 14:09:13 [post_content] => It's hard to imagine a natural disaster until it starts happening in your own backyard. Unfortunately, the people of Texas have experienced and continue to experience the unimaginable over the course of the last several days. The scale and magnitude of flooding, damage, and tragedy from Hurricane Harvey is still ongoing - many people have lost their lives, and many more have lost their homes and possessions. Canadians can recall our own flooding disasters in Toronto, Calgary, and Canmore in 2013, as well as the repeated flooding of Winnipeg over the years. As devastating as these were, they were but a tiny fraction of what Houston is now enduring. From past and present experiences of cities that have endured a natural disaster, it is known that the cleanup and rebuilding will take years. As many people near and far may want to help, but can't participate, they will donate their money or goods to charities helping the cause. During this time of community outreach through donations and services, it is important to remember the important to take some basic precautions.

Making Sure Your Contributions Count

It important to note that the first call of security is the protection of people. For this reason, we shine light on the fact that disasters bring out both the best and the worst in people. The best can be reflected through the TexasNavy and CajunNavy volunteers, businesses on the ground who've pitched in to open their doors or helped where they can, the emergency service personnel working around the clock to exhaustion, as well as the neighbors and strangers who help along the way. The worst in people, however, can be reflected in the scams that take place from those seeking to gain profit from a tragedy such as this. Therefore, before you give, please take a few moments to research the charity you plan on donating to and avoid any charities that don't check out. You may also refer to Brian Kreb's article warning of hurricane relief scams and how to check out charities. CNN has posted an article on legitimate ways to help those effected by the storm. The plight of the people of Texas is deeply felt. Our deepest sympathies, prayers, and hope go out to you all.   [post_title] => Hurricane Harvey: How To Avoid Scams When Donating To Natural Disaster Charity Groups [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => security-hurricane-harvey [to_ping] => [pinged] => [post_modified] => 2017-08-31 14:39:12 [post_modified_gmt] => 2017-08-31 14:39:12 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1545 [menu_order] => 80 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [comment_count] => 0 [current_comment] => -1 [found_posts] => 47 [max_num_pages] => 16 [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 ) )
Hurricane Harvey: How To Avoid Scams When Donating To Natural Disaster Charity Groups
August 31 2017

It’s hard to imagine a natural disaster until it starts happening in your own backyard. Unfortunately, the people of Texas have experienced and continue to experience the unimaginable over the course of the last several days. The scale and magnitude of flooding, damage, and tragedy from Hurricane Harvey is still ongoing – many people have

Read More
NIST Moves on Sweet32 – 3DES, Blowfish, and Others – Mostly Unsafe
July 19 2017

Now is the time to stop using 64-bit block length ciphers such as 3DES (TDEA) and Blowfish in general purpose applications of cryptography. In 2016, an attack was demonstrated that affects all ciphers using 64-bit block lengths, including the most commonly used ciphers 3DES (TDEA), Blowfish, and IDEA; and specialized ciphers such as KASUMI, PRESENT, and HIGHT

Read More
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

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!