Data Security: Trust No One

Change Healthcare: When America's Medical System Went Dark

The Target

  • 15 billion transactions annually
  • 1 in 3 patient records touched
  • 100+ critical functions for US healthcare
  • Every hospital in America depends on it

What they process:

Insurance eligibility • Drug prescriptions • Claims • Payments

The Attack

  • Feb 21, 2024: ALPHV/BlackCat strikes
  • Ransomware: Systems encrypted
  • Data theft: 193M records stolen
  • $22M ransom paid - data still leaked

Attack vector:

No MFA on Citrix portal → Admin access → Encrypt & exfiltrate

The Impact

  • 94% of hospitals financially hit
  • 74% patient care delayed
  • 33% lost half their revenue
  • 2-3 months to recover

The double hit:

Pharmacies couldn't fill prescriptions • Doctors couldn't authorize care • 193M Americans' data exposed forever

The lesson: When you trust everything, you protect nothing. This is why we need Zero Trust.

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

What You Can Never Trust: 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

So what do you do when you can't trust anything?

You follow the 5 Commandments of Zero Trust ↓

Zero Trust: Never Trust, Always Verify

The Zero Trust Principle

Assume breach. Verify everything. Trust no one.

Every connection is hostile until proven otherwise.

1

Verify Everything

Never trust, always verify

  • Authenticate every connection
  • Validate every input
  • Verify every identity
2

Minimal Access

Least privilege by default

  • Read-only unless proven otherwise
  • Time-limited access tokens
  • No shared admin accounts
3

Layer Defenses

Multiple barriers to breach

  • Network isolation (private subnets)
  • Application security (WAF, validation)
  • Database hardening (configs, patches)
4

Expect Attacks

Assume breach will happen

  • Plan incident response now
  • Test restore procedures monthly
  • Document recovery runbooks
5

Watch Always

You can't fix what you can't see

  • Audit all database activity
  • Alert on anomalies in real-time
  • Monitor 24/7 with automation

Remember: It's not paranoia if they're really trying to hack you. And they are.

Security Implementation Checklist (Starter)

PriorityTimeZero TrustActionPostgreSQL Command
CRITICAL5 min12Secure Password Management
• Change default passwords
• Set password expiry
• Enforce strong passwords		ALTER USER postgres PASSWORD '...';
ALTER USER appuser VALID UNTIL '2025-12-31';
ALTER SYSTEM SET password_encryption = 'scram-sha-256';
CRITICAL1 hour312Secure Network Configuration
• Enable SSL/TLS encryption
• Limit max connections
• Restrict connection sources		ssl = on in postgresql.conf
ALTER SYSTEM SET max_connections = 100;
Edit pg_hba.conf for IP restrictions
CRITICAL10 min23Least Privilege Access
• Read-only for analytics/data science
• Keep UPDATE/DELETE privileges tight		CREATE USER analyst WITH PASSWORD '...';
GRANT SELECT ON ALL TABLES IN SCHEMA public TO analyst;
-- Never grant write access unless essential
HIGH5 min51Enable audit loggingALTER SYSTEM SET log_statement = 'all'; SELECT pg_reload_conf();
HIGH45 min4351Complete 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		pg_dump dbname > backup_$(date +%Y%m%d).sql
aws s3 cp backup_*.sql s3://backups/
aws s3api put-object-lock-configuration --bucket backups
psql testdb < backup.sql (test restore monthly)
Enable S3 cross-region replication

Zero Trust in Action

The following examples demonstrate how to apply Zero Trust principles in practice:

Example: SQL Injection Defense 1 3

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() # 💀 GAME OVER when attacked 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() # ✅ Safe from injection! 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!

Example: Security Audit Queries 2 5 1

Demonstrates: Minimal Access (check permissions) • Watch Always (audit activity) • Verify Everything (validate configs)

Copy these queries and run them TODAY:

PostgreSQL Security Audit

-- 1. Who has superuser? (Should be minimal)
SELECT usename, usesuper, usecreatedb, userepl 
FROM pg_user 
WHERE usesuper = true;

-- 2. Check for default passwords
SELECT usename FROM pg_user 
WHERE passwd IS NULL OR passwd = '';

-- 3. List all granted permissions
SELECT 
    grantee, 
    table_schema, 
    table_name, 
    privilege_type 
FROM information_schema.role_table_grants 
WHERE grantee NOT IN ('postgres', 'pg_database_owner')
ORDER BY grantee, table_schema, table_name;

-- 4. Check SSL enforcement
SHOW ssl;  -- Should be 'on'

-- 5. Audit logging enabled?
SHOW log_statement;  -- Should be 'all' or 'ddl'

Incident Response: When Things Go Wrong

Database Breach Decision Tree Your database is compromised. What now? ⚠️ BREACH DETECTED Suspicious activity or ransom note Can you isolate affected systems? Network disconnect, disable accounts YES 1. ISOLATE • Disconnect from network • Disable compromised accounts • Preserve evidence (logs) NO FULL SHUTDOWN • Kill all connections • Stop database service • Snapshot current state Have verified clean backups? Immutable, tested, before breach YES 2. RESTORE FROM BACKUP • Verify backup integrity first • Restore to isolated environment • Apply all security patches • Change ALL credentials Recovery: 4-24 hours NO CRITICAL DECISION Option A: Pay ransom (not recommended) • No guarantee of recovery Option B: Rebuild from scratch • Data loss likely Recovery: Days to weeks WHO TO CALL (IN ORDER) 1. Your incident response team 2. Legal counsel (for regulations) 3. Cyber insurance provider 4. Law enforcement (FBI IC3) 5. PR team (if public breach)

Resources & Tools

Last Updated: 2025 | Remember: Security is a journey, not a destination. Stay paranoid, stay safe.