Think like a defender: network attack surface, threat modeling, the OWASP Top 10, core controls, identity, cryptography, frameworks and the rules of ethical testing.

Cybersecurity Fundamentals

## Why it matters

Individual controls are easy to list. The hard questions are: **are we covering everything that matters, and what should we do next?** Security frameworks answer those questions with a shared structure. When a manager asks "how mature is our security?", or an auditor asks "how do you detect incidents?", a framework lets you answer in terms everyone recognises. Two of the most widely used are the **NIST Cybersecurity Framework (CSF)** and the **CIS Critical Security Controls**.

## NIST Cybersecurity Framework 2.0

The US National Institute of Standards and Technology (NIST) published CSF 2.0 in 2024. It is voluntary, free, and used by organisations of all sizes around the world, not only in the US. Official site: [nist.gov/cyberframework](https://www.nist.gov/cyberframework). Checked on 2026-10-23.

CSF organises security outcomes into **six functions**:

| Function | Question it answers | Example outcomes |
|---|---|---|
| **Govern (GV)** | How do we set direction and accountability? | Risk strategy, roles and responsibilities, policy, supply-chain risk management |
| **Identify (ID)** | What do we have and what are the risks? | Asset inventory, risk assessment, improvement plans |
| **Protect (PR)** | How do we safeguard it? | Identity and access management, training, data security, platform hardening |
| **Detect (DE)** | How do we find attacks and anomalies? | Continuous monitoring, analysis of suspicious events |
| **Respond (RS)** | What do we do during an incident? | Incident management, analysis, reporting, containment |
| **Recover (RC)** | How do we restore normal operations? | Executing recovery plans, communicating during recovery |

**Govern** was added in version 2.0. It sits at the centre because the other five depend on leadership decisions: who owns risk, how much risk is acceptable, and how security is funded.

Each function is divided into **categories** and **subcategories** (specific outcomes). CSF tells you **what** to achieve, not exactly **how**: it points to other standards for detailed controls. Organisations use it to build a **current profile** (where we are) and a **target profile** (where we want to be), then plan the gap.

## CIS Critical Security Controls

The Center for Internet Security (CIS) publishes the **CIS Controls**: a prioritised list of 18 practical safeguard areas, written by practitioners based on how real attacks succeed. Official site: [cisecurity.org/controls](https://www.cisecurity.org/controls). Checked on 2026-10-23.

The first few controls show the thinking: you cannot protect what you do not know about.

1. Inventory and control of enterprise assets
2. Inventory and control of software assets
3. Data protection
4. Secure configuration of enterprise assets and software
5. Account management
6. Access control management
7. Continuous vulnerability management
8. Audit log management

Later controls cover email and browser protections, malware defences, data recovery, network infrastructure, security awareness training, service providers, application software security, incident response and penetration testing.

Each control contains specific **safeguards**, grouped into three **Implementation Groups**:

- **IG1** ("essential cyber hygiene"): the minimum every organisation should do, sized for small teams with limited IT staff.
- **IG2**: adds safeguards for organisations with more complex environments and sensitive data.
- **IG3**: everything, for organisations facing skilled, targeted attackers.

## How they fit together

CSF is the **map**: it tells you which outcomes matter and lets you describe maturity to leadership. The CIS Controls are a **to-do list**: specific, prioritised safeguards you can implement. CIS publishes mappings from its safeguards to CSF, so many teams use CSF for reporting and CIS IG1 as the starting work plan.

## Worked example: mapping controls to CSF functions

A small company lists what it already does. Mapping each control to a CSF function shows where the gaps are:

| Control | CSF function |
|---|---|
| Board-approved security policy naming the IT manager as owner | Govern |
| Spreadsheet listing every laptop, server and cloud account | Identify |
| Yearly risk assessment of the customer database | Identify |
| MFA on email and the cloud console | Protect |
| Automatic OS and browser updates | Protect |
| Phishing awareness training | Protect |
| Alerts on logins from new countries | Detect |
| Written incident response plan with phone numbers | Respond |
| Offline backups tested by a quarterly restore | Recover |

Reading the table, Protect is strong but Detect has only one item, and nothing covers reviewing logs for unusual activity. That points to the next investment: centralised logging and alert review (CIS Control 8, audit log management). This is exactly how frameworks are used day to day.

## Common mistakes

- **Treating a framework as a certificate.** CSF is not something you "pass"; it is a way to measure and plan.
- **Implementing everything at once.** Start with the essentials (asset inventory, MFA, patching, backups, logging) and grow.
- **Skipping Govern.** Without clear owners and agreed risk tolerance, controls get bought but not maintained.
- **Copying another organisation's profile.** Your target depends on your own risks, data and resources.

## Quick recap

- NIST CSF 2.0 has six functions: Govern, Identify, Protect, Detect, Respond, Recover. Govern is new in 2.0.
- CSF describes outcomes (what), not specific controls (how); profiles compare where you are with where you want to be.
- CIS Controls are 18 prioritised, practical control areas with safeguards in three Implementation Groups; IG1 is essential hygiene.
- Use CSF to find and explain gaps, and CIS safeguards to close them.


Map everyday security controls to the six NIST Cybersecurity Framework functions and the CIS Critical Security Controls.

Frameworks: NIST CSF and CIS

The NIST Cybersecurity Framework (CSF) 2.0

Strengthen Cybersecurity Posture with the CIS Critical Security Controls

## Why it matters

The tools and techniques of attackers and defenders are the same. A port scan, a password-guessing script or an XSS payload is a legitimate test in one situation and a crime in another. The difference is not skill or intent; it is **authorisation**. Understanding this protects you, your employer and the people whose systems and data you touch. This lesson is general awareness, not legal advice: laws differ by country and state, and professionals check with their organisation's legal team before testing.

## The core rule

**Only test systems you own, or systems whose owner has given you explicit, written permission, and only within the scope they agreed.**

"I was only looking", "the server was misconfigured", "I didn't change anything" and "I was going to report it" are not authorisation.

## The laws, in brief

Most countries have laws against accessing computers without permission:

- **United States: Computer Fraud and Abuse Act (CFAA).** It makes it a crime to access a computer "without authorization" or to exceed authorized access, and to cause damage. Many states have their own computer crime laws too. In 2022 the US Department of Justice announced a policy of not charging good-faith security research under the CFAA, but that is prosecutor policy, not a legal shield: civil lawsuits, state laws and other countries' laws still apply.
- **United Kingdom: Computer Misuse Act 1990.** Unauthorised access, access with intent to commit further offences, and unauthorised acts that impair a computer are all offences.
- **Elsewhere:** the Council of Europe's Budapest Convention on Cybercrime has been adopted by many countries, and most have similar offences.

Data protection laws (such as GDPR in Europe) add duties when testing involves personal data, even with permission.

## What authorisation looks like at work

Professional penetration testers and red teams never start without paperwork:

- **A contract or statement of work** with the system owner, signed by someone who actually has authority over those systems.
- **Scope**: exactly which domains, IP ranges, applications and accounts are in, and which are out. Third-party services (a cloud provider, a SaaS tool) usually need their own permission or have published testing rules.
- **Rules of engagement**: allowed techniques (is social engineering allowed? denial of service?), testing hours, how to handle sensitive data found, and who to call if something breaks.
- **A "get out of jail" letter**: a signed authorisation the tester can show if questioned.

If anything is unclear, stop and ask in writing before continuing.

## Ethics beyond the law

Being legal is the minimum. Professional codes of ethics (from bodies such as ISC2 and EC-Council, and CompTIA's candidate code of conduct) add expectations:

- Protect the confidentiality of anything you see. Take only the minimum evidence needed.
- Do no harm: avoid actions that could take systems down or destroy data, even within scope.
- Report honestly, including your own mistakes.
- Do not use access for anything beyond the agreed purpose.

## Responsible (coordinated) disclosure

Sometimes you find a vulnerability by accident, for example a website that shows other customers' orders when you change a number in the URL. **Coordinated vulnerability disclosure** is the accepted way to handle it:

1. **Stop.** Do not explore further, download data or "prove" the impact. Note only what you saw.
2. **Find the right contact.** Look for a `security.txt` file (a standard defined in RFC 9116) at `https://example.com/.well-known/security.txt`, a vulnerability disclosure policy, or a bug bounty programme page.
3. **Report privately** with clear, minimal details: what you saw, where, when, and how to reproduce it safely.
4. **Give the owner time to fix it**, commonly around 90 days, and agree on any public write-up.
5. **If you get no response**, national coordination centres (such as CERT/CC in the US) can help.

Many organisations publish a **vulnerability disclosure policy** (VDP) that promises not to take legal action against good-faith reporters who follow its rules. **Bug bounty programmes** go further and pay for valid findings, but only within their published scope and rules. Testing outside the scope, or breaking the rules, removes that protection.

## Worked scenarios

| Situation | Authorised? | What to do |
|---|---|---|
| Scanning the laptop and VM you own on your home network | Yes | Go ahead; keep it on your own network |
| Your employer asks you, by email, to "check the website's security" | Unclear | Get written scope, rules of engagement and sign-off from someone with authority |
| Testing a company's main website because it has a bug bounty | Only within the programme's scope | Read the scope and rules first; out-of-scope assets are off limits |
| Noticing that your school portal shows other students' grades when you change the URL | No further testing | Stop, report privately to the school's IT or security contact |
| Practising on TryHackMe, Hack The Box or PortSwigger's Web Security Academy | Yes, within their rules | These platforms exist to give you legal targets |

## Common mistakes

- **Assuming public means permitted.** A website being reachable from the internet does not give you permission to test it.
- **Scope creep.** Finding a link to another server during an authorised test does not put that server in scope.
- **Verbal permission.** Always get it in writing, from someone who has the authority to give it.
- **"Proving" a bug by taking data.** Downloading records turns a report into a breach.

## Quick recap

- Authorisation, in writing and within scope, is what separates security testing from crime.
- Laws such as the US CFAA and the UK Computer Misuse Act make unauthorised access illegal; good intentions are not a defence. This is not legal advice.
- Professional testing uses contracts, scope and rules of engagement.
- Found something by accident? Stop, report privately through `security.txt` or a disclosure policy, and give the owner time to fix it.


Explain why written authorisation is what separates security testing from crime, and how responsible disclosure works.

Legal and ethical hacking

Ethical Hacking in Action: Red Teaming, Pen Testing, & Cybersecurity

Coordinated Vulnerability Disclosure

Open the official CompTIA Security+ page, download the current exam objectives, and note the exam version, the domains and their weightings.

Make a study tracker (a spreadsheet or notebook) with one row per objective and columns for confidence (1 to 5) and notes. Rate yourself honestly using what you learned in this course.

Write a week-by-week plan for 8 to 12 weeks: which domains you will study each week, your main study resource, and when you will start practice exams.

Install a hypervisor you can use for free (VirtualBox or UTM) and create a host-only or internal network for the lab.

Create or reuse a Linux VM on that lab network, and take a snapshot named "clean".

Add a deliberately vulnerable practice app (for example OWASP Juice Shop or DVWA) on the lab network only, following its official setup instructions. Confirm the lab VM cannot reach your home network.

Do one small exercise from your study plan in the lab (for example, find the practice app's login page and watch its access log while you log in with a wrong password), and write a short defender-focused note about what the logs showed.

Restore your snapshot to confirm you can undo changes, and write down how you will keep the lab isolated.

## Why it matters

Hiring managers for security roles look for two things in a junior candidate: **proof of knowledge** and **proof of practice**. Certifications are the usual proof of knowledge. A home lab, with notes and write-ups of what you built and broke, is the proof of practice. This lesson helps you plan both, honestly and on a small budget.

## The certification path

Certification details (exam versions, objectives, prices, renewal rules) change regularly. Always check the official sites rather than relying on any summary, including this one.

- **CompTIA Security+** is the most common entry-level security certification. It covers threats and vulnerabilities, security architecture, operations, incident response, and governance, risk and compliance: much of what this course introduced. It appears in many junior job postings and in US government and defence contractor role requirements. Official page: [comptia.org/certifications/security](https://www.comptia.org/en-us/certifications/security/). Checked on 2026-10-23.
- **Network+** is useful if networking still feels shaky, but it is not required before Security+.
- **CompTIA CySA+** (cybersecurity analyst) is a common next step for people heading into security operations, covered in the Security Operations & Defense course.
- **ISC2 CISSP** is a senior certification. It requires about five years of paid security experience (an associate status exists for those who pass without it). Official page: [isc2.org](https://www.isc2.org/). Checked on 2026-10-23.
- Cloud security roles also value vendor cloud certifications (AWS, Azure, Google Cloud) alongside Security+.

Some roles also require a degree or a security clearance. A certification helps you get interviews; it does not replace experience, and employers will ask what you have actually done.

## A realistic Security+ study plan

Most people with this course behind them need about **8 to 12 weeks** at 5 to 8 hours a week. A plan that works:

1. **Download the official exam objectives** from CompTIA. This is your checklist; every topic on the exam is listed there.
2. **Pick one main course** (a video series such as Professor Messer's free course, or a book) and one source of practice questions.
3. **Weekly rhythm:** study one or two objective domains, take notes in your own words, and do a short lab for each topic where possible.
4. **Track weak areas** in a simple spreadsheet: objective, confidence 1 to 5, notes. Revisit anything below 3.
5. **Practice exams in the last 2 to 3 weeks.** Review every wrong answer and why the right answer is right.
6. **Book the exam** when you consistently score well above the passing level on practice tests from more than one source.

Beware of "brain dump" sites that sell real exam questions: using them breaks the certification agreement and can get your certification revoked.

## Building a safe home lab

A home lab is a small, **isolated** environment where you are allowed to break things. You do not need expensive hardware: a laptop with 16 GB of RAM can run two or three small virtual machines.

A good beginner lab:

- **Hypervisor:** VirtualBox (Windows, Linux, Intel Macs) or UTM (Apple silicon Macs).
- **Network:** a **host-only or internal network** in the hypervisor, so lab VMs can talk to each other but not to your home network or the internet. Only connect a VM to the internet when you need to download updates, and never expose deliberately vulnerable machines to the internet.
- **Machines:**
  - A Linux VM you administer (you built one in Linux Administration).
  - A deliberately vulnerable practice app, such as **OWASP Juice Shop** or **DVWA**, on the isolated network only.
  - Optionally, a security-tools VM (for example Kali Linux) to attack the practice app, and a log collector such as a free SIEM to watch the attacks from the defender's side.
- **Snapshots:** take one before every experiment so you can roll back.

Free online platforms are a legal complement to your lab: **TryHackMe**, **Hack The Box**, **PortSwigger Web Security Academy**, **OverTheWire** and **picoCTF** all provide targets you are explicitly allowed to attack, within their rules.

The rules from the previous lesson apply: attack only machines in your lab or on platforms that authorise it. Never point lab tools at your school, employer, ISP or neighbours.

## Make your practice visible

Keep a lab notebook or a public repository with short write-ups: what you set up, what you tried, what you saw in the logs, and how you would defend against it. Defender-focused write-ups ("here is what the attack looked like in the logs and the alert I wrote") stand out to employers. Never publish secrets, real company data, or write-ups of retired platform machines in ways their rules forbid.

## Common mistakes

- **Collecting certifications without practice.** Interviews quickly reveal whether you have done the work.
- **Bridged networking for vulnerable VMs.** That puts an intentionally broken machine on your home network. Use host-only or internal networks.
- **Studying without the objectives.** You will over-study some topics and miss others.
- **Waiting until you feel "ready" to apply.** Apply for help desk, junior SOC and IT roles while you study; they are common entry points.

## Quick recap

- Security+ is the usual first security certification; CySA+ and cloud certifications follow; CISSP needs years of experience. Check official sites for current details.
- Study from the official objectives with one main course and practice questions, over roughly 8 to 12 weeks.
- Build an isolated lab with a hypervisor, host-only networking, snapshots and deliberately vulnerable apps.
- Practise only on your lab and authorised platforms, and write up what you learn.

## Try it

Open the **Do** tab to write your study plan and set up your lab.


Plan your CompTIA Security+ study and build a safe, isolated home lab for hands-on practice.

Certifications and labs

How to Pass Your SY0-701 Security+ Exam in 2026

Build Your Own Cybersecurity Lab at Home (For FREE)

The NIST Cybersecurity Framework and CIS Controls, legal and ethical hacking, and planning certifications and a home lab.