What Are The Fundamental Services Provided By Security? Hint: CIA Is Not The Answer

The CIA Triad Is Dangerously Obsolete and Incomplete

14 min readMar 24, 2020

The CIA Triad (Confidentiality, Integrity, Availability) purports to define the services that are provided by security to defend against threats to an asset being secured. Yet, it only provides defenses for three of the seven widely-recognized categories of security threats. An incomplete definition of the security’s fundamental services means we are also dangerously incomplete in the proper securing of our assets.

A New Security Model Is Required!

Any model that defines the fundamental services provided by security must be both clear and complete. Complete, in that it addresses all possible threats against security. Clear, in that it is intuitively obvious to the most casual of observers which service defends against which threat or threats.

Clarity also requires that each service has clearly-defined defense mechanisms. It is unacceptable to leave it ambiguous, where under certain circumstances, one defense mechanism may be required, but under a slightly different circumstance, an entirely different mechanism is required. Such circumstances easily lead to both mistakes and gaps in security.

Any security model must provide a complete set of security services and be applicable to all types of assets being secured, including, but not limited to: digital, physical, and human assets. It also must be applicable to physical, information, and cyber security environments, and preferably, applicable to security in general.

The CIA Triad purports to define all the services that are provided by security to defend against all the possible threats to any asset being secured. It has been the central tenant of security mantras since at least the 1970s. It has become almost like a religion, and to disagree with it, many consider tantamount to heresy.

Well, consider it blasphemy, but The CIA Triad is wrong! It fails both the clarity and completeness requirements for a viable security model. As the most central tenant of security, it is so incomplete that, if followed, it leaves serious security gaps unaddressed. Worse, it is based on reasoning that has been considered obsolete since at least the mid-1980s.

What makes the CIA Triad obsolete and incomplete? It is obsolete because it is information security–centric, and it only considers there to be three categories of threats against security, and which only require three services to defend against those threats. By only considering three of the seven generally recognized categories of threats that must be addressed by security, and only addressing three of the five generally recognized categories of security services, it leaves the CIA Triad incomplete as well.

Any viable security model that purports to specify the services that are provided by security must recognize all categories of security threats. The seven widely-recognized categories of security threats are:

Denial of Authorized Access: The category of security threats where authorized access to a protected asset is denied. (This is the proper name for this security threat. In the information security–centric world, it is often — and, improperly — referred to as “Denial of Service.”)
Forgery: The category of security threats where fraudulent information is used in an attempt to bypass security defenses.
Repudiation: The category of security threats where the origin and/or integrity of an asset is disputed (where “disputed” includes failed digital verification tests).
Spoofing: The category of security threats where an entity masquerades as a different entity in an attempt to bypass security defenses.
Unauthorized access: The category of security threats where access of a protected asset not explicitly authorized is attempted.
Unauthorized disclosure: The category of security threats where a revelation related to a protected asset not explicitly authorized is attempted.
Unauthorized modification: The category of security threats where a change to a protected asset not explicitly authorized is attempted.

The CIA Triad only specifies services that defend against the following security threats:

Confidentiality: The security service which defends against the security threat of unauthorized disclosure of a protected asset.
Integrity: The security service which defends against the security threat of unauthorized modification of a protected asset.
Availability: The security service which defends against the security threat of denial of authorized access of a protected asset.

Missing from the CIA Triad are defenses against the security threats of spoofing, forgery, repudiation, and unauthorized access. By adding two additional services to the list of services provided by security, we can overcome these shortcomings. Thus, we add:

Authenticity: The security service which defends against the inauthenticity security threats of forgery, spoofing, and repudiation; that is, the protection of a protected asset from attacks against its provenance and integrity. [See note 1.]
Access-Control: The security service which defends against the security threat of unauthorized access of a protected asset. [2]

This gives us CIA³, which defines five security services that defend against the seven categories of security threats.

Okay, I can already hear the complaint, “Authenticity and access-control are aspects of integrity.” No, they are not aspects of integrity — for two reasons: First, authenticity and access-control defend against attacks other than unauthorized modification; Second, authenticity and access-control have different defenses than integrity.

If you look at how defenses against threats are implemented, then the differentiation becomes clear. For example, consider threats against digital assets: cryptography can provide direct defenses for five of the seven security threats, and a mix of cryptographic services can be used in various aspects of defense for a sixth service. However, cryptography cannot do anything to protect against denial of authorized access. So, for each threat against a digital asset, what are its cryptographic defenses?

Unauthorized Disclosure: Encryption
Unauthorized Modification: Hashing
Denial of Authorized Access: (usually requires non-cryptographic defenses)
Spoofing: Digital Signatures
Forgery: Digital Signatures
Repudiation: Digital Signatures
Unauthorized Access: Encryption, Hashing, Digital Signatures (and non-cryptographic defenses)

These defenses against security threats clearly show there are five aspects to security, and that authenticity and access-control are different from integrity. And, it shows that the same defenses apply to all inauthenticity security threats (spoofing, forgery, and repudiation).

The examples below should help clarify that authenticity and access-control differ from integrity, and that they are necessary to provide both clarity and completeness to our security model.

Examples

Database Defense

The four possible accesses to data are defined by the CRUD model: create, read, update, and delete. Creation and deletion of records in a database are attacks against the database itself, whereas read and update are attacks against individual records in the database. If we use cryptographic defenses to protect the data, we would create “keyed hashes” (HMACs) for each record in the database. An HMAC could also theoretically protect the database itself — but, would be impractical, as every change to the database would require the entire database to be rehashed.

Now let’s examine how to defend the integrity of data records against attack in each type of access:

Create new record: Unauthorized addition of records to a database should be detectable because, unless the attacker had access to the secret key used to create HMACs, any new records added to the database would not have valid HMACs.
Read existing record: The validity of a record can be checked by comparing the recorded HMAC to the computation of an HMAC for that data record.
Update existing record: This is the same case as creating a new record: without access to the secret key used to sign the hash, an updated record would not have a valid HMAC.
Delete existing record: Uh, gee. We have no cryptographic defense against deleting records!

From this gap, it is clear that we have two security issues that must be addressed: protection against unauthorized modifications of data records and protection against unauthorized accesses to the database. This means we have two categories of threats, requiring two different security services. HMACs provide defenses against unauthorized data modification, but they do not protect against unauthorized access.

Clearly, access-control defenses are also required to completely protect our database. Let’s examine a full defense of our database and its records:

Create new record: HMACs provide data record validity defenses, but access-control defenses are required to protect against the unauthorized creation of new records in the database.
Read existing record: HMACs provide data record validity defenses, but access-control defenses are required to protect against unauthorized access of existing records in the database.
Update existing record: This is the same case as creating a new record, except access-control now provides defenses against both unauthorized reads and writes (updates) to the database.
Delete existing record: Access-control is the only defense against unauthorized deletion of records in the database.

Clearly, both HMACs and access-control mechanisms are required to protect the integrity of the database and its data records. But, they are actually different and separate security services: one (HMACs) defending against unauthorized modification, and the other (access-control) defending against unauthorized access. The next example should make this differentiation clearer.

Physical and Human Asset Security

Bob works at a company that has a mandatory vacation policy. Bob does not hold a key position in the company, so mandatory vacations are not viewed as a security control in his case, rather vacations are viewed as a quality-of-life policy. During mandatory vacations, employees are not permitted access to any company asset, including email, messaging, and company facilities.

So, what category of security threat must we defend against here? Clearly, this is not a threat against unauthorized modification, unauthorized disclosure, or any other category of security threat except for unauthorized access. In this case, we are not worried about Bob creating a threat against anything confidential, Bob attacking the integrity of any asset, or Bob denying access to some asset.

Conversely, we want to deny Bob access to something! Thus, we obviously need an access-control security service. And, it is the access-control service that is what defends against Bob having access to company resources during his vacation.

Thus, there is a clear differentiation between integrity and access-control! And, this is only one of many examples where access-control differs from integrity and the other traditional security services.

Document Provenance

In this example, we have a document that claims Alice as its author. But, Alice denies she is the author. In other words, Alice repudiates authorship of the document.

If we look at the original CIA Triad, what service defends against the attack of repudiation? It is clearly not an issue of confidentiality, as the document is not one being protected against unauthorized disclosure. It is not an attack against availability, as the document is clearly available. And, it is not an attack against integrity, as no one is saying the document has been modified — or, for that matter, that it is a forgery. All that is in question is its authorship.

Thus, this is an attack against origin: we cannot verify the document’s provenance. This is a case where we must defend against repudiation, and that requires a service that can verify the document’s authenticity. Again, we are not claiming this document is a forgery, just that its origin is in dispute.

Here, we clearly need an authenticity security service. That authenticity security service would handle not only repudiation, but also forgery and spoofing as well.

Again, none of these security threats are addressed by the CIA Triad.

Overflow and Spray Attacks Against Software

Overflow and spray attacks attempt to modify an application’s memory space to cause the execution of arbitrary code of the attacker’s choosing. At first glance, these appear to be attacks against integrity, as the application’s memory space is undergoing unauthorized modification.

The standard defense against an attack on integrity would be to “hash something” in order to be able to detect the attack. For example, theoretically, we could detect a stack overflow attack by hashing EIP or ESP in an x86_64-based application, but the overhead required for hashing would make such an approach impractical. (A logically similar concept of “canaries” is a more practical approach, but not as foolproof.)

There have been a lot of different “integrity” approaches to solving memory corruption attacks. ASLR and canaries have been among the most visible approaches. However, none of these approaches, which attempt to limit the effectiveness of modifying an application’s memory space, are foolproof and are often trivial to bypass for an experienced attacker.

So, why do our attempts to protect the integrity of an application’s memory space so often fail? Well, if we look more closely at the problem, we quickly discover that we don’t actually have an integrity problem — integrity is simply the visible symptom of a problem that is most readily observable — but what we really have is an access-control problem.

Application memory space in most modern processors is typically divided into four distinct blocks: Text (static program instructions), Data (initialized and uninitialized program variables), Heap (dynamically allocated memory), and Stack (data and control for function calls). If we examine how we should secure each block, it is obvious that we need to execute code in the Text block but do not want it to be modifiable; for the Data, Heap, and Stack blocks, we want them to be modifiable, but we do not want code written to them to be executable.

Most modern processors provide half the access control measures required to implement such protections: they provide the ability to prevent execution in a given memory space, but they cannot prevent overwriting code segments. Intel and AMD processors are typical in that they simply support a “no execute” bit that prevents code from executing in memory segments so marked. (What is needed are processors that follow the old SPARC processor memory model, where there were three bits controlling memory access: Read, Write, and Execute. If all processors supported such a memory management scheme, memory corruption prevention could be fully implemented in hardware.)

So, upon closer examination, it is obvious that the real security threat is unauthorized access of memory segments, not the unauthorized modification of memory, and that the unauthorized modification of memory occurred as the result of a failure in our access-control measures. Unfortunately, we have no proper solutions to this problem — only a series of kludges to try to work around limitations in our hardware.

If we want to be honest, that is not the entire extent of the problem. Here’s why.

All modern operating systems support hardware-based execution protection schemes. However, poorly written software often prevents the implementation of even these minimal protection measures. Why? Too many programs generate and execute in-memory code; thus, enabling execution protection (e.g., Intel NX-bit) breaks all software that dynamically generates and executes code.

To summarize the problem: memory corruption attacks appear at first glance to be integrity attacks, but are actually access-control attacks. Unfortunately, due to both hardware and application software limitations, we are not able to effectively implement proper security controls to mitigate such attacks fully.

Once again, we have a clear differentiation between integrity and access-control, showing that they are separate security services.

Reverse Engineering

Eve wants to find a way to hack a popular web security camera. Her first step is to open the casing on the device and examine the circuit board. She quickly discovers a UART header still in place on the board, so she attaches a cable to it and to her computer. She immediately discovers she gets a “root” shell prompt from the connection — no authentication required. Thus, she now has full access to everything on that device.

With a little probing, she discovers a process listening on a high UDP port. Examining the process in a debugger, Eve discovers that this process is a backdoor into the camera, and that she can send two different specially crafted packets to this backdoor: one will start a TFTP process which can be used to upload code to the camera, and the other will open a reverse root shell back to her computer.

Since most consumer-grade firewalls do not filter high-port UDP traffic, Eve’s discovery means that she can now take control of virtually every one of these cameras anywhere on the Internet — potentially hundreds of thousands to millions of devices.

So, how do you characterize this attack? Well, it is not an attack against the device’s integrity, because Eve isn’t making any changes to the camera — well, at least not until Eve starts installing and running her own software on it. Availability is not compromised, as even if Eve hacks into every camera on the Internet, unless her actions interfere with the camera’s ability to work as a security camera, her actions are not an attack on availability. Eve could be considered attacking confidentiality if she intercepted the camera’s audio/video stream, but if she does not hijack the audio/video stream, there is no breach of confidentiality here.

This camera obviously has many security flaws. However, the one most blatant flaw is the lack of authentication on the internal serial port, which is what allowed Eve access to the internal workings of the camera. Without that access, it would have been highly unlikely that she would have discovered the backdoor into the camera, and far less likely that she would have been able to figure out how to exploit it.

Thus, this entire attack is an attack against access-control, and another example where the traditional CIA Triad fails us.

(As a side note, I should add that if this camera had been designed properly from a security perspective, it would have had authentication on the serial port and no backdoor. It would also have had fusible connectors on both the UART and JTAG pins which, after manufacturing tests, would have been blown, thus preventing any reverse engineering of the device at the hardware-debugger level.)

Replay Attack

Eve knows that Alice is in regular communications with an unknown party we’ll call Bob. She wants to discover who Bob is. So, she has been capturing Alice’s encrypted network traffic.

Eve notices that Alice sends a consistent-length encrypted message two or three times a week. And, later that evening, she always goes to a particular coffee shop. Eve isn’t certain whom Alice is meeting at the coffee shop, as she interacts with several people while she is there.

In an attempt to discover who is Bob, Eve decides to resend Alice’s last message. She then goes to the coffee shop and watches for anyone familiar to show up. That evening, she observes only one individual who was also there when Alice sent the actual message. Furthermore, he looks like he is waiting for someone. After an hour, her suspect leaves without interacting with anyone. Eve knows she has most likely found Bob.

This replay attack is an example of spoofing, where Eve is masquerading as Alice. Thus, this is an attack against authenticity. (Since Eve didn’t modify Alice’s message, this isn’t an attack against integrity, and since she didn’t break the encryption, it isn’t an attack against confidentiality either.)

What allowed this attack to succeed is that Alice lacked any replay defenses in her messaging system. So, Bob had no way of knowing this was a repeat of a previous message.

Again, our traditional CIA Triad fails us, as it offers no protection against authenticity attacks.

Examples Wrap-Up

I could easily provide dozens more examples that differentiate integrity from authenticity and access-control. But, from these examples, it should be clear that there are obvious differences between integrity and authenticity, and integrity and access-control.

Unquestionably, these examples illustrate that there are critical security gaps not covered by the traditional CIA Triad.

Thus, there is an absolute necessity that authenticity and access-control become a part of our fundamental security services model, in addition to confidentiality, integrity, and availability.

Summary

There are five fundamental security services (CIA³) which defend against seven classes of security threats:

Confidentiality, which defends against unauthorized disclosure of a protected asset.
Integrity, which defends against unauthorized modification of a protected asset.
Availability, which defends against denial of authorized access to a protected asset.
Authenticity, which defends against spoofing, forgery, and repudiation (inauthenticity attacks) of a protected asset.
Access–Control, which defends against unauthorized access of a protected asset.

Call me a heretic and blasphemer of the standard security mantra, but I rest my case.

Oh, you should also quit thinking of security as a religion with blessed tenants that are immutable. (Clue: It isn’t, and they aren’t.)

Notes

Forgery, spoofing, and repudiation are all forms of inauthenticity. They are explicitly specified as threats against authenticity for completeness and clarity. Yes, authenticity could be defined as defending against inauthenticity, but that definition would not be as clear as one that explicitly stated the categories of threats that constitute inauthenticity.
Access-Control is discussed in more detail in the blog entry: AAA Is Missing An “I” and an “A” (coming soon!).

Please check out my Blog Introduction and Index to find other postings about what we are doing wrong in security and how we need to fix it.

About The Blogger

Featured Image