What you'll learn this week
- What cybersecurity actually protects, and why "keeping hackers out" is the wrong mental model
- Who attacks systems, what they want, and how that shapes what you defend
- The CIA triad — the three questions you ask about any system
- The rules of this course: everything we attack, we own
- Build your home lab: VirtualBox with an Ubuntu and a Windows virtual machine
- Threat-model something you actually own, and write it up
Security is not a wall
Most people picture security as a wall around a building. Attackers are outside, defenders are inside, and the job is keeping the wall high. It is a comforting picture and it is wrong in a way that will hurt you if you keep it.
Real systems are not buildings. They are more like a busy market: hundreds of people coming and going all day, most of them legitimate, some of them not, and no practical way to stop everyone at the gate. Your staff need to log in from home. Your customers need to reach your website. Your accountant needs to open the invoice that arrived by email. Every one of those needs is also a way in.
So the job is not "keep everyone out". The job is:
Make the bad things hard, make the important things harder, and know quickly when something has gone wrong anyway.
That last part — knowing quickly — is the half that beginners skip, and it is the half this course is built around. By Week 8 you will be running software whose entire purpose is to tell you that something happened.
Nothing is "secure"
There is no such thing as a secure system, in the way there is no such thing as a healthy person who will never get sick. There are only systems that are harder or easier to attack, and organisations that find out sooner or later.
This matters practically. If you are asked "is this secure?", the honest answer is another question: secure against whom, and how would we know? A laptop that is safe against a curious colleague is not safe against a determined criminal group, and neither of those is the same as safe against a government.
That is not pessimism, it is how the work gets prioritised. You cannot defend everything equally, so you decide what matters most and spend your effort there.
The three questions
Everything in this field comes back to three properties, known as the CIA triad — nothing to do with the American agency. We spend a whole lesson on it later this week, but here they are so you start seeing them everywhere:
- Confidentiality — can the wrong people read it?
- Integrity — can the wrong people change it, and would we notice?
- Availability — can the right people get to it when they need it?
A hospital's patient records need all three, but if you forced a choice, availability comes first: a doctor who cannot open a record during an emergency has a problem right now. A bank's transaction ledger leans on integrity: reading a balance you shouldn't is bad, but silently changing one is catastrophic. A journalist's source list is confidentiality above everything — losing it could get someone killed.
Different systems need different amounts of each. Deciding which matters most is a business decision, not a technical one, and it is where security work starts.
What this course is, and is not
This is a defensive course. You are learning to be the person who protects systems and notices when something is wrong — the blue team, in the jargon.
You will see attacks. You have to: you cannot recognise a break-in if you have never seen what one looks like from the inside. But every attack you run in this course happens against machines you built yourself, on your own laptop, disconnected from anything that matters.
That brings us to the one rule that has no exceptions.
The rule
Everything we attack, we own.
Running a scan against a website you do not own is a crime in Nigeria under the Cybercrimes Act 2015, and in essentially every other country. Not a grey area, not a "well I was just curious" — a criminal offence carrying real prison time. The same tools that make you employable make you prosecutable when pointed at someone else's system.
This is not a scare tactic and it is not negotiable. Anyone who scans, probes, or attacks anything outside their own lab is removed from the programme. Your instructor will have you acknowledge this in writing.
The professional version of this rule is: you need permission, in writing, before you touch someone's system. In a job, that permission is a contract or an authorisation letter. Get used to asking for it now.
Try it now
Before the first lab, check your laptop can actually run the course:
- Find your RAM. On Windows:
Ctrl+Shift+Esc→ Performance → Memory. On macOS: → About This Mac. You need 16 GB. 8 GB will not run two virtual machines and a SIEM, and there is no workaround. - Check virtualisation is on. On Windows, in the same Performance → CPU panel, look for Virtualization: Enabled. If it says Disabled, you will need to turn it on in your BIOS — bring this to your instructor in the first session rather than discovering it during the lab.
- Free up 60 GB of disk. The VMs are large and they grow.
If any of those three fail, tell your instructor today. Every one of them takes time to fix and none of them can be fixed during a lab.