Free learning route
Security fundamentals
You will learn how security people think: what they protect, who they defend against, how attacks are described, and how controls are chosen. You will threat model a fictional company and write findings that someone could act on. Pen and paper only.
For: Anyone who wants to understand how security actually works before specialising, including people moving from support, operations, business or AI roles with no coding background.
Before you start: None. No coding, no lab, no account, no tools to install.
First session: about 35 minutes. Times are estimates; work at your own pace.
Tick completed steps to save progress in this browser. No account or quiz needed. Clearing browser data removes progress.
What you will be able to do
- Describe an asset, threat, vulnerability and risk, and tell them apart in a real sentence
- Threat model a small fictional system and produce a ranked list of what could go wrong
- Map a control to the thing it actually prevents, and say what it does not cover
- Write a finding with impact, likelihood and a specific recommendation, in the format a reviewer expects
Start now · about 25 minutes
Threat model a fictional loyalty app on one page
- Write down this fictional system: Northwind Bikes has a loyalty web app. Customers sign in with email and password, see their points balance, and can redeem points for vouchers. Two staff have an admin page that can adjust any customer's points. The app stores name, email, postcode and points in one database. It runs on a cloud server, backed up nightly to the same cloud account. For this exercise, assume there are 40,000 fictional customer records, staff sign in with only a password, and the admin page allows unrestricted export. These are scenario assumptions, not findings about a real system.
- List the assets, meaning the things worth protecting. Aim for five, and include at least one that is not data.
- For each asset write who would want to harm it and what they would want: a customer trying to get free vouchers, a criminal after the email list, a careless admin, and an attacker who has stolen a staff password.
- For each of those four, write the one thing that would have to go wrong first for them to succeed. That first step is the one you will recommend a control for.
- Rank your four scenarios by how bad the result would be for the business, not by how technically interesting they are, and write one sentence saying why your top one is top.
Done when: You have a one-page note listing five assets, four named threat scenarios with a first-step-to-fail each, and a ranking justified by business impact rather than technical novelty.
Lesson 1 · about 30 minutes
Assets, threats, vulnerabilities and risk
An asset is something worth protecting: customer data, a payment process or the ability to keep trading. A threat is a potential cause of harm, such as an attacker, an accidental deletion or a power outage. A vulnerability is a weakness that could make that harm possible. Risk considers the likelihood and impact of the harm in this particular situation.
Saying 'we have a vulnerability' does not explain the decision a manager needs to make. In our fictional app, a stolen staff password could expose 40,000 records because the admin page has no second authentication factor and permits unrestricted export. That describes a threat scenario, a weakness and the information at risk. It still needs evidence before it could be a finding about a real system.
Three common security goals are confidentiality (only authorised people can read information), integrity (information remains accurate and changes are authorised) and availability (a service works when needed). This is the CIA triad. Priorities depend on the system: a hospital must consider both timely access to records and the harm of disclosure or incorrect treatment data.
A control reduces risk. Preventive controls try to stop harm, detective controls help notice it and corrective controls help recover. For example, multi-factor authentication, or MFA, requires more than one kind of proof when signing in; an alert can flag suspicious access; a tested backup can restore lost information. No single control covers every failure.
Try it
Take your fictional loyalty app note from the first task. For your top-ranked scenario, write four labelled lines: Asset, Threat, Vulnerability, Risk. Then write one line naming which of confidentiality, integrity or availability is most at stake.
Check your answer
For this fictional scenario: asset, the customer records; threat, credential theft followed by misuse; vulnerability, password-only staff access and unrestricted export; risk, the possibility of a large disclosure with financial or privacy consequences. Confidentiality is most directly affected. Likelihood and notification duties need further evidence, not a guess. A threat can also be accidental or environmental; it need not involve an attacker.
Read more
- NCSC Small Business Guide
Free UK government guidance, no account. Five short sections; the plainest introduction to what basic controls exist and why.
- NCSC 10 Steps to Cyber Security
Free. Read the overview page to see how an organisation groups controls. Do not try to memorise it; use it as a checklist later.
- CISA Secure Our World
Free US government basics on passwords, MFA, phishing and updates. Useful for explaining controls to non-specialists.
Lesson 2 · about 30 minutes
Threat modelling: four questions, in order
Threat modelling asks four questions: what are we building, what can go wrong, what will we do about it, and did we do a good enough job? Start with the system and the people who use it, rather than choosing security products first.
Draw the components that process or store data, the people who use them and arrows showing the data flows. Mark where different permissions or assumptions about trust apply. These are trust boundaries, such as a customer browser sending data to a server. They help you decide where the server must validate a request or enforce access.
One prompt list is STRIDE: Spoofing (pretending to be someone else), Tampering (unauthorised changes), Repudiation (disputes about actions that cannot be resolved from evidence), Information disclosure, Denial of service and Elevation of privilege (gaining permissions you should not have). Use the list to question each component and data flow. It helps you look systematically; it does not guarantee a complete review.
Match controls to a specific scenario and state what remains possible. MFA can prevent a stolen password alone from being enough, but it does not stop misuse by an authorised staff member. Export limits can reduce the amount disclosed; logging and alerts can help detect misuse. A rate limit is preventive, while an alert is detective. Phishing-resistant authentication can address risks that one-time codes do not.
Try it
Sketch the fictional loyalty app and walk STRIDE across the sign-in, points and admin flows. Write a plausible issue for four categories, labelling any new assumptions. Choose one issue and recommend a control, then state what that control leaves unresolved.
Check your answer
Examples include reuse of stolen passwords (spoofing), trusting a points value supplied by the browser (tampering), missing redemption records (repudiation), exposing another user's balance (disclosure), excessive requests preventing sign-in (denial of service) or a missing admin permission check (elevation of privilege). These are hypotheses to test, not facts established by the sketch. A control should address your chosen scenario and have a way to verify it.
Read more
- OWASP Threat Modeling Cheat Sheet
Free, no account. The canonical short version of the four questions and STRIDE. Read it once, then reread after your first model.
- OWASP Top 10
Free. The ten most common weakness categories in web applications, with plain descriptions. Address now redirects to owasp.org/projects/top-ten.
- Application security on this site
Local summary of where these weaknesses appear in real applications, and what to read next.
Lesson 3 · about 30 minutes
Identity, controls and writing a finding people act on
Identity is a useful place to start. Authentication establishes who a user or system is; authorisation determines what it may do. They can fail separately. A site might correctly identify a customer yet let them read another customer's order by changing an ID in a request. The missing check is authorisation.
The two principles worth internalising are least privilege (every person and system gets the minimum access needed, for the minimum time) and defence in depth (assume any single control fails, so layer them). Applied to the fictional loyalty app: staff get admin rights only while on shift rather than permanently, exports are capped and logged, and the nightly backup goes to a separate account so that someone who compromises the app cannot also destroy the recovery path.
Organisations need a shared way to describe all this, which is what frameworks are for. NIST's Cybersecurity Framework groups activity into Govern, Identify, Protect, Detect, Respond and Recover; the CIS Controls give a prioritised list of what to implement first; MITRE ATT&CK catalogues the techniques attackers actually use, so defenders can ask 'would we notice this one?'. You do not memorise these. You use them so your findings land in language the business already reviews.
Write a finding with the issue, location, supporting evidence, likely impact and a specific action with an owner. For the fictional app: password-only access and unrestricted export allow a stolen staff credential to expose customer records. Recommend appropriate MFA, restricting export to staff who need it, and logging and alerting on unusual use. Choose any numerical limit based on business needs and tests, rather than copying a universal threshold.
Try it
Write one finding about your fictional loyalty app in that five-part shape, under 120 words. Then add a single line stating which framework area it belongs to (for example Protect, or identity and access management) so a manager can file it.
Check your answer
Does the finding identify the component, distinguish evidence from assumptions, explain the impact, state the uncertainty about likelihood and give an owner a testable action? Add a check that would demonstrate the fix works. Specific recommendations are useful, but unsupported numbers or severity labels are not evidence.
Read more
- NIST Cybersecurity Framework
Free. Read the six-function overview only; the full documents are reference material, not reading.
- MITRE ATT&CK
Free, no account. Open two or three techniques under Initial Access to see how real attacker behaviour is described and detected.
- CIS Critical Security Controls
Overview is free to read; downloading the full control set requires a free registration form. Optional, not needed for this route.
- Identity and access management on this site
Local summary of authentication, authorisation and least privilege in practice.
Keep what you made
One-page threat model and finding for a fictional system
A single page containing your fictional loyalty app sketch with trust boundaries marked, five assets, four ranked threat scenarios, a STRIDE pass over one trust boundary, and one finding written in the five-part format with a named residual gap. This is the artefact to reuse as a work sample.
- Assets are ranked by business impact, and at least one is not data
- Each threat scenario describes a plausible cause of harm, and assumptions are labelled
- At least one trust boundary is marked on the sketch and one issue is tied to it
- The finding states location, attacker achievement, likelihood, specific recommendation and owner
- The residual gap left by your recommended control is written down, and the whole page uses only fictional data
Completing a route records your practice, not a qualification or proof of job readiness.
Where to go next
- AI security fundamentals →
Take this next once you can threat model a normal system, because AI security is this discipline applied to models, prompts and agents.
- AI fundamentals →
Do this first instead if you cannot yet explain what a large language model is and how it fails.
- Governance, risk and compliance →
Go here if the framework and reporting side interested you more than the technical attack side.