Have you heard of PCI DSS v3.1? Its coming soon and the big change is the NO SSL ALLOWED requirement.
Excerpt from the Council’s Feb 13 2015 bulletin:
The National Institute of Standards and Technology (NIST) has identified the Secure Socket Layers (SSL) v3.0 protocol (a cryptographic protocol designed to provide secure communications over a computer network) as no longer being acceptable for protection of data due to inherent weaknesses within the protocol. Because of these weaknesses, no version of SSL meets PCI SSC’s definition of “strong cryptography,” and revisions to the PCI Data Security Standard (PCI DSS) and the Payment Application Data Security Standard (PA-DSS) are necessary.
the Council will soon publish PCI DSS v3.1 and PA-DSS v3.1 to address this issue and provide other minor updates and clarifications.
When published, PCI DSS v3.1 will be effective immediately, but impacted requirements will be future-dated to allow organizations time to implement the changes. For PA-DSS v3.1, the Council is also looking at how to address both future submissions and currently listed applications.
Strong Encryption for Transmitted CHD
The term “strong encryption” occurs in several different PCI DSS requirements. (including 3.4 which is about storage, not transmission, so we will not discuss it here). The transmission of CHD over open public networks requires the use of strong cryptography in requirement 4.1
4.1 Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks…
Examples of open, public networks include but are not limited to:
• The Internet
• Wireless technologies, including 802.11 and Bluetooth
• Cellular technologies, for example, Global System for Mobile communications (GSM), Code division multiple access (CDMA)
• General Packet Radio Service (GPRS)
• Satellite communications
4.1.a Identify all locations where cardholder data is transmitted or received over open, public networks. Examine documented standards and compare to system configurations to verify the use of security protocols and strong cryptography for all locations.
4.2.a If end-user messaging technologies are used to send cardholder data, observe processes for sending PAN and examine a sample of outbound transmissions as they occur to verify that PAN is rendered unreadable or secured with strong cryptography whenever it is sent via end-user messaging technologies.
What kinds of devices/applications are we transmitting CHD over open public networks with? Webservers, loadbalancers and application servers for the majority. (Am I missing anything?) Hopefully there aren’t too many of these devices out there where a supported version does not support TLS (and disabling SSL!). And if you are running unsupported kit on the internet, you probably aren’t passing your ASV scans anyway. I don’t see much impact of the new SSL ban for these CHD transmission requirements.
The Real Impact of PCI DSS v3.1
Other than transmission of CHD, administrative access and password transmission must use “strong encryption” too (Req 2.3 and 8.2.1). What will this include? Quite likely things like:
- ldap servers for authentication (ldap with TLS)
- TN3270 terminal emulation (got a mainframe?)
- Proprietary fat client administrative access to network devices, appliances, printers, storage systems, and lots more.
- web interfaces of network devices, security appliances, storage systems, and lots more.
Consult your CDE asset list for more examples! Hopefully support for TLS won’t be an issue on these platforms, but potentially disabling SSL to prevent fallback attacks will be. Just when we finally appear to have the universal ability to disable telnet!
Might want to tune your internal vulnerability scanners to check for internal services that offer SSL V3 (or 2) on any port (389, 636, 443, etc).
I would love to hear about equipment on your CDE asset list where SSL can not be disabled.
2.3 Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access.
2.3.c Observe an administrator log on to each system to verify that administrator access to any web-based management interfaces is encrypted with strong cryptography.
2.3.d Examine vendor documentation and interview personnel to verify that strong cryptography for the technology in use is implemented according to industry best practices and/or vendor recommendations.
8.2.1 Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components.
8.2.1.a Examine vendor documentation and system configuration settings to verify that passwords are protected with strong cryptography during transmission and storage.
Ad below this line: