Pragmatic WAF Management: Securing the WAF
WAFs themselves are an application, and as such they provide additional attack surface for your adversaries. Their goal isn’t necessarily to compromise the WAF itself (though that’s sometimes a bonus) – the short-term need is evasion. If attackers can figure out how to get around your WAF, many of its protections become moot. Your WAF needs to be secured, just like any other device sitting out there and accessible to attackers. So let’s start by discussing device security, including deployment and provisioning entitlements. Then we can get into some evasion tactics you are likely to see, before wrapping up with a discussion of the importance of testing your WAFs on an ongoing basis. Deployment Options Managing your WAF pragmatically starts when you plug in the device, which requires you to first figure out how you are going to deploy it. You can deploy WAFs either inline or out of band. Inline entails installing the WAF in front of a web app to block attacks directly. Alternatively, as with Network Access Control (NAC) devices, some vendors to provide an out-of-band option to assess application traffic via a network tap or spanning port, and then use indirect methods (TCP resets, network device integration, etc.) to shut down attack sessions. Obviously there are both advantages and disadvantages to having a WAF inline, and we certainly don’t judge folks who opt for out-of-band deployment rather than risking impact to applications. But as with NAC evasion, out-of-band enforcement can be evaded and presents an additional risk to the application. But balancing risks, such as reduced application protection against possible application disruption, is why you get the big bucks, right? You will also need to consider high availability (HA) deployment architectures. If a WAF device fails and takes your applications with it, that’s a bad day all around. So make sure you can deploy multiple boxes with consistent policy and utilize some kind of non-disruptive failover option (active/active, active/passive, load balancer front-end, etc.). Of course some folks opt for a managed WAF service, so the device doesn’t even sit in their data center. This offloads responsibility for scaling up the implementation, providing high availability, and managing devices (patching, etc.) to the service provider. Additionally, the service provider can offer some obfuscation of your IP addresses, complicating attacker reconnaissance and making WAF evasion harder. Depending on how the service is packaged, the service provider may also provide resources to manage policies. Of course they cannot offload accountability for protecting applications, and a service provider cannot be expected to interface directly with your developers. You should also understand the background of your WAF provider. Are they a security company? Does the WAF provide full application security features, or is it a glorified content distribution network (CDN)? Obviously a service provider isn’t likely to offer the full granular capabilities and policy options of a device in your data center, so you need to balance the security capabilities of a managed WAF service against what you can do yourself. Other Security Considerations Obviously you need to keep attackers away from the physical devices, so ensuring physical security of devices is the first step, and hopefully already largely covered by existing security measures. After that you need to ensure all credentials stored on the device are protected, including the SSL private keys used for SSL interception. You will also need to exercise good security hygiene on the device, which means detailed logging of any changes to device configuration and/or policies. Hopefully the logs will aggregated on an external aggregation system (a log management server) to prevent tampering, and alerts should be sent if logging is turned off. That also means keeping the underlying operating system (for software-based WAFs) and the WAF itself patched and up to date. No different than what you should do for every other security device in your environment. Again, a managed WAF service gets you out of having to update devices and/or WAF software, but make sure you can get access to the appropriate WAF activity logs. Make sure you have sufficient access for forensic investigation, if and when you need to go there. Finally, keep in mind that Denial of Service (DoS) attacks continue to be problematic, targeting applications with layer 7 attacks, in addition to simpler volume-based attacks. Make sure you have sufficent bandwidth to deal with any kind of DoS attack, a sufficiently hearty WAF implementation to deal with the flood, and a DDoS-focused service provider on call to handle additional traffic if necessary. Protecting against DoS attacks is a discipline unto itself, and we plan a series on that in the near future. Provisioning and Managing Entitlements Once you have secured the device, next make sure the policies and device configurations are protected. Take steps to control provisioning and management of entitlements. Given the sensitivity of the WAF, it makes sense to get back to the 3 A’s. Yeah, man, old school. Authorization: Who is allowed to access the WAF? Can they set up policies? Change configurations? Is this a group or set of individuals? Authentication: Once you know who can legitimately get into the device, how will you ensure it’s really them? Passwords? 2-factor authentication? Digital certificates? Retinal scans? Okay, that last was a joke, but this question isn’t. Audit: You want an audit event every time a WAF policy, configuration, entitlement, or anything else is changed. Note that a managed WAF service will complicate your ability to manage entitlements. The service provider will have the ability to change policies and may even be responsible for managing them. Ensure you adequately vet folks who will have access to your policies, with an audit trail. We know we are beating the audit horse, but it’s particularly important in this context. An alternative method for managing access to WAF devices is Privileged User Management (PUM). In this scenario administrators log into some sort of proxy, which manages credentials and provides access only to the WAFs each administrator has authorization for. That’s just one of