Trustwave’s revelation that it has issued a digital certificate that allowed a private company to spy on SSL-protected connections within a data loss prevention (DLP) system comes hot on the heels of VeriSign’s disclosure of breaches last week. Unfortunately this is meat and drink for the ‘SSL bashers’ in the industry.
Trustwave should be commended for making this statement public, knowing that this could result in reputational damage. I believe it is commendable that they will no longer continue this practice, but the reality is, in my opinion, that this is a common industry practice.
Most large enterprises use this approach to be able to monitor outgoing and incoming traffic, and it is common to find an assortment of technologies between a user and a web service such as DLP, Performance Monitoring, and Customer Experience Monitoring technologies, which are there ostensibly to help provide users and customers’ with more efficient services.
An analogy would be that when we call a help desk for a bank or an airline, we are frequently greeted with the message that our call may be monitored and recorded to help improve customer services – we find this quite acceptable. The fact that businesses do the same for internet traffic is therefore understandable.
So in order for a business to improve services and customer experience, they frequently need to “record” what is happening. Yet if this data is encrypted, then this becomes impossible. The solution adopted by many is to decrypt and re-encrypt at each “checkpoint” and –to provide a customer with a seamless service –they will use the same SSL certificate and shared private key throughout the network. Perception is that this eases the operational burden, though in reality it opens up the company to significant security risks.
Without knowing all the details of how Trustwave managed this with their client the challenge is how do you actually control this in practice. To their credit they state that the “certificate was subject to a Certification Practice Statement (CPS), Subscriber Agreement and Relying Party Agreement crafted by Trustwave, after an audit of the customer’s physical security, network security, and security policies.
In the vast majority of enterprises today, there is little or no control over the security and management of private keys. Little thought is given to how keys are protected against loss, misuse or theft, and these are important questions given that, according to a recent report from Gartner, the majority of data breaches are executed from inside organisations.
In most cases, the private keys are not being protected, and system administrators are handling keys manually. This in turn exposes organisations and users to a host of security vulnerabilities, either because the administrators are not following best practices or because they have malicious intent.
In fact, in spite of best-practice suggestions and specific key management requirements, private encryption keys are not well protected. They are not protected from lax distribution processes or poor and infrequent keystore password rotation practices — and are frequently protected with the same password across hundreds of administrative keystores.
Administrators also often have direct access to the keystore(s) and duplicate the keys in them for distribution. They also reuse them on other systems and applications throughout the infrastructure. These keys—shared by all and protected by none—are, in essence, the keys to the kingdom. With them, an insider with privileged keystore access can, working alone or with an outside hacker, gain access to the protected data or even to the authentication (user name and password) information meant to secure it.
Manually managing private keys invariably introduces additional custodians who, in order to perform their administrative functions require access to the private key(s). In most cases, these administrators have direct keystore access and can make duplicate copies of the keys. These are the same keys that are used to decrypt the data they protect. Thus, it is crucial that processes are implemented to ensure administrators are not able to copy the keys.
This is a common scenario in most organisations and raises the security exposure from increased and non-monitored access to the keys. It would be interesting to know how many other CAs are issuing certificates of the type that Trustwave have just stopped issuing. And just because Trustwave have not issued such a certificate “to a ‘government’, ‘ISP’ or to ‘law enforcement’” agency, does not mean this hasn’t been done. Maybe it’s time websites carried the same message as the telephone service; “this session may be recorded!”.
Ultimately if an organisation needs to be able to “listen” to traffic, then they need to ensure that they are able to audit the practices in their organisations, and to automate the management of keys and certificates as much as possible, to eliminate the risks associated with mismanagement and malicious activity. They also need to avoid using CAs who may not be quite as honest as Trustwave, especially ones you may never have heard of! And what about all these far flung Managed Service Providers? What certificates are they using? It doesn’t bear thinking about”!