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] => 2 [ignore_sticky_posts] => 1 ) [query_vars] => Array ( [post_type] => post [post_status] => publish [cat] => 14 [orderby] => date [order] => DESC [posts_per_page] => 3 [paged] => 2 [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 3, 3 [posts] => Array ( [0] => WP_Post Object ( [ID] => 1625 [post_author] => 2 [post_date] => 2018-01-10 10:07:08 [post_date_gmt] => 2018-01-10 10:07:08 [post_content] => PCI DSS v3.2 is due for an update this year - but what will that look like? In this article, we peer into our crystal ball to make some predictions ...

What Will The New DSS Bring?

Q: The updated DSS will need a new version number, so will that be:  4.0,  3.3, or 3.2.1?
A: The PCI Council indicated in 2017 that they expect that the next update to the DSS will not be a major overhaul. We've also seen indications that there will likely be changes that go beyond just baking in future dated requirements.  We expect a new DSS published before the end of Q3 2018 and it will be version 3.3.
Q: What about SSL and early TLS?
A: The transition period ending June 30, 2018 will not be extended. The exemption for POI devices that can show they remain safe to use will remain for the foreseeable future. As PCI PTS and PA-DSS have not allowed this exemption for some time there may be clarification that this is intended for legacy devices (i.e. pre-existing deployments).
Q: What about Multi-factor Authentication requirements?
A: The current MFA requirements dated January 31, 2018 will be baked into the new DSS. This was supported by recently released guidance on MFA (see PCI below). So we don't expect major changes here. Some minor clarifications are possible and we wouldn't be surprised to see FAQs emerge (e.g. strong vs. weak MFA).
Q: What about the other January 31, 2018 requirements?
A: The requirements to ensure that all entities include PCI DSS controls in all new or updated systems; as well as, the additional documentation and procedures required of service providers will be baked into the new version. Possibly these will be accompanied by some clarifications.
Q: How soon will the new DSS come into effect?
A: We expect that the new DSS will be designed to come into effect very quickly after publication. In order to facilitate this, we expect that any significant changes will be future dated to allow for orderly transition.
Q: How will PCI align with the new NIST password complexity guidance?
A: We would expect the new DSS will handle this in an evolutionary manner retaining backward compatibility and using "equivalent or better strength" interpretations. We'd like to see adjustments that wouldn't require the use of compensating controls (see NIST below).
Q: How will  the DSS align with the updated OWASP 2017 top 10 list?
A: While OWASP and PCI don't always stay in perfect alignment, this generally should not be a problem as PCI is intended to align with current industry best practices (note on 6.5) and has a backstop rule (6.5.6). The back stop requirement mandates that "high severity" vulnerabilities must be corrected.  However, there has been some recent drift which includes a couple of significant changes (see OWASP below).  We expect there is a reasonable chance of PCI DSS clarifications and possibly some future-dated requirements to bring these closer together.  The following have no direct correlation in (6.5.x) and we think that there may be some adjustment to better align with A4, A8, and A9.  From a best practice perspective, it may be time to ensure that code reviews look for logging deficiencies (A10).
  • A4:2017 XML External Entities (XXE)
  • A8:2017 Insecure Deserialization
  • A9:2017 (and 2013) Using Components with Known Vulnerabilities
  • A10:2017 Insufficient Logging & Monitoring
Q: Will any of the requirements that apply only to service providers be applied to merchants?
A: Several Business as Usual (BAU) requirements, such as validating that executive management has established responsibility for an internal PCI DSS compliance program (12.4.1) and  that processes are being followed throughout the year (12.11), may be considered for expansion to merchants. Again, we would expect these to be future dated and possibly with different frequency (e.g. semi-annually vs quarterly).
Q: Will any of the Designated Entity Supplemental Validation (DESV) requirements make it into the core of the DSS?
A: We expect that the bulk of the DESV requirements will remain in Appendix A3.
Q: How will the DSS address industry changes, such as the new 8-digit BINs?
A: The rules for truncation will remain the same; however, there may be clarifications added to account for the fact that in some cases full 8-digit BINs may be considered cardholder data requiring protection (e.g. encryption). See BIN truncation below)
Q: Will the new DSS deprecate 64-bit-block ciphers like 3-DES and Blowfish?
A: PCI tends to avoid specifying algorithms within the DSS and relies instead on the use of "strong cryptography" and the use of supporting documents.  However, the problem with 64-bit-block is similar to the SSL and early TLS problem with a similar mix of use cases and migration challenges (see Sweet32 below).  We anticipate that a solution similar to Appendix A2 and the SSL/early TLS migration with long future dates may be included in the next DSS.
Q: Will the new DSS deprecate SHA-1?
A: The DSS relies upon the definition of strong cryptography in the official PCI DSS Glossary and FAQs (see SHA-1 below and PCI FAQ).  We expect this will be addressed within the Glossary.
Q: Will there be requirements for new security technologies like white-listing, code-signing, or Data Loss Prevention?
A: We don't anticipate the council will require the addition of new technologies into the DSS.  They will continue to be used as examples in guidance and by organizations needing formal compensating controls.
Q: Will the DSS directly address newer technologies such as cloud and containers?
A: These are not generally addressed directly by the DSS but through separate guidance such as the 2013 Cloud guidance.  At this time, there is no scheduled update for Cloud or Container technologies.  If your organization is interested, you may want to contact the PCI Special Interest Group team.
Q: Will there be further clarifications to the e-commerce applicability scenarios used in SAQ A and A-EP and the supporting IFRAME/URL-redirection FAQs?
A: The current criteria for distinguishing these use cases continues to cause confusion in cases such as scripted IFRAMEs. While we don't expect the DSS to directly address this, we do expect that further clarifications in the form of FAQs are likely.  While there is a potential for some future dated requirements such as confirming the same origin policy is in force, we expect that additional SAQ eligibility requirements, or increasing the compliance footprint used for the simplest redirection use cases are more likely.
Q: Will there be further changes to segmentation and isolation requirements/guidance?
A: We don't anticipate any major changes in the DSS requirements or current scoping guidance a around segmentation and isolation. While there is always the potential for clarifications or minor updates through FAQs, we view this as mature and stable. (see "Connected-to" below and Scoping below)
Q: Will PCI DSS continue to challenge organizations?
A: That much won't change.

Learn More

PCI Publications and Guidance

Industry Best Practice

Insight Articles

_______________________________________________________________ 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] => 17 Predictions About the Next Version of PCI DSS [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => predictions-next-version-pci-dss [to_ping] => [pinged] => https://controlgap.com/blog/connected-to-pci/ https://controlgap.com/blog/sha-1-is-dead/ https://controlgap.com/blog/nist-moves-on-sweet32/ [post_modified] => 2018-01-16 18:18:47 [post_modified_gmt] => 2018-01-16 18:18:47 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1625 [menu_order] => 26 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [1] => WP_Post Object ( [ID] => 1538 [post_author] => 2 [post_date] => 2017-12-07 19:51:39 [post_date_gmt] => 2017-12-07 19:51:39 [post_content] => PCI DSS is all about scope. Getting scope right or wrong is perhaps the single most critical factor determining the ultimate success or failure of an organization's compliance. While determining scope is the responsibility of the assessed, validating scope is the responsibility of the assessor. What that means is that an organization can't arbitrarily choose their scope or exclude things, their decisions must be credible and consistent within the framework of the DSS. Any organization being assessed that uses inconsistent approaches to scoping, can expect potential disagreements in scoping methodology leading to unpleasant surprises and experiences.  Organizations having to secure new found scope will often require the investment of significant expense and effort to achieve timely remediation. Clearly, it is critically important to understand the current scoping rules of PCI DSS. We emphasized the word current because the interpretation and rules around DSS scoping have been clarified and evolved as the standard matured. Unfortunately, this evolution can lead to confusion if not everyone is on the same page.

How Scoping Has Evolved

Before we get into the current rules, it may be useful to understand some of this evolution and clarification from the early DSS until today:
  • Systems and applications that stored, processed, or transmitted cardholder data
  • Inclusion of all systems on the same network as cardholder data systems
  • Extension of scope to people, processes, and technology
  • Inclusion of security systems
  • Clarification on e-commerce redirection methods
It's also important to understand that these changes eased into PCI, initially being understood as best practices or the intent of the standard, and only later being codified. There have been several efforts to provide better scoping guidance over the years.  The PCI council set up a working group to look at scoping in 2010 which produced some draft documents. In 2012, the Open PCI Scoping Toolkit (OPST) was published by third parties. While not officially endorsed by the council, the toolkit was clearly similar to the approach taken by the previous SIG.  The OPST is quite well structured but could lead to disagreements over risk. Later, the council published their own guidance on Scoping and Segmentation in 2016 and updated it in 2017. The language of PCI also reflects this evolution. The terms "Connected-to" and "Security-impacting" being just two of the PCI-isms that you will hear in scoping discussions. In particular, the meaning of "Connected-to" has evolved. It originally was used to focus on the connections of same network systems or what we sometimes refer to as Big Flat Network issues. Today, "Connected-to", literally means a connection that is agnostic to media (e.g. cable, wireless), protocols, and network access controls (e.g. firewalls).

Scoping Today

The PCI council scoping guidance is published in the PCI Document Library on their web site (see Learn More below). One of the key artifacts here is an info-graphic showing PCI DSS scoping considerations and criteria. This info-graphic is clearly covers the issues. There isn't a lot that we would recommend changing or clarifying. Nonetheless, we still see people getting confused about scope and question specific wording rather than focusing on intent. We've seen all kinds of debates on scope, some examples:
  • "The word-smith" : "the systems on the second site LAN extension aren't in scope because it is a different (unfirewalled) segment"
  • "Living in a Non-security Silo" : "but the source code control system for our payment application isn't security impacting"
  • "The confused": "But the XYZ system connects to ABC company and to customers on the Internet so they must be in scope too?"
While we see all kinds of debates on scope, the numbers of people that get confused about the rules suggests that the message isn't getting through clearly.  We wondered, why this might be? And if there is a better way to explain it?

Scope vs. Compliance Footprints

We think part of the problem is that people are confusing the being "in-scope" for PCI DSS with the applicability of the requirements. This is something we refer to as a "Compliance Footprint" and have written about before (see Learn More below). The first thing we noted in Figure 1 was the top two boxes in the "Connected-to" or "Security-Impacting Systems" group: "System components directly connected to the CDE" and "System components indirectly connected to the CDE".  Examples of the first group could be things like a pin pad on a serial cable, a USB printer, a Bluetooth device, or every system at another location on the WAN. The second group could be connections through firewalls and/or proxies.  This is often where people get a bit far afield. Consider that many companies have business partners that connect to their systems. Q: Are they "in-scope"? A: "Yes".  But the real money question is "How are they in scope?" Some common ways include:
  • A service provider that has validated their compliance for the services provided (Covered in DSS 12.8 and 12.9)
  • A service provider that has not validated their compliance and will need to have applicable services validated as part of your assessment
  • Another third party connection that can be demonstrated to pose no risk to the PCI environment (e.g. retrieves reports of truncated card data from your reporting system)
The last case can confuse people, they naturally want to argue that the third party system is out of scope.  It helps to understand that "in-scope for DSS" is another example of PCI jargon. Scope doesn't mean exactly what people think it means. What has really happened, is that your organization assessed the risk of that connection and concluded that no PCI DSS requirements applied because your architecture treated it as untrusted  and implemented appropriate security measures.  Basically both ends of the connection are in scope, but one end doesn't matter.

Shrinking Footprints

This leads us to our last piece of PCI jargon "in-scope for all applicable requirements". When something is in scope for PCI DSS it doesn't necessarily follow that all DSS requirements apply. There is specific guidance that makes it clear that not all requirement apply in all cases (see Learn More below). The various SAQ forms are evidence that there are examples of use cases where only subsets of the requirements apply. This leads us to an interesting conclusion and one that sounds very strange, it is possible to have systems in-scope for PCI DSS with zero applicable requirements!  What this means is the connection is in scope, the connecting system is untrusted by design, and the system was designed and verified to deal with that untrusted system. By this point, you are likely to think that this is merely an academic statement of no practical value. If you think that, you are mistaken. Not only is this possible, it is actually common. The following examples illustrate this.
  • In P2PE solutions, merchants deploy encrypting terminals connected to POS systems and networks. In these deployments the terminals are in scope for a small number of requirements (see SAQ P2PE) and the connected POS system and network have no applicable DSS requirements.
  • The example, used previously, on a non-PCI report (e.g. truncated settlement reports) is another example.
While most people will naturally see a system with zero applicable requirements as being "out-of-scope" on a practical level, it is important to understand how you get there in order to deal with other types of connected systems. You could even use this approach to explain away e-commerce customers.  Again, the central point of the argument would be that the e-commerce server was designed to work with untrusted client systems. So even if they were not out of scope by definition, it could be argued that they don't matter because there are no applicable requirements.

Scope Is About Connections!

The takeaways from this are that scope is not just about systems and networks, and that a large scope doesn't always mean a large footprint. Scope is inherently about connections. Footprint size is about the associated risk of those connections.

Applying This In Practice

If you want to apply these ideas in practice, you need to document your position.
  • Don't shy away from a scope because it's large or drags in many connected-to systems
  • Do show you understand the connections in your environment
  • Do show you understand the risks of each connection/application/protocol
  • Do validate (i.e. test) to ensure your low/no risk connections are in fact no/low risk
Remember, it’s wrong to think of PCI as just securing systems and networks. It secures connections and by definition it secures applications.

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] => Understanding "Connected-to" - Is The Internet In Scope For PCI DSS? [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => connected-to-pci [to_ping] => [pinged] => https://controlgap.com/blog/pci-compliance-footprints/ [post_modified] => 2018-01-02 19:02:18 [post_modified_gmt] => 2018-01-02 19:02:18 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1538 [menu_order] => 32 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [2] => WP_Post Object ( [ID] => 1602 [post_author] => 7 [post_date] => 2017-11-23 18:35:04 [post_date_gmt] => 2017-11-23 18:35:04 [post_content] => This year, and for many years prior, Control Gap Inc. continues to be a proud supporter of Easter Seals Ontario through the Toronto Maple Leafs Skate for Easter Seals Kids. The Toronto Maple Leafs Skate for Easter Seals Kids is a fundraising event where kids have the opportunity to skate with members of the Toronto Maple Leafs team. Participants need to reach a fundraising donation minimum of $200 in order to partake in the event, and all proceeds go towards the Easter Seals Ontario foundation which supports kids in the province with physical disabilities. We have had the opportunity of learning about this event through a young, ambitious, and dedicated Easter Seals participant, Casey MacKay. Casey first stopped by our office in Mississauga, ON about three years ago and has continued to visit and share his enthusiasm for this event with us on an annual basis. This year, we donated to the Easter Seals Skate in support of Casey and his friend, Luke. Casey was able to surpass his initial goal of $5,000 and has decided to raise his goal to $6,500. You can learn more about the skate here or you can donate to Casey directly to help him reach his new goal here. We wish the best of luck to everyone participating in this year's skate and hope each participant has a fun filled day! [caption id="attachment_1607" align="alignnone" width="700"] Control Gap Partners, Bruce Duff and Neal Christopher, with Easter Seals participant Casey MacKay at the Control Gap office in Mississauga, ON.[/caption] [post_title] => Control Gap Inc. Supports Easter Seals Ontario [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => easter-seals-skate [to_ping] => [pinged] => http://eastersealsskate.org/skate-information/about/ [post_modified] => 2017-11-30 14:58:14 [post_modified_gmt] => 2017-11-30 14:58:14 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1602 [menu_order] => 35 [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] => 1625 [post_author] => 2 [post_date] => 2018-01-10 10:07:08 [post_date_gmt] => 2018-01-10 10:07:08 [post_content] => PCI DSS v3.2 is due for an update this year - but what will that look like? In this article, we peer into our crystal ball to make some predictions ...

What Will The New DSS Bring?

Q: The updated DSS will need a new version number, so will that be:  4.0,  3.3, or 3.2.1?
A: The PCI Council indicated in 2017 that they expect that the next update to the DSS will not be a major overhaul. We've also seen indications that there will likely be changes that go beyond just baking in future dated requirements.  We expect a new DSS published before the end of Q3 2018 and it will be version 3.3.
Q: What about SSL and early TLS?
A: The transition period ending June 30, 2018 will not be extended. The exemption for POI devices that can show they remain safe to use will remain for the foreseeable future. As PCI PTS and PA-DSS have not allowed this exemption for some time there may be clarification that this is intended for legacy devices (i.e. pre-existing deployments).
Q: What about Multi-factor Authentication requirements?
A: The current MFA requirements dated January 31, 2018 will be baked into the new DSS. This was supported by recently released guidance on MFA (see PCI below). So we don't expect major changes here. Some minor clarifications are possible and we wouldn't be surprised to see FAQs emerge (e.g. strong vs. weak MFA).
Q: What about the other January 31, 2018 requirements?
A: The requirements to ensure that all entities include PCI DSS controls in all new or updated systems; as well as, the additional documentation and procedures required of service providers will be baked into the new version. Possibly these will be accompanied by some clarifications.
Q: How soon will the new DSS come into effect?
A: We expect that the new DSS will be designed to come into effect very quickly after publication. In order to facilitate this, we expect that any significant changes will be future dated to allow for orderly transition.
Q: How will PCI align with the new NIST password complexity guidance?
A: We would expect the new DSS will handle this in an evolutionary manner retaining backward compatibility and using "equivalent or better strength" interpretations. We'd like to see adjustments that wouldn't require the use of compensating controls (see NIST below).
Q: How will  the DSS align with the updated OWASP 2017 top 10 list?
A: While OWASP and PCI don't always stay in perfect alignment, this generally should not be a problem as PCI is intended to align with current industry best practices (note on 6.5) and has a backstop rule (6.5.6). The back stop requirement mandates that "high severity" vulnerabilities must be corrected.  However, there has been some recent drift which includes a couple of significant changes (see OWASP below).  We expect there is a reasonable chance of PCI DSS clarifications and possibly some future-dated requirements to bring these closer together.  The following have no direct correlation in (6.5.x) and we think that there may be some adjustment to better align with A4, A8, and A9.  From a best practice perspective, it may be time to ensure that code reviews look for logging deficiencies (A10).
  • A4:2017 XML External Entities (XXE)
  • A8:2017 Insecure Deserialization
  • A9:2017 (and 2013) Using Components with Known Vulnerabilities
  • A10:2017 Insufficient Logging & Monitoring
Q: Will any of the requirements that apply only to service providers be applied to merchants?
A: Several Business as Usual (BAU) requirements, such as validating that executive management has established responsibility for an internal PCI DSS compliance program (12.4.1) and  that processes are being followed throughout the year (12.11), may be considered for expansion to merchants. Again, we would expect these to be future dated and possibly with different frequency (e.g. semi-annually vs quarterly).
Q: Will any of the Designated Entity Supplemental Validation (DESV) requirements make it into the core of the DSS?
A: We expect that the bulk of the DESV requirements will remain in Appendix A3.
Q: How will the DSS address industry changes, such as the new 8-digit BINs?
A: The rules for truncation will remain the same; however, there may be clarifications added to account for the fact that in some cases full 8-digit BINs may be considered cardholder data requiring protection (e.g. encryption). See BIN truncation below)
Q: Will the new DSS deprecate 64-bit-block ciphers like 3-DES and Blowfish?
A: PCI tends to avoid specifying algorithms within the DSS and relies instead on the use of "strong cryptography" and the use of supporting documents.  However, the problem with 64-bit-block is similar to the SSL and early TLS problem with a similar mix of use cases and migration challenges (see Sweet32 below).  We anticipate that a solution similar to Appendix A2 and the SSL/early TLS migration with long future dates may be included in the next DSS.
Q: Will the new DSS deprecate SHA-1?
A: The DSS relies upon the definition of strong cryptography in the official PCI DSS Glossary and FAQs (see SHA-1 below and PCI FAQ).  We expect this will be addressed within the Glossary.
Q: Will there be requirements for new security technologies like white-listing, code-signing, or Data Loss Prevention?
A: We don't anticipate the council will require the addition of new technologies into the DSS.  They will continue to be used as examples in guidance and by organizations needing formal compensating controls.
Q: Will the DSS directly address newer technologies such as cloud and containers?
A: These are not generally addressed directly by the DSS but through separate guidance such as the 2013 Cloud guidance.  At this time, there is no scheduled update for Cloud or Container technologies.  If your organization is interested, you may want to contact the PCI Special Interest Group team.
Q: Will there be further clarifications to the e-commerce applicability scenarios used in SAQ A and A-EP and the supporting IFRAME/URL-redirection FAQs?
A: The current criteria for distinguishing these use cases continues to cause confusion in cases such as scripted IFRAMEs. While we don't expect the DSS to directly address this, we do expect that further clarifications in the form of FAQs are likely.  While there is a potential for some future dated requirements such as confirming the same origin policy is in force, we expect that additional SAQ eligibility requirements, or increasing the compliance footprint used for the simplest redirection use cases are more likely.
Q: Will there be further changes to segmentation and isolation requirements/guidance?
A: We don't anticipate any major changes in the DSS requirements or current scoping guidance a around segmentation and isolation. While there is always the potential for clarifications or minor updates through FAQs, we view this as mature and stable. (see "Connected-to" below and Scoping below)
Q: Will PCI DSS continue to challenge organizations?
A: That much won't change.

Learn More

PCI Publications and Guidance

Industry Best Practice

Insight Articles

_______________________________________________________________ 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] => 17 Predictions About the Next Version of PCI DSS [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => predictions-next-version-pci-dss [to_ping] => [pinged] => https://controlgap.com/blog/connected-to-pci/ https://controlgap.com/blog/sha-1-is-dead/ https://controlgap.com/blog/nist-moves-on-sweet32/ [post_modified] => 2018-01-16 18:18:47 [post_modified_gmt] => 2018-01-16 18:18:47 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1625 [menu_order] => 26 [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] => 33cf985084681950bc0bf4e00b11dc6e [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] => 2 [ignore_sticky_posts] => 1 ) [query_vars] => Array ( [post_type] => post [post_status] => publish [cat] => 14 [orderby] => date [order] => DESC [posts_per_page] => 3 [paged] => 2 [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 3, 3 [posts] => Array ( [0] => WP_Post Object ( [ID] => 1625 [post_author] => 2 [post_date] => 2018-01-10 10:07:08 [post_date_gmt] => 2018-01-10 10:07:08 [post_content] => PCI DSS v3.2 is due for an update this year - but what will that look like? In this article, we peer into our crystal ball to make some predictions ...

What Will The New DSS Bring?

Q: The updated DSS will need a new version number, so will that be:  4.0,  3.3, or 3.2.1?
A: The PCI Council indicated in 2017 that they expect that the next update to the DSS will not be a major overhaul. We've also seen indications that there will likely be changes that go beyond just baking in future dated requirements.  We expect a new DSS published before the end of Q3 2018 and it will be version 3.3.
Q: What about SSL and early TLS?
A: The transition period ending June 30, 2018 will not be extended. The exemption for POI devices that can show they remain safe to use will remain for the foreseeable future. As PCI PTS and PA-DSS have not allowed this exemption for some time there may be clarification that this is intended for legacy devices (i.e. pre-existing deployments).
Q: What about Multi-factor Authentication requirements?
A: The current MFA requirements dated January 31, 2018 will be baked into the new DSS. This was supported by recently released guidance on MFA (see PCI below). So we don't expect major changes here. Some minor clarifications are possible and we wouldn't be surprised to see FAQs emerge (e.g. strong vs. weak MFA).
Q: What about the other January 31, 2018 requirements?
A: The requirements to ensure that all entities include PCI DSS controls in all new or updated systems; as well as, the additional documentation and procedures required of service providers will be baked into the new version. Possibly these will be accompanied by some clarifications.
Q: How soon will the new DSS come into effect?
A: We expect that the new DSS will be designed to come into effect very quickly after publication. In order to facilitate this, we expect that any significant changes will be future dated to allow for orderly transition.
Q: How will PCI align with the new NIST password complexity guidance?
A: We would expect the new DSS will handle this in an evolutionary manner retaining backward compatibility and using "equivalent or better strength" interpretations. We'd like to see adjustments that wouldn't require the use of compensating controls (see NIST below).
Q: How will  the DSS align with the updated OWASP 2017 top 10 list?
A: While OWASP and PCI don't always stay in perfect alignment, this generally should not be a problem as PCI is intended to align with current industry best practices (note on 6.5) and has a backstop rule (6.5.6). The back stop requirement mandates that "high severity" vulnerabilities must be corrected.  However, there has been some recent drift which includes a couple of significant changes (see OWASP below).  We expect there is a reasonable chance of PCI DSS clarifications and possibly some future-dated requirements to bring these closer together.  The following have no direct correlation in (6.5.x) and we think that there may be some adjustment to better align with A4, A8, and A9.  From a best practice perspective, it may be time to ensure that code reviews look for logging deficiencies (A10).
  • A4:2017 XML External Entities (XXE)
  • A8:2017 Insecure Deserialization
  • A9:2017 (and 2013) Using Components with Known Vulnerabilities
  • A10:2017 Insufficient Logging & Monitoring
Q: Will any of the requirements that apply only to service providers be applied to merchants?
A: Several Business as Usual (BAU) requirements, such as validating that executive management has established responsibility for an internal PCI DSS compliance program (12.4.1) and  that processes are being followed throughout the year (12.11), may be considered for expansion to merchants. Again, we would expect these to be future dated and possibly with different frequency (e.g. semi-annually vs quarterly).
Q: Will any of the Designated Entity Supplemental Validation (DESV) requirements make it into the core of the DSS?
A: We expect that the bulk of the DESV requirements will remain in Appendix A3.
Q: How will the DSS address industry changes, such as the new 8-digit BINs?
A: The rules for truncation will remain the same; however, there may be clarifications added to account for the fact that in some cases full 8-digit BINs may be considered cardholder data requiring protection (e.g. encryption). See BIN truncation below)
Q: Will the new DSS deprecate 64-bit-block ciphers like 3-DES and Blowfish?
A: PCI tends to avoid specifying algorithms within the DSS and relies instead on the use of "strong cryptography" and the use of supporting documents.  However, the problem with 64-bit-block is similar to the SSL and early TLS problem with a similar mix of use cases and migration challenges (see Sweet32 below).  We anticipate that a solution similar to Appendix A2 and the SSL/early TLS migration with long future dates may be included in the next DSS.
Q: Will the new DSS deprecate SHA-1?
A: The DSS relies upon the definition of strong cryptography in the official PCI DSS Glossary and FAQs (see SHA-1 below and PCI FAQ).  We expect this will be addressed within the Glossary.
Q: Will there be requirements for new security technologies like white-listing, code-signing, or Data Loss Prevention?
A: We don't anticipate the council will require the addition of new technologies into the DSS.  They will continue to be used as examples in guidance and by organizations needing formal compensating controls.
Q: Will the DSS directly address newer technologies such as cloud and containers?
A: These are not generally addressed directly by the DSS but through separate guidance such as the 2013 Cloud guidance.  At this time, there is no scheduled update for Cloud or Container technologies.  If your organization is interested, you may want to contact the PCI Special Interest Group team.
Q: Will there be further clarifications to the e-commerce applicability scenarios used in SAQ A and A-EP and the supporting IFRAME/URL-redirection FAQs?
A: The current criteria for distinguishing these use cases continues to cause confusion in cases such as scripted IFRAMEs. While we don't expect the DSS to directly address this, we do expect that further clarifications in the form of FAQs are likely.  While there is a potential for some future dated requirements such as confirming the same origin policy is in force, we expect that additional SAQ eligibility requirements, or increasing the compliance footprint used for the simplest redirection use cases are more likely.
Q: Will there be further changes to segmentation and isolation requirements/guidance?
A: We don't anticipate any major changes in the DSS requirements or current scoping guidance a around segmentation and isolation. While there is always the potential for clarifications or minor updates through FAQs, we view this as mature and stable. (see "Connected-to" below and Scoping below)
Q: Will PCI DSS continue to challenge organizations?
A: That much won't change.

Learn More

PCI Publications and Guidance

Industry Best Practice

Insight Articles

_______________________________________________________________ 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] => 17 Predictions About the Next Version of PCI DSS [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => predictions-next-version-pci-dss [to_ping] => [pinged] => https://controlgap.com/blog/connected-to-pci/ https://controlgap.com/blog/sha-1-is-dead/ https://controlgap.com/blog/nist-moves-on-sweet32/ [post_modified] => 2018-01-16 18:18:47 [post_modified_gmt] => 2018-01-16 18:18:47 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1625 [menu_order] => 26 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [1] => WP_Post Object ( [ID] => 1538 [post_author] => 2 [post_date] => 2017-12-07 19:51:39 [post_date_gmt] => 2017-12-07 19:51:39 [post_content] => PCI DSS is all about scope. Getting scope right or wrong is perhaps the single most critical factor determining the ultimate success or failure of an organization's compliance. While determining scope is the responsibility of the assessed, validating scope is the responsibility of the assessor. What that means is that an organization can't arbitrarily choose their scope or exclude things, their decisions must be credible and consistent within the framework of the DSS. Any organization being assessed that uses inconsistent approaches to scoping, can expect potential disagreements in scoping methodology leading to unpleasant surprises and experiences.  Organizations having to secure new found scope will often require the investment of significant expense and effort to achieve timely remediation. Clearly, it is critically important to understand the current scoping rules of PCI DSS. We emphasized the word current because the interpretation and rules around DSS scoping have been clarified and evolved as the standard matured. Unfortunately, this evolution can lead to confusion if not everyone is on the same page.

How Scoping Has Evolved

Before we get into the current rules, it may be useful to understand some of this evolution and clarification from the early DSS until today:
  • Systems and applications that stored, processed, or transmitted cardholder data
  • Inclusion of all systems on the same network as cardholder data systems
  • Extension of scope to people, processes, and technology
  • Inclusion of security systems
  • Clarification on e-commerce redirection methods
It's also important to understand that these changes eased into PCI, initially being understood as best practices or the intent of the standard, and only later being codified. There have been several efforts to provide better scoping guidance over the years.  The PCI council set up a working group to look at scoping in 2010 which produced some draft documents. In 2012, the Open PCI Scoping Toolkit (OPST) was published by third parties. While not officially endorsed by the council, the toolkit was clearly similar to the approach taken by the previous SIG.  The OPST is quite well structured but could lead to disagreements over risk. Later, the council published their own guidance on Scoping and Segmentation in 2016 and updated it in 2017. The language of PCI also reflects this evolution. The terms "Connected-to" and "Security-impacting" being just two of the PCI-isms that you will hear in scoping discussions. In particular, the meaning of "Connected-to" has evolved. It originally was used to focus on the connections of same network systems or what we sometimes refer to as Big Flat Network issues. Today, "Connected-to", literally means a connection that is agnostic to media (e.g. cable, wireless), protocols, and network access controls (e.g. firewalls).

Scoping Today

The PCI council scoping guidance is published in the PCI Document Library on their web site (see Learn More below). One of the key artifacts here is an info-graphic showing PCI DSS scoping considerations and criteria. This info-graphic is clearly covers the issues. There isn't a lot that we would recommend changing or clarifying. Nonetheless, we still see people getting confused about scope and question specific wording rather than focusing on intent. We've seen all kinds of debates on scope, some examples:
  • "The word-smith" : "the systems on the second site LAN extension aren't in scope because it is a different (unfirewalled) segment"
  • "Living in a Non-security Silo" : "but the source code control system for our payment application isn't security impacting"
  • "The confused": "But the XYZ system connects to ABC company and to customers on the Internet so they must be in scope too?"
While we see all kinds of debates on scope, the numbers of people that get confused about the rules suggests that the message isn't getting through clearly.  We wondered, why this might be? And if there is a better way to explain it?

Scope vs. Compliance Footprints

We think part of the problem is that people are confusing the being "in-scope" for PCI DSS with the applicability of the requirements. This is something we refer to as a "Compliance Footprint" and have written about before (see Learn More below). The first thing we noted in Figure 1 was the top two boxes in the "Connected-to" or "Security-Impacting Systems" group: "System components directly connected to the CDE" and "System components indirectly connected to the CDE".  Examples of the first group could be things like a pin pad on a serial cable, a USB printer, a Bluetooth device, or every system at another location on the WAN. The second group could be connections through firewalls and/or proxies.  This is often where people get a bit far afield. Consider that many companies have business partners that connect to their systems. Q: Are they "in-scope"? A: "Yes".  But the real money question is "How are they in scope?" Some common ways include:
  • A service provider that has validated their compliance for the services provided (Covered in DSS 12.8 and 12.9)
  • A service provider that has not validated their compliance and will need to have applicable services validated as part of your assessment
  • Another third party connection that can be demonstrated to pose no risk to the PCI environment (e.g. retrieves reports of truncated card data from your reporting system)
The last case can confuse people, they naturally want to argue that the third party system is out of scope.  It helps to understand that "in-scope for DSS" is another example of PCI jargon. Scope doesn't mean exactly what people think it means. What has really happened, is that your organization assessed the risk of that connection and concluded that no PCI DSS requirements applied because your architecture treated it as untrusted  and implemented appropriate security measures.  Basically both ends of the connection are in scope, but one end doesn't matter.

Shrinking Footprints

This leads us to our last piece of PCI jargon "in-scope for all applicable requirements". When something is in scope for PCI DSS it doesn't necessarily follow that all DSS requirements apply. There is specific guidance that makes it clear that not all requirement apply in all cases (see Learn More below). The various SAQ forms are evidence that there are examples of use cases where only subsets of the requirements apply. This leads us to an interesting conclusion and one that sounds very strange, it is possible to have systems in-scope for PCI DSS with zero applicable requirements!  What this means is the connection is in scope, the connecting system is untrusted by design, and the system was designed and verified to deal with that untrusted system. By this point, you are likely to think that this is merely an academic statement of no practical value. If you think that, you are mistaken. Not only is this possible, it is actually common. The following examples illustrate this.
  • In P2PE solutions, merchants deploy encrypting terminals connected to POS systems and networks. In these deployments the terminals are in scope for a small number of requirements (see SAQ P2PE) and the connected POS system and network have no applicable DSS requirements.
  • The example, used previously, on a non-PCI report (e.g. truncated settlement reports) is another example.
While most people will naturally see a system with zero applicable requirements as being "out-of-scope" on a practical level, it is important to understand how you get there in order to deal with other types of connected systems. You could even use this approach to explain away e-commerce customers.  Again, the central point of the argument would be that the e-commerce server was designed to work with untrusted client systems. So even if they were not out of scope by definition, it could be argued that they don't matter because there are no applicable requirements.

Scope Is About Connections!

The takeaways from this are that scope is not just about systems and networks, and that a large scope doesn't always mean a large footprint. Scope is inherently about connections. Footprint size is about the associated risk of those connections.

Applying This In Practice

If you want to apply these ideas in practice, you need to document your position.
  • Don't shy away from a scope because it's large or drags in many connected-to systems
  • Do show you understand the connections in your environment
  • Do show you understand the risks of each connection/application/protocol
  • Do validate (i.e. test) to ensure your low/no risk connections are in fact no/low risk
Remember, it’s wrong to think of PCI as just securing systems and networks. It secures connections and by definition it secures applications.

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] => Understanding "Connected-to" - Is The Internet In Scope For PCI DSS? [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => connected-to-pci [to_ping] => [pinged] => https://controlgap.com/blog/pci-compliance-footprints/ [post_modified] => 2018-01-02 19:02:18 [post_modified_gmt] => 2018-01-02 19:02:18 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1538 [menu_order] => 32 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [2] => WP_Post Object ( [ID] => 1602 [post_author] => 7 [post_date] => 2017-11-23 18:35:04 [post_date_gmt] => 2017-11-23 18:35:04 [post_content] => This year, and for many years prior, Control Gap Inc. continues to be a proud supporter of Easter Seals Ontario through the Toronto Maple Leafs Skate for Easter Seals Kids. The Toronto Maple Leafs Skate for Easter Seals Kids is a fundraising event where kids have the opportunity to skate with members of the Toronto Maple Leafs team. Participants need to reach a fundraising donation minimum of $200 in order to partake in the event, and all proceeds go towards the Easter Seals Ontario foundation which supports kids in the province with physical disabilities. We have had the opportunity of learning about this event through a young, ambitious, and dedicated Easter Seals participant, Casey MacKay. Casey first stopped by our office in Mississauga, ON about three years ago and has continued to visit and share his enthusiasm for this event with us on an annual basis. This year, we donated to the Easter Seals Skate in support of Casey and his friend, Luke. Casey was able to surpass his initial goal of $5,000 and has decided to raise his goal to $6,500. You can learn more about the skate here or you can donate to Casey directly to help him reach his new goal here. We wish the best of luck to everyone participating in this year's skate and hope each participant has a fun filled day! [caption id="attachment_1607" align="alignnone" width="700"] Control Gap Partners, Bruce Duff and Neal Christopher, with Easter Seals participant Casey MacKay at the Control Gap office in Mississauga, ON.[/caption] [post_title] => Control Gap Inc. Supports Easter Seals Ontario [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => easter-seals-skate [to_ping] => [pinged] => http://eastersealsskate.org/skate-information/about/ [post_modified] => 2017-11-30 14:58:14 [post_modified_gmt] => 2017-11-30 14:58:14 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1602 [menu_order] => 35 [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] => 1625 [post_author] => 2 [post_date] => 2018-01-10 10:07:08 [post_date_gmt] => 2018-01-10 10:07:08 [post_content] => PCI DSS v3.2 is due for an update this year - but what will that look like? In this article, we peer into our crystal ball to make some predictions ...

What Will The New DSS Bring?

Q: The updated DSS will need a new version number, so will that be:  4.0,  3.3, or 3.2.1?
A: The PCI Council indicated in 2017 that they expect that the next update to the DSS will not be a major overhaul. We've also seen indications that there will likely be changes that go beyond just baking in future dated requirements.  We expect a new DSS published before the end of Q3 2018 and it will be version 3.3.
Q: What about SSL and early TLS?
A: The transition period ending June 30, 2018 will not be extended. The exemption for POI devices that can show they remain safe to use will remain for the foreseeable future. As PCI PTS and PA-DSS have not allowed this exemption for some time there may be clarification that this is intended for legacy devices (i.e. pre-existing deployments).
Q: What about Multi-factor Authentication requirements?
A: The current MFA requirements dated January 31, 2018 will be baked into the new DSS. This was supported by recently released guidance on MFA (see PCI below). So we don't expect major changes here. Some minor clarifications are possible and we wouldn't be surprised to see FAQs emerge (e.g. strong vs. weak MFA).
Q: What about the other January 31, 2018 requirements?
A: The requirements to ensure that all entities include PCI DSS controls in all new or updated systems; as well as, the additional documentation and procedures required of service providers will be baked into the new version. Possibly these will be accompanied by some clarifications.
Q: How soon will the new DSS come into effect?
A: We expect that the new DSS will be designed to come into effect very quickly after publication. In order to facilitate this, we expect that any significant changes will be future dated to allow for orderly transition.
Q: How will PCI align with the new NIST password complexity guidance?
A: We would expect the new DSS will handle this in an evolutionary manner retaining backward compatibility and using "equivalent or better strength" interpretations. We'd like to see adjustments that wouldn't require the use of compensating controls (see NIST below).
Q: How will  the DSS align with the updated OWASP 2017 top 10 list?
A: While OWASP and PCI don't always stay in perfect alignment, this generally should not be a problem as PCI is intended to align with current industry best practices (note on 6.5) and has a backstop rule (6.5.6). The back stop requirement mandates that "high severity" vulnerabilities must be corrected.  However, there has been some recent drift which includes a couple of significant changes (see OWASP below).  We expect there is a reasonable chance of PCI DSS clarifications and possibly some future-dated requirements to bring these closer together.  The following have no direct correlation in (6.5.x) and we think that there may be some adjustment to better align with A4, A8, and A9.  From a best practice perspective, it may be time to ensure that code reviews look for logging deficiencies (A10).
  • A4:2017 XML External Entities (XXE)
  • A8:2017 Insecure Deserialization
  • A9:2017 (and 2013) Using Components with Known Vulnerabilities
  • A10:2017 Insufficient Logging & Monitoring
Q: Will any of the requirements that apply only to service providers be applied to merchants?
A: Several Business as Usual (BAU) requirements, such as validating that executive management has established responsibility for an internal PCI DSS compliance program (12.4.1) and  that processes are being followed throughout the year (12.11), may be considered for expansion to merchants. Again, we would expect these to be future dated and possibly with different frequency (e.g. semi-annually vs quarterly).
Q: Will any of the Designated Entity Supplemental Validation (DESV) requirements make it into the core of the DSS?
A: We expect that the bulk of the DESV requirements will remain in Appendix A3.
Q: How will the DSS address industry changes, such as the new 8-digit BINs?
A: The rules for truncation will remain the same; however, there may be clarifications added to account for the fact that in some cases full 8-digit BINs may be considered cardholder data requiring protection (e.g. encryption). See BIN truncation below)
Q: Will the new DSS deprecate 64-bit-block ciphers like 3-DES and Blowfish?
A: PCI tends to avoid specifying algorithms within the DSS and relies instead on the use of "strong cryptography" and the use of supporting documents.  However, the problem with 64-bit-block is similar to the SSL and early TLS problem with a similar mix of use cases and migration challenges (see Sweet32 below).  We anticipate that a solution similar to Appendix A2 and the SSL/early TLS migration with long future dates may be included in the next DSS.
Q: Will the new DSS deprecate SHA-1?
A: The DSS relies upon the definition of strong cryptography in the official PCI DSS Glossary and FAQs (see SHA-1 below and PCI FAQ).  We expect this will be addressed within the Glossary.
Q: Will there be requirements for new security technologies like white-listing, code-signing, or Data Loss Prevention?
A: We don't anticipate the council will require the addition of new technologies into the DSS.  They will continue to be used as examples in guidance and by organizations needing formal compensating controls.
Q: Will the DSS directly address newer technologies such as cloud and containers?
A: These are not generally addressed directly by the DSS but through separate guidance such as the 2013 Cloud guidance.  At this time, there is no scheduled update for Cloud or Container technologies.  If your organization is interested, you may want to contact the PCI Special Interest Group team.
Q: Will there be further clarifications to the e-commerce applicability scenarios used in SAQ A and A-EP and the supporting IFRAME/URL-redirection FAQs?
A: The current criteria for distinguishing these use cases continues to cause confusion in cases such as scripted IFRAMEs. While we don't expect the DSS to directly address this, we do expect that further clarifications in the form of FAQs are likely.  While there is a potential for some future dated requirements such as confirming the same origin policy is in force, we expect that additional SAQ eligibility requirements, or increasing the compliance footprint used for the simplest redirection use cases are more likely.
Q: Will there be further changes to segmentation and isolation requirements/guidance?
A: We don't anticipate any major changes in the DSS requirements or current scoping guidance a around segmentation and isolation. While there is always the potential for clarifications or minor updates through FAQs, we view this as mature and stable. (see "Connected-to" below and Scoping below)
Q: Will PCI DSS continue to challenge organizations?
A: That much won't change.

Learn More

PCI Publications and Guidance

Industry Best Practice

Insight Articles

_______________________________________________________________ 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] => 17 Predictions About the Next Version of PCI DSS [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => predictions-next-version-pci-dss [to_ping] => [pinged] => https://controlgap.com/blog/connected-to-pci/ https://controlgap.com/blog/sha-1-is-dead/ https://controlgap.com/blog/nist-moves-on-sweet32/ [post_modified] => 2018-01-16 18:18:47 [post_modified_gmt] => 2018-01-16 18:18:47 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1625 [menu_order] => 26 [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] => 33cf985084681950bc0bf4e00b11dc6e [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 ) )
17 Predictions About the Next Version of PCI DSS
January 10 2018

PCI DSS v3.2 is due for an update this year – but what will that look like? In this article, we peer into our crystal ball to make some predictions … What Will The New DSS Bring? Q: The updated DSS will need a new version number, so will that be:  4.0,  3.3, or 3.2.1?

Read More
Understanding “Connected-to” – Is The Internet In Scope For PCI DSS?
December 7 2017

PCI DSS is all about scope. Getting scope right or wrong is perhaps the single most critical factor determining the ultimate success or failure of an organization’s compliance. While determining scope is the responsibility of the assessed, validating scope is the responsibility of the assessor. What that means is that an organization can’t arbitrarily choose

Read More
Control Gap Inc. Supports Easter Seals Ontario
November 23 2017

This year, and for many years prior, Control Gap Inc. continues to be a proud supporter of Easter Seals Ontario through the Toronto Maple Leafs Skate for Easter Seals Kids. The Toronto Maple Leafs Skate for Easter Seals Kids is a fundraising event where kids have the opportunity to skate with members of the Toronto

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!