To get value out of your WAF investment – which means blocking threats, keeping unwanted requests and malware from hitting applications, and virtually patching known vulnerabilities in the application stack – the WAF must be tuned regularly. As we mentioned in our introduction, WAF is not a “set and forget” tool – it’s a security platform which requires adjustment for new and evolving threats.

To flesh out the process presented in the WAF Management Process, let’s dig into policy management – specifically how to tune policies to defend your site. But first it’s worth discussing the different types of polices at your disposal. Policies fall into two categories, blacklists of stuff you don’t want – attacks you know about – and whitelists of activities that are permissible for specific applications. These negative and positive security models complement one another to fully protect applications.

Negative Security

Negative security models should be familiar – at least from Intrusion Prevention Systems. The model works by detecting patterns of known malicious behavior. Things like site scraping, injection attacks, XML attacks, suspected botnets, Tor nodes, and even blog spam, are universal application attacks that affect all sites. Most of these policies come “out of the box” from vendors, who research and develop signatures for their customers. Each signature explicitly describes an attack, and they are typically used to identify attacks such as SQL injection and buffer overflows. The downside of this method is its fragility – any variation of the attack will no longer match the signature, and will thus bypass the WAF. So signatures are only suitable when you can reliably and deterministically describe an attack, and don’t expect the signature to immediately become invalid.

So vendors provide a myriad of other detection options, such as heuristics, reputation scoring, detection of evasion techniques, and several proprietary methods used to qualitatively detect attacks. Each method has its own strengths and weaknesses, and use cases for which it is more or less well suited. They can be combined with each other to provide a risk score for incoming requests, in order to block requests that look too suspicious. But the devil is in the details, there are literally thousands of attack variations, and figuring out how to apply policies to detect and stop attacks is quite difficult.

Finally, fraud detection, business logic attack detection, and data leakage policies need to be adapted to the specific use models of your web applications to be effective. The attacks are designed to find flaws in the way application developers code, targeting gaps in the ways they enforce process and transaction state. Examples include issuing order and cancellation requests in rapid succession to confuse the web server or database into revealing or altering shopping cart information, replaying attacks, and changing the order of events. You generally need to develop your own fraud detection policies. They are constructed with the same analytic techniques, but rather than focusing on the structure and use of HTTP and XML grammars, they examine user behavior as it relates to the type of transaction being performed. These policies require an understanding of how your web application works, as well as appropriate detection techniques.

Positive Security

The other side of this coin is the positive security model: ‘whitelisting’. Yes, this is the metaphor implemented in firewalls. First catalog legitimate application traffic, ensure you do not include any attacks in your ‘clean’ baseline, and set up policies to block anything not on the list of valid behaviors.

The good news is that this approach is very effective at catching malicious requests you have never seen before (0-day attacks) without having to explicitly code signatures for everything. This is also an excellent way to pare down the universe of all threats into a smaller, more manageable subset of specific threats to account for with a blacklist – basically ways authorized actions such as GET and POST can be gamed.

The bad news is that applications are dynamic and change regularly, so unless you update your whitelist with each application update, the WAF will effectively disable new application features. Regardless, you will use both approaches in tandem – without both approaches workload goes up and security suffers.

People Manage Policies

There is another requirement that must be addressed before adjusting polices: assigning someone to manage them. In-house construction of new WAF signatures, especially at small and medium businesses, is not common. Most organizations depend on the WAF vendor to do the research and update policies accordingly. It’s a bit like anti-virus: companies could theoretically write write their own AV signatures, but they don’t. They don’t monitor CERT advisories or other source for issues to protect applications against. They rarely have the in-house expertise to write these policies even if they wanted to. And if you want your WAF to perform better than AV, which generally addresses about 30% of viruses encountered, you need to adjust your policies to your environment.

So you need someone who can understand the rule ‘grammars’ and how web protocols work. That person must also understand what type of information should not leave the company, what constitutes bad behavior, and the risks your web applications pose to the business. Having someone skilled enough to write and manage WAF policies is a prerequisite for success. It could be an employee or a third party, or you might even pay the vendor to assist, but you need a skilled resource to manage WAF policies on an ongoing basis. There is really no shortcut here – either you have someone knowledgable and dedicated to this task, or you depend on the canned policies that come with the WAF, and they just aren’t good enough. So the critical success factor in managing policies is to find at least one person who can manage the WAF, get them training if need be, and give them enough time to keep the policies up to date.

What does this person need to do? Let’s break it down:

Baseline Application Traffic

The first step is to learn how the applications are deployed and what they are doing. Sure, some of you just install the WAF, update the attack signatures, and let it rip. Very little effort but very little security. And we hear plenty of stories about frustrated users who botched their first deployment, but that’s water under the bridge. Taking a fresh look involves letting the WAF observe your application traffic for a while. All WAF platforms can be deployed in monitor only mode to collect traffic and alert on policy violations, but some vendors also provide a specific ‘learning’ mode to assist in classifying application usage, users, structure and services. These baselines are your roadmap to what the application actually does; they provide information you need to know what you need to secure, and provide clues to the best way to write security polices. This initial discovery process is very important for ensuring your initial ruleset actually covers what’s really out there, not just what you think is out there. It’s the basis for creating an application whitelist of acceptable actions (the positive security model) for each application. There is really no other effective way to understand what ‘normal’ application behavior is for all the applications on your network, and to get a handle on the different applications and services you need to protect.

Understand the Applications

Now that you have cataloged the application traffic you want to understand the transactions being processed and get an idea of the risks and threats you face in the context of that business application. Map the baselines into a set of rules, which requires understanding application activities and transactions in order to select the appropriate type of rule. Half the battle is understanding the application, and the other half is understanding how attackers will attempt to undermine its functions. Understanding transactions is not something you will have coming into this process unless you already possess deep knowledge of the application, so you will need to work closely with DevOps to understand how each application works and how events are processed. Part of your job will be to work with the people who possess the information you need to understand each application to document key functions subject to attack.

Once you understand the application functions, and have a pretty good idea of what attacks to expect, you need to determine how you will counter the threats. For example, if your application has a known defect that cannot be addressed in a timely fashion through code changes, you have several options:

• You can remove the offending function from the whitelist of allowed activity, thereby removing the threat. The downside is this also removes an app function or service, and may break the application.
• You can write a specific signature that defines the attack so you can detect attempts to exploit the vulnerability. This approach will stop known attacks but requires you to account for all possible variations and evasion techniques, and assumes that legitimate use will not break the application.
• You can use one or more heuristics to look for clues that indicate abnormal application use or an attack. Heuristics include malformed requests, odd customer geolocation, customer IP reputation, use of known weak/insecure application areas, requests for sensitive data, and any of a number of other attack indicators.

Many customers remain apprehensive with this part of the process. They have a handle on the application functionality, so they can create the whitelists for their applications. But they lack knowledge of how attackers work, so they are not clear on what threats to look for or how to write specific policies. Fear not – there are several ways to fill this knowledge gap.

The first thing to understand is that the vendor will be most helpful in understanding hackers, and many common blacklist policies will come from the vendor. Review the standard policies that come with the WAF. This will give you a very good idea of the types of attacks in current use – spoofing, repudiation, tampering, etc. Embedded policies reflect the long organizational memories of WAF vendors for web app attacks, and how they choose to block them. They should help you understand how attackers work and provide clues on how to approach writing your own policies. Second, there are publicly available lists of attacks – from OWASP, CERT and other organizations – which you can familiarize yourself with. Some even include example attacks, WAF evasion examples, and rules for detecting them. Third, you can hire penetration testers to probe your applications and identify weaknesses. This type of examination is excellent because it approaches exploitation and WAF evasion the way an attacker would. Finally, if you still have concerns, you can always buy professional services to get over the hump.

Another daunting part of this exercise is the scope of the problem. It’s one thing if you’re only talking about a handful of applications – but it’s entirely different when you consider 200 applications, or 1,000. The rules you implement for each application differ so this process is iterative. When facing an overwhelming number of applications, it’s best to take a divide-and-conquer approach: implement basic security across all applications and select a handful of applications to get advanced rules. Iterative your way through the rest of the applications and services, starting with the apps that pose the greatest risk to your organization. This requires working closely with development teams, which we will discuss in the next post, to help cut this problem down to size.

To reiterate, if your WAF has a learning mode, use it. Baselining each application and building a profile of what it does will help you plow through the policies much faster. You will still need to apply a large dose of common sense to see which rules don’t make sense and what’s missing. You can do this by building threat models for dangerous edge cases and other situations to ensure nothing is missed. But learning tools do speed up the process.

Protect against Attacks

Now that you have selected how you want to block threats to your application, it’s time to implement the rules and apply them to the WAF or WAFs. This is where you write rules and develop test cases to verify the rules you have deployed are effective. You will want to deploy both negative and positive rule sets, one at a time, then validate the rules have propagated to each WAF and are in place to protect the applications you’ve cataloged. Don’t assume the rules are active or that they work – verify with the test cases you developed. Testing is your friend. Our introductory post mentioned a story about the company that taught their WAF to accept all attacks as legitimate traffic – running a pen test while the WAF was in learning mode. The key failure was not that they messed up the WAF rules – it was not testing the resulting ruleset or discovering the problem until a third-party pen tester probed their system months later. The moral is to verify that your rules are in place and effective.

Keep in mind that this is an ongoing process – especially in light of the dynamic attack space impacting your blacklist and application changes impacting your whitelist. Your WAF Management process need to continually learn and catalog user and application behaviors, and collect metrics as part of the process. Which metrics are meaningful, and what activities you need to monitor most closely, differ between customers and vendors/solutions. The only consistency is that you cannot measure your success without metrics to measure progress and performance.

A final note: writing negative security policies requires a balancing act. You need to ensure that the pattern reflects a specific threat, but its definition must not be so specific that it misses trivial variants. A signature is useless if it is immediately rendered useless by evolution of the targeted attack. You need to detect threats without generating too many false positives or negatives. Of course that is easier said than done, so you will continually revisit policies to provide effective protection for your applications.

Next we will tackle one of the trickier issues around effective WAF management: working with application development teams to stay current on what’s happening with applications.