Top 4 WAF Protections

The traditional network security approach to securing your web servers and database servers is more than likely going to get you in trouble some day. Think about it. Network Security preaches deny everything and permit only what you need. Great, open up port 443 and send encrypted traffic to your web server. KaBOOM gotcha!

Think about your Web Application Firewall and the reasons for your investment in web application security.

Regardless of the technology you have selected, here are four protections your WAF investment needs to be providing:

#1 Enforce decryptable web communications.
This might seem counter-intuitive but first and foremost, if your WAF can’t see it – then the WAF can’t intelligently PROTECT your assets! You need to disable any encryption not supportedby your WAF. It’s a long-standing double-edge sword securing web communications but still being able to inspect the communications. No more pre-shared or temporary key SSL sessions, sorry Diffe-Hellman, most WAF’s only support pure RSA. In addition, this is a good time to make sure your servers negotiate at a respectable bit length.

#2 Enable Correlation.
Attack signatures are great, but correlation is better. If your WAF doesn’t offer some form of correlation of multiple signatures and security events before triggering an alert, you might consider picking one up that does. Web Intelligence is a good product, but it’s not an F5, Breach, or Imperva WAF, and that difference could cost you.

#3 Serve & Protect, becomes Learn & Protect.
The best offense is a good defense. If your WAF knows what the application it’s protecting looks like or even better, how it behaves, then the application’s very own structure, coding, and URL/parameter make-up becomes it’s shield against malicious attacks. You don’t need to wait for a signature to protect your web application from new SQL Injection or XSS or Fuzzing attacks, if the WAF is stopping anything that doesn’t conform to expected behavior!

#4 Assess THEN Customize.
When you build a new house, you might expect to have certain things done specific to your requirements before you ever set foot inside the house but you’ve at least looked at the blueprints and seen sketches of the final product. For a WAF guarding a Web Application, custom rules really should be the last thing you do, and ideally AFTER you validate existing protections aren’t enough through penetration testing or code scanning. The major WAF vendors support the inclusion of vulnerability assessments in their products for custom policy creation.

Obviously enabling any of these are subject to your risk exposure / tolerance, but I wouldn’t advocate running for any length of time without these protections regardless of the organization or the other protections you may in place to guard your web applications.

Consider what every online entity is up against, there is more money to be made hacking your protected assets by nefarious (hopefully external) sources than you have resources or funding – short of government entities. If that wasn’t bad enough there are more newly coded applications and updates released every minute than there are security fixes going in. If you’re not fully leveraging what you have and not securing as you go, then your company is leaving something undone for the bad guys to come along and exploit.

How is your WAF being used? Is it being used? Need help getting more out of your WAF?

Advertisements

Posted on July 1, 2009, in Security / Risk, Security Management and tagged , , , . Bookmark the permalink. 2 Comments.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: