quality attributes
Security: Designing for Protection
Architectural tactics and patterns for building secure systems that protect against threats while enabling business functionality.
Security: Designing for Protection
TL;DR
Security architecture protects systems through defense in depth: multiple layers of controls so that no single failure compromises the system. Focus on the CIA triad (Confidentiality, Integrity, Availability), implement least privilege access, validate all inputs, encrypt data in transit and at rest, and assume breach in your design.
Key Takeaways
- Defense in depth: Multiple security layers, not a single perimeter
- Least privilege: Grant minimum access required for the task
- Zero trust: Verify explicitly, never trust by default
- Shift left: Integrate security into development, not just operations
- Assume breach: Design as if attackers are already inside
Why This Matters
Security breaches cost organizations an average of $4.45 million per incident (IBM 2023). Beyond financial impact, breaches damage reputation, erode customer trust, and trigger regulatory penalties. Security can't be bolted on after the fact—it must be designed into the architecture from the start. The goal isn't to eliminate all risk (impossible) but to reduce risk to acceptable levels through appropriate controls.
Security vs Usability
Security and usability often conflict. Excessive security measures frustrate users and lead to workarounds (password Post-it notes). Design security that users can actually follow.
Security Fundamentals
CIA Triad
SECURITY OBJECTIVES
┌─────────────────────┐
│ CONFIDENTIALITY │
│ (Who can see it?) │
└─────────┬───────────┘
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
┌───────┐ ┌───────────┐ ┌──────────┐
│ │ │ │ │ │
│ CIA │ │ INTEGRITY │ │AVAILABILITY│
│ TRIAD │ │(Is it │ │(Can I │
│ │ │ accurate?)│ │ access?) │
└───────┘ └───────────┘ └──────────┘
CONFIDENTIALITY: Prevent unauthorized disclosure
INTEGRITY: Prevent unauthorized modification
AVAILABILITY: Ensure authorized access when needed
Zero Trust Model
ZERO TRUST PRINCIPLES
TRADITIONAL (Castle & Moat)
┌─────────────────────────────────────┐
│ Trusted Network │
│ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │ App │ │ DB │ │Users│ │
│ └─────┘ └─────┘ └─────┘ │
│ (implicit trust) │
└─────────────────────────────────────┘
Firewall (perimeter)
ZERO TRUST (Never Trust, Always Verify)
┌─────────────────────────────────────┐
│ ┌───────────────────────┐ │
│ │ Identity Verification │ │
│ └───────────┬───────────┘ │
│ ┌──────────────┼──────────────┐ │
│ ▼ ▼ ▼ │
│ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │ App │ ←──→ │ DB │ ←──→ │User │ │
│ └─────┘ └─────┘ └─────┘ │
│ (verify) (verify) (verify) │
└─────────────────────────────────────┘
ZERO TRUST PILLARS
├── Verify explicitly (authenticate/authorize)
├── Least privilege access (minimum necessary)
└── Assume breach (design for compromise)
Threat Modeling
THREAT MODELING PROCESS (STRIDE)
1. IDENTIFY ASSETS
└── What are we protecting?
2. IDENTIFY THREATS (STRIDE)
├── Spoofing: Impersonating something/someone
├── Tampering: Modifying data
├── Repudiation: Denying actions
├── Information Disclosure: Exposing data
├── Denial of Service: Preventing access
└── Elevation of Privilege: Gaining access
3. IDENTIFY VULNERABILITIES
└── What weaknesses enable threats?
4. PRIORITIZE RISKS
└── Likelihood × Impact = Risk
5. MITIGATE
└── Apply controls or accept risk
Security Tactics
Goal
Identify security incidents quickly to minimize impact.
Tactics
| Tactic | Description | Implementation |
|---|---|---|
| Intrusion Detection | Identify malicious activity | IDS/IPS, anomaly detection |
| Logging & Monitoring | Record security events | SIEM, audit logs |
| Input Validation | Detect malformed input | Allowlists, sanitization |
| Integrity Checks | Detect tampering | Checksums, signatures |
Security Logging
SECURITY LOG ESSENTIALS
WHAT TO LOG
├── Authentication events (success/failure)
├── Authorization decisions (granted/denied)
├── Data access (read/write to sensitive data)
├── Configuration changes
├── Administrative actions
└── Security exceptions
LOG FORMAT
{
"timestamp": "2024-01-15T10:30:00Z",
"event": "authentication_failure",
"actor": "user@example.com",
"source_ip": "203.0.113.42",
"resource": "/api/login",
"result": "failure",
"reason": "invalid_password",
"session_id": "abc123"
}
WHAT NOT TO LOG
├── Passwords or secrets
├── Full credit card numbers
├── Session tokens
└── PII (unless necessary and encrypted)
Detection Speed
Mean Time to Detect (MTTD) is critical. IBM found breaches detected in under 200 days cost $3.93M vs $4.95M for longer detection times. Invest in detection capabilities.
Defense in Depth
DEFENSE IN DEPTH LAYERS
┌─────────────────────────────────────────────────────────────┐
│ POLICIES & PROCEDURES │
│ Security policies, training, acceptable use │
├─────────────────────────────────────────────────────────────┤
│ PHYSICAL │
│ Data center security, badges, locks │
├─────────────────────────────────────────────────────────────┤
│ PERIMETER │
│ Firewall, DDoS protection, WAF │
├─────────────────────────────────────────────────────────────┤
│ NETWORK │
│ Segmentation, IDS/IPS, network ACLs │
├─────────────────────────────────────────────────────────────┤
│ HOST │
│ OS hardening, antimalware, patch management │
├─────────────────────────────────────────────────────────────┤
│ APPLICATION │
│ Input validation, authentication, authorization │
├─────────────────────────────────────────────────────────────┤
│ DATA │
│ Encryption, access controls, classification │
└─────────────────────────────────────────────────────────────┘
Cloud Security
Shared Responsibility Model
SHARED RESPONSIBILITY (AWS Example)
CUSTOMER RESPONSIBLE FOR (Security IN the Cloud)
├── Customer data
├── Platform, applications, IAM
├── Operating system, network, firewall config
├── Client-side encryption
└── Server-side encryption
AWS RESPONSIBLE FOR (Security OF the Cloud)
├── Hardware/AWS Global Infrastructure
├── Regions, Availability Zones, Edge Locations
├── Compute, Storage, Database, Networking
└── Software (managed services)
VARIES BY SERVICE TYPE
├── IaaS (EC2): Customer manages most
├── PaaS (RDS): Shared management
└── SaaS (S3): AWS manages most
Cloud Security Controls
| Layer | AWS | Azure |
|---|---|---|
| Identity | IAM, Organizations | Azure AD, RBAC |
| Network | VPC, Security Groups, WAF | VNet, NSG, Azure Firewall |
| Data | KMS, Secrets Manager | Key Vault |
| Detection | GuardDuty, CloudTrail | Sentinel, Defender |
| Compliance | Config, Security Hub | Policy, Compliance Manager |
Secure Development (DevSecOps)
SHIFT LEFT SECURITY
TRADITIONAL
Design → Develop → Test → Deploy → Security Review
↑
(Too late, expensive to fix)
DEVSECOPS
Design → Develop → Test → Deploy
↓ ↓ ↓ ↓
Security Security Security Security
Modeling Scanning Testing Monitoring
SECURITY IN CI/CD
┌─────────────────────────────────────────────────────────────┐
│ Code │ Build │ Test │ Deploy │ Monitor │
├──────────┼──────────┼──────────┼───────────┼───────────────┤
│ SAST │ SCA │ DAST │ CSPM │ SIEM │
│ Pre- │ Depend- │ Security │ Config │ Runtime │
│ commit │ encies │ scan │ audit │ protection │
│ hooks │ │ │ │ │
└──────────┴──────────┴──────────┴───────────┴───────────────┘
Security Testing Types
| Type | What It Tests | When |
|---|---|---|
| SAST | Source code | During development |
| SCA | Dependencies | Build time |
| DAST | Running application | Test environment |
| IAST | Application runtime | Test environment |
| Pen Test | Full system | Pre-production |
Quick Reference Card
┌─────────────────────────────────────────────────────────────┐
│ SECURITY CHEAT SHEET │
├─────────────────────────────────────────────────────────────┤
│ │
│ CIA TRIAD │
│ ───────────────────────────────────────────────────────── │
│ Confidentiality → Who can see it? │
│ Integrity → Is it accurate? │
│ Availability → Can I access it? │
│ │
│ ZERO TRUST PRINCIPLES │
│ ───────────────────────────────────────────────────────── │
│ • Verify explicitly (never implicit trust) │
│ • Least privilege access (minimum necessary) │
│ • Assume breach (design for compromise) │
│ │
│ OWASP TOP 3 DEFENSES │
│ ───────────────────────────────────────────────────────── │
│ 1. Validate all inputs (server-side) │
│ 2. Parameterized queries (prevent injection) │
│ 3. Encode output (prevent XSS) │
│ │
│ ENCRYPTION REQUIREMENTS │
│ ───────────────────────────────────────────────────────── │
│ In Transit → TLS 1.2+ (HTTPS everywhere) │
│ At Rest → AES-256 (database, storage) │
│ Secrets → Key Vault/Secrets Manager │
│ │
│ AUTHENTICATION │
│ ───────────────────────────────────────────────────────── │
│ Best → Passwordless (FIDO2/WebAuthn) │
│ Good → MFA (password + authenticator) │
│ Minimum→ Strong passwords (12+ chars) │
│ │
│ QUICK WINS │
│ ───────────────────────────────────────────────────────── │
│ 1. Enable MFA everywhere │
│ 2. Encrypt data in transit and at rest │
│ 3. Scan dependencies for vulnerabilities │
│ 4. Enable security logging and alerting │
│ 5. Conduct threat modeling on critical systems │
│ │
└─────────────────────────────────────────────────────────────┘
Related Topics
- Quality Attributes Overview - All quality attributes
- Cloud Architecture - Cloud security patterns
- AWS Well-Architected - AWS Security Pillar
Sources
- OWASP - Open Web Application Security Project
- NIST Cybersecurity Framework
- AWS Security Best Practices
- Azure Security Documentation
- CIS Controls