Imperva Increases Self-Service Capability Fourfold with Custom Security Rules

Back in 2014, we introduced Rules (previously IncapRules) to give our customers advanced control over their application security.

Today we’re putting even more of this custom tuning power in the hands of our customers by quadrupling the number of filters available via self-service.

Rules Basics

Rules are an extensive policy engine developed in response to the emergence of increasingly advanced threats as well as the growing demand to add more logic at the edge. Advanced threats continue to drive the need for adaptive security solutions which enable real-time response and flexible, custom security policy enforcement.

Rules are built using filters, operators, and values. Filters are the core function which helps tune manual policies. Customers use filters for advanced bot protection, security against brute-force attacks, and more. Although about 90% of our customers use our out-of-the-box policies in their default preventative settings, leaving the burden of tuning to the Imperva security experts, there are times when some of our customers need to make specific adjustments to their security policies.

The Existing Filter Set

Traditionally, Imperva has limited to 20 the list of filters exposed to our customers. A set of parameters is available for self-service use when defining Rules.

Filters for Rules are divided into three logical groups:

1. Clients: Information about the connecting client
2. Requests: Information about the current request
3. Counters\rates: A running count of the number of actions performed  

As one example, there’s an existing filter for the ID for the client application.

• Googlebot (Search bot) (6)

• cURL (Developer Tool) (47)

When adding or editing a rule in the Management Console, you start entering text in the value field to display a list of available values.

Example: ClientId == 15

×

Nov 7 Upcoming Webinar

Elevate your Security Posture by Balancing Effectiveness and Efficiency

Register Now

The New Filters

Behind the scenes, the Imperva Support team and SOC alone have had much more power up until now in terms of custom tuning upon request, with access to approximately 100 different filters.

But by expanding the set of Rules available via self-service to a total of 48 filters, even more policy customization is possible without ever needing to contact the Support team.  

To complement existing self-service Rules for bot protection, protection against Account Takeover (ATO), application hardening, rate limiting, and Advanced Access Control (ACL), the new filters offer the following and more:

• Advanced optionality when handling advanced bot scenarios
• Logic based on popular technologies such as Drupal, PHP, Joomla, WordPress and others
  (the idea here is to simplify complex expressions by encapsulating the tech detection and rates within a single command)

• Client certificate info such as CN, SHA1 and Serial Number

Examples

Here are three examples of new filters unveiled to customers:

(1) session-creation-ip_rate

If you set the value here to, say, 800, you will be able to capture sessions with more than 800 requests from a certain IP in 1 minute – a likely indicator of a DDoS attack.

(2) request-rate-ip_rate

This filter measures the rate of requests per IP over a 1-minute period, and if you expect no more than 100 requests, you can set the action to “block” or “alert” because that could indicate that an attacker is trying to scrape your website.

(3) login-bf-drupal_rate

Though we patch by default from the backend to mitigate known exposures such as the latest critical RCE vulnerabilities affecting Drupal, this filter may be useful for our more advanced customers who wish to add an extra layer of logic and protection.

The filter allows you to measure the rate of requests per IP over a period of time to a Drupal login page, helping in detection and prevention of brute-force attacks on Drupal login pages.

The Demand for Logic at the Edge

The customer policy rule engine has proven to be a powerful tool when you need to perform specialized adjustments for specific use cases. Advanced options for building custom security policies complement the default prevention settings in our cloud WAF for complete protection.  

But as organizations of all sizes shift to the cloud and our enterprise customer list has expanded rapidly in turn, the demand for more edge functionality has also increased. We’ve heard time and again that our customers find it very appealing to be able to add advanced logic rules at the edge.

Last year we announced the rollout of advanced Application Delivery Rules. And while we invested in building and improving the engine which drives both of these rule sets, we honed in on the need to (1) develop advanced filters which can help address emerging threats and exploitation and (2) expose logical parts of our classification engine and bot protection layers previously hidden from customer view.

The Move to More Control and Visibility

The newly visible Rules will provide a much more powerful tool for savvy customers who need to tune their policies in order to handle complex cases. This approach is yet another step we’re taking to put enhanced visibility and extended control in our customers’ hands and to stay ahead of the curve in handling the most sophisticated and automated attacks out there.