Security Architect

What this skill does

# Security Architect

## Overview

Security Architect is a consolidated skill that covers the complete security lifecycle: threat modeling, secure design principles, secure coding practices, and regulatory compliance. It ensures security is integrated from the start, not bolted on at the end.

**Consolidated from:**

- **threat-modeling** - STRIDE threat analysis and risk assessment
- **security-first-design** - Security principles and secure design patterns
- **secure-coding-review** - OWASP Top 10 and vulnerability detection
- **compliance-validator** - GDPR, HIPAA, SOC2, PCI-DSS compliance

## When to Use This Skill

Use Security Architect when:

- Starting a new project (design phase)
- Conducting security architecture review
- Reviewing code for security vulnerabilities
- Ensuring regulatory compliance
- Responding to security incidents
- Planning for security certifications (SOC2, ISO 27001)
- Designing authentication and authorization systems

## Key Capabilities

### Threat Modeling (from threat-modeling)

- Apply STRIDE methodology for threat identification
- Assess risk levels (Likelihood × Impact)
- Create threat models and mitigation plans
- Identify attack surfaces and trust boundaries

### Security Design (from security-first-design)

- Apply security principles (Defense in Depth, Least Privilege, Zero Trust)
- Design secure authentication and authorization
- Implement encryption and key management
- Design secure APIs and data protection

### Secure Coding (from secure-coding-review)

- Review code against OWASP Top 10
- Detect injection vulnerabilities (SQL, XSS, command)
- Identify broken authentication and access control
- Ensure secure data handling and validation

### Compliance (from compliance-validator)

- Ensure GDPR, HIPAA, CCPA, SOC2, PCI-DSS compliance
- Implement data subject rights (access, erasure, portability)
- Design audit logging and retention policies
- Configure encryption and access controls

## Workflow

### Part 1: Threat Modeling (STRIDE)

#### STRIDE Framework

**S - Spoofing (Authentication)**

- **Threat:** Attacker impersonates a user or system
- **Examples:**
  - Stolen credentials
  - Session hijacking
  - Weak or no authentication
- **Mitigations:**
  - Multi-factor authentication (MFA)
  - Strong password policies
  - JWT with short expiration
  - Secure session management

**T - Tampering (Integrity)**

- **Threat:** Attacker modifies data or code
- **Examples:**
  - SQL injection
  - Man-in-the-middle attacks
  - Parameter manipulation
  - Code injection
- **Mitigations:**
  - Input validation and sanitization
  - HTTPS/TLS everywhere
  - Signed tokens (JWT)
  - Integrity checks (hashing)

**R - Repudiation (Accountability)**

- **Threat:** User denies performing an action
- **Examples:**
  - No audit logs
  - Unsigned transactions
  - Anonymous actions
- **Mitigations:**
  - Comprehensive audit logging
  - Digital signatures for transactions
  - Immutable log storage
  - User action tracking

**I - Information Disclosure (Confidentiality)**

- **Threat:** Sensitive data exposed to unauthorized parties
- **Examples:**
  - Exposed API keys
  - Database dumps
  - Verbose error messages
  - Insufficient access controls
- **Mitigations:**
  - Encryption at rest and in transit
  - Principle of least privilege
  - Secure secret management (AWS Secrets Manager, Vault)
  - Role-based access control (RBAC)

**D - Denial of Service (Availability)**

- **Threat:** System becomes unavailable to legitimate users
- **Examples:**
  - DDoS attacks
  - Resource exhaustion
  - Unhandled exceptions
- **Mitigations:**
  - Rate limiting and throttling
  - Input validation (reject massive payloads)
  - Auto-scaling infrastructure
  - CDN and DDoS protection (Cloudflare)

**E - Elevation of Privilege (Authorization)**

- **Threat:** User gains unauthorized access to higher privileges
- **Examples:**
  - Broken access control
  - Insecure direct object references (IDOR)
  - Missing authorization checks
- **Mitigations:**
  - Authorization checks on every request
  - Principle of least privilege
  - Attribute-based access control (ABAC)
  - Regular permission audits

---

#### Threat Modeling Process

**Step 1: Identify Assets**

- User data (PII, passwords, financial info)
- Business data (IP, customer lists, transactions)
- System credentials (API keys, certificates)
- Infrastructure (servers, databases, APIs)

**Step 2: Identify Trust Boundaries**

- User ↔ Web App
- Web App ↔ API
- API ↔ Database
- Internal services ↔ External APIs
- Admin ↔ Production systems

**Step 3: Apply STRIDE to Each Boundary**
For each boundary, ask:

- **S:** Can an attacker spoof identity?
- **T:** Can data be tampered with?
- **R:** Can actions be repudiated?
- **I:** Can information be disclosed?
- **D:** Can service be denied?
- **E:** Can privileges be elevated?

**Step 4: Assess Risk**

```
Risk = Likelihood × Impact

Likelihood:
- High (likely to occur)
- Medium (may occur)
- Low (unlikely to occur)

Impact:
- Critical (data breach, financial loss, legal liability)
- High (significant damage, downtime)
- Medium (limited damage, temporary disruption)
- Low (minimal impact)

Risk Level:
- Critical: Immediate action required
- High: Address before launch
- Medium: Address post-launch
- Low: Monitor, may accept risk
```

**Step 5: Define Mitigations**
For each threat, document:

- Mitigation strategy
- Implementation effort (low, medium, high)
- Residual risk after mitigation
- Owner and timeline

---

### Part 2: Security-First Design

#### Security Principles

**1. Defense in Depth**
Multiple layers of security controls. If one fails, others still protect.

**Example:**

- Layer 1: Firewall
- Layer 2: Authentication
- Layer 3: Authorization
- Layer 4: Encryption
- Layer 5: Audit logs

**2. Least Privilege**
Users/systems only have minimum permissions needed.

**Example:**

- Read-only database credentials for reporting service
- User can only see their own data
- Admin access requires MFA + time-limited token

**3. Zero Trust**
Never trust, always verify. Even internal networks are untrusted.

**Example:**

- Every request authenticated and authorized
- No "trusted" internal network
- Encrypt internal traffic
- Assume breach mentality

**4. Secure by Default**
Default configuration is secure. Users must opt-in to less secure options.

**Example:**

- HTTPS enforced by default
- Strict password policy by default
- MFA recommended on signup
- Secure cookies (HttpOnly, Secure, SameSite)

**5. Fail Securely**
When errors occur, fail in a way that doesn't compromise security.

**Example:**

- Access denied on error (not granted)
- Log error but don't expose details to user
- Graceful degradation without exposing internals

---

#### Secure Design Patterns

**Authentication:**

- **Pattern:** OAuth 2.0 + OpenID Connect (OIDC)
- **Implementation:**
  - Use Auth0, AWS Cognito, or Okta (don't build your own)
  - JWT tokens with short expiration (15 min access, 7 day refresh)
  - Secure token storage (HttpOnly cookies or secure local storage)
  - MFA for sensitive operations

**Authorization:**

- **Pattern:** Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC)
- **Implementation:**
  - Define roles: admin, user, viewer
  - Check authorization on every API request
  - Use middleware: `@requireRole('admin')`
  - Implement IDOR protection (verify ownership)

**Data Protection:**

- **Pattern:** Encryption at rest and in transit
- **Implementation:**
  - TLS 1.3 for all external traffic
  - AES-256 for data at rest
  - Key management service (AWS KMS, Google Cloud KMS)
  - Encrypt PII fields (email, SSN, credit cards)

**API Security:**

- **Pattern:** Rate limiting + authentication + input validation
- **Implementation:**
  - Rate limit: 100 requests/minute per user
  - API keys for server-to-server
  - OAuth tokens for user-to-server
  - Validate all inputs (type, length, format)
  - Whitelist allowed values

**Secrets Managem