By Paul Rummery, Securenet Consulting
See announcement by PCI DSS council
Firms have a grace period of until 30 June 2016 in which to implement v3.1 compliance, but they will not be able to roll out any new systems with SSL or early versions of TLS from April 2015.
The PCI Security Standards Council (PCI SSC) officially released PCI DSS v3.1. This release contains some relatively minor clarifications needed after the last major release (v3.0) went into full effect January 1, 2015. The primary driver for this new release, however, is the removal of SSL and early versions of TLS as examples of secure protocols.
Upgrading to a current, secure version of TLS – the successor protocol to SSL – is the only known way to remediate these vulnerabilities, which have been exploited by browser attacks such as POODLE and BEAST.
Requirements to remove SSL and early TLS
Requirement 2.2.3
Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.
"Encryption for VPNs, NetBIOS, file sharing, Telnet, FTP and similar services that are considered insecure."
Requirement 2.3
Encrypt all non-console administrative access using strong cryptography.
Requirement 4.1
Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.
What’s new?
For a summary of changes in PCI DSS 3.1
Risk mitigation and migration plan
What do, if you use SSL/TLS, and need to continue using:
Point-of-sale (POS)/Point-of-interaction (POI) terminals that have been verified as not being susceptible to all known exploits for SSL and early TLS may continue using these protocols as a security control after 30 June 2016. Organisations will be required to show how they intend to meet the mandated target migration deadline of June 30, 2016.
First, remember not to use any new technologies that use SSL/TLS. If you need to continue using SSL/TLS to continue regular business operations, here are some examples of what you can do to replace use of SSL/early TLS:
- Upgrade to a current, secure version of TLS configured to not accept fallback to SSL or early TLS.
- Encrypt data with strong cryptography before sending over SSL/early TLS (for example, use field-level or application-level encryption to encrypt the data prior to transmission).
- Set up a strongly-encrypted session first (e.g. IPsec tunnel), then send data over SSL within the secure tunnel.
- Check firewall configurations to see if SSL can be blocked.
- Check all application and system patches are up to date.
- Check and monitor systems to ID suspicious activity that may indicate a security issue.
Effective now:
Merchants are prohibited from implementing new technology that relies on SSL or early TLS. SSL and early TLS are no longer considered a best practice for strong encryption.
June 30, 2015:
Anyone completing an assessment or SAQ before this date is not required to make any SSL/TLS related changes (although we recommend that you do - adopting the early bird principle).
Anyone completing an assessment or SAQ after this date is required to provide an SSL mitigation plan, if they are not able to immediately discontinue its use.
June 30, 2016:
After this date, merchants are no longer allowed to use SSL or early TLS in any way to protect payment data; but if your POS (Point Of Sale) or POI (Point Of Interaction) terminals still use SSL or early TLS, but you can verify they are not susceptible to known exploits for SSL and TLS, then these terminals can continue to be used after June 30, 2016. (This exception was made because it is difficult for manufacturers to upgrade systems quickly).
Click here for useful information about migrating to the latest version of SSL / TLS.
Contact us today to discuss your requirements in more detail.
+44(0)7714 209927
+44(0)1273 329753
|
 |