Security Fundamentals & the CIA Triad

What Security Actually Protects

Why Vague Definitions Fail

Ask ten people what "cybersecurity" means and you will get ten different answers, most of them vague: stopping hackers, protecting data, keeping systems safe. None of those definitions tell an engineer what to build or an analyst what to watch for.

Security is not a single property you either have or lack. It is a set of specific, sometimes competing properties that a system either preserves or fails to preserve under specific conditions. The job of a security program is to decide which properties matter for which assets, then build controls that preserve them.

Every Control Needs a Named Target

This matters because every control has a cost, and costs only make sense against a specific property being protected. Encrypting a database protects confidentiality, but it does nothing to stop someone with legitimate write access from corrupting the data, and it can even work against availability if key management fails during a recovery.

A firewall rule that blocks inbound traffic protects availability against certain floods but does nothing if the threat is an insider exfiltrating data over an already-permitted outbound channel. Without a model of what you are protecting, you cannot reason about whether a control is doing its job, whether it is redundant with another control, or whether it is protecting the wrong thing entirely.

The CIA Triad as the Answer

The CIA triad is the industry's answer to this problem. It names three properties, confidentiality, integrity, and availability, and asserts that essentially every security objective reduces to preserving one or more of them for a given asset.

It was not handed down by a single authority; it emerged over decades of information assurance practice and got formalized enough that it now appears in nearly every foundational certification and framework, from ISO 27001 to NIST SP 800-53. Its longevity is not an accident: it is simple enough to apply to a laptop or a nuclear plant, and specific enough to expose exactly what a proposed control does and does not do.

The rest of this chapter builds outward from that model. First the triad itself, in detail, with real failure examples for each property. Then two extensions that fill gaps the original triad leaves open, the Parkerian Hexad and the AAA framework. Then the vocabulary, threat, vulnerability, risk, exploit, attack surface, that every conversation about security decisions depends on. By the end you should be able to look at almost any control and say precisely what property it protects, what it costs, and what it does not cover.

The CIA Triad

Confidentiality

Confidentiality is the property that information is accessible only to those authorized to see it. A confidentiality failure does not require any data to be altered or destroyed; the information can remain perfectly intact and the system perfectly available, and confidentiality is still violated the moment an unauthorized party reads it.

A breach where an attacker exfiltrates a customer database is a pure confidentiality failure. So is an employee looking up a coworker's salary in an HR system they should not have access to, or a misconfigured cloud storage bucket left open to the public internet. Confidentiality controls include encryption at rest and in transit, access control lists, need-to-know policies, and data classification schemes that tell you what level of protection a given piece of information requires in the first place.

Integrity

Integrity is the property that information and systems remain accurate, complete, and unmodified except by authorized action. An integrity failure is about unauthorized or unintended change, not unauthorized viewing. An attacker who modifies application logs to remove evidence of their activity has committed an integrity violation, even if they never read a single byte of sensitive data.

A misconfigured backup job that silently corrupts files, a developer who accidentally pushes a bad database migration, and a man-in-the-middle attack that alters a financial transaction in transit are all integrity failures, ranging from accidental to deliberate. Controls include cryptographic hashing and digital signatures, file integrity monitoring, version control, checksums on transferred files, and write-access restrictions that limit who can modify a given resource.

Availability

Availability is the property that authorized users can access information and systems when they need to. It is the property most visible to non-security people, because its failure mode is usually immediate and obvious: the service is down.

A distributed denial-of-service attack that floods a web application until legitimate users cannot connect is the textbook availability failure. So is ransomware that encrypts production data, a hardware failure with no redundant path, or a misconfigured deployment that takes an API offline during a routine release. Availability controls include redundancy and failover architecture, capacity planning, DDoS mitigation services, backup and disaster recovery processes, and rate limiting that keeps one bad actor or one buggy client from starving everyone else.

Where They Trade Off

These three properties frequently trade off against each other, and recognizing the trade-off is part of the skill. Locking a system down so tightly that legitimate users cannot get their work done protects confidentiality at the cost of availability.

A system that logs everything in full detail for integrity and forensic purposes may create a confidentiality liability if those logs themselves contain sensitive data and are not access-controlled. There is rarely a control that maximizes all three simultaneously; mature security programs make the trade-off deliberately, based on what the specific asset actually needs, rather than defaulting to "more security" as if it were a single dial.

Beyond CIA: the Parkerian Hexad and AAA

The CIA triad is deliberately minimal, and that minimalism leaves gaps. Donn Parker proposed an extension in the late 1990s, now called the Parkerian Hexad, that adds three more properties on top of confidentiality, integrity, and availability. It is worth knowing even though it never displaced the triad as the default model, because the gaps it points at are real and come up constantly in practice.

The Parkerian Hexad's Three Additions

• Possession or control separates "who has physical or logical control of the data" from confidentiality. A laptop stolen with an encrypted disk is a possession violation, someone else now controls the device, even though confidentiality may remain intact because the data is unreadable without the key.
• Authenticity is the property that data and its claimed origin actually match. A phishing email spoofing a CEO's address is an authenticity failure distinct from confidentiality or integrity: nothing was read that shouldn't have been, nothing was altered, but the claimed source is false.
• Utility is whether the data is actually usable for its intended purpose. A ransomware note that offers a decryption key which turns out to be corrupted has restored availability, the files are there, but not utility, they cannot actually be used.

These three properties rarely get their own dedicated controls the way CIA does, but they explain edge cases that pure CIA thinking misses. Interview questions about "what security property does X violate" sometimes expect one of these answers rather than a CIA one.

Where the Parkerian Hexad extends the triad conceptually, AAA (authentication, authorization, and accounting) is the operational framework that actually enforces it day to day.

AAA: The Operational Framework

• Authentication answers "who are you," verifying an identity claim through something you know, something you have, or something you are, before anything else happens.
• Authorization answers "what are you allowed to do," applying policy to a now-verified identity to grant or deny access to a specific resource or action.
• Accounting (sometimes called auditing) answers "what did you actually do," logging actions after the fact so they can be reviewed, investigated, or used as evidence.

The relationship between AAA and CIA is direct and worth internalizing: authentication and authorization are the primary enforcement mechanisms for confidentiality, since they determine who gets to see or touch a resource in the first place. Accounting is the primary enforcement mechanism for integrity in an operational sense, because a tamper-evident audit trail is what lets you detect and attribute an unauthorized change after it happens, even if it could not be prevented.

Nearly every access-related control you will encounter for the rest of this curriculum, multi-factor authentication, role-based access control, session logging, is an implementation detail sitting somewhere inside AAA, which is itself in service of CIA.

Core Vocabulary: Threat, Vulnerability, Risk, Exploit

These four terms get used loosely in casual conversation and precisely in every framework, report, and risk register a security professional will ever touch. Getting them right is not pedantry; it changes what you communicate to leadership and what actions a document actually calls for.

Threat

A threat is any actor or event with the potential to cause harm to an asset. It can be a person, a group, or a non-human event: a ransomware gang, a malicious insider, a hurricane that takes out a data center, or a bug in a dependency that has not yet been discovered by anyone.

A threat exists independent of whether your systems can currently be harmed by it. Nation-state espionage groups are a threat to a small retail business in the abstract sense that they exist and have capability, even if that business has nothing they would realistically target.

Vulnerability

A vulnerability is a weakness in a system, process, or control that could be leveraged by a threat to cause harm. An unpatched CVE in a web server is a vulnerability. So is a weak password policy, an employee untrained on phishing, or a business process that lets a single person both request and approve a wire transfer.

A vulnerability without any corresponding threat capable of exploiting it is a much lower priority than one actively being targeted in the wild, which is why vulnerability management programs weight CVSS scores against active exploitation data rather than treating every CVE as equally urgent.

Risk and Exploit

Risk is what happens when a threat and a vulnerability meet: the potential for loss when a threat actor is capable of exploiting a specific vulnerability against a specific asset. Risk is usually expressed as some function of likelihood and impact, and it is the quantity that actually drives business decisions.

"We have a vulnerability" and "we have a critical unpatched CVE actively being exploited by ransomware crews against internet-facing servers exactly like ours" call for very different urgency even though both sentences describe the same technical flaw. An exploit is the concrete mechanism, code, technique, or sequence of actions, that a threat actor uses to actually take advantage of a vulnerability. The exploit is the realization of the risk: it is what turns "this could go wrong" into "this went wrong."

Attack Surface

Attack surface is the sum of all the points where an unauthorized actor could attempt to enter or extract data from a system, every open port, exposed API, user input field, third-party integration, and physical access point.

A larger attack surface does not by itself mean more risk, but it means more places a vulnerability could exist, which is why attack surface reduction, turning off unused services, closing unneeded ports, retiring stale accounts, is treated as a first-order control rather than an afterthought.

Defense in Depth

The Reasoning

Defense in depth is the principle that security should be built from multiple independent, overlapping layers rather than a single strong barrier. The reasoning is straightforward once you accept that every individual control can fail: a firewall rule can be misconfigured, a patch can be delayed, a user can be phished.

A single point of failure in security is exactly as dangerous as a single point of failure in any other engineered system, and the response is the same, add redundancy so that one failure does not cascade into a total compromise.

The military origin of the term is literal: rather than betting everything on one perimeter wall, a defender builds successive lines that each slow or stop an advancing attacker, buying time and reducing the odds that any single breach reaches the objective. Translated into a modern enterprise network, that becomes a stack of controls an attacker has to get through in sequence. Getting past one does not mean the attacker has won, it means they have reached the next layer, where a different kind of control is waiting.

A Layered Example

A realistic layered example for a typical corporate environment moves through five stages, each catching what the layer before it missed:

1. Perimeter firewall. Filters unwanted inbound and outbound traffic, primarily protecting availability and, to a lesser extent, confidentiality, by blocking known-bad connections before they reach anything internal.
2. Endpoint detection and response (EDR). Runs on every workstation and server behind the perimeter, protecting integrity by detecting and containing malicious code execution that got past the firewall.
3. Multi-factor authentication (MFA). Protects confidentiality on every account by making stolen credentials alone insufficient for an attacker to log in.
4. Least privilege access control. Limits what any single compromised account or process can touch, protecting confidentiality and integrity simultaneously by shrinking the blast radius of any one failure.
5. Immutable, tested backups. The last line, protecting availability and integrity: even if every earlier layer fails and data is encrypted or destroyed, the organization can restore to a known-good state rather than losing the data permanently or paying a ransom.

Why It's a System, Not a Checklist

What makes this a system rather than a checklist is that the layers are chosen to be independent of each other's failure modes. A phishing email that defeats security awareness training still has to get past EDR to execute its payload. A stolen password still has to get past MFA to be useful.

An attacker who reaches a server through an unpatched vulnerability still has to escalate past least-privilege boundaries to reach anything valuable. No single layer is trusted to hold on its own, which is precisely why defense in depth remains the default architecture recommendation across essentially every security framework, regardless of industry or company size.

What This Module Covers

Eight chapters build the vocabulary and mental models that the rest of H3AD-LEARN assumes you already have. Chapter 1 (this chapter) establishes CIA, the Parkerian Hexad, AAA, and the threat/vulnerability/risk/exploit vocabulary that every later chapter, and every other module on this platform, uses without redefining.

• Chapter 2, Authentication & Access Control: identity verification methods, RBAC versus ABAC, the principle of least privilege, and why session management is a bigger practical risk than most people assume.
• Chapter 3, Cryptography Basics: symmetric versus asymmetric encryption, hashing, digital signatures, and where each shows up in real infrastructure.
• Chapter 4, Common Attacks & the Cyber Kill Chain: the anatomy of a typical intrusion from reconnaissance to objectives.
• Chapter 5, Security Frameworks & Compliance: NIST CSF, ISO 27001, and how compliance requirements relate to, and sometimes diverge from, actual security posture.
• Chapter 6, Risk & Vulnerability Management: how organizations score, prioritize, and remediate weaknesses at scale.
• Chapter 7, Security Operations Basics: what a SOC actually does day to day, the detect-triage-respond cycle, and how alerts become incidents.
• Chapter 8, Career Paths & Your Learning Roadmap: mapping the concepts in this module onto the specialization tracks available elsewhere on this platform.

This module is the prerequisite foundation for everything else on H3AD-LEARN. Threat Hunting assumes you already know what a vulnerability and an attack surface are. Threat Intelligence assumes you can reason about threats and risk without those terms being defined again. Cloud Security and LOLBAS both assume a working knowledge of CIA and AAA to explain why a given misconfiguration or living-off-the-land technique matters. If any concept in another module feels like it is assuming prior knowledge, this is the module that supplies it.