Secure by Design Principles
Secure by Design means building security into the foundation of systems rather than adding it later. These principles, derived from Saltzer and Schroeder's classic work, guide architects in creating inherently secure systems.
Saltzer & Schroeder's Principles
1. Economy of Mechanism
Keep the design as simple as possible. Every added complexity increases the attack surface.
- • Simpler systems are easier to analyze and verify
- • Fewer components = fewer vulnerabilities
- • Avoid clever or tricky implementations
2. Fail-Safe Defaults
Base access decisions on permission rather than exclusion. Default to deny.
- • New users have no access until explicitly granted
- • Missing configuration = secure state
- • Errors result in denied access, not granted
3. Complete Mediation
Every access to every object must be checked for authorization.
- • No caching of access decisions that can go stale
- • Check permissions at each request, not just login
- • Verify authorization at the resource level
4. Open Design
Security should not depend on the secrecy of the design (Kerckhoffs's principle).
- • Algorithms should be publicly known and reviewed
- • Security comes from keys, not hidden mechanisms
- • Open source allows more eyes to find bugs
5. Separation of Privilege
Require multiple conditions or parties to grant access to critical operations.
- • Two-person rule for sensitive operations
- • MFA requires multiple factors
- • Approval workflows for privileged actions
6. Least Privilege
Every program and user should operate with the minimum privileges needed.
- • Time-limited elevated access
- • Scoped API tokens and service accounts
- • Drop privileges after initialization
7. Least Common Mechanism
Minimize shared mechanisms between users to reduce information leakage.
- • Separate processes for different trust levels
- • Tenant isolation in multi-tenant systems
- • Avoid shared caches with sensitive data
8. Psychological Acceptability
Security mechanisms should not make the system harder to use than without them.
- • Users shouldn't need to bypass security to work
- • Intuitive security interfaces
- • Balance security with usability
Privacy by Design
Privacy by Design (PbD) is a framework developed by Ann Cavoukian that embeds privacy into the design of systems. It's required by GDPR and similar regulations.
1. Proactive not Reactive
Anticipate and prevent privacy issues before they occur.
2. Privacy as Default
Maximum privacy without user action required.
3. Privacy in Design
Embedded into design, not added as an afterthought.
4. Full Functionality
Avoid false tradeoffs; achieve both privacy and functionality.
5. End-to-End Security
Protect data throughout its entire lifecycle.
6. Visibility & Transparency
Operations verifiable by users and auditors.
7. Respect for User Privacy
User-centric design with strong defaults, consent mechanisms, and data subject rights.
Data Minimization
The Best Security
Collection Minimization
- • Only collect data you actually need
- • Question every field in forms
- • Use derived data instead of raw data when possible
Retention Minimization
- • Define retention periods for all data types
- • Automate data deletion
- • Anonymize instead of delete when aggregates needed
Access Minimization
- • Limit who can access sensitive data
- • Implement need-to-know access controls
- • Log and audit all access to sensitive data
Secure Defaults Checklist
- ☐ Authentication required for all endpoints by default
- ☐ HTTPS enforced, HTTP redirects to HTTPS
- ☐ Security headers enabled (CSP, HSTS, X-Frame-Options)
- ☐ Debug mode disabled in production
- ☐ Error messages don't expose stack traces
- ☐ Admin interfaces on separate ports/paths
- ☐ Database connections use TLS
- ☐ Logging enabled but sensitive data redacted
- ☐ Rate limiting active on all endpoints
- ☐ CORS restricted to known origins