Designing Next-Gen WAF Sites for your Organization

Having the flexibility to deploy Next-Gen WAF in a way that makes sense for you is key to protecting your mission-critical applications. We can easily integrate with Kubernetes, Serverless, Fastly’s Edge, and many more technologies. Since Fastly does not require one specific architecture to protect your applications, you gain the power to decide what type of architecture makes the most sense for your company.

The purpose of this blog is to outline a few of the options available to you when setting up NGWAF Sites within your Corp. Let’s review the three most common design patterns that we see for managing security. 

As a note, Fastly’s Next-Gen WAF is exceptional at keeping your applications secure without requiring much tuning and configuration. Before getting into the deployment examples, one often overlooked mechanic for how our Next-Gen WAF works is that the configuration that is tied to your application by our WAF is not based on the HTTP host header. This means that many different applications may be grouped together into a single Next-Gen WAF Site configuration. With this flexibility, you may manage the security posture of your grouped applications, reduce the configuration management overhead, and ultimately reduce the cost of implementing and maintaining your WAF. You can make your security team's life better by not requiring them to individually manage the settings of dozens (or even hundreds) of WAF instances like they may have to with a legacy WAF.

With that said let's get into the different options that we see in the field.

Pattern 1 - One Site within the Corp

This setup is typically the entry point for any new Fastly customer. A single site enables Next-Gen WAF users to manage all of their settings in a single pane of glass. Rules may be configured for testing by adding conditions such as an office IP address or testing HTTP header to a Next-Gen WAF Request Rule. With a rule configured this way, only the traffic that matches that testing criteria would take the defined action in the Request Rule.

Potential Advantages:

• Easy en-masse configuration for all traffic

• Visibility into all traffic via the site's customizable dashboards

• Dev, Staging, and Production can have the same settings to avoid version drift

• Least amount of staffing required to manage

Potential Disadvantages:

• Limits to the total number of Rate Limiting rules are at the site level

• Granular visibility requires adding signals to requests

Pattern 2 - Distinct Sites per application bundle

We often see customers move towards bundling applications by functionality into segmented Next-Gen WAF Sites. In this pattern, if a configuration is applied to the individual Site, it will impact that one grouping of applications without impacting Sites with other groupings of applications. This is a way to maintain the same configuration for applications in a way that is independent of their stage of development, which can help developers spot issues before they reach production. You can also segment mission-critical applications into their own specific Next-Gen WAF Site while bundling many distinct internal applications that still need general broad spectrum WAF protection into a separate Next-Gen WAF Site. The WAF settings for the mission-critical applications will not be impacted by the internal applications’ WAF settings and vice versa. 

Potential Advantages:

• Enables app-specific configuration, including a larger number of total rate limiting rules

• Minimizes risk of version drift between Dev, Staging, and Production

• Broad Site statistics are available in the Corp overview

• Developers may become active participants in seeing attacks in the Next-Gen WAF UI

• No risk for different application owners to impact each other as roles are assigned for the individual sites

Potential Disadvantages:

• Applications that have a similar function are managed independently (except for Corp rules)

• Visibility into individual applications requires navigating into the individual Sites

Pattern 3 - One Site per application lifecycle stage

With agile engineering, it is expected that there will be something that resembles development, staging, and production environments and deployments are promoted through these stages (assuming no identified issues). The Fastly Next-Gen WAF can accommodate this type of setup as well, with distinct applications having their own Site for each stage of development.

Potential Advantages:

• Enables teams to promote configurations from Development to Staging to Production

• Applications with similar functions may be grouped to minimize re-implementing the same rules across sites

• Developers may become active participants in seeing attacks in the Next-Gen WAF UI

Potential Disadvantages:

• Configuration drift between the distinct Sites is expected and part of this design

• Many distinct applications will result in many distinct Next-Gen WAF sites, making visibility more challenging in the UI

Examples

Single development team (Pattern 1)

For our customers that want protection from attack traffic without investing much time into the security tooling, having a single Site is a great option. You can benefit from having your security settings and visibility contained on the same Site and if any tuning is required, then you only need to make a change in a single Site.

Single Security Team. Devs are not involved with Application Security (Pattern 2)

Typically when a dedicated Security Team is responsible for application security, the Next-Gen WAF Sites can be grouped by function. For example, an e-commerce platform that provides online shops for their customers may want to group all of their customers’ sites together under a single Site. This way, it’s a very easy task if specific configurations need to be applied to a functional grouping of the e-commerce platform’s customers. Other applications for the e-commerce platform could be grouped together in a similar fashion with other Sites. The Security Team in this context may even be a managed security services provider that interfaces more directly with customers.

For internal applications, the social contract between developers and the Security Team is important to define. This is because if Development, Staging, and Production are all in the same Next-Gen WAF Site, then developers need to know how to raise concerns to the Security Team if specific tuning is necessary.

Large Company with many different application teams (Pattern 3)

When there are multiple application teams who operate independently and own the security of their applications, these teams should likely have their own Next-Gen WAF Site for each application. This allows the teams that are the most knowledgeable about the application to own its security configurations. This model scales very well with large organizations or companies with many subsidiaries and many development teams. More agile development teams may utilize option 3, while others may want consistent configurations across their applications like what option 2 provides.

Summary

The three distinct deployment options outlined above are examples of actual deployments that are live in the field today. We also see hybrid approaches that mix the different options to best suits a customer’s needs and the way their organization is structured. When getting started, it’s a good rule to remember it is always easier to start with something simple and make it more complex than to go the other way. 

Fastly customers looking for an even more hands-off approach to managing their security settings from Next-Gen WAF to the Fastly Edge can check out Fastly’s Managed Security Service. 

At Fastly, we are always eager to help our customers overcome their most pressing security challenges. Reach out and let us know what we can do to make your life easier.