Data Security: Trust No One

Concept. Zero Trust assumes compromise at every layer: network, users, admins, code, and backups. The system verifies every request instead of trusting a boundary. The database stores PII, so one unverified path causes a breach.

Intuition. The 2024 mega-breaches used common failures. National Public Data stored plaintext database passwords in an exposed file. Change Healthcare exposed a remote portal without MFA. Snowflake customers reused stolen credentials on accounts without MFA. Each breach used one surface that a defender treated as trusted.

Three Breaches, Half a Billion Records

The vector is almost never a clever zero-day. It is an unpatched library, a plaintext password, or a missing MFA prompt.

Breach	Year	Records	Root cause
Equifax	2017	148M SSNs	unpatched Apache Struts bug, pivoted to root on the DB
National Public Data	2024	170M people (2.9B records)	plaintext DB passwords in an exposed backend file
Change Healthcare	2024	193M medical records	remote portal with no MFA, then ransomware
Snowflake / Ticketmaster	2024	terabytes exfiltrated	stolen credentials on cloud accounts without MFA

The average breach cost $4.88M in 2024 (IBM), and the count rose sharply year over year. Every root cause above is a surface someone trusted instead of verifying.

Zero Trust: The Five Surfaces

A grey data store holding the database and PII, with five red surfaces below it you must not trust by default: the network (assume compromised), users (assume phished), admins (assume insider threat), code (assume injection), and backups (assume deletable).

Figure 1. Zero Trust treats every path to the data as hostile until verified. Attackers can sniff the network, phish a user, compromise an admin account, inject code, or encrypt backups with ransomware. Defenses verify each request at each surface and apply least privilege, MFA, and immutable backups.

Zero Trust DB Checklist (Starter)

Priority	Time	Action
CRITICAL	5 min	Passwords. Change defaults, set expiry, enforce strong passwords.
CRITICAL	1 hour	Network. Enable SSL/TLS, limit max connections, restrict connection sources.
CRITICAL	10 min	Least privilege. `REVOKE ALL ON users FROM public;` then `GRANT SELECT ON users TO analytics_role;` and enable Row-Level Security.
HIGH	5 min	Audit logging. Turn it on.
HIGH	45 min	3-2-1 backups. 3 copies, 2 storage types, 1 offsite; test restores; keep them immutable against ransomware.

SQL Injection: The One Bug That Keeps Winning

Injection defense is the clearest case of "verify every input." The classic Bobby Tables attack still works wherever a query is built by string concatenation.

The same attacker input Robert'; DROP TABLE users; -- takes two fates: a string-concatenated query splices it in and runs DROP TABLE users (red); a parameterized query binds it as one value, so the database searches for a user with that literal name and drops nothing (green).

Figure 2. The same input can act as SQL or as data. String concatenation lets an attacker terminate a string literal and inject a new command, so DROP TABLE users executes. A parameterized query sends values separately from SQL text, so the database treats the input as one value and executes no injected command. Parameterize every query and never concatenate input into SQL.

Module 6 Capstone: Power Cuts Both Ways

In Module 1 you saw that SQL is powerful: a few declarative SELECT and JOIN statements move enormous amounts of data. Here in Module 6 you see the other edge. That same power means one mistake, a single concatenated string, lets an attacker turn your query engine against you. SQL injection is just an attacker hijacking your syntax to run their own SELECT and DROP.

Do not trust the network. Do not trust the user. Verify every query.