Skip to content

Cybersecurity Fundamentals

Security is not a feature you add at the end. It is a set of habits: reduce exposure, verify trust, limit damage, and assume things will go wrong.

This cheat sheet is defensive and educational. It focuses on understanding risks and building safer systems, not on how to attack them.

The CIA Triad

The classic starting point for thinking about security goals.

Property Meaning Example concern
Confidentiality Only authorized parties can see the data leaked API keys, exposed files
Integrity Data and systems are not improperly altered tampered model weights, corrupted records
Availability Systems and data are accessible when needed denial of service, lost credentials locking you out

Real systems usually care about all three, with different emphasis. A public dashboard may prioritize availability; a customer database definitely cares about confidentiality and integrity.

Threat Modeling in One Paragraph

Before you dive into controls, ask four questions:

  1. What am I protecting? — data, credentials, models, infrastructure, reputation.
  2. Who might want it? — external attackers, compromised accounts, accidental misuse, trusted-but-buggy code.
  3. How could they get it? — phishing, injection, misconfiguration, leaked secrets, weak access control.
  4. What happens if they do? — impact on users, data, operations, and legal/contractual obligations.

You do not need a formal methodology to be better than guessing. Spend a few minutes on these questions before designing anything that handles sensitive data or external input.

The Security Mindset

  • Assume input is hostile. Anything from outside your trust boundary can be malformed, malicious, or both.
  • Least privilege. Give a component only the access it needs, for only as long as it needs it.
  • Default deny. If something is not explicitly allowed, it is not allowed.
  • Fail safely. A failure should expose as little as possible and leave the system in a safe state.
  • Defense in depth. No single control is perfect, so layer controls that catch different kinds of problems.
  • Verify, do not trust. Check authorization, input, output, and configuration even when you "know" they should be correct.
  • Plan for compromise. Monitor, rotate credentials, limit blast radius, and keep recovery paths tested.

Common Security Concepts

Authentication vs Authorization

Concept Question it answers
Authentication Who are you?
Authorization What are you allowed to do?

Authenticate first, then authorize. Do not rely on the user interface alone to enforce permissions; enforce them at the server or service layer.

Trust Boundaries

A trust boundary is where your level of trust changes. Examples: - Your application code vs user input. - Your internal network vs the public internet. - Your service vs a third-party API. - A trusted container vs the host.

Every boundary is a place to validate, sanitize, isolate, or monitor.

Attack Surface

The attack surface is the set of places where an attacker can try to interact with your system: - Public endpoints - File uploads - Forms and APIs - Configuration files - Credentials and keys - Dependencies and their dependencies

Smaller surfaces are easier to defend. Remove or close what you do not need.

Secrets Management

  • Do not hardcode secrets in source code.
  • Do not commit secrets to version control.
  • Use environment variables, secret managers, or managed credentials where possible.
  • Rotate secrets when exposure is suspected.
  • Limit who and what can access them.

A secret in code is a secret that has already leaked in every clone, log, and backup of that code.

Vulnerability vs Exploit vs Risk

  • Vulnerability — a weakness.
  • Exploit — a method that uses the weakness.
  • Risk — the likelihood and impact of something bad happening.

You can reduce risk by removing vulnerabilities, making exploits harder, lowering exposure, or reducing impact.

Phishing and Social Engineering

Not everything is a code bug. A lot of compromise starts with tricking people: - Fake login pages - Urgent-seeming email - Impersonation of support or internal staff - Requests that bypass normal process "just this once"

Defenses are partly technical (MFA, filtering, verification steps) and partly cultural (users should feel safe questioning unusual requests).

Defense in Depth

Layer controls so no single mistake becomes a total breach.

Example layers for a web service: 1. Identity and authentication 2. Authorization checks on every request 3. Input validation 4. Parameterized queries / safe API usage 5. Output encoding where appropriate 6. TLS for traffic 7. Rate limiting and abuse protection 8. Secrets not in code 9. Logging and alerting 10. Patching and dependency hygiene

One layer can fail. The others should still help.

Principle of Least Privilege

Give accounts, services, and users only what they need.

Examples: - A batch job that reads one dataset does not need write access to the whole cluster. - A service account should not be an admin "because it is easier." - Human users should not share one generic account. - Temporary access is better than permanent broad access.

Least privilege limits how far a compromise can spread.

Secure by Default

  • Disable features you do not use.
  • Turn off debug modes in production.
  • Require authentication where it belongs.
  • Deny access until explicitly granted.
  • Close unused ports and endpoints.

Defaults shape real-world security more than policy documents do.

Fail Safe

When something goes wrong: - Do not expose internal errors to users. - Do not leave a system in an insecure state if you can avoid it. - Log the failure securely. - Return a safe response rather than a leaky one.

A crash that reveals stack traces, paths, or credentials is a worse outcome than a generic error message.

Secure Development Habits

  • Validate input at the boundary.
  • Use parameterized queries instead of string-building SQL.
  • Escape or encode output where the context demands it.
  • Keep dependencies updated.
  • Review changes that touch auth, permissions, secrets, or data exposure.
  • Add tests for security-sensitive logic where practical.
  • Use code review as a security checkpoint, not just a style checkpoint.

Logging and Monitoring for Security

Security-relevant logging is not only for forensics after a breach. It helps you notice: - Repeated failed authentication attempts - Authorization failures - Unexpected configuration changes - Unusual access patterns - Errors that may indicate probing or abuse

Log enough to detect and investigate, but avoid logging sensitive data in the process.

Incident Response Basics

Even good systems can be compromised. Have a plan before you need one.

  1. Detect — through alerts, logs, user reports, or odd behavior.
  2. Triage — determine scope and severity.
  3. Contain — limit the damage: revoke credentials, isolate systems, disable compromised access.
  4. Investigate — understand what happened and what was affected.
  5. Eradicate and recover — remove the cause, restore clean state, verify integrity.
  6. Learn — fix the gap that allowed it, and improve detection.

A response plan that exists only in your head tends to become chaos under pressure.

Common Misconceptions

  • "It is an internal tool, so it does not need security." — Internal systems get compromised, reused, and exposed.
  • "Security is the security team's job." — Developers and data engineers make daily decisions that change the risk profile.
  • "If there is no sensitive data, security does not matter." — Systems can be abused, taken over, or used as a stepping stone.
  • "Encryption solves everything." — Encryption helps confidentiality, but it does not fix bad access control, bad validation, or bad secrets management.
  • "If it works, it is secure." — A working feature can still leak data or be abused.

A Simple Threat-Example Mindset

Suppose you are exposing a model inference API.

  • What is sensitive? — the model, the API, the inputs/outputs, any credentials used to call downstream services.
  • Who might abuse it? — someone trying to exfiltrate data, flood the service, probe for weaknesses, or misuse the model.
  • Where are the boundaries? — public internet, your API layer, your model service, your data store.
  • What controls help? — authentication, authorization, rate limiting, input validation, logging, secret management, patching, least privilege.

You do not need to imagine every clever attack. You do need to know your boundaries and your controls.

Official Documentation

  • There is no single authoritative source, but good starting points include:
  • OWASP Top 10 — common web application security risks
  • NIST Cybersecurity Framework — high-level security program structure
  • Your organization's security policy and internal guidance, when it exists

General guidance: prefer widely accepted defensive practices over clever ones, and learn the specific controls that apply to the systems you build.

Last Updated

2026-09-06 — Initial version.