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

Security teams spend money and time on **controls**: anything that reduces risk, from a firewall rule to a locked door to a policy. To decide which controls a system needs, and to talk about them clearly with auditors, managers and other engineers, you need a shared vocabulary. The CIA triad and the standard control categories and types are that vocabulary. They also appear on almost every entry-level security exam.

## The CIA triad

Every security goal maps onto one or more of three properties:

- **Confidentiality**: only authorised people can read the data. Threats: data leaks, eavesdropping, a lost unencrypted laptop. Controls: access control, encryption, data classification.
- **Integrity**: data and systems are accurate and have not been changed without authorisation. Threats: tampering, malware, accidental edits. Controls: hashing and digital signatures, change control, input validation, backups to restore a known-good state.
- **Availability**: systems and data are there when authorised people need them. Threats: outages, ransomware, denial-of-service attacks, hardware failure. Controls: redundancy, backups, capacity planning, patching, DDoS protection.

The three often pull against each other. Encrypting everything with keys held by one person helps confidentiality but hurts availability if that person is away. Good design balances them for the data in question: a hospital's patient records need high availability as well as confidentiality, while a public website needs integrity and availability far more than confidentiality.

Many frameworks add related ideas such as **authenticity** (data really comes from who it claims) and **non-repudiation** (someone cannot later deny an action, usually provided by digital signatures and audit logs).

## Control categories: who or what carries out the control

| Category | Description | Examples |
|---|---|---|
| **Technical** | Implemented by systems and software | Firewalls, MFA, encryption, antivirus, logging |
| **Managerial** | Decisions and oversight by management | Risk assessments, security policies, vendor reviews |
| **Operational** | Carried out day to day by people | Security awareness training, guard patrols, change procedures |
| **Physical** | Protect the physical world | Door locks, badges, fences, CCTV, server room cages |

## Control types: what the control does

| Type | Goal | Examples |
|---|---|---|
| **Preventive** | Stop an incident before it happens | Firewall deny rule, MFA, door lock |
| **Detective** | Notice an incident during or after | Intrusion detection, log alerts, CCTV review |
| **Corrective** | Limit damage and restore normal operation | Restoring from backup, patching after an exploit, isolating an infected host |
| **Deterrent** | Discourage an attacker from trying | Warning banners, visible cameras, "this area is monitored" signs |
| **Compensating** | An alternative when the usual control cannot be used | Extra monitoring and network isolation for an old system that cannot be patched |
| **Directive** | Tell people what to do | Policies, procedures, "visitors must sign in" signs |

A control has one category **and** one or more types. A security camera is a physical control; it is deterrent when visible and detective when someone reviews the footage.

## Defence in depth

No single control is perfect, so defenders **layer** them. If one fails, another still stands. For a company laptop:

1. **Preventive, technical:** full-disk encryption, MFA on login, automatic patching.
2. **Detective, technical:** endpoint detection software reporting to the security team.
3. **Corrective, technical:** remote wipe and restore from backup.
4. **Directive and operational:** a policy and training on locking the screen and reporting loss quickly.

Losing the laptop on a train is now an inconvenience, not a data breach.

## Worked example: classifying controls

A small accounting firm lists its controls. Classify each one:

| Control | Category | Type | Mainly protects |
|---|---|---|---|
| Nightly backups kept offline | Technical | Corrective | Availability, integrity |
| Staff must use a password manager (written policy) | Managerial | Directive | Confidentiality |
| Alerts when an account logs in from a new country | Technical | Detective | Confidentiality |
| Server room door needs a badge | Physical | Preventive | Confidentiality, availability |
| Old tax software cannot be patched, so it runs on an isolated network segment with extra logging | Technical | Compensating | All three |
| Login banner: "Unauthorised access is prohibited and monitored" | Technical | Deterrent | Confidentiality |
| Quarterly phishing training | Operational | Preventive | Confidentiality |

Notice the reasoning: the backup cannot stop ransomware from encrypting files, but it fixes the damage afterwards, so it is corrective. The isolated network does not fix the unpatched software, it compensates for the missing patch.

## Common mistakes

- **Mixing up category and type.** Category answers "what kind of thing is it?"; type answers "what does it do in an incident?"
- **Only buying preventive controls.** Prevention fails eventually. Without detective and corrective controls you will not notice or recover.
- **Forgetting availability.** Ransomware is an availability attack first. Tested, offline backups are among the most valuable controls a small organisation can have.
- **Treating policy as done.** A directive control only works if people know it and something checks that they follow it.

## Quick recap

- CIA: confidentiality (only the right people read it), integrity (it is accurate and unaltered), availability (it is there when needed).
- Control categories: technical, managerial, operational, physical.
- Control types: preventive, detective, corrective, deterrent, compensating, directive.
- Layer different kinds of controls (defence in depth) so one failure does not become a breach.


Use the CIA triad to describe what a control protects, and classify controls by category and type.

The CIA triad and controls

The CIA Triad - CompTIA Security+ SY0-701 - 1.2

Security Controls - CompTIA Security+ SY0-701 - 1.1

## Why it matters

Most breaches involve an identity: a stolen password, a phished session, an over-powered service account or an old account nobody removed. Attackers increasingly "log in" rather than "break in". **Identity and access management (IAM)** is how organisations decide who someone is, what they may do, and how to prove what they did. It is a core skill for security, cloud and systems roles alike.

## The core idea: four steps (IAAA)

1. **Identification**: claiming an identity, such as a username or email.
2. **Authentication**: proving the claim, such as with a password plus a second factor.
3. **Authorization**: deciding what that identity is allowed to do.
4. **Accounting** (auditing): recording what it did, so actions can be reviewed and traced.

Authentication answers "who are you?" Authorization answers "what may you do?" Mixing them up causes many access-control bugs: a system that checks you are logged in but never checks that the record belongs to you.

## Authentication factors and MFA

Factors fall into three classic groups:

- **Something you know**: a password or PIN.
- **Something you have**: a phone app, a hardware security key, a smart card.
- **Something you are**: a fingerprint or face.

**Multi-factor authentication (MFA)** combines factors from **different** groups. A password plus a security question is still one factor (two things you know). A password plus a code from an authenticator app is two.

Not all MFA is equally strong:

| Method | Strength | Weak spot |
|---|---|---|
| SMS code | Better than nothing | SIM-swap fraud, interception, phishing |
| Authenticator app code (TOTP) | Good | Can be phished by a fake login page in real time |
| Push approval | Good with number matching | "MFA fatigue": users approve a flood of prompts to make them stop |
| Security key or passkey (FIDO2/WebAuthn) | Strongest, phishing-resistant | Needs device support and a backup method |

Passkeys and security keys are **phishing-resistant** because the key checks the website's real domain before answering; a look-alike site gets nothing useful.

## Authorization models

- **Role-based access control (RBAC)**: permissions are attached to roles (viewer, editor, admin), and people get roles. Easy to understand and review.
- **Attribute-based access control (ABAC)**: rules use attributes such as department, location or time ("managers can approve expenses from their own department").
- **Discretionary access control**: the owner decides who can access their resource, as with file sharing.

Most real systems combine RBAC with a few attribute rules.

## Least privilege and its friends

**Least privilege** means every person, program and service gets only the access needed for its job, and only for as long as needed. Related practices:

- **Separation of duties**: no single person can complete a sensitive action alone. The person who creates a supplier cannot also approve payments to it.
- **Just-in-time access**: admin rights are granted for a short window when needed and removed automatically.
- **Separate admin accounts**: admins browse and read email with a normal account and use a privileged account only for admin work.
- **Joiner, mover, leaver process**: grant access when people join, change it when they move roles (and **remove** the old access), and disable it the day they leave.
- **Access reviews**: managers regularly confirm who still needs what.

**Service accounts** and API keys need the same care. They often have broad rights, never log in interactively, and are forgotten. Give each one a single purpose, the narrowest permissions, and a known owner; store their secrets in a secrets manager, not in code.

## Worked example: access for a small team

A five-person team runs a web app in the cloud.

| Person or service | Needs | Grant |
|---|---|---|
| Developer (x3) | Deploy to staging, read production logs | Developer role on staging; read-only logs role on production |
| Team lead | Approve and run production deploys | Deployer role on production, used through a separate admin account with a security key |
| Support agent | Look up a customer's account status | Read-only support role limited to the customer table, no export |
| CI pipeline | Push a container image and update one service | A service identity that can update only that service, no human login |
| Former intern | Nothing | Account disabled on the last day; keys rotated |

Before this review, all three developers had full admin rights "to save time" and the intern's account was still active. Each change is small, but together they mean a single phished developer password can no longer take down production or read every customer record.

## Common mistakes

- **Shared accounts.** Five people using `admin` makes accounting impossible.
- **Privilege creep.** People collect access as they change roles and nothing gets removed.
- **MFA everywhere except the most important place**, such as email, the domain registrar or the cloud root account.
- **Checking authentication but not authorization** on every request.
- **Long-lived keys in code.** Rotate keys, prefer short-lived credentials, and scan repositories for leaked secrets.

## Quick recap

- IAAA: identification, authentication, authorization, accounting.
- MFA means factors from different groups; phishing-resistant methods (passkeys, security keys) are strongest.
- Least privilege, separation of duties, just-in-time access and regular reviews keep access small.
- Remove access on role changes and departures, and treat service accounts as identities with owners.


Apply authentication, MFA and least privilege so each person and service gets only the access it needs.

Identity and access

Identity and Access Management - CompTIA Security+ SY0-701 - 4.6

Multifactor Authentication - CompTIA Security+ SY0-701 - 4.6

## Why it matters

Cryptography sits under almost every control you have met so far: TLS, password storage, software signatures, disk encryption, MFA codes. You do not need to invent algorithms (and you never should), but you do need to pick the right tool. The most common beginner mistake is confusing **encoding**, **hashing** and **encryption**, which do very different jobs.

## Three different tools

| Tool | Reversible? | Needs a key? | Purpose | Examples |
|---|---|---|---|---|
| **Encoding** | Yes, by anyone | No | Represent data in another format | Base64, URL encoding, hex |
| **Hashing** | No (one-way) | No | Fingerprint data to check integrity; store passwords | SHA-256, SHA-3; bcrypt, scrypt, Argon2, PBKDF2 for passwords |
| **Encryption** | Yes, with the key | Yes | Keep data confidential | AES (symmetric), RSA and elliptic-curve (asymmetric) |

Base64 is **not** security. `cGFzc3dvcmQ=` decodes to `password` in one command. If you see "encrypted" data that ends in `=` and no key was involved, it is probably just encoded.

## Hashing

A cryptographic hash function turns any input into a fixed-size **digest**. Good hash functions have three properties:

- **Deterministic**: the same input always gives the same digest.
- **One-way**: you cannot work back from the digest to the input.
- **Collision-resistant**: it is infeasible to find two inputs with the same digest. A one-character change produces a completely different digest (the avalanche effect).

In Python:

```python
import hashlib

print(hashlib.sha256(b"hello").hexdigest())
# 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
print(hashlib.sha256(b"hellp").hexdigest())
# a completely different 64-character digest
```

**Integrity checks** are the classic use. A download page publishes the SHA-256 of a file; after downloading, you hash your copy and compare. If they match, the file was not corrupted or swapped (as long as you got the published hash from a trusted place).

MD5 and SHA-1 are **broken for collisions**: researchers can create two different files with the same digest. Do not use them for security; use SHA-256 or stronger.

### Hashing passwords

Servers should never store passwords, even encrypted. They store a **password hash** and compare hashes at login. Plain SHA-256 is the wrong tool for this, for two reasons:

1. It is **fast**. Attackers with GPUs can try billions of guesses per second against a stolen hash.
2. Identical passwords give identical hashes, so precomputed tables of common-password hashes work instantly.

The fix is a **slow, salted** password hashing function: bcrypt, scrypt, Argon2 or PBKDF2.

- A **salt** is random data, unique per user, stored next to the hash. Two users with the same password get different hashes, and precomputed tables become useless.
- A **work factor** (iterations or memory cost) makes each guess expensive. Logging in takes a few milliseconds more; guessing a million passwords takes far longer.

Python's standard library includes PBKDF2:

```python
import hashlib, hmac, os

salt = os.urandom(16)
digest = hashlib.pbkdf2_hmac("sha256", b"correct horse", salt, 600_000)

# At login: recompute with the stored salt and compare in constant time
attempt = hashlib.pbkdf2_hmac("sha256", b"correct horse", salt, 600_000)
print(hmac.compare_digest(digest, attempt))  # True
```

`hmac.compare_digest` compares in constant time, so an attacker cannot learn how many leading bytes matched by timing the response. In production, use a maintained library (for example `bcrypt` or `argon2-cffi`) or your framework's built-in password hasher, with the work factor it recommends today.

## Encryption

Encryption keeps data secret from anyone without the key.

- **Symmetric encryption** uses one shared key to encrypt and decrypt. AES is the standard. It is fast, so it is used for bulk data: disk encryption, database fields, the body of a TLS session. The hard part is sharing and protecting the key.
- **Asymmetric encryption** uses a key pair: a **public key** anyone may have, and a **private key** only the owner holds. Data encrypted with the public key can only be decrypted with the private key. It is slower, so it is used to exchange symmetric keys and to create **digital signatures**: the owner signs with the private key, and anyone can verify with the public key. That is how TLS certificates and software updates are verified.

TLS combines both: asymmetric cryptography during the handshake to authenticate the server and agree a key, then fast symmetric encryption for the data.

**Key management** is where real systems fail: keys committed to Git, the same key everywhere, keys never rotated. Use a key management service or secrets manager, restrict who can use each key, and rotate them.

## Common mistakes

- **"We encrypt passwords."** Passwords should be hashed with a slow, salted function, not encrypted (encryption can be reversed by anyone who gets the key).
- **Using MD5 or SHA-1** for anything security-related.
- **Rolling your own crypto**, including "clever" combinations of standard pieces. Use well-reviewed libraries with safe defaults.
- **Comparing secrets with `==`** in authentication code instead of a constant-time comparison.
- **Calling Base64 encryption.**

## Quick recap

- Encoding changes format (no secrecy), hashing fingerprints one way, encryption hides data and can be reversed with a key.
- Use SHA-256 or stronger for integrity; never MD5 or SHA-1 for security.
- Store passwords with a slow, salted function (bcrypt, scrypt, Argon2, PBKDF2) and compare in constant time.
- Symmetric encryption (AES) for bulk data, asymmetric for key exchange and signatures; protect and rotate keys.

## Try it

Open the **Do** tab to verify a file's integrity and hash passwords with Python's `hashlib`.


Explain the difference between encoding, hashing and encryption, and use Python's hashlib to check integrity and store passwords safely.

Cryptography basics

Hashing Algorithms and Security - Computerphile

The CIA triad and control types, identity and access management, and cryptography basics.