Currently websites allow the capture, processing, storage and transmission of sensitive customer data (e.g., personal details, Mastercard numbers, Social Security information, etc.) for immediate and recurrent use. To ensure that Web Application Firewall as a service will happen safely, organizations got to employ differing types of controls and tools that allow them to extend their capacity to detect and answer threats to their network. One of the most challenges in implementing these tools surfaces thanks to the need that for them to research and choose whether the traffic must be blocked they have to be placed within the middle of the traffic, adding latency to every request which may become prohibitive for applications that depend upon a coffee latency response. 

Another challenging obstacle when deploying them is caused thanks to the false positive rate, or how common these tools decide a traditional user is malicious and might block their activity, which may make the adoption of those tools much harder than they might expect. 

To take advantage of this model, we'd like to be ready to efficiently decide what traffic to dam. This will minimize the latency incurred on regular users and take away the likelihood of false positives affecting them. To achieve that we'll got to decide what traffic should be placed in an ‘inline’ mode within the following ways: 

Traffic routing is the way by which we will decide that portions of the traffic should add an in-line mode, having every single request analyzed by the WAF and blocked if it's considered an internet application attack. This allows applications that have a coffee tolerance for latency to be ready to have their traffic inspected and only add latency when a threat is detected and malicious requests need to be blocked. This can be achieved within the following ways, either by human or an automatic decision-making process: 

By analyzing the traffic automatically in the log processing component, we can extract fingerprints that are performing web application attacks and only have those go through the WAF service (adding latency to them). These fingerprints would be extracted by combination of parts of the request (IP address, client ID, User Agent or combinations) or by particular fingerprints which may be automatically or manually added. While the Log processing component would be automatically creating these fingerprints and adding them to the State store component, in order that the Agent is aware that the traffic must be router to the WAF service, this will even be triggered by an analyst which decides that a specific fingerprint must be routed through the WAF. 

Another option for routing traffic is predicated on a network block. This means that specific ISPs, hosting providers or other known services that have a better risk of attacks coming from them (such as open proxies or anonymity networks like TOR) are often routed by default to the WAF service. This will only happen by updating the state store with the IP address net blocks for these providers or members of the networks so as that the Agent is aware that it should route such traffic to the WAF. 

For cases where vulnerability is known to exist on particular endpoints, or where these endpoints have a far better degree of risk and need to possess the WAF Security service inspecting every single call (not only a threat is detected), we will enable virtual patching. This denotes that specific endpoints are routed to the WAF service for analysis of requests coming to them, either for the entire endpoint or a mix of parameters that might be vulnerable to attacks.