Here at Kunai we see a common problem across nearly all our new clients: Trust. The current security model is simple. We trust everybody that works in IT with almost everything, and when something is sensitive we trust a somewhat smaller group of people, but we trust them individually rather than in groups or at least pairs. That’s what we mean when we tell our clients Trust no 1. Trust you IT department as an organization, but don’t place blanket trust in an individual.
This requires effort and commitment. It’s not the industry standard. Unless your company does something unusual, absolutely everything stored on the cloud or in a data center can be accessed with one identity. Someone somewhere in your IT department has access to the root credentials. If your IT team treats staff availability using the standard N+2 rule and promises 24x7x365 support at least 15 people have access to the root credentials. Compromising one of these 15 people is how the Democratic National Committee was hacked during the 2016 Elections. It’s also how Twitter’s IT department was used to read private messages on behalf of a nation state.
Filing cabinets were better
Filing cabinets had a limit on how much information they could store. That was a good thing. At best data we care about is complicated and broken up across multiple systems under different root credentials that evolved from the days of filing cabinets. With the internet and the push for consolidation, the most sensitive data is usually in just one place. That was exactly what happened to Equifax. Yes, Equifax was breached because they didn’t keep software up to date, but that wasn’t the real failure. The real failure was that they consolidated data worth 4 billion dollars all in one place, with no limit protection. If Equifax was a bank that put 4 billion dollars worth of bearer bonds all in one vault and the vault had been robbed, EFX would be at 0, but somehow they are still in business. How is that possible?
Digital assets vs digital information
There are two main reasons for this. First, digital assets and digital information are two different things. BitCoin is an example of a digital asset. It has a direct value that once exposed can be taken directly. The information itself is the thing of value and it has no other related interest or value. If I steal the password to your BitCoin wallet and then transfer your coin to a wallet I control, you’ll know it, and the value lost and gained is a simple calculation. That’s a digital asset.
Digital information is different. The value is more complicated. Let’s say I steal digital information about an earnings report a day before an earnings call and make a trade based on that information. The value lost and gained is still simple. I gained some amount of money; all the other investors lost that money. The difference is that the loss is spread out and, depending on how I conducted the trade, hidden. That obscurity makes organizations complacent when it comes to protecting sensitive information. They aren’t worried that someone in IT might be taking some of it. Even if some IT person is caught taking it they can say that they were operating at or well above the industry standards for protection of information, which brings us to the second reason…
Industry standard security is waaay too low
When it comes to protecting your data the industry standard sets the bar low. How low? At Kunai we think it’s somewhere between try not to trip over it and don’t stub your toe on it. It has holes in it you can drive a truck through. Let’s talk about a few of our favorites.
Many of the compliance standards require use of a Hardware Service Module or HSM. PCI requires this, and with good reason, but it’s not the reason you think. HSM’s are a good source for creating cryptographic materials. They are also an Ok place for storing them. They have specialized hardware that’s better than standard hardware when it comes to making keys and protecting them from external physical attack. They are like a vault with keys in them. Sounds good right? Now all we have to do to secure something is encrypt it and keep the key in that vault. That’s true, but…
The keys are managed with the data
Guess what the standard implementation that our IT departments use does with that HSM vault? It keeps the door to it open all the time and in most cases it connects that door directly to the sensitive data. This is the case with data that is stored using S3 server side encryption and similar services from other cloud providers. This is also the case for databases protected by an HSM. So great, now when a bad disk lands in a dumpster it probably won’t have the encryption keys that went with the data that’s on the disk. That’s good, but the database is still on a network. Anybody that manages anything that can access it can steal the data.
Doing it right
The right thing to do would be to separate the part of the IT department that manages the keys from the part of the IT department that processes and stores the data. Then you can force users to interact with these two separate departments to bring keys together with data. This can be done, but it is non-standard and involves writing a great deal of code.
Even if you implement this you still have another problem: All the data is being processed in one place, thus the IT department that manages that place can see all that data. They can’t cause it to be decrypted, the users do that, but once it is decrypted they could steal it. So what do you do?
Treat sensitive data like cash
If this was actually cash the answer is pretty simple and it’s implemented by every bank on the planet:
- Each bank vault has a target and a limit on the amount of cash that it holds.
- If the target amount of cash is exceeded the cash is moved to another vault.
- If the limit is reached, no more cash is placed in the vault.
- No one goes into the vault alone or without identification and authorization.
- When new vaults need to be created, they are created, etc.
This is not what’s done to secure digital information. With digital information the standards loosely suggest that this be done, but the IT departments don’t have off the shelf tools from major providers to do it so they don’t really require it. At best Kunai sees InfoSec departments make a rough calculation every once in a while for digital assets. That’s nothing like a bank, which can tell you exactly how much cash is in its vaults, who has access to it, in what quantity, at any given time.
Nothing does this off the shelf (yet)
If you want to create something like this within an IT department you are going to have to create something that isn’t off the shelf. You may face opposition from the parts of the company that are trying to implement consolidation and automation. They are trying to handle more data with less staff and less footprint. You are suggesting they intentionally shard data centers to create more of them, and you are telling them to separate responsibilities inside the IT organization.
As experts on the development of systems that securely process data, Kunai faces this challenge frequently. We could shy away from it and just do industry standard security, but we think that’s a mistake. We know from experience that it’s worth it to have solid security that treats digital information like it’s worth something. That’s what your customers expect. That’s what Kunai does. We leverage what the banking industry has learned in protecting physical assets to protect sensitive digital information properly.
Next: How Kunai solves this problem
In my next post I’m going to give you details about how Kunai likes to solve this problem. This solution works even when the attack vector is through the IT root credentials. As a preview of how Kunai does this I will tell you that all secure implementations start with a security architecture. This is the one we like to use to protect digital information:Security Architecture
It follows the basic rule stolen from bank security, Trust no 1. That means:
- Don’t keep the keys with the data.
- Know real-time who accessed what, where, when, how much it’s worth
- Don’t give root privileges for identity, encryption, or data to the same person. Keep these roles separated.
- Impose limits on automation through human authorization.
- Force end users to interact with identity, encryption, and data processing systems separately and directly.
If you want to learn more about exactly how we build this read the second article in this series: Three May Keep a Secret if Two Are Dead: Protect Sensitive Data Without Killing Your IT Staff