To wit, to WAF? Part 3

on

Prologue

Good morning dear reader! In part two, I tempted you with promise of some well-rounded, pragmatic pathways to drive value from your WAF investment, and instead invented a fake organisation with an invented (but not at all uncommon) list of assumptions and problems which they looked to their new WAF to help them solve. I have no regrets however, it's worth knowing what we want to try and solve and the environment in which we want to solve it before we start. 

Anyway, let's go! 

The wisdom of the WAF

Protect WolfCorp's Web Applications from known attack types. Detect and block known web application attacks directed at WolfCorp's web applications:

  1. Block attacks against known vulnerabilities present in the WC's applications prior to their resolution within the application itself, so that application teams are afforded more time to resolve vulnerabilities discovered during pre-release pen testing whilst maintaining the secure public-facing posture of the application.

  2. Block attacks against known vulnerabilities that cannot be resolved, and/or unknown vulnerabilities that may be present in the applications.

  3. Create a blocking strategy that balances usability/UX with security. 

Set the right expectations - Do not treat your WAF as though it were a firewall.

But... That's what the F, stands for? Correct. And I can see why. A WAF for many years was a physical device, often from a security vendor that cost a lot of money. Like a firewall, you slotted it inline in your network, between the Internet and the Application Server, and that is where the similarity ended. 

A network firewall is typically installed in a closed state, then configured to explicitly allow connections inbound from sources you trust to the services which they need access. It forms a perimeter, separating your prized assets from the scary outside world. Changes to rules are well controlled and based on known data; no assumptions. If you attempted to install a WAF using the same logic, your application will be rendered useless, or at best crippled. Think about your web applications, a complex, intertwined ball of user input, AJAX requests, built using the latest and greatest platforms or some woefully out of support legacy CMS (and anything in between); for any appliance or service to attempt to perfectly judge which requests are potentially malicious in origin and which are part of the application's nominal function without some degree of informed human oversight/tuning is likely impossible. Therefore...

Ideally, your WAF will be installed first in "bypass" mode - not blocking any request determined to be malicious, but logging them as "events". As you gain insight into the types of attacks your applications are facing and how they're responding to them, you'll be able to create exceptions for the false positives, ensure you have protection for your applications weak spots and keep those all important genuine users of your applications happy.

With the right visibility, you'll see events (notifications per the WAF that it has determined that a request is malicious) falling into three broad categories:

  1. Events with payloads that make no sense in the context of your application - GET requests to resources that don't exist with strange looking characters, directory paths, nonsensical form inputs where only certain types of data or schema are expected. Typically the application will react with a HTTP 4xx response.
  2. Events where the path of a GET request, the body of the POST request seem to contain legitimate data, or point to a legitimate resource that's a part of the application and the request from the client is expected (looks kinda funky, but your Devs assure you that it's a legit AJAX POST) - but because an event is logged, the WAF has made a determination that they're malicious. The application is probably responding with a 200, or a 3xx response.
  3. Events which feature requests or payloads which are strange looking, seemingly not relevant to the normal operation of the application or user flow ("SELECT * FROM members; DROP members--" in a customer feedback field?) but the application is responding with a 200/3xx code.

You can see all of those types of events? Excellent. Lets look at what they mean in context:

I've typed enough for now. I had intended to wrap everything up in this post, but for my sanity and probably yours too, I'll discuss how we expand on those actions in the table above to deliver and demonstrate value against our use cases in part 4.

Comments

Post a Comment