This document applies the STRIDE threat modeling framework to analyze security threats against the WAF system itself.
STRIDE stands for:
- Spoofing
- Tampering
- Repudiation
- Information Disclosure
- Denial of Service
- Elevation of Privilege
- Threat: Attacker modifies configuration files to disable security rules
- Mitigation:
- Configuration files should have restricted file permissions
- Configuration validation on startup
- Consider configuration signing/verification
- Threat: Attacker modifies
waf.yamlorruleset.yamlto weaken security - Mitigation:
- File integrity monitoring
- Read-only configuration files in production
- Configuration version control
- Threat: Configuration files reveal internal structure or thresholds
- Mitigation:
- Separate configuration for different environments
- Sensitive values in environment variables or secrets management
- Threat: Attacker crafts requests that bypass rule matching
- Mitigation:
- Comprehensive normalization (URL decoding, path cleaning)
- Multiple rule layers (defense in depth)
- Regular rule updates
- Threat: Attacker modifies ruleset to allow malicious traffic
- Mitigation:
- Ruleset file integrity checks
- Ruleset versioning and audit logs
- Immutable ruleset in production
- Threat: Complex regex patterns cause CPU exhaustion
- Mitigation:
- Regex compilation validation
- Request timeout limits
- Rule evaluation timeout (future enhancement)
- Performance testing of rules
- Threat: Request normalization fails, allowing evasion
- Mitigation:
- Multiple normalization passes
- Comprehensive URL decoding
- Header normalization
- Path traversal detection
- Threat: Attacker manipulates anomaly score calculation
- Mitigation:
- Immutable score calculation logic
- Score validation
- Audit logging of score calculations
- Threat: Logs reveal sensitive information (passwords, tokens)
- Mitigation:
- Optional request body logging (disabled by default)
- Log sanitization (future enhancement)
- Secure log storage
- Threat: Attacker spoofs upstream server responses
- Mitigation:
- TLS verification for upstream connections
- Upstream server authentication
- Response validation
- Threat: Attacker modifies requests in transit to upstream
- Mitigation:
- TLS encryption to upstream
- Request integrity checks
- Upstream connection security
- Threat: Upstream server overload causes WAF to fail
- Mitigation:
- Connection pooling and limits
- Request timeout configuration
- Circuit breaker pattern (future enhancement)
- Upstream health checks
- Threat: Attacker denies making malicious requests
- Mitigation:
- Comprehensive request logging
- Timestamp and source IP logging
- Request ID tracking
- Immutable log storage
- Threat: Logs contain sensitive data (PII, credentials)
- Mitigation:
- Configurable body logging (disabled by default)
- Log sanitization filters (future enhancement)
- Secure log storage and access controls
- Log retention policies
- Threat: Attacker modifies logs to hide attack traces
- Mitigation:
- Append-only log files
- Log integrity monitoring
- Centralized logging (future enhancement)
- Log signing/checksums
- Threat: Resource exhaustion attacks (connection flooding, slowloris)
- Mitigation:
- Configurable timeouts (read, write, idle)
- Connection limits (future enhancement)
- Rate limiting (future enhancement)
- Resource monitoring
- Threat: IP spoofing to bypass IP-based rules
- Mitigation:
- X-Forwarded-For header validation
- Source IP verification
- Multiple header checks
- Threat: Error messages reveal internal structure
- Mitigation:
- Generic error responses
- No stack traces in production
- Error message sanitization
- Description: Attacker crafts requests that bypass rule matching
- Examples:
- Encoding variations (URL encoding, double encoding)
- Case variations
- Whitespace manipulation
- Mitigation: Comprehensive normalization, multiple rule patterns
- Description: Attacker sends requests that cause high CPU/memory usage
- Examples:
- ReDoS (Regular Expression Denial of Service)
- Large request bodies
- Many query parameters
- Mitigation: Timeouts, request size limits, optimized regex
- Description: Attacker modifies configuration to weaken security
- Examples:
- Lowering anomaly threshold
- Disabling critical rules
- Changing upstream to attacker-controlled server
- Mitigation: Configuration file protection, validation, monitoring
- Description: Attacker injects malicious content into logs
- Examples:
- Newline injection in user input
- Log parsing attacks
- Mitigation: Structured JSON logging, input sanitization
- Description: Attacker targets upstream server through WAF
- Examples:
- Request smuggling
- Header injection
- Protocol downgrade
- Mitigation: Request validation, secure proxy configuration
-
Configuration Security:
- Use file permissions (600) for configuration files
- Implement configuration signing/verification
- Use secrets management for sensitive values
-
Rule Management:
- Version control for rulesets
- Automated rule testing
- Regular rule updates from security sources
-
Logging Security:
- Encrypt log files at rest
- Implement log rotation
- Use centralized logging with access controls
- Sanitize sensitive data before logging
-
Network Security:
- Use TLS for all connections
- Implement network segmentation
- Use firewall rules to restrict access
-
Monitoring:
- Monitor anomaly scores and blocked requests
- Alert on configuration changes
- Track performance metrics
- Monitor upstream health
-
Testing:
- Regular penetration testing
- Fuzz testing of rule engine
- Performance testing under load
- Integration testing with various attack patterns
- Rate limiting per IP
- IP whitelisting/blacklisting
- Request body size limits
- Advanced evasion detection
- Machine learning-based anomaly detection
- Distributed rule evaluation
- Real-time rule updates
- Metrics and telemetry collection