A recent Gartner Inc. study highlighted this risk by estimating that 75% of today's successful attacks occur at the application layer. It made an even more frightening prediction: by the year 2009, 80% of enterprises will fall victim to an application-layer attack.
This is where application firewalls come into play. These firewalls perform application-layer inspection of HTTP traffic before it reaches the Web server. The devices are able to inspect a connection and analyze the nature and type of commands that users are providing to the application. They can then analyze the traffic for signatures of known attacks or deviations from profiles of standard utilization.
While application firewalls have great potential, the process of deploying them should be slow and deliberate. Back when network firewalls first entered the enterprise, implementation managers typically adopted a cautious approach to these projects, conducting careful analysis and extensive testing. That same approach should be applied when deploying a Web application firewall. Careful testing builds confidence among an organization's application developers, serving as leverage security managers can use to convince them that the technology will help the enterprise more than it will hinder their day-to-day lives.
Once an organization is ready to move the product into the production environment, it's time to think about a solid firewall rule base. Here's a step-by-step approach for building and deploying application firewall rule bases in an organization:
- Have an adequate adjustment period. Modern Web application firewalls have sophisticated capabilities that monitor traffic and learn patterns of normal activity. Over time, the firewall is "trained" to recognize these patterns and block anomalous traffic. The firewall, however, needs to be trained over a long enough period of time so that the rule base reflects periodic and seasonal trends in network activity. For example, an ecommerce retailer wouldn't want to train the firewall protecting its Web site during the slow summer months, and then deploy the rule base during the busy winter holiday shopping season.
- Develop custom rules to supplement vendor-provided signatures. Knowledge of an organization's infrastructure is important, and customizing a firewall to meet a company's unique needs can dramatically improve the tool's effectiveness. For example, if only one Web application in an environment should accept file uploads, a rule should be set that completely blocks PUT commands (the HTTP command used for file uploads), to all other systems.
- Begin with an initial run in passive mode. Testing out a rule base often requires a "soft launch." With such a strategy, the firewall is placed online with all of its proposed rules. It is then run in monitoring mode without actually blocking any traffic. Before the firewall is actually put into active mode, time should be spent evaluating the traffic that violates the firewall's rules. Those in charge of implementation should also tune the false positive rate before going into production. Since programmers never like it when security systems break their applications, this will go a long way toward improving relations with your developers!
- Monitor, monitor, monitor. Once the firewall is deployed in active mode, it should be watched carefully. The logs created by blocked traffic will tell an important story. Records of the blocked attacks can show management the return on their security investment. There may also be additional false positives, and they can further assist in the fine-tuning of the rule base.
About the author:
Mike Chapple, CISA, CISSP, is an IT security professional with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Mike is a frequent contributor to SearchSecurity, a technical editor for Information Security magazine and the author of several information security titles, including the CISSP Prep Guide and Information Security Illuminated.
This was first published in April 2007