Challenging the CIA Triad

It's healthy from time to time to challenge the things we think we know or the things we choose to believe. Today let's challenge the InfoSec CIA triad. The origins of the CIA triad are unclear but suffice to say that they have been broadly accepted as guiding tenets of information security for many decades, at least as far back as the 1970s. There have been numerous attempts over the years to evolve or supplant the triad, so far none have succeeded in gaining much traction.

So, is the CIA triad tired or tried and tested?

First of all, what it is and what it is not

The CIA triad is a set of three information security principles; the attributes of a piece of data that may be protected or compromised; Confidentiality, Integrity, and Availability. These attributes apply to the data of a system, they are not intended to apply to the things described by the data or upstream applications and utilisation of the data system, although there is inherently overlap amongst these parts. I think that this broad applicability is what makes them lasting tenets of information security. It might be that confidentiality of a given piece of data is unimportant but it is still a valid question. If we can ask a question such as "how important is this?" or "how well are we protecting this?" then the question is valid, even if the answer is zero or not-at-all.

Being able to measure, compare, and set targets in equivalent terms across disparate systems simplifies security and risk management discussions. But! tenets are foundational, they are a starting point upon which to build, they are not intended to represent the totality of information security or to constrain our thinking.

Should we consider additional attributes?

Privacy and Safety are often proposed as additions, but the problem with both terms is that they are not attributes of the data in the same way as C I and A.

Privacy applies to the entity represented by data, but only where that entity is an identifiable individual. Privacy is a human notion. If the data in question is say topographical data, it makes no sense to ask "how important is the privacy of these mountains?". The answer isn't even zero because the question makes no sense.

Similarly, Safety is a factor of the utilisation of the system in question. Using our topography example, if the application is printing tourist guide books then safety is pretty unimportant but if the application is plotting a flight path then safety becomes a little more relevant. We're not measuring the safety of the data but rather the safety of what we do with the data. In this scenario, safety is the output and is intrinsically tied to the integrity and availability of the data.

This is not to say that Privacy and Safety aren't important considerations. In many cases they are essential considerations, but they are not universal. Furthermore, they apply to whatever the data represents or what we do with the data rather than applying to the data itself and as such they are not comparative to C I and A.

Non-repudiation has also been touted for inclusion, often with reference to ISO27001 and Information Assurance. Non-repudiation is the notion that a person cannot refute having done a thing; it is the intersection of integrity of transactional records and authentication. It only applies to transactional records, while authentication is a countermeasure (control, protection). Clearly then non-repudiation, while important in some scenarios, is also not comparative to C I and A.

At the same time, we can conclude that Authentication is not comparative in being a countermeasure rather than an attribute of the data that it is intended to protect.

Parkerian Hexad

The Parkerian Hexad proposes to add Authenticity, Possession, and Utility to the triad.

In order to assert a lack of corruption you must first be able to refer to a sufficiently reliable origin. You can't have integrity without authenticity, but it is possible to assert the authenticity of data without latterly maintaining its integrity. As such, authenticity is a subset of integrity.

Data being in the possession of an unauthorised person is a breach of confidentiality. You can't have confidentiality without control of possession, but it is possible to identify possession of data without recognising authorisation for access. As such, possession is a subset of confidentiality.

If data has been altered in such a way that it is not usable then it is not available for its intended purpose, but there are other ways in which availability may be impacted. As such, utility is a subset of availability.

In each case, the additional term is merely a more granular element of the established triad. The Parkerian Hexad adds unnecessary complexity rather than additional distinct attributes that can be measured and rated in equivalent terms.

DIE model

Distributed, Immutable, Ephemeral. CIA and DIE are more complimentary that contradictory, but they do not deliver the same objectives.

The idea is that a distributed system is inherently available, but as we see with Utility above, Availability is multi-faceted so merely being distributed might not be enough to ensure availability. Conversely, a centralised system might be sufficiently available for its intended purpose.

The idea of immutability is that if data cannot be changed then concerns of integrity become moot. However, in many systems data needs to be changed over time so immutability is not equivalent to integrity. One might argue that a change to data creates new immutable data with immutable transactional records and pointers between old and new. That's a convoluted way to make immutable mean the same thing as integrity while undermining the intent of immutability.

The idea behind ephemeral is that data exists only for only a short period making it more difficult to compromise confidentiality, but that doesn't work for any system where data needs to exist for a prolonged period. Even if your processing systems are spun up and destroyed ad-hoc, the data must exist somewhere to be pulled into that ephemeral system on demand.

The DIE model might be an aid in designing cloud-based systems to be resilient, but the CIA triad operates in a much broader space.

Is there any way to improve upon the CIA triad?

When threat modelling a system I'll typically consider three aspects of the system: storage, transmission, and processing/access. These are the three aspects where an attacker might target a system or where a weakness or error might manifest. As with CIA they are pretty universal in that almost every information system can be described in terms of these three aspects, data exists in each of these three states to varying degrees.

When seeking to protect a system a common trope is People, Process, Technology. That is, make sure the people using a system understand their duties, make sure that a system is well-defined and operating effectively (policy and practice), and make sure that a system's security incorporates the right tools.

If we were to combine these three facets then we are in effect asking: What do we need to protect? Where do we need to protect it? How are we protecting it? If we are able to demonstrate that we've considered each intersection of this 3x3x3 matrix then we're off to a pretty good start in securing a system.

Does it still satisfy the objective of being an information security tenet? I think it does. Each intersection is a valid question against any information system (remember, zero is a valid answer to a valid question, null is not).

It turns out someone else came to this conclusion back in 1991 when John McCumber published his McCumber Cube. Turns out I've been using this idea for several years without realising it's an established model!

So what are your thoughts? Are there additional attributes that we should consider and which are equivalent to C I and A in terms of applicability? Have you come across the McCumber Cube? Are there other facets that we might seek to incorporate?