Defense in Depth
Defense in Depth is a security strategy that layers multiple security controls throughout an IT system. If one layer fails, other layers continue to provide protection.
The Castle Analogy
Security Layers
Physical Security
Data center access controls, surveillance, environmental controls, hardware security.
- • Biometric access to server rooms
- • Security cameras and motion sensors
- • Hardware destruction policies
Network Security
Firewalls, IDS/IPS, network segmentation, DDoS protection, VPNs.
- • Next-gen firewalls with deep packet inspection
- • Network segmentation with VLANs
- • Zero Trust network architecture
Perimeter Security
WAF, API gateways, DDoS mitigation, email security, reverse proxies.
- • Web Application Firewall (WAF) rules
- • Rate limiting and throttling
- • Bot detection and mitigation
Host Security
OS hardening, endpoint protection, host-based firewalls, patch management.
- • Minimal OS installations
- • EDR/XDR solutions
- • Automated patching pipelines
Application Security
Secure coding, input validation, authentication, authorization, SAST/DAST.
- • Security-focused code reviews
- • OWASP Top 10 mitigations
- • Runtime application self-protection (RASP)
Data Security
Encryption, access controls, DLP, backup and recovery, data classification.
- • Encryption at rest and in transit
- • Database activity monitoring
- • Data loss prevention (DLP) rules
Network Segmentation
Network segmentation divides a network into smaller, isolated segments. This limits lateral movement and contains breaches to a single segment.
DMZ Architecture
Isolate public-facing services from internal network.
Internet → [Firewall] → DMZ → [Firewall] → Internal
- • Web servers in DMZ
- • Database servers internal
- • Strict ingress/egress rules
Micro-Segmentation
Granular segmentation at workload level.
App1 ←→ DB1 only App2 ←→ DB2 only App1 ✗ DB2 blocked
- • Software-defined networking
- • Container network policies
- • Service mesh enforcement
Principle of Least Privilege
Every user, process, and system should have only the minimum permissions necessary to perform their function. Nothing more.
User Accounts
- • No standing admin privileges—use just-in-time access
- • Separate accounts for admin and daily work
- • Regular access reviews and recertification
- • Automatic deprovisioning when roles change
Service Accounts
- • Unique service account per application
- • No interactive login allowed
- • Scoped permissions to specific resources
- • Credential rotation policies
Database Access
- • Application accounts with only needed tables/procedures
- • Read-only replicas for reporting
- • No direct production database access
- • Stored procedures instead of direct queries
Fail-Safe Defaults
Deny by Default
- • Firewall: Block all, allow specific
- • IAM: No permissions until granted
- • API: Require authentication
- • Features: Opt-in, not opt-out
Fail Securely
- • Errors don't expose sensitive data
- • Auth failures deny access, don't skip
- • Exceptions caught and handled safely
- • Timeouts close connections cleanly
Redundancy & Resilience
No Single Points of Failure
Critical security controls should have redundancy. If one WAF fails, another takes over.
Graceful Degradation
Systems should maintain security even when components fail. Read-only mode is safer than complete shutdown.
Circuit Breakers
Automatically stop calling failing services to prevent cascade failures and resource exhaustion.