@martinffx/atelier 1.1.0 → 1.2.1

package/skills/oracle-security/references/security-patterns.md

@@ -0,0 +1,236 @@
+# Security Design Patterns
+
+Catalog of architectural patterns for building secure systems.
+
+## Input Validation Patterns
+
+### Whitelist Validation
+Define what's allowed, reject everything else. More secure than blacklist (define what's blocked, allow everything else).
+
+- Specify allowed types, formats, lengths, ranges
+- Reject input that doesn't match exactly
+- Don't try to "fix" invalid input — reject it
+
+### Schema Validation
+Define expected structure and enforce it at the boundary.
+
+- Types, required fields, field constraints
+- Nested object validation
+- Array item validation
+
+### Sanitization vs. Validation
+
+| Approach | When to Use | Risk |
+|----------|-------------|------|
+| **Validation** | Reject invalid input entirely | Low — no invalid data enters system |
+| **Sanitization** | Clean input for safe use | Medium — subtle bugs in sanitization logic |
+| **Encoding** | Escape for specific context | Context-dependent — wrong encoding for wrong context |
+
+**Rule**: Validate first. Only sanitize if you understand exactly what the destination context requires.
+
+## Authentication Patterns
+
+### Session-Based Authentication
+- Server-side session storage
+- Session ID in httpOnly, secure, sameSite cookie
+- Server validates session on every request
+
+### Token-Based Authentication
+- Signed token (JWT, Paseto) containing claims
+- Token sent in Authorization header
+- Server validates signature and expiry
+
+### Multi-Factor Authentication
+- Something you know (password)
+- Something you have (device, token)
+- Something you are (biometric)
+
+**Key Decision**: Session vs. Token depends on state requirements, scale, and revocation needs.
+
+## Authorization Patterns
+
+### Role-Based Access Control (RBAC)
+- Users assigned to roles
+- Roles granted permissions
+- Simple to understand and audit
+
+### Attribute-Based Access Control (ABAC)
+- Policies based on user attributes, resource attributes, environment
+- More flexible but more complex
+- Better for fine-grained, dynamic access control
+
+### Resource-Level Authorization
+Every operation checks: "Does this user have permission to perform this action on this specific resource?"
+
+- Don't check once at login and assume it's valid for all subsequent actions
+- Re-verify on every request that touches a resource
+- Consider resource ownership, sharing, delegation
+
+## Output Protection Patterns
+
+### Response Filtering
+Remove sensitive fields from API responses based on caller's authorization level.
+
+- Never return internal IDs, passwords, tokens, or secrets
+- Filter differently for different user types
+- Consider field-level access control
+
+### Error Message Safety
+- Return generic errors to users
+- Log detailed errors internally
+- Never expose: stack traces, database schemas, file paths, internal IPs, system versions
+
+## Audit and Logging Patterns
+
+### Security Event Logging
+Log events that matter for security investigations:
+
+- Authentication attempts (success and failure)
+- Authorization failures
+- Sensitive data access
+- Configuration changes
+- Privilege escalations
+
+### Audit Trail Requirements
+- **Who**: Which user or service performed the action
+- **What**: What action was performed
+- **When**: Timestamp (UTC)
+- **Where**: Source IP, endpoint, service
+- **Result**: Success or failure
+- **Context**: Relevant IDs, parameters (sanitized)
+
+### Log Protection
+- Logs should be tamper-evident (append-only, signed)
+- Separate log access from application access
+- Retain according to compliance requirements
+- Don't log secrets, tokens, or sensitive personal data
+
+## Secrets Management Patterns
+
+### Environment-Based Configuration
+- Secrets in environment variables, never in code
+- Separate config per environment (dev, staging, prod)
+- Use secret management services in production (Vault, AWS Secrets Manager, etc.)
+
+### Secret Rotation
+- Rotate credentials regularly
+- Support emergency rotation
+- Don't hardcode secret references
+
+### Least-Exposure Principle
+- Services should only know the secrets they absolutely need
+- Don't use one API key for everything
+- Separate credentials by function and scope
+
+## Resilience Patterns
+
+### Circuit Breaker
+When a dependency fails repeatedly, stop calling it temporarily to prevent cascading failures.
+
+- Detect failure threshold
+- Open circuit (fail fast) for a period
+- Half-open (test with limited traffic) before fully closing
+
+### Rate Limiting
+Prevent abuse by limiting requests per time window per client.
+
+- Different limits for different endpoints (auth vs. data)
+- Different limits for different user types (anonymous vs. authenticated)
+- Consider burst allowances and graceful degradation
+
+### Timeout and Backoff
+- All external calls should have timeouts
+- Retry with exponential backoff for transient failures
+- Don't retry authentication failures (could be brute force)
+
+## Data Protection Patterns
+
+### Encryption at Rest
+- Sensitive data encrypted in database
+- Key management separate from data access
+- Consider performance impact on queries
+
+### Encryption in Transit
+- TLS for all external communication
+- Consider mTLS for service-to-service
+- Don't disable certificate verification
+
+### Tokenization
+Replace sensitive data with non-sensitive equivalents.
+
+- Actual data stored in secure vault
+- Token used in application logic
+- Reduces exposure surface
+
+## Secure Defaults Patterns
+
+### Deny by Default
+- All access denied unless explicitly granted
+- All features disabled unless explicitly enabled
+- All connections rejected unless explicitly allowed
+
+### Minimal Surface Area
+- Don't expose features you don't need
+- Disable unused endpoints, services, protocols
+- Remove default accounts and sample data
+
+### Secure Configuration
+- Framework defaults should be hardened
+- Don't rely on "out of the box" security
+- Explicitly configure security settings
+
+## Defense in Depth Patterns
+
+### Layered Controls
+Multiple independent controls for the same threat:
+
+```
+Threat: SQL Injection
+├── Layer 1: Input validation (reject non-matching input)
+├── Layer 2: Parameterized queries (prevent interpretation as SQL)
+├── Layer 3: Least privilege database user (limit damage if bypassed)
+└── Layer 4: Monitoring (detect and alert on suspicious patterns)
+```
+
+### Compartmentalization
+- Separate sensitive operations from general operations
+- Isolate user data by tenant or scope
+- Use different credentials for different functions
+
+### Fail-Safe States
+- When validation fails: reject
+- When auth fails: deny
+- When encryption fails: don't send
+- When logging fails: fail closed (don't proceed silently)
+
+## Anti-Patterns to Avoid
+
+### God Object Security
+Putting all security logic in one place (e.g., a single middleware) instead of at each layer.
+
+**Problem**: Bypass the middleware, bypass all security.
+**Fix**: Security at every relevant layer.
+
+### Client-Side Security
+Relying on browser validation, hidden fields, or client logic for security.
+
+**Problem**: Clients are completely under attacker control.
+**Fix**: Server-side validation is the only validation that matters.
+
+### Security Through Obscurity
+Relying on secrecy of design or implementation for security.
+
+**Problem**: Once discovered (and it will be), there's no protection.
+**Fix**: Assume attackers know your design. Security should work even when public.
+
+### Trusting the Network
+Assuming internal network traffic is safe.
+
+**Problem**: Lateral movement after initial compromise is common.
+**Fix**: Authenticate and validate internal traffic too.
+
+### Hardcoded Secrets
+Embedding credentials, keys, or tokens in source code.
+
+**Problem**: Committed to version control, visible to anyone with code access.
+**Fix**: Environment variables, secret managers, runtime injection.

package/skills/oracle-security/references/threat-modeling-guide.md

@@ -0,0 +1,137 @@
+# Threat Modeling Guide
+
+Extended approaches for analyzing security threats during system design.
+
+## Data Flow Analysis
+
+Map how data moves through your system to identify trust boundaries:
+
+```
+External Request → [Trust Boundary] → API Gateway → [Trust Boundary] → Service → [Trust Boundary] → Database
+                        ↑                                              ↑
+                   Authenticate                                    Authorize
+                   Validate input                                 Validate output
+                   Rate limit                                     Audit log
+```
+
+**Process**:
+1. Draw the data flow for a specific use case
+2. Identify every trust boundary crossing
+3. Ask: "What's the worst thing that could enter here?"
+4. Ask: "What validation or enforcement should happen at this boundary?"
+5. Look for paths that bypass expected controls
+
+## STRIDE in Depth
+
+### Spoofing
+- **Threat**: Attacker pretends to be a legitimate user or system
+- **Questions**: How are identities verified? Can tokens be stolen or forged? Can sessions be hijacked?
+- **Controls**: Strong authentication, token binding, session validation, mutual TLS
+
+### Tampering
+- **Threat**: Data is modified in transit or at rest
+- **Questions**: Is integrity checked? Can parameters be altered? Can files be modified?
+- **Controls**: Input validation, checksums, signatures, immutable audit logs
+
+### Repudiation
+- **Threat**: Actions can't be traced back to an actor
+- **Questions**: Are all sensitive operations logged? Are logs tamper-evident? Can users deny their actions?
+- **Controls**: Comprehensive audit logging, signed logs, non-repudiation mechanisms
+
+### Information Disclosure
+- **Threat**: Sensitive data leaks to unauthorized parties
+- **Questions**: What data is exposed in errors? In logs? In API responses? Can users access other users' data?
+- **Controls**: Output filtering, log redaction, access controls, encryption at rest/transit
+
+### Denial of Service
+- **Threat**: System becomes unavailable or unusable
+- **Questions**: Can endpoints be overwhelmed? Are there expensive operations? Can resources be exhausted?
+- **Controls**: Rate limiting, resource quotas, circuit breakers, caching, input size limits
+
+### Elevation of Privilege
+- **Threat**: User gains more access than authorized
+- **Questions**: Is authorization checked on every operation? Can parameters be manipulated to access other resources? Are roles properly enforced?
+- **Controls**: Resource-level authorization, parameter validation, role enforcement, privilege separation
+
+## Attack Trees
+
+### Building an Attack Tree
+
+```
+Goal: Access User Data
+├── Path A: Steal Session Token
+│   ├── Phishing (requires social engineering)
+│   ├── XSS (requires input injection) ← Mitigated by output encoding
+│   └── Network interception (requires unencrypted traffic) ← Mitigated by HTTPS
+├── Path B: Direct Database Access
+│   ├── SQL Injection (requires unparameterized query) ← Mitigated by parameterized queries
+│   └── Direct connection (requires network access) ← Mitigated by network segmentation
+└── Path C: Abuse API
+    ├── IDOR (requires missing authorization) ← Mitigated by resource checks
+    └── Parameter tampering (requires missing validation) ← Mitigated by input validation
+```
+
+**Usage**: Focus on the unmitigated paths. If you find a path with no controls, that's your priority.
+
+### Risk Scoring
+
+For each identified threat, assess:
+
+- **Impact** (1-5): How bad would exploitation be?
+- **Likelihood** (1-5): How easy is it to exploit?
+- **Risk** = Impact × Likelihood
+
+| Score | Action |
+|-------|--------|
+| 20-25 | Must mitigate before release |
+| 12-16 | Should mitigate in next release cycle |
+| 6-10 | Track and mitigate when convenient |
+| 1-5 | Accept risk, document reasoning |
+
+## Trust Boundary Patterns
+
+### External → Internal
+- Every external request is hostile until authenticated and validated
+- Validation must happen before any processing
+- Never use external data to make internal decisions without verification
+
+### Internal → External
+- Assume external systems are compromised or malicious
+- Validate all responses from third parties
+- Don't expose internal state or identifiers
+
+### User → User
+- Users should never directly access each other's data
+- All cross-user access must go through authorization checks
+- Consider temporal access (can user A access user B's data at time T?)
+
+### Process → Process
+- Inter-service communication should be authenticated
+- Don't trust internal network traffic by default
+- Validate messages between components as if they came from outside
+
+## Threat Modeling Checklist
+
+For each feature or component:
+
+- [ ] All entry points identified
+- [ ] All trust boundaries mapped
+- [ ] STRIDE threats considered
+- [ ] Attack paths identified for high-value targets
+- [ ] Existing controls mapped
+- [ ] Gaps identified and prioritized
+- [ ] Risk scores assigned
+- [ ] Mitigations planned and scheduled
+- [ ] Assumptions documented (what are we trusting?)
+
+## Lightweight Threat Modeling
+
+When you don't have time for full analysis:
+
+1. **Write the user story**: "As an attacker, I want to..."
+2. **Identify one critical asset**: What would hurt most to lose?
+3. **Find the shortest path**: What's the easiest way to access it?
+4. **Add one control**: What's the simplest mitigation?
+5. **Repeat**: Do this for 3-5 attack stories
+
+This takes 15 minutes and catches the most obvious issues.