HSMs and why being compliant is not secure

Data from companies, governments, and people are becoming less contained. You can find data from each of these on public, private and personal environments. As the data is shared across more platforms and with more people, it becomes more susceptible to breach, abuse and theft.

The conversations I usually have around these issues range from “we can trust this vendor”, to “its on their network, so they’ll look after it”, to a more considered, but still not to the point, “lets encrypt it with a Hardware Security Module (HSM) and use their bring your own key program”. All of these fail to address the general necessity to control and protect the integrity and confidentiality of the data. Integrity means that you need to preserve the data in a state where you know when and how it will change by authorized processes or people. Confidentiality means that only authenticated people or processes may access the data.

In the past, we tended not to worry too much about the finer points of the above because we thought we were safe inside our firewalls. That was hardly ever the case, and is even less so now as our firewall environments must let data flow in and out of them from authenticated and authorized sources. So, if we can’t trust even our own environment anymore, the simple, and ultimately ineffective answer to this question has been, let’s just encrypt everything with an HSM. Its FIPS 140 compliant, so nobody can complain when we tell them we used it.

The HSM has always been more of a sledgehammer approach. It is useful in a lot of situations, but usually not those we think it is. It can be very expensive, either to own yourself or “rent” in the cloud. There isn’t a regulation, specification or control that I know of that specifies using an HSM in most banking situations outside of PCI. There are many specifications (e.g. NIST) that address encryption and key management, but they do not say exactly when and how to use them. That is, as it should be, up to your risk assessment and mitigation plan. In addition, most HSM modules tend to suffer from neglect and single person points of failure. When that person leaves usually CyberSecurity has to pay a premium to resurrect access to the HSM. The only HSM that I’ve worked with that was both useful and well managed was the one on the IBM Mainframe. This was because it was maintained and managed by RACF under z/OS, i.e. integrated into the management of the entire system. So, bottom line: only use the HSM when the situation and controls warrant it, and most importantly, only when you can assure proper management of it.

Instead of making the situation fit the tool, let’s let the tool fit the situation and try to build security in. If I need to protect the integrity and confidentiality of the data, encryption is a fine tool. But, let’s be careful with how we do it, who we let access the key to unlock the data and how we manage the keys. That is the real issue: management and placement of the encryption material/key.

Keys aren’t magic. They are mathematical variables of input into a mathematical encryption equation. Because of this, they aren’t much good if they aren’t kept secret. If we spend a ton of money on an HSM to generate a key, and we just give that key to someone ( a vendor for instance ), trusting they’ll keep it safe, how have we improved security? It’s similar to buying an expensive Medeco lock with a key, and then giving that key to someone who puts it where anyone can find it. Not a solution. You haven’t really protected anything. It’s a fair supposition that if someone else in your chain of custody can get at the key, then your key management isn’t up to the task, and someone you don’t know about and is unauthorized can access the key.

What we really need to do is to generate a master key, a set of encryption keys, and then manage the access and lifecycle of those keys. This is why in most cases, for what we need to protect in Financial Institutions, a key management system is enough to implement our controls. It has most of the controls of an HSM, without the expense and overhead of a piece of hardware. But, it won’t work right either, if you don’t manage your keys correctly.

In the first case, you want absolute preventative control. You’re risk analysis has shown you that the data represents a huge amount of risk that only be mitigated in this way. That could mean that irrespective of the environment (public/private cloud, datacenter) we hold the key and serve it out on request from an authenticated and authorized application. That’s a good preventative control. If the data gets stolen, or you don’t want to use the vendor anymore, just expire the keys, and all that is left is an encrypted blob. If you are really clever, there are some systems that are fine grained enough, that you have the ability to encrypt everything even from the root user. By root user, that not only means your systems admins, but the system admins of the vendor. The root user can see that the directories and files are there and configured correctly. But, they cannot look inside and see their contents. That permission you can delegate to yourself, and by only serving out the decrytion keys to your ids, you have stopped anyone that you don’t know about from seeing and possibly changing the data. The downside of this is that you have build your key management apis into your systems, which requires a fair amount of sophistication on the part of your developers. You are also forgoing the built in key management abilities of such systems as AWS, Azure, and Google.

If your risk profile allows you to share control/substitute a number of detective controls for a preventative control, then a solution that protects the keys in a shared responsibility model is to deposit an encryption key with a vendor, on the condition that they will allow a number of compensating detective controls around the key management environment, such as logging when the keys are used, access controls around the key management modules that are transparent to you, and authentication and authorization of key managers that are also transparent and logged to you. You also want to be able to audit their environment and their choice of personnel in general. This is possible with some vendors and cloud vendors. If it is not, you are not going to have an environment that implements enough detective controls to protect the confidentiality and integrity of your data as well as pass muster with any of the auditors, regulators or compliance people.

In summary, as a famous fictional Scottish starship engineer said, “ye ken ye want the right tool for the right job.” If encryption is the tool that your controls compel you to use to migitate the risk, then do it right. Implement effective and efficient key control first. Keep control of your keys and your master key. Don’t use a sledgehammer like HSM when a scalpel will do. It will be much more efficient for you, more cost effective, and better balance of controls to mitigate your risk.