The CIA Triad: Confidentiality, Integrity and Availability

The CIA triad is the model security people use to say what a control protects. It names three properties of information and systems: confidentiality, integrity and availability. Most security controls exist to keep one or more of them true. If you can say which property an event broke, you already know the kind of damage it did and which kind of control should have stopped it.

This article picks up where What Is Cybersecurity? ends. That article said security is about protecting information and systems from harm. This one narrows the idea into three goals and gives you a way to sort real events.

#What the CIA triad is

Each property answers a different question:

• Confidentiality: who is allowed to read this?
• Integrity: is this unchanged, and does it really come from who it says it does?
• Availability: can the right people use it when they need it?

NIST uses these three terms across its security publications. FIPS 199 builds its federal information categories on them: each category asks how much harm a loss of each property would cause. The formal definitions are longer and more careful than the summary above. The sources at the end of this article link to them, and you should read them once you have the basic idea.

The letters are a memory aid, not a ranking. C does not come first because it matters most. A hospital scheduling system may treat availability as its top concern, while a payment ledger may care more about integrity. The right priority depends on the system and on what happens when it fails.

#Why three properties and not one

"Keep it safe" hides the trade-offs. A system can keep its secrets and still be useless because nobody can reach it. It can be online all the time and serve wrong data. It can be accurate and always available and still leak records to the wrong people. Naming three properties lets you ask a precise question about each one and pick controls that answer it.

Other frameworks add more terms, such as authenticity, accountability and non-repudiation. Some definitions fold authenticity and non-repudiation into integrity. FIPS 199 does this. Whichever definition you use, the three-property model is the common starting point, so learn it first.

#Confidentiality: the leaked file

Imagine a company exports its customer list to a spreadsheet and saves it on a shared drive. Everyone in the company can open that drive. A contractor who was only supposed to see one project downloads the whole file. Nothing was changed. The service stayed online. The information still left the place where it was supposed to stay, so confidentiality was lost.

Confidentiality is about who can read data, and it covers data at rest (on a disk, in a database), data in transit (moving across a network) and data in use (open in memory or on a screen).

#Typical controls for confidentiality

• Encryption makes data unreadable without a key. It protects stolen disks and intercepted traffic, but it does not stop someone who already holds the key or is authorized to read the data.
• Access control and least privilege give each person only the permissions the job needs. The contractor in the example should not have been able to reach the whole folder.
• Multi-factor authentication makes a stolen password less useful on its own.

#Optional check: encryption at work

The commands below run on a scratch file. They show what encryption does in practice. This is an illustration, not a graded lab, and the passphrase is for this demo only. Never put real secrets on a command line or in shell history.

printf 'Patient: J. Example, diagnosis: placeholder\n' > record.txt
export DEMO_PASS='lab-only-passphrase'
openssl enc -aes-256-cbc -pbkdf2 -salt -pass env:DEMO_PASS -in record.txt -out record.enc
od -A x -t x1z record.enc | head -3
openssl enc -d -aes-256-cbc -pbkdf2 -pass env:DEMO_PASS -in record.enc
openssl enc -d -aes-256-cbc -pbkdf2 -pass pass:wrong -in record.enc -out /dev/null

On the machine where this was run (Windows 11, Git Bash, OpenSSL 3.2.4), the output was:

000000 53 61 6c 74 65 64 5f 5f e4 81 09 19 9d 68 fe de  >Salted__.....h..<
000010 54 5b 6c 39 12 1a 38 01 b3 03 ac b8 66 be 3b 4b  >T[l9..8.....f.;K<
000020 68 ae 58 39 8f 74 f1 59 23 27 09 fe b7 cf cc 58  >h.X9.t.Y#'.....X<
Patient: J. Example, diagnosis: placeholder
bad decrypt
D4C00000:error:1C800064:Provider routines:ossl_cipher_unpadblock:bad decrypt:../openssl-3.2.4/providers/implementations/ciphers/ciphercommon_block.c:107:

The first three lines are the start of the ciphertext. The bytes after the Salted__ header look random, and they change on every run because OpenSSL picks a fresh salt each time, so your hex will differ. The right passphrase returns the original line. The wrong one fails with bad decrypt, and that error is all the wrong key produces. The error text does not reveal the content. The leading eight-character code in the error also varies between runs.

#Integrity: the tampered download

Someone downloads an installer from a mirror site. If the file was changed, it may still run perfectly well. The question is not whether it runs. The question is whether its bytes match what the vendor published.

Integrity also covers data in a database that someone edited without authorization, a log that was erased after an intrusion, and a configuration file changed by a script nobody approved. In each case, the damage is that you can no longer trust what the data says.

#Hashes: detect a change

A hash function reads a file and produces a fixed-length fingerprint. Change one byte and the fingerprint changes completely. Comparing fingerprints lets you check that two copies are identical without reading both files side by side.

The commands below create a file, record its SHA-256 hash, and change its content:

printf 'Transfer: 10.00 USD to account A\n' > transfer.txt
sha256sum transfer.txt
printf 'Transfer: 1000.00 USD to account A\n' > transfer.txt
sha256sum transfer.txt

Observed output:

f5ff0bd125880721c12f4eeecd95eb1a03fbc98f61dbd4ea2235cd7c902aa936 *transfer.txt
486ca9f3224c8003ff043ae09f3d1bc6cbe5008859a81c08e95da91945812b04 *transfer.txt

The second hash has nothing in common with the first, even though the change was one extra zero. The check becomes useful when you keep the expected hash and compare against it. Save the original hash to release.sha256, then verify:

sha256sum -c release.sha256

For the original file it printed release.txt: OK. After the file was tampered with, it printed this:

release.txt: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

The command exits with status 1, so a script can stop on it.

A hash has a limit. If an attacker replaces the file and also replaces the published hash on the same web page, the comparison passes and proves nothing. The hash only tells you that the file matches whatever hash you were given, so you need a trusted copy of that hash.

#Digital signatures: prove who published it

A digital signature handles that problem. The publisher signs the file with a private key. Anyone holding the matching public key can verify the signature. An attacker without the private key cannot produce a valid signature for a changed file.

The next commands use a throwaway RSA key created in a scratch folder. Do not reuse it for anything real.

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out priv.pem
openssl pkey -in priv.pem -pubout -out pub.pem
openssl dgst -sha256 -sign priv.pem -out release.sig release.txt
openssl dgst -sha256 -verify pub.pem -signature release.sig release.txt

On the original file, the verification printed Verified OK. After the file was changed, the same verification printed Verification failure, followed by OpenSSL error lines that include source paths. Those lines are omitted here.

A valid signature shows that the file was signed by the holder of the private key. It does not show that the key belongs to the vendor you expected. That link comes from a separate step: a certificate, a trusted key distribution or a fingerprint you check through another channel.

#Typical controls for integrity

• Hashes published through a channel separate from the download, so an attacker who edits the file cannot edit the reference too.
• Digital signatures on software packages, updates and documents.
• Audit logs and change control that record who changed what and when. Logs need protection too, or an intruder can erase the record.
• Version control for code and configuration, so a change leaves a diff and a reviewer.

#Availability: the site that is down

A clinic runs its appointment system on one server. A disk fails on a Monday morning. Patients cannot book for a day. Nothing was stolen and nothing was changed. The service was simply not there when people needed it.

Attacks cause the same outcome. A distributed denial-of-service (DDoS) attack floods a service with traffic until legitimate users cannot get through. Ransomware can lock files so that staff cannot work, even when no data leaves the organization. Availability also covers the people path: an account locked after too many failed logins is a small availability loss.

#Typical controls for availability

• Backups copied to a separate location. A backup you have never restored is a hope, not a control, so test restores on a schedule.
• Redundancy and failover: a second server, a second network path or a standby database that takes over when the first one fails.
• Capacity planning and rate limiting to absorb normal spikes and slow down abusive traffic.
• DDoS protection from your hosting or network provider, which filters traffic before it reaches your servers.
• A written recovery plan that states how long the service may be down (recovery time) and how much recent data you can afford to lose (recovery point).

Backups have a catch. A backup can protect integrity when it lets you restore a clean copy after an intrusion, but only if the backup was made before the intrusion and kept out of the attacker's reach. A backup is also confidential data, so it needs encryption and access control too.

#How the three properties map to controls

Most controls touch more than one property. The useful question is which property you are relying on for a given risk.

#A method you can reuse

1. Name the asset: a file, a database, a login system, a website.
2. For each property, ask what the harm would be if the asset were disclosed, changed or unavailable.
3. Rate each harm as low, moderate or high. This is the same kind of reasoning FIPS 199 applies to federal systems.
4. Pick controls for the highest harms first.
5. Ask how you would know the control had failed. A backup needs a restore test, a signature needs a check, and a password policy needs a way to notice abuse.

#Paper exercise: classify ten incidents

Read each description and write one letter: C (confidentiality), I (integrity) or A (availability). If two properties fit, pick the one the description emphasizes most and note the other in brackets. You do not need a computer for this. Try all ten before you read the answer key.

1. A laptop is stolen from a car. Its disk is not encrypted, and the customer list on it is readable.
2. A mirror site serves a modified installer. Users who compare its SHA-256 hash with the vendor's published value find a mismatch.
3. Ransomware encrypts the company file server. Staff cannot open shared files for three days.
4. An employee emails a payroll spreadsheet to a personal address by mistake.
5. A flood of traffic hits the company's public website. Customers see timeouts for six hours.
6. An insider edits a transfer record so the amount shows as 1,000 instead of 10. No log entry records the change.
7. An attacker phishes a database administrator's password and downloads the customer table.
8. A hospital's scheduling service runs on a single server with no standby. A disk failure takes it offline for a day.
9. A checkout page sends the price from the browser to the server, and the server accepts it. A user changes the price from 100 to 1, and the order is recorded at 1.
10. A support portal shows other customers' names and addresses to any logged-in user.

#Answer key

1. C. The data was readable by whoever had the laptop. Encryption at rest would have protected it.
2. I. The modified file no longer matches the published hash. The hash comparison detected the change.
3. A. Staff lost access to their files. The encryption that ransomware performs also changes the files, so you could argue [I] as well. The description focuses on the outage.
4. C. Payroll data reached an address outside the company. This is a disclosure mistake, and it is still a confidentiality loss.
5. A. The traffic kept legitimate customers from reaching the site.
6. I. The record was changed without authorization, and the missing log also weakens accountability.
7. C. A stolen password led to the disclosure of the customer table. Authentication is a confidentiality control, so the password theft is the first hit.
8. A. The single server had no failover, so one failed disk stopped the service.
9. I. The server trusted a value the user controlled, so the recorded order no longer matches the real price. Never let the client set a price.
10. C. Other customers' personal data was visible to users who were not authorized to see it.

Scoring: eight or more correct means you can already sort incidents. If you missed several in the integrity group, reread the hash section. Some incidents fit two properties, so accept a reasoned answer that picks a different primary property if you explain why.

#Common mistakes

• Treating the triad as a ranking. Which property matters most depends on the system. Decide it per asset.
• Assuming encryption solves everything. Encryption protects data from people without the key. It does nothing against an account that is already authorized to read the data.
• Mixing up hashes and encryption. A hash shows that something changed. It does not hide the content, and a hash of a short, guessable value can be reversed by guessing.
• Trusting a backup you never tested. Many recovery plans fail on the first real restore.
• Calling every incident a hack. Many serious outages come from misconfiguration, a failed disk or a mistaken deletion. The triad helps you see those as availability or integrity problems too.
• Forgetting that a published hash needs a trusted source. The check is only as strong as the place you got the reference from.

#How to go further

Read the introduction sections of NIST SP 800-12 Rev. 1 and the impact definitions in FIPS 199 in full. They use the words you have just learned, and they will make the formal documents easier to read.

Next, read What Is a Vulnerability? to see how a weakness turns into a loss of one of these three properties. For the mechanics behind encryption and hashes, read What Is Cryptography?.

To practice without touching anyone else's systems, take a few of your own files, record their hashes, change one character, and run the check again. Then encrypt a copy with a throwaway passphrase, decrypt it, and try the wrong passphrase. Delete the scratch files when you finish. The goal is to watch the properties work, not to build a secure system from shell commands.

Finally, read a public incident report and classify its main event with the same method. Ask which property it hit first, then which control would have changed the result.

#Sources

• NIST, An Introduction to Information Security, NIST SP 800-12 Rev. 1, June 2017: https://csrc.nist.gov/pubs/sp/800/12/r1/final
• NIST, Standards for Security Categorization of Federal Information and Information Systems, FIPS 199, February 2004: https://csrc.nist.gov/pubs/fips/199/final