Threats in plain words

Security is not about stopping every possible attack. It is about knowing what you care about, who might go after it, and which few habits stop the attacks that actually happen. By the end of this lesson you can write a threat model for yourself in five minutes.

Three questions: a threat model

A threat model is a short, honest answer to three questions:

Question	What it means	Example answer for a student developer
What do I protect?	Your assets: the things that would hurt to lose or leak	Email account, GitHub account, laptop, a cloud API key, photos
From whom?	The threats: who or what could cause the harm	Scammers sending fake emails, bots trying leaked passwords, a thief, a dying disk
How?	The controls: the habits and tools that block each threat	A password manager, two-factor sign-in, a disk password, backups

Notice that "a dying disk" is on the list. A threat does not have to be a person. Anything that makes you lose or leak an asset counts: hardware failure, a mistake, a stolen bag.

Three words you will meet everywhere:

• Confidentiality: only the right people can read it. A leaked API key breaks this.
• Integrity: nobody changed it without permission. A tampered download breaks this.
• Availability: it is there when you need it. A dead disk with no backup breaks this.

Rank by what is likely

You cannot defend against everything, so start with what is likely and costly:

                     COST IF IT HAPPENS
                     low            high
                ┌──────────────┬──────────────┐
LIKELY   high   │ fix soon     │ FIX FIRST    │  password reuse, phishing,
                │              │              │  a secret pasted in a chat
                ├──────────────┼──────────────┤
         low    │ ignore for   │ plan for it  │  stolen laptop,
                │ now          │              │  dead disk
                └──────────────┴──────────────┘

For most people the top-right box holds the same few things: reused passwords, phishing, and secrets left in places other people can read. A spy agency targeting you personally is not in it. Spend your effort where the risk is.

Common attacks, in plain words

Phishing

A message pretends to be from someone you trust (your bank, your university, GitHub, a colleague) and asks you to click a link, sign in, or open a file. The link leads to a copy of the real sign-in page, and whatever you type goes to the attacker.

From:    GitHub Security <security@github-alerts.example>
Subject: Unusual sign-in detected - verify within 24 hours

Click here to keep your account: https://github.com.verify-login.example/

The warning signs: urgency ("within 24 hours"), a sender address that is close but not right, and a link whose real domain is not the company's. In github.com.verify-login.example, the domain is verify-login.example; github.com is only the first part of the name.

What stops it: do not sign in from a link in a message. Open the site yourself, from a bookmark or by typing the address. A password manager helps too: it refuses to fill your password on a look-alike domain.

Password reuse and credential stuffing

Sites get breached, and lists of email-and-password pairs end up for sale. Attackers feed those lists to bots that try the same pairs on hundreds of other sites. This is credential stuffing. If you used the same password on a forum that was breached and on your email, the attacker is now in your email.

What stops it: a different password for every site, kept in a password manager, plus two-factor sign-in on the accounts that matter. Lesson 2 covers both.

Leaked tokens and keys

An API key or token is a password for a program. Developers paste them into code, config files, screenshots, chat messages and bug reports, and from there they reach public repositories and logs. Automated bots search public code for keys around the clock, so a key pushed to a public repository can be found and used within minutes.

What stops it: keep secrets out of code, scan for them before you push, and when one leaks, replace it at once. Lessons 2 and 5.

Machine-in-the-middle on public Wi-Fi

On a network you do not control, someone can set up a hotspot with a familiar name ("Airport_Free_WiFi") and sit between you and the internet. This is a machine-in-the-middle attack: your traffic passes through their device on the way.

 You ─────► Fake hotspot ─────► The real website
            (reads or changes
             anything that is
             not encrypted)

What stops it: HTTPS for websites, host-key checks for SSH, and not turning on sharing or debugging features on networks you do not trust. Lesson 3.

Malware from unofficial downloads

A "free" or "cracked" copy of an app, a fake download button on an ad-filled page, or an APK passed around in a chat group can contain malware: a program that steals passwords, encrypts your files for ransom, or uses your computer for someone else's purposes.

What stops it: install only from the official source, check the checksum when one is published, and keep software updated. Lesson 4.

Lost and stolen devices

A laptop left on a train or a phone taken from a table holds your email, your sessions, your files, and often saved passwords.

What stops it: a screen lock, full-disk encryption (BitLocker on Windows, FileVault on macOS, the encryption option in the Linux installer, built in on modern phones), and a backup so you lose only the device, not the data.

A worked threat model

Priya is a computer science student. She has a laptop, a GitHub account with a few projects, and a cloud account for a class project with an API key.

Asset	Threat	Control
Email account	Phishing; reused password	Password manager, unique password, two-factor sign-in with an authenticator app
GitHub account	Same as email; its tokens leaking	Two-factor sign-in; tokens with an expiry date and only the scopes needed
Cloud API key	Committed to a public repository by mistake	Key in a .env file listed in .gitignore; a scan before each push with DL Sentinel
Laptop	Theft	Screen lock, full-disk encryption
Project files and photos	Disk failure, theft, ransomware	Backups to a second place, for example with CloudDrop

Five rows, about ten habits. That is a threat model, and it covers most of what is likely to go wrong for her.

Stay safe

• Backups are a security control. Ransomware, theft and dead disks all end the same way if you have no copy. Keep at least one copy somewhere other than the device. CloudDrop uploads a folder to your own cloud storage and never deletes anything there; DiskRescue can sometimes recover photos from a failing drive, but recovery is the last resort, not the plan. See the Files, backups and recovery track.
• Slow down on urgent messages. Urgency is the attacker's main tool. A real bank or service will still be there in ten minutes, when you have opened its site yourself.
• Revisit your threat model when something changes: a new job, a public project, a crypto wallet. New assets bring new threats.

Check yourself

QuizThreats in plain words

Question 1 of 6

Which three questions make up a simple threat model?

Score: 0

What you learned

• A threat model answers: what do I protect, from whom, and how.
• Start with what is likely and costly: reused passwords, phishing and leaked secrets.
• Most common attacks are stopped by a few habits: unique passwords, two-factor sign-in, official downloads, HTTPS, screen locks and backups.

Next steps

• Lesson 2: Passwords and secrets
• Auth basics: how sign-in works for APIs
• Files, backups and recovery