Blog Viewer

Types of Web Security Policies - Fundamentals of On-Prem WAF Part 4

By Ira Miga posted 07-08-2022 10:54


Types of Web Security Policies - Fundamentals of On-Prem WAF Part 4


Having already addressed the SSL Certificates and Ciphers, part 4 of this On-Prem WAF Fundamentals blog series will hone in on policies, looking at the different types available and best practices. This is followed by a step by step guide on defining policies.

What is a Policy?
To ensure complete application security, Imperva On-Premises WAF policies provide the system with multi-level protection in line with the Imperva On-Premises WAF object hierarchy, as follows: 

Server Groups > Services > Applications

Policies are enabled by applying them to the individual objects in this hierarchy. 

The security system includes several security layers called security policy types, mostly corresponding to the OSI model. At each level, the system can block traffic immediately or continue monitoring specific IPs, application users and sessions for blocking later, if required.

Each policy type is bound to a specific object level within the In-premise WAF security layers:

  • The lower level of the network security layer prevents network based attacks and is bound to the Server Group level.
  • The protocol and basic applicative functionality layer, such as protocol compliance and application attacks signatures, is bound to the Service level.
  • The higher protection layers, such as application profile and correlated attack validations, are bound to the Application level.

Types of Web Security Policies

  • To view Web Security Policy Types, Go to Main > Policies > Security, Select Basic Filter tab.
  • Expand option By Type and Web, View Policy Types listed under headings:
    • Service Level
    • Application Level

Custom Policies

Web Service Custom policies provide you with the flexibility to combine the server group and service protection levels. This is done by creating user-defined policies based on different combinations of the match criteria.

Correlation policies can be manually configured or are available as predefined rules that cover certain well-known scenarios.

Web Application Custom policies provide you with the ability to combine all the protection levels and to define very accurate and high level protection.

For example, using custom correlation policies you can limit access to specific URLs and directories based on the source IP address. You can also restrict the permitted HTTP headers, user agents (browsers), and so on.

You can define as many custom correlation policies as you want.

In general, most operations should use predefined profile / protocol violation policies. Custom correlation policies should only be used for operations that are otherwise impossible to perform.

How to define Security Policy?

  1. From Main > Policies > Security
  2. Use the green + sign to create new policy.
    1. The following (web) types are available (according to the level where it will be applied):
      1. Web Service - Web Service Custom
      2. Web Application - Web Application Custom
  3. Choose the Web Service Custom type:

Select relevant Match criteria from the Available Match Criteria list using the green arrow:


  • Each policy contains one or more match criteria, Logical ‘AND’ on all criteria, meaning the policy will be triggered only when all match criteria are TRUE.

For example, the picture below shows a policy with different match criteria:


This policy will be matched only if HTTP Request has parameter "pid" AND HTTP Request Method is POST, setting desired action (None/Block) and Severity.

Policy Examples:

  • Limit access to specific URLS and directories based on source IP
  • Restrict permitted HTTP headers, and user agents

Web Response Auditing

Checking the “Display response” page in “alerts” option enables the administrator the ability to view the response the user received from a web server. It also provides additional capabilities such as capturing a response that contains sensitive data or a violation. This ability enables the administrator to track the data that was leaked from the company.

The information is recorded by Imperva On-Premises WAF and it appears on the Response page in the Monitoring window.


Related links:

Application Hierarchy: Server Group, Service, Application - Fundamentals of On-Prem WAF - Part 3

SSL certificates and Ciphers - Fundamentals of On-Prem WAF - Part 2

Fundamentals of On-Premise WAF - Blog Series Pt1