zhongwei/gh-lyndonkl-claude

Fork 0

Files

Zhongwei Li 41d9f6b189 Initial commit

2025-11-30 08:38:26 +08:00

20 KiB

Raw Permalink Blame History

Security Threat Model Template

Workflow

Copy this checklist and track your progress:

Security Threat Model Progress:
- [ ] Step 1: Map system architecture and data flows
- [ ] Step 2: Identify trust boundaries
- [ ] Step 3: Classify data and compliance
- [ ] Step 4: Apply STRIDE to each boundary
- [ ] Step 5: Define mitigations and monitoring

Step 1: Map system architecture

Complete the System Architecture section. Document all components and data flows.

Step 2: Identify trust boundaries

Mark boundaries in the Trust Boundaries section. Identify where data crosses security domains.

Step 3: Classify data

Complete Data Classification. Rate sensitivity and identify compliance requirements.

Step 4: Apply STRIDE

For each boundary, complete STRIDE Analysis. Systematically check all six threat categories.

Step 5: Define mitigations

Document controls in Mitigations & Monitoring. Prioritize by risk score.

Security Threat Model

System Overview

System Name: [Name of system being threat modeled]

Purpose: [What this system does, business value, users served]

Scope: [What's included in this threat model, what's out of scope]

Date: [Date of analysis]

Analyst(s): [Who conducted this threat model]

Review Date: [When this should be reviewed next, e.g., quarterly, after major changes]

System Architecture

Component Diagram:

[User/Browser] ─── HTTPS ───> [Load Balancer] ─── HTTP ───> [Web Server]
                                                                   │
                                                                   │ JDBC
                                                                   ▼
                                                             [Database]
                                                                   │
                                                                   │
                                                                   ▼
                                                           [Backup Storage]

Components:

Component	Technology	Purpose	Network Zone	Authentication Method
[User/Browser]	Chrome/Safari/Firefox	End user interface	Public Internet	Session cookie
[Load Balancer]	AWS ALB	Traffic distribution, TLS termination	DMZ	N/A (no auth)
[Web Server]	Node.js/Express	Business logic, API endpoints	Private VPC	API key from LB
[Database]	PostgreSQL RDS	Persistent storage	Private subnet	DB credentials
[Backup Storage]	S3 bucket	Encrypted backups	AWS Region	IAM role
[Third-party service]	Stripe API	Payment processing	External	API secret key

Data Flows:

User Login: User → LB → Web Server → Database (credentials check) → Web Server → User (session token)
Data Retrieval: User → LB → Web Server → Database (query) → Web Server → User (JSON response)
Payment: User → LB → Web Server → Stripe API (payment token) → Webhook → Web Server → Database (order confirmation)
Backup: Database → S3 (nightly encrypted snapshot)

External Dependencies:

Service	Purpose	Data Shared	Authentication	SLA/Criticality
[Stripe]	Payment processing	Card tokens, customer IDs	API secret key	Critical (payment failures = revenue loss)
[SendGrid]	Email delivery	Email addresses, message content	API key	High (notifications)
[Datadog]	Monitoring/logging	Logs, metrics (may contain PII)	API key	Medium (observability)

Trust Boundaries

Boundary 1: Public Internet → Load Balancer

Data crossing: HTTP requests (headers, body, query params)
Trust change: Untrusted (anyone on Internet) → Trusted infrastructure
Controls: TLS 1.2+, DDoS protection, rate limiting, Web Application Firewall (WAF)
Risk: High (direct exposure to attackers)

Boundary 2: Load Balancer → Web Server

Data crossing: HTTP requests (forwarded), source IP, X-Forwarded-For headers
Trust change: DMZ → Private VPC
Controls: Security groups (whitelist LB IPs), API key validation, input validation
Risk: Medium (internal but accepts untrusted input)

Boundary 3: Web Server → Database

Data crossing: SQL queries, query parameters
Trust change: Application layer → Data layer
Controls: Parameterized queries, connection pooling, DB credentials in secrets manager, least privilege grants
Risk: High (SQL injection = full data compromise)

Boundary 4: Web Server → Third-Party API (Stripe)

Data crossing: Payment tokens, customer data, order details
Trust change: Internal → External (Stripe's control)
Controls: HTTPS, API key rotation, minimal data sharing, audit logging of requests
Risk: Medium (data leaves our control, reputational risk)

Boundary 5: Database → Backup Storage (S3)

Data crossing: Encrypted database snapshots
Trust change: Live database → Long-term storage
Controls: AES-256 encryption at rest, bucket policies (private), versioning, lifecycle policies, cross-region replication
Risk: Medium (exposure if misconfigured, compliance requirement)

Boundary 6: Client-side (JavaScript) → Server-side (API)

Data crossing: User inputs, client-side state
Trust change: User-controlled code → Server validation
Controls: Server-side validation (never trust client), CSRF tokens, CSP headers, HttpOnly cookies
Risk: High (client fully controlled by attacker)

Data Classification

Data Inventory:

Data Element	Classification	Compliance	Storage Location	Encryption	Retention
User passwords	Restricted	GDPR	Database	bcrypt hash (cost 12)	Until account deletion
Credit card numbers	Restricted (PCI)	PCI DSS Level 1	Stripe (tokenized)	Stripe manages	Stripe retention policy
Email addresses	Confidential (PII)	GDPR, CAN-SPAM	Database, SendGrid	At rest: AES-256	7 years post-deletion
Order history	Confidential	GDPR	Database	At rest: AES-256	7 years (tax law)
Session tokens	Confidential	-	Redis, cookies	In transit: TLS	24 hours
Audit logs	Internal	SOC 2	Datadog, S3	At rest: AES-256	1 year
API keys (3rd party)	Restricted	-	AWS Secrets Manager	Encrypted by SM	Rotated quarterly
User IP addresses	Internal (PII)	GDPR	Logs, analytics	At rest: AES-256	90 days

Classification Levels:

Public: Can be freely shared (marketing content, public documentation)
Internal: For internal use, no external sharing (business metrics, roadmaps)
Confidential: Sensitive, access controlled (PII, customer data)
Restricted: Highly sensitive, strict access (credentials, PCI data, PHI)

Compliance Requirements:

GDPR: Data minimization, consent management, right to deletion, breach notification (72 hours)
PCI DSS Level 1: No storage of CVV, tokenization, quarterly ASV scans, annual audit
SOC 2 Type II: Access controls, audit logging, change management, annual audit

STRIDE Analysis

For each trust boundary, systematically apply all six STRIDE threat categories:

Boundary: Public Internet → Load Balancer

S - Spoofing

Threat: Attacker spoofs user identity using stolen session cookies
Likelihood: Medium (session cookies in browser storage vulnerable to XSS)
Impact: High (full account access)
Mitigation: HttpOnly + Secure + SameSite=Strict cookies, short session timeout (1 hour), IP binding, device fingerprinting
Status: ✓ Implemented
Monitoring: Alert on geo-impossible travel (login from US then China in 1 hour)

T - Tampering

Threat: Man-in-the-middle attack modifies requests/responses
Likelihood: Low (TLS widely enforced)
Impact: High (data corruption, command injection)
Mitigation: TLS 1.2+ enforced, HSTS header, certificate pinning (mobile), integrity checks on critical operations
Status: ✓ Implemented
Monitoring: Monitor TLS version usage, alert on downgrade attempts

R - Repudiation

Threat: User denies making purchase, no audit trail
Likelihood: Low (audit logging in place)
Impact: Medium (dispute resolution, fraud)
Mitigation: Comprehensive audit logging (user ID, timestamp, action, IP, user agent), immutable logs (S3 with object lock), digital signatures on transactions
Status: ✓ Implemented
Monitoring: Alert on log tampering, regular log integrity checks

I - Information Disclosure

Threat: Verbose error messages reveal stack traces, database schema
Likelihood: Medium (development errors in production)
Impact: Medium (aids attacker reconnaissance)
Mitigation: Generic error messages to users, detailed errors logged server-side only, security headers (X-Content-Type-Options, X-Frame-Options), no PII in URLs/logs
Status: ⚠ Partial (need to audit error messages)
Monitoring: Log analysis for stack traces in responses, alert on 500 errors

D - Denial of Service

Threat: DDoS attack exhausts resources, site becomes unavailable
Likelihood: Medium (e-commerce sites are targets)
Impact: High (revenue loss, reputation)
Mitigation: CloudFront CDN, AWS Shield Standard, WAF rate limiting (100 req/min per IP), auto-scaling, circuit breakers, resource quotas
Status: ✓ Implemented
Monitoring: Alert on traffic spikes (>10x baseline), track error rates, auto-scaling metrics

E - Elevation of Privilege

Threat: Regular user gains admin access via authorization bypass
Likelihood: Low (authorization checks in place)
Impact: High (full system compromise)
Mitigation: Role-based access control (RBAC), authorization check on every request, principle of least privilege, admin actions require re-authentication
Status: ✓ Implemented
Monitoring: Alert on privilege escalation attempts, admin action audit log

Risk Score (Likelihood × Impact):

Spoofing: 2 × 3 = 6 (Medium)
Tampering: 1 × 3 = 3 (Low)
Repudiation: 1 × 2 = 2 (Low)
Information Disclosure: 2 × 2 = 4 (Medium)
Denial of Service: 2 × 3 = 6 (Medium)
Elevation of Privilege: 1 × 3 = 3 (Low)

Top Risks for This Boundary: Session hijacking (Spoofing), DDoS (DoS), Information disclosure via errors

Boundary: Web Server → Database

S - Spoofing

Threat: Attacker connects to database impersonating web server
Likelihood: Very Low (internal network, firewall rules)
Impact: High (full data access)
Mitigation: Database credentials in AWS Secrets Manager (rotated), security groups (whitelist web server IPs only), IAM database authentication
Status: ✓ Implemented
Monitoring: Alert on new database connections from unexpected IPs, failed auth attempts

T - Tampering

Threat: SQL injection modifies data, drops tables
Likelihood: Medium (common vulnerability)
Impact: Critical (data loss, corruption, exfiltration)
Mitigation: Parameterized queries (ORM), input validation, least privilege DB user (no DROP/ALTER), read-only replicas for reporting, database backups
Status: ⚠ Partial (manual code review needed for all SQL)
Monitoring: Database audit log for DDL statements, unexpected UPDATE/DELETE volumes

R - Repudiation

Threat: Database changes cannot be attributed to specific user
Likelihood: Low (application logging in place)
Impact: Low (audit, compliance)
Mitigation: Application-level audit logging (user ID + action + timestamp), database query log (CloudWatch), immutable logs
Status: ✓ Implemented
Monitoring: Daily audit log integrity check

I - Information Disclosure

Threat: Database dump exposed through misconfiguration, backup left public
Likelihood: Medium (S3 misconfigurations common)
Impact: Critical (full data breach)
Mitigation: Encryption at rest (AES-256), encrypted backups, S3 bucket policies (private), no public snapshots, VPC endpoint for S3, data masking in non-prod
Status: ✓ Implemented
Monitoring: AWS Config rules for public S3 buckets, daily snapshot encryption check

D - Denial of Service

Threat: Expensive queries exhaust database CPU/memory
Likelihood: Medium (missing query optimization)
Impact: High (site unavailable)
Mitigation: Query timeouts (5s), connection pooling, read replicas, CloudWatch alarms on CPU (>80%), slow query log, query plan analysis
Status: ✓ Implemented
Monitoring: Alert on database CPU/memory, slow query log review weekly

E - Elevation of Privilege

Threat: Web server DB user escalates to DBA privileges
Likelihood: Very Low (IAM policies enforced)
Impact: High (full database control)
Mitigation: Least privilege DB grants (SELECT/INSERT/UPDATE only, no ALTER/DROP/GRANT), separate admin credentials, MFA for DB admin access
Status: ✓ Implemented
Monitoring: Alert on privilege grant operations, regular IAM policy audit

Risk Score:

Tampering (SQL injection): 2 × 4 = 8 (High - Priority 1)
Information Disclosure (backup exposure): 2 × 4 = 8 (High - Priority 1)
Denial of Service (query exhaustion): 2 × 3 = 6 (Medium)
Spoofing: 1 × 3 = 3 (Low)
Repudiation: 1 × 1 = 1 (Low)
Elevation of Privilege: 1 × 3 = 3 (Low)

Top Risks for This Boundary: SQL injection (Tampering), Backup exposure (Information Disclosure)

[Repeat STRIDE analysis for each trust boundary identified above]

Mitigations & Monitoring

Preventive Controls (block attacks before they succeed):

Control	Threats Mitigated	Implementation	Owner	Status
TLS 1.2+ enforcement	Tampering (MITM)	ALB listener policy	DevOps	✓ Done
Parameterized queries	Tampering (SQLi)	ORM (Sequelize)	Engineering	⚠ Partial
Input validation	Tampering, Injection	Joi schema validation	Engineering	✓ Done
Rate limiting	DoS	WAF rules (100 req/min/IP)	DevOps	✓ Done
CSRF tokens	Spoofing (CSRF)	csurf middleware	Engineering	✓ Done
HttpOnly cookies	Spoofing (XSS → session theft)	Express cookie settings	Engineering	✓ Done
Least privilege IAM	Elevation of Privilege	IAM policies	DevOps	✓ Done
MFA for admin	Spoofing (credential theft)	AWS IAM MFA	DevOps	✓ Done
Encryption at rest	Information Disclosure	RDS encryption, S3 default encryption	DevOps	✓ Done
WAF (OWASP Top 10)	Multiple (SQLi, XSS, etc.)	AWS WAF managed rules	DevOps	✓ Done

Detective Controls (identify attacks in progress or after):

Control	Detection Method	Alert Threshold	Incident Response	Owner	Status
Failed login monitoring	CloudWatch Logs Insights	>5 failures in 5 min from same IP	Auto-block IP (24h), notify security team	DevOps	✓ Done
SQL injection attempts	WAF logs + application logs	Any blocked SQLi pattern	Security review of attempted payload	Security	✓ Done
Unusual data access	Database audit log	User accessing >1000 records in 1 min	Throttle user, security review	Engineering	⚠ Partial
Privilege escalation attempts	Application audit log	Non-admin accessing admin endpoints	Block user, security review	Engineering	✓ Done
Geo-impossible travel	Session activity log	Login from US then Asia <2 hours	Force re-auth, notify user	Engineering	⚠ TODO
DDoS detection	CloudWatch metrics	Traffic >10x baseline	Engage AWS Shield Response Team	DevOps	✓ Done
Backup integrity	S3 lifecycle checks	Missing daily backup	Page on-call, investigate	DevOps	✓ Done
Secret rotation overdue	Secrets Manager	>90 days since rotation	Automated rotation, alert if fails	DevOps	✓ Done

Corrective Controls (respond to and recover from attacks):

Scenario	Response Plan	Recovery Time Objective (RTO)	Recovery Point Objective (RPO)	Owner	Tested?
Database compromise	Restore from backup, rotate credentials, forensic analysis	<4 hours	<24 hours (daily backups)	DevOps	⚠ Last tested 6 months ago
DDoS attack	Enable AWS Shield Advanced, adjust WAF rules, failover to static site	<15 minutes	N/A	DevOps	✓ Tested quarterly
Credential leak	Rotate all secrets, force password resets, revoke sessions, notify users	<1 hour	N/A	Security	⚠ Runbook exists, not tested
Data breach	Incident response plan, legal notification, forensic preservation, public disclosure	<72 hours (GDPR)	N/A	Legal + Security	⚠ Tabletop exercise needed

Risk Prioritization

Risk Matrix (Likelihood × Impact):

Threat	Likelihood (1-5)	Impact (1-5)	Risk Score	Priority	Mitigation Status	Residual Risk
SQL injection	3 (Medium)	5 (Critical)	15	P0 (Critical)	Partial (manual review needed)	Medium
Backup exposure	2 (Low)	5 (Critical)	10	P1 (High)	Implemented	Low
Session hijacking	3 (Medium)	4 (High)	12	P1 (High)	Implemented	Medium
DDoS	3 (Medium)	4 (High)	12	P1 (High)	Implemented	Low
Info disclosure (errors)	3 (Medium)	2 (Medium)	6	P2 (Medium)	Partial	Medium
Credential stuffing	2 (Low)	4 (High)	8	P2 (Medium)	Implemented (rate limiting)	Low
CSRF	2 (Low)	3 (Medium)	6	P2 (Medium)	Implemented	Low
Query DoS	2 (Low)	3 (Medium)	6	P2 (Medium)	Implemented	Low

Top 3 Priorities:

SQL Injection (P0): Complete manual code review of all SQL queries, add automated SQLi detection in CI/CD
Session Hijacking (P1): Implement geo-impossible travel detection, add device fingerprinting
DDoS Protection (P1): Test Shield Advanced failover, document runbook

Accepted Risks:

CSRF on read-only endpoints: Low impact (no state change), cost of tokens on every GET outweighs risk
Verbose logging in development: Acceptable in dev/staging (not in production), aids debugging

Action Items

Action	Owner	Deadline	Priority	Status
[Manual SQL code review for parameterized queries]	Engineering	2 weeks	P0	🔴 Not Started
[Implement geo-impossible travel detection]	Engineering	1 month	P1	🔴 Not Started
[Audit all error messages for information disclosure]	Engineering	2 weeks	P2	🔴 Not Started
[Test database restore procedure]	DevOps	1 week	P1	🟡 In Progress
[Tabletop exercise for data breach response]	Security + Legal	1 month	P1	🔴 Not Started
[Document DDoS runbook and test]	DevOps	2 weeks	P1	🟡 In Progress
[Rotate all API keys]	DevOps	Immediately	P0	✅ Done

Guidance for Each Section

System Architecture: Include visual diagram, technology stack (specific versions), network zones (DMZ/VPC/Internet), external dependencies (SaaS, APIs). Avoid vague descriptions.

Data Classification: Classify every element (public/internal/confidential/restricted), consult legal/compliance for PII/PHI/PCI, document retention and encryption. Don't forget data in logs/analytics/backups.

STRIDE Application: Apply all 6 categories to each boundary. Start with high-risk boundaries (user input, external integrations). Likelihood: 1=sophisticated attacker, 3=script kiddie, 5=trivial. Impact: 1=nuisance, 3=significant exposure, 5=complete compromise.

Mitigation Status: ✓ Implemented, ⚠ Partial, 🔴 TODO, ✅ Done

20 KiB Raw Permalink Blame History Unescape Escape