Infrastructure Security & Network Hardening
- Executive Summary
- Working Knowledge
- Technical Spec
Securing the Foundation
Infrastructure security is the bedrock on which all other security controls rest. ReGenesis runs on AWS in the us-east-1 (N. Virginia) region, using a defense-in-depth architecture: multiple overlapping layers of protection so that no single failure creates a breach. The architecture includes private subnets for databases (no direct internet access), a Web Application Firewall (WAF) that filters malicious traffic, DDoS protection via AWS Shield, and strict network segmentation between environments.
For McKinsey and other Fortune 500 clients, infrastructure security is heavily scrutinized. Enterprise procurement teams expect to see a professional network architecture diagram, evidence of regular penetration testing, vulnerability scanning, and environment separation. ReGenesis meets these expectations with a VPC design that mirrors enterprise best practices, Infrastructure as Code via Terraform for reproducibility and auditability, and a commitment to annual penetration testing with remediation SLAs.
The infrastructure is designed for a US-first launch with EU-grade security standards, and the architecture supports multi-region expansion without re-engineering. All infrastructure changes are version-controlled, peer-reviewed, and deployed through automated CI/CD pipelines -- there is no manual SSH access to production servers in normal operations.
Network Architecture
VPC Design
The Virtual Private Cloud (VPC) is the isolated network environment where all ReGenesis resources run. It functions as a private data center within AWS.
Key Design Principles
| Principle | Implementation |
|---|---|
| No public database access | Databases in private subnets with no internet gateway |
| Least privilege networking | Security groups allow only required traffic on required ports |
| Multi-AZ deployment | App servers and databases span two availability zones |
| Outbound control | All outbound traffic routes through NAT Gateway (auditable) |
| No SSH to production | SSM Session Manager for emergency access (logged, audited) |
| Immutable infrastructure | Servers are replaced, never patched in place |
| Infrastructure as Code | All infra defined in Terraform, version-controlled |
Security Layers
Web Application Firewall (WAF)
The WAF sits in front of the application and blocks common attack patterns before they reach the application servers:
| Rule Group | What It Blocks | Source |
|---|---|---|
| AWS Managed Core Rule Set | XSS, SQLi, command injection, path traversal | AWS |
| Known Bad Inputs | Known exploit payloads, Log4j patterns | AWS |
| SQL Injection | SQL injection attempts in all parameters | AWS |
| IP Reputation | Known malicious IP addresses | AWS |
| Rate Limiting | More than 2000 requests per 5 minutes per IP | Custom |
| Geo-Blocking | Block traffic from sanctioned countries | Custom |
| Bot Control | Block known bad bots, challenge unknown bots | AWS |
DDoS Protection
| Layer | Protection | Service |
|---|---|---|
| Layer 3/4 (network) | Volumetric flood protection | AWS Shield Standard (free, always on) |
| Layer 7 (application) | Application-layer DDoS | AWS Shield Advanced (recommended for pilot+) |
| DNS | DNS-layer attack protection | Route 53 + Shield |
| CDN | Absorb traffic at edge | CloudFront |
Environment Separation
| Environment | Purpose | Network | Data | Access |
|---|---|---|---|---|
| Development | Developer testing | Separate VPC | Synthetic data only | All developers |
| Staging | Pre-production validation | Separate VPC | Anonymized production subset | DevOps + QA |
| Production | Live platform | Production VPC | Real client data | Automated deploys only |
Production, staging, and development run in completely separate VPCs with no network connectivity between them. There are no shared credentials, databases, or encryption keys across environments. A developer with staging access has zero access to production data.
Penetration Testing
| Aspect | Detail |
|---|---|
| Frequency | Annual (minimum), plus before major releases |
| Scope | External + internal, web app + API + mobile |
| Provider | Independent third-party firm (CREST/OSCP certified) |
| Methodology | OWASP Testing Guide, PTES, custom AI threat scenarios |
| Remediation SLA | Critical: 24h, High: 7 days, Medium: 30 days, Low: 90 days |
| Retesting | Critical/High findings retested after remediation |
| Report | Executive summary available to enterprise clients |
| First test | Before McKinsey pilot |
Vulnerability Scanning
| Tool | Scope | Frequency |
|---|---|---|
| Dependabot | npm dependencies (known CVEs) | Daily |
| OWASP ZAP / Burp | Dynamic application scanning | Weekly (automated) |
| Trivy | Container image vulnerabilities | On every build |
| AWS Inspector | EC2/container vulnerabilities | Continuous |
| AWS Config | Infrastructure misconfigurations | Continuous |
Server Hardening
For containerized workloads (ECS Fargate or EKS):
| Control | Implementation |
|---|---|
| Minimal base images | Distroless or Alpine-based images |
| No root process | Application runs as non-root user |
| Read-only filesystem | Container filesystem is read-only |
| No shell access | No bash/sh in production containers |
| Resource limits | CPU and memory limits enforced |
| Health checks | Liveness and readiness probes |
| Image signing | Images signed with Cosign/Notation |
| Image scanning | Scanned before deployment |
Certificate Pinning (Mobile)
For the ReGenesis mobile app, certificate pinning prevents man-in-the-middle attacks by verifying that the server certificate matches a known value:
| Platform | Implementation |
|---|---|
| iOS | URLSessionDelegate with pinned certificate hashes |
| Android | Network Security Config with pinned certificates |
| Pin rotation | Include current + next certificate pin; rotate quarterly |
| Fallback | If pin fails, block connection and alert user |