When Security engineers and architects think of application security deployments in distributed environments, one of the challenges they face is balancing the rigidity of security with the flexibility that modern applications require. Often while performing this balancing act, we err toward rigidity. Still, when it comes to designing a security strategy focused on protecting as many application architectures as possible, flexibility is critical. As much as these two traits seem at odds with one another, the number of applications deployed by organizations requires them to coexist.
Unprecedented growth trends are happening in the world of application deployment, including the types of environments. Whether it’s public or private cloud, on-premises, collocated, or at the edge, each application will have a set of standard and individual security needs. All applications require protections for the App and API OWASP Top 10, L3-7 DoS, Fraud and Bot Defense. Additionally, each has specific requirements related to its use case, infrastructure, and language. Your strategy and architecture are going to need to account for this diversity. Doing so should help accomplish or accelerate your security initiatives and may also help you reduce overall total cost due to architectural flexibility.
Layered security, we have been told for years that the most effective security strategy is composed of multiple, loosely coupled or independent layers of security controls. We need to know that if one of our layers fails or is compromised, another layer in the strategy will still provide us with the protection our applications require. A WAF fits snugly into the technical security controls area and has long been known as an essential piece of application security. What if we take this further and apply the layered approach directly to our WAF deployment? Let's look at some of our current WAF deployment strategies and what this layered approach might look like.
Deploying a scalable, easily managed WAF at the edge allows us to block malicious traffic outside our perimeter. This is where F5's Distributed Cloud WAF fits into the picture. It gives a common security posture for all our applications no matter where they reside in our overall architecture, accounting for some of that environmental diversity we mentioned before. It also provides a foundation for a multi-cloud strategy. Additionally, it has the added value of lowering costs by blocking the traffic before it reaches an area where we incur costs for network usage. This all sounds great, but aren't we also supposed to be shifting security left?
Integrating security into every stage of the development pipeline and moving security solutions away from the perimeter by placing tailored granular security as close to the application as possible is a key part of shifting left. Products like NGINX App Protect and BIG-IP Advanced WAF are perfect for this type of deployment. Whether it's hardware in the data center, virtual edition in public or private cloud, or a lightweight platform agnostic solution protecting your essential microservices, these products help to shift that security left. This gives the ability to meet the specific security needs of our essential apps, allowing us to account for some of that language and use case diversity.
Both capabilities are critical to a comprehensive security strategy that meets the needs of the security teams, while providing the flexibility developers require. Luckily, both capabilities are complimentary, not mutually exclusive. We can deploy these without added complexity due to each product having the same core. That core or engine at the heart of all our WAF products is the foundation for this article series. It's what I mean when I say “one WAF engine, total flexibility.”
When we started this project, there was some confusion about what we meant by One WAF Engine. For anyone familiar with the F5 product portfolio, it is plainly apparent we do not have “One WAF”. All these options being available allows us to be more flexible and plays a vital role in this project. So, what is it we mean?
The engine at the foundation of the entire F5 WAF portfolio is based on the best-in-class efficacy and performance of our BIG-IP based Advanced WAF. This gives application security teams the ability to choose the best deployment option that matches the specific needs of their applications without sacrificing policy familiarity and portability. Organizations can employ:
Each of these products support deployment patterns that both stand on their own and complement each other. The architectures shown in this article series will primarily focus on that complimentary aspect of the portfolio, with occasional forays into the singular deployment pattern.
No modern security strategy is complete without incorporating DevSecOps practices. Integrating security into the entire software delivery lifecycle is essential for delivering secure applications with speed and quality. This project aims to account for those practices by utilizing F5’s fully supported APIs and tooling. Each architecture will include a GitHub repo with IAC code, examples of integration into a CI/CD pipeline, and telemetry options.
F5 Hybrid Security Architectures: One WAF Engine, Total Flexibility (Intro)
F5 Hybrid Security Architectures (Part 1 - F5's Distributed Cloud WAF and BIG-IP Advanced WAF)
F5 Hybrid Security Architectures (Part 2 - F5's Distributed Cloud WAF and NGINX App Protect WAF)
F5 Hybrid Security Architectures (Part 3 - F5 XC API Protection and NGINX Ingress Controller)
F5 Hybrid Security Architectures (Part 4 - F5 XC BOT and DDoS Defense and BIG-IP Advanced WAF)
F5 Hybrid Security Architectures (Part 5 - F5 XC, BIG-IP APM, CIS, and NGINX Ingress Controller)
Minimizing Security Complexity: Managing Distributed WAF Policies
For further information or to get started: