Data Security: Trust No One

The Zero Trust Reality: Whether it's a sprawling ELT pipeline or a modest Postgres setup, the risk is the same: one slip, a password, a PII column (personally identifiable information like SSNs, names, IP addresses) column, and your company could be history. The network? Unreliable. The client? Suspect.

The Big 3: Data Security Disasters That Exposed America

The Big 3: Data Security Disasters That Exposed America When trust failed, millions paid the price 1. EQUIFAX (2017) The Identity Theft Catastrophe 148M Americans' SSNs exposed What they stole: • Social Security Numbers • Birth dates, addresses • Driver's license numbers The damage: • Data still sold on dark web • Victims got ~$125 each • Identity theft for decades 2. NATIONAL PUBLIC DATA (2024) The Data Broker Disaster 170M People across US/UK/Canada What they stole: • 2.9 billion records total • SSNs, phone numbers • Current & past addresses The damage: • Company went bankrupt • No help for victims • Half of US population hit 3. CHANGE HEALTHCARE (2024) The Medical Records Nightmare 193M Americans' medical data What they stole: • Medical records, SSNs • Diagnoses, prescriptions • Insurance information The damage: • Paid $22M, data still leaked • Pharmacies couldn't operate • Medical fraud risk forever 490% increase from 2023→2024 3-4x per year your data is exposed $4.88M average breach cost (IBM 2024) Your Database Could Be Next Unless you implement Zero Trust Security, where nothing and no one is trusted by default

The Engineering Failures Behind the Blast Radius

The graphic above shows the financial blast radius, but as engineers, we must study the actual breach vectors:

  • Equifax (2017): Failed to patch a known vulnerability in the Apache Struts application layer. Attackers used this application bug to pivot and gain root access to the backend databases.

  • National Public Data (2024): A fatal failure of plaintext credentials. A threat actor found unencrypted database passwords hardcoded in a backend file that was inadvertently exposed.

  • Change Healthcare (2024): An attacker gained access to a remote access portal that did not enforce Multi-Factor Authentication (MFA), allowing them to deploy ransomware directly onto the medical data clusters.

  • Snowflake & Ticketmaster (2024): A mass credential stuffing campaign. Attackers purchased info-stealer logs containing legitimate employee credentials to cloud data lake accounts that lacked MFA, quietly exfiltrating terabytes of raw analytics data.

Zero Trust, Always Verify: The 5 Attack Vectors

The Uncomfortable Truth

These 5 things WILL betray you. Plan accordingly.

Don't Trust the Network

Assume: Already compromised

• Man-in-the-middle attacks
• Packet sniffing
• DNS poisoning

Don't Trust Users

Assume: Already phished

• Credential theft
• Social engineering
• Malware on devices

Don't Trust Admins

Assume: Insider threat

• Disgruntled employees
• Compromised accounts
• Privilege abuse

Don't Trust Code

Assume: Injection attempts

• SQL injection
• Supply chain attacks
• Malicious libraries

Don't Trust Backups

Assume: Will be deleted

• Ransomware targets
• Corrupted restores
• Untested procedures

Zero Trust DB Checklist (Starter)

PriorityTimeZero Trust Action
CRITICAL5 minSecure Password Management
• Change default passwords
• Set password expiry
• Enforce strong passwords
CRITICAL1 hourSecure Network Configuration
• Enable SSL/TLS encryption
• Limit max connections
• Restrict connection sources
CRITICAL10 minLeast Privilege Access (Postgres SQL)
• Execute: REVOKE ALL ON users FROM public;
• Execute: GRANT SELECT ON users TO analytics_role;
• Enforce Row-Level Security (RLS)
HIGH5 minEnable audit logging
HIGH45 minComplete 3-2-1 Backup Strategy
• 3 copies: Primary + Secondary + Offsite
• 2 storage types: Local disk + Cloud (S3)
• 1 offsite: Different region/location
• Test restores: Verify backups actually work
• Immutable backups: Protect from ransomware

Zero Trust DB App Checklist (Starter)

Example: SQL Injection Defense

Demonstrates: Verify Everything (validate all inputs) • Layer Defenses (parameterized queries)

The Bobby Tables Attack (Still Works in 2025!) How a simple quote mark can destroy your database VULNERABLE CODE (What NOT to do) # Python - String concatenation (BAD!) def get_user (username): query = f"SELECT * FROM users WHERE name = ' {username} '" # User input directly in query! cursor.execute(query) return cursor.fetchall() Attacker Input: Robert'; DROP TABLE users; -- Resulting Query: SELECT * FROM users WHERE name = ' Robert'; DROP TABLE users; --' ↑ Query ends ↑ New command! ↑ Comment SECURE CODE (Always use prepared statements) # Python - Prepared statement (GOOD!) def get_user (username): query = "SELECT * FROM users WHERE name = %s" # Placeholder, not string! cursor.execute(query, (username,) ) return cursor.fetchall() Same Attack Input: Robert'; DROP TABLE users; -- Resulting Query: SELECT * FROM users WHERE name = 'Robert''; DROP TABLE users; --' ↑ Entire string treated as data, not code!

Module 6 Capstone: The Double-Edged Sword

In Module 1 (SQL), you learned that standard SQL is incredibly powerful. You can extract and manipulate huge amounts of data using just a few simple declarative SELECT and JOIN statements.

Here in Module 6 (Data Security), you see the flip-side. That incredible query power means an attacker only needs one mistake (like a vulnerable string concatenation) to weaponize your database against you. SQL Injection is simply an attacker hijacking your syntax to execute unauthorized SELECT and DELETE commands.

Do not trust your network. Do not trust your users. Verify every query.