Confidentiality

Confidentiality ensures sensitive information is available only to authorized people, processes, or systems. Think sealed envelope versus postcard: the postcard's problem is not that it can be crumpled; it is that anyone along the route can read it. A breach that publishes patient records unchanged is still a confidentiality failure. A café stranger reading open email is a confidentiality failure. A cloud link set to "anyone with the link" that escapes the intended circle is a confidentiality failure. Integrity would require unauthorized modification; availability would require authorized people being unable to use the system.

Secrets have a lifecycle: created, stored (at rest), moved (in transit), displayed, shared, archived, deleted. Each stage needs a control. Encryption at rest helps a stolen laptop. Encryption in transit (HTTPS/TLS) helps on hostile networks. Access control decides who may open the door before encryption even matters. Minimization means you never collected the extra field that later leaked. Defenders who only encrypt and never think about sharing links still lose confidentiality to a mis-sent URL.

Screen lock is still a confidentiality control in physical space. An unlocked phone on a café table hands whoever sits down the same session cookies and mail the owner had open. Device encryption without a lock is weaker in practice because the OS may already have keys unlocked for the signed-in user. Module 1's "lock the door" habit belongs here: Confidentiality fails when unauthorized eyes can read, whether those eyes arrived through a network or through an empty chair. Credential stuffing is the remote cousin — reused passwords hand mail to strangers without them ever touching your laptop.

Encryption transforms readable data (plaintext) into ciphertext so an interceptor without the key sees gibberish. It is a confidentiality mechanism for data at rest (full-disk / phone encryption) and in transit (HTTPS). It does not by itself prove who you are talking to — certificates and name checks matter — and it does not stop someone who already has your unlocked session. Encryption also does not equal integrity by itself; separate mechanisms (MACs, signatures, hashes) detect change. For this lesson: when the goal is "eavesdroppers cannot read the contract," encryption is the right pillar language.

Practical habit: prefer https:// destinations you navigate yourself for banking and mail. Click the padlock only on sites you intended to visit — never as an excuse to follow a phishing link. On devices you own, confirm screen lock and device encryption are on so a lost phone is not an open archive. You will deepen crypto later in the topic; today you need the mechanism: without authorization and without the key, the content should stay unreadable.

Access controls — passwords, MFA, roles, biometrics — decide who may open the door before they see the file. MFA raises the cost of a stolen password. Roles bind permissions to job need. Biometrics unlock a device you possess; they are not a reason to share that device. Access control fails confidentiality when accounts are shared, when offboarding leaves ex-employee tokens alive, or when everyone is an admin "for convenience."

Need-to-know and least privilege shrink blast radius: marketing should not browse HR payroll by default; a support tool should not export every customer's full ID by default. Data minimization and masking reduce what exists to steal — receipts that print ****1234, logs that store hashes instead of raw secrets, forms that do not ask for data they never use. The fewer secrets in motion, the fewer confidentiality failures a single mistake can cause.

Sharing settings are where many personal confidentiality failures actually happen. "Anyone with the link" is convenient and invisible until the URL lands in a group chat or search index. Review cloud shares the way you would review who has a spare house key: named people, expiry when possible, no public links for tax PDFs or ID scans. Confirming a padlock on a bank site you typed yourself protects transit; tightening a share protects the copy at rest in someone else's browser history. Both are Confidentiality. Neither requires attacking a network.

These checks are on your own sites and devices. They are not instructions to intercept other people's traffic or to "test" a company's encryption. Navigate yourself; observe padlocks; tighten sharing on one file you own.

1. Visit your bank or email in a NORMAL tab you navigated to
2. Look for the padlock / "Connection is secure"
3. Click the lock → confirm HTTPS and a sensible certificate owner name
4. Prefer https:// addresses you type yourself — not links from strangers

Settings → search "encryption" / "lock screen"
- Screen lock ON
- Device encryption ON (most modern phones enable this by default)

mkdir -p "$HOME/cyberlium-lab"

whoami

whoami
mkdir -p "$HOME/cyberlium-lab"
cd "$HOME/cyberlium-lab"

curl -I https://example.com

date > conf-notes.txt
chmod 600 conf-notes.txt

whoami
New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\cyberlium-lab" | Out-Null
curl.exe -I https://example.com

Confidentiality keeps unauthorized eyes off the data through encryption, access control, least privilege, and minimization. Next — Integrity — we protect the data from silent tampering even when someone can already touch the system or when a download claims to be "the official installer."