Cybersecurity is a vast field, but every concept in it traces back to a small set of foundational principles. Get these right and the rest of the discipline starts to make sense.
The CIA Triad
The three letters of CIA describe what security tries to protect:
| Property | Means | Threatened by |
|---|---|---|
| Confidentiality | Information is disclosed only to authorised parties | Eavesdropping, data breaches, shoulder-surfing, insider leaks |
| Integrity | Information is accurate and has not been altered without authorisation | Tampering, malware modification, fraudulent transactions |
| Availability | Authorised users can access the system when they need to | DDoS, ransomware, hardware failure, natural disasters |
Every security control you encounter — encryption, hashing, redundancy, backups, MFA, firewalls — exists to protect one or more of these properties. When you evaluate a risk or design a control, ask: which leg of the CIA triad does this affect?
A useful extension is sometimes called the Parkerian Hexad, which adds:
- Authenticity: the source is genuinely who it claims to be
- Possession/Control: the owner retains physical or logical control over the asset
- Utility: the data remains useful (e.g., not encrypted with a lost key)
AAA: Authentication, Authorization, Accountability
- Authentication — proving you are who you claim to be (passwords, biometrics, hardware tokens).
- Authorization — what an authenticated identity is allowed to do (read, write, admin).
- Accountability — being able to prove who did what (audit logs, non-repudiation).
A common interview trap: "you logged in" is authentication; "you can access this file" is authorization. They are different problems and use different mechanisms.
Defense in Depth
No single control is perfect. Defense in depth layers multiple, independent controls so that a failure of any one does not compromise the system.
Imagine an attacker trying to reach a database that holds customer credit cards:
- Firewall blocks unsolicited inbound traffic
- WAF inspects HTTP requests for SQL injection
- Application validates input and uses parameterised queries
- Application authenticates the user (MFA)
- Authorization checks the user can read this customer
- Database connection uses a least-privilege account
- Card numbers are encrypted at rest with KMS
- Tokenization replaces real card numbers with tokens in most systems
- Audit logs are streamed off-host and alert on anomalies
To exfiltrate cards, the attacker must defeat all of these layers. Each one buys time and increases the chance of detection.
Principle of Least Privilege
Every identity — user, service account, container, function — should have the minimum permissions required to do its job, and no more. The blast radius of a compromised credential is exactly the permissions that credential had.
Practical applications:
- An app that only reads data should not have write permissions
- A backup process should not have rights to modify production data
- Engineers don't need permanent admin access — use just-in-time elevation
- Service accounts get scoped IAM roles, not
*:*
Other Foundational Principles
| Principle | What it means |
|---|---|
| Separation of duties | No single person can both initiate and approve a sensitive action (e.g., creating a vendor and paying the invoice) |
| Fail secure / fail closed | When a control fails, the system denies access rather than allowing it |
| Minimise attack surface | Fewer features, ports, and dependencies mean fewer ways in |
| Secure by default | Out-of-the-box configuration is safe; users must take action to weaken security |
| Zero trust | Never trust based on network location alone — always authenticate and authorize |
| KISS / economy of mechanism | Simpler systems have fewer bugs and fewer attack paths |
Risk = Threat × Vulnerability × Impact
Security is risk management, not risk elimination. You cannot secure everything to the same degree — and you don't need to. Quantify risk across three dimensions:
- Threat: who or what might attack? Their capability and motivation.
- Vulnerability: what weakness exists in the system?
- Impact: what's the cost if the threat exploits the vulnerability?
You then have four ways to handle each risk:
- Mitigate — apply controls to reduce likelihood or impact
- Transfer — buy insurance, outsource to a more capable provider
- Accept — formally acknowledge and live with the risk
- Avoid — stop doing the activity that creates the risk
Every security decision in the rest of this course is, ultimately, an instance of this framework.