CIA Triad & Threat Framing

Before tools, before exploits, before any of the cool stuff, security people share a single mental model. It's a small one. Three letters. C, I, A.

Whenever you look at a system, a website, a Wi-Fi network, a database, the laptop on your desk, you ask three questions:

1. Confidentiality, can the wrong people see this?
2. Integrity, can the wrong people change this?
3. Availability, can the right people use this when they need to?

That's it. That's the whole frame. Everything else in this course hangs off these three words.

Why this matters

A "bug" and a "security issue" can look identical from the outside. A button that doesn't work is a bug. A button that also lets a stranger read someone else's messages is a confidentiality failure. The code is broken either way, but only one of them is a security finding, and the triad is how you tell them apart.

When you find something weird in a target system, before you get excited, ask: which of the three does this break? If the answer is "none of them," it's a quality bug. If the answer is one or more, you've found something security-relevant, and you can describe it clearly to whoever owns the system.

Confidentiality, "who can see this?"

Confidentiality is about keeping information visible only to the people who should see it.

Everyday analogy. A sealed envelope. The postcard you sent has zero confidentiality, anyone in the mail chain can read it. The sealed envelope has some. A locked diary has more.

Concrete examples of broken confidentiality:

• A misconfigured cloud bucket lets anyone on the internet list and download customer invoices.
• A web app's "view profile" page accepts ?user_id=43 and happily shows you user 43's data when you're logged in as user 44.
• Wi-Fi traffic on an open café network reveals which sites a person is visiting.

In every case, information leaked to an audience that wasn't supposed to have it. That's a C-failure.

Integrity, "can this be changed without permission?"

Integrity is about keeping data and systems unaltered except by people allowed to alter them, and in ways that are tracked.

Everyday analogy. A bank statement. You assume nobody can quietly change the numbers between the bank printing it and you reading it. If they can, the statement is worthless, not because it's secret, but because you can't trust it.

Concrete examples of broken integrity:

• An attacker modifies a software update on its way to your machine, slipping malware into a tool you trusted.
• A web form lets you submit price=-999 and the shopping cart cheerfully accepts the negative price.
• A logged-in user can edit anyone's profile by changing the user id in the request.

The information might still be visible to the right people, that's fine. The problem is it can be rewritten by the wrong people, and now nobody knows what's true.

Availability, "can the system actually be used?"

Availability is about the system being there when legitimate users need it.

Everyday analogy. A shop with a working front door. The shop can have perfect stock control (integrity) and a perfect customer list (confidentiality), but if the door is jammed shut, customers are blocked. To them, the shop doesn't exist today.

Concrete examples of broken availability:

• A flood of junk traffic (a denial-of-service attack) makes a checkout page time out, so real customers can't buy.
• A ransomware infection encrypts a hospital's patient records, the data still exists, but staff can't open it.
• A single deploy quietly takes the login service offline; nobody can sign in for two hours.

It doesn't matter that nobody saw the data and nobody changed it. The legitimate users can't use it. That's an A-failure.

How to use the triad in practice

Train yourself to do this on autopilot:

See a finding. Pause. Ask: does this break C, I, or A, and how?

If you can answer that in one sentence, you can write a clear report, a clear ticket, and a clear explanation to a non-technical stakeholder. If you can't answer it, the finding probably isn't a security issue, or you don't understand it yet, both useful things to know.

You'll see this triad again and again in this course. Every vulnerability class we cover maps onto one or more of these three letters.

Quick self-check: which does this break?

For each scenario, pick C, I, A, or more than one.

1. An old API endpoint returns every user's email address with no authentication.
2. The site is up, but an attacker can change the price of any item in their cart to $0.01 before checkout.
3. A botnet keeps a small business's website offline for six hours during a sale.
4. An attacker silently swaps the content of a published PDF on the company's download page.

Answers: 1 = C. 2 = I. 3 = A. 4 = I (and arguably C if the original PDF was private, see, sometimes it's more than one, and that's normal).

Takeaway

You now have the lens. From this point on, when something looks suspicious in a target, the very first thing you do, before nmap, before curl, before anything, is name which of the three it threatens. That habit is the difference between a tester who finds noise and a tester who finds findings.