The Answer Is Not 42 … It’s Zero (Trust)
The Answer Is Not 42 … It’s Zero (Trust)
Kerckhoff’s principle, No more leaky buckets and Defending on multiple fronts
When was the last time you asked someone for directions, and they replied with, “Oh, well, I wouldn’t start from here!”?
The problem
And, so, if we started again with our cybersecurity infrastructures, we certainly wouldn’t start from where we are. Overall, we often have hybrid and legacy systems, and where there’s not too much we can fix on our flawed approaches. A “let’s start again” approach is never going to be popular with the CEO. We have thus scaled from small-scale desktops on local networks to running our applications and services in the cloud. Also, we have increasenly brought in third-party services to perform trusted operations.
Our role-based approaches, too, are often based on 20th Century methods, that have scaled into the cloud. And, finally, our usage of encryption and proper digital trust is often patchy, and either too localized or too generalised. In some systems, its almost as if encryption and digital signing were never actually invented, and are red flags to the development team.
All of these problems have scaled our small-scale networks of the 1980s into our modern cloud-based infrastructure — but often little has changed about the core implementation of cybersecurity. And, when it comes to multifactor authentication, we often have a sticking plaster approach that does scale well into our application and data infrastructures. And, when it comes to resilience and data backup, we still often backup everything and leave our secrets alongside our non-secrets.
Towards a perfect state
But, this shouldn’t stop us from trying to move toward a perfect state. And that perfect state would be one where we could properly extract all of the secrets in the system into a secure (and highly guarded) place and left everything else out in a state where it wouldn’t matter if someone managed to get access to our system.
With your car, you leave it in a public space, and where you keep the keys to your car in a secret place. So while these keys stop your car from being stolen, someone could still break into your car and steal its contents, and so, again, you might make sure that the contents are locked up with a key that you have.
Kerckhoff’s principle
The way we often still design our systems is to simplify the setup by defining zones of trust:
This type of security design goes back to the days when we had DMZs (demilitarized zones), and where we created a security gap between each of the zones. Unfortunately, these days, this type of approach does not work. First, if an intruder gets into the trusted area, they can then have the rights to enact to view and change the system, and the second is that it is almost impossible to apply this approach to every type of system within the infrastructure. The last major problem is that this type of infrastructure works for our networks, but does not work for our applications and services. Overall, this type of approach does not scale well into a public cloud infrastructure.
In a perfect cybersecurity world, our systems would abide by Kerckhoff’s principle:
A [cryptographic system] should be designed to be secure, even if all its details, except for the [key], are publicly known.
We could write this in a more general form as:
A [data, network and compute infrastructure] should be designed to be secure, even if all its details, except for the [secret], are publicly known.
And this is how we should design our systems to be secure, and where we move all the secrets away into a highly secure area, and leave everything else in a place where it would matter if someone had access to our systems. Of course, we should always lock down access to our systems and data, but the actual secrets are distilled out of the infrastructure. In this way, we now guard the place where the secrets are stored. This becomes an easier task, as we are not fighting on multiple fronts.
Distilling out the secrets
In Figure 2, we have now distilled out all the secrets in the system and placed them in a highly secure area. This area can then be guarded and logged (and securely backed up, of course). All of the areas in the system can then be protected with access control and security barriers. Each encryption key used for data is then defined with application keys, and which are uniquely generated for each data object, and which the application key is then encrypted with a root key — this is known as envelope encryption. Without the root key, the application keys cannot be revealed. The access to application keys is then controlled in our normal access control rights, but the access to the root keys is strictly controlled and locked down to trusted entities. No one in the organisation should have access to the keys stored in the highly secure area.
100% Public Cloud
There’s a misconception with the public cloud that you cannot have any real security, as your cloud provider has access to anything, and that your administrators can see everything. This is not the case, as the Cloud provider normally provides three ways of storing encryption keys: Cloud provider managed (using the keys of the Cloud provider); managed in a secure enclave; and bring-your-own-enclave. In AWS, we have the Key Management System (KMS), and where keys and secure processing can be held and conducted in a secure space (Figure 3). This is implemented within a FIPS140–2 compliant HSM (Hardware Security Module).
With the HSM we can guard our secrets, and conduct the decryption of the application keys and perform digital signing with the stored private keys. This key store can then have extensive logging applied, so that every access is monitored and where alerts and alarms are triggered.
Conclusions
The latest announcement that AWS will encrypt S3 buckets — often the leakiest of all the data stores — by default, shows the way that the industry is going — and where it is the Cloud providers who are forcing their customers to encrypt their data. And, so, now we could have data systems that are actually more secure than unencrypted on-premise data stores.
I know we have legacy systems, but it should stop us from focusing on Kerckhoff’s principle, and where we distill out the secrets that reveal things and place them somewhere we can protect. Like an army, you often limit the fronts that you defend on and concentrate your resources on them. So, zero is the answer.
So:
A [data, network and compute infrastructure] should be designed to be secure, even if all its details, except for the [secret], are publicly known.