As the security administrator of your company's internet-facing applications, a typical day could involve managing a constant cycle of CVEs, alerts, updates and patches. Add continuous changes in your application stack, including new applications, features and API endpoints, and to say your to-do list can feel overwhelming, is an understatement. Adding additional work to your day is far from ideal. WAFs can help. Most WAFs enable you to deploy rules that act as virtual patches to protect against vulnerabilities when a patch isn’t ready to deploy or one does not exist. These patches could result in separate rules for each request element, such as the header, query, and cookie. But what started as a tool to protect against zero-day vulnerabilities can cause complexity and additional management burden. In addition to tracking all your applications, you now have to manage the different elements in the WAF.
We’re pleased to introduce two new features to our WAF solution: Security Application Manager (SAM) and Security Rules Manager (SRM). Security Application Manager is a policy umbrella that makes managing this complex stream of security updates across your application stack easier. This feature is most valuable when you have multiple applications running across different software stacks and platforms, each with different updates, patches, vulnerabilities, and development teams.
SAM enables you to replicate the behavior in one rule. It saves time, is more efficient, and is faster. Now, you don't have to manage as many rules.
SAM, working with SRM, secures your applications against malicious and unwanted traffic.
In the previous version, protecting sites required changes in different sections of the Media Control Center. To configure WAF rules, we had to add rules for a WAF instance in the Rules Engine, configure a profile and actions in the WAF Instance Manager, and define policies in the WAF Profile Manager. To configure rate limiting, we had to configure rules for the hostname and path matching, conditions, thresholds, and enforcement in a different section.
Figure 1: In the previous version, you needed to configure instances within the Media Control Center Rule Builder and the Media Control Center Security, noted below.
Figure 2: Media Control Center Security.
In the new version, we simplified this approach by putting all settings in the Security section of the Media Control Center – where you’ll find the SRM and SAM.
Figure 3: Security Rule Manager.
The SRM platform includes all the protection rules: Access Rules, Managed Rules, Rate Rules, and Custom Rules.
The SAM defines all your specific applications and how they should be protected. It defines the applications to be protected, the SRM rules it will use and the type of action that should occur when the rule triggers.
There are many advantages to this modularized security solution:
You can deploy changes faster.
The administration is more modular and intuitive. We can specify which rules apply to a particular hostname and URL path.
You can save time by configuring rules once and using them across multiple applications.
The protection is more flexible and allows you to create and deploy custom rules.
You can still use all the benefits from the previous version, like Dual WAF Mode.
Lastly, the WAF platform is now a standalone solution, operating independently of any other CDN configurations.
Let's see the new WAF in action.
In this example, we’ll secure three applications for a hypothetical company: a blog, a forum, and an API. We will use the following domains:
We will create one Access Rule, one Managed Rule, and one Rate Rule and share it across all applications. We will create a second Rate Rule used by the API application only.
The first step is to create a new Access Rule.
We've named this Access Rule "All Properties ACL." And we've unchecked HEAD under Allowed HTTP Methods to block any requests using HEAD.
Figure 4: Create a new Access Rule.
Next, we create a new Rate Rule.
We've named this Rate Rule "All Properties RL" and applied it to the "IP address and user agent" property with a rate limit of 50 requests per minute.
Figure 5: Create a new Rate Rule.
We then create another Rate Rule to be used only for the API application.
We've named this Rate Rule "API RL" and applied it to the "IP address and user agent" property with a rate limit of 10 requests per minute.
Figure 6: Create a new Rate Rule.
Finally, we create a new Managed Rule.
We've named this rule "All Properties Managed" and accepted all the defaults on the Settings tab. Under the Policies tab, we've chosen to automatically opt-in to the latest Edgio ruleset so it will automatically use the most current version.
Figure 7: Create a new Managed Rule.
Now that we’ve created the rules in the SRM, we will create three new applications in SAM. One application each for the blog, forum, and API applications.
For each new application, we're entering the specific hostname (such as blog.example.com) and leaving URL Path(s) to Default, so it matches on all paths.
Under the Rules section for each SAM, we will re-use the All Properties ACL access rule, the All Properties Managed managed rule and the All Properties RL rate rule we created in the SRM. We choose Block Request as the action to take when the rule triggers.
Figure 8: Apply All Properties ACL Access Rule.
We will apply the API RL Rate Rule for the API application only. We do this by editing the API application to include this additional rule. Ordering matters here, so we drag and drop the API RL Rule to the top.
Figure 9: Apply API Rate Limiting Rule.
Lastly, we have the final view of our SAM configuration, showing Access Rules, Rate Rules, and Managed Rules for each application.
Figure 10: Security Application Manager configuration summary.
You now know how to create rules in the Security Rules Manager and apply them to the Security Application Manager applications. We encourage you to explore the many options and features available to secure your applications with SAM.
Let's connect today for even more detail about our security solutions, including our WAF.