Overview
Implementation of a Web Application Firewall as a separate project, integrated into the application's internal Nginx using ModSecurity with OWASP Core Rule Set and anomaly scoring, following a defense in depth strategy complementary to AWS WAF.
Context
AWS WAF protected the platform's external entry points, but the security strategy required a second protection layer closer to the application. A separate internal WAF project was needed to add threat detection and blocking at the application layer, with independent tuning capacity and controlled rollout.
Challenge
Implement and operate an internal WAF that complemented AWS WAF without duplicating efforts, maintaining application compatibility, controlling false positives and enabling activation and deactivation without operational impact.
My role
- ModSecurity with OWASP Core Rule Set implementation as a separate project
- Integration with the application's internal Nginx
- OWASP CRS-based rule configuration and tuning
- Anomaly scoring implementation with configurable thresholds
- Parameterization for per-environment activation/deactivation
- False positive analysis and continuous rule calibration
- Logging, troubleshooting and application compatibility
Architecture
The defense in depth architecture was clear: AWS WAF operated at the edge, protecting external entry points; ModSecurity + OWASP CRS operated internally as a separate application protection layer. Each control operated at a distinct point in the architecture, with complementary — not duplicated — roles.
Technical decisions
- Separate internal WAF project — not an AWS WAF extension
- OWASP Core Rule Set as the base for attack pattern detection
- Anomaly scoring instead of single-rule blocking
- Parameterization as engineering decision: rollout, rollback and troubleshooting
- Defense in depth with controls at distinct architecture points
Security & governance
ModSecurity used OWASP Core Rule Set to detect patterns associated with common attack classes: SQL injection, cross-site scripting, protocol violations, malformed requests and suspicious request patterns. Anomaly scoring allowed different rules to contribute to an accumulated score — final behavior was defined based on score and configured thresholds.
Automation
Parameterization allowed enabling or disabling ModSecurity via environment parameter, enabling controlled rollout, testing, progressive activation, troubleshooting and simplified rollback.
Engineering challenges
Implementing an internal WAF wasn't just installing ModSecurity. The work involved Nginx integration, rule configuration, anomaly score threshold tuning, false positive analysis, logging, troubleshooting, application compatibility and continuous rule maintenance.
Results
- Complementary application-layer protection, separate from AWS WAF
- Protection based on recognized OWASP CRS rules
- Tuning capacity through anomaly scoring with thresholds
- Controlled activation via configuration with rollout and rollback capability
- Defense in depth strategy with controls at distinct architecture points