Balancing Security and Performance with Web Application Firewalls

• Security is important, but so is performance.
• More than half (57%) of organizations use web application firewalls to protect apps in the cloud and on-premises (State of Application Delivery 2018)
• Scanning an outbound response is one of the last opportunities to detect a breach in progress – and stop it. 
• You can have “too much of a good thing.” Carefully consider how to balance security with performance to optimize both. 

We (as in everyone) know how important performance is to the continued success of the digital business. While those of us who were weaned on dial-up connections and hours-long downloads are tend to be more forgiving when it comes to performance, our digital native children are not so generous. They expect instantaneous responses and quick downloads.

The proof of our impatience is in the numbers – more than 80% of us have deleted an application because of poor performance. Some of us – three in ten – are even willing to pay for the privilege of our apps being lightning fast.

But we’re hard to please, no matter what technology generation we’re from. Don’t you dare ignore security while you’re making that app go faster. If you do, and our data is breached, we’ll do more than just delete your app.

It is left, then, to IT professionals – particularly those who practice security – to balance the demand for performance with the need for security. Apps must be fast and secure.

One of the ways more than half of organizations achieve safer apps is by using a web application firewall (WAF) – amongst other application services – to protect applications against attack. They do this in two ways:

First, they scan inbound requests to detect any malicious activity. Second, they inspect outbound responses. It is no surprise that organizations that always apply these security tactics are amongst those with the highest confidence in withstanding an application attack.

Using a WAF you can inspect every last bit of a request and a response. You can parse, pull apart, twist, and modify content however you want.

But just because you can, doesn’t mean you should.

Security is not free. It takes CPU cycles and memory to inspect application traffic with the kind of attention required to find attacks or evidence of a breach.

That’s why it’s important to balance security with performance. Every extra microsecond you spend scanning or scrubbing is an extra microsecond users must wait for that response.

And they add up.

After all, it’s a matter of physics that it takes a number of microseconds for packets to pass through a network and back. It takes another few microseconds to establish a connection. Another few to process… you get the picture. Everything you do takes time, and the more time you take, the more impatient your users are growing.

Some have traditionally thrown the baby out with the bathwater when it comes to this conflict. They turn off security until performance is acceptable. But that’s not the right answer. There is a balance that can satisfy both the need for security and the demand for performance.

On the request, feel free to perform protocol-level parsing and verification. Inspect the payload and seek out any signs of an attack. Go with signature based scans first and text-based comparisons second. Signature-based scans when possible improve the performance of security because you don’t have to parse and compare. It’s just a straight comparison, and it’s a pretty fast process. 

On the response, don’t succumb to the temptation to parse and put the content under a microscope. There has to be some level of trust with developers, here, that the JSON is formatted correctly or the XML follows the appropriate schema. Face it, if there’s a protocol or format error here, the user will find out about it. That’s a developer concern, it’s not generally a security risk.

What is a security risk is the inclusion of sensitive data – credit card or account numbers, social security numbers, e-mail addresses, perhaps. Numbers and data with well-defined patterns that can be quickly scanned for and obscured in the data. Like signature-based scans, you’re doing pattern matching here and security services have gotten really good at performing them as fast as they can.

Content length, too, is something you’ll want to check if you can. A number of high-profile exploits were identifiable simply by the amount of content returned. If you know a specific request should only return about 1K of data, then a 4K response should probably set of alarm bells somewhere. It’s a simple check that takes far less time than parsing and counting data records.

A good rule of thumb is to always obey Security Rule Zero on the request and check everything you can when there is user input present. On the outbound, look for indicators of an ongoing breach and obfuscate sensitive data, but don’t spend time worrying about data formats and schema compliance. Let developers worry about whether they formatted the response correctly. That is their purview, not yours.

Security and performance can be balanced, as long as you don’t sacrifice one for the other. And that means in both directions. Don’t give up security for performance, but don’t throw performance under the bus for the sake of (potentially unnecessary) security.

If you use security strategically to prevent exploitation and detect breaches you can achieve the balance with performance you need to keep users happy and data and applications safe.