Documentation Index
Fetch the complete documentation index at: https://resources.devweekends.com/llms.txt
Use this file to discover all available pages before exploring further.
Capstone Project: SecureHealth Platform
This capstone project challenges you to build a fully HIPAA-compliant healthcare application from the ground up. You’ll implement all the security controls, compliance measures, and best practices covered throughout this course.Project Overview
What You’ll Build
SecureHealth - A patient portal and clinical management system featuring:Patient Portal
Clinical Interface
Admin Dashboard
Integration APIs
Technology Stack
Phase 1: Foundation & Architecture (Week 1)
Objectives
- Set up secure development environment
- Design database schema with PHI classification
- Implement core security infrastructure
- Create project structure following security best practices
1.1 Project Setup
1.2 Encryption Service
Implement the encryption service for PHI:Phase 1 Deliverables
- Project repository with security-focused structure
- Database schema with PHI classification
- Encryption service with key management integration
- Development environment with secrets management
- Initial security documentation
Phase 2: Authentication & Access Control (Week 2)
Objectives
- Implement secure authentication with MFA
- Build role-based access control (RBAC)
- Create session management with security controls
- Implement break-glass procedures
2.1 Authentication System
2.2 Role-Based Access Control
Phase 2 Deliverables
- Authentication service with MFA
- RBAC implementation with minimum necessary
- Session management with security controls
- Break-glass procedure implementation
- Password policy enforcement
Phase 3: Audit Logging & Monitoring (Week 3)
Objectives
- Implement comprehensive audit logging
- Create PHI access tracking
- Build anomaly detection system
- Design audit reporting for compliance
3.1 Audit Logging Service
Phase 3 Deliverables
- Comprehensive audit logging for all PHI access
- Authentication event logging
- Anomaly detection rules
- Accounting of Disclosures report
- Audit log integrity verification
Phase 4: API Security & Integration (Week 4)
Objectives
- Build secure REST API with HIPAA controls
- Implement API rate limiting and throttling
- Create secure third-party integration patterns
- Build data validation and sanitization
4.1 Secure API Endpoints
Phase 4 Deliverables
- Secure API endpoints with authentication
- Permission-based access control on all endpoints
- Request/response validation
- Rate limiting implementation
- API documentation with security notes
Phase 5: Infrastructure & Deployment (Week 5)
Objectives
- Deploy to HIPAA-eligible cloud infrastructure
- Implement infrastructure as code
- Configure security monitoring
- Set up backup and disaster recovery
5.1 Terraform Infrastructure
Phase 5 Deliverables
- HIPAA-compliant AWS infrastructure
- Terraform modules for all components
- Security groups with least privilege
- CloudTrail and CloudWatch configuration
- Backup and DR procedures
Phase 6: Testing & Compliance Validation (Week 6)
Objectives
- Security testing (penetration testing prep)
- Compliance checklist validation
- Documentation completion
- Final review and sign-off
6.1 Security Testing Checklist
6.2 Compliance Checklist
Final Compliance Checklist
Final Compliance Checklist
- Unique user identification
- Emergency access procedure (break-glass)
- Automatic logoff
- Encryption and decryption
- Audit log mechanism implemented
- Logs retained for 6 years
- Log integrity verification
- Regular log review process
- Authentication of ePHI
- Change detection mechanism
- Integrity controls
- Encryption in transit (TLS 1.2+)
- Risk analysis documented
- Risk management plan
- Sanction policy
- Information system activity review
- Access authorization policy
- Workstation use policy
- Device and media controls
- Audit controls policy
Phase 6 Deliverables
- Complete security test suite
- Penetration testing report (if applicable)
- Compliance checklist completed
- Risk assessment documentation
- Policies and procedures documentation
- User training materials
Grading Rubric
| Component | Weight | Criteria |
|---|---|---|
| Architecture & Design | 15% | Clean architecture, security-first design, proper PHI handling |
| Encryption Implementation | 20% | Proper encryption at rest and in transit, key management |
| Access Control | 20% | RBAC, minimum necessary, break-glass procedures |
| Audit Logging | 15% | Comprehensive logging, PHI access tracking, reporting |
| API Security | 10% | Secure endpoints, validation, rate limiting |
| Infrastructure | 10% | HIPAA-eligible services, proper configuration |
| Testing & Documentation | 10% | Security tests, compliance documentation |
Submission Requirements
-
Code Repository
- Complete source code
- README with setup instructions
- Environment configuration (without secrets)
-
Documentation
- Architecture diagram
- Security controls documentation
- Risk assessment summary
- Policies and procedures
-
Demo
- Working deployment (local or cloud)
- Walkthrough of security features
- Audit log demonstration
-
Testing
- Security test results
- Compliance checklist (completed)
- Any penetration testing results
Congratulations!
Upon completing this capstone, you will have:Built Real Security
Practical Experience
Compliance Knowledge
Portfolio Project
Interview Deep-Dive
You are presenting the architecture of your HIPAA-compliant healthcare platform to a panel of security reviewers. They ask: 'What is the single biggest security risk in this system and how did you mitigate it?' How do you answer?
You are presenting the architecture of your HIPAA-compliant healthcare platform to a panel of security reviewers. They ask: 'What is the single biggest security risk in this system and how did you mitigate it?' How do you answer?
- The single biggest security risk is the key management layer — specifically, the concentration of decryption capability in HashiCorp Vault or AWS KMS. If the key management system is compromised, the attacker can decrypt every piece of PHI in the database, every encrypted message, and every encrypted backup. Every other security control (RBAC, audit logging, network segmentation) becomes irrelevant if the attacker has the keys.
- How I mitigated this: First, the key management system runs in its own isolated security zone with no direct internet access, restricted network paths, and a dedicated security group. Only the application’s encryption service can reach Vault, and only from specific private subnet IPs. Second, Vault is configured with auto-unseal using a cloud KMS key (avoiding the operational risk of manual unseal keys) but the auto-unseal key itself requires IAM authentication with MFA and condition keys. Third, the key hierarchy uses envelope encryption so that a Vault compromise does not immediately expose data — the attacker needs both Vault access AND database access. Fourth, Vault’s own audit log tracks every key operation (encrypt, decrypt, rotate, create) and feeds into the SIEM with real-time alerting on anomalous patterns (unusual volume of decrypt operations, access from unexpected IPs, access outside business hours). Fifth, key material is never exported from Vault — the application sends data to Vault for encryption/decryption rather than extracting keys and using them locally. This means there is no key material in application memory to be dumped by an attacker who compromises the application server.
- The defense-in-depth principle: no single compromise should lead to total data exposure. An attacker who compromises the application server cannot decrypt without Vault access. An attacker who compromises Vault cannot read data without database access. An attacker who compromises the database sees only ciphertext without Vault access.
Your capstone project uses FastAPI with async database access, Redis sessions, and field-level encryption. An interviewer asks: 'If I gave you 10x the traffic tomorrow, what breaks first?' Walk through the scaling bottlenecks.
Your capstone project uses FastAPI with async database access, Redis sessions, and field-level encryption. An interviewer asks: 'If I gave you 10x the traffic tomorrow, what breaks first?' Walk through the scaling bottlenecks.
- At 10x traffic, the first bottleneck is the encryption/decryption layer. Every PHI read requires DEK unwrapping (KMS API call) and AES decryption. At 10x, the KMS API rate limits become the constraint — AWS KMS has a default limit of 5,500 requests per second per region for symmetric operations. If each patient record read requires one KMS call, and you are doing 5,000 reads per second, you are already at the limit. Mitigation: implement DEK caching. Cache unwrapped DEKs in application memory for their rotation period. This converts N KMS calls per patient into 1 KMS call per DEK, with all subsequent decryptions using the cached key. This alone provides 100-1000x improvement in the encryption layer.
- The second bottleneck is the PostgreSQL connection pool. Async SQLAlchemy uses a connection pool, but at 10x traffic, you exhaust the pool and requests queue. The encrypted columns (BYTEA type) are also larger than plaintext, increasing I/O per query. Mitigation: add read replicas for read-heavy workloads (patient record lookups), tune the connection pool size, and implement database-level connection pooling with PgBouncer.
- The third bottleneck is the audit logging pipeline. At 10x traffic, the audit logger processes 10x events. If the flush interval and batch size are not tuned, the in-memory buffer grows unbounded or flush operations back-pressure the API. Mitigation: increase the batch size (from 100 to 500), use async writes exclusively, and add a message queue (Kafka or SQS) between the audit service and the database so that audit log writes are fully decoupled from API request handling.
- The fourth bottleneck is Redis session management. At 10x concurrent users, Redis memory usage increases linearly. Each session stores metadata plus last-activity timestamps updated on every request. At 10x, you are doing 10x Redis writes per second for activity tracking. Mitigation: batch activity updates (update Redis every 30 seconds instead of every request), use Redis Cluster for horizontal scaling, and tune session TTLs to free memory faster.
- What does NOT break: the RBAC policy evaluation (in-memory, no external calls), TLS termination (handled by the load balancer, scales horizontally), and the FastAPI application itself (async framework handles concurrent requests efficiently with more workers).
A security auditor reviewing your capstone project says: 'Show me how you would demonstrate compliance with HIPAA Section 164.312(b) -- Audit Controls -- for your entire platform.' What do you present?
A security auditor reviewing your capstone project says: 'Show me how you would demonstrate compliance with HIPAA Section 164.312(b) -- Audit Controls -- for your entire platform.' What do you present?
- Section 164.312(b) requires: “Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.” I would present a comprehensive demonstration covering four areas.
- Area one — what we log: demonstrate the audit event schema capturing the complete W5 for every PHI interaction. Show live audit events being generated by normal platform operations: a patient login (authentication event), viewing a record (PHI access event), a provider updating a note (PHI modification event with old/new values), and a failed authorization attempt (security event). Show that the event captures actor identity, timestamp, resource, action, outcome, and data fields accessed.
- Area two — how we store and protect logs: show the PostgreSQL audit_logs table with append-only triggers preventing UPDATE and DELETE. Demonstrate the hash chain by showing two consecutive events and verifying the previous_hash linkage. Show the digital signature verification on a sample event using the public key. Show the partition strategy and retention configuration (7 years of monthly partitions). Show the role separation — the auditor role has SELECT-only access, the application role has INSERT-only access, no role has UPDATE or DELETE.
- Area three — how we examine logs: demonstrate the audit dashboard showing real-time event streaming, filterable by event type, actor, patient, and time range. Show the anomaly detection alerts: a simulated brute-force login attempt triggering a threshold alert, a break-glass access generating an immediate critical alert. Run the chain integrity verification tool against the last 24 hours and show a clean verification report with zero errors.
- Area four — how we maintain the system: show the daily automated integrity verification checkpoints and their stored results. Show the archival pipeline moving old partitions to encrypted cold storage. Show the quarterly access review process where the compliance team reviews who has access to audit logs. Show the incident response integration: when an alert fires, it creates a ticket in the incident management system with a link to the relevant audit events.
- Close with: “Section 164.312(b) requires mechanisms to record and examine. We record comprehensively with tamper-proof integrity, and we examine through real-time alerting, dashboards, and scheduled reviews. Here is the documentation that describes all of this for your compliance file.”