Fundamental principles of InfoSec explained using two three-letter acronyms

The internet is a dangerous place. Any server you hook up to the internet is virtually guaranteed to be targeted by attackers who are looking to steal sensitive information, install ransomware, and deface your website.

Fortunately there are all kinds of security measures that you can take to prevent that from happening. These security measures are typically based on three foundational information security principles that are collectively known as the CIA triad (side note: Not to be confused with the Central Intelligence Agency, whose goal is to secure an entire nation, or the Chinese triads, which were originally formed to overthrow the Qing Dynasty.).

CIA stands for three principles, confidentiality, integrity and availability. I’ll explain what these terms mean within the context of something we’re all familiar with: online banking.

Confidentiality is about keeping information secret from those who should not have access to it.

A bank has a lot of information on you that you’d probably want to keep private. This includes of course your personal details, but also your transaction history. No one other than you needs to know that you spend all of your disposable income on My Little Pony collectibles, OnlyFans creators, and Kentucky Fried Chicken deliveries.

Integrity is the second principle. This principle is about making sure that applications and information are always accurate and trustworthy.

The account balance of each customer is the result of a series of financial transactions. Under no circumstance should someone be able to modify those balances directly, nor should it be possible for someone else to withdraw money from your account on your behalf. Methods like hashing and digital signatures are typically used to ensure integrity of information.

The third principle, availability, is about making sure that applications or information are accessible when needed.

The best way to prevent attackers from stealing or secretly modifying sensitive data is to simply unplug the server from the internet, and maybe even turn it off. This is obviously not very helpful for customers, who want to be able to access their accounts and perform transactions at all times. You therefore want to make sure that systems have as little downtime as possible, whether it’s due to technical issues or denial-of-service attacks.

Applying the principles from the CIA triad is easier said than done. No matter how much effort you put into reducing the risk of getting hacked, eventually you’ll make a mistake (side note: Or someone else makes a mistake and it becomes a zero-day exploit in your system.) and all will have been for nothing.

So what you’ll want to do is not only reduce your risk of getting hacked, but also reduce the impact of when it does happen.

This is where the DIE model comes in. The DIE model is a relatively new concept that shifts the focus from securing data to securing the infrastructure that manages that data. The DIE model suggests that secure infrastructure should be distributed, immutable, and ephemeral, in order to limit the amount of damage that can be done by unwanted visitors.

Don’t put all your eggs in one basket. Instead, make sure that your systems are distributed. This makes it easier to scale your system to deal with unexpectedly high loads and makes it less likely that a failure in one small area brings down your entire system.

The second principle states that your infrastructure should be immutable. Have you ever been in a situation where you upgrade a package (side note: Or someone else does it for you, in the form of a backdoor or a crypto miner) and suddenly the whole system doesn’t work anymore? If you make your infrastructure immutable it becomes impossible to modify – not by you, and certainly not by an attacker.

Finally, the principle that infrastructure should be ephemeral is based on the idea that system components should have a short lifespan by design: if a component becomes compromised, you should be able to quickly dispose of it or replace it with a clean version.

If you work on cloud-native development, you’re likely already somewhat familiar with these principles, as they essentially advocate for treating (parts of) your infrastructure as “cattle” instead of “pets”. But now you know a fancy name for it!