Protecting Values: The Intersection of CIA and DIE in Information Security

When my article “Three Values - CIA or DIE” was published in iX at the end of May, nothing happened at first. But when the text appeared online on June 5, calls from friends and emails from readers began. The well-known blogger Fefe even dedicated one to my 5600-character article 3600 character review. “Is that a gloss or marketing bullshit?” said a comment in the heise online forum. How did I manage to catch the first shitstorm of my life? Yes, I deliberately exaggerated – but the discussion had never flown around my ears like this.

He has a weakness for risks and over-cyber-writing: In his main job as co-founder and CTO of intcube GmbH, David Fuhr rages and lets loose in this column about current incidents and universal truths of information security.

Looking back, I have to say that I made three mistakes. First, I used the pointed form of a gloss in a post that wasn’t supposed to be a column. Second, I exaggerated without a side channel that could make it clear where I’m serious and where I’m not. I’m sorry for that. And thanks for the feedback!

Values must remain!

Thirdly, I admit that this time I overdid it with the provocative shortening. For me it was not at all about getting rid of the values of confidentiality, integrity and availability: the values themselves are valuable and important, ideally complemented by others that either have to be implicit anyway (integrity without authenticity is almost always meaningless – I know that the email has not been tampered with, but I don’t know who sent it), or those that technically support other legal or ethical values, such as non-repudiation and anonymity.

It is right to protect these values. And it’s a good sign that many people see this as a mandate and maybe even an honor. What is always to be questioned is the best – and that also means the most realistic – way to achieve this noble goal. Because demanding CIA alone doesn’t change anything at first. It is similar with the pure analysis of the confidentiality, integrity and availability requirements, after all, that’s what I’ve learned from years of filling out pages and pages of CIA justification tables in security concepts. The decisive point is where something changes in the “doing”.

Let’s take the cloud. Firstly, because the topic of “values” is particularly tricky there and secondly, because an ever-increasing proportion of our data is being processed there. If you carry out a protection requirement assessment for any service, it is usually clear what will come out: Someone will put in very high protection-needy data anyway, so that we either always have to build for “very high / very high / very high” anyway, or we do as if our policies actually prevent customers from posting certain things there. How well this works can be seen particularly well with LLMs (Large Language Models).

Where I think we have leverage is when operators of large services try to make things structurally and architecturally better. The DIE model (Distributed – distributed, Immutable – immutable, Ephemeral – short-lived) was developed in 2019 by Sounil Yu, who by the way was a bank CISO at the time, not “cloud geek”. It starts from Assume Breach: the realization that all organizations will be hacked sooner or later. 100% confidentiality or availability cannot be achieved. What can be achieved is increasing resilience through distribution, detecting tampering by specifying what data should be immutable, and reducing the “blast radius” of leaks by making information as short as possible to expire.

An example: If I have a very high need for confidentiality, I try to prevent unauthorized access by taking strong measures. Assume Breach now tells me that it will come to that one day anyway. A design pattern such as Ephemeral can then ensure that the majority of the data is already worthless to the attacker at the moment the data is extracted.

THE are not alternative values that are intended to dilute the actual values, but – if applied correctly – supporting resilient design patterns, such as privacy by design must help to defend informational self-determination as a value in data protection.

Of livestock and domestic animals

Yu envisions that bulk data (cattle) can reside in the cloud and be secured with DIE, while the most valuable data (pets) remain on premises and are protected by CIA. So CIA and DIE are not intended as opposites, but complementary. However, due to the absolute and relative growth of the cloud sector, the cattle share is becoming increasingly important.

Can we get the big cloud providers not only to write DIE on their banners, but to implement them with vigour? Hopefully. Do they always do that in our mind? No. Would it be enough even if they did? No. But does it make any difference for AWS and Co. whether I put the protection requirement classes 3-2-1, 1-2-3 or 3-3-3 on my data? Not at all. So we must learn to speak the language of those who watch over the lion’s share of our data treasures, and urge them to implement the right patterns for us to protect the CIA and everything else we hold dear.