What the CIA Triad Is and Why It Matters
The CIA triad is the foundation of information security. It names the three things every security control ultimately protects: Confidentiality, Integrity, and Availability. When you analyze a threat, a breach, or a new system, the first question a security professional asks is which leg of the triad it affects. A stolen password threatens confidentiality. A forged transaction threatens integrity. A ransomware outage threatens availability. Naming the leg tells you what you are defending and which controls belong in the conversation. No real system maximizes all three at once. They trade off against each other, and good security means balancing them for the value of the asset. A public news site cares most about availability and integrity. A hospital's patient records care most about confidentiality. Your job is to protect the right leg for the right asset.
Remember it as three questions
For any asset, ask: Can only the right people read it? (Confidentiality) Is it unchanged and trustworthy? (Integrity) Is it there when I need it? (Availability) Every security control you will ever meet exists to protect at least one of these three.
The three legs pull against each other
Strengthening one leg can weaken another, so security is a balancing act, not a checklist. Encrypting everything (confidentiality) can slow a system down (availability). Locking an account after five bad passwords protects confidentiality, but an attacker who deliberately types wrong passwords can lock out the real user, turning a confidentiality control into a loss of availability. Always ask what a control costs the other two legs.
Confidentiality: Only the Right People Can Read It
Confidentiality means information is disclosed only to the people and systems authorized to see it, and to no one else. It is what most people mean by keeping data private. In practice it is enforced by two ideas working together: encryption (scrambling data so an intercepted copy is useless without the key) and access control (making sure only the right identities can reach the data in the first place). Data classification, labeling data as public, internal, confidential, or restricted, decides how much protection each piece needs.
| Threat | Example | Control that defends it |
|---|---|---|
| Eavesdropping / packet sniffing | An attacker on public Wi-Fi reads unencrypted HTTP traffic | Encrypt in transit with TLS (HTTPS) |
| Stolen device or data breach | A lost laptop has an unencrypted hard drive | Full-disk encryption (BitLocker, LUKS), encryption at rest |
| Weak or reused passwords | Credential stuffing unlocks an account | Strong unique passwords plus multi-factor authentication |
| Shoulder surfing / oversharing | Someone reads a PIN over your shoulder | Privacy screens, screen locks, least privilege |
| Misconfigured access | A public cloud bucket exposes customer records | Access controls, data classification, default-deny permissions |
Two places data must be protected
In transit is data moving across a network, protected by TLS, the S in HTTPS. At rest is data sitting on a disk or in a database, protected by full-disk or database encryption such as AES. A site can encrypt in transit but still store data in plaintext, or the reverse. Strong confidentiality needs both.
Integrity: The Data Is Trustworthy and Unchanged
Integrity means data is accurate, complete, and has not been altered by an unauthorized party, and that if it is changed you can detect it. Confidentiality asks who can read the data. Integrity asks whether you can trust that it is exactly what it should be. The core tool is the cryptographic hash: running a file through an algorithm like SHA-256 produces a fixed-length fingerprint that changes completely if even one byte changes. Pair a hash with a digital signature and you can also prove who produced the data, not just that it is unmodified.
| Threat | Example | Control that defends it |
|---|---|---|
| Tampering / unauthorized edit | An attacker changes the amount on a bank transfer | Hashing (SHA-256) plus digital signatures |
| Man-in-the-middle or malicious mirror | A tampered mirror swaps in a trojaned download | HTTPS plus verifying the published checksum or signature |
| Accidental corruption | A failing disk flips bits in a stored file | Checksums, RAID, backups, error detection |
| Malware altering files | Ransomware or a virus rewrites system files | File-integrity monitoring, code signing, least privilege |
| Invalid or malicious input | An injection attack corrupts database records | Input validation, parameterized queries, access controls |
Why download pages publish a hash
When a download page lists a SHA-256 checksum, it lets you confirm the file you received is byte-for-byte the file the publisher released, catching corruption or a tampered mirror. The hash proves integrity. It does not keep the file secret, which would be confidentiality. Hashing and encryption are different jobs for different legs.
Availability: It's There When You Need It
Availability means the data and systems are usable when authorized people need them. A perfectly confidential, perfectly intact database is worthless if it is offline during finals week. Availability is protected by redundancy (no single point of failure), backups (a tested way to restore after loss), and resilience against overload and attack. It is the leg attackers target directly with denial-of-service floods and ransomware.
| Threat | Example | Control that defends it |
|---|---|---|
| Denial-of-service (DoS / DDoS) | A flood of traffic overwhelms a web server | Rate limiting, DDoS mitigation or CDN, over-provisioning |
| Ransomware | Files are encrypted and held hostage | Offline or immutable backups, a tested restore plan |
| Hardware failure | A single disk or server dies | Redundancy (RAID), failover, clustering |
| Power or network outage | The building loses power | UPS, backup generator, redundant internet links |
| Unpatched software exploited | A known bug is used to crash the service | Patch management, monitoring, vulnerability scanning |
The 3-2-1 backup rule
Keep 3 copies of important data, on 2 different types of media, with 1 copy kept offline or off-site. The offline copy is what defeats ransomware, because malware cannot encrypt a backup it cannot reach. A backup you have never tested restoring is only a guess, so practice the restore before you need it.
AAA: Authentication, Authorization, Accounting
Protecting the triad in a running system relies on three steps often called AAA. They happen in order every time you use a secured resource. First the system confirms who you are (Authentication), then it checks what you are allowed to do (Authorization), then it records what you did (Accounting). Confusing the first two is a common source of security bugs. Being authenticated (logged in) is not the same as being authorized (permitted) to open a particular file.
| Step | Question it answers | How it works | Example |
|---|---|---|---|
| Authentication | Who are you? | Verify identity with one or more factors | Logging in with a password and a code from an authenticator app |
| Authorization | What are you allowed to do? | Check permissions and roles | A student can view grades but not change them (role-based access control) |
| Accounting (Auditing) | What did you do? | Log and retain a record of actions | An audit log shows admin Lopez deleted the file report.pdf at 10:42 |
The three authentication factors
Authentication uses factors from three categories: something you know (a password or PIN), something you have (a phone, security key, or smart card), and something you are (a fingerprint or face scan). Multi-factor authentication (MFA) combines two or more factors from *different* categories, which is why a password plus a code on your phone is far stronger than two passwords, since two passwords are both the same category.
Core Security Principles
Beyond the triad and AAA, a handful of design principles guide how secure systems are built and configured. They are not features you install. They are habits that shape every decision.
| Principle | What it means | Example |
|---|---|---|
| Least privilege | Give each user or process the minimum access it needs and nothing more | A web app's database account can read its own tables but cannot delete them |
| Defense in depth | Layer several independent controls so one failure is not fatal | Firewall, plus endpoint antivirus, plus MFA, plus encryption, plus user training |
| Separation of duties | Split a sensitive task so no single person controls it end to end | One employee requests a payment and a different one approves it |
| Need to know | Limit access to the information a specific role actually requires | HR can see salary data, but the help desk cannot |
| Fail securely | On error or failure, default to denying access, not granting it | An authorization check that crashes denies the request rather than allowing it |
Least privilege limits the blast radius
Least privilege is the single highest-value habit on this list. If every account holds only the access it truly needs, a stolen password or a compromised program can reach only a small corner of the system instead of the whole thing. It shrinks the damage of a breach you did not prevent.
Failing Securely: Fail Closed, Not Open
When software or hardware fails, it should default to a safe, locked state rather than an open one. Failing closed (deny by default) protects the asset. Failing open (allow by default) hands it to whoever shows up during the outage. A classic bug is an authorization function that returns allowed when it cannot reach the permissions server. Under heavy load or a deliberate attack, that path quietly grants everyone access at the worst possible moment.
Never let an error path grant access
If code that checks a permission throws an error, the safe behavior is to catch it and deny the request, not to let execution fall through to the allowed branch. Attackers deliberately trigger errors and timeouts to reach fail-open code. Test what your system does when the auth service is slow or down, not only when everything works.
Fail-secure vs fail-safe locks
The wording flips by context, so know which you need. A fail-secure electronic lock stays locked when power is cut, which is right for a server room protecting data. A fail-safe lock unlocks when power is cut, which is required on fire-exit doors so people can escape. Security usually wants fail-secure, but life-safety codes can require fail-safe. Match the choice to whether you are protecting the asset or the people.
Try it yourself
1. Classify the leg. For each event, name the CIA leg it primarily threatens: a website goes offline in a traffic flood, an attacker changes a grade stored in a database, and a laptop full of unencrypted files is stolen. 2. Map controls to legs. Take three controls, multi-factor authentication, off-site backups, and a published SHA-256 checksum, and match each to the triad leg it most directly supports. 3. Spot the fail-open risk. In plain English, describe what a login system should do if the server that stores permissions becomes unreachable in the middle of a request, and explain why letting the user in is the dangerous answer.
security-incidents.csvDownload security-incidents.csv: https://restedteacher.com/practice-files/cybersecurity/security-incidents.csv
Twelve short, fictional incident write-ups to classify by which leg of the CIA triad each one primarily threatens.
Open the spreadsheet
Open security-incidents.csv in Google Sheets or Excel. Each row has an incidentid, a date, the affected system, and a one- or two-sentence description — that description is all you need to classify the incident.
Using security-incidents.csv, classify every row's description as Confidentiality (unauthorized reading or disclosure), Integrity (unauthorized or accidental modification/corruption), or Availability (a system or data made unusable), then answer:
1. How many of the 12 incidents are primarily Confidentiality breaches?
2. How many are primarily Integrity breaches?
3. How many are primarily Availability breaches?
4. Exactly one Integrity incident was caused by an accidental hardware failure rather than a person deliberately tampering with data. Which incidentid is it?