There are two fundamental strategies that security teams use to defend web applications, and they can be simply categorized as a positive or negative security model. These could also be thought of as a proactive or reactive approach to protecting your applications, respectively.
Positive Security Model
A positive security model approach is one in which all inbound traffic is baselined and well understood for the application. Strict input sanitization requirements should be implemented.
For example, only x number of requests per a specific time period or only requests from countries 1, 2, and 3 would be permitted. All other traffic patterns that do not match the baseline are rejected or denied.
This approach is similar to using a deny-all rule, but then adding specific allow statements in a packet-filtering firewall.
Note that this approach is significantly time-consuming for the product and information security team(s) but produces a tighter security posture for your application.
Negative Security Model
In stark contrast to the positive security model, the negative security model approach would initially leverage a more permissive security control set. Security teams would initially configure a set of protections they believe to be appropriate, based upon their knowledge of the application and the history of attempted attacks against it. As problems and issues are noted, the information security and/or product teams would then use the web application firewall to adequately remediate the nefarious traffic.
This approach is similar to using an allow-all approach but then blocking certain events that are causing issues to production. The negative security model is a practical starting point to securing applications for those teams that do not yet fully understand the web application and its vulnerabilities.
Below are some pros and cons of each approach:
Pros and Cons of a Security Model for Web Applications
Positive Security Model
| Pro | Con |
|---|---|
| The restrictive rule sets will filter out a high percentage of the nefarious traffic. | It requires significant upfront investment to understand traffic patterns to the application in order to identify valid traffic. |
| It’s lLikely to block malicious traffic. | It should be integrated into the DevOps and change control pipelines, so that new production releases are properly ‘coupled’ with the web application firewall (WAF) rule sets. |
| The web application and its vulnerabilities are well understood, thus the protections put in place are likely to facilitate only valid requests to the application. | Unless detailed tuning is done up front, there are likely to be significant rates of blocked legitimate requests. The rule sets will likely require ongoing tuning and adjustments as changes to the infrastructure and code base are made. |
Negative Security Model
| Pro | Con |
|---|---|
| It’s simpler to implement than a positive security model. | Attacks may occur for some time while the information security and/or SOC team(s) collaborate to work to find an adequate remediation rule set and or strategy. |
| Preconfigured default protections and vulnerability signatures can be easily applied to your application from the UltraWAF portal. | It has less complete coverage than a a positive security model. |
| Onboarding process is painless and simple. | The application could be vulnerable to zero-day attacks. |
How to Decide
While trying to determine which model fits an organization the best, consider the depth at which the application is understood and the rate at which code pushes are being made to production.
If code pushes are occurring often, then it may be best to use a reactive approach. If the code pushes are not occurring too often and have long periods before another release comes, it may be good to do a proactive information security approach on the WAF.
While implementing a positive security model is difficult, UltraWAF provides some tools that can ease policy creation.
The first is learning mode. When learning mode is enabled for a protection, UltraWAF analyzes traffic patterns and provides suggestions for rules that can either allow or deny specific traffic. To make learning mode even easier to use, the second tool available to ease policy creation is trusted sources. As the name implies, trusted sources are clients that you know source legitimate traffic. As traffic from trusted sources is known to be valid, you can enable the rules that were created by learning mode without detailed analysis. While learning mode and trusted sources will go a long way toward creating policies that will enable an effective positive security model, full analysis of all learned rules should be completed.
If you need assistance determining which model your organization should use, or if you need a combination of both, our professional services team can assist you with developing your WAF policies.
