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 Management:

• •Pattern: Never commit secrets, use secret managers
• •Implementation:
  • •AWS Secrets Manager or HashiCorp Vault
  • •Environment variables for config (never in code)
  • •Rotate secrets regularly (90 days)
  • •Use IAM roles (not long-lived credentials)

Part 3: Secure Coding Review (OWASP Top 10)

OWASP Top 10 (2021)

A01: Broken Access Control

• •Risk: Users access data/functions they shouldn't
• •Examples:
  • •URL tampering: /user/123 → /user/456
  • •Missing authorization checks
  • •Insecure Direct Object References (IDOR)

How to Detect:

// BAD: No authorization check
app.get('/api/users/:id', (req, res) => {
  const user = db.users.findById(req.params.id)
  res.json(user) // Anyone can see any user!
})

// GOOD: Check ownership
app.get('/api/users/:id', authMiddleware, (req, res) => {
  const requestedId = req.params.id
  const currentUserId = req.user.id

  if (requestedId !== currentUserId && !req.user.isAdmin) {
    return res.status(403).json({ error: 'Forbidden' })
  }

  const user = db.users.findById(requestedId)
  res.json(user)
})

A02: Cryptographic Failures

• •Risk: Sensitive data exposed due to weak or missing encryption
• •Examples:
  • •Plaintext passwords in database
  • •HTTP instead of HTTPS
  • •Weak hashing (MD5, SHA1)

How to Detect:

// BAD: Plaintext password
const user = { email, password: req.body.password }
db.users.create(user)

// GOOD: Hash with bcrypt
const bcrypt = require('bcrypt')
const hashedPassword = await bcrypt.hash(req.body.password, 10)
const user = { email, password: hashedPassword }
db.users.create(user)

A03: Injection

• •Risk: Attacker injects malicious code (SQL, XSS, command)
• •Examples:
  • •SQL injection
  • •Cross-site scripting (XSS)
  • •Command injection

How to Detect:

// BAD: SQL Injection
const query = `SELECT * FROM users WHERE email = '${req.body.email}'`
db.query(query) // Attacker can send: ' OR '1'='1

// GOOD: Parameterized query
const query = 'SELECT * FROM users WHERE email = ?'
db.query(query, [req.body.email])

// BAD: XSS
;<div dangerouslySetInnerHTML={{ __html: userInput }} />

// GOOD: Escape user input
import DOMPurify from 'dompurify'
const sanitized = DOMPurify.sanitize(userInput)
;<div dangerouslySetInnerHTML={{ __html: sanitized }} />

A04: Insecure Design

• •Risk: Flawed architecture or missing security controls
• •Examples:
  • •No rate limiting
  • •Lack of threat modeling
  • •No security requirements

How to Detect:

• •Review architecture diagram
• •Check for rate limiting, authentication, authorization
• •Validate threat model exists

A05: Security Misconfiguration

• •Risk: Default configs, verbose errors, unnecessary features enabled
• •Examples:
  • •Default admin password
  • •Directory listing enabled
  • •Stack traces in production

How to Detect:

// BAD: Exposes stack trace
app.use((err, req, res, next) => {
  res.status(500).json({ error: err.stack })
})

// GOOD: Generic error message
app.use((err, req, res, next) => {
  logger.error(err)
  res.status(500).json({ error: 'Internal server error' })
})

A06-A10: Other Critical Issues

• •A06: Vulnerable and Outdated Components (use npm audit, Dependabot)
• •A07: Identification and Authentication Failures (weak passwords, no MFA)
• •A08: Software and Data Integrity Failures (supply chain attacks)
• •A09: Security Logging and Monitoring Failures (no audit logs)
• •A10: Server-Side Request Forgery (SSRF) (validate URLs)

Part 4: Compliance Validation

Regulatory Frameworks

GDPR (General Data Protection Regulation)

• •Scope: EU data subjects
• •Key Requirements:
  • •Lawful basis for processing (consent, contract, legitimate interest)
  • •Data subject rights (access, rectification, erasure, portability)
  • •Privacy by design and default
  • •Data breach notification (72 hours)
  • •Data Protection Impact Assessment (DPIA) for high-risk processing

Implementation Checklist:

• • Consent mechanism for data collection
• • Data subject access request (DSAR) process
• • Right to erasure ("right to be forgotten") implementation
• • Data portability export (JSON/CSV)
• • Privacy policy and cookie banner
• • Data Processing Agreement (DPA) with vendors
• • Breach notification process

HIPAA (Health Insurance Portability and Accountability Act)

• •Scope: Healthcare data in the US
• •Key Requirements:
  • •Protected Health Information (PHI) must be encrypted
  • •Access controls and audit logs
  • •Business Associate Agreements (BAA)
  • •Breach notification

Implementation Checklist:

• • Encrypt PHI at rest (AES-256) and in transit (TLS 1.3)
• • Role-based access control to PHI
• • Audit logs for all PHI access
• • BAA with cloud providers (AWS, Azure)
• • Breach notification process
• • Regular security risk assessments

SOC 2 (Service Organization Control 2)

• •Scope: SaaS companies handling customer data
• •Key Requirements:
  • •Trust Service Criteria (Security, Availability, Confidentiality)
  • •Access controls and monitoring
  • •Change management
  • •Incident response

Implementation Checklist:

• • Security policies documented
• • Background checks for employees
• • Multi-factor authentication (MFA) enforced
• • Encryption at rest and in transit
• • Audit logging and monitoring
• • Incident response plan
• • Vendor management program
• • Regular security training

PCI-DSS (Payment Card Industry Data Security Standard)

• •Scope: Organizations handling credit card data
• •Key Requirements:
  • •Never store CVV/CVC codes
  • •Encrypt cardholder data
  • •Regularly update and patch systems
  • •Restrict access to cardholder data

Implementation Checklist:

• • Use payment processor (Stripe, Braintree) - DON'T store cards yourself
• • If storing cards, use tokenization
• • PCI-compliant hosting (Level 1 certified)
• • Network segmentation (isolate cardholder data)
• • Vulnerability scanning and penetration testing
• • Strong access controls

Examples

Example 1: Threat Model for SaaS Application

Application: Project Management SaaS

Assets:

• •User credentials (email, password)
• •Project data (documents, tasks, comments)
• •Payment information (via Stripe)
• •API keys for integrations

Trust Boundaries:

1. •User Browser ↔ Web App (HTTPS)
2. •Web App ↔ API Server (internal TLS)
3. •API Server ↔ Database (encrypted connection)
4. •API Server ↔ Stripe API (HTTPS)

STRIDE Analysis for Boundary 1 (User ↔ Web App):

Priority Mitigations:

1. •Implement MFA (High risk, high impact)
2. •Add rate limiting (Medium risk, easy fix)
3. •Enable CSP headers (High risk, easy fix)

Example 2: Secure Code Review Findings

Code Review: User authentication endpoint

Findings:

CRITICAL: SQL Injection (A03)

// Current code (VULNERABLE):
const query = `SELECT * FROM users WHERE email = '${email}' AND password = '${password}'`

// Recommended fix:
const query = 'SELECT * FROM users WHERE email = ? AND password_hash = ?'
const hashedPassword = bcrypt.hashSync(password, user.salt)
db.query(query, [email, hashedPassword])

HIGH: Plaintext Passwords (A02)

// Current code (VULNERABLE):
db.users.create({ email, password })

// Recommended fix:
const hashedPassword = await bcrypt.hash(password, 10)
db.users.create({ email, password: hashedPassword })

MEDIUM: No Rate Limiting (A04)

// Recommended fix:
const rateLimit = require('express-rate-limit')
const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 5 // 5 attempts
})
app.post('/login', loginLimiter, loginHandler)

Action: Fix CRITICAL and HIGH before deployment. Add MEDIUM post-launch.

Example 3: GDPR Compliance Implementation

Requirement: Implement data subject rights

Implementation:

1. Right to Access (DSAR)

app.get('/api/user/data-export', authMiddleware, async (req, res) => {
  const userId = req.user.id

  const userData = {
    profile: await db.users.findById(userId),
    projects: await db.projects.findByUser(userId),
    comments: await db.comments.findByUser(userId),
    activity: await db.activityLog.findByUser(userId)
  }

  res.setHeader('Content-Type', 'application/json')
  res.setHeader('Content-Disposition', 'attachment; filename=my-data.json')
  res.json(userData)
})

2. Right to Erasure

app.delete('/api/user/account', authMiddleware, async (req, res) => {
  const userId = req.user.id

  // Anonymize instead of delete (retain for legal compliance)
  await db.users.update(userId, {
    email: `deleted-${userId}@example.com`,
    name: 'Deleted User',
    deleted_at: new Date()
  })

  // Delete PII
  await db.sessions.deleteByUser(userId)
  await db.notifications.deleteByUser(userId)

  res.json({ message: 'Account deleted successfully' })
})

3. Consent Management

const user = {
  email,
  marketing_consent: req.body.marketingConsent || false,
  analytics_consent: req.body.analyticsConsent || false,
  consent_date: new Date()
}

Best Practices

Threat Modeling

1. •Model early - Design phase, not after development
2. •Update regularly - When architecture changes
3. •Focus on high-risk threats - Don't aim for 100% coverage
4. •Document mitigations - Not just threats

Security Design

1. •Use proven solutions - Don't roll your own crypto
2. •Defense in depth - Multiple layers of security
3. •Secure by default - Opt-in to less secure, not opt-out
4. •Assume breach - Design with "when" not "if" mindset

Secure Coding

1. •Automate security scanning - SAST, DAST, SCA in CI/CD
2. •Validate all inputs - Trust nothing from users
3. •Use security libraries - OWASP, helmet.js, DOMPurify
4. •Keep dependencies updated - Monitor with Dependabot

Compliance

1. •Understand scope - Which regulations apply to you
2. •Document everything - Policies, procedures, decisions
3. •Regular audits - Internal + external reviews
4. •Work with legal - Don't interpret regulations alone

Common Pitfalls

1. Security as an Afterthought

Antipattern: Build first, secure later Result: Expensive retrofitting, vulnerabilities in production

Better: Integrate security from design phase

2. Trusting Client-Side Validation

Antipattern: Only validate on frontend Result: Attacker bypasses with curl

Better: Always validate on backend

3. Rolling Your Own Crypto

Antipattern: Custom encryption or hashing Result: Weak crypto, vulnerabilities

Better: Use proven libraries (bcrypt, libsodium)

4. Over-Reliance on Compliance

Antipattern: "We're compliant, so we're secure" Result: Compliant but insecure

Better: Compliance is minimum; security is ongoing

5. Ignoring Low-Risk Threats

Antipattern: Only fix CRITICAL issues Result: Death by a thousand cuts

Better: Systematically address all severity levels

Related Skills

• •quality-assurance - Security testing and validation gates
• •api-designer - API security patterns
• •deployment-advisor - Infrastructure security
• •framework-orchestrator - Security in phase gates
• •data-engineer - Data security and privacy

Deliverables

When using Security Architect, produce:

1. •

   Threat Model

   • •Asset inventory
   • •Trust boundaries
   • •STRIDE analysis
   • •Risk assessment
   • •Mitigation plan
2. •

   Security Architecture Document

   • •Authentication/authorization design
   • •Encryption strategy
   • •Secrets management
   • •Network diagram with security controls
3. •

   Secure Code Review Report

   • •OWASP Top 10 findings
   • •Severity ratings
   • •Remediation recommendations
   • •Re-test results
4. •

   Compliance Checklist

   • •Applicable regulations
   • •Implementation status
   • •Gap analysis
   • •Remediation plan

Success Metrics

Security Architect is effective when:

• •Threat models completed before development
• •Zero CRITICAL vulnerabilities in production
• •Security incidents <1 per year
• •Compliance audits passed
• •Security gates enforced in CI/CD
• •Team follows secure coding practices
• •Regular security training completed

Remember: Security is not a feature, it's a foundation. Build it in from the start.