The  Payment Card Industry Data Security Standard  (PCI DSS) is conventionally released every three years. In Nov 2013, PCI DSS v.3....

The Untimely Release of PCI DSS v.3.1

Sunday, January 31, 2016 Sensei Fedon 0 Comments



The Payment Card Industry Data Security Standard (PCI DSS) is conventionally released every three years. In Nov 2013, PCI DSS v.3.0 of PCI DSS was released with the next revision expected to be released in 2016. However, in April 2015, PCI Security Standards Council released an untimely version PCI DSS v.3.1. The reason behind this was to overcome threats imposed by early Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols. Though SSL was succeed in 1999 by TLS, it was still being used until 2014 till the discovery of browser attack POODLE. Furthermore, discovery of other unfixable vulnerabilities like FREAK and WinShock resulted in PCI SSC disapproving their use and release the update ahead of time.
The revision states that SSL and early versions of TLS cannot be used anymore as they are weak encryption protocols for sending cardholder data across web servers and browsers.
The requirements that are directly affected by PCI DSS v3.1 are:
  • 2.3 – (Requires encryption for services and protocols such as VPNs, FTP, Telnet, file share, etc.)
  • 3 – (Requires encryption for non-console administrative access)
  • 1 – (Requires encryption and implementation of security protocols to protect cardholder data during transmission over open, public networks.)

How to Know if your Organization is using SSL/TLS?

SSL/TLS protocol is commonly used for encryption purposes. There is a high possibility that your organization is using it to transmit critical information over unsecured network. For identifying SSL/TLS version being used, call the vendor and ask for the version. Then update or reconfigure your software accordingly.
Always keep in mind to conduct internal and external vulnerability scans for identifying unsecured SSL-based applications. If you are using windows XP, always know that the operating system is not supported and also running outdated browser versions or Internet Explorer is an open invitation to malicious individuals.

What Needs to be Done?

Merchants were forbidden to use early TLS and SSL in any new technology after April 2015. Furthermore, after June 2016, these cannot be used as security protocols for cardholder data protection. Merchants that are already using technologies based upon these protocols need to create and implement risk mitigation and migration plan. The migration plan needs to be detailed and implemented before deadline. Point of Sale (PoS) terminals that have never been exposed to vulnerabilities of TLS and SSL can continue to use these protocols after 30th June, 2016.
Plan of action depends upon your need for upgradation or reconfiguration of the system, or a little bit of both.
  • Disable SSL 3.0 in your software to reconfigure. Take instructions from vendor or from online forums.
  • Buy latest software version from vendor to upgrade and configure for latest TLS version.
  • Encrypt data with strong application or field level cryptography before transmitting data over early TLS or SSL.
To make sure no vulnerabilities are found, conduct penetration tests and vulnerability scans. Apply “automatic updates” settings in browser.

What Can E-Commerce Websites Do to Eliminate SSL / Early TLS?

E-commerce websites can be easily affected by SSL and early TLS related threats because of their web-based interface. Until migration is done, servers should be reduced to a minimum number to minimize any loss resulting from potential threats. If migration cannot be carried out at once, the reason for this should be documented and mentioned in Risk Mitigation and Migration Plan.

What Can Small Merchants Do to Eliminate SSL / Early TLS?

According to PCI DSS v.3.1 update, Small merchants are also supposed to remove SSL / early TLS protocols from cardholder data environment for ensuring security of data. For POS terminal security, small merchants need to contact terminal providers or merchants banks for SSL vulnerability assessments. Other interfaces like servers, virtual payment terminals and user computers should be validated and an immediate action for upgradation or reconfiguration should be undertaken.

Migrating Safely from SSL/Early TLS

PCI SSC has suggested the following outline to migrate from SSL/Early TLS to another alternate:
  1. Identify data flows and system components that support vulnerable protocols.
  2. Identify the business or technical need to use the vulnerable protocol for each data flow or system component.
  3. Remove all such occurrences of vulnerable protocols which are not supported by a business or a technical need.
  4. Identify which technologies can replace the protocols and also develop complete documentation of secure configurations that are planned for implementation.
  5. Document the migration plan that outlines steps and timeframes of each update.
  6. Deploy controls of risk reduction to counter the effect of known vulnerabilities till all vulnerable protocols are permanently removed.
  7. Follow the change control procedures to make sure that all updates are authorized.
  8. Upgrade system configuration standards after migration process is complete.

0 comments:

Subscribe to: Post Comments (Atom)