Payment Security Insights

November 1, 2017 Jacob Ansari

There are some important PCI DSS deadlines coming up. Let’s start with the SSL/early TLS migration. Why is it important for organizations to migrate away from SSL/TLS?

Jacob Ansari: Using SSL v3.0 (or earlier) or TLS v1.0 comes with significant security risks. There are some fairly complicated reasons why the protocols themselves have fundamental weaknesses, so they can’t get fixed with a patch or a configuration change. Specifically, an attacker who’s monitoring the encrypted traffic can find weaknesses in the values and attempt to extract that key and decrypt the session. This isn’t particularly theoretical either; if the good guys can demonstrate it, the bad guys can use it maliciously. Therefore, it’s high time to move to more secure versions of TLS, namely 1.2. 

What is the deadline? What are some major steps organizations need to be doing to meet the deadline?

Jacob Ansari: The deadline is June 30, 2018 for both merchants and service providers to no longer use SSL and early TLS as a security control. This is different from the provision in PCI DSS Appendix A2 that service providers must provide a secure service offering, which already needs to have happened. This is expressly no longer using the insecure protocols as security controls. Between now and the deadline, organizations that are still using these insecure protocols as a security control need a formal documented transition plan (i.e., a schedule for this transition) and a Risk Mitigation and Migration Plan (i.e., how to ameliorate the risks of using the insecure protocols between now and their deactivation).

Another major update to PCI DSS is the new language around multi-factor authentication. Can you provide a brief overview of what these changes mean for organizations?

Jacob Ansari: The new language calls for multi-factor authentication for all non-console administrative access to the cardholder data environment, even if from the organization’s corporate network. For a long time, many organizations mistook the intent of the original language and implemented two-factor or multi-factor authentication from the Internet to the out-of-scope corporate network, and didn’t require multi-factor authentication from that corporate network into the cardholder data environment. This seems to miss the point of the requirement and the new language supports this idea: administrative users....

Read More:

About the Author

Jacob Ansari

Jacob Ansari is the Chief Information Security Officer at Schellman & Company, where he develops and manages the company-wide information security program. Jacob oversees the processes for risk and security assessment, vulnerability management, software security, awareness and education, and incident response. Jacob has also performed in a client facing role as the technical lead for Schellman’s PCI services, and represents Schellman to the payments industry. Additionally, Jacob has experience with other Payment Card Industry assessment services, namely Software Security Framework, PA-DSS, P2PE, 3DS, and PIN. Jacob has extensive technical expertise on matters of information security, compliance, application security, and cryptography, and has been performing payment card security assessments since the card brands operated the predecessor standards to PCI DSS. Over the 20 years of his career, Jacob has spoken extensively on PCI-related matters, trained and mentored assessors, and contributed to groups on emerging standards, advisory bodies, and special interest groups.

More Content by Jacob Ansari
Previous Article
Schellman Joins PCI 3DS Assessors
Schellman Joins PCI 3DS Assessors

Schellman & Company, LLC, a leading provider of attestation and compliance services, has become ...

Next Video
Getting Ready for PCI
Getting Ready for PCI