Cybersecurity Foundations

If you are a child, think of it like this. The internet is a busy city. Cybersecurity is how we do four things.

1. Lock doors that should be locked
2. Check who is allowed in
3. Notice when something looks wrong
4. Have a plan for when mistakes happen

Four terms people mix up

Let’s define four common terms precisely, using simple language.

• Vulnerability?
• Exploit?
• Incident?
• Breach?

Notice the difference.

1. A vulnerability can exist even if nobody uses it.
2. An exploit is about how the weakness is used.
3. An incident is about what happened and whether it needs response.
4. A breach is about impact. One example is confidentiality being broken.

What this course deliberately does not teach

This course is defensive and ethical. It does not teach you to break into systems. It teaches you to understand risk, spot weak assumptions, and choose controls that protect people.

Here is a short story that shows what "cyber" looks like in real life. A finance team gets an email that looks like a supplier. The invoice is correct. The tone is correct. The bank details are new. The team is under pressure. They pay. A week later the supplier calls to chase payment. Nobody was hacked in a dramatic way. It was an identity failure plus a weak process. The outcome was still real loss.

In 2023, UK outsourcing company Capita experienced a data breach that affected 6.66 million people. The direct cost was over £25 million, plus a £14 million fine. But the reputational damage was worse. Capita lost major contracts, their share price dropped, and clients lost trust. When you handle data for hundreds of organisations, one security failure affects everyone.

In 2017, Equifax failed to patch a known vulnerability. The result was a breach of 147 million people's personal information. Equifax paid $700 million in settlements and fines. Their CEO, CIO, and CSO all resigned. The company's reputation was destroyed. The cost of patching that vulnerability would have been a fraction of what they paid after the breach.

If you are responsible for security, getting it wrong does not just affect you. It affects your team, your organisation, your customers, and potentially your career. The average cost of a data breach in the US is $10.22 million. But beyond the money, there is reputational damage that can take years to recover from. Companies can lose 2.1% of their market value within two days of announcing a breach.

The best security work is often invisible. It is clear boundaries, clear logs, and controls that survive an incident report. It is patching known vulnerabilities promptly. It is verifying identities before making payments. It is understanding that security is about reducing risk, not eliminating it. And it is knowing that the cost of prevention is always less than the cost of a breach.

Everyday example. If you leave your house key under a plant pot, the threat is someone trying doors, the vulnerability is the predictable hiding place, and the risk depends on your street, your neighbours, and what happens if someone gets inside.

Common mistake. Treating cybersecurity as a list of scary words, instead of a habit of checking assumptions. Another common mistake is over focusing on rare, advanced attacks while ignoring the easy ones that happen daily.

Why it matters. When you separate threat, vulnerability, and risk, you stop guessing. You can choose the control that reduces harm most, and you can explain that choice to a manager without waving your hands.

After this section you should be able to

1. Explain what cybersecurity is and what it is not
2. Use the terms vulnerability, exploit, incident and breach correctly
3. Explain why security is about trade offs and context

Risk is contextual. The same control can be essential in one place and pointless in another. A strict password policy does not help if the real attack path is a shared admin account. A fancy monitoring tool does not help if nobody knows what to do when it alerts. Controls without context turn into theatre. They look reassuring and then fail at the worst time.

We will use one simple example for the rest of Foundations. Imagine a small clinic with an online booking system. The key assets are the patient data, the appointment schedule, the staff time, and the clinic's ability to operate. The threats include phishing, stolen passwords, ransomware, and honest mistakes. The vulnerabilities include reused passwords, no multi-factor authentication (MFA), and missing backups. The risk is how those realities combine for this clinic, not a generic list from a template.

In real organisations, this is how risk conversations should sound. "If this fails, who gets hurt, how quickly, and how would we know." This is why asset lists and data classification exist, even when they feel like paperwork. They make priorities explicit.

Everyday example. Your phone is an asset, but so is your ability to get into your bank account. If your phone is lost, the worst case is not "my phone is gone." The worst case is "my identity is used to reset accounts." The asset is not the device. The asset is what the device unlocks.

Common mistake. Starting with controls and tools instead of starting with assets and outcomes. People often buy a scanner, a dashboard, or an audit template before they can answer what they are protecting and why.

Why it matters. When you get the asset and context right, you can spend effort where it reduces harm. You stop doing security theatre and start doing risk reduction.

After this section you should be able to

1. Explain why risk is contextual and what breaks when controls are applied blindly
2. Explain how assets, threats, and vulnerabilities connect to real decisions
3. Explain why Identify work comes before tool buying

Identity is now the security perimeter because work happens everywhere. Staff work from home. Phones are used for approvals. Vendors have access. Cloud services connect to other cloud services. The question is no longer only "is the network safe". The question is "who is this, and what should they be allowed to do".

In real organisations, identity failures show up as shared accounts, stale accounts, "temporary" exceptions that become permanent, and approvals done on the wrong channel. This is where audit findings come from, but it is also where incidents come from.

Everyday example. Handing someone your house keys is authorisation. Checking their ID at the door is authentication. If you give a spare key to a neighbour "just in case" and never take it back, you created a long lived trust decision without noticing.

Common mistake. Treating identity as a user experience detail instead of a safety system. Another common mistake is giving broad permissions because it is easier, then being surprised when something bad happens quickly.

Why it matters. When identity is strong and access is narrow, a compromised account does not automatically become a full breach. It buys time. It limits harm. It makes detection and recovery possible.

After this section you should be able to

1. Explain the difference between authentication and authorisation
2. Explain what breaks when identity is treated as a soft control
3. Explain why least privilege reduces blast radius during incidents

If you are building or reviewing a system, the safer approach is this.

1. Parse inputs using a trusted parser for that format
2. Validate based on the expected structure and context
3. Encode outputs in the correct context. Examples include HTML, URL, JSON

Hashing is one way. You cannot reverse it. It is used for integrity checks and for storing passwords with specialised password hashing. Encryption is two way. You can decrypt with a key. It is used for confidentiality in transit and at rest.

1. Hashing is one way and it is not reversible
2. Encryption is reversible with the correct key
3. A common mistake is storing passwords with a fast hash such as SHA 256. Use bcrypt, Argon2, or scrypt instead
4. Rainbow tables are precomputed hashes of common passwords. Salts help prevent simple lookups. Password hashing schemes handle salts for you

After this section you should be able to

1. Explain why representation and parsing mistakes create security risk
2. Explain what breaks when systems disagree on how bytes should be interpreted
3. Explain why integrity controls depend on correct data handling

Prevention alone fails. Not because people are lazy, but because systems are complex. Something will slip. A password will leak. A laptop will go missing. A supplier will get compromised. Defence needs layers, and it needs feedback.

This aligns to the NIST Cybersecurity Framework 2.0 Protect, Detect, and Respond functions. Protect reduces likelihood. Detect reduces time to notice. Respond reduces harm and recovery time. Cyber Essentials Plus focuses on practical technical controls that support this loop. Examples include secure configuration, access control, malware protection, patch management, and boundary protections.

In real organisations, this is the difference between "we think it was this account" and "we can show the exact sequence of actions." It is also why detection engineering is a real job. Good teams treat detection as a product that is tuned, tested, and improved.

Everyday example. If a fire alarm goes off but nobody knows which room triggered it, everyone wastes time. If the alarm logs the room and the time, you can respond quickly and avoid a full building panic.

Common mistake. Turning on every log and then drowning in noise, or logging nothing and then trying to do forensics with guesses. Another common mistake is writing an incident plan that nobody has rehearsed.

Why it matters. Detection and response are how you limit harm when prevention fails. You cannot undo a breach with wishful thinking. You need evidence, speed, and clear ownership.

Under the hood, data still moves as packets. A packet has a header and a payload. The header is the envelope that tells the network where it is going. The payload is the content. Even when the payload is encrypted, metadata can still reveal behaviour. That is why monitoring often starts with patterns, not secrets.

1. HTTPS uses HTTP with TLS. It protects data in transit between browser and server. It does not hide all metadata.
2. DNS stands for Domain Name System. It turns names into IP addresses. DNS can be attacked or manipulated, which is why secure DNS options exist.
3. VPN stands for Virtual Private Network. It creates an encrypted tunnel to a VPN provider. It can protect traffic from local observers, but the VPN provider still becomes a point of trust.
4. Network segmentation means separating networks by trust level or function. It limits blast radius when something is compromised.

1. Man in the middle, often shortened to MitM. An attacker tries to intercept traffic. TLS and certificate validation help.
2. DNS hijacking. An attacker tries to redirect name lookups. DNSSEC and encrypted DNS help.
3. Packet sniffing. An attacker captures traffic. Encryption helps.
4. ARP spoofing. An attacker tries to confuse devices about who is who on a local network. Monitoring and secure network design help.

Your home network is an attack surface too. Consider four areas.

1. Router. Default passwords, firmware updates, guest network
2. IoT devices. Smart speakers, cameras, and thermostats often have weak security
3. WiFi. WPA3 where possible, strong passphrase, guest network separation
4. Devices. Phones, laptops, and tablets need updates and protection

A compromised smart camera can be used to spy on you, launch attacks on other devices, or join a botnet for distributed denial-of-service (DDoS) attacks. Security isn't just about corporate networks.

After this section you should be able to

1. Explain why trust boundaries exist and what breaks when networks are assumed safe
2. Explain how metadata can leak behaviour even when content is encrypted
3. Explain why monitoring often starts with patterns, not secrets

To keep this practical, we will use one simple frame. Confidentiality, integrity, and availability are often shortened to CIA. Confidentiality means only the right people can see information. Integrity means changes are correct and visible. Availability means systems are there when needed. The purpose is not to memorise three words. The purpose is to ask better questions.

In plain language, confidentiality is about privacy, integrity is about truth, and availability is about being able to function. Most incidents are one of these three, usually with a second one following close behind.

When identity is weak, confidentiality fails. When changes are untracked, integrity fails. When backups are missing, availability fails. Good governance makes those failures less likely because it makes the decisions explicit and reviewed.

In real organisations, CIA is how you explain impact to non security people. A leader might not care about a vulnerability ID, but they do care about "patients could not be seen" or "invoices were changed" or "private data leaked." CIA translates technical failures into outcomes.

Everyday example. Confidentiality is your bank statement being private, integrity is your balance being correct, and availability is being able to pay for groceries when you are at the checkout.

Common mistake. Thinking CIA is a checklist where you must maximise all three at once. In practice you trade. Tight security might reduce availability if you lock out staff too often. High availability might reduce confidentiality if you spread access too widely. The job is to choose wisely and explain the trade.

Why it matters. CIA is a simple way to reason about controls and to spot what kind of harm you are actually preventing. It helps you avoid security theatre and focus on outcomes.

After this section you should be able to

1. Explain CIA as decision questions, not memorised words
2. Explain what breaks when identity is weak or integrity is not monitored
3. Explain why availability needs planning, not hope

Humans are not the weakest link. Humans are the system. Most insecure behaviour is a rational response to a bad setup. If it takes five minutes to do the safe thing, people will do the fast thing. If approvals block urgent work, people will route around them. If security tools produce noise, people will ignore them.

Real organisational failures are often not technical. They are unclear ownership, unclear priorities, and no rehearsal for bad days. The paperwork shows up after the incident, usually with a new template and a tired team.

In real organisations, governance shows up as: who is allowed to approve exceptions, how access is granted and removed, how incidents are escalated, and what gets funded. Good governance is boring in the best way. It makes security decisions repeatable instead of emotional.

Everyday example. If nobody is clearly responsible for locking up at night, it eventually becomes "someone will do it." That is not a plan. Governance is deciding who locks up, how you check, and what happens if it is missed.

Common mistake. Blaming individuals for predictable system failures. Another common mistake is writing policies that describe an ideal world and then punishing people for living in the real one.

Why it matters. Human factors and governance are what make security sustainable. Without them, controls decay, exceptions pile up, and the organisation only gets serious after harm has happened.

After this section you should be able to

1. Explain why humans are part of the system and what breaks when processes are unrealistic
2. Explain governance as ownership of trade offs, not documents
3. Explain why clear roles and rehearsed response reduce harm

Privacy is a security property. It is about reducing harm from unnecessary collection, unnecessary sharing, and unnecessary retention. If you collect less data, there is less data to leak. If you keep data for less time, there is less to steal later.

This capstone is about turning learning into action. Choose a small set of changes you can explain. Make them real. Keep it calm and practical.

This is Foundations. Move into Applied next once you can explain every term on this page to another person and show them how the tools work.