Blog Archives

Three reasons why IPS and WAF won’t converge anytime soon

Continuing on the IPS vs WAF theme, one might consider the notion that WAF will just converge with IPS. I wanted to point out three reasons why I think this will NOT happen anytime soon. The reasons center around demand, performance, and implications, and feed into each other.

It’s akin to Chris Rock’s joke about driving a car with your feet: You can drive your car with your feet if you want to, that don’t make it a good __ idea!
Read more…

Advertisements

WAF vs IPS (or Four Things Your IPS Can’t Do)

I see this often and I am always amused at the topic. I have worked with IDS/IPS for 8 years, so I know IPS when it was just a flavor of IDS that no one wanted to enable for fear of blocking access to users and customers. I chuckle at the thought of WAF being a glorified IPS. My how times have changed.
Here are four things that your WAF can do that your IPS can’t. I tried to keep this vendor agnostic.

Please feel free to pile on or comment, just no flames please!

WAF vs IPS?
Web Application Firewalls, as the name implies, work with web applications almost exclusively. Most WAF are often not best-of-breed traditional firewalls, and should not be implemented in place of a traditional network firewall. Typical WAF deployments feature SSL decryption of web application traffic and blocking of web-based threats after the WAF reassembles each web session. This is possible because the WAF operates at the application layer where HTML, XML, Cookies, Javascript, ActiveX, Client requests, and Server responses live.
Read more…

Off to the WAF races

PCI DSS called for implementation of code reviews and web-application firewalls (WAF’s) in order to continue compliance and fight off the Breach Boogieman. Organizations can also conduct code reviews, as outlined in section 6.

Some ‘experts’ believe the web firewalls are just another piece of technology being thrown on the bonfire, while others believe you will never find all the potential bugs and flaws in an organization’s custom code, let-alone commercial software.

Interestingly, there continue to be heated discussions debating the usefulness of WAF’s, where they have to be deployed, what they are supposed to inspect, and whether businesses should be distracted by WAF’s in the first place.  The most important aspect of all this is the functionality that is to be provided by this technology. The WAF requirements outlined in requirement 6.6:

  • Verify that an application-layer firewall is in place in front of web-facing applications to detect and prevent web-based attacks.

Make sure any WAF implementation meets the full extent of the requirement because “detect and prevent web-based attacks” can get a little sticky. As technology goes, there are a few variations in how WAF’s have been developed. Some products use reverse proxying to interrupt the web session for the ‘detect’ and accomplish the ‘prevent’ by only allowing valid sessions. This validation is being done in variations just like typical IDS/IPS’s operation: you get your choice of signatures, anomaly detection, protocol inspection, and combinations thereof. Some of the available products skip the proxy function and monitor the web traffic like a traditional IDS/IPS for known or suspicious threats either in-line or via a SPAN or TAP. Companies can not only choose their type of technology but can also decide on using open-source software or commercially supported products or a cross between the two.

The open-source route offers mod_security for apache and if companies need commercial support, you can get an appliance running mod_security. I found it interesting, in a recent Oracle Application deployment, Oracle recommends the use of mod_security to service as an application-layer firewall and URL-filtering firewall for DMZ-deployments. If mod_security doesn’t fit your needs, Guardian is also an open-sourced software with detection and prevention capabilities. Both have commercial support and product options.

mod_security has some other interesting options. It is possible to take the SNORT web signatures and convert them to mod_security rules via a script provided with mod_security. There are also several groups that provide signatures / rules for mod_security to identity new threats.

Outside the open-source space, there are products like Imperva’s SecureSphere gateways that use anomaly detection and profiling to determine whether something should or should not be allowed to access a web server. This company’s product line features an interesting twist, the dynamic profiling technology relied upon to ‘detect and prevent’ comes from none other than the man that developed ‘stateful packet inspection’ in CheckPoint firewalls.

Along with Imperva, are F5, Cisco, CheckPoint, and the usual list of security vendors ready to snatch up your “bail-out” funding 🙂 . As with any security technology, only after a review of your organizations needs and a thorough pilot of the prospective technology will identify the best-fit for any organization.

At the end of the day, the use of WAF technology to mitigate web application security is but one of the many defenses an organization should have in place to provide data security and data privacy.

What do you use to guard the security of your web applications?

Security’s Foe: Complexity (Part 1)

Newflash:           Complexity does not mean or provide security.

Although there probably is a company out there that hasn’t purchased a firewall, isn’t running anti-virus software, and has no plans to implement intrusion prevention technology, there are plenty that have spent the equivalent of Ughanda’s GDP for the last 5 years on security technology. After 10 years of security work and countless conversations with peers, I have concluded all this spending is not solving the fundamental problem security set out to address: create safe and secure environments.

Why not?

The answer lies in why many business don’t have many of the generally accepted mainstream security technologies deployed. Complexity.

The complexity of security solutions and the perceived inability of security to meet dynamic business needs because of that complexity are some of the key underminers of security.

It almost begins to sound like a popular comedian’s tagline:

  • If your security solution or product requires a triple PhD from MIT to operate, you might have a complexity problem.
  • If your security solution or product has not been updated since men walked on the moon, you might have a complexity problem.
  • If a 5lb block of swiss cheese has fewer holes in it than your security solution or product, you might have a complexity problem.

Sure there are all manner of security schemes on the market from network-based defenses and host-based defenses to security policy frameworks and security intelligence services to meet an organization’s security needs, but technology has only brought us to the place where we now need a room full of security experts pouring over event data or some artificial intelligence, akin to that of Skynet from the Terminator franchise, in order to determine whether our security is working or if the bad guys have just dumped the contents of the customer billing information database to a botnet-based auction system via a partner’s VPN connection using valid credentials they obtained through an infected email to an outsourced developer.

Fired up? Come back for part 2…