Home > Resources > Blog
Date posted: 20th June 2017
Ensuring that Web-based applications are secure requires a number of layers of security, not the least of which is a Web application firewall (WAF). A Web Application Firewall is a critical layer when considering the confidentiality, availability and integrity of Web-accessible data. This guide seeks to help organizations in purchasing a WAF by wading through the key questions and concerns they should consider while investigating the market.
The range in price, deployment methods, complexity and a host of other specifications is quite large for WAFs. Understanding business needs, capabilities and available resources (such as in-house skill and financing) ahead of shopping for a WAF can go a long way toward ensuring an organization ends up with a product that best fits its desired end result. Proper planning and a careful assessment of what the market offers are critical as well.
The key points and questions (purchase criteria, really) outlined below are designed to provide organizations with the tools to get moving in the right direction and make these assessments.
These criteria include determining how a WAF will fit into its environment, detects and responds to attacks, and performs logging, as well as what is required in terms of WAF management and maintenance. Answering these questions for each WAF product being investigated will help any enterprise narrow down its choices to only those products that can serve its needs.
One of the most critical aspects to look at when evaluating a WAF is deployment. In other words, what is required to put the WAF to work? There are a few different WAF deployment options to look at, and each of these should be considered, along with an enterprise’s existing environment, to determine which type of WAF is the best fit. In many cases, this will allow decision makers to — through the elimination of products that don’t work for their network and IT environment — to narrow down the list of vendors and products.
There may be performance implications here, because the traffic is taking extra steps before reaching company servers. Most vendors have adequate bandwidth, so this isn’t a problem in the majority of instances (but should still be kept in mind). The cloud-based WAF is often easier to implement because it requires only the DNS change (and possibly SSL keys being installed), and could be less work on internal IT technology skill. NOTE: Many cloud-based programs now offer DDoS protection as well.
It’s important to talk to the vendor and involve internal technical teams when evaluating the type of WAF an enterprise wishes to buy. There may be requirements or restrictions that they aren’t aware of on the surface, but could have a major impact on what is chosen. An example of this might be how the chosen integrated WAF works with the Web server. Having Web server administrators involved might avoid any problems during implementation. Another common issue is with streaming or heavy, network-based content streaming through a cloud-based WAF. Having the network team and performance-testing employees handy will ensure users don’t experience latency issues.
Another important consideration here is how the WAF handles Secure Sockets Layer (SSL), which protects website identity and data as it flows over the Internet. WAF implementations vary in how they work in regards to SSL.
In either cloud- or appliance-based WAF implementations, organizations need to decrypt the traffic in order to see it. This involves either terminating the SSL session and recreating it (if necessary) or decrypting the sessions on the wire as they pass through the WAF. Make sure the products being evaluated supports these options.
WAFs operate primarily by inspecting the content of requests and responses between the application server and the client. How and what a WAF inspects is critical to its effectiveness in protecting enterprise resources.
What the WAF inspects — such as headers, sessions, file uploads, etc. — will determine its ability to respond. A WAF should be able to inspect all components of a request/response object, including the session details itself. If an application has requirements, such as limiting the number of sessions for a user, most WAFs can help enforce those. A WAF should have configurations available to allow admins to choose these options with ease. If an organization has specific requirements around how GET versus POST is used, or specific items in the referrer, the WAF should support this.
Detection of anomalous or malicious traffic is based on a few models, and understanding each is important.
If the WAF uses a blacklist approach, it will only block requests if they are found to contain a known attack in the list. Well-known attacks such as SQL injection and cross-site scripting often contain certain characters that are easily detected. Blacklisting works great, as long as the WAF is aware of the attack method. So, blacklists must be kept up to date as threats change often.
If a WAF uses a whitelist approach, it will only allow requests that meet the criteria in the list or configuration. This detection method requires more effort during implementation on the front end, but is usually a more secure approach because it blocks everything that isn’t defined as acceptable.
Either of these methods should be configurable by a company’s technical team.
Beyond detection, how the WAF responds to an attack or anomaly is also critical. There are a number of response options that WAFs offer, and they should be able to be easily changed in the configuration interface. Typically, a WAF will interact with a request or session in some way (when an attack or anomaly is identified), such as terminating the session with the application server or blocking that single request. Each method has benefits and drawbacks, and understanding which methods are available is important.
A WAF should be configurable to block using one of the following methods:
Ideally, a WAF should support these in various configurations as a response to detecting an attack or anomaly. In some cases, though, a WAF may need to rely on other devices, such as network firewalls or routers, to perform its blocking operation. Organizations should make sure the WAF product chosen is compatible with existing network devices if they wish to use this feature.
While (arguably) the most important feature of a WAF is to protect from attacks, a close second would be its ability to log and alert admins to what’s going on. In some cases, organizations may suspect an attack or compromised user, and want to see the details of what happened. This is where, what and how the WAF logs are critical. The easiest breakdown of how to do this logging is the tried-and-true Where, When, What method.
First, let’s discuss the “What.” What does the WAF log? It should be logging as much detail as possible. It should be tracking each transaction, including sessions, navigation details and everything in-between. The full details of each transaction log entry should be well-documented to reduce the amount of time and effort it takes to investigate an incident. By having extremely detailed logging, enterprises will also be able to troubleshoot problems that might occur due to configuration issues with the WAF itself.
Next, let’s discuss the “When.” This is pretty straightforward, but it’s important to look at two key points. At minimum there should be two sets of logs. The first would be an access or transaction log populated with all activity passing through the WAF. The second would be an event log where an entry is created when something triggers the WAF’s detection or reaction. While both logs are important, the event log will be used often because the entries usually indicate anomalous behavior, such as attacks or suspected attacks.
Finally, let’s discuss the “Where.” Where the logs are stored or how they are sent to a central logging service is critical. Are the logs formatted and transmitted using formats and protocols supported by security information and event management, or SIEM, systems that the organization uses? Are the logs retained for a certain period of time on the devices? Does the WAF obfuscate any sensitive information, such as Social Security numbers or permanent account numbers (credit card numbers, for example) contained in requests? This could be important for compliance with regulations such as Payment Card Industry Data Security Standard Version, or PCI DSS.
In addition to storage, the Where also includes how alerts are generated and sent to the organization. Email alerts, Web portals and SNMP are the norm, but the more options available, the better.
WAFs aren’t intended to be configured and forgotten, and so how they are managed is important for long-term use. If a WAF uses blacklist signatures or rules, an enterprise should find out how they are going to be updated. The organization should also ensure that it can customize these rules and signatures in a way that affords the most flexibility.
If the company isn’t using the PHP scripting language, it likely doesn’t need those blacklist signatures or expression rules, and should disable them. Typically these options are configured via WAF policies through the management interface. Ensure that these policies are entirely user-configurable, in order to maintain the most control over how the WAF works.
If an organization is getting regular vendor updates, how are they delivered? Many vendors will supply a manual update file, or allow the appliance to automatically contact an update service. The same concern should be applied to the underlying operating system updates, depending on the platform that the WAF runs on (such as Windows or Linux). Make sure that whatever update method the WAF product uses, it does in fact perform them. It would be counter-productive to have an insecure device protecting the enterprise’s Web applications.
In summary, enterprise decision makers should have a thorough and detailed list regarding which questions need to be answered before they choose a WAF product or vendor.
Learn more about Next Generation Firewall from Palo Alto Networks and Netfast
Netfast Cloud Managed Services for New York Business
Netfast Managed Security Services