Chapter 2: Protecting Data and Identity

Protecting Data and Identity 🔐

Least privilege, strongest proof.

Networks exist to move data, and almost every attack is ultimately about data: stealing it, changing it, locking it away for ransom or pretending to be someone who is allowed to see it. That makes two questions central to all of cybersecurity. What exactly are we protecting, and how do we know who is asking for it?

This chapter answers both. You will connect the three goals of security to the three states that data lives in, and plan for the day something is lost. You will compare the ways organizations decide who gets access to what, and why the best answer is usually “as little as possible.” You will see why the password, the oldest login method in computing, is finally being replaced, and how the replacement actually works. Then you will open up cryptography, the math that protects nearly everything online, and look ahead to the quantum computers that will force the world to upgrade it.

2.1 — CIA and the States of Data 🔺

Security professionals describe their goals with the CIA triad. It has nothing to do with the intelligence agency.

Confidentiality: only the right people can see the data. A leaked medical record is a confidentiality failure.
Integrity: the data is accurate and has not been changed without authorization. A student secretly editing a grade is an integrity failure.
Availability: the data and systems work when people need them. A ransomware attack that locks the gradebook during report-card week is an availability failure.

The three goals pull against each other. Locking data in a vault with ten passwords boosts confidentiality but hurts availability. Good security finds the balance each kind of data needs. A hospital’s patient chart needs very high availability, because a doctor cannot wait an hour for it in an emergency, while an old archive of tax forms can trade some availability for tighter confidentiality. Before choosing any control, defenders ask which of the three goals matters most for that data and what a failure would cost the people it describes.

Three States of Data

Data is never in just one place. Security teams protect it in all three states of data, and each state stresses the triad differently:

	At rest (stored)	In transit (moving)	In use (being processed)
Confidentiality	Stolen laptop or leaked backup; use full-disk and database encryption	Eavesdropping on Wi-Fi; use TLS and VPNs	Malware reading memory or screens; use endpoint protection, privacy screens
Integrity	Silent tampering with files; use hashes, versioning, access logs	Altered packets on the path; use authenticated encryption	A bug or attacker changing values while processed; use input validation
Availability	Drive failure or ransomware; use backups and redundancy	Network outage or flood; use backup links, DDoS protection	Overloaded server; use capacity planning, load balancing

Notice the pattern: encryption is the main tool for confidentiality in every state, but it does nothing for availability. Ransomware gangs exploit this exact gap: your files may be perfectly encrypted by you, and then encrypted again by them.

Planning for Data Loss

Data loss is not a matter of if. Drives fail, people delete the wrong folder, laptops get left on buses, and ransomware happens. The answer is redundancy, planned in advance. A classic rule of thumb is 3-2-1: keep three copies of important data, on two different kinds of storage, with one copy off site. Many organizations now add that at least one copy should be offline or immutable (unchangeable for a set time), so ransomware that reaches the network cannot encrypt or delete it.

Two numbers turn a backup habit into a real plan. The recovery point objective (RPO) is how much data you can afford to lose: if backups run nightly, you might lose a day of work. The recovery time objective (RTO) is how long you can afford to be down. A district might accept losing one day of lesson-plan edits but need the student information system back within four hours.

Finally, redundancy is more than backups. A mirrored drive array (RAID) keeps a server running when one disk dies, but it happily copies deletions and ransomware to every disk, so it is not a backup. And a backup that has never been restored is only a hope. Test restores on a schedule.

2.2 — Access Control and Least Privilege 🪪

Every login answers three questions, often called AAA. Authentication: are you who you claim to be? Authorization: now that we know who you are, what may you do? Accounting: what did you actually do, recorded in logs? Authentication uses factors from three categories: something you know (a password or PIN), something you have (a phone or security key) and something you are (a fingerprint or face). Two passwords are still one factor, because both are something you know; true multi-factor sign-in combines different categories.

Authentication and authorization fail in different ways, and the difference matters when you investigate. If an attacker logs in with a stolen password, authentication failed. If a real student logs in correctly and then can open the teachers’ grade folder, authorization failed, and no stronger password would have prevented it.

Access Control Models

Once a user is authenticated, an access control model decides what they can reach.

Model	Who decides	How it works	Good fit
Discretionary (DAC)	The owner of each resource	You share your own document with whoever you choose	Personal files, small teams
Mandatory (MAC)	A central authority	Data and users get labels such as Confidential or Secret; the system enforces them	Military and government systems
Role-based (RBAC)	Administrators, by job role	Permissions attach to roles; people are assigned roles	Schools, businesses, most organizations
Attribute-based (ABAC)	Policy rules	Decisions use attributes: role, device, location, time, data label	Cloud and zero-trust environments

role-based access control (RBAC) is the workhorse. Instead of granting 80 teachers access one by one, an administrator gives the Teacher role access to the gradebook for their own classes, then assigns people to that role. When someone changes jobs, you change one role, not dozens of permissions. ABAC adds context, so a rule might say “counselors may view student records only from a district-managed device during school hours.”

The Principle of Least Privilege

The most important rule in access control is least privilege: give every person, program and device the minimum access needed to do its job, for no longer than needed. Least privilege limits the damage of every mistake and every stolen account. If a student account is phished, the attacker gets one student’s view, not the whole district.

Least privilege erodes quietly through privilege creep: people collect permissions as they move between jobs and never lose the old ones. Organizations fight it with a joiner-mover-leaver process (grant, adjust and remove access as people arrive, change roles and leave), regular access reviews, separation of duties (the person who requests a payment cannot also approve it) and just-in-time administration, where IT staff use everyday accounts and receive admin rights only for a specific task and a limited time.

Recommending an Approach

For a school district, a strong recommendation combines these ideas: single sign-on so each person has one well-protected identity; RBAC with roles such as Student, Teacher, Counselor, Office Staff and IT Administrator; ABAC rules for the most sensitive records; phishing-resistant multi-factor authentication for anyone who can see other people’s data; separate, just-in-time admin accounts; and logs reviewed for unusual access.

2.3 — Going Passwordless 🔑

Passwords have three deep flaws. People reuse them, so a password leaked from one site unlocks others through credential stuffing, where attackers try stolen username and password pairs everywhere. People can be tricked into typing them into fake sites. And servers must store something derived from them, which can be stolen in a breach.

Not All MFA Is Equal

multi-factor authentication (MFA) adds a second proof, and it blocks most automated account takeovers. But many common forms can still be phished, because a person can be tricked into handing over the code or approving the prompt:

Method	Can a fake site or caller trick you out of it?
Codes sent by text message	Yes: you can be tricked into reading the code aloud or typing it on a fake site, and phone numbers can be hijacked
Codes from an authenticator app	Yes: a fake login page can ask for the code and use it within seconds
Push approvals (“Is this you?”)	Yes: attackers can send prompt after prompt hoping for a tired tap; in 2022 Uber said an attacker got in after flooding an employee with prompts and then posing as IT support
FIDO2 security keys and passkeys	No: the credential only works on the real website

How Passkeys Resist Phishing

A passkey is built on the FIDO2 standards (WebAuthn in the browser and CTAP between devices), developed by the FIDO Alliance and the World Wide Web Consortium. When you create a passkey, your device generates a unique pair of cryptographic keys for that one website. The public key goes to the website. The private key never leaves your device or your password manager’s encrypted vault.

To sign in, the website sends a random challenge. Your device asks you to unlock it locally with a fingerprint, face or PIN, then signs the challenge with the private key, and the site checks the signature with the public key. Three properties make this phishing-resistant. The browser binds each passkey to the website’s real domain, so a look-alike site simply cannot request it. There is no shared secret for you to type or read aloud. And the server only stores public keys, which are useless to a thief. Your fingerprint or face is checked on your own device and is never sent to the website.

Passkeys come in two forms: synced passkeys, backed up across your devices by a password manager or platform account, and device-bound passkeys on a physical security key, which cannot be copied and are preferred for administrators.

The Policy Side

Technology is half of the story. In 2022 the U.S. Office of Management and Budget directed federal agencies to adopt phishing-resistant MFA, and CISA describes FIDO-based authentication as the strongest widely available option. Any organization planning the switch must also decide how lost devices are recovered (recovery is now the weakest link), how shared lab computers and young students without phones will sign in, how to support people with disabilities, and who pays for hardware keys.

A transition plan usually runs in phases: inventory systems and which ones support passkeys; start with the highest-risk accounts (IT administrators and finance); offer passkeys to everyone else while keeping a strong fallback; train users and the help desk; then retire passwords on each system once adoption is high and recovery is proven.

2.4 — How Cryptography Works 🔐

Cryptography is the math that keeps data confidential and proves it has not been changed. Three tools do almost all the work.

Symmetric Encryption

Symmetric encryption uses one secret key to lock and unlock data. The Advanced Encryption Standard (AES) is the global default; it protects your phone’s storage, Wi-Fi traffic and encrypted drives. It is extremely fast. Its one problem is sharing the key: how do two computers that have never met agree on a secret key while an eavesdropper listens?

Public-Key Cryptography

public-key cryptography solves that. Each party has a key pair. Data locked with the public key can only be unlocked with the matching private key, and a signature made with the private key can be checked by anyone with the public key. RSA and elliptic-curve cryptography (ECC) are the most widely used public-key systems. Their security rests on math problems that ordinary computers cannot solve in any useful amount of time: factoring enormous numbers for RSA, and a related problem on elliptic curves for ECC.

Hashing and Signatures

A hash function such as SHA-256 turns any input into a fixed-length fingerprint. The same input always gives the same hash, and the tiniest change gives a completely different one:

"Final grade: B"  ->  82fab62354e49fd996499cb1938f651a95dbe263abfe092993b5622fa4c4413a
"Final grade: A"  ->  2c9dc63d90c93c8f839fa41998ff912b1930b8a3bb85b0c6b91250e847d3b323

Hashes protect integrity: if a file’s hash matches the published one, it has not been altered. A digital signature is a hash signed with a private key, which proves both who sent something and that it was not changed. Software updates, apps and websites all rely on signatures.

Putting It Together: TLS

When you visit an HTTPS site, Transport Layer Security (TLS) combines all three. The server proves its identity with a certificate signed by a trusted authority. The two sides use a public-key key exchange to agree on a fresh secret, and from then on fast symmetric encryption protects the conversation, with integrity checks on every message. Modern TLS creates new session keys for every connection, a property called forward secrecy, so stealing a server’s long-term key later does not unlock conversations recorded in the past by ordinary computers.

Cryptography rarely fails because the math is broken. It fails because keys are stored carelessly, old algorithms are left switched on, certificates expire unnoticed or programmers write their own “clever” encryption. The rule professionals repeat is simple: never invent your own cryptography; use well-reviewed standard libraries and protect the keys.

The Quantum Problem

Quantum computers use qubits, which can represent combinations of states, to attack certain math problems very differently from ordinary computers. In 1994 mathematician Peter Shor described a quantum algorithm that could factor large numbers and solve the elliptic-curve problem efficiently. A large, reliable quantum computer running it would break RSA and ECC, which means today’s key exchanges and signatures. Symmetric encryption and hashing fare much better: another quantum algorithm, Grover’s, roughly halves their effective strength, so longer keys such as AES-256 remain secure.

No publicly known quantum computer can do this yet; today’s machines are far too small and error-prone. But there is a catch called “harvest now, decrypt later”: an adversary can record encrypted traffic today and store it until a capable quantum computer exists. Any secret that must stay secret for many years, such as health records, government data or a person’s identity information, is already at risk.

2.5 — Post-Quantum Readiness ⚛️

The fix for the quantum problem is not quantum technology. It is new math. post-quantum cryptography (PQC) uses problems that neither ordinary nor quantum computers are known to solve efficiently, and it runs on the phones and servers we already have.

The New Standards

After an open international competition that began in 2016, the U.S. National Institute of Standards and Technology (NIST) published its first three post-quantum standards in August 2024:

Standard	Algorithm	Job	Replaces
FIPS 203	ML-KEM	Agreeing on keys (key encapsulation)	RSA and ECC key exchange
FIPS 204	ML-DSA	Digital signatures	RSA and ECC signatures
FIPS 205	SLH-DSA	Digital signatures from hash functions, as a backup approach	RSA and ECC signatures

In 2025 NIST also selected HQC as a backup key-encapsulation algorithm built on different math. NIST has proposed a timeline that deprecates today’s quantum-vulnerable public-key algorithms after 2030 and disallows them after 2035, and the U.S. Quantum Computing Cybersecurity Preparedness Act of 2022 directs federal agencies to plan their migration.

The upgrade has already started where you cannot see it. Major web browsers and content-delivery networks now use hybrid key exchange, combining a classic elliptic-curve method with ML-KEM, so a connection stays safe as long as either one holds. Messaging apps such as Signal and Apple’s iMessage have added post-quantum protection too.

Building a Cryptographic Inventory

Organizations cannot migrate what they cannot find, so step one is a cryptographic inventory: a list of everywhere cryptography is used and what kind. For each system, record what it protects, which algorithms and key sizes it uses, who supplies it (your own code or a vendor), and how long its data must stay secret. Then prioritize. A common rule compares two times: if the years the data must stay confidential plus the years migration will take is longer than the years until a capable quantum computer might exist, that system is urgent. Long-lived sensitive records and systems that are hard to update (embedded devices, building controls) move to the top. A key design goal is crypto agility: systems built so that algorithms can be swapped without rebuilding everything.

Equity, Governance, and Risk

Post-quantum migration is not equal for everyone. A large bank has cryptographers on staff; a rural school district may have two IT employees and depend entirely on vendors. Older devices that cannot be updated may need to be replaced, which costs money that under-resourced communities do not have. Governance questions follow: who in an organization owns the migration, how vendors will be held to deadlines in contracts, and how progress is reported. The risks run both ways. Waiting leaves recorded data exposed, but rushing creates bugs, and new algorithms are young, which is exactly why hybrid approaches and crypto agility matter. A practical policy for a small organization therefore looks less like a science project and more like good purchasing: ask every vendor for its post-quantum roadmap, write migration expectations into new contracts, replace hard-to-update equipment on the normal refresh cycle, and share plans and lessons with neighboring districts or regional consortia so that no community is left behind.

Chapter 2 Activity: Protect the District’s Data 🏫

You are advising Lakeview Unified, a fictional district of twelve schools. Its data includes a student information system, a SaaS learning platform, payroll, counseling notes and security camera footage. Work in teams on paper or in a district-approved document tool.

Part 1: Data in Three States

Pick three kinds of Lakeview’s data. For each, fill in a grid of the CIA triad against the three states of data with one threat and one control per cell. Then write a redundancy plan for the student information system: its 3-2-1 backup design, an offline or immutable copy, an RPO, an RTO and a restore-testing schedule.

Part 2: Who Gets What

Define at least six roles (for example Student, Teacher, Counselor, Principal, Payroll Clerk, IT Administrator). Build an RBAC matrix showing which role can read, edit or not access each system, and add two ABAC rules for the most sensitive data. Explain how least privilege, separation of duties and just-in-time admin appear in your design.

Part 3: The Passwordless Plan

Write a phased transition plan from passwords to passkeys for Lakeview. Name which accounts go first and why, how students on shared lab computers will sign in, how lost devices will be recovered, how you will support users with disabilities and what training the help desk needs.

Part 4: The Post-Quantum Policy Brief

Build a cryptographic inventory of at least six Lakeview components (for example the website’s TLS, the VPN, staff laptops’ disk encryption, the camera system and two SaaS vendors) and rank them for migration with a written reason for each. Then write a one-page policy brief to the school board recommending a proactive post-quantum data protection strategy, including equity concerns, governance (who owns it), vendor requirements and a timeline.