Cybersecurity Career Foundations · Beginner · ~10 hours
Cybersecurity Fundamentals
Understand the principles, threats and controls behind modern cybersecurity.
Status: Catalogue ready. This lesson version is available in review mode while subject-matter, accessibility and assessment checks are completed.
Security thinking and protective controls
Security goals and threat modelling
By the end of this lesson
- Explain confidentiality, integrity and availability using everyday workplace examples.
- Describe a simple threat-modelling process that starts with assets, actors, events and controls.
- Prioritise defensive actions by impact, likelihood and practical context.
Security protects things people depend on
Cybersecurity begins with a question that is more useful than “which tool should we buy?”: what are we trying to protect, from what, and for whom? An organisation may need to protect customer records, payment details, product designs, staff identities, service availability or the trust that allows people to use a service. Those assets have different owners, different consequences and different acceptable levels of risk. A small internal document and a public booking system should not automatically receive the same controls, even though both deserve sensible care. The classic security goals are confidentiality, integrity and availability. Confidentiality means that information is only seen by people or systems that should see it. Integrity means that data and configuration are accurate and have not been changed in an unauthorised or unnoticed way. Availability means that an authorised person can access a service or record when it is needed. These goals can pull in different directions. Strong access restrictions may improve confidentiality but create a support burden if people cannot reach essential information. A resilient service may remain available while temporarily offering less functionality. Good security makes those trade-offs explicit rather than pretending that one control solves every problem. Threat modelling is a structured way to examine those trade-offs before an incident. A beginner can identify an asset, map how it is used, ask what could go wrong, and record the existing or proposed controls. The process is not a prediction of every possible event. It is a conversation that makes important assumptions visible. For each threat, record the affected asset, the possible harm, the conditions that would make it more likely, the controls already present and the evidence needed to make a better decision. Keep the language factual and avoid labelling people as threats simply because of their role or location. A useful model also distinguishes a threat from a vulnerability and a risk. A threat is a potential cause of harm, such as a stolen password or a service outage. A vulnerability is a weakness or condition that could make the threat easier to realise, such as shared accounts or an untested recovery process. Risk describes the possibility and consequence of that harm in a particular context. The purpose is not to produce a dramatic list; it is to decide which improvements are proportionate and who owns them.
From risk list to defensive decision
A threat model becomes useful when it leads to a decision that can be checked later. Suppose a fictional clinic stores appointment information in a cloud application. The asset is not only the database; it also includes the staff workflow, the availability of the appointment service and the people whose information is held there. A risk statement could say: “If a staff account is taken over, an unauthorised person may view appointment details; the impact is a privacy incident and loss of trust.” That statement is more actionable than “cyber attack risk” because it names the asset, event and consequence. Controls can be preventive, detective, corrective or compensating. A unique account and multi-factor authentication help prevent unauthorised use. Logs and alerts help detect suspicious activity. Backups and an incident plan help correct or recover from damage. A manual verification process may compensate temporarily when a technical control is unavailable. Controls should be connected to the risk they address and tested in a way that does not create new exposure. A policy that nobody understands is not a strong control merely because it is written down. Prioritisation needs evidence and context. A high-impact event that is unlikely but difficult to recover from may deserve attention before a frequent but low-impact nuisance. Cost, staff capacity, legal obligations and service dependencies all matter. Avoid pretending to calculate precise percentages when the organisation has no reliable data. A simple high, medium or low rating with a written rationale can be more honest. Review the model when the service, data, supplier or workflow changes, and record who accepted any remaining risk. Good threat modelling is collaborative. Product, operations, support, data protection and technical teams may each see a different failure mode. A learner should be able to explain the model to a non-specialist, ask for missing context and record disagreement respectfully. The goal is not to win an argument or blame the person who made an earlier decision. It is to improve the organisation's ability to notice, reduce and recover from harm.
Workplace example
Brightwell Health Services is reviewing a new appointment portal. The product owner lists appointment data, staff accounts and service availability as assets. A workshop identifies account takeover, accidental disclosure and an outage as different risks, then assigns owners for identity controls, logging and recovery testing.
Try this walkthrough
- 1.Name one asset, its owner and the people who depend on it.
- 2.Describe one plausible unwanted event without giving instructions for causing it.
- 3.Record the impact, existing controls, remaining uncertainty and a proportionate next action.
Watch for these traps
- Treating a threat list as a prediction rather than a decision aid.
- Confusing a vulnerability with the person or team who owns a system.
- Assigning precise risk scores without evidence or a clear rationale.
- Selecting a product before understanding the asset and the harm being reduced.
Knowledge check
Choose the response you think is strongest. These checks are practice until the course version has passed subject-matter review; graded attempts will be handled server-side.
For the reviewed pilot, answers are checked on the server. This draft result is not yet added to your official learning record.
Practice studio
Make a decision. Test a response. Leave evidence.
Use the case from this lesson to practise judgement without creating a score or changing your course record.
Scenario decision
Brightwell Health Services is reviewing a new appointment portal. The product owner lists appointment data, staff accounts and service availability as assets. A workshop identif…
Choose a response
Branching roleplay
A colleague asks you to move this situation forward. What do you say next?
Evidence workspace
Draft a short known / assumed / next note from the fictional case. Use fictional details only.
This is a session-only practice draft. It is not saved, graded or added to your learning record. Never enter real personal or confidential information.
Practical assignment
Create a five-row defensive risk register for a fictional online appointment service. For each row include the asset, unwanted event, impact, existing control, uncertainty and one owner for the next review. Do not include exploit steps or real personal data.
Pass this lesson's knowledge check before recording it as complete.
Portfolio evidence
Practical portfolio project
Review a fictional organisation's security posture, identify key risks and propose a prioritised set of defensive controls.
Turn the practical project into a bounded evidence record. Save a draft while you work, then submit it for human review when it is ready.
Sign in to save practical evidence. Sign in