Did PCI Just Kill E-Commerce By Saying SSL is Not Sufficient For Payment Info ? (spoiler: TLS!=SSL)
The "Council's Assessor Newsletter", which is distributed by the Payment Card Industry council responsible for the PCI security standard, contained an interesting paragraph that is causing concerns among businesses that have to comply with PCI for online transactions. [1]
The paragraph affects version 3.1 of the standard. Currently, version 3.0 of the standard is in effect, and typically these point releases clarify and update the standard, but don't include completely new requirements. In short, the newsletter states that
no version of SSL meets PCI SSC's definition of "strong cryptography"
Wow. Is this the end of e-commerce as we know it? I thought SSL is (was?) THE standard to protect data on the wire. Yes, it had issues, but a well configured SSL capable web server should be able to protect data as valuable as a credit card number adequately. So what does it mean?
Not quite. You can (and should!) do https without SSL. Remember TLS? That's right: SSL is out. TLS is in. Many developers and system administrators use "SSL" and "TLS" interchangeably. SSL is not TLS. TLS is an updated version of SSL, and you should not use ANY version of SSL (SSLv3 being killed by POODLE). So what you should do is to make sure you are using TLS, and this "new" rule wont affect you at all.
Secondly, you could try to take advantage of new JavaScript APIs to encrypt the data on the client before it is ever sent to the server. This is a neat option, that is not yet available in all browsers, but something to consider in particular if you pass payment information to backend systems. In this case, you pass a public key as a JavaScript variable, and then use JavaScript on the client to encrypt the card number. Only backend systems that need to know the raw payment data will have the private key to encrypt this information.
Next: Also make sure your system administrators, and hopefully your QSAs understand that SSL != TLS and assess you correctly.
[1] https://www.darasecurity.com/article.php?id=31
Microsoft Hardens GPO by Fixing Two Serious Vulnerabilities.
Microsoft released more details about two vulnerabilities patched on Tuesday. Both patches harden Microsoft's group policy implementation. [1]
Group policy is a critical tool to manage larger networks. Not just enterprises, but also a lot of small and medium size businesses depend on group policies to implement and enforce baseline configurations. With the ability to manage systems remotely comes the risk of someone else impersonating and altering these group policies.
Windows can be configured to retrieve a remote login script whenever the user logs in. Whenever the user logs in, the system attempts to run this script, even if the system is connected to a "foreign" network (e.g. Coffee Shop, SANS Conference Hotel Network ...). The attacker could now observe these requests, and setup a server to respond to them and deliver a malicious file. The victim will (happily?) execute the file.
You would think that this should fail, as the attacker's server can not be authenticated. However, it turns out that if the client can't find a server that supports authentication, it will fall back to one that does not support any authentication mechanisms. After the patch is applied, the client will require that the server supports methods for the client to verify the server's authenticity.
The second bug patched affected systems that were not able to receive a policy, or systems that received a corrupt policy. In this case, the system would revert to a default configuration, which may not include some of the protections the actual configuration provided.
MS15-011 is a "must apply" patch for any system traveling and connecting to untrusted networks. For internal systems, this is less of a problem, but should not be ignored either as it may be used for lateral movement inside a network. But even then, the attack is more difficult as it competes with the legitimate server.
For more details, please refer to the Microsoft blog.
[1] http://blogs.technet.com/b/srd/archive/2015/02/10/ms15-011-amp-ms15-014-hardening-group-policy.aspx
Comments