The lens through which every security question gets answered. If you only remember one framework from this course, make it this one.
CIA triad = what you're protecting: Confidentiality (keep secrets secret), Integrity (data isn't tampered with), Availability (systems are there when needed). AAA framework = how access is controlled: Authentication (who are you?), Authorisation (what can you do?), Accounting (what did you do?). Every attack violates at least one CIA pillar. Every control strengthens at least one. Every access check uses AAA. These two frameworks together explain roughly 80% of this subject.
8.1 Why Frameworks Matter
Security is a huge subject. Without a framework, every attack, every defence, and every design decision feels random. Frameworks give you a mental filing cabinet — when you see a new attack, you instantly know where it fits and what defence to reach for.
The two frameworks in this chapter do different jobs:
CIA tells you what property is being attacked or defended
AAA tells you how access to a system is being controlled
In an exam, tagging your answers with the right framework term is worth easy marks — it shows the examiner you're thinking structurally. "The attacker violated Confidentiality by reading the data in transit" scores higher than "the attacker saw the data."
8.2 The CIA Triad
Three pillars. Security professionals classify every attack and every control by which pillar(s) it affects. You should too.
Confidentiality — keep secrets secret
Confidentiality means only authorised people can read the data. When confidentiality fails, sensitive information is exposed to someone who shouldn't see it.
Real-world examples of confidentiality:
Your bank PIN isn't visible to the person behind you at the ATM
Your medical records are accessible to your doctor but not to strangers
Your Snapchat messages go only to the intended recipient
Your school's staff salary spreadsheet is off-limits to students
What breaks confidentiality: packet sniffing on unencrypted Wi-Fi, data breaches (Optus, Medibank), shoulder-surfing, spyware, stolen laptops with unencrypted drives, insider threats reading data they shouldn't.
Main controls for confidentiality:encryption (both in transit via HTTPS/TLS and at rest on disks), access control (only authorised users can open the file), physical security (locked server room), classification (marking what's sensitive so people handle it correctly).
EXAM PHRASING: "This attack breaches confidentiality because the attacker is able to read [specific data] that they are not authorised to access." Name the data and who shouldn't see it — specificity scores.
Integrity — data hasn't been tampered with
Integrity means data is accurate and hasn't been modified, either by malicious change or accidental corruption. When integrity fails, you can't trust what you're looking at.
Real-world examples of integrity:
When you download a software update, it's the real update and not malware
When your school emails parents, the email actually came from the school
When a bank transfers $50, it doesn't somehow become $500 during transit
Your grades in the school system weren't changed by another student
What breaks integrity: MITM attacks (modifying data in transit), malware that alters files, SQL injection that modifies database records, spoofing (pretending to be someone else), unauthorised edits by insiders, data corruption from hardware faults.
Main controls for integrity:hashing (produces a fingerprint that changes if data changes — any tampering is detectable), digital signatures (cryptographic proof of origin AND integrity), access control (only authorised users can modify), version control & audit logs, input validation (preventing injection attacks).
TRAP: Integrity is NOT the same as confidentiality. Someone who MODIFIES your data without reading it has breached integrity only. Someone who READS your data without modifying it has breached confidentiality only. Most advanced attacks breach both, but don't conflate them in exam answers.
Availability — the system is there when you need it
Availability means authorised users can access the system and data when they need to. When availability fails, legitimate users are locked out — even if nothing was stolen or modified.
Real-world examples of availability:
The school's online learning platform works when there's homework due
ATMs dispense cash when you need it
The hospital's patient record system works 24/7
Your email doesn't disappear overnight
What breaks availability: DoS and DDoS attacks, ransomware (files encrypted = unavailable), hardware failures, power outages, accidental deletion, network outages, successful attacks that take systems offline for investigation.
Main controls for availability:redundancy (backup servers, backup internet connections), backups (restore after data loss), DDoS mitigation services (Cloudflare, Akamai), load balancing (spread traffic across multiple servers), disaster recovery planning, uninterruptible power supplies.
Reminder — which pillar did the big breaches attack? Optus (2022): Confidentiality — 9.8M customer records exposed. Medibank (2022): Confidentiality primarily (data exfiltrated), plus threatened Integrity (data posted publicly). WannaCry (2017): Availability primarily (systems encrypted, NHS surgeries cancelled). Colonial Pipeline (2021): Availability — fuel couldn't flow because billing systems were down. Dyn DNS (2016): Availability — DDoS took down DNS, which took down half the internet.
Pattern: Confidentiality attacks are more common (data theft is profitable). Availability attacks are more disruptive (they halt operations). Integrity attacks are rarer but most dangerous in regulated industries (finance, healthcare) where trust in data is everything.
CIA conflict — you can't maximise all three
A subtle but important point: the three pillars often pull against each other. Pushing one up can push another down.
Strengthen this...
...often weakens this
Example
Confidentiality (locked down tight)
Availability (users can't get in easily)
MFA everywhere is more secure but adds friction — users lock themselves out
Availability (always accessible)
Confidentiality (easier access = more attack surface)
A public-facing login page is convenient, but invites credential-stuffing attacks
Integrity (everything signed/verified)
Availability (verification takes time)
Heavy cryptographic verification on every request slows systems down
EXAM-GRADE INSIGHT: Good design isn't about maxing one pillar — it's about finding the right balance for the specific context. A hospital prioritises availability (doctors need records during an emergency). A spy agency prioritises confidentiality (a leak ends lives). A bank prioritises integrity (a single wrong transaction is catastrophic). Whenever you justify a design choice, think about which pillar matters most for this scenario.
A student changes their grades in the school's online gradebook. Which CIA pillar did this violate?
Integrity. The data was modified without authorisation. Note: no data was stolen (so not confidentiality), and the system is still available to others (so not availability). Pure integrity attack. (It also likely involved an authentication or authorisation failure — we'll cover that in section 8.4.)
A ransomware attack encrypts a company's servers. Which CIA pillar(s) are violated?
Primarily Availability — the company can't access their data. Modern ransomware often also threatens Confidentiality ("pay or we publish your files" — called "double extortion"). Integrity is arguably affected too if files are corrupted. Real attacks often hit multiple pillars.
Someone secretly reads emails as they pass through a public Wi-Fi network but doesn't modify them. Which pillar?
Confidentiality only. The attacker read data they shouldn't have. They didn't change anything (integrity intact) and didn't make anything unavailable. This is classic packet sniffing on an unencrypted network — and it's why HTTPS matters.
8.3 Extending CIA — sometimes you'll see extra letters
Some frameworks extend CIA with additional concepts. You don't need to know them all, but two come up often:
Letter
Concept
What it adds
N
Non-repudiation
A sender can't later deny they sent a message. Achieved through digital signatures. Matters in legal and financial contexts — "you can't claim you didn't authorise this transaction."
A (second)
Authenticity
A message genuinely came from who it claims to be from. Overlaps with integrity. Digital signatures provide this.
If your syllabus uses an expanded acronym (like "CIANA"), you'll see these. Otherwise stick with CIA as your workhorse.
8.4 The AAA Framework — how access is actually controlled
CIA tells you what to protect. AAA tells you how access to a system is controlled when someone tries to use it. Every time you log in anywhere, all three A's are at work.
Sometimes written as "AAAA" with Auditing split out, but Accounting usually covers both. The core split is AuthN → AuthZ → log.
Authentication — "who are you?"
Authentication proves you are who you claim to be. You prove this by providing factors — pieces of evidence tied to your identity.
Geolocation, network location (e.g., "inside the office network")
Single-factor authentication uses just one (typically a password). Multi-factor authentication (MFA) requires two or more factors from different categories. "Password + security question" is NOT MFA — both are things you know. "Password + phone code" IS MFA — different categories.
TRAP: Students often confuse identification with authentication. Identification is claiming an identity (typing your username). Authentication is proving it (entering your password). You identify first, then authenticate. Getting this wrong in a detailed answer costs marks.
Authorisation — "what can you do?"
Once the system knows who you are, it still has to decide what you're allowed to do. This is authorisation.
Example: at your school, every teacher is authenticated the same way (username + password). But a classroom teacher authorised to view their students' grades; the principal is authorised to view all students' grades; the IT admin is authorised to reset passwords. Same authentication, different authorisation.
Common authorisation models:
Role-Based Access Control (RBAC) — permissions attached to a role (Teacher, Student, Admin). Users are assigned roles. Most common model in schools and businesses.
Attribute-Based Access Control (ABAC) — permissions based on attributes (time of day, location, user's department, sensitivity of the resource). More flexible, more complex.
Discretionary Access Control (DAC) — the owner of a resource decides who can access it (like sharing a Google Doc).
Mandatory Access Control (MAC) — the system enforces fixed rules based on security classifications (used in government/military, "secret" vs "top secret").
Principle of Least Privilege
The most important authorisation principle: every user and every system should have the minimum permissions needed to do their job, and no more.
Why it matters: if an account is compromised, the damage is limited to what that account could do anyway. The IT contractor account that enabled the Medibank breach should not have had access to every system — that's a least-privilege failure.
REAL-WORLD APPLICATION: When you set up a new database for a web app, don't give the web app the "admin" database account. Give it a dedicated account that can only read and write the tables it needs. If the app is later hacked via SQL injection, the attacker inherits only those limited permissions — not full database admin. Same principle applies everywhere: cloud roles, file permissions, VPN access.
Accounting — "what did you do?"
Accounting (sometimes called Auditing) means keeping a record of who did what, when. Logs capture actions: logins, file access, configuration changes, failed attempts.
Accounting serves three purposes:
Detection — noticing suspicious activity (100 failed logins, an admin account active at 3am from a strange country)
Investigation — after a breach, logs are how you figure out what happened
Compliance — laws like the Privacy Act require organisations to know who accessed personal data and when
Without accounting, even if you detect a breach, you can't tell what the attacker did once inside. Chapter 15 covers how monitoring and incident response use these logs.
TRAP: Logs are only useful if someone is looking at them. Many major breaches had logs showing the attack in progress, but no one reviewed the logs until weeks later. Collecting logs ≠ monitoring logs. In a design answer, say "logs are centralised and alerted on" — not just "logs are collected."
8.5 AuthN vs AuthZ — the distinction that trips everyone up
This is the single most-confused concept in the course. Lock it in now.
Authentication (AuthN)
Authorisation (AuthZ)
Question answered
"Who are you?"
"What are you allowed to do?"
Happens...
First, when you log in
Second, on every action
Checks...
Credentials (password, biometric, etc.)
Permissions (roles, policies)
Failure looks like...
"Invalid username or password"
"You don't have permission to access this"
Common attacks
Phishing, credential stuffing, brute force
Privilege escalation, broken access control, IDOR
Fixes
Strong passwords, MFA, passwordless login
Least privilege, RBAC, regular permission reviews
MEMORY HOOK: AuthN = "N" for kNow who — proving identity. AuthZ = "Z" for aZZess level — what you're allowed to do. (Silly, but it sticks.)
Common exam scenarios — classify them:
A phishing email tricks you into giving up your password → Authentication attack (steals the "who are you" proof)
An attacker, already logged in as a low-level user, finds a way to access admin functions → Authorisation failure (got access they shouldn't have, even though authentication worked correctly)
A password reset system doesn't verify the new request is from the actual user → Authentication failure (the system can't properly confirm identity)
A hospital employee views the medical records of a celebrity for curiosity → Authorisation failure + Accounting catches it (the employee was authenticated fine, but shouldn't have been authorised for those records — and if accounting logs are reviewed, they get caught)
An attacker uses SQL injection on a login page and bypasses the check entirely, logging in as admin. Is this an AuthN or AuthZ failure?
Primarily an authentication failure — the system failed to properly verify the user's identity (it was tricked into accepting the attacker as "admin" without valid credentials). Once they're in as admin, the resulting excessive access is an authorisation problem too, but the root cause is AuthN broke. In exam terms: the attack exploits a failure in the authentication mechanism.
A disgruntled employee who has legitimate login access downloads the entire customer database before quitting. Which CIA pillar and which A of AAA are relevant?
CIA: Confidentiality (data has been exfiltrated to someone who shouldn't have the whole database off-site). AAA: This is an authorisation failure — the employee's role likely shouldn't include "download the entire customer database" in one go. Least-privilege access and/or data loss prevention (DLP) controls would have limited the damage. Accounting is also relevant — logs should flag and alert on unusual bulk downloads.
8.6 How CIA and AAA Relate
The two frameworks work together. Here's how they connect:
When this AAA step fails...
...this CIA pillar is at risk
Weak authentication (stolen passwords)
Usually Confidentiality (attacker logs in and reads data) — but could be any pillar depending on what they do
Broken authorisation (privilege escalation)
All three — attacker gets permissions they shouldn't have
Missing/ignored accounting
Indirectly affects all three — you can't detect breaches you're not watching for
THE BIG-PICTURE INSIGHT: AAA is a mechanism. CIA is an outcome. When you design security:
1. Start with CIA — what outcomes do we need to protect?
2. Use AAA — design access controls to achieve those outcomes
3. Layer other defences on top (encryption, segmentation, monitoring)
This is how the BSSS design-solution task (Chapter 16) is structured.
8.7 The Exam Mark-Scoring Template
For any "analyse this attack" question:
1. Name the attack type (from Chapter 10)
2. Identify the CIA pillar(s) violated — C, I, A, or combinations
3. Identify the AAA step(s) that failed — authentication, authorisation, or accounting
4. Explain the mechanism — how the failure led to the compromise
5. Recommend defences — tied to the failure modes identified
Hit all five and you have a structured, high-scoring answer.
8.8 Quick-Fire Quiz
Name the three pillars of the CIA triad and give a one-line example of each.
Confidentiality — only authorised people can read data (e.g., your medical records aren't public). Integrity — data is accurate and untampered (e.g., a downloaded installer is the real one, not malware). Availability — the system is accessible when needed (e.g., online banking works when you need it).
A website forces you to enter a password AND a code from an authenticator app. What kind of authentication is this, and why is it stronger than just a password?
Multi-factor authentication (MFA). It combines something-you-know (password) with something-you-have (phone/app). It's stronger because an attacker who steals your password via phishing still can't log in — they'd also need to steal your phone, or compromise the authenticator app. Different factor categories = attacker has to breach two independent things.
Explain why the principle of least privilege is one of the most important security concepts.
Least privilege limits the damage from any compromise. If every user and every service has only the minimum access they need, then a breach of one account doesn't become a breach of everything. The Medibank attacker got in via one compromised credential but then had access to the whole environment — classic least-privilege failure. Applied properly, least privilege turns most breaches into small incidents instead of catastrophes. In exam terms: it reduces the blast radius of a compromise.
A company collects extensive logs but no one reviews them. A breach goes undetected for 6 months. What AAA principle was violated?
Accounting was implemented but not used effectively. Logging without monitoring is near-worthless — the logs existed to detect this breach, but nobody was looking. Good security requires both collection AND review (or automated alerting via a SIEM system). This pattern — "logs showed the attack but no one was watching" — describes many major breaches. Chapter 15 covers monitoring properly.