SecureSphere

.
12.0

ed
rv
Web Application

se
re
Security and Compliance

s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

Web Application Security and

Compliance
Course Manual
©
20
17
Im
pe
rv
a,
In
c.
Al
lr
ig
ht
s
re
se
rv
ed
.
 .
ed
SECURESPHERE 12.0

Imperva SecureSphere

rv
se
Web Application Security

re
Course Manual

s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©
SecureSphere 12.0 Web Application Security Course Manual

Copyright Notice
© 2002 - 2017 Imperva, Inc. All Rights Reserved.
Follow this link to see the SecureSphere copyright notices and certain open source license terms:
https://www.imperva.com/sign_in.asp?retURL=/articles/Reference/SecureSphere-License-and-Copyright-
Information
This document is for informational purposes only. Imperva, Inc. makes no warranties, expressed or implied.
No part of this document may be used, disclosed, reproduced, transmitted, transcribed, stored in a retrieval system,

.
ed
or translated into any language in any form or by any means without the written permission of Imperva, Inc. To
obtain this permission, write to the attention of the Imperva Legal Department at: 3400 Bridge Parkway, Suite 200,

rv
Redwood Shores, CA 94065.
Information in this document is subject to change without notice and does not represent a commitment on the part

se
of Imperva, Inc. The software described in this document is furnished under a license agreement. The software may
be used only in accordance with the terms of this agreement.

re
This document contains proprietary and confidential information of Imperva, Inc. This document is solely for the use
of authorized Imperva customers. The information furnished in this document is believed to be accurate and

s
reliable. However, no responsibility is assumed by Imperva, Inc. for the use of this material.

ht
TRADEMARK ATTRIBUTIONS

ig
Imperva and SecureSphere are trademarks of Imperva, Inc. lr
All other brand and product names are trademarks or registered trademarks of their respective owners.
Al

PATENT INFORMATION
c.
In

The software described by this document is covered by one or more of the following patents:
US Patent Nos. 7,640,235, 7,743,420, 7,752,662, 8,024,804, 8,051,484, 8,056,141, 8,135,948, 8,181,246, 8,392,963,
a,

8,448,233, 8,453,255, 8,713,682, 8,752,208, 8,869,279 and 8,904,558, 8,973,142, 8,984,630, 8,997,232, 9,009,832,
9,027,136, 9,027,137, 9,128,941, 9,148,440, 9,148,446 and 9,401,927.
rv

Imperva Inc.
pe

3400 Bridge Parkway, Suite 200

Im

Redwood Shores, CA 94065

United States
17

Tel: +1 (650) 345-9000 Fax: +1 (650) 345-9004

Website: http://www.imperva.com
20

General Information: [email protected]

Sales: [email protected]
Professional Services: [email protected]
©

Technical Support: [email protected]

© 2017 Imperva, Inc. All rights reserved ii

SecureSphere 12.0 Web Application Security Course Manual

Headquarters Imperva, Inc.

3400 Bridge Parkway, Suite 200
Redwood Shores, CA 94065
United States
Tel: +1 (650) 345-9000
Fax: +1 (650) 345-9004
Services Training: [email protected]
Professional Services: [email protected]
Support: [email protected]

.
ed
Feedback E-mail any comments or questions about our courseware to
[email protected].
Document Part Number 210-120-WAS

rv
Revision SecureSphere Web Application Security 12.0 - 02212017

se
Publication Date 2/17/2017

re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved iii

SecureSphere 12.0 Web Application Security Course Manual

Contents at a Glance
Lesson 0 Lab Environment and Web UI

Lesson 1 Web Application Security Admin Setup

.
Lesson 2 Verifying the Initial Configuration

ed
Lesson 3 Web Application Level Preparations

rv
Lesson 4 Security Policies

se
Lesson 5 Web Application Profiling

re
Lesson 6 ThreatRadar

s
ht
Lesson 7 Alerts and Violations

ig
Lesson 8 Web Application Security Tuning

Lesson 9 Active Blocking

lr
Al
Lesson 10 Web Scanner Integration
c.

Lesson 11 Reverse Proxy (Optional)

In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved iv

SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved v

SecureSphere 12.0 Web Application Security Course Manual

Web Application Security Admin Setup

Chapter Overview
Securing web applications begins with the security infrastructure. In the context of SecureSphere, this includes
appropriate access controls to the SecureSphere web interface. This chapter shows how to create additional
SecureSphere users and how to assign permissions based on the user’s role in the company.

.
ed
Chapter Objectives

rv
• Configure users, roles and permissions for the SecureSphere Web Application Firewall.

se
• Create additional SecureSphere users with local or external authentication, as needed.

re
Users, Roles & Permissions
Several SecureSphere user accounts are defined during initial deployment; however, additional users may be

s
required to properly limit access to SecureSphere, based on company requirements.

ht
ig
Default Roles and Permissions for Web Application Security Deployments
lr
Out of the box, SecureSphere provides two roles that are relevant for Web Application Security deployments, the
Al
Administrator role, and the Web Security Admin role.
c.

Role Permission Scope Purpose

Administrator Full permissions over all The administrator role is generally reserved for
In

aspects of SecureSphere. individuals responsible for the maintenance and

administration of the SecureSphere deployment. This
a,

role may be appropriate for security team members who

rv

are responsible both for Web Application Security

settings and the administration of SecureSphere.
pe

Web Security Admin View, Edit, and Create The Web Security Admin role is limited to SecureSphere
permissions for SecureSphere Web Application Security components. This role is
Im

Web Application Security appropriate when the security team is not directly
components. responsible for the ongoing administration of the
17

SecureSphere servers.
Table 1-1 SecureSphere Roles for Web Application Security
20
©

© 2017 Imperva, Inc. All rights reserved 1-1 Lesson 1: Web Application Security Admin Setup
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
Figure 1-1 Users & Roles

re
s
Note:

ht
If more granular access is required, refer to the online help or the Web Security User Guide. The Web Security

ig
Users Guide and other Imperva SecureSphere documentation is available on the Imperva customer portal.
lr
Al
Configuring SecureSphere Web UI Users, Roles, and Permission for
c.

Web Application Deployments

In

To create a new Web User Interface user based on an existing role in SecureSphere:
a,

1. Connect to the SecureSphere UI and login as admin.

2. Go to Admin > Users & Permissions.
rv

3. From the Users & Roles Window, click Create.

pe

4. Select Create New User.

5. Enter a username for the user.
Im

6. Enter a password for the user and reenter it below to verify.

7. Select authenticator SecureSphere.
8. Select the desired role for the user from the Available window and click the right arrow to move it to the
17

Assigned window. For Web Application Security deployments, the most likely role will be either the Web
Security Admin role or the Administrator role.
20

9. Click Create.
©

Note
SecureSphere supports multiple authentication methods which are discussed in the SecureSphere Administrator’s
guide and covered in the SecureSphere Administration Class.

© 2017 Imperva, Inc. All rights reserved 1-2 Lesson 1: Web Application Security Admin Setup
SecureSphere 12.0 Web Application Security Course Manual

Review Questions
No questions.

Exercises
Exercise 1: Create an Administrator User in the SuperVeda Lab Environment

.
ed
This activity was performed during Lesson-3 of the Administration class. If you are continuing from Administration,
skip this exercise and move on to Exercise-2. If you attended the administration class during a previous training and

rv
are only attending the Web Application Security course this week, please take a moment here to create a personal
administrative account.

se
Instructions: Create an administrator user for use during the remainder of the class. Be aware that you will be

re
prompted to change the password during the first login. Due to the configuration of the Training environment, you
will be able to reuse the original password as the new password.

s
ht
1. Beginning with the Veda Client virtual machine, open the Firefox Web Browser.

ig
2. The default homepage for Firefox is set to the SecureSphere login interface, however, if that doesn’t load,
manually enter the SecureSphere URL - https://veda-mx.superveda.local:8083/
lr
or https://192.168.51.200:8083/
Al
3. Login: admin
PW: Impuser123
c.
In
a,
rv
pe
Im

4. Select the Admin workspace

17
20
©

© 2017 Imperva, Inc. All rights reserved 1-3 Lesson 1: Web Application Security Admin Setup
SecureSphere 12.0 Web Application Security Course Manual

5. Select Users & Permissions

.
ed
rv
6. From the Users & Roles window, click the button and select Create New User

se
re
s
ht
7. In the Create New User window, perform the following:

ig
a. Name the user after yourself following your company’s account naming convention.
b. Set the password to Barbapapa1. lr
Note:
Al
The password entered here is temporary and will be reset at first login. The password Barbapapa1 is
c.

recommended for temporary use. During the first time login, changing the password to Impuser123 is
recommended to simplify future lab access.
In

c. Select the Administrator role and click the right arrow to move it to Assigned
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 1-4 Lesson 1: Web Application Security Admin Setup
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In

8. Create the user.

a,

Exercise 2: Create a Web Security Admin User in the SuperVeda Lab Environment
rv

Create a second SecureSphere user and assign the Web Security Admin role to the secondary user
pe

1. From Users & Permissions again select Create > Create New User.
2. Create the new user account with your name and something to identify the role of Web Security Admin.
Im

a. Set the password to Barbapapa1.

Note:
17

The password entered here is temporary and will be reset at first login. The password Barbapapa1 is
20

recommended for temporary use. During the first time login, changing the password to Impuser123 is
recommended to simplify future lab access.
©

© 2017 Imperva, Inc. All rights reserved 1-5 Lesson 1: Web Application Security Admin Setup
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In

3. Select the Web Security Admin role

4. Create the user.
a,
rv
pe

Exercise 3: Compare Interface Views when using Administrator and Web Security Roles
Compare the SecureSphere web interface when using the Administrator and Web Security Admin Roles.
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 1-6 Lesson 1: Web Application Security Admin Setup
SecureSphere 12.0 Web Application Security Course Manual

Answers to Exercises
Exercise 1
Creating an administrator user closely follows the steps in the lesson. The Create New User window will look similar
to this screenshot:

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im

Name the account following your company’s administrative account naming convention or FirstName_LastName.
Use the default SecureSphere user Password: Barbapapa1
17

Exercise 2
20

The web security administrator user will look similar to this:

©

© 2017 Imperva, Inc. All rights reserved 1-7 Lesson 1: Web Application Security Admin Setup
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In

Name the account following your company’s administrative account naming convention or First_Last_Web_Sec.

Again, use Barbapapa1 for the initial, temporary, password and later when logging into this account set the
a,

password to Impuser123.
rv
pe

Exercise 3
Compare the SecureSphere web interface when using the Administrator and Web Security Admin Roles.
Im

To simplify the process, consider logging in with one user account using Internet Explorer, and the other account
17

with Firefox.
20

Numerous differences can be found. Two examples are show below.

Example of tab and menu differences on Main workspace:

©

• Tabs and Menus visible to Administrator users.

• Tabs and Menus visible to Web Security Admin users.

© 2017 Imperva, Inc. All rights reserved 1-8 Lesson 1: Web Application Security Admin Setup
SecureSphere 12.0 Web Application Security Course Manual

Example of differences in workspaces:

• Workspaces available to Administrator users.

.
ed
rv
se
• Workspaces available to Web Security Admin users.

re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 1-9 Lesson 1: Web Application Security Admin Setup
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 1-10 Lesson 1: Web Application Security Admin Setup
SecureSphere 12.0 Web Application Security Course Manual

Verifying the Initial Configuration

.
Overview

ed
You may find that SecureSphere has already been deployed in your organization. An important step, whether or not
you are responsible for deploying SecureSphere in your network, is to verify the configuration of SecureSphere to

rv
ensure that important Web assets are being monitored or secured by SecureSphere. To begin monitoring and
protecting the Web applications, you will need to verify the Sites Tree is configured with the proper network

se
settings, install SSL Keys for the protected Web applications, and configure the Web Service to work with proxied
and load balanced connections. To prevent exposure of sensitive information in the SecureSphere logs, you will

re
need to configure Data Masking for known sensitive data. To prevent exposure of sensitive information to clients
through Web error pages, you will need to take steps to configure a Custom Error Page.

s
Objectives

ht
By the end of this chapter, you should be able to:

ig
• Verify and configure all Web assets are protected by SecureSphere.
• Verify network traffic from Load Balancers and Proxies will be handled correctly.
•
•
Understand how to install SSL keys for the Web applications to be protected.
Prevent potential compliance issues by configuring Data Masking.
lr
Al
• Customize the SecureSphere default Error Page.

Verifying the Monitoring and Protection of Web Assets

c.

To ensure SecureSphere is able to monitor and protect Web applications, follow this high level outline of steps
In

described in the table below. Further details of how to conduct each step follow in the chapter.
a,

Process for Verifying the Monitoring and Protection of Web Assets in SecureSphere
Step Description
rv

1 Verify the initial configuration performed on the SecureSphere system.

• Verify Web server IP addresses are protected.
pe

• Verify all HTTP and HTTPS ports are protected.

• Verify Forwarded Connections settings.

Im

• Verify or Install SSL Keys for protected Web applications.

• Verify Forwarded Connections settings.

17

2 Configure Data Masking for sensitive data.

3 Customize the SecureSphere default Error Page.
20

In many organizations, the SecureSphere administrators provide a basic site configuration for known assets. Use the
following steps to verify, or add, the IP addresses of the Web servers.
©

© 2017 Imperva, Inc. All rights reserved 2-1 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

1. Select Main > Setup > Sites.

.
ed
2. In the Sites Tree, expand a Site object.

rv
3. Select a Server Group object.

se
re
s
ht
ig
Note
It may not always be obvious that a Server Group object is a Web Server Group object if another naming
lr
convention has been followed.
Al
4. On the Definitions tab, review the Protected IP Addresses section. Confirm the system administrator:
a. Entered the appropriate IP addresses for the Web servers requiring monitoring or protection
c.

b. By the specific SecureSphere Web security gateway or Gateway Group.

In
a,
rv
pe
Im
17

5. If an IP address is missing, it can be added by clicking the Create button to add a row to the Protected IP
20

Addresses list.
©

© 2017 Imperva, Inc. All rights reserved 2-2 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
6. Input the relevant IP Address, select the Gateway Group, and include a comment to identify the server
being protected.

se
re
s
ht
7. Once the information has been entered click to save your changes.

ig
Note
lr
The Gateway Group is used to identify which Gateways will be responsible for monitoring traffic to the IP address.
If you are unclear which Gateway Group should be selected, work with the system administrator to determine the
Al
correct setting.

Verifying all HTTP and HTTPS Ports are Protected

c.

By default, SecureSphere will monitor Web traffic directed to Ports 80 and 443. Traffic to non-standard ports will be
In

ignored unless these ports included in the Sites Tree, HTTP Service object.

To verify the HTTP and HTTPS ports and configure non-standard ports for protection, log into the SecureSphere Web
a,

User Interface and perform these steps:

rv

1. Select Main > Setup > Sites.

2. In the Sites Tree, expand a Server Group.
pe

3. Select an HTTP Service Object.

Im
17
20

4. On the Definitions tab, locate the HTTP Ports and SSL Ports entries.
©

© 2017 Imperva, Inc. All rights reserved 2-3 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
5. Enter any additional HTTP Ports and SSL Ports (HTTPS), using commas to separate the values.

ig
6. Click to Save Changes.
lr
Al
Verifying Forwarded Connections Settings
c.

Load Balancer and HTTP Proxy Servers Impacts on Traffic Inspection

In

When analyzing Web traffic, every aspect of the client request is inspected in an effort to separate the good traffic
from the bad. The SecureSphere Gateway inspects the network packets for source and destination IP addresses and
network ports. A load balancer or HTTP proxy server can complicate IP address identification. Depending on the
a,

network topology, the true source or destination IP address may differ from what is observed on the network.

SecureSphere Gateway First Topology

rv

The following diagram shows a Gateway first topology, where the SecureSphere Gateway handles client requests
pe

before the load balancer (LB) or proxy does.

Im
17
20
©

Figure 2-1 - Gateway First - Network Topology

© 2017 Imperva, Inc. All rights reserved 2-4 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

Load Balancer / Proxy First Topology

The following diagram shows a load balancer/ proxy first topology, where the load balancer or proxy server handles

.
client requests before the SecureSphere Gateway.

ed
rv
se
re
s
ht
Figure 2-2 - Load Balancer / Proxy Server First - Network Topology

ig
Each topology option raises specific configuration requirements for SecureSphere. The following table details the
most common impacts when SecureSphere is deployed with load balancers or proxy servers. lr
Al
Topology Inspection Impacts Impact Details
Gateway Source IP Address None The source IP address will be correct.
First Destination IP Configuration Use the Virtual IP address from the Load Balancer or proxy
c.

Address server in the SecureSphere Protected IP Addresses list.

In

SSL Certificates None The SecureSphere Gateway will need all SSL Certificates to
properly inspect traffic for the protected assets.
LB/Proxy Source IP Address Configuration The source IP address will be obfuscated by the load balancer
a,

First or proxy. Forwarded Connections, covered next, are required

for accurate source IP identification
rv

Destination IP Configuration All IP addresses and HTTP/HTTPs Ports on the Web servers
Address should be configured in SecureSphere.
pe

SSL Certificates Possible simple SSL certificates may not be required if the load balancer or
Configuration proxy performs SSL offloading.
Im

Table 2-2 - Comparison of Gateway and load balancer / proxy server topolocy impacts

Note
17

Load balancers and proxy servers often make it easy to direct additional IP addresses and ports to the protected
Web applications, all of which need to be configured in SecureSphere. If not, an uninspected path to the
application could exist, significantly degrading the security position of the SecureSphere deployment.
20

Extracting True Source IP Addresses from HTTP Headers

©

When client traffic passes through a load balancer or proxy server first, the Gateway is likely to identify the IP
address of the load balancer or proxy as the source IP address and not the client’s original IP address. If a load

© 2017 Imperva, Inc. All rights reserved 2-5 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

balancer or proxy server is unaccounted for in the configuration of SecureSphere, this will impact all policies that
depend on the true client source IP address including the ThreatRadar IP reputation policies. Fortunately, load
balancers and proxies will add an HTTP Header containing the clients IP address and this can be extracted by

.
ed
SecureSphere with the Forwarded Connections configuration.

rv
se
re
s
ht
ig
lr
Al
Figure 2-2 - Load Balancer and Proxy impact on client requests
c.

Configuring Forwarded Connections

Forwarded Connections are configured under the Sites Tree in the HTTP Service object.
In
a,
rv
pe
Im
17
20

Figure 2-3 - Main > Setup > Sites - HTTP Service object - Forwarded Connections

The Forwarded Connections is enabled by selecting Identify real client IP according to HTTP forwarding header. For
©

each load balancer or proxy, enter the Header Name and select a proxy IP group from Proxy IP Group drop down
list.

© 2017 Imperva, Inc. All rights reserved 2-6 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
Figure 2- 4 - Forwarded Connections settings

It is important to include an IP group for each Header Name instead of the default value of Any. If the Proxy IP Group

se
left with the default setting of Any, it is then possible for an external user to spoof, or fake, their IP address which
will limit the effectiveness of all security policies depending on an IP address match condition.

re
s
ht
ig
lr
Al
c.
In
a,
rv

Figure 2-5 - X-Forwarded-For spoofing example

Additional information on the configuration of Forwarded Connections is available in the SecureSphere Web
pe

Security User’s Guide.

Im

Verifying or Installing SSL Keys for Protected Web Applications

In order to inspect encrypted Web traffic destined for a Web application you want to protect or monitor, the SSL
17

keys must be uploaded to the HTTP Service object in SecureSphere. Extreme caution should be used when working
with SSL Key files due to the damage that could be done if the keys were to fall into the wrong hands. Follow your
company’s policies for all SSL Key handling procedures and avoid any unnecessary copying of the SSL Key files. For
20

example, when uploading the SSL Keys to SecureSphere from a network share it would be better to upload the SSL
Keys directly from the network share, instead of copying to your desktop to then upload.
©

© 2017 Imperva, Inc. All rights reserved 2-7 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

Note
If the Hardware Security Module (HSM) is installed on your gateways, the SSL Keys will be installed directly to the

.
gateway appliance and a ‘fake’ key is generated by the HSM for importing into the SecureSphere Web Interface.

ed
Detailed instructions are provided in the Imperva SecureSphere Administration Guide.

rv
Installing SSL Keys

se
To install the SSL Keys into SecureSphere, log into the SecureSphere Web interface and perform these steps:

1. Acquire the SSL Keys, or arrange for someone who has access to the SSL Keys to be available during this

re
configuration.
2. Select Main > Setup > Sites.
3. Expand the Site and Server Group objects to locate the relevant HTTP Service object.

s
ht
ig
lr
Al
c.

4. In the HTTP Service window, select the Definitions tab.

5. Locate the Encryption Support section.
In
a,

6. Click the Create button and the Add SSL Keys pop-up window will appear.
rv
pe
Im
17
20

7. Enter a Name for the SSL Key for later identification.

©

© 2017 Imperva, Inc. All rights reserved 2-8 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

Tip
When uploading SSL Keys to SecureSphere, include the expiration date in the name of the key. Doing this

.
consistently will help with key management.

ed
8. Select the key file format based on the SSL Key.
a. For PEM format SSL Keys, the public and private keys will be in separate PEM files.

rv
se
re
Note

s
The public key may also be called a certificate or signed certificate.

ht
b. For PKCS12, PFX, or P12 files, the public and private keys are in the password protected file.

ig
lr
Al
9. Click the Browse button. A file browser window to locate the SSL Key will appear.
10. When the file or files have been selected and the password entered, if required, click the Upload
button.
c.
In
a,
rv
pe
Im

11. When the upload completes, the Web interface will show the details of the uploaded certificate.
17

12. Click to Save Changes.

20
©

© 2017 Imperva, Inc. All rights reserved 2-9 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

Note
Verification of the SSL Keys in the Alerts log is normally performed immediately after installation to verify the SSL

.
keys are working properly. It is also possible that more than one SSL Key is in use and a required key was not

ed
installed. However, the necessary background topics have not been covered yet so the verification of SSL Keys will
be covered later in the tuning lesson.

rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 2-10 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

Configuring Data Masking for Sensitive Data

With the IP addresses, HTTP/HTTPS ports, and the SSL Keys configured, SecureSphere can now inspect all Web

.
traffic for the configured Web applications. This also means SecureSphere can record traffic occurring between the

ed
clients and server. However, this can cause issues with sensitive information like credit card numbers, government
identification numbers, or login credentials. If sensitive information is recorded in the SecureSphere traffic logs, it

rv
can cause serious problems with regulatory compliance. Fortunately, sensitive data can be excluded from the logs
with Data Masking. Data Masking is a feature that replaces sensitive values with repeated asterisks (*) symbols. Data

se
masking is performed by the Gateway during traffic inspection and the sensitive values are masked in memory
before the first write. Data Masking only applies to the process of logging events in SecureSphere and does not alter
the client requests or server responses.

re
Data Masking is configured under the Sites Tree in the HTTP Service object. Two forms of data masking for Web
applications are available:

s
1. Mask Data in Elements

ht
2. Sensitive Dictionaries

ig
lr
Al
c.
In
a,
rv

Figure 2-6 - HTTP Service Operation Tab - Data Masking

Each of these Data Masking methods has advantages and limits that are important to understand in order to ensure
pe

sensitive data is properly masked.

Im

Masking Data in Elements

Masking Data in elements masks sensitive values based on an HTTP element. An element is a webpage parameter,
HTTP header, or a cookie. Any value assigned to the parameter, header, or cookie in question will be masked.
17

Masking based on elements is ideal for sensitive values that appear in a consistent location in the Web application,
like the username and password parameters on a Web login page.
20

SecureSphere provides a default list of elements for masking called the Default Data Masking Group. The list is
located in Global Objects, Data Masking Groups scope.
©

© 2017 Imperva, Inc. All rights reserved 2-11 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
Figure 2-7 - Main > Setup > Global Objects - Scope Selection - Data Masking Groups

Note

re
In the Data Masking Group view, the masking elements are referred to as fields.

s
The Default Data Masking Group is predefined and contains sensitive elements used in popular Web application

ht
frameworks. The performance impact of the Data Masking in Elements check is minimal and the default list will not
have a negative impact on performance. For these reasons, the Default Data Masking Group is an excellent starting

ig
point for new deployments and newly on-boarded Web assets. However, Web assets built in-house often have
elements unique to the application which will require customization of the Mask Data in Elements list.

Customizing Data Masking Groups

lr
Al
The Default Data Masking Group can be edited if needed; however, this list is automatically applied to all new Web
applications. In general, it is better to create a copy of the Default Data Masking Group and customize the copy.
c.

Additional lists may be required with additional protected Web assets based on the types of sensitive information
and the customizations present in the Web pages. For some organizations with a common Web server software and
In

content framework, a single list may be sufficient. A good example of this would be for a Web hosting company that
provides WordPress content management for the sites. Because all sites have a common content management
system, a single Data Masking Group could be used. In most corporate deployments, however, multiple
a,

technologies are in use and it will likely be better to have several custom Data Masking Groups.
rv

Tip
pe

If multiple Web content management technologies are in use, prioritize the most sensitive Web assets first and
customize a list for those assets. Customized lists for lower priority assets can be created when needed.
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 2-12 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
Figure 2-8 - Data Masking Group

How Data Masking in Elements Works

s
ht
The Data Masking Group is a listing of names to be identified during traffic inspection. The associated values will be
masked for every name that matches. Inspection for a particular field name is performed if the Enabled checkbox is
checked and will apply to the Parameters, Headers, or Cookies based on which boxes are checked.

ig
Column
Name
Purpose
The name of the field to match in the Web traffic.
lr
Al
Enabled Enable or disable matching for this field. New fields are enabled by default. To disable them
deselect the enable checkbox.
Match Option, Full or Prefix. From the dropdown menu, select whether you want to match the full name,
c.

or if matching a prefix is sufficient to identify the field for masking.

Description Enables you to type a free text description of the field.
In

Parameters Determines if inspection for this parameter should apply to Web page parameters.
Headers Determines if inspection for this parameter should apply to Web headers.
Cookies Determines if inspection for this parameter should apply to cookies.
a,

Table 2-- Data Masking Group column details

rv

Data Masking Group Example

pe

Consider an accounting firm that receives regular sensitive information from their customers through an Application
Programming Interface (API). The earnings field, API_Earnings, and the API ID, API_ID_XXXXX, field need to be
masked. The API_Earnings value should be matched anywhere while the API_ID only occurs in the HTTP headers or a
Im

cookie. Unfortunately, the XXXXX part of API_ID_XXXXX is randomly assigned so the masking needs to work for all
names starting with API_ID. The following entries are configured to properly mask these sensitive values. Commented [A1]: Can this be clarified?
17
20

Figure 2-9 - Custom Data Masking Group Example: API Fields

Note
©

Names in the Data Masking Group are case insensitive, so api_earnings will match API_Earnings.

© 2017 Imperva, Inc. All rights reserved 2-13 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

The effect of this configuration are shown in the following table:

Example HTTP Request Details
Original Request POST https://www.supervedal.local:8443/api_cust.asp HTTP/1.1

.
Host: 192.168.53.105

ed
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5

rv
Accept-Encoding: gzip, deflate
Cookie: ASPSESSIONIDCQBCRBQC=IGPLOOOBAKHOCNLGBEDMAECA; API_ID_93155

se
API_Customer_Name=BronzeWerks&API_Earnings=1.238M
SecureSphere Logs POST https://www.supervedal.local:8443/api_cust.asp HTTP/1.1
Host: 192.168.53.105

re
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5

s
Accept-Encoding: gzip, deflate
Cookie: ASPSESSIONIDCQBCRBQC=IGPLOOOBAKHOCNLGBEDMAECA; API_ID******

ht
API_Customer_Name=BronzeWerks&API_Earnings=******

ig
Table 2-3 - HTTP request details before and after masking

Creating a Custom Data Masking Group lr

Al
To create and customize a new Data Masking Group, log into the SecureSphere Web interface and perform these
steps:

1. Select Main > Setup > Sites and expand the Sites Tree to select the relevant HTTP Service object.
c.

2. Select Operation tab in the HTTP Service window.

3. Click the icon to expand the Data Masking section.
In
a,
rv
pe
Im

4. Create a new custom Data Masking Group as follows:

a. Click the button.
17
20
©

© 2017 Imperva, Inc. All rights reserved 2-14 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

b. In the Create Data Masking pop-up window, enter the name for this list.

.
ed
rv
se
c. Choose Use Existing and select Default Data Masking Group from the menu.

re
Note
Generally, it is easier to tune a list of common elements, rather than create the list from scratch. If; however, the

s
Web developers supply a list of all sensitive elements that require masking, creating a custom list with just those

ht
elements would make sense.

ig
d. Click Create.
5. In the HTTP Service window, verify the newly created Data Masking Group is selected.
6. Click to save the changes.
7. Select Main > Setup > Global Objects.
lr
Al
8. In the Scope Selection menu, select Data Masking Groups and then locate your newly created Data Masking
Group in the Globals Tree.
c.

9. With the new Data Masking Group selected, use the + and X buttons to add or remove rows to the table to
customize the fields as needed.
In

10. Click to save changes.

a,

Sensitive Data Dictionaries

rv

The secondary method for masking sensitive information is with Sensitive Dictionaries. A Sensitive Data Dictionary is
a Global Object consisting of one or more regular expression patterns that match the sensitive data. Data Masking
pe

with Sensitive Dictionaries is especially useful when masking must be performed and the name of the parameter,
HTTP header, or cookie is unknown. Sensitive Dictionaries require the data have a predictable format like credit
Im

card numbers or government identification numbers. Sensitive data that does not follow a consistent format, like
passwords, needs to be masked with the Masking in Elements feature previously covered.
17

Note
A regular expression a sequence of characters that define a search pattern. This course will not cover the design
20

or creation of regular expression patterns. However, the SecureSphere Web Security User’s Guide does provides
sufficient information creating basic regular expressions.
©

© 2017 Imperva, Inc. All rights reserved 2-15 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

Preconfigured Sensitive Data Dictionaries

Sensitive Data Dictionaries are Global Objects containing the regular expressions for sensitive data identification and

.
masking. SecureSphere comes pre-configured with the following Sensitive Data Dictionaries:

ed
Name Description
American Express Credit Card Numbers Credit Card Identification and Masking

rv
Diner's Club/Carte Blanche Credit Card Numbers Credit Card Identification and Masking

se
Discover Credit Card Numbers Credit Card Identification and Masking
JCB Credit Card Numbers Credit Card Identification and Masking
MasterCard Credit Card Numbers Credit Card Identification and Masking

re
U.S Social Security Numbers US Social Security Number Identification and Masking
Visa Long Credit Card Numbers Credit Card Identification and Masking

s
Visa Short Credit Card Numbers Credit Card Identification and Masking

ht
enRoute Credit Card Numbers Credit Card Identification and Masking

Table 2-4 - SecureSphere Preconfigured Sensitive Data Dictionaries

ig
Understanding Sensitive Data Dictionaries
lr
Sensitive Data Dictionaries are located in Main > Setup > Global Objects, Sensitive Data Dictionary Groups scope.
Al
c.
In
a,

Figure 2-9 - Main > Setup > Global Objects - Sensitive Data Dictionary Groups scope
rv

The Sensitive Data Dictionary window shows the configuration for the selected dictionary. The predefined Sensitive
Data Dictionaries will show the Application Defense Center (ADC) emblem which indicates that changes are limited.
pe

Below the ADC emblem are several configuration options that will be covered later because it is important to first
understand the patterns themselves.
Im

Column Purpose
Display Name The specific name of the pattern. If this Sensitive Data Dictionary
is used in a security policy, the name will be visible in any
17

resulting violation details.

Type: Simple or Advanced This controls whether the pattern is an exact text match, or a
regular expression match, respectively.
20

Pattern (Type - Simple) The exact text to mask for in the Web traffic.
Pattern (Type - Advanced) The regular expression pattern to be applied to the Web traffic.
©

© 2017 Imperva, Inc. All rights reserved 2-16 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

Elements without masking (Type - Advanced) This is only available for Advanced patterns and identifies the
regular expression pattern groups that will remain in plain text,
i.e. unmasked.

.
ed
Figure 2-4 - Dictionary Patterns Table Details

Custom Sensitive Data Dictionaries

rv
The following custom Sensitive Data Dictionary example has one Simple and one Advanced pattern showing.

se
re
Figure 2-10 - Example - SuperVeda Custom Sensitive Data Dictionary

s
Simple patterns are, not surprisingly, easy to configure. The exact text that should be identified is entered in the

ht
pattern field. The Advanced setting allows for both simple and advanced pattern matching and has the following
requirements:

ig
• Simple patterns are proceeded part= and Advanced, regular expression, patterns with rgxp=
•
•
The pattern itself must be enclosed in double quotes lr
Search terms are comma separated and spaces are acceptable before or after the commas
Al
• Multiple part= terms are allowed but only one rgxp= term can be used per pattern
• Data Masking behavior is controlled by parenthesis ( ) groupings in the regular expression
• Regular expression groups are counted from the left and used in Elements without masking as $1,$2,…
c.

The additional configuration options for the Sensitive Data Dictionary above the patterns list.
In

Figure 2-11 - Sensitive Dictionary options

a,

Sensitive Data Dictionary configuration options:

rv

• Validation: Options None / Validate Luhn Formula

• Case Sensitive
pe

• Limited Values: Min & Max

The Validation option allows an additional Luhn validation check on numeric identified by the patterns. Luhn
Im

validation is a form of error checking that is used for credit card numbers. An identified number that passes both the
regular expression match and the Lunh validation check can be identified as a credit card number with very high
confidence. The last two options, Case Sensitive and Limited Values, are relatively self-explanatory and are typically
17

needed for sensitive dictionaries that will be used in security policies by allowing precise matching of the Web
traffic.
20

Note
Luhn validation is commonly referred to as the Luhn Algorithm or the Modulus 10 / Mod 10 algorithm. It is a
©

simple hashing function to identify input or transmission errors.

© 2017 Imperva, Inc. All rights reserved 2-17 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

Data Masking with Sensitive Data Dictionaries

.
1. Select Main > Setup > Sites and expand the Sites Tree to select the relevant HTTP Service object.

ed
2. Select tab in the HTTP Service window.
3. Click the icon to expand the Data Masking section.

rv
se
re
s
ht
ig
4. On the top of the Sensitive Dictionaries list, click the button. A new row will be added to the list.
5. Select an option from existing Sensitive Dictionaries drop down list as needed.
lr
Al
c.
In
a,
rv

6. If the available data dictionaries are not suitable, you will need to create a custom Sensitive Dictionary as
follows:
pe

a. Click the icon and the configure Sensitive Dictionary window will appear.
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 2-18 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

b. On the top of the Global Trees pane, click the and the Custom Data Dictionary window will appear.

.
ed
rv
se
re
s
c. Enter the Name for the custom dictionary.

ht
d. Set the Case Sensitive and Limited Values options as needed; these options can be changed later.

ig
e. Click the button.
f. From the Sensitive Dictionary window, click the button at the top of the patterns table to add a row to
the table. lr
Al
c.
In
a,

g. Name and configure the row as needed.

h. Click to save changes.
rv

7. When the Configure Sensitive Dictionary window closes you will see the HTTP Service window.
8. If the newly created Sensitive Dictionary is not selected, select it.
pe

9. Click to save changes.

Im

Customizing the SecureSphere Default Error Page

17

The next configuration step for the HTTP Service object is to set the default error page. This is a preparation step
that will become effective when SecureSphere is configured to block traffic. The default error page will be displayed
to clients blocked by a security policy. There are two main reasons to change the default error page from the pre-
20

defined value.

• Company branding
• Unintended disclosure of SecureSphere Protection
©

© 2017 Imperva, Inc. All rights reserved 2-19 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

If a regular client is blocked, the block page ensures they know there was a problem with their request. Having the
block page branded by the company ensures the client is aware that their request went to the right location and
that it was intentionally denied. This is especially important when legitimate client traffic is accidentally identified as

.
ed
an attack and is blocked. The block page will encourage legitimate users to report the issue and the incorrect traffic
identification can be identified and resolved.

rv
The second reason is less obvious but is still important. The default error message is known to hackers and criminals.
If they are blocked and see SecureSphere’s pre-defined default error page, it is as good as advertising that your Web

se
application is protected by SecureSphere. For unskilled hackers, the realization that SecureSphere is protecting the
site may be enough to convince them to give up and move along. However, for elite hackers and criminal
organizations this is just valuable information and they will use to adjust to more stealthy investigations and attack

re
preparations which can be much harder to detect.

It is important to note that the Default Error Page is only visible to Web users when the Server Group mode is set to

s
Active and a security policy configured for blocking is triggered by the user’s activity. For most, switching the Server

ht
Group to Active will only be done be after the initial deployment, configuration and at least one round of tuning.
Depending on the complexity of the protected Web assets, this could take between three weeks to a couple of

ig
months from the installation date for SecureSphere to the switch to active. Since the changing the default error
page is important for the overall security position of SecureSphere, but is only noticeable when SecureSphere is set
lr
to blocking several weeks later, it is considered a best practice to update the configuration during the initial
deployment. This excludes the chance of forgetting later on.
Al
The Error Page settings are on the HTTP Service object under the Default Tab.
c.
In
a,
rv
pe
Im
17
20

Figure 2-12 - HTTP Service, Error Page settings

SecureSphere supports the two following options for Error Pages:

Error Page Option Description
©

Redirect Redirect blocked clients to the configured URL

Page Present the configured HTML Page to blocked clients

© 2017 Imperva, Inc. All rights reserved 2-20 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

Table 2-5 - Error Page types: Redirect and Page

Tip

.
ed
For most organizations, redirecting to an URL which is maintained by the Web developers is the best choice. This
lets the Web developers retain design and branding control over the block page, instead of requiring the
SecureSphere team to maintain the page through the SecureSphere Web interface.

rv
Customizing the Default Error Page

se
1. Select Main > Setup > Sites.
2. Expand the Site and Server Group objects to locate the relevant HTTP Service object.

re
s
ht
ig
3. In the HTTP Service window, select the tab.
lr
Al
4. Click the to expand the Error Page section.
c.
In
a,
rv
pe

5. By default, Page is selected and shows the default HTTP Page that needs to be modified:
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 2-21 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

Note
Even if the default error page will be a redirection URL, it is important to change the default page text to ensure it

.
will always be different from the original page block page provided by SecureSphere.

ed
6. Locate and remove text starting with “This page can’t be displayed…” and ending with “The incident id is:
${SESSION_ID}.

rv
se
re
7. Enter a unique error statement like “Your page could not be displayed” or “Problem processing your request”

s
or “Page not found.” Uniqueness is important because any consistent pattern here could become a clue for the
hackers.

ht
ig
lr
Al
8. Click to save changes.
9. If SecureSphere will be configured to redirect to a URL, select the Redirect option and enter the desired
c.

destination URL.
In
a,
rv

Note the use of the $(HOST) placeholder. This will be substituted with the host name in the client request.
10. Click to save changes.
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 2-22 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

Review Questions
1. Explain what Data Masking does and the possible consequences of unmasked sensitive data for a

.
SecureSphere deployment.

ed
2. Describe what will happen with Web traffic directed at an IP Address that is not present in the Protected IP
Addresses list. Likewise, what will happen with traffic directed to a port that is not configured as an HTTP or

rv
SSL Port?
3. For a Web asset with both HTTP and HTTPs activity, how serious of an issue would it be to not upload the SSL

se
Key to SecureSphere? Why?
4. Give two or more reasons to modify the default error page.

re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 2-23 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

Exercises

Exercise 1: Verify Web Server IP Addresses are protected

.
ed
Instructions: For the SuperVeda Site, verify the IP Addresses and Ports are configured for traffic inspection. If
anything is missing or incorrect, update the SuperVeda site objects to match the following:

rv
Item Setting
Server: VedaWeb 192.168.53.105

se
HTTP Ports 80, 8008
HTTPs Ports / SSL Ports 443, 8443

re
Note

s
You will need to check both the Server Group and Service levels of the Sites Tree to complete this task.

ht
Use the following steps to verify, or add, the IP addresses of the Web servers.

ig
1. Beginning with the Veda Client virtual machine, open the Firefox Web Browser.
2. The default homepage for Firefox is set to the SecureSphere login interface. If the page fails to load
lr
automatically, try manually entering the SecureSphere URL - https://veda-mx.superveda.local:8083/
or https://192.168.51.200:8083/
Al
3. After successfully logging in, the default page, Main > Setup > Sites, should appear. If not, select Main >
Setup > Sites.
4. Locate the Sites Tree and expand the SuperVeda Site.
c.

5. Select the SuperVeda Web SG Server Group.

In
a,
rv
pe

6. On the Definitions tab, review the Protected IP Addresses section. Confirm the system administrator
Im

entered the appropriate IP addresses for the Web servers requiring monitoring or protection by the
specific SecureSphere Web security gateway or Gateway Group. In this case, verify the
17
20
©

© 2017 Imperva, Inc. All rights reserved 2-24 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

www.superveda.local IP address is configured as 192.168.53.105, and the Gateway Group is set as veda-gw.

.
ed
rv
se
re
s
ht
ig
7. For the SuperVeda Web server group, the required IP addresses are present. If an IP address was missing,
however, it could be added at this time.

Exercise 2: Verify all HTTP and HTTPS Ports are protected

lr
Al
Instructions: To verify the HTTP and HTTPS ports and configure non-standard ports for protection, log into the
SecureSphere Web User Interface and perform these steps:
c.

1. Select Main > Setup > Sites.

In

2. In the Sites Tree, select the SuperVeda – Http – Service.

a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 2-25 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

3. On the Definitions tab, locate the HTTP Ports and SSL Ports entries.

.
ed
rv
se
re
s
ht
ig
4. For your convenience, the required ports documented at the beginning of this section are repeated here:

HTTP Ports 80, 8008

HTTPs Ports / SSL Ports 443, 8443
lr
Al
5. Enter any additional HTTP Ports and SSL Ports (HTTPS) required, using commas to separate values.
c.

6. Click to Save Changes.

In

Exercise 3: Configure and Customize the Default Error Page

a,

Instructions: Configure the default error page so that when SecureSphere is configured to block the page will be
displayed to clients blocked by a security policy.
rv

1. Select Main > Setup > Sites.

2. Expand the Site and Server Group objects to locate the relevant HTTP Service object.
pe
Im
17
20

3. In the HTTP Service window, select the tab.

©

© 2017 Imperva, Inc. All rights reserved 2-26 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

4. Click to expand the Error Page section.

.
ed
rv
se
re
s
ht
ig
5. Use Default Error Page is selected by default and the error page type is set to Page with the Imperva defined
HTTP Page which needs modification.
lr
Al
c.
In
a,
rv

Note
pe

Even if the default error page will be a redirection URL, it is important to change the default page text to ensure it
will always be different from the Imperva defined page to remove the possibility of accidentally advertising that
Im

the web application is protected by SecureSphere.

6. Locate and remove text starting with “This page can’t be displayed…” and ending with “The incident id is:
${SESSION_ID}.
17
20
©

© 2017 Imperva, Inc. All rights reserved 2-27 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

7. Enter a unique and minimally informative error statement. Uniqueness is important because any consistent
pattern across multiple Imperva customers could become a clue for attackers.

.
ed
rv
se
Possible alternatives:
The page could not be displayed.
Problem processing your request.

re
Page not found.
8. Click to save changes.
9. If SecureSphere will be configured to redirect to a URL, select the Redirect option and enter the desired

s
destination URL. The placeholder $(HOST) can be helpful since it will be replaced with the host name in the

ht
client’s blocked request.

ig
lr
Al
10. Click to save changes.
c.

Exercise 4: Upload a Certificate to the HTTP Service Object

In

Instructions: Upload the wc.superveda.pfx certificate to the SuperVeda – Http – Service. The Certificate is a wildcard
certificate and is located under the tools folder.
a,

Certificate Details:
rv

SSL Key File wc.superveda.pfx

Location Veda Client: C:\…\Desktop\Tools\Training Classes\SSL Certificates
pe

Certificate Type PFX

Certificate Password superveda (all lowercase)
Expiration 8/23/2025
Im

Recommended Name *.SUPERVEDA.LOCAL – 8/23/2025

17

Exercise 5: Configure Data Masking

Instructions: Configure Masking Data in Elements for the SuperVeda Website. Create a copy of the default data
20

masking list named SuperVeda Data Masking List and apply this custom list to the SuperVeda HTTP Service object.
©

© 2017 Imperva, Inc. All rights reserved 2-28 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

Exercise 6: Assign Sensitive Dictionaries to an HTTP Service

Instructions: Assign the following credit card Sensitive Dictionaries to the SuperVeda HTTP Service:

.
ed
• American Express
• MasterCard
• Visa (Short & Long)

rv
• SuperVeda Credit Cards

se
The SuperVeda company cards will require a custom sensitive data dictionary and the following information has
been provided:

re
• SuperVeda Credit Card Numbers are 16 digits long and start with 1234 for the first four digits.

The following regular expression pattern has been provided for identifying SuperVeda credit cards:
part="1234", rgxp="([^\d]|^)(1234)([-\.\s\\\/=]?)(\d{4})([-\.\s\\\/=]?)(\d{4})([-\.\s\\\/=]?)(\d{4}([^\d]{1}|$))”

s
Elements without Masking: $1,$3,$5,$7,$8

ht
Tip:

ig
The info.txt file available on the desktop has the above regular expression for your convenience. Be sure the final
string is properly formatted with a part= and rgxp= parts and the patterns are enclosed in quotes. If you have any
lr
difficulty with this part check the answer to this exercise or work with the instructor to identify the issue.
Al
Exercise 7: Modify the Default Error Page Text
c.

Instructions: Modify the text in the pre-defined Default Error Page to reduce the risk of outsiders identifying
SecureSphere.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 2-29 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

Answers to Review Questions

1. Explain what Data Masking does and the possible consequences of unmasked sensitive data for a

.
SecureSphere deployment.

ed
a. Data Masking replaces sensitive values with hash symbols in the SecureSphere security logs. It only applies
to SecureSphere logging and does not alter the client request, or server response.

rv
b. Having un-masked sensitive data in the security logs is likely non-compliant with common compliance
regulations like PCI or HIPPA and can result in falling an audit.

se
2. Describe what will happen with Web traffic directed at an IP Address that is not present in the Protected IP
Addresses list. Likewise, what will happen with traffic directed to a port that is not configured as an HTTP or
SSL Port?

re
a. Web traffic directed to an IP address absent from the Protected IPs list is allowed and ignored by
SecureSphere. It will not be inspected, logged, or controlled in any way.
b. Web Traffic directed to a network Port number absent from the SecureSphere configuration will be allowed

s
and ignored by SecureSphere. This traffic will not be inspected or controlled in any way.

ht
3. For a Web asset with both HTTP and HTTPs activity, how serious of an issue would it be to not upload the SSL
Key to SecureSphere? Why?

ig
a. A missing SSL Key is a serious issue.
b. Without the SSL Key, absolutely no protection is provided for the HTTPs traffic based on that key. The
lr
encrypted areas of a Web application almost always sensitive areas of the application and being unable to
inspect this traffic leaves the application unprotected.
Al
4. Give two or more reasons to modify the default error page.
a. Modifying the error page allows for company branding and messaging and can minimize end-user questions
to being blocked.
c.

b. Hackers and internet criminals are familiar with the SecureSphere Default Error Page and seeing it will let
them know that SecureSphere is protecting the Web application. With this information, skilled criminals
In

may obfuscate their attack preparations and making them harder to track. Without this information, the
criminal is likely to trigger more simple security violations, each of which is an opportunity for the security
a,

team to learn about the attacker and counter the attack.

rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 2-30 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

Answers to Exercises

Exercise 1: Verify Web Server IP Addresses are Protected

.
ed
1. Log into SecureSphere with the custom administrator login created in the exercises from lesson 1. Commented [A2]: So screenshot should have first_last
instead of student_admin

rv
se
re
s
2. If this is the first time logging in with this account the password will need to be reset. Set the password to

ht
Impuser123.

ig
lr
Al
c.
In
a,

3. From the Main workspace, select Setup > Sites.

rv
pe
Im

4. From the Sites Tree, expand the SuperVeda Site and select SuperVeda Web SG.
17
20
©

5. Verify the VedaWeb server IP address, 192.168.53.105, is in the Protected IP Addresses table:

© 2017 Imperva, Inc. All rights reserved 2-31 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
Exercise 2: Verify all HTTP and HTTPS Ports are Protected lr
1. Select the SuperVeda – Http – Service object from the Sites Tree.
Al
c.
In
a,
rv

2. Verify HTTP ports 80 and 8008 and SSL ports 443 and 8443 are listed and if not, add the ports using commas to
pe

separate them.
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 2-32 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
Exercise 3: Configure and Customize a Default Error Page

ht
The steps in this exercise are fully documented in Exercise 3. When done the setting Use Default Error Page should

ig
still be selected, the page type is Redirect, and the redirect URL should be HTTP://$(HOST)/error.htm.

Exercise 4: Upload a Certificate lr

Al
1. Select Main > Setup > Sites.
2. The Add SSL Keys window should appear as follows before uploading the certificate:
c.
In
a,
rv
pe
Im

3. Once uploaded, the certificate should appear as follows:

17
20

Exercise 5: Configure Data Masking

©

1. Select Main > Setup > Global Objects.

© 2017 Imperva, Inc. All rights reserved 2-33 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

.
ed
2. From Scope Selection select Data Masking Groups. It may be necessary to scroll down when locating the Data
Masking Groups scope.

rv
se
re
s
ht
ig
3. Click to create a new Data Masking Group.
4. In the Create Data Masking Group window, name the new data masking group SuperVeda Data Masking List.
5. Select Use Existing: Default Data Masking Group. lr
Al
c.
In
a,
rv
pe
Im

6. Click . The custom data masking group is now available for use with the SuperVeda – Http –
Service.
7. Select Setup > Sites to return to the Sites Tree.
17

8. Expand the Sites Tree as needed to select SuperVeda – Http – Service

9. From the service window select the Operation tab.
10. Locate and expand the Data Masking section.
20
©

© 2017 Imperva, Inc. All rights reserved 2-34 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
11. Select the SuperVeda Data Masking list.

s
ht
ig
12. Click to save changes. Modifications of the custom Data Masking list will be limited to SuperVeda Data
and will not impact other Web applications. lr
Exercise 6: Assign Sensitive Dictionaries
Al
Assigning the predefined sensitive data dictionaries is relatively straightforward.
c.

1. Select Main, Setup > Sites and the SuperVeda – Http – Service object.
In

2. From the Service window, select the Operation tab and expand the Data Masking section.
a,
rv
pe
Im
17

3. On the Sensitive Dictionaries table, click the Create button four times

4. Select the predefined credit card number sensitive dictionaries.

20
©

© 2017 Imperva, Inc. All rights reserved 2-35 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
5. Configure the resulting rows as follows:

se
o American Express Credit Card Numbers
o MasterCard Credit Card Numbers
o Visa Long Credit Card Numbers

re
o Visa Short Credit Card Numbers

s
ht
ig
6. Click to save changes.
lr
Al
7. Create a custom Sensitive Data Dictionary as follows:
c.

8. Click the Create button one additional time

9. From the last row, click the Icon.

In
a,
rv
pe

10. The Configure Sensitive Dictionary window will appear,

Im

11. From the Globals Tree, click create.

17
20

The Create Sensitive Dictionary Group window will appear.

©

© 2017 Imperva, Inc. All rights reserved 2-36 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
12. Name the new Sensitive Dictionary SuperVeda Credit Cards.

ht
13. Leave the remaining settings in their default values and click .

ig
14. Once the SuperVeda Credit Cards sensitive data dictionary group is created, it is auto-selected and ready for
configuration.
lr
Al
c.
In

15. Configure the row as follows:

Display Name SuperVeda CC Numbers - 1234

a,

Type Advanced
rv

Pattern:
part="1234", rgxp=”([^\d]|^)(1234)([-\.\s\\\/=]?)(\d{4})([-\.\s\\\/=]?)(\d{4})([-\.\s\\\/=]?)(\d{4})([^\d]{1}|$)”
pe

Elements without masking $1,$3,$5,$7,$8

Im

The configured row should appear as follows:

17
20

16. Click to save changes.

©

Note

© 2017 Imperva, Inc. All rights reserved 2-37 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

If you copy and paste the pattern, you may see the following error message:

.
ed
rv
This can be corrected by checking every dash and quote in the pattern for windows smart-replacements. If found,

se
simply delete the smart quote or extended hyphen and type in a replacement quote or hyphen. In the
SecureSphere Web Interface, the regular character will be entered and your pattern should be allowed to save.

re
17. After saving the changes, close the Sensitive Dictionary window.

18. Select the SuperVeda Credit Cards sensitive dictionary.

s
ht
ig
19. Click to save changes.
lr
Al
Exercise 7: Modify the Default Error Page
c.

The steps in this exercise tightly follow the process documented earlier in this lesson. Any significant modification to
the default error page would be acceptable. If you followed the steps demonstrated in this lesson the resulting
In

default error page would appear as follows:

a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 2-38 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 2-39 Lesson 2: Verifying the Initial Configuration
SecureSphere 12.0 Web Application Security Course Manual

Web Application Level Preparations

Overview
SecureSphere is application aware with traffic analysis extending to the individual pages, forms, fields and
parameters that collectively make up the Web applications being protected. To benefit from such fine grained traffic
inspection, it helps to have distinct Web application objects in the sites tree. This chapter shows how to rename,

.
create and map Web application objects in the Sites tree and how to set default learning thresholds used by all Web

ed
application objects in the learning process.

rv
Objectives

se
By the end of this lesson you should be able to:

re
• Create and Configure Web Applications, as needed.
• Direct client activity to the relevant Web Application objects.

s
• Adjust the initial learning thresholds based on the protected applications and Imperva best practice

ht
recommendations.

ig
Creating and Configuring Web Applications lr
Web Application Sites Tree objects are useful for two reasons. First, Web application objects allow application of
Al
unique security policies allowing tight control over activity on each protected asset. Second, Web application objects
are directly tied to SecureSphere’s Web Application Profile, a learning engine that builds a model of expected client
c.

activity and is used by security policies.

In

For example, a company may have both a content management system (CMS) and an e-commerce application on
a,

the same server. Having a unique Web application object for each asset would allow aggressive security on the CMS
application, such as limiting logins to only intranet IP addresses. At the same time a cautious security policy for the
rv

e-commerce application could require a few abnormal requests before initiating a block, addressing concerns
pe

around the possibility of blocking legitimate activities. For both applications, the learning process will perform better
because the client behavior for each application is more consistent. The CMS client activity is directed to the CMS
Im

application object and shopping activity is handled by the e-commerce application object. Both security Policies and
the Web Application Profile will be covered in detail in future lessons.
17

Proper naming of items in the Sites Tree is an important practice to streamline management of SecureSphere. For
example, when an HTTP Service object is created, SecureSphere automatically creates a Default Web Application
20

object underneath it. However, if several HTTP Service objects are created, there will be multiple Web application
objects all named “Default Web Application” which can lead to confusion.
©

Note
It is an Imperva best practice to rename all Default Web Application objects to unique names that correspond
with the protected Web assets.

© 2017 Imperva, Inc. All rights reserved 3-1 Lesson 3: Web Application Level Preparations
SecureSphere 12.0 Web Application Security Course Manual

Renaming a Default Web Application

To rename a Default Web Application object, follow the steps outlined below:
1. From Veda Client, Login to SecureSphere, and select Main > Setup > Sites.
2. From the Sites Tree navigation pane, expand the relevant Site object and select the desired Default Web
Application.

.
ed
rv
se
re
3. From the Web Application window, select the Definitions tab and locate the Name field.

s
ht
ig
lr
Al
c.
In
a,

4. Enter a new name in the Name field and click to save your changes.
rv

5. Verify the name is updated by checking the full name across the top of the Web Application window.
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 3-2 Lesson 3: Web Application Level Preparations
SecureSphere 12.0 Web Application Security Course Manual

Note
Although the name change has been saved, the Sites Tree requires a page reload to display the change. The value
showing at the top of the Web Application window shows the current value.

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20

(Continued on next page)

©

© 2017 Imperva, Inc. All rights reserved 3-3 Lesson 3: Web Application Level Preparations
SecureSphere 12.0 Web Application Security Course Manual

Determining When to Create Additional Web Application Objects

It is common for Web servers to host multiple Web applications. It is possible to create a separate Web Application
in SecureSphere for each hosted application on the protected server. However, this is not necessarily the best
option because it will also add maintenance and tuning overhead for the overall SecureSphere deployment.

A more nuanced strategy is often better. Review the existing applications and group them by the sensitivity of the
data involved, the underlying technology of the Web application, and the purpose of the Web application. If several

.
ed
applications have a similar level of sensitivity, common technology, and a similar purposes, they would be excellent
candidates to share a common Web Application object in SecureSphere.

rv
The following table shows an analysis of the SuperVeda Web environment, including future planning.

se
Web Application Purpose Sensitivity Data Types Technology Possible Grouping

re
VedaAdmin SuperVeda Admin Portal Very High PW Custom ASP App 1
SuperVeda E-commerce Website High PW, PII, PCI Custom ASP

s
ht
SuperVeda-2.0 App 2
E-commerce Website High PW, PII, PCI Custom ASP
(future)

ig
Customer Forum
Forum / Social Low lr PW, PII WordPress App 3
(future)
Al
Table 3-1 - Categorizing Web applications for protection

From this analysis, all SuperVeda Web applications could be protected with three SecureSphere Web Application
c.

objects.
In

If many applications will be protected but only a few handle sensitive information it may be helpful to only create
a,

application objects for the sensitive applications. The remaining non-sensitive applications can will use the Default
Web Application which will simplify management of those applications.
rv

Creating and Configuring Additional Web Applications Objects

pe

To create additional Web Application objects under a single HTTP Service object, follow the steps below:
Im

1. Select Main > Setup > Sites.

2. Expand Site, expand the Server Group, and Select HTTP Service object.
17
20
©

3. With the HTTP Service object selected, click the Create button, the Create Application dialog will appear.

© 2017 Imperva, Inc. All rights reserved 3-4 Lesson 3: Web Application Level Preparations
SecureSphere 12.0 Web Application Security Course Manual

4. Name the Web application object something different from your prior Web Application object and click Create.

5. Verify the new Web Application has been created.

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 3-5 Lesson 3: Web Application Level Preparations
SecureSphere 12.0 Web Application Security Course Manual

Directing Web Traffic to the Relevant Web Application Objects

With more than one Web Application under a particular HTTP Service object, SecureSphere needs information on
how traffic should be directed between the Web Application objects. This is defined at the HTTP Service level of the
Sites Tree with the Host/URL to Application Mapping setting.

Configuring Host/URL to Application Mapping

.
To configure the Host/URL to Application Mapping setting, follow the steps below:

ed
1. Select Main > Setup > Sites.

rv
2. Expand the Site down to the HTTP Service object.

se
re
s
ht
ig
lr
3. On the HTTP Service window, select the Applications tab.
Al
c.
In
a,
rv
pe
Im
17

4. From the Host/URL to Application Mapping area, click the Create button to add a new row to the mapping
20

table.
©

© 2017 Imperva, Inc. All rights reserved 3-6 Lesson 3: Web Application Level Preparations
SecureSphere 12.0 Web Application Security Course Manual

The Host/URL to Application Mapping feature supports precise matching conditions. However, it is sufficient to begin
with a simple matching setting. For example:

.
ed
Parameter Value

rv
Priority 1

se
Host admin.superveda.local

re
Host Match Type Exact

Include URLs <BLANK>

s
Exclude URLs <BLANK>

ht
Application VedaAdmin – Web Application

ig
lr
Al
c.
In
a,
rv

5. Once you have entered your desired parameters and values, click to save your changes.
pe
Im
17
20
©

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 3-7 Lesson 3: Web Application Level Preparations
SecureSphere 12.0 Web Application Security Course Manual

Adjusting Initial Learning Thresholds

SecureSphere ships with learning thresholds which are global settings that define the duration, accuracy, or number
of events required to complete the learning process. The default values may be overly aggressive for some
environments and may not provide a sufficient learning period for larger Web applications. Adjusting the settings
based on the approximate size of the application and the volume of client activity is an Imperva recommended best
practice.

.
Switching to “Protect” Mode Thresholds (Web)

ed
The global learning threshold settings are located in the Admin Workspace under Admin > System Definitions.

rv
se
re
Figure 3-1 - Selecting Admin > System Definitions in the SecureSphere Web Interface

Note

s
ht
Viewing and adjusting these settings will a SecureSphere user account with administrator privileges. Depending on

ig
the account permissions, it be necessary to work with the SecureSphere administrators for the following settings.
lr
From the System Definitions pane, expand the Dynamic Profile folder and select the Switching to “Protect” Mode
Al
Thresholds (Web).
c.
In
a,
rv
pe
Im

Figure 3-2 - Selecting Switch to "Protect" Mode Thresholds (Web)

17
20

The following screenshot shows the default settings.

©

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 3-8 Lesson 3: Web Application Level Preparations
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
Figure 3-3 - Switching to "Protect" Mode Thresholds (Web)

The Imperva Best Practice recommendation for Web application Switching to “Protect” Mode Thresholds (Web) are

re
as follows:
Threshold Setting Recommended Default

s
Duration (in hours) required to switch all Cookies to protect or ignored mode

ht
720 (hrs.)
Duration (in hours) required to switch all URLs to protect mode

ig
Table 3-2 - Imperva Best Practice – Duration in Hours for Switching To "Protect" Mode Thresholds (Web)
lr Protected Application Size
Al
Threshold Setting Small Medium Large and Highly
Active
c.

Minimum occurrences required to switch a cookie into protect mode

2000 5000 10000
Number of occurrences required to determine if a parameter is read-only
In

Table 3-3 - Imperva Best Practice – "Occurrences" settings for Switching to "Protect" Mode Thresholds (Web)
a,

Note
rv

For this class, any remaining threshold settings should be left with their default values.
pe
Im

Adjusting the threshold settings outside class can be easily done by entering the desired values in the fields of the
Switching to “Protect” Mode Thresholds (Web) window and clicking Save.
17
20
©

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 3-9 Lesson 3: Web Application Level Preparations
SecureSphere 12.0 Web Application Security Course Manual

Review Questions
1. Give two reasons for renaming the default Web application.

Exercises

.
Exercise 1: Rename the Default Web Application

ed
Instructions: For the SuperVeda – Http – Service, rename the Default Web Application object.

rv
Original Name New Default Web Application

se
New Name SuperVeda – Web Application

re
Follow the steps outlined below:

1. Select Main > Setup > Sites.

s
2. From the Sites Tree navigation pane, expand the SuperVeda Site object and select Default Web Application.

ht
ig
lr
Al
c.
In

3. From the Web Application window, select the Definitions tab and locate the Name field.
a,
rv
pe
Im
17
20

4. Enter the new Name SuperVeda - Web Application and click to save your changes.
5. Verify the name is updated by checking the full name across the top of the Web Application window.
©

© 2017 Imperva, Inc. All rights reserved 3-10 Lesson 3: Web Application Level Preparations
SecureSphere 12.0 Web Application Security Course Manual

Exercise 2: Create and Configure an Additional Web Application

Instructions: The SuperVeda Administrative pages should be secured with separate Web application object.
Under the SuperVeda – Http – Service create an additional Web Application object.
Name: VedaAdmin – Web Application.

Follow the steps below to create the object:

.
1. Select Main > Setup > Sites.

ed
2. Expand the SuperVeda Site to the SuperVeda – Http – Service object and select it.

rv
se
re
s
ht
ig
3. With the SuperVeda – Http – Service selected, click the Create button, the Create Application dialog will
appear.
lr
Al
4. Name the application VedaAdmin – Web Application and click Create.
c.
In
a,

5. Verify the new Web Application has been created.

rv
pe
Im
17
20
©

Exercise 3: Direct Web Traffic to the Relevant Web Application Object

Instructions: With more than one Web Application under a SuperVeda HTTP Service, SecureSphere needs
information on how traffic should be directed between the Web Application objects VedaAdmin and SuperVeda.
Reminder: This is defined at the HTTP Service level of the Sites Tree with the Host/URL to Application Mapping
setting. Follow the steps below to configure this:

© 2017 Imperva, Inc. All rights reserved 3-11 Lesson 3: Web Application Level Preparations
SecureSphere 12.0 Web Application Security Course Manual

1. Select Main > Setup > Sites and expand the SuperVeda Site down to the SuperVeda – HTTP – Service object.

.
ed
rv
2. On the HTTP Service window, select the Applications tab.

se
re
s
ht
ig
lr
Al
c.

3. From the Host/URL to Application Mapping area, click the Create button to add a new row to the mapping
In

table.
a,
rv
pe
Im

4. Under the SuperVeda – Http – Service, configure the Host/URL to Application Mapping.
a. Set the Default Application.
17

Parameter Value
20

Default Application SuperVeda – Web Application

©

b. Create a mapping for the SuperVeda administrative portal, admin.superveda.local

© 2017 Imperva, Inc. All rights reserved 3-12 Lesson 3: Web Application Level Preparations
SecureSphere 12.0 Web Application Security Course Manual

Parameter Value
Priority 10
Host admin.superveda.local
Host Match Type Exact
Included URLs <BLANK>
Excluded URLs <BLANK>
Application VedaAdmin – Web Application

.
ed
c. Create a mapping for the SuperVeda website.
Parameter Value

rv
Priority 20

se
Host www.superveda.local
Host Match Type Exact

re
Included URLs <BLANK>
Excluded URLs <BLANK>

s
Application SuperVeda – Web Application

ht
5. Click to save your changes.

ig
Exercise 4: Configure Initial Learning Thresholds lr
Al
Instructions: From the Admin Workspace configure the initial learning thresholds with the following, non-standard,
settings in the tables below.
c.
In

Important
a,

The following settings are specific to the SuperVeda lab and are not guidelines for any other environments.
rv

Threshold Setting SuperVeda Lab Setting

pe

Duration (in hours) required to switch all Cookies to protect or ignored mode
12 (hrs.)
Duration (in hours) required to switch all URLs to protect mode
Im

Threshold Setting SuperVeda Lab Setting

17

Minimum occurrences required to switch a cookie into protect mode

10 (Verify)
Number of occurrences required to determine if a parameter is read-only
20
©

© 2017 Imperva, Inc. All rights reserved 3-13 Lesson 3: Web Application Level Preparations
SecureSphere 12.0 Web Application Security Course Manual

Answers to Review Questions

1. Give two reasons for renaming the default Web application.
a. The SecureSphere Web Application Profile learning process is tied to the Application object
b. Unique Web Application Sites Tree objects allow narrow application of specialized security policies.

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 3-14 Lesson 3: Web Application Level Preparations
SecureSphere 12.0 Web Application Security Course Manual

Answers to Exercises

Exercise 1: Rename the Default Web Application

1. From Main > Setup > Sites, expand the SuperVeda Web SG all the way down to the Default Web Application
object and select it.
2. From the Definitions tab replace Default Web Application with SuperVeda Web Application.

.
ed
rv
se
re
s
ht
3. Click to save your changes

ig
lr
Exercise 2: Create and Configure Additional Web Application Objects
Al
1. Select the SuperVeda – Http – Service Sites Tree object.
c.

2. Click Create to create a new application and name the application VedaAdmin – Web Application.
In
a,
rv
pe
Im
17
20

3. Click Create.
©

Exercise 3: Direct Web Traffic to Application Objects

1. Select the SuperVeda – Http – Service object, Applications tab.

© 2017 Imperva, Inc. All rights reserved 3-15 Lesson 3: Web Application Level Preparations
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
2. Set the Default Application

re
s
ht
ig
3. Create a mapping for the SuperVeda administrative portal, admin.superveda.local
lr
Al
c.

4. Create a mapping for the SuperVeda website.

In
a,

5. Click to save your changes

rv
pe

Exercise 4: Configure Initial Learning Thresholds

Im

1. Select Admin > System Definitions.

2. From Dynamic Profiling select Switching to “Protect” Mode Thresholds (Web)
17

3. Set the two “Duration” rules to 12.

20
©

© 2017 Imperva, Inc. All rights reserved 3-16 Lesson 3: Web Application Level Preparations
SecureSphere 12.0 Web Application Security Course Manual

4. Set the two “Occurrence” rules to 10.

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 3-17 Lesson 3: Web Application Level Preparations
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 3-18 Lesson 3: Web Application Level Preparations
SecureSphere 12.0 Web Application Security Course Manual

Web Application Security Policies

Overview
In this chapter, we will explore SecureSphere Security Policies. We will discuss the creation, configuration and
application of Security Policies as well as Security Policy best practices and strategies to address common
deployment goals. We will finish by looking at Security Policy reports, which provides visibility into the active policies

.
and support compliance review processes.

ed
Objectives

rv
se
At the end of this lesson, you will be able to:

• Given different types of Web attacks, configure appropriate polices to defend Web applications.

re
• Review Action Set policies from the system administrator, and create new Action Set policies as needed.
• Use Action Set policies in the followed actions of the subsequent Security Policies, as needed.

s
• Configure and apply signature policies to defend Web applications from attacks with easily recognizable

ht
signatures.

ig
• Configure and apply protocol policies to defend Web applications from protocol attacks.
• Configure and apply correlation policies to protect against multi-front Web attacks.
•
lr
Configure and apply custom Web policies to protect specific application weaknesses.
Al
• Configure and apply ThreatRadar policies to protect against advanced Web attacks, and the latest Web attacks.
• Explain the factors that determine when to use modify a built-in policy, and when to create a copy of a built-in
c.

policy and modify it instead.

• Create policy configuration reports.
In

Introduction to Security Policies

a,
rv

A Security Policy is a set of rules that identify concerning Web traffic and the actions to take in response. Security
Policies are located in Main > Policies > Security.
pe
Im
17

Figure 4-1 - Main > Policies > Security

20

The Security window has three panes:

• Filter Pane – Filters available policies

©

• Policies List Pane – Lists all policies matching the current filter
• Policy Details Pane – Shows the settings for the currently selected Security Policy

© 2017 Imperva, Inc. All rights reserved 4-1 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
Figure 4-2 - Security Policy Panes

re
Security Policies consist of one or more Rules. Policy Rules are definitions of concerning activity that will be matched
during the inspection process. For policies consisting of just a single rule, the rule definition is a collection of Match
Criteria. A Match Criteria defines the search pattern for a specific aspect of inspected traffic. Match Criteria will be

s
covered in more detail in the Custom Web Application Policies section later in this lesson.

ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17

Figure 4-3 - Security Policy showing Rules and Responses

SecureSphere contains an expansive set of predefined policies that provide protections against the majority of
20

known attacks and threats. During the initial configuration, a set of the predefined policies are automatically
applied, providing a baseline of security for protected Web applications. Many predefined policies are maintained
©

and updated by the Imperva Application Defense Center (ADC) team. These ADC based policies only allow limited
modifications and can be identified by the ADC emblem shown here:

Figure 4-4 - ADC Logo Indicating Limited Changes

© 2017 Imperva, Inc. All rights reserved 4-2 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

While the baseline security provides an excellent starting point for securing Web applications, additional ADC
policies and custom security policies can be applied in order to protect advanced Web application or to address
specific business concerns.

Client and Server Interactions

To fully understand the Web Security Policies, it is important to be familiar with the process of client to server
communications for HTTP traffic. When someone clicks a hyperlink in their browser, the browser opens a network

.
connection to the Web server and sends an HTTP request like the following example.

ed
GET /homepage.asp HTTP/1.1

rv
Host: www.superveda.local

se
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5

re
Accept-Encoding: gzip, deflate
Referer: http://www.superveda.local/

s
ht
Table 4-1 - Client HTTP Request

ig
The first line shows the HTTP request method, the URL, and HTTP version. The remaining lines begin with the HTTP
request headers. Request headers provide additional details about the client and browser that can be useful to the
lr
Web server.
Al
When the Web server receives an HTTP request from the client, it processes the request and returns the relevant
c.

Web page in an HTTP response.

In

HTTP/1.1 200 OK
Cache-Control: no-cache,private
a,

Content-Length: 1687
Content-Type: text/html
rv

Server: Microsoft-IIS/8.5
Set-Cookie: ASPSESSIONIDCSSBRBAA=ICOLBCEAKPMCOKLAANDFMBFE; path=/
pe

Date: Thu, 03 Sep 2015 17:32:37 GMT

Im

<html>
<head>
17

<title>Super VEDA</title>
…
20

Table 4-2 - Server HTTP Response

The top line of the response gives the response status including the server response code of 200. The response code
©

is a three digit number provided by the Web server that identifies the results of processing the client request and
indicates if problems occurred while trying to deliver the page.

(continued on next page)

© 2017 Imperva, Inc. All rights reserved 4-3 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

Code Description
1XX Informational
2XX Success
3XX Redirection
4XX Client Error
5XX Server Error
Figure 4-5 - HTTP Server Response Codes

.
ed
The server response headers start at the second line and continue to the blank line. Response headers provide
information about the returned data, are used by the browser for displaying the Web page, and manage the user’s

rv
activity within the Website. The HTTP data is visible after the two blank lines. This is the information parsed by the
browser and turned into a user-friendly Web page.

se
As we explore Security Policies in more depth, we will examine aspects of the client to server communication

re
process. The terminology in the table below will be helpful in these discussions.
Term Description

s
Web traffic Web traffic is any HTTP traffic between client and server.

ht
Web or HTTP request Web or HTTP request is an HTTP request originating from the client and directed to

ig
the Web server.
Web or HTTP response Web or HTTP response is an HTTP response from the server, returning with the
lr
results of processing the client HTTP request.
Al
Event or Web event An Event or Web event is a single HTTP request or HTTP response. In general,
events should be inspected by the SecureSphere Gateway.
c.

Security Event Security Events are events that matches SecureSphere Security Policy rules.
Violation A Violation is a Gateway generated message, created when an event matches a
In

Security Policy rule. The violation is created by the Gateway and passed to the
Management Server for logging.
a,

HTTP and HTTPS HTTP and HTTPS identify un-encrypted and encrypted Web communications,
rv

respectively. In SecureSphere, the use of HTTP generally represents both HTTP and
HTTPS traffic except when HTTPS is specifically mentioned in the same context.
pe

Table 4-3 - Common Terminology

Im

Web Application Security Policy Types

17

Web applications present a broad attack surface for cybercriminals. Web applications often contain hundreds or
thousands of vulnerabilities, some of which may be totally unknown to the application owners. Some vulnerabilities
20

may be exploited in more than one way. Combined, the vulnerabilities and possible exploits are the attack surface.
SecureSphere addresses this challenge with a broad set of default, predefined and custom security policies and are
organized by policy type and by level they are applied in the Sites Tree.
©

Some policy types only allow single instance of the policy to be applied on a given Sites Tree object while other
policy types allow multiple instances on the same Sites Tree object. One example is the Firewall Policy which is a
single instance policy. The Firewall Policy allows the Gateway to enforce basic network firewall rules. Allowing two
firewall policies for the same Sites Tree object would be confusing and not benefit because the inspection is being
performed by just one Gateway. For this reason, the Firewall Policy is a single instance policy.

© 2017 Imperva, Inc. All rights reserved 4-4 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

The Sites Tree structure and Security Policies reflect the traffic inspection process. When traffic arrives at the
SecureSphere gateway the inspection process begins with network level analysis. When the network level inspection
is complete, the inspection continues with the HTTP payload. The final level of analysis is application aware, taking
the unique structure of the protected Websites into account. The SecureSphere Site Tree objects, and
corresponding analysis, broadly mirror the Open Systems Interconnection Reference Model (OSI Model).

.
Data Unit OSI Layer SecureSphere Objects

ed
7+ Custom Application Web Application

rv
7 Application

se
HTTP Data 6 Presentation HTTP Service
Site

re
5 Session

Segments 4 Transport

s
Server Group

ht
Packets 3 Network

ig
Frames 2 Data link

Bits 1 Physical
lr
Al
Table 4-4 - OSI+1 Network Model and the SecureSphere Sites Tree
c.

Two significant differences exist between the OSI Model and the SecureSphere Sites Tree levels. The first and most
significant difference is in OSI layer 7 application traffic. In the OSI Model the application level represents traffic
In

belonging to a named protocol like SMTP, FTP or HTTP. However, inspecting just to the protocol level leaves out
attacks specific to the Web application. For an example of an application specific attack, consider an insurance
a,

Website being slowed by an attacker repeatedly requesting a price quote to create latency for legitimate customers.
rv

Another example could be an attacker trying to invalidate an online poll where an individual stuffs the ballet by
repeatedly submitting an unpopular answer. In SecureSphere the Web Application Sites Tree object represents a
pe

specific protected Web application, or Website, with unique URLs, pages, logins, forms, etc. At Imperva, we refer to
a Seven Plus-One OSI Model, where the additional layer represents a specific Custom Application that is being
Im

protected.

The second difference between the OSI Model and the SecureSphere Sites Tree is subtle. In the OSI Model network
17

ports, like Port 80 for HTTP and 443 for HTTPS, are part of the TCP/IP Packet and belong in OSI layer 3. However, in
SecureSphere the network port is part of the HTTP Service object.
20

The mapping between the OSI Model and The SecureSphere Sites Tree may be useful when trying to determine the
©

level at which a Security Policy is applied. For example, knowing that the Firewall Policy performs network level
analysis, OSI layer 3, helps identify that the Firewall Policy is assigned at the Server Group level. For another
example, consider a policy designed to identify abnormal HTTP requests. The policy is applied at the HTTP Service
level of the Sites Tree, which corresponds to OSI layer 7. For a final example, consider a policy inspecting repeated
submissions to an online forum. Since this policy would require the ability to identify a specific Web page, it would
be applied at the Web Application level and doesn’t have a corresponding OSI level.

© 2017 Imperva, Inc. All rights reserved 4-5 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

The following tables list the available policy types, the instances allowed per Sites Tree object, and a brief
description of the policy purpose.

Sever Group Level Security Policies Instances Description

Policy provides basic firewall functionality. Blocking
Firewall Policy Single
requires that the gateway is deployed inline.
Validates proper use of the TCP/IP Protocol according to
Network Protocol Validation Single
the RFC standard.

.
ed
Stream Signatures Multiple Identifies well know attacks for generic services
Table 4-5 - SecureSphere Sever Group Level Security Policy Types

rv
HTTP Service Level Security Policies Instances Description

se
Validates proper use of the HTTP protocol according to the
HTTP Protocol Validation Single
RFC standard

re
Web Service Correlated Validation Single Protects against multi-stage Web application attacks
HTTP Protocol Signatures Multiple Protects against known protocol attacks using signatures

s
Enables creating user-defined Web service level policies

ht
Web Service Custom Multiple
based on various combinations of Match Criteria

ig
Enables cookie signing and verification. Only used with
Cookie Signing Validation Single
reverse proxy deployments.
lr
Table 4-6 - SecureSphere HTTP Service Level Security Policy Types
Al
Web Application Level Security Policies Instances Description
c.

Account Takeover Several advanced policies based on ThreatRadar which

provide protection for complex account takeover tactics:
In

• Credential Stuffing
• Device Intelligence (Client Device Inspection)
a,

• Dictionary Attack (Weak password attacks)

• Privileged Account Brute Force
rv

Anti-Scraping Multiple Identified scraping events in which someone is attempting

to "scrape" data from Web pages.
pe

Bot Mitigation Multiple Identifies bot attacks meant to cause Denial of Service and
other automated attacks.
Im

Captcha - Activity Based N/A The Captcha policies complement existing Threat Radar
Bot Protection analysis and will be discussed in the
ThreatRadar Policy. Note: 11.5 Captcha - Activity Based
17

policy is disabled by default.

Captcha - Event Based Multiple The Captcha policies complement existing Threat Radar
20

Bot Protection analysis and will be discussed in the

ThreatRadar Policy.
Fraud Prevention Services Multiple Works together with third party vendors to determine if
©

devices connecting to the network are compromised.

Then determine policies for handling problematic traffic.
OCSP Protocol Validation Single Verifies the revocation status of X.509 digital certificates.
This assists Web infrastructure including servers and
Internet browsers in determining if a Web site certificate is
valid, has been revoked, or if its status is unknown.

© 2017 Imperva, Inc. All rights reserved 4-6 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

(Continued)
Web Application Level Security Policies Instances
Description
Threat Radar Bot Protection Single
Multistep analysis policy to categorize clients. For example
a client can be identified as human, Crucial Bots (i.e.
search engines), Bad Bots (Known to be Malicious) and
unknown.
Web Application Custom Multiple Enables creating of user-defined Web application level
policies based on various combinations of the Match
Criteria

.
ed
Web Application Signatures Multiple Protects against known application attacks using
signatures
Web Profile Single Alerts on and prevents the application user behavior that

rv
deviates from the Application Profile, as defined in

se
SecureSphere
Web Worm Single Provides protection for zero day Web worms based on
Imperva unique technology

re
Table 4-7 - SecureSphere Web Application Level Security Policy Types

s
Security Policy Responses

ht
ig
The wide collection of policy types allows for detailed analysis over all aspects of the Web traffic but without an
effective response these policies would be useless. Fortunately, SecureSphere Security Policies also provide detailed
lr
response options when policy violations occur. The policy response options are threefold. First, the violating event
Al
will be assigned a severity which will be visible in the Alerts and Violations logs. Second, an immediate block action
can be triggered, which will prevent the offending request from getting through. Finally, additional actions can be
triggered with Followed Actions setting that will be discussed shortly.
c.
In
a,
rv
pe
Im
17
20
©

Figure 4-6 - Identifying Rules and Responses in Security Policies

© 2017 Imperva, Inc. All rights reserved 4-7 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
Figure 4-7 - Security Policy Responses - Severity, Action and Followed Action

Response Type Values Purpose

s
High

ht
Medium

ig
Severity Low Assigned to violation and appears in security event logs.
Informational
No-Alert
lr
Al
None Determines if the event violating the policy rule will be blocked by
Immediate Action
Block SecureSphere.
c.

Followed Actions allow additional responses after the violation

Various /
Followed Actions occurs and are used for notification, timed blocking or timed
In

User- Defined
monitoring of the client that generated the violation.
a,

Table 4-8 - Security Policy Responses

rv
pe
Im
17
20
©

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 4-8 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

Important
Blocking requires the Server Group’s Operation Mode be set to Active.

.
ed
rv
Figure 4-8 - Sever Group Operation Mode set to Active

se
During the initial setup the Server Group’s Operation Mode will be Simulation and blocking will not occur.

re
s
ht
ig
Figure 4-9 - Server Group Operation Mode set to Simulation lr
Al
Policy rules with a Block action and triggered by a security event, while the Server Group is in Simulation Mode,
will be logged as an Immediate Block (Simulation Mode) to indicate the rule was triggered but the block was not
c.

enforced.
In

Action Interfaces, Action Sets, and Followed Actions

a,

Action Interfaces are objects that define actions that SecureSphere can take when specific conditions or events
rv

occur. Action Sets are a type of policy that contain one or more Action Interfaces. Parameters that are not explicitly
configured in the Action Interface definition are configured in the Action Set. Followed Actions define when to
pe

implement Action Sets, and trigger after events such as a policy violation.
Im

Action Interfaces
Action Interfaces define parameters that allow SecureSphere to take action in response to specified events. They are
17

configured in Admin > System Definitions, under Management Server Settings > Action Interfaces. The system
administrators will configure action interfaces during the initial setup of SecureSphere.
20

Action Sets
©

Action Sets are policies that contain one or more Action Interfaces. Configure Action Sets from Main > Policies >
Action Sets. If an Action Interface has specific parameters defined, such as an SYSLOG Host, they cannot be changed
in the Action Sets. The Action Interface parameters which are undefined are user editable and will need to be
configured to complete the Action Set. The folowing image illistrates the defined Syslog Host parameter and the
remaining undefined parameters.

© 2017 Imperva, Inc. All rights reserved 4-9 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
Figure 4-10 - A New SYSLOG Action Set using the Server System Log > Log to System Log (syslog) Action Interface

se
Note

re
If the available Action Interfaces are not sufficient, work with the SecureSphere administrators to for changes or

s
new Action Interfaces.

ht
Placeholders

ig
Placeholders are identifiers that will be replaced by the corresponding information from the violating event, which
lr
enables security administrators include relevant information in the Action Interface messages. Placeholders begin
with a dollar sign, and are enclosed by rounded brackets – sometime called curly braces – like this: ${}
Al
See the Message field in the image of the syslog Action Set below for an example of Placeholders.
c.
In
a,
rv
pe
Im

Figure 4-11 - Syslog Action Interface Showing Message Placeholders

17

Note
20

By default, if a placeholder in a message does not have a value from the system, then the placeholder itself is sent
as raw text. For example, if the Username placeholder (${Alert.username}) is part of the message, and there is no
©

username in the alert, then the message will show ${Alert.username} instead of the username.

To hide the placeholder instead of sending the placeholder’s name as raw text, include an exclamation point
immediately after the dollar sign. For example, enter the above placeholder as $!{Alert.username} to prevent
${Alert.username} from appearing when the username is not contained in the alert.

© 2017 Imperva, Inc. All rights reserved 4-10 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

Tip
You may want to enclose each parameter with its string within identifiers such as a comma (,), colon (:) or any
other character to later parse this information and extract specific items. This indicates to a script or a parser
where value start and end.

See the Placeholders index in the Web Application Firewall User Guide and SecureSphere Online Help for a
complete list of placeholders and further information on using Placeholders in SecureSphere.

.
ed
Followed Actions

rv
Followed Actions define when to implement Action Sets. Followed Actions are configured in places where
SecureSphere can take additional action in response to an event, such as responding to a policy violation (configure

se
the Followed Action in the Policy) or after a scheduled job, such as running an MX backup, completes (configure in

re
Admin > Jobs Status, then configure the job’s Followed Action tab). Followed Actions are not always labeled with the
more generic, Followed Action; however, the word Action is present, such as Audit syslog action.

s
Tip

ht
Configuring Followed Actions for sending notifications of high severity violation events to established incident

ig
management systems helps reduce administrative overhead while improving incident response times.
lr
Action Sets for Web Application Security Policies
Al
For Web Application Security Policies, notification and blocking System Events will be needed. SecureSphere ships
c.

with several predefined Action Sets which will provide the blocking Action Sets required initially. During the initial
In

setup, the system administrators will also create several Action Sets which will provide a good starting place for the
notification Followed Actions.
a,

SecureSphere has four Action Interfaces types usable for notifications: Email, SYSLOG, SNMP Traps, and Remedy –
rv

Create Incident. Organizations with an existing Security Information Management (SIM) system, or a Security
Information and Event Management (SEIM) system, will typically use SYSLOG Action interfaces or, when supported,
pe

SNMP Traps Action Interfaces.

Im

Note
Predefined SYSLOG Action Interfaces are available to assist with integration to HP ArcSight and RSA Envision, as
17

well as any SIEM that supports those message formats.

20

By default, notification action interfaces will only generate a single notification when the violation first occurs. This
can be controlled with the Run on Every Event setting. In most cases, Run on Every Event should be selected with
SYSLOG and SNMP Trap Action Interfaces. SYSLOG servers are designed to handle high frequency events.
©

(Screenshot on next page)

© 2017 Imperva, Inc. All rights reserved 4-11 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

.
ed
Figure 4-12 - Run on Every Event selected for SYSLOG Action Interface

rv
For email notifications, leave Run on Every Event unselected. It is very easy to overload an email inbox with

se
notification emails when an automated attack occurs like a Website vulnerability scan, or a hacker attempts a
password brute-force attack. In both cases thousands of emails could be generated in under a minute.

re
s
ht
ig
lr
Al
c.
In
a,
rv
pe

Figure 4-13 - Run on Every Event unselected for Email Action Interface
Im

Note
17

When first setting up an email Action Interface, selecting Run on Every Event is helpful when verifying email
delivery. Just remember to unselect this once successful email delivery is confirmed.
20

Creating Action Sets for Web Application Security Policies

©

The following table shows the Action Sets in the SuperVeda environment after the initial configuration of
SecureSphere. The Action Sets that are suitable for Web Application Security Policies are indicated in bold-italics.
The origin column indicates whether the Action Set is predefined or created by the SuperVeda system
administrators.

© 2017 Imperva, Inc. All rights reserved 4-12 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

Action Set Type Origin

Default Archive Action Set Archiving
Email Data Owner Portal Reviewer Security Violations - File Application Level
Long IP Block Security Violations - All SecureSphere
Long Session Block Security Violations - Web Service Level
Long User Block Security Violations - Service Level
SV - Archive MX Backups Archiving

.
SV - Archive Reports Archiving

ed
SV - Email Security Admin Any Event Type
User Defined

rv
SV - Failed SecureSphere admin Login System Events
SV - Send System Event to syslog System Events

se
SV - Send to VedaDB syslog Any Event Type
Send Email to Blocked SharePoint User Security Violations - SharePoint Application Level

re
Send Email to Data Owner Security Violations - File Application Level
Short IP Block Security Violations – All

s
SecureSphere

ht
Short Session Block Security Violations - Web Service Level
Short User Block Security Violations - Service Level

ig
Terminate Session Security Violations - DB Service Level

Figure 4-14 - SuperVeda Lab Configured Action Sets

lr
Al
If available Action Sets are not sufficient, a custom action set can be created as follows:
c.

1. Select Main > Policies > Action Sets.

In
a,
rv

2. In the Select section, click the Create button. The Action Set window opens.
3. Enter the name, SV - Violation - SYSLOG and Email Security Admin.
pe

4. Select Apply to Event Type: Security Violations –Web Service Level.

Im
17
20
©

5. Click Create.
6. In Available Action Interfaces, click the Move Up button next to the Server System Log > Log to System
Log (syslog). Server System Log > Log to System Log (syslog) moves up to Selected Actions.

© 2017 Imperva, Inc. All rights reserved 4-13 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

(Screenshot on next page)

.
ed
rv
se
re
s
ht
7. In Available Action Interfaces, click the Move Up button next to the Email > Sen an Email. Email > Send
an Email moves up to Selected Actions.

ig
lr
Al
c.
In

8. Expand Server System Log > Log to System.

9. Enter the name, SV - Violation – Send to VedaDB Syslog. Note, the Syslog Host is not configurable here as it
a,

was previously defined by the system administrators.

rv

10. Set the Syslog Log Level to, WARN.

11. Set the Message to, $!{Alert.severity},$!{Alert.alertType},$!{Alert.description}.
pe

12. Set Facility to, Local0.

13. Select Run on Every Event.
Im
17
20

14. Expand Email > Send an Email.

©

15. Enter the name, SV - Violation – Email Security Admin. Note the SMTP Server Address is not configurable
here as it was previously defined by the system administrators.
16. Set the From Address to, [email protected].
17. Set the To Address to, [email protected].
18. For the Email Subject, leave Use Default selected.
19. For the Email Body, Unselect Use Default.

© 2017 Imperva, Inc. All rights reserved 4-14 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

20. Click the button. The Choose Content window will appear.

21. Select Type: Alerts and Format: Text.

.
ed
rv
se
22. Click OK. The pop-up will close.
23. For Email Format, select Text.

re
24. Select Run on Every Event. Note, during normal usage, Run on Every Event would be unselected for email
Action Interfaces. However, during setup and testing, it can be selected. When testing is complete, it

s
should be unselected.

ht
ig
lr
Al
c.
In
a,
rv

25. Click Save.

pe

This completes the preparation for working with the initial Security Policies. The custom action set and previously
defined action sets are now ready for use as we work through the Security Policies.
Im

SecureSphere Default Behavior

17

SecureSphere traffic inspection differs from other common security systems in two important ways.
20

1. When un-configured, SecureSphere allows all traffic without any blocking or logging. Contrast this with the
typical default behavior of network firewalls, which may block all inbound traffic by default.
2. Traffic being inspected is tested by all applied Security Policies, for the relevant site tree objects, and when
©

a blocking policy rule is triggered inspection continues with the remaining policies applied at the same level
of the sites tree.
These default behaviors provide several benefits. The first point ensures traffic inspection is limited to specifically
configured systems. It provides flexibility for the deployment process and allows the security team to focus on the
most critical Web applications first, without fear of impacting access to other Web applications. The second point
allows for multiple policies to work together effectively. For Example, a client event may trigger two separate

© 2017 Imperva, Inc. All rights reserved 4-15 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

policies. The first policy may have a block action and the request will be blocked. However the second policy may
have both a block action, plus a followed action that will generate a notification of the event.

Security Policies Filters

Due to the large number of predefined policies, becoming familiar with the applied and available policies may take
some time. When working with policies, the policy filters are particularly useful for finding relevant policies.

.
ed
Finding the right policy with the Basic filter:
Policy Basic Filter Description Policies Displayed

rv
By ADC Keyword Enables filtering policies according to the predefined categories Applied & Un-applied
to present the following industry standards: EBS, HIPPA, PCI,

se
PeopleSoft, SAP, SOX.
By Type Presents policies according to policy types Applied & Un-applied

re
By Level Displays all policies assigned to the Network / Sever Group level, Applied & Un-applied
or the Web Service or Application levels of the Sites tree.

s
By Server Group Presents all the server groups in the alphabetical order and Applied Only

ht
enables you to view policies applied to the selected server

ig
group.
By Service Presents all the services in the alphabetical order and enables Applied Only
lr
you to view policies applied to the selected service.
Al
By Application Presents all the applications in the alphabetical order and Applied Only
enables you to view policies applied to the selected application.
c.

Default Policies Presents all default policies available in SecureSphere. Policies applied by
Default
In

Policy Origins Identifies the policies based on the policy creator. Used to Applied and Un-applied
quickly find ADC, User Defined or System defined policies
a,

Table 4-9 - Policy Basic Filters Explained

rv

From Main > Policies > Security, the Basic filter is on the left.
pe
Im
17
20
©

Figure 4-15 - Security Policies Basic Filter

© 2017 Imperva, Inc. All rights reserved 4-16 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

If the Basic Filter is not showing it has been hidden with the Filter hanging tab, as can be seen in the following figure

.
ed
rv
se
Figure 4-16 - Security Policy Filter Hanging Tab

The Basic Filter tab displays the available filters, which is expanded to see available filter criteria. The filter is defined

re
by selecting the relevant criteria. In the following example, the filter will display Web - Service Level - HTTP Protocol
Signatures policies:

s
ht
ig
lr
Al
c.
In
a,
rv
pe

Figure 4-17 - Example Basic Filter for HTTP Protocol Signatures Policies

The chosen filter must be applied with the Apply button:

Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 4-17 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
Figure 4-18 - Basic Filter Apply Button

ig
Currently applied Filters are indicated with the funnel icon.
lr
Al
c.
In
a,
rv

Figure 4-19 - Applied Filter Indicators

pe

When trying to identify policies that are currently applied the best filter options are the By Server Group, By Service
Im

and By Application. These filters will only show policies actually applied to the selected sites tree objects.

Alternatively, the Sites Tree objects will also list all applied policies on the Applied Policies Tab. From the Main
17

workspace, select Setup > Sites. Then select the relevant Sites Tree object.
20
©

© 2017 Imperva, Inc. All rights reserved 4-18 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
Figure 4-20 - Viewing Policies Applied to Sites Tree Objects

re
Tip

s
The Applied Policies tab will display all policies at the current level and higher levels. The Applied Policies tab for a

ht
Web Application object will show all currently applied Application, Service and Server Group policies.

ig
SecureSphere Web Application Security Policies lr
Al
The following Security Policy types will be used by virtually all SecureSphere Web Application Firewall deployments.

• Signature Policies
c.

• Protocol Validation Policies

In

• Correlation Policies
• Custom Web Service and Custom Web Application Policies
a,

• Web Profile Policies

• ThreatRadar Policies
rv

Note
pe

The Web Profile Policies and ThreatRadar Policies will be discussed in later lessons.
Im

Signature Policies
17

Signature Policies are Security Policies consisting of one or more signature dictionaries. Each signature dictionary
acts as a policy rule. If any signatures within the dictionary match the inspected traffic, the policy response for the
20

dictionary is triggered. SecureSphere provides predefined Signature Policies for the Server Group and HTTP Service
levels. Signature policies are an essential tool in SecureSphere that provide both direct controls over attacks, as well
©

as providing information on the client activity which will be useful for other Security Policies.

Signatures
A Signature is a sequence of characters that define a search pattern. Signatures are similar with Data Dictionaries
discussed earlier. In particular, the signature patterns can contain part= and rgxp= components for simple text

© 2017 Imperva, Inc. All rights reserved 4-19 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

matching and regular expression matching, respectively. SecureSphere regular expressions follow Perl Style regular
expressions with some limitations.

Note
Some advanced features in Perl Style Regular Expressions are not supported by SecureSphere. This is intentional,
to avoid potential performance issues that could be caused by a misbehaving regular expression. If you require
large, complex regular expressions, work with Imperva Professional Services or Imperva Technical Support to
verify the regular expressions can be supported.

.
ed
The following shows the proper format of part= and rgxp= terms within a signature.
Component Example Use Note

rv
part= part="cmd.exe" Will match exact text: cmd.exe

se
Multiple part= allowed
rgxp= rgxp="http[s]?:\/\/localhost[\x2E:\/\s]" Only one rgxp= allowed

re
part= and part="update.php", part="function_dir", Components separated by commas.
rgxp= rgxp="function_dir\s*=" Whitespace allowed around

s
commas.

ht
Table 4-10 - Examples of part= and rgxp= signature components

ig
lr
Signatures can be viewed from Main > Setup > Signatures. The following example shows a signature dictionary
designed to identify path traversal activity, a distinctive behavior that strongly indicates malicious intent. Note the
Al
usage of part= and rgxp=.
c.
In
a,
rv
pe
Im
17
20

Figure 4-21 - Signature example showing part= and rgxp= components

The predefined signature database is maintained by the Imperva ADC team and included in the ADC updates. Each
©

signature is evaluated for performance and accuracy. The Matching Target tab provides information about the
complexity of the attack, the risk posed by a successful attack, and details about the underlying issues on the
targeted system.

The following image, shows the Matching Target tab, which provides details on a WordPress vulnerability signature.

© 2017 Imperva, Inc. All rights reserved 4-20 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
Figure 4-22 – Signature Matching Target tab

re
The Additional Info tab provides information on affected systems, associated bug or vulnerability numbers, and the

s
signature accuracy.

ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17

Figure 4-23 - Signature Additional Info tab

20

Note
It is possible to create custom Signatures when needed. The process will be described in the following section.
©

Signature Dictionaries
A Signature Dictionary is a container holding one or more related signatures. Signature Dictionaries can be viewed
from Main > Setup > Signatures.

© 2017 Imperva, Inc. All rights reserved 4-21 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
Figure 4-24 - Main > Setup > Signatures

se
A Signature Dictionary typically contains signatures grouped first by the risk posed by the attack. This is due to the
structure of Security Policies that will be covered shortly. An example of this can be seen when comparing the

re
signatures in two similar related Signature Dictionaries. For example:

• Recommended for Detection for Web Applications

s
• Recommended for Blocking for Web Applications

ht
These two dictionaries are used to protect Web applications. A quick review of the signatures in the Recommended

ig
for Detection for Web Applications will show they tend to have a risk of Medium. In contrast, the signatures in the
lr
Recommended for Blocking for Web Applications dictionary all have a risk of High.
Al
Signature Policy Types
c.

Signature Policies are Security Policies consisting of one or more signature dictionaries. Each signature dictionary
acts as a policy rule. If any signatures within the dictionary match the inspected traffic, the policy response for the
In

dictionary is triggered. SecureSphere provides predefined Signature Policies for the Server Group and HTTP Service
levels.
a,
rv

Stream Signature Policies

pe

At the Server Group level, the Signature Policies are called Stream Signatures, because the network traffic stream is
inspected.
Im
17
20
©

Figure 4-25 – ADC Stream Signatures Policy Recommended for General Applications

© 2017 Imperva, Inc. All rights reserved 4-22 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

Stream Signature Policies provide similar protections to many Intrusion Prevention Systems (IDS) and packet
inspecting firewalls. Organizations with existing network level protections will still benefit with the addition of
SecureSphere. An additional layer of protection from an independent vendor improves the risk position.

HTTP Protocol Signature Policies

At the HTTP Service level, the Signature Policies are called HTTP Protocol Signatures. These signature policies inspect
the HTTP protocol and identify abnormalities in the Web traffic. The following image show the Recommended
Signatures Policy for Web Applications policy which is automatically applied to new HTTP Service objects.

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In

Figure 4-26 - Recommended Signatures Policy for Web Applications

Note
a,

Notice that many of the Dictionaries are set to No Alert for severity. These Dictionaries contain signatures that will
rv

be leveraged by more advanced policies later.

pe
Im

Creating Custom Signature Policies

17

Creating custom Signature Policies may require the creation of one or more Signature Dictionaries first and creating
custom Signatures.
20

Creating Custom Signature Dictionaries

SecureSphere provides the following methods for creating custom Signature Dictionaries.
©

• Filter Dictionary
• Threat Radar Dictionary – Remote File Include (RFI)
• Manual Dictionary

The Filter Dictionary and Threat Radar Dictionary – Remote File Inclusion (RFI) are both collections of Imperva
maintained signatures. The Manual Dictionary is a fully custom dictionary built from custom signatures.

© 2017 Imperva, Inc. All rights reserved 4-23 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

Creating Filter Dictionaries and ThreatRadar Dictionary – Remote File Include (RFI)
The Filter Dictionary and Threat Radar Dictionary consist of all available ADC Signatures or ThreatRadar RFI
signatures, respectively. The dictionaries are then configured by disabling unwanted signatures.

1. From the Main workspace, select Setup > Signatures.

2. Click the Create button and select Create Filter Dictionary.

.
ed
rv
se
re
s
ht
ig
lr
Al
Note
Creating these custom Signature Dictionaries takes several minutes as the management server creates the new
c.

Signature Dictionary with a copies of all related signatures.

In

3. When the dictionary is ready disable undesired signatures as follows:

a. Select unwanted signatures with the mouse, selecting multiple items with the Shift or Control keys.
a,

b. Right click and select Disable Signatures From This Dictionary Only.
rv
pe
Im
17
20
©

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 4-24 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

c. The status column will show to indicate the signature is disabled and to indicate an enabled
signature.

.
ed
rv
se
re
d. Using the Page Selection, work through the remaining signatures, disabling all undesirable signatures from

s
the current dictionary. Strategic use of the Signature Filter can also speed the process.

ht
ig
lr
Al
c.

e. The Filter Dictionary will be available for use in the Signature Policies.
In

Creating Manual Dictionaries and Custom Signatures

a,

Manual Dictionaries allow the creation of custom signatures.

rv

1. From the Main workspace, select Setup > Signatures.

pe

2. Click the Create button and select Create Manual Dictionary.

Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 4-25 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

3. In the Create New Dictionary window Name the dictionary SuperVeda Manual Signature Dictionary and select
Dictionary Type: Web.

.
ed
rv
se
4. Click Create.

re
5. In the SuperVeda Manual Signature Dictionary - Manual, Web window, click the Create button to create a
custom signature.

s
ht
ig
lr
Al
6. Configure the Add Signature window as follows:
Signature Name: Suspicious Comments.
c.

Signature: part=”IPwnYou”.
In

Protocols: HTTP, HTTPS.

Search Signature In: Headers and URLs and Parameters.
a,
rv
pe
Im
17
20
©

7. Click Create.
8. Add additional Signatures as needed.
The custom Manual Dictionary can now be used with signature Security Policies.

© 2017 Imperva, Inc. All rights reserved 4-26 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

Creating a custom Signature Policy

1. From the Main workspace, select Policies > Security.
2. Above the Policies List, Click the Create button and select Web Service.

.
ed
rv
3. Configure the Create New Policy window as follows:
Name: SuperVeda Custom Signature Policy.

se
Select From Scratch.
Type: HTTP Protocol Signatures.

re
s
ht
ig
lr
Al
c.

4. Click .
5. From the Policy Window, click the Create button. This will add a row to the Dictionaries Table.
In

6. Configure the table as follows:

Dictionary Name: SuperVeda Manual Signature Dictionary.
a,

Select Enabled.
rv

Severity: Low.
Action: None.
pe

Followed Action: SV – Send to VedaDB syslog.

Im
17
20

7. Assign the policy to the SuperVeda HTTP Service object as follows:

a. Select the Apply To Tab.
©

b. Expand SuperVeda Site and SuperVeda Web SG.

© 2017 Imperva, Inc. All rights reserved 4-27 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

(continued on next page)

c. Select the SuperVeda HTTP Service object.

.
ed
rv
se
re
s
ht
8. Click to save changes.

ig
Protocol Validation Policies lr
Al
Another important class of policies are the Protocol Validation Policies. SecureSphere has predefined Network
Protocol Validation and HTTP Protocol Validation policies, which are automatically applied to new Site tree objects.
c.

Network Protocol Validation Policy

In

The network protocol validation policy is applied to Server Group objects in the sites tree and inspects the network
level traffic for compliance with the TCP/IP standards. The policy can perform detailed analysis of the network
a,

traffic, however only two of twenty eight rules are enabled by default. The reason for these defaults are twofold.
rv

First, this network level validation is likely redundant with other infrastructure in the network such as firewalls and
routers. Second, it is quite common for normal network traffic to fall short of strict protocol compliance and with
pe

the number of individual packets passing back and forth on the network, large numbers of security violations can be
generated in just a few moments.
Im

The Two Network Protocol Validation rules that are enabled by default are quite important overall. They are:
17

• SSL Untraceable Connection

• TCP – Invalid Data Length in Header
20

The SSL Untraceable Connections rule is triggered when encrypted Traffic is identified by the SecureSphere Gateway
but cannot be decrypted for inspection. This can occur for the following reasons:
©

1. If the SecureSphere gateway did not see the initiation of the SSL connection.
2. If SecureSphere has no access to the server's private key used to establish this session.
3. If the SSL cipher method used for this session is not supported by SecureSphere.

Reason one will generally resolve itself rapidly and is usually does not indicate any problems. Reasons two and three
can indicate serious configuration issues that requires attention. SSL Untraceable events will be covered in more in
the tuning lesson.

© 2017 Imperva, Inc. All rights reserved 4-28 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

The TCP – Invalid Data Length in Header rule identifies packets that have an inconsistency in their size which can
indicate an overflow attack.

HTTP Protocol Validation Policy

The HTTP Protocol Validation policies validate the Web traffic follows the RFC standards for HTTP. The default HTTP
Protocol Validation policy is named the Web Protocol Policy and is automatically applied to new HTTP Service
objects.

.
ed
rv
se
re
s
ht
ig
lr
Al
Figure 4-27 - Automatically applied Web Protocol Policy

Many attacks are based on sending invalid requests to the Web server to exploit a server weakness, or vulnerability.
c.

Validating the traffic follows the HTTP protocol standards can quickly identify many common attacks. For example a
In

hacker’s automated reconnaissance tool will test for vulnerabilities, like encoding backspaces and control character
in the URL to illicitly access sensitive files on the Web server. The Illegal Byte Code Character in URL rule would
a,

identify this inappropriate activity.

rv
pe
Im

Figure 4-28 - Web Protocol Policy Rule - Illegal Byte Code Character in URL
17

Many highly damaging attacks can be prevented by enforcing protocol compliance. For example, an attacker may try
20

to leverage a buffer overflow vulnerability on a Web server. A buffer overflow vulnerability is a weakness on the
server that allows excess data to be written beyond the allocated memory area. An attacker exploiting this
vulnerability can force malicious code into overflow region, causing the Web server to run the malicious code. A
©

successful buffer overflow attack can gain full control of the Web server, and after the fact, it may be very difficult to
detect that the server has been compromised. This type of attack necessarily includes a large amount of submitted
data to trigger the overflow. The HTTP Protocol rules like Extremely Long HTTP Request and Extremely Long
Parameter can prevent these types of buffer overflow attacks.

The HTTP Protocol policy also addresses denial of service attacks with the following four policies:

© 2017 Imperva, Inc. All rights reserved 4-29 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

• Slow HTTP from Multiple Sources

• Slow HTTP from a Single Source
• Slow HTTPS from Multiple Sources
• Slow HTTPS from a Single Source
Collectively referred to as Slow HTTP/S Denial of Service Attacks.

A Slow HTTP or HTTPS Denial of Service attack prevents legitimate clients from using the Web application by tying

.
up all of the available Web server processes that are listening for new client connections. The listening process can

ed
only communicate with one client at a time, so a pool of listeners is available for new client connections.

rv
The slow HTTP/S denial of service attacks allow one client to keep hundreds or thousands of listeners busy with very

se
minimal overhead allowing a very small number attackers interfere with all legitimate client activities. In some cases,
a single client attacking from a single computer has been successful. The attacker ties up a Web listening process on

re
the destination Web server by opening a connection and very slowly adding to the HTTP request headers. The client
sends data just fast enough to keep the connection from timing out, and never completed the request. The attack

s
would look similar to the following example:

ht
POST / HTTP/1.1

ig
Host: www.superveda.local
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
lr
X-Y8fn2rdnvIItBCz: F1BB87
Al
...10 second delay...
X-W65lEIZ7YfE5Fsh: F375DB
...10 second delay...
c.

X-GMZCLIasp9P0d7q: 078D17
...10 second delay...
In

X-7jC7tMk5M9rBz4J: 92EEE4
...10 second delay... (etc…)
a,

This process requires very little resources on the client’s side, allowing the attacker to open hundreds or thousands
rv

of connections to the Web server, thus tying up all available listening processes and shutting out valid clients.
pe

There are slight differences between the slow HTTP and slow HTTPS attacks, however, the details are not important
here because the overall client behavior is what causes problems and it is what the policy rules identify. By default
Im

the policy multiple source policies are looking for over one hundred unique clients, each with a slow connection. For
a single source, the criteria is fifty or more unique connections, all slow. The client and connection thresholds are
17

located in the rule details and can be adjusted. The following image shows details for the rule Slow HTTP from
Multiple Sources.
20
©

Figure 4-29 - HTTP Protocol Policy Rules Slow HTTP from Multiple and Single Sources Details.

The following image shows details for the rule Slow HTTP from a Single Source.

© 2017 Imperva, Inc. All rights reserved 4-30 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

Figure 4-30 - HTTP Protocol Policy Rules Slow HTTP from Single Sources Details

The thresholds used to determine a slow connection are also configurable. The default Values are:

.
ed
1. The client is actively sending data, but at a rate less than 500 bytes per second.
2. The client connection is five or more seconds old.

rv
3. Notifications and followed actions will occur at the start of the violation and again are resent every 300
seconds during the attack.

se
The slow connection thresholds can be viewed and edited from the Advanced tab of the Web protocol policy.

re
s
ht
ig
lr
Al
c.
In
a,
rv
pe

Figure 4-31 - Web Protocol Policy Settings for Slow HTTP / HTTPS Attack – Thresholds
Im

Note.
In rare situations an extremely slow Web application, or very high network latency can mimic a multiple-source
17

HTTP/S denial of service attack, causing false positives. This is resolved by addressing the causes of latency.
20

Correlation Policies
©

The next policy type we will discuss is the Web Service Correlated Validation policy type. Like the other policy types
discussed earlier, this type also has a predefined policy, the Web Correlation Policy, which is automatically applied to
new HTTP Service objects.

Correlation policies make use of SecureSphere’s unique Correlated Attack Validation technology, which analyzes
multiple pieces of information from the network, protocol and application levels over time. By basing decisions on

© 2017 Imperva, Inc. All rights reserved 4-31 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

multiple observations rather than a single event, Correlated Attack Validation delivers a highly accurate, fully
automated defense system with accuracy that cannot be matched by several standalone data security products.

For example, a signature may identify a User-Agent header commonly associated with an automated Web scanner.
However, some Web scanners will spoof the headers of a common Web browser, so in this case, there may be a
chance of false positives, making a block response unsafe at this point. The Signature Violation is passed to the
SecureSphere Correlation Engine and retained there. Later in the traffic inspection process, the HTTP Protocol Policy
identifies an illegal byte code in the parameters of this request. The HTTP Protocol Violation is also passed to the

.
ed
SecureSphere Correlation Engine. The combination of a signature that likely identifies a Web scanner, and
suspicious data being passed in a parameter field strongly indicates an attack and a correlation policy rule can

rv
identify and block this attack.

se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe

Figure 4-32 - Example Attack identified by SecureSphere Correlation

The following shows the automatically applied Web Correlation Policy.

Im
17
20
©

Figure 4-33 - Web Correlation Policy

© 2017 Imperva, Inc. All rights reserved 4-32 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

Two rules in the Web Correlation Policy are enabled by default.

• Cross Site Scripting

• SQL Injection
The remaining rules are not enabled by default because they may only benefit specific Web applications, or they
may require tuning to prevent false positive matches. Additional information is available by expanding individual
rules.

.
ed
rv
se
re
Figure 4-34 - Cross Site Scripting Rule Details

s
ht
The SQL Injection attack provides another example of the benefit of correlation policies.

ig
Note
lr
If you are unfamiliar with how an SQL Injection works see the video: Anatomy of an SQL Injection Attack.
Al
Video 4-1 - Anatomy of an SQL Injection Attack
c.

The benefit can be seen with one of the most basic SQL Injection patterns.
In

‘or 1=1--
a,
rv

This pattern supersedes an existing logical constraint with the always true condition of 1=1. However, effectively
blocking all variants of this pattern presents challenges because the attacker can easily make a minor adjustment to
pe

evade pattern based matches, without affecting the logic of the operation: For example:
Im

‘or 123456=123456--
17

Or…
20

‘or “blue”=“blue”--
©

The SQL Injection correlation policy rule uses signatures to identify the individual parts of the attack and triggers
when the all of the required parts are present.

(continued on next page)

© 2017 Imperva, Inc. All rights reserved 4-33 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

Custom Web Service and Custom Web Application Policies

In spite of the broad range of attacks that are protected with predefined Security Policies, the need to customize the
behavior of SecureSphere for specific requirements usually necessitate custom Web Service and Web Application
policies. The large number of predefined policies may appear daunting at first. Fortunately, the process of assigning
custom and Web application policies is initially straight forward. The more complex Security Policies are then built
over time.

.
ed
Common reasons for creating a Security Policy:
1. Modifications to an ADC defined policy are required.

rv
2. A policy needs to operate differently between two or more Server Groups, or HTTP Services, or Web
Applications.

se
3. An alert or notification is required when specific activities occur.
4. A unique aspect of the Web application requires a unique policy securing it.

re
The first two reasons for creating custom Security Policies are typical encountered during the initial configuration of

s
SecureSphere. In the first case, the ADC policy only allows minor modifications. In the second case, the existing

ht
policy may be fine for some Sites Tree objects, but a subset of the protected assets require different settings. In
both cases, the typical resolution is to clone the existing policy and apply the copied policy to the relevant Sites Tree

ig
objects. Cloning a policy is also referred to as copying the policy.
lr
The third and fourth reasons commonly surface later in the configuration process and will require progressively
Al
more detailed custom policies. This will be covered in more detail in the Web Application Security Tuning lesson.
c.

Cloning an Existing Policy

In

1. Select Main > Policies > Security.

a,

2. Click to create a new policy and select Web Service.

rv
pe

3. Configure the Create New Policy window as follows:

Im

a. Name the Policy: SV - Custom Web Protocol Policy.

b. Select: Use Existing.
c. Select the original policy to be cloned: HTTP/1.x Protocol Policy.
17

d. Click
20
©

© 2017 Imperva, Inc. All rights reserved 4-34 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

4. Select the Apply To tab

5. Expand the Sites Tree and select the SuperVeda - Http – Service

.
ed
rv
se
re
6. Only one HTTP/1.x Protocol Policy is allowed per HTTP Service object, when notified click OK.

s
ht
ig
lr
Al
7. Click to save changes
c.

8. Verify the changes (Optional)

In

a. Select Main > Setup > Sites, expand the sites tree and select SuperVeda – Http –Service
b. Verify the newly created policy is displayed on the Applied Policies tab
a,
rv
pe
Im
17

Web Service Custom and Web Application Custom Policy Types.

20

At the HTTP Service and Web Application analysis levels, an additional class of policies is available. These policies
define just one rule, unlike previous policies discussed which have multiple rules per policy.
©

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 4-35 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
Figure 4-35 - Structure of Single Rule Policies - Automated Vulnerability Scanning Policy

ig
Note
lr
Although the majority of Web Application level Security Policies will be single rule policies, there are several
exceptions. The Web Profile Policy is an example which will be discussed in the Web Application Profile lesson.
Al
c.

In a single-rule Security Policy the rule is defined by Match Criteria. Each Match Criteria matches a specific aspect of
the inspected traffic. For example, the Source IP Address Match Criteria will match the originating IP address in the
In

inspected traffic.
a,
rv
pe
Im
17

Figure 4-36 - Match Criteria: Source IP Address

20

For comparison, the Application User Match Criteria will match username of users that have logged into the
protected Web application.
©

Figure 4-37 - Match Criteria: Application User

© 2017 Imperva, Inc. All rights reserved 4-36 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

Note
The Application User Match Criteria also depends on proper user identification, which will be discussed in the
Web Application Profile Lesson.

The following table describes some of the more commonly used Match Criteria. A description of all Match Criteria is
available in the Web Application Firewall User Guide and SecureSphere Online Help . The following table

.
shows some of the most frequently used Match Criteria:

ed
Match Criteria Description

rv
Application User Matches the Web Application Username for authenticated users.

se
Generic Dictionary Lookup Custom pattern matching. Simple and regular expression pattern matches can be
performed

re
HTTP Request * Multiple, Match Criteria that match specific attributes of the HTTP request or
response.

s
Lookup Data Set Search Allows identification of additional information not present in the request, but

ht
relevant for inspection. For example, a user’s activity may be prevented because
they are not in the right company department.

ig
Number of Occurrences Correlation Match Criteria, able to identify activity over time. Minimum time
lr
frame 5 Seconds and increments in 5 second intervals.
Sensitive Dictionary Lookup Custom pattern matching. Simple and regular expression pattern matches can be
Al
performed.
Signatures The request matches the selected signatures
c.

Source Geo Location Threat Radar Match Criteria: Matches the source IP address based on the GEO
In

location of the source IP.

Source IP Address Matches the originating IP Address
a,

Violations Correlation Match Criteria: The current request also triggered the selected
violations.
rv

Table 4-11 - Frequently Used Match Criteria

pe

Creating a Web Service Custom policy

Im

9. From the Main workspace, select Policies > Security

10. Create a new policy with the button and select Web Service
17
20
©

11. Configure the Create New Policy window:

a. Name the Policy: SV - Track Hacker Taunting Actions
b. Select: From Scratch
c. Type: Web Service Custom
d. Click
(Screenshot on next page)

© 2017 Imperva, Inc. All rights reserved 4-37 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
12. Since the Web Service Custom policy was created from scratch, it will not have Match Criteria defined.

se
re
s
ht
ig
lr
Al
c.

13. Select and configure Match Criteria to define the policy rule:
In

a. From the Available Match Criteria section, select the Application User Match Criteria by clicking the
arrow.
a,
rv
pe
Im

b. The Application User Match Criteria will move up.

17
20
©

c. Expand Application User and click the button to add a row to the table.

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 4-38 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

d. Enter the name: bugsb.

14. Select the Apply To tab.

.
ed
rv
se
re
s
ht
ig
lr
15. Expand the Sites Tree and select the SuperVeda - Http – Service.
16. Verify the policy from the Sites Tree (Optional):
Al
a. Select Main, Setup > Sites and expand the sites tree to select the SuperVeda – Http – Service object.
b. Verify the newly created policy is displayed on the Applied Policies tab.
c.
In
a,
rv
pe
Im
17
20
©

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 4-39 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

Note
Creating a Web Application Custom policy will follow the above process, with the adjustment of selecting the Web
Application Custom policy type, instead of Web Service Custom policy types. The desired Match Criteria will also
likely be different.

Web Profile Policy

.
The Web Profile Policy receives abnormal client event information that was identified by the SecureSphere Web

ed
Application Profiling. This policy will be discussed in the Web Application Profiling lesson.

rv
Threat Radar Policies

se
ThreatRadar Policies are an advanced set of policies that utilize the Imperva ThreatRadar data feed. This is a license

re
subscription service with regularly updated reputation feeds to identify internet bad-actors. The Threat Radar lesson
will have detailed coverage of the ThreatRadar based policies.

s
ht
Security Policy Configuration Report

ig
Once the initial set of predefined and custom Security Policies are in place it will be important to periodically verify
lr
the policies are all applied. Ideally the verification process should be standardized, repeatable, and require minimal
overhead. SecureSphere Configuration Reports are the ideal tool to gain visibility into the Security Policies applied.
Al
The following Security Policy Configuration report provides an example of the information provided by Security
c.

Policy Configuration reports.

In

Warning
a,

Reports are owned by the SecureSphere user that originally created the report.
rv

Removing a user from SecureSphere will clear all scheduled reports that were owned by the user.
pe

The reports are retained and assigned to the SecureSphere Admin user account, but they cannot be rescheduled.
Im

Instead, the report needs to be cloned. Create a new report and choose Use Existing and select the original report.
This copy can be scheduled as desired.
17

Example SV - All Active Security Policies Report

20

1. Select Main > Reports > Manage Reports

©

© 2017 Imperva, Inc. All rights reserved 4-40 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

2. Click create and select Configuration > Security Policies.

.
ed
rv
se
re
s
ht
ig
lr
3. Configure Create Security Policies Report window as follows:
Al
a. Name: SV – All Active Security Policies.
b. Select: From Scratch.
c.

c. Click .
4. The Report Window will show the settings for the new report.
In

5. Select the General Details tab.

a,
rv
pe
Im

6. Select Format: PDF and Page Orientation: Landscape.

17
20
©

7. Assigning keywords is recommended to simplify filtering reports. If a relevant keyword is available, select it and
move it to the Report Keywords column with the arrow. Refer to the SecureSphere Administration class or
SecureSphere Admin Guide for information on creating keywords. The following example shows the

© 2017 Imperva, Inc. All rights reserved 4-41 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

assignment of Keyword SuperVedaWeb to the report.

.
ed
rv
se
8. Select the Data Scope tab and use the arrow to move Applied to Assets and Rule Enabled report fields into
the Enabled Fields section.

re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

9. Expand the Applied to Assets Field and click the Create button to define the SuperVeda Sites Tree assets as
follows:
a. Site: SuperVeda.
b. Server Group: SuperVeda Web SG.
c. Services: SuperVeda – Http – Service.

© 2017 Imperva, Inc. All rights reserved 4-42 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

d. Applications: <BLANK>.

.
10. Expand the Rule Enabled field and verify it is set to True.

ed
rv
se
11. Select the Tabular tab and click the create button repeatedly to add nine rows to the table.

re
s
ht
ig
lr
Al
c.
In
a,
rv

12. Configure the rows shown in the following figure.

pe
Im
17
20
©

13. Configure the Sorting as follows:

a. First By: Rule Severity, Sort: Descending.
b. Then By: Rule Name, Sort: Ascending.
14. Select the Scheduling tab.

© 2017 Imperva, Inc. All rights reserved 4-43 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

15. Schedule the report to run monthly, select:

a. Occurs: Recurring, Monthly, on the First Day every Month.
b. Starting from: Today.
c. At Time: 7 AM.

.
ed
rv
se
re
16. Save the changes.

s
17. Select the General Details tab and click (scroll to the bottom of the page).

ht
18. Download and review report.

ig
Example Results:

lr
Al
c.
In
a,

Tip
rv

The provided report is just an example and the following additional columns may also be desirable in some
pe

environments (will cause much larger reports):

Match Criteria – This details the settings for the active Match Criteria in the policy.
Im

Applied to Assets – Lists the Sites Tree Object the policy is applied to
17
20
©

© 2017 Imperva, Inc. All rights reserved 4-44 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

Review Questions
1. Describe several benefits of using Followed Actions in Security Policies and explain which notification option(s)
you expect to use in your SecureSphere deployment (Email, Syslog, SNMP Traps, Remedy)?
2. Describe a key benefit provided by each of the following policy types:
a. Stream Signature Policies or HTTP Protocol Signature Policies (pick one).
b. HTTP Protocol Validation Policies
c. Correlation Policies

.
ed
d. Custom Policies
3. What is the difference between a policy rule and a Match Criteria? How are they related?

rv
4. Describe how to identify a multi-rule policy and a single-rule policy.

se
Exercises

re
Prerequisite:

s
Important

ht
Before beginning the exercises, you must complete the steps detailed in the following class interactive sections.

ig
1.Creating Manual Dictionaries and Custom Signatures.

Exercise 1
lr
Al
Configure a Followed Action for later use that meets the following requirements:
c.

Create a new Action Set as follows:

In

Parameter Value
Name: SV - Violation - Send to VedaDB Syslog
a,

Apply To Event Type: Security Violations – All

rv

Select the following Action Sets:

pe

Parameter Value
Action Interface Server System Log > Log to System
Im

Configure the Server System Log > Log to System action interface as follows:
17

Parameter Value
Name: SV - Violation – Send to VedaDB Syslog
20

Syslog Host PREDEFINED – No Changes

Syslog Log Level WARN
Message $!{Alert.severity},$!{Alert.alertType},$!{Alert.description}
©

Facility Local0
Run on Every Event Selected

© 2017 Imperva, Inc. All rights reserved 4-45 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

Exercise 2
Create a custom Manual Signature Dictionary and a corresponding Signature Policy to address hacker taunting
messages in the SuperVeda environment.

Manual Signature Dictionary Name: SV - Hacker Taunting Signatures

Parameter Value
Enter Name SV - Hacker Taunting Signatures

.
Description Collection of hacker taunts seen on SuperVeda

ed
Dictionary Type Web

rv
Configure two Hacker Taunt signatures:

se
Hacker Taunt 1
Parameter Value

re
Signature Name Hacker Taunt – IPwnYou
Signature part="IPwnYou"

s
Protocols http, https

ht
Search Signature In URLs And Parameters

ig
Hacker Taunt 2
Parameter Value
lr
Al
Signature Name Hacker Taunt - PwnedSuperVeda
Signature part=" PwnedSuperVeda"
c.

Protocols http, https

In

Search Signature In URLs And Parameters

a,

Create an HTTP Web Service Policy as follows:

Parameter Value
rv

Name SV – Hacker Taunting Signatures

pe

From Scratch Selected

Type HTTP Web Service Custom
Im

Configure the policy as follows:

Parameter Value
17

Dictionary Name SV – Hacker Taunting Signatures

Enabled Selected
20

Severity Medium
Action None
©

Followed Action SV - Violation - Send to VedaDB Syslog

When the new HTTP protocol signatures policy is complete, use the Apply To tab to assign the policy to the
SuperVeda - Http – Service. Verify policy successfully identifies the signature by leaving a hacker’s taunt.

© 2017 Imperva, Inc. All rights reserved 4-46 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

Perform the following actions on the SuperVeda Web application:

1. Select About Us and click the Here link.

.
ed
rv
Note: You must click the word here in order to view the Contact Us form.

se
2. In the Contact Us form, enter a subject and Comment and include the hacker’s taunt in either location

re
s
ht
ig
lr
Al
3. Check for the violation in the SecureSphere Main workspace, Monitor > Dashboard, looking for a security
violation named: SV – Hacker Taunting Signatures
c.
In
a,
rv
pe
Im

Exercise 3
17

Clone the Web Protocol Policy, naming the new policy SV – Custom Web Protocol Policy. Adjust the threshold for
20

Slow HTTP from Single Source rule from 50 to 10 in the new policy. Apply the cloned policy to the SuperVeda – Http –
Service sites tree object.
©

Exercise 4
Create a Web Service Custom policy that will identify persistent taunting activity.

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 4-47 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

Web Service Custom policy requirements:

Parameter Value
Name SV – Persistent Hacker Taunting
From Scratch Selected
Type Web Service Custom

Match Criteria 1 – Number of Occurrences

Parameter Value

.
ed
Occurred More than 3
Within 60

rv
In the Context of a Single Originating Session

se
Match Criteria 2 – Signatures

re
Parameter Value
Operation At least one
[Signature Type] User Defined Signatures

s
ht
Selected Hacker Taunt - IPwnYou
Hacker Taunt – PwnedSuperVeda

ig
Match Criteria 3 – URL
Parameter Value
lr
Al
Match Exact URLs
Operation At least one
c.

Value: /sendmsg.asp
In

Other Policy Settings:

a,

Parameter Value
Action None
rv

Severity High
pe

Followed Action None

Enabled Selected
Im

One Alert Per Session Not Selected

Apply the policy to the SuperVeda – Http – Service.

17
20

Exercise 5
Recreate the SV – All Active Security Policies report shown earlier in this lesson.
©

Tab: General Details

Parameter Value
Name SV - All Active Security Policies
Description (Optional) Reports on all active Security Policies applied to SuperVeda Web assets.
Format PDF
Page Orientation Landscape

© 2017 Imperva, Inc. All rights reserved 4-48 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

Tab: Data Scope

Enabled Field Field Settings
Applied to Assets Field Name Field Setting
Operation: Equals
Value: Site Server Group Services Applications
SuperVeda SuperVeda Web SG SuperVeda 0 Http Service <NONE>
Enabled Field Field Setting
Rule Enabled True

.
ed
Tab: Tabular

rv
Title: (Optional)
Table

se
Column Aggregation Function Order

re
Rule Severity None 1
Policy Level None 2
Policy type None 3

s
ht
Policy Name None 4
Rule Name None 5

ig
Rule Action None 6
Rule Followed Action
Rule has Exception
None
None
lr 7
8
Al
ADC Content None 9
Sorting:
c.

First By: Aggregation Function Sort:

In

Rule Severity None Descending

Then By: Aggregation Function Sort:
a,

Rule Name None Ascending

Generate Group Headers: Un-selected
rv
pe

Tab: Scheduling
Occurs: Recurring
Im

Monthly Selected
Day Selected
Monthly Scheduling Day 1 of every 1 month(s)
17

Starting from <TODAY’S DATE>

At time: 7:00 AM
20

Answers to Review Questions

©

1. Describe several benefits of using Followed Actions in Security Policies and explain which notification option(s)
you expect to use in your SecureSphere deployment (Email, Syslog, SNMP Traps, Remedy)?
a. Benefits: Followed Actions allow tight integration between SecureSphere and the organizations established
event handling procedures. The exact configuration will depend on organizational requirements and the
deployment goals.

© 2017 Imperva, Inc. All rights reserved 4-49 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

b. Expected Use: Answers will vary. Some organizations will choose to use notifications only on blocking rules,
while others may choose to syslog all violation events.

2. Describe a key benefit provided by each of the following policy types:

a. Stream Signature Policies or HTTP Protocol Signature Policies (pick one).
1. Stream Signatures: Analyzes all network traffic for known attack patterns protecting the server against
network level attacks.

.
ed
2. HTTP Protocol Signatures: Analyses HTTP traffic for known attacks on the server.
b. HTTP Protocol Validation Policies

rv
1. These policies identify abnormal Web requests or responses. Many simple attack strategies, like buffer
overflow attacks, can be quickly identified with protocol validation.

se
c. Correlation Policies
1. By using correlated events, these policies allow accurate identification of attack patterns while excluding

re
false positive events. Correlation policies allow confidence when blocking.
d. Custom Policies

s
1. Custom policies are the most flexible policies and are invaluable when securing highly sensitive Web

ht
applications.

ig
lr
3. What is the difference between a policy rule and a Match Criteria? How are they related?
a. Policy rules are composed of Match Criteria. Each Match Criteria defines a detail of the inspected traffic and
Al
collectively they build a rule associated with a Security Policy. For policies with multiple rules, Match Criteria
are not visible.
c.
In

4. Describe how to identify a multi-rule policy and a single-rule policy.

a,

a. A multi-rule policy has a table with multiple rules and associated Severity, Immediate Action and Followed
Action settings. A single rule policy will show the Match Criteria that defines the rule.
rv
pe

Answers to Exercises
Im

Exercise 1
Create the Followed Action: SV - Violation - Send to VedaDB Syslog.
17
20
©

Configure the Server System Log > Log to System action interface as follows:

© 2017 Imperva, Inc. All rights reserved 4-50 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
Exercise 2

se
Create a custom Signature Dictionary and Signatures Policy meeting the following requirements:

re
Signature Dictionary Name: SV - Hacker Taunting Signatures.

s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

Configure the two Hacker Taunt signatures as follows:

Hacker Taunt 1:

© 2017 Imperva, Inc. All rights reserved 4-51 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
Hacker Taunt 2:

ig
lr
Al
c.
In
a,
rv
pe
Im
17

Manual Signature Dictionary configured:

20
©

© 2017 Imperva, Inc. All rights reserved 4-52 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

Create an HTTP Protocol Signature Policy as follows:

1. Select Main > Policies > Security.

2. Click to create a new Web Service Security Policy.

3. From the Create New Policy window, name the policy and select From Scratch and type HTTP Protocol

.
ed
Signatures.

rv
se
re
s
ht
ig
4. Click lr
to add a row to the signature rules table and configure the row based on the provided information:
Al
c.
In

5. Select the Apply To tab and expand the Sites Tree.

a,

6. Select the SuperVeda – Http – Service sites tree object.

rv
pe
Im
17
20
©

7. Click to save changes.

Verify the policy:

© 2017 Imperva, Inc. All rights reserved 4-53 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

1. Select About Us and click the Here link.

.
ed
Note: You must click the word here in order to view the Contact Us form.

rv
se
2. In the Contact Us form, enter a subject and Comment and include the hacker’s taunt in either location.

re
s
ht
ig
lr
3. Check for the violation in the SecureSphere Main workspace, Monitor > Dashboard, looking for a security
Al
violation named: SV – Hacker Taunting Signatures.
c.
In
a,
rv
pe
Im

Exercise 3
Clone the Web Protocol Policy, naming the new policy SV – Custom Web Protocol Policy. Adjust the threshold for
17

Slow HTTP from Single Source rule from 50 to 10 in the new policy. Apply the cloned policy to the SuperVeda – Http –
Service sites tree object.
20

Start by creating a new Web Service Security Policy and configuring the Create New Policy Window as follows:
©

© 2017 Imperva, Inc. All rights reserved 4-54 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
Configure the Slow HTTP from a Single Source rule as follows:

se
1. Select the newly created policy and scroll down to the Slow HTTP from a Single Source rule.

re
2. Click to expand the rule and set the Number of Slow Connections to 10.

s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17

3. Select the Apply To tab and expand the Sites Tree.

20
©

© 2017 Imperva, Inc. All rights reserved 4-55 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

4. Select the SuperVeda – Http – Service sites tree object.

.
ed
rv
se
5. Click OK to confirm the replacement of the Default Web Protocol Policy.
6. Click to save changes.

re
s
ht
ig
lr
Al
(Continued on next page)
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 4-56 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

Exercise 4
1. Select Main > Policies > Security.
2. Click to create a new Web Service policy.

3. From the Create New Policy window, name the policy SV – Persistent Hacker Taunting, select From Scratch and

.
ed
type Web Service Custom.

rv
se
re
s
ht
ig
lr
4. Use the arrow to move the following two Available Match Criteria into the Match Criteria section:
a. Number Of Occurrences.
Al
b. Signatures.
5. Click to expand the Number of Occurrences Match Criteria and configure as shown in the following figure:
c.
In
a,
rv
pe
Im
17
20
©

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 4-57 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

6. Click to expand the Signatures Match Criteria and configure as shown in the following figure:

.
ed
rv
se
7. Configure the Security Policy response as shown in the following figure:

re
s
ht
ig
lr
Al
8. Select the Apply To tab and expand the Sites Tree.
9. Select the SuperVeda – Http – Service sites tree object.
c.
In
a,
rv
pe
Im
17

10. Click to save changes.

20
©

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 4-58 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

Exercise 5
Name the report SV – All Active Security Policies and follow the instructions provided in the Example SV - All Active
Security Policies Report section.

The report results will look similar to the following:

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 4-59 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 4-60 Lesson 4: Security Policies
SecureSphere 12.0 Web Application Security Course Manual

Web Application Profiling

Chapter Overview
SecureSphere includes the ability to learn from normal client interactions with the protected web applications
through the Web Application Profile. The Web Application Profile is a learning engine that builds a mapping normal
URL and Cookie and access patterns. Profiles represent a "whitelist" security model, defining what is allowed, in

.
contrast to security policies discussed earlier that represent a "blacklist" or restrictive model of what is not allowed.

ed
SecureSphere provides a visibility and control over the learning process ensuring accurate and timely learning.
When configured, the profile can automatically restart learning when changes to the protected applications are

rv
detected. Responses to abnormal client activity are managed through the Web Profile Policy giving security

se
administrators fine-grained controls over the response.

re
Chapter Objectives
• Describe the components of the Web Application Profile.

s
ht
• Explain how the Web Application Profile learns and protects web applications.
• Define and explain how application activity is mapped to the profile application mapping.

ig
• Identify common web application components used in the learning process.
•
•
lr
Define and explain how web application user tracking operates.
Explain how to select Web Profile Policy rules for the protected web application.
Al
• Configure appropriate reports to help administrators analyze profiles and profile learning.
c.

SuperVeda Lab Preparation

In

The following preparation steps will populate the SecureSphere Web Profile for the SuperVeda environment and will
a,

provide examples of learned behavior that will be discussed in the lesson.

rv

From the point that the SuperVeda Sites Tree was configured in SecureSphere, web activity events that meet safety
requirements can become learning events and will be learned. Previous exercises directed some activity to the
pe

www.superveda.local ecommerce web application and some learning should be visible there. The administrative
portal - admin.superveda.local/vedaadmin/, however, has received little or no activity and can be used to confirm
Im

profile learning is occurring.

17

Profile learning be confirmed as follows:

1. Select Main > Profile > Overview.

20
©

© 2017 Imperva, Inc. All rights reserved 5-1 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

2. Expand the SuperVeda site, SuperVeda Web SG,

and SuperVeda Http – Service to see the two
SuperVeda application objects.

.
ed
rv
Note

se
The numbers displayed in the URLs and URL Tracking columns will vary based on the amount of activity to the

re
SuperVeda applications.

3. The SuperVeda – Web Application object will likely show some numbers, indicating learned activity. However,

s
the Vedaadmin – Web Application most likely will not show any numbers, indicating a lack of activity.

ht
ig
lr
Al
4. Manually generate activity on the web application. Start Internet Explorer and brows to
c.

http://admin.superveda.local/vedaadmin/.
In
a,
rv
pe

<- admin
<- system
Im
17

URL: Credentials
20

Username: admin
http://admin.superveda.local/vedaadmin/
Password: system
©

© 2017 Imperva, Inc. All rights reserved 5-2 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

5. Log in and click on a couple links.

.
ed
rv
se
Note

re
Avoid the User Removal and Logout Links.

s
ht
6. After generating some web activity, refresh the SecureSphere Profile Overview page, look for newly learned

ig
URLs.
lr
Al
c.

This screenshot shows new URL counts for the Vedaadmin – Web Application.
In

Note
a,

If either the SuperVeda – Web Application or Vedaadmin – Web Application objects have no numbers under the
rv

URL columns, double check the Host/URL Application Mapping discussion in Lesson 3, Web Application Preparation
pe

and re-generate traffic events with Internet Explorer. IF the problem persists, work with your instructor to ensure
the Sites Tree configuration is correct.
Im

7. Next you will simulate web activity with a script on the SecureSphere Gateway.
8. From Client PC, start the Putty SSH tool and connect to the SecureSphere Gateway.
17

Field Value
IP Address 192.168.51.201
20

Username imperva_user
Password Impuser123
©

Note
Be certain to connect to the SecureSphere Gateway. The script used is not present on the Management Server.

9. At the command prompt enter the command admin and re-enter the password.

© 2017 Imperva, Inc. All rights reserved 5-3 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

login as: imperva_user

[email protected]'s password: <- Impuser123
Last login: Thu Oct 8 19:02:40 2015 from 192.168.51.2

Welcome to SecureSphere Shell

Type "help" for a list of commands

.
ed
SecureSphere> admin
[root@vedagw ~]#

rv
se
Note

re
You can verify you are the full administrative, root, user by noting the command prompt. The un-privileged
imperva_user account prompt ends with >

s
ht
SecureSphere>

ig
While the Root prompt ends with #

[root@veda-gw ~]#
lr
Al
10. Enter the following command to generate common profile traffic (only type the text in bold).
c.

[root@veda-gw ~]# build-sv-profile.sh

In
a,

Tip
rv

The SecureSphere Linux CLI supports tab-completion. You can simplify typing the above command by using tab to
pe

auto-completion as follows: build-s[TAB]

The full script names will auto-complete when you hit tab.
Im

11. Leave the command running and let the instructor know you are finished. The traffic simulation will take
approximately 5 to complete.
17

Web Application Elements

20

Understanding the profile depends on a baseline understanding common elements of web applications. In particular
it will be necessary to recognize the following:
©

• HTTP Request and Response formats

• Uniform Resource Locator (URL) / Uniform Resource Identifier (URI)
• HTTP Headers
o Host Header
o Cookies
• HTTP Methods

© 2017 Imperva, Inc. All rights reserved 5-4 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

• Parameters
• HTML Forms & Form Submission process
• ECMA Script (JavaScript)
• XML / JSON
• SOAP, AJAX, and REST

The remainder of this section will provides some basic details on the structure of web applications and can be
skipped if you are comfortable with the above topics.

.
ed
HTTP Request and Response Formats

rv
Examples of HTTP Request and Response formats were discussed in the Web Security Policies lesson.

se
Uniform Resource Locators (URLs) and Uniform Resource Identifiers (URIs)

re
A URL or URI is a string of characters used to identify the name of a resource on a network or the internet. There are
subtle differences between URLs and URIs. However, due to our current focus on web applications they can be

s
treated as equivalent and this text will use URL.

ht
ig
The following is an example of a URL from the SuperVeda Web Appliction:

http://www.superveda.local/home.asp
lr
Al
c.

HTTP Headers
In

The HTTP request and responses both include headers provided by the client and server, respectively. The following
headers will be relevant for web profiling.
a,

Header Origin Description

rv

HOST Client The Fully Qualified Domain Name, or Address, in the URL.
pe

Set-Cookie Server Header containing a Cookie. A Cookie is an identifier and value that are stored
by the client’s browser and included subsequent requests request to the
Im

server.
Cookie Client The cookie or cookies defined by the server and stored by the client browser.
17

Table 5-1 - HTTP Headers relevant for profiling

Examples
20

URL and Host Header

©

Original URL:
HTTP://www.superveda.local/home.asp

Headers:
GET /home.asp HTTP/1.1
Host: www.superveda.local
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
Iceweasel/38.2.0

© 2017 Imperva, Inc. All rights reserved 5-5 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://www.superveda.local/

Table 5-2 - Example: HTTP request (Client origin) showing original URL and request headers

Note

.
ed
HOST header is in bold.

rv
(Continued on next page)

se
Set-Cookie Header:

re
HTTP/1.1 200 OK
Cache-Control: no-cache,private

s
Content-Length: 1687
Content-Type: text/html

ht
Server: Microsoft-IIS/8.5

ig
Set-Cookie: ASPSESSIONIDCSSBRBAA=ICOLBCEAKPMCOKLAANDFMBFE; Privileges=FreeShip
Date: Tue, 22 Sep 2015 21:32:04 GMT
lr
Table 5-3 - Example: HTTP Response (server origin) showing response headers
Al
Cookie-Header:
c.

Cookie: ASPSESSIONIDCSSBRBAA=ICOLBCEAKPMCOKLAANDFMBFE; Privileges=FreeShip

In

Table 5-4 - Example: of Cookie Header on subsequent requests

a,

HTTP Methods
rv

The HTTP protocol provides for multiple Methods that allow the client to define the desired action of the client
pe

request. The two most commonly used actions are GET and POST. Other methods can be dangerous if left enabled
on the web server. For example the PUT method allows the client to upload a new document to the URL location.
Im

Another example is the DELETE method which allows the client to delete the resource defined in the URL. The Web
Application Profile will identify all methods used by clients.
17

Parameters
Parameters are named variables containing data from the client. Most commonly this data is furnished when the
20

client fills in a web-form and submits the results. Parameter data may be defined in other ways. For example a script
in the webpage may set the value based on calculations, or the Web Server may have included a hidden and read-
©

only parameter value in the current page.

HTTP GET Method URL Example

Parameters and their values can be seen in the client request. For requests using the GET HTTP method, the
parameters will be included in the request URL like the example below.

© 2017 Imperva, Inc. All rights reserved 5-6 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

http://www.superveda.local/login.asp?mode=draw&return=home.asp

Table 5-5 - HTTP URL containing parameters

The format of URLs with parameters format:

URL Part Description
? Designates the end of the URL path and beginning of the parameters
<Parameter Name>=<Parameter Value> The parameter name and value, separated by an equals sign

.
ed
& or + Used to separate parameters when more than one is present
Table 5-6 - URL Parameter Identification

rv
se
re
Note
The above is the, most common URL format but it is not universal. Other URL formats exist, particularly for newer

s
web applications.

ht
HTTP POST Method Headers Example

ig
When a client a request using the HTTP POST method, returned parameters are located in HTTP request headers.
lr
Al
POST /login.asp HTTP/1.1
Host: www.superveda.local
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
c.

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
In

Accept-Language: en-US,en;q=0.5
Referer: http://www.superveda.local/login.asp?mode=draw&return=home.asp
Cookie: ASPSESSIONIDCSSBRBAA=ICOLBCEAKPMCOKLAANDFMBFE; Privileges=FreeShip;
a,

Content-Length: 82
username=bugsb&password=carrots&submit.x=6&submit.y=2&mode=login&return=home.asp
rv
pe

Table 5-7 - HTTP POST Request Headers showing parameters

HTML Form Parameters

Im

HTML forms are one of the most common client interaction interfaces in web applications. Take for example the
SuperVeda Login Page:
17
20
©

Figure 5-1 - SuperVeda Login HTTP Form

Clients enter and submit their credentials to log into the SuperVeda website. Below, the HTML source show the
form. The form parameters are identified in bold text.

© 2017 Imperva, Inc. All rights reserved 5-7 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

<form method="post" action="login.asp" class="main_body_text">

<table>
<tr>
<td>Username:</td>
<td><input type="text" name="username" size="20"></td>
</tr>
<tr>
<td>Password:</td>
<td><input type="password" name="password" size="22"></td>

.
ed
</tr>
<tr>
<td colspan="2">

rv
<input name="submit" type="image" src="images/login_button.jpg">

se
</td>
</tr>
</table>

re
<input type="hidden" name="mode" value="login">
<input type="hidden" name="return" value="home.asp">

s
</form>

ht
Table 5-8 - SuperVeda HTML source of the login page

ig
When the client clicks submit, information provided by the client is assigned to the parameters and for POST
lr
requests, included in the HTTP Headers, or for GET requests, included in the URL.
Al
ECMA Script (JavaScript)
c.

ECMA Script or JavaScript, is a programming language that can be embedded in web pages and run by the client’s
In

browser. JavaScript can provide a rich user experience. Additional calls to the web application can be triggered from
the JavaScript itself. For example, an online investing website may include a Stock-Ticker JavaScript program that
a,

regularly retrieves updated stock quotes.

rv

XML / JSON
pe

Rich web applications, like the Stock-Ticker example above, may use an alternate format for updates. Two of the
most commonly used alternatives are XML and JSON. Although these two formats are quite distinct in their
Im

appearance, in both cases they serve the purpose of passing data between a script in the browser and the web
server to provide a rich user experience. For example, a web hosting company may provide a WYSIWYG webpage
editor for customers. A customer using the editor will work directly with the JavaScript running in their browser.
17

When the customer submits their updates, the data could be packed into an XML or JSON object and passed up to
the server at that point.
20

SOAP, AJAX, and REST

SOAP, AJAX, and REST can be viewed as application design architectures detailing the handling of client to server
©

communications for rich web applications. SOAP is limited to XML format for data exchange, but variants of SOAP do
support other formats. AJAX typically uses either XML or JSON for data exchange but can also support other formats.
REST applications can work with many data exchange formats but JSON seems to be most common followed by
XML.

Introducing the SecureSphere Web Application Profile

© 2017 Imperva, Inc. All rights reserved 5-8 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

The Web Application Profile (profile) is the learning engine and learning dataset used to identify abnormal client
activity. The profile starts in Learning, allowing new and unique client activity to be added to the profile. When the
learning period is over, the profile switches to protect. Client requests that deviate from the learned profile are
identified and responded to with Security Policies. All traffic is evaluated for safety to ensure that attack or
potentially dangerous traffic is excluded from learning.

The SecureSphere Web Application Profile separates detection and enforcement. The profile data set contains the
collection of learned client behavior. During Inspection, the Imperva Gateway identifies any request that deviates

.
ed
from previously learned requests. This difference is passed to the Web Profile Policy, which is responsible for the
response to the concerning request. Questions often arise about the interaction of the Profile when the Server

rv
Group Mode can be set to either Simulation or Active. SecureSphere’s behavior is easier to understand by
remembering that learning and detection activities are separate from enforcement.

se
A real world comparison that may help is that of a criminal investigation. When a crime occurs, police respond,
investigate, and arrest the perpetrator. However, punishment for the crime is determined by a judge or jury in the

re
courts. With SecureSphere profiling, the profile itself is like the police force and is responsible for identifying
abnormal events while the Web Profile Policy is like the courts, and is responsible for enforcement.

s
ht
Criminal Investigations SecureSphere Equivalent

ig
Detection
Police monitor for criminal Profile Learning:
activities.
lr
Profile engine initially learns to identify normal activity.
Al
Identification
Profile Protection:
Investigators find the
c.

With learning complete, any unexpected activity is considered

perpetrator.
abnormal and passed to the Web Profile Policy.
In

Judgement
Profile Policy:
Legal system determines guilt
a,

Each rule of the Web Profile Policy determines the response

and sentencing
to identified abnormalities
rv

Table 5-9 - Comparing Criminal Investigation to Web Application Profiling

pe

A well-trained Web Application Profile can significantly enhance the security for the assets protected by
Im

SecureSphere. On the other hand, a poorly trained Web Application Profile can generate numerous false positive
alerts and create needless work for the web security team.
17

Warning
Be aware that the SecureSphere Personal Information Masking (PIM) feature cannot be used with Web
20

Application Profiling. If PIM is enabled, profiling is automatically disabled.

©

Working with Web Application Profiles

SecureSphere Web Application Profiles are viewed in the Main > Profile > Overview. The profile Overview provides a
top-level view of learning for all web application.

© 2017 Imperva, Inc. All rights reserved 5-9 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
Figure 5-2 - Web Application Profile Overview

re
Note

s
Application Mapping is required to direct web activity to newly created Web Application objects for analysis. The

ht
Default Web Application is an exception because it is automatically configured. Application Host Mapping is

ig
discussed in lesson 3, Web Application Level Preparations.
lr
The profile Overview is particularly useful when verifying that the learning process is progressing correctly. The
individual profiles themselves are viewed from Main > Profile > Application View. The Application View requires an
Al
application to be selected.
c.
In
a,
rv
pe
Im

Figure 5-3 - Profile > Application View Requires Selecting an Application

Select the relevant web application from the sites tree.

17

With a web application selected, the Application View provides visibility into the learned activity.
20
©

© 2017 Imperva, Inc. All rights reserved 5-10 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
Figure 5-4 - Choose Application Profile for Review with from the Sites Tree

re
s
ht
ig
lr
Al
c.
In
a,
rv
pe

Figure 5-5 - Web Application Profile Details

Im

The views pane provides visibility into each aspect of the profile.
View Description Usage
17

URLs (Tree View) URLs view – hierarchical display of web application URLs
Learned data
URLs (List View) URLs view – List display of URLs including searching and sorting
20

URL Patterns are used to tune the profile and will be covered in
URL Patterns Tuning
the tuning lesson
Cookies Displays learned cookies and identifies tracking behavior Learned data
©

Application user
User Tracking Identifies login page URLs and tracks application users
identification
Learned Hosts Listing of all valid HOST headers in use Learned data
Listing of all sensitive directories known to be targets of internet Exploit
Susceptible Directories
worms and exploits protection
URL Insight Graphs Application usage and performance graphs. URL Analysis

© 2017 Imperva, Inc. All rights reserved 5-11 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

Access Patterns
Broken Links & References Listing of identified broken links and references URL Analysis
Optimization Profile analysis to identify tuning opportunities Tuning Assistant
Table 5-10 - Description of profile views

URL Views
The URLs (Tree View) and URLs (List View) each provide a convenient view of the application URLs learned by

.
ed
SecureSphere. The URLs (Tree View) groups URLs into folders to match the file structure on the web server while
the URLs (List View) presents a tabular displays of the full URLs plus related information gathered during learning.

rv
URLs View Figure

se
re
s
ht
Tree View

ig
lr
Al
c.
In
a,
rv

List View
pe
Im
17

Table 5-11 - Comparison of URLs (Tree View) and URLs (List View)
20

URL Learning Status

©

In both the Tree and List View, the URL icon provides information about the learning status of the page. Additionally
SOAP or XML based URLs are also identified.

Icon Learning Status Description

Learning Mode URL is in learning
Protect Mode URL is in protection. Automatic update is possible.

© 2017 Imperva, Inc. All rights reserved 5-12 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

Locked URL is in protection. Automatic update is disabled

XML / JSON URL XML and JSON based activity icon indicates markup language
Broken link or Reference Client requests to the URL failed due to a broken link or reference

Table 5-12 - URL Profile Icons

.
SecureSphere Web Profile Learning

ed
rv
URL Based Learning

se
For many, the structure of the web profile is significantly different than what is imagined by the term learning. It is
easy to envision a learning process building a history of client activity, like a sequence of pages visited. However this

re
type of history would be of little use because it would distract from looking at the user submitted data on each URL
which is a critical part of virtually every attack.

s
ht
SecureSphere learning groups all client activity by URL and tightly classifies the data submitted into each web page
parameter. For example, a web application registration form may require an address and part of the address could

ig
be a postal code field. For clients in the United States, even a small set of unique submissions would quickly reveal
lr
the pattern of the five digit ZIP code. If client submitted letters, numbers and punctuation for a U.S. ZIP code there is
clearly something wrong. Other fields in the address, like the street name and number would be expected to contain
Al
numbers, letters and possibly punctuation characters as well, and it will almost certainly be longer than five
characters long.
c.
In

Selecting a URL from either the Tree or List view displays the learned information for the selected URL in the Profile
window.
a,
rv
pe
Im
17
20
©

Figure 5-6 - Profile Window showing selected URL and learned activity

© 2017 Imperva, Inc. All rights reserved 5-13 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

The following image shows some of the learned parameters from the SuperVeda new user registration page.

.
ed
Figure 5-7 - SuperVeda new user registration page parameters

rv
For each parameter, an expected character set is listed, along with a minimum and a maximum length. Parameters

se
that must have a value will be identified as Required and parameters that do not allow modification will be identified
as Read Only. The prefix column indicates the parameter was manually defined for tuning purposes and will be

re
discussed later.
Clicking the value type link will display the learned values for the selected parameter.

s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17

Figure 5-8 - Value types for SuperVeda Address Field

20

The expected values are defined first by the primary value type and then by the selection of any additional character
groups. The example above shows learning from the SuperVeda Address parameter which is expected to have
©

alpha-numeric values, spaces, commas and periods.

The possible primary value types are:

• Numeric
• Latin Characters
• Foreign Language Characters (UTF-8)

© 2017 Imperva, Inc. All rights reserved 5-14 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

Custom Value Type allow for a regular expression patterns to define the expected input format. The Custom Value
Type could be used for application specific ID values, or regularly formatted values like U.S. Social Security Numbers.

When the SecureSphere web profile is fully trained, every parameter on every URL in the application has an
expected character set, size and required or read-only classification. Malicious client activity like an SQL Injection
attack is easy to identify because it likely contain unexpected characters or is the wrong size.

.
Manually setting URL Learning Status

ed
The Learning Status of a URL can be updated manually by right clicking on the URL and choosing the new status
from the menu.

rv
se
URL State - Learning URL State - Protect URL State - Locked
Switch to Protect: Switch to Learn: Unlock URL:

re
s
ht
ig
Lock URL: lr Switch to Learn:
Al
c.
In

In the Folders in the URLs (Tree View), all URLs in the folder can be updated as follows.
a,

Description Folder Action Sub-Menu

rv

Change Mode URLs in

Folder
pe

Set URLs to Protect or

Im

Learn.
17

Removes all learned URLs

20

and Folders

Useful to restart learning

©

from scratch

Option only from root

folder, ‘/’ folder

© 2017 Imperva, Inc. All rights reserved 5-15 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

Description Folder Action Sub-Menu

Lock this directory:
Prevents Learning any
additional URLS

Lock all protected URLs in

this directory: Switch
Protected URLs to Locked

.
ed
Add HTTP Method to all
URLs in folder.

rv
se
re
s
ht
ig
A locked directory prevents the learning of any additional URLs. With the Default Security Policy, requests to an un-
profiled URL in the locked folder will generate block violation.
lr
Al
User Tracking
c.

The User Tracking view displays login pages used by the web clients and allows SecureSphere to track authenticated
users throughout the web application.
In
a,
rv
pe
Im
17

Figure 5-9 - User Tracking

20

All identified login URLs for the application are identified in the Action URL column. When a particular URL is
selected, the learned details of the login process are identified in the Action URL Details window.
©

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 5-16 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
Figure 5-10 - Action URL Details

ht
The Action URL Details displays the current status of the selected URL. A URL can be In Learning, Active, or in

ig
Manual Editing. SecureSphere identifies successful user login events by observing the application server’s response
to the login request. SecureSphere scans the response for one of three response types:
lr
• Redirect – The client was redirected to a URL matching the specified value
Al
• Response Code – The HTTP Response code, part of the response headers, matches a specified value
• Pattern – The response page contains text matching the specified value
c.

One or more of each condition can be tested for a given URL. When the server response matches one of the defined
In

patterns, the client login attempt is assigned the value from the Login Result column. This can be Succeeded, Failed,
or Unknown. Unknown is assigned by default and is a placeholder during the learning process. When a user
a,

successfully logs into the web application the value in the name field is retained as the name of the application user.
rv

If none of the defined patterns match the response page, the default decision is applied.
pe

Note
Im

In security, the usual decision is set the default value to the most conservative setting. In this case it would be to
default to a login failure. However, while monitoring web traffic, SecureSphere is just an observer. If a client
successfully logged in, but the response did not match the defined patterns, then the user will be authenticated
17

but be logged without a user name. Sometimes the best default decision is to default to success, because
SecureSphere will then retain the user name submitted during the last login attempt.
20
©

Cookies Learning
The SecureSphere profile identified cookies set by the web application. Some cookies are known as persistent
cookies and are issued with a long time to live. Other cookies are only valid for the duration of the client session and
are known as Session cookies. The SecureSphere profile focus is on Session cookies, due to the sensitive nature of
the session specific data contained in the cookies. Persistent cookies are primarily used for non-sensitive data. For

© 2017 Imperva, Inc. All rights reserved 5-17 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

example a persistent cookie may identify the user’s language and text size preferences for the web application,
where a session cookie may contain shopping information on an e-commerce web application.

.
ed
rv
Figure 5-11 - Profile Cookies View

se
The Cookies view displays a list of identified cookies. When a cookie is selected, the details are displayed on the

re
right. Cookies are either protected or ignored. When a cookie is protected, it is monitored for cookie tampering. If
Injection is selected, the profile also monitors for the cookie being submitted by the client that is not related to any

s
Set-Cookie events from the server.

ht
Occasionally, a temporary cookie name may include randomized or unique information for each client session.

ig
Unfortunately, since the SecureSphere profile will treat each cookie as unique, this can overload the profile. The
lr
cookie prefix checkbox indicates that the cookie name should be treated as a prefix, and any additional characters in
the name can be ignored. For example a cookie name may be VendorID09A292F, however the hexadecimal number
Al
is likely randomly assigned. Creating a new cookie with the name VendorID and selecting Prefix will remove the
variable part of the name, and will treat all future VendorID cookies the same.
c.

Learned Hosts
In

The Learned Hosts view displays the HTTP Host header value used in successful client connections to the web
a,

application.
rv
pe
Im
17

Figure 5-12 - Learned Hosts

20

The learned Hosts list is particularly helpful when determining if additional Web Application Sites Tree objects are
required for web servers supporting multiple sites.
©

Susceptible Directories
The susceptible Directories view displays web server directories that are known to contain sensitive information.
During the learning process, the profile identifies normal access to the susceptible directories. Later when the
susceptible directories are being protected, any abnormal access to the directories can be identified and blocked.

© 2017 Imperva, Inc. All rights reserved 5-18 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

Application Analysis
During the learning process, details of the overall application behavior are available for review through the following
views:

• URL Insights Graphs

• Access Patterns
• Broken Links & References

.
ed
The URL Insights graphs help visualize the learned URLs and parameters in the web application. The Access Patterns
display the amount of activity for the web application URLs. The Broken Links and References view provides a quick
location to identify any broken links in the web application.

rv
se
Managing Learning

re
Learning event exclusions

s
A key concern with any learning engine is the ability to prevent learning attack traffic. For SecureSphere web traffic

ht
must pass two strict tests in order to be eligible for learning.

ig
• Client request is clean – Request did not trigger any security policy rules
lr
• Server response is clean – No response policy violations, i.e. data leakage signatures, and server response code
is 200 or 304
Al
Security Policy rules set to Informative, or No-Alert still qualify as a policy match and will prevent triggering events
from being learned.
c.
In

Two important caveats arise from the above learning requirements. First, If all requests to a URL generate a
violation, the URL may never be learned. Second, If the web server is designed to issue a 304 redirect for invalid
a,

client requests, incorrect learning can happen.

rv

The acceptable response codes are configured under Admin > System Definitions on the Dynamic Profiling - Learning
pe

Exceptions page.
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 5-19 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
Figure 5-13 - System Definitions, Dynamic Profiling - Learning Exceptions

se
re
s
ht
Figure 5-14 - Learning Exceptions - Response Code

ig
URL Patterns
lr
URL Patterns are used to tune the profile learning process and will be covered in the tuning lesson.
Al
Optimization
c.

Optimization is used to identify potential issues with the learning process and will suggest remedies for learning
In

issues. Optimization will be discussed in the Tuning Lesson.

a,

Profile Enforcement with the Web Profile Policy

rv

The Web Profile Policy controls the reaction to abnormal client traffic that has been identified by the Web Profile.
pe
Im
17
20
©

(Screenshot on next page).

© 2017 Imperva, Inc. All rights reserved 5-20 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.

Figure 5-15 - Web Profile Policy Rules

In

The Web Profile Policy allows for fine-grained control over any concerning events identified by the profile. The only
rule set to block is the Unauthorized URL Access rule. This rule will only trigger if a client requests a non-profiled URL
a,

in a folder manually locked by a security administrator.

rv

Several powerful rules are not enabled by default because in combination with a poorly trained profile, they can
pe

generate significant numbers of false-positive violations.

Automatic Profile Updates

Im

Over time, web applications are updated and changed and it is critical that the profile remains current. It is possible
17

for the security administrators to manually switch the profile back into learning. However, the overhead of profile
maintenance can become prohibitive as the number of protected web applications grow.
20

Fortunately, SecureSphere profiles can restart the learning process through Automatic Profile Updates. The
Automatic Profile Update (APU) is a set of rules in the web profile policy which define specific thresholds required to
©

re-initiate learning. For security minded individuals, the possibility of the profile automatically restarting the learning
process may raise some concerns. However, Web Security Administrators have full control of this process.

Automatic Profile Update safety:

• APU changes only effect the URLs or Cookies that require updating, other URLs and Cookies remain protected.
• Security Admins can prevent automatic updates on sensitive URLs by Locking the URL in the Web Profile.

© 2017 Imperva, Inc. All rights reserved 5-21 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

• Security Admins can set the threshold to restart learning for every APU condition.
• Security Admins can disable each APU condition.

APU settings are located on the Web Profile Policy, Advanced tab.

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17

Figure 5-16 - Web Profile Policy, Advanced tab, Automatic Profile Update settings
20

Each APU rule has a specific threshold of activity that must be reached to initiate the switch to learning. Automatic
Profile Updates for each aspect of the profile policy can be configured or disabled. De-selecting Enabled will disable
©

automatic profile updates for the rule. For example, a company knows the core web application may change over
time, but does not foresee any changes to cookie names or the structure of the information stored in the cookies. In
that context, de-selecting Enabled for Cookie Injection and Cookie Tampering APU rules will prevent the profiled
cookies from being switched back to learning automatically.

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 5-22 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

The default values for all APU Rules are:

• 50 Distinct Sources (i.e. 50 unique IPs or Session IDs)

• 50 Unique occurrences
• Over 12 Hours
The following show the thresholds for the Parameter Type Violation rule.

.
ed
rv
se
re
s
ht
ig
Figure 5-17 - APU Settings for Parameter Type Violation rule
lr
From the Parameter Type Violation above, if more than 50 unique violations from 50 or more unique clients occur
within a 12 hour timeframe, the affected URL is switched back into learning.
Al
All Profile learning state changes are logged in the System Events logs. The following shows the switch to protect
c.

event for the URL home.asp.

In
a,
rv
pe
Im
17
20

Figure 5-18 - System Events Log showing home.asp being set to protect

Automatic Profile Updates and Server Group Mode

©

The interaction between the APU and Sever Group mode may also generate some questions. It helps to remember
that the profile’s activity is focused on the traffic. Initially built the profile by learning from normal client requests,
and then to identify abnormal events and pass those events onto the Web Profile Policy. The server group mode
only impacts the Web Profile Policy and when set to simulation, will prevent blocking actions from taking place.

© 2017 Imperva, Inc. All rights reserved 5-23 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

The following table identifies the responses to client traffic and Automatic Profile Update count.
Server Group’s Profile Page’s Profile Policy Rule: Response to Client Profile
Operation Mode: Current State: Action Enabled Traffic
Active Protect Alert & Block + APU count
Simulate Protect Alert, No Block + APU count
YES

.
Active Learn No Alert, No Block Learn, Update Profile

ed
Block
Simulate Learn No Alert, No Block Learn, Update Profile
Active or Simulate Protect No Alert, No Block Does not affect APU

rv
NO
Active or Simulate Learn No Alert, No Block Not Learned

se
Table 5-13 - Profile Enforcement

Additional Rules for tuned profiles

re
With a well maintained Web Protocol Policy, the following Web Profile Rules will provide additional profiling

s
Benefits:

ht
Rule Name Rule triggers when: False Positive Likely When: Benefit

ig
Parameter Length A Submitted parameter • Short Learning period Excellent identification of
Violation is shorter/longer than • Low traffic URLs
lr all overflow attacks and
expected. • Application Changes nearly all injection attacks.
Al
Required Parameter A parameter identified • Short Learning period When correct, strongly
Not Found as required is not • Low traffic URLs indicates intentional
c.

present • Application Changes misbehavior of client

In

Reuse of Expired The Client receives a • Browser issues Can identify cookie replay
Session’s Cookie new session identifier • Application design attacks and session
a,

but continues to include • Browser side scripting hijacking attempts

rv

Note: Applies to old identifiers assigned

Protected cookies. to an expired session.
pe

Unknown Parameter An un-profiled • Short learning period When correct, can indicate
Im

parameter was present • Application Changes client is probing for

in the client request • Low traffic URLs vulnerabilities or useful
• Browser side scripting error messages
17

Table 5-14 - Web Profile Policy Rules Suitable for Well-Tuned Profiles
20
©

© 2017 Imperva, Inc. All rights reserved 5-24 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

Profile Reports
Each aspect of the profile learning process is logged and available to reporting. The following Web Profile report
types are available:

• Web Profile – URLs

• Web Profile – URL Patterns
• Web Profile – Cookies

.
• Web Profile – Learned Hosts

ed
• Web Profile – Susceptible Directories
• Web Profile – Web Application User tracking

rv
se
Generally profile reports will be customized for the environment. The following examples may prove helpful when
working with the SecureSphere Web Profile in active environments.

re
Web Profile URLs Report

s
ht
Web Profile URLs reports are a core report for documenting the learned URLs, the learning status of the URLs as
well as gaining visibility into the parameter learning. The following example report will be limited to newly learned

ig
URLs for the SuperVeda Web Application.
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 5-25 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17

Figure 5-19 - Web Profile URLs Report, General Details

20

• Providing a descriptive name is especially helpful as the number of reports grow.

• Providing a description is also recommended.
o An example of helpful information for the description will be shown momentarily.
©

• For PDF reports, the Landscape Orientation is often easier to read.

• Headers can be used to identify the sensitivity or confidentiality of the resulting report.
• Keywords allow related reports to be identified and reported

© 2017 Imperva, Inc. All rights reserved 5-26 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
Figure 5-20 - Web Profile URLs Report, Data Scope

re
The report is restricted to the SuperVeda Web Application and only displays URLs with at least one parameter,
number of parameters greater than 0, and which have been created within the last 90 days.

s
ht
Notes on the Data Scope configuration:

ig
• The Last 90 Days requirement makes this report only suitable during the initial learning period of the Profile, or
lr
for identifying new URLs learned during Automatic Profile Updates. This would be an important detail to
include in the report description.
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 5-27 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe

Figure 5-21 - SuperVeda Web Profile URLs, Tabular

The column selection will be highly dependent on local requirement and the provided configuration is specific to
Im

SuperVeda due to the lack of SOAP and XML / JSON data elements.
17

Notes on the Tabular configuration:

• Sorting by Number of Parameters Descending moves the pages with the most parameters to the top which can
20

help identify URLs with dynamic parameters.

• The Selected columns provide details on the learning for each parameter including:
o The Learning State of the URL – Learning or Protected.
©

o The timestamp of the learning state change, giving visibility into manual and automatic profile updates.
o The expected data type for the parameter plus any additional characters.
• A title for the table is recommended, but missing from the example.

© 2017 Imperva, Inc. All rights reserved 5-28 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

Figure 5-22 - SuperVeda Web Profile URLs, Data Analysis Views

The Data Analysis Views selection is also highly dependent on local requirements. The first graph provides view of
Profile URLs set to Learning or Protected. The second graph showing the Locked vs Unlocked URLs.

© 2017 Imperva, Inc. All rights reserved 5-29 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

Notes on the Data Analysis Views configuration:

• Over time, one would expect the number of URLs Protected to grow as the profile learns the normal client
activities for each parameter.

Web Profile Cookies Report

.
Web Profile Cookies report documents the name and learning state of the learned cookies. The following example

ed
report displays learned cookies for all sites in the training environment.

rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

Figure 5-23 - Web Profile Cookies, General Details

© 2017 Imperva, Inc. All rights reserved 5-30 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

(continued on next page)

The recommendations for the General Details settings are the same as in the previous report example. Since this
report is not limited to a single site, no conditions for the Data Scope are set. However, with larger deployments,
setting a Data Scope to limit the report size is would be recommended.

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe

Figure 5-24 - Web Profile Cookies, Tabular

Im

The selected columns will depend on the local requirements, this example focuses on the cookies for each
application, the learning status and last update time.
17
20

Web Profile Learned Hosts Report

Web Profile Learned Hosts reports identifies all valid Hosts identified from normal client connections. This
©

information is particularly helpful for identifying hosts that justify the creation of additional SecureSphere
Applications.

The following example report displays learned cookies for all sites in the training environment and the General
Details tab is configured similarly with the previous two examples.

© 2017 Imperva, Inc. All rights reserved 5-31 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

(Screenshot on next page)

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe

Figure 5-25 - Web Profile Learned Hosts, Tabular

Im

In this example, the all columns are selected and ordered to display the learned HOST headers by each application.
The Occurrences column provides visibility into the number of client requests seen for each identified HOST.
17
20
©

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 5-32 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

Review Questions
• Name three types of information in a client’s web request that can be profiled.
• What are the possible learning states for a URL?
• What is Automatic Profile Update (APU)?
• Describe at least two ways to control the APU behavior?
• Pick a Web Profile Policy Rule and give an example of bad client behavior that could be identified by the rule.
Refer to the SecureSphere web interface in your lab environment or from the Profile Policy figure in this lesson.

.
ed
Exercises

rv
Prerequisite:

se
Important

re
Before beginning the exercises, you must complete the steps detailed in the following class interactive sections.
1. SuperVeda Lab Preparation.

s
ht
Exercise 1

ig
Use the Use Firefox and Web inspect tool to Identify information from HTTP Requests and Responses to the
lr
SuperVeda Web application.
Al
• How to use Firefox Web Inspect:
o On ClientPC start Firefox and create a New Tab by clicking the + icon to the right of the current tab:
c.
In
a,
rv
pe

o Click the Tools menu, then mouse over Web Developer and click Web Console. The console opens at the
bottom of the Firefox window.
Im
17
20
©

(Screenshot on next page)

© 2017 Imperva, Inc. All rights reserved 5-33 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
o Click the downward pointing arrow on the right side of the Net button, and ensure that Log is checked.
Al
c.
In
a,
rv
pe

o In the URL bar of the new tab, enter http://www.superveda.local and press Enter. The SuperVeda
home page opens, and the Web Console shows the HTTP GET requests.
Im
17
20
©

(Screenshot on next page)

© 2017 Imperva, Inc. All rights reserved 5-34 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

o Click one of the GET requests to view the details in the Inspect Network Request window.

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In

• Using Firefox Web Inspect, perform the following actions:

a,

o Find an example of Request Headers.

o Find an example of Response headers.
rv

o Find an example of a Session Cookie.

o Identify a request URL that includes the Username & Password parameters in the URL
pe

 Login Information: Username: bugsb, Password: carrots

o Identify a response that includes a new or changed cookie (Shown as Received Cookie in the Inspect
Im

Network Request window).

Hint: It may require looking at several URLs. Focus on the URL ending with asp.
17
20

Exercise 2
Protect and lock the login.asp URL for the SuperVeda – Web Application.
©

View the Login Page Source code to identify the expected length of the username and password values. Configure
the Username and Password parameter size restrictions as follows:
Parameter Minimum Maximum
Username 2 <Number found in page source>
Password 4 <Number found in page source>
Note

© 2017 Imperva, Inc. All rights reserved 5-35 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

The SuperVeda Website uses frames. The simplest way to view the Page Source of a frame is to Right-Click on the
desired frame and select This Frame > View Frame Source.

.
ed
rv
se
re
s
ht
ig
Exercise 3
lr
Configure User Tracking for the SuperVeda – Web Application as follows:
Al
It may be desirable to manually configure the user tracking settings. The following details how this can be done with
c.

the SuperVeda Web Application.

In

1. Verify the application behavior for successful and failed login attempts as follows:
a. Use Internet Explorer to access the SuperVeda Website.
a,

b. Select .
c. At the login prompt enter an incorrect username and password.
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 5-36 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

d. Click and note the application response.

.
ed
rv
e. Note the following:

se
1. The page was not redirected, so matching a Redirect condition will not work for failed logins.
2. The page loaded normally and likely had a standard 200 Response code so the Response code condition

re
will probably not work for failed logins.
3. The page does include text indicated the login failed, so a Pattern condition can work for failed logins.

s
f. Next log in with a valid Username and Password.

ht
Username: bugsb.
Password: carrots.

ig
g. Click and note the application response.
lr
h. Note the following:
Al
1. The successful login was completed with a redirection so a Redirection condition can be used to identify
successful logins.
c.

2. Identifying the resulting URL may take some investigation but in the case of SuperVeda the URL is
home.asp which is will also be identified with sufficient learning.
In

2. Log into SecureSphere and, from the Main workspace, select Profile > Application View.
a,
rv
pe
Im
17
20
©

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 5-37 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

3. Expand the sites tree and select SuperVeda Web SG, SuperVeda - Http – Service, SuperVeda - Web Application.

.
ed
rv
se
re
s
ht
4. Select the User Tracking view.

ig
lr
Al
c.
In
a,
rv
pe

5. Select the Action URL: /login.asp.

6. Set the Action URL Status to Manual Editing.
Im
17
20
©

7. Click to save changes.

8. Click twice to add two rows the Action URL Details table.

9. Configure the two rows as follows:

© 2017 Imperva, Inc. All rights reserved 5-38 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

a. Row 1, Type: Pattern, Value: Invalid Username or Password, Login Result: Failed.
b. Row 2, Type: Redirect, Value: home.asp, Login Result: Succeeded.

10. Set the Default Decision to: Succeeded.

11. Set the Action URL Status to: Active.

.
12. Click to save changes.

ed
Note

rv
Verifying the User Tracking settings will be discussed later in the Alerts & Violations lesson.

se
re
Exercise 4

s
ht
Clone the Web Profile Policy and name the new policy Vedaadmin Profile Policy.

ig
Enable the following rules:

• Parameter Value Length Violation

lr
Al
• Unknown Parameter

Configure the Parameter Type Violation as follows:

c.

• Severity: High
In

• Action: None
• Followed Action: SV - Violation – Send to VedaDB Syslog
a,
rv

Exercise 5
pe

Create two reports.

Im

Report 1: Create a Profile URLs report following the Web Profile URLs Report section earlier in the lesson.
Note, if a suitable keyword is not available this step can be skipped.
17

Report 2: Create a profile report of your choice. If you are pressed for time, consider creating a Cookies or Learned
Hosts profile report with data scope restrictions limiting the report to the SuperVeda site.
20

Answers to Review Questions

©

• Name three types of information in a client’s web request that can be profiled.
o Cookies, Host Header name, Parameters, Methods, XML / JSON / Other data exchange formats, URLs
• What are the possible learning states for a URL?
o Learning, Protected, Protected and Locked
• What is Automatic Profile Update (APU)?

© 2017 Imperva, Inc. All rights reserved 5-39 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

o The Automatic Profile Update is a SecureSphere feature that allows protected profile pages and cookies to
automatically switch back into learning when a specific pattern of profile violations occurs. By Default, the
Automatic Profile Update thresholds for web are: 50 Unique Sources, 50 Occurrences, over 12 hours.
• Describe at least two ways to control the APU behavior?
o Lock URL, Adjust Thresholds, Uncheck Enabled checkbox
• Pick a Web Profile Policy Rule and give an example of bad client behavior that could be identified by the rule.
o Answers vary, discuss with instruction and class.

.
ed
Answers to Exercise

rv
Exercise 1

se
Note: Answers may vary.

re
• How to use Firefox Web Inspect - Explained in Exercise.
• Using Firefox Web Inspect, perform the following actions:

s
o Find an example of Request Headers.

ht
ig
lr
Al
c.
In
a,
rv

o Find an example of Response headers.

pe
Im
17

o Find an example of a Session Cookie.

20
©

o Identify a request URL that includes the Username & Password parameters in the URL

© 2017 Imperva, Inc. All rights reserved 5-40 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

• Identify a response that includes a new or changed cookie.

.
ed
rv
se
re
s
ht
ig
Note lr
The cookie names and values will vary based on Client Activity. Other cookies can be seen by logging in to the
Al
SuperVeda website with different customer accounts.
c.
In

Exercise 2
Protect and lock the login.asp URL for the SuperVeda – Web Application.
a,

Select Main > Profile > Application View, expand the Sites Tree and select the SuperVeda - Web Application.
rv

From the URLs (Tree View) or URLs (List View) locate the login.asp URL.
pe

Right-Click the URL and select Switch to Protect.

Im
17
20

Right Click the URL again and this time select Lock URL
©

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 5-41 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

View the Login Page Source code to identify the expected length of the username and password values. Details for

.
ed
viewing the login frame were provided in the exercise. The login source code show the following values for the
Username and Password parameters:

rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe

With this information the minimum and maximum values are all known:
Parameter Minimum Maximum
Im

Username 2 20
Password 4 22
17

These are configured in the Profile as follows:

20
©

(Screenshot on next page)

© 2017 Imperva, Inc. All rights reserved 5-42 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In

Click to save changes.

a,

Exercise 3
rv

The individual steps were documented in the exercise itself. The Action URL Details will look similar to the following.
pe
Im
17
20
©

The Response Code type can be with a Login Result of Unknown or the row can be removed.

© 2017 Imperva, Inc. All rights reserved 5-43 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

Exercise 4
Clone the Web Profile Policy and name the new policy Vedaadmin Profile Policy.

Enable the following rules:

1. Parameter Length
2. Unknown Parameter
Configure the Parameter Type Violation as follows:

.
ed
• Severity: High
• Action: None

rv
• Followed Action: SV - Violation – Send to VedaDB Syslog

se
• Select Main > Policies > Security.
• Click to create a new Web Application security policy.

re
s
ht
• Configure the Create New Policy window as follows:

ig
Name: Vedaadmin Profile Policy
Select Use Existing > Web Profile Policy lr
Al
c.
In
a,
rv
pe

• Click .
Im
17
20
©

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 5-44 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

• The following screenshot shows the policy configured based on the requirements.

.
ed
rv
se
re
s
ht
ig
lr
Al
• Click to save changes.
c.
In

Exercise 5
Create two reports.
a,

Report 1: Create a Profile URLs report following the Web Profile URLs Report section earlier in the lesson.
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 5-45 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

(Continued on next page)

Tabular Settings:

© 2017 Imperva, Inc. All rights reserved 5-46 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 5-47 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

Data Analysis Views:

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17

(Continued on next page)

20
©

© 2017 Imperva, Inc. All rights reserved 5-48 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

Example of Report Results:

Data Analysis Views:

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 5-49 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

Tabular Results:

.
ed
Report 2: Answers will vary.

rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 5-50 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 5-51 Lesson Chapter 5: Web Application Profiling
SecureSphere 12.0 Web Application Security Course Manual

SecureSphere ThreatRadar
Chapter Overview
ThreatRadar is a premier threat intelligence data feed for SecureSphere Web Application Firewalls. In this lesson we
will discuss the configuration of ThreatRadar data feeds and corresponding white lists, application of predefined
ThreatRadar security policies, creation of custom security policies, configuration controls over data shared in the

.
Intelligence (Community Defense) program and ThreatRadar Bot Protection.

ed
Chapter Objectives

rv
se
• Identify and configure appropriate ThreatRadar feeds to help secure web applications
• Identify when to use and how to configure TR Reputation Services

re
o Anonymous Proxies
o Comment Spam IPs

s
o Geo Location & IP Forensics

ht
o Malicious IPs
o Phishing URLs

ig
o TOR IPs
lr
• Identify when to use and how to configure ThreatRadar Bot Protection
o Identify differences between Bot Protection and Bot Mitigation
Al
• Identify when to use and how to configure Intelligence (Community Defense)
o Remote File Include (RFI)
c.

o SQL Injection IPs

In

o Scanner IPs
• Identify environments that may benefits from ThreatRadar Fraud Prevention Services
a,

Threat Landscape
rv

The internet has provided criminals a historically unique opportunity for crime. Attacks can be performed from
pe

anywhere in the world and criminals have proven very effective at hiding their tracks, resulting in few actual
prosecutions for criminal activities. With the large number of vulnerable web applications, the criminals have nearly
Im

unlimited opportunities to learn and improve their attacks and with powerful automation tools, the number of
attacks is also increasing. Altogether, it translates into increasingly spectacular attacks with stunning consequences,
17

exemplified by any of the recent high profile breeches in the news.

20

The first order of business for attackers is to hide their tracks and multiple strategies are used in this effort. A very
common tool is the Anonymous Proxy. This is a web proxy server that forwards web requests, without including
information on the true origin of the client.
©

Another tool of attackers is the botnet. A botnet is a collection of malware-compromised computers controlled by
the attacker. The attacker manages the infected systems and distributes attack actions for the systems to perform.
Botnets allow attack activity to be distributed, ensuring another system is able to continue the attack any time a
system is blocked. From the target’s perspective, the activity may appear independent and recognizing that that it is

© 2017 Imperva, Inc. All rights reserved 6-1 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

coordinated attack can prove difficult. Botnets also hide the attacker’s tracks behind a veil of infected systems and
the unlucky users who happened to get malware on their systems.

The following common botnet activities are of particular concern when protecting web applications:

• Attack preparation
o Web site reconnaissance
o Vulnerability scans

.
o Web Application Fuzzing

ed
• Attacking Web Applications
o SQL Injection

rv
o Denial of Service

se
o Directory Traversal & Site Scraping
• Attacking Clients

re
o Password brute force attacks
o Phishing Attacks

s
o Comment Spam

ht
o Remote File Inclusion Attacks

ig
Although the attack tools used by hackers are potent and menacing the attacks still originate from specific locations.
lr
Over time the locations will change, but a regularly updated list of attack locations will allow for an aggressive
Al
response against bad actors and, most importantly, combats some of the most powerful attack tools used.
Imperva’s ThreatRadar threat intelligence provides this visibility into the reputation of clients and for some
protections is able to actively challenge the client to identify regular users from bad actors.
c.
In

Imperva ThreatRadar
a,

ThreatRadar is the premier threat intelligence feed that arms the SecureSphere Web Application Firewall.
ThreatRadar is a subscription service which provides the following protections.
rv

• Reputation Service: Filters traffic based upon latest, real-time reputation of source
pe

• Intelligence (Community Defense): Adds unique threat intelligence crowd-sourced from Imperva users
• Bot Protection: Detects botnet clients and application DDoS attacks
Im

• Account Takeover Protection: Protects website user accounts from attack and takeover
• Fraud Prevention: Simplifies deployment of best-in-class partner fraud prevention solutions
17

ThreatRadar Intelligence Services

20

ThreatRadar Intelligence Services provide visibility into the reputation of clients connecting to SecureSphere
protected web application. Imperva provides the following ThreatRadar Services:
©

difference between the reputation services and Intelligence (Community Defense) feeds is source of data.
Reputation service feeds are assembled from information gathered with server honeypots, active research by the
Imperva Application Defense Center team as well as through data feed partners. The Intelligence (Community
Defense) feeds are built from information provided by existing SecureSphere customers through the Intelligence
(Community Defense) program. Altogether ThreatRadar provides ten unique feeds that provide insight into client
connections.

© 2017 Imperva, Inc. All rights reserved 6-2 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

Service Data Feed Protects For

Intelligence (Reputation Services)
Anonymous Proxies Anonymous Proxy servers that hide the client IP address
Comment Spam IPs Unwanted advertisements posted websites from the IP
address.
Geo Location IP Analysis feed that allows country of origin
identification of client

.
IP Forensics IP Analysis feed that allows geographic location mapping

ed
of client
Malicious IPs Numerous attacks originated from the IP address

rv
Phishing URLs URL or Referrer header is associated with Phishing

se
activities for the protected web application.
TOR IPs IP address belongs to The Onion Router (TOR). TOR is

re
used to obfuscate the client’s real IP address.
Intelligence (Community Defense)

s
Remote File Include Numerous SecureSphere community reports of Remote

ht
File Inclusion attacks
SQL Injection IPs Numerous SecureSphere community reports of SQL

ig
Injection attacks
Scanner IPs lr
Numerous SecureSphere community reports of site or
vulnerability scans
Al
Anti-Automation (Bot Protection)
CAPTCHA Automated BOT activity like comment spam submissions
c.

or website scraping.
In

ThreatRadar Bot Protection Bad or malicious BOT activities.

Emergency Feed
a,

Blocking Authenticated Sessions Rapidly emerging and high profile vulnerabilities such as
Blocking GET requests Zero-Day attacks and large scale exploit behaviors.
rv

Blocking General requests

pe

Blocking POST requests

Detection
Im

Account Takeover Protection

Credential Stuffing Botnet attacks testing stolen credentials against other
high value web applications.
17

Device Intelligence Attacks leveraging compromised devices used that may

have been used in other attack campaigns.
20

Dictionary Attack Brute force credentials guessing attacks using common

passwords.
©

Privileged Account Brute force Brute force credentials guessing attacks targeted at high
privilege accounts.
Fraud Prevention Services
ThreatMetrix TrustDefender Covert attacks due to malware on the client’s system.
iovation ReputationManager 360
Trusteer Pinpoint

© 2017 Imperva, Inc. All rights reserved 6-3 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

Table 6-1 - ThreatRadar Reputation and Intelligence (Community Defense) data feeds

The data feed information is regularly updated by the MX and stored in SecureSphere as a lookup data set - global
object. The lookup data set is then used in security policy’s match criteria.

ThreatRadar Intelligence (Reputation Services)

ThreatRadar data is regularly retrieved by the SecureSphere Management Server and stored in Lookup Data Sets. A

.
Lookup Data Set is a Global Object that contains a table of key identifiers and is used by the Gateway to identify

ed
traffic that matches a key value. For ThreatRadar Lookup Data Sets, the key values are IP addresses identified by
Imperva’s Application Defense Center team as sources of concerning activity. Each ThreatRadar feed has a

rv
corresponding ThreatRadar Lookup Data Set, allowing the identification of unwanted clients based on previous
behavior.

se
re
The status of each ThreatRadar Data Feed is displayed on the dashboard. Select Main > ThreatRadar > Dashboard.

s
ht
ig
lr
Al
c.

Figure 6-1 - ThreatRadar Dashboard Location

In

If ThreatRadar is un-licensed, it is still available on an emergency basis. The Emergency Activation option allows one-
time access to the ThreatRadar updates for a period of three days.
a,
rv
pe

Figure 6-2 - ThreatRadar Emergency Activation

Im

Emergency Activation is intended to help address large attack events against the protected web applications in the
event that ThreatRadar was not previously purchased. If Emergency Activation is selected, Imperva technical
support will also contact the organization to ensure the emergency is fully understood and mitigated.
17
20
©

© 2017 Imperva, Inc. All rights reserved 6-4 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

The Dashboard displays each ThreatRadar feed and indicate the status and feeds experiencing problems are clearly
identified.

.
ed
rv
se
re
s
ht
Figure 6-3 - ThreatRadar Data Feeds Status

ig
lr
Selecting a feed displays summary and management options for the feed and feed status details if update problems
Al
were encountered. The following shows an example of the Anonymous Proxies data feed Summary tab:
c.
In
a,
rv
pe
Im
17

Figure 6-4 - ThreatRadar Anonymous Proxies Summary tab

20

For each data feed, the summary tab displays statistics on the number of policy violations based on the feed. The
data feed Manage shows Lookup Data Set, predefined security policies and predefined reports.
©

© 2017 Imperva, Inc. All rights reserved 6-5 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
Figure 6-5 - Anonymous Proxy Manage Tab

s
The pencil icon can be used to quickly review the relevant configuration objects. Scheduling and detailed

ht
configuration of the data feed are configurable through the Lookup Data Sets.

ig
ThreatRadar Lookup Data Sets lr
Al
The lookup data set can be reached from the ThreatRadar Dashboard or directly from Global Objects.
Viewing the ThreatRadar- Malicious IPs Lookup Data Set from the dashboard.
c.

Viewing the ThreatRadar Lookup Data Set from the Dashboard:

In

Select Main > ThreatRadar > Dashboard. Select the relevant ThreatRadar Data feed and from the Manage Tab click
the Pencil icon to open the Lookup Data Set. The example below shows the process for the Malicious IPs data feed.
a,
rv
pe
Im
17
20
©

Figure 6-6 - Locating Threat Radar Data Feed Configuration Details From Threat Radar Dashboard

Viewing the ThreatRadar Lookup Data Set from Global Objects:

Select Main > Setup > Global Objects, Scope Selection: Lookup Data Sets to view the ThreatRadar Lookup Data Sets.
The ThreatRadar Lookup Data Sets can be reached from both the ThreatRadar Dashboard and from the Global
Objects.

© 2017 Imperva, Inc. All rights reserved 6-6 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
Figure 6-7 - Locating Threat Radar Data Feed Configuration Details From Global Objects

s
ht
The ThreatRadar Lookup Data Set contains the listing of reputation data for use while inspecting web traffic. From

ig
the Data tab, the existing values can be reviewed. In the following screenshot, the Quick Filter, Page Selection and
Malicious IP addresses are identified. lr
Al
c.
In
a,
rv
pe
Im
17
20
©

The ThreatRadar Lookup Data Set is updated regularly. The update frequency is determined by Imperva’s
Application Defense Center based on the rate of changes to the ThreatRadar feeds and are ultimately driven by the
frequency of change in the specific type of concerning behavior. The example below shows the Malicious IP list
scheduled for daily updates.

© 2017 Imperva, Inc. All rights reserved 6-7 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ThreatRadar Phishing URLs

ht
The ThreatRadar Phishing URLs data feed requires manual configuration before it can receive updates. The

ig
configuration limits the update to just the URLs of the protected web assets. The Phishing URLs lookup data set
lr
must be configured with the valid host headers accepted by the protected web applications.
Al
Configuring ThreatRadar Phishing URLs
1. Select Main > ThreatRadar > Dashboard
c.
In
a,
rv
pe
Im
17
20

Note the warning which indicates the Phishing URLs feed is un-configured.
©

© 2017 Imperva, Inc. All rights reserved 6-8 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

2. In the Phishing URLs window, Manage tab, select pencil icon for the ThreatRadar Phishing URLs Lookup Data
Set. The Lookup Data Set: ThreatRadar – Phishing URls window will appear.

.
ed
Select the Configuration tab and click Configure.

rv
se
re
s
ht
ig
3.
4. Under Add Domain Names, click the Create
lr
button to add one or more rows to the table.
Al
5. Add one host header per line. The following screenshot shows the SuperVeda ecommerce website host header
added to the Phishing URLs configuration.
c.
In
a,
rv
pe
Im
17
20
©

6. For the SuperVeda training lab, add www.superveda.local and click Update to save the configuration.

Note
The ThreatRadar Dashboard warning will be cleared during the next Phishing URLs update which can take up to
one hour.

© 2017 Imperva, Inc. All rights reserved 6-9 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

ThreatRadar Predefined Security Policies

ThreatRadar includes the following predefined, auto-applied security policies:

• ThreatRadar - Anonymous Proxies

• ThreatRadar - Comment Spam IPs
• ThreatRadar - Malicious IPs
• ThreatRadar - Phishing URLs

.
• ThreatRadar - SQL Injection IPs

ed
• ThreatRadar - Scanner IPs
• ThreatRadar - TOR IPs

rv
These policies are applied by default with an action of None. However, the full benefit of ThreatRadar are realized

se
when unwanted clients are blocked as early. Typically organizations will set the policy actions to Block after an
appropriate trial period with a reviews of the security logs to rule out any false positive events.

re
The following table identifies possible exceptions to blocking for each ThreatRadar Security Policy:

s
ht
ThreatRadar Policy Action Possible Exceptions
Block unless clients have a compelling reason to hide their source IP address.

ig
For example, a news submission page for war correspondents. In such cases,
Anonymous Proxies Block lr
blocking can be performed with a custom policy that identifies clients both
using Anonymous Proxies and triggering other high severity violations.
Al
Extremely low traffic web applications or web applications without
Comment Spam IPs Block
comments areas.
c.

Malicious IPs Block None - Blocking is recommended for all web applications.
In

Phishing mostly targets user logins. If the protected web application does
Phishing URLs Block
not allow user login, Phishing URLs policy may not be needed.
a,

SQLI IPs Block None - Blocking recommended for all deployments

Scanning IPs Block None - Blocking recommended for all deployments
rv

Block unless clients have a compelling reason to hide their source IP address.
TOR IPs Block
pe

(See Anonymous Proxies - above)

Table 6-2 - ThreatRadar Policy Recommendations
Im

ThreatRadar security policies follow a very similar format and only vary in the Lookup Data Set Match Criteria. The
ThreatRadar - Anonymous Proxies policy shows the basic structure.
17
20
©

(Screenshot on next page)

© 2017 Imperva, Inc. All rights reserved 6-10 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv

Figure 6-8 - ThreatRadar Anonymous Proxies Security Policy

pe

Each of the policies contains just two match criteria, one matching the data feed and the second excluding whitelist
values. While the ThreatRadar feed is automatically updates, the white list requires manual configuration.
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 6-11 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

Figure
6-9 -

.
ed
rv
se
re
s
ht
Predefined ThreatRadar Security Policy Match Criteria Logic

ig
For some deployments, directly blocking on the ThreatRadar feeds may touch on concerns about accidentally
lr
blocking legitimate users. In such cases, a custom security policy that correlates the data feed along with other
Al
violations may be appropriate. The following example shows a security policy that may be appropriate for a news
organization with an anonymous tips site. The predefined ThreatRadar - Anonymous Proxies and ThreatRadar - TOR
IPs security policies would be left in the default, non-blocking, configuration.
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 6-12 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
Figure 6-10 - Custom Policy for Anonymous Proxies and TOR IPs Data Feeds
c.
In

As configured, the example policy is only looking for fifty serious violations within a minute from an anonymous
proxy or TOR IP address. The policy could be made more aggressive by matching more violations, reducing the
a,

number of occurrences required, or increasing the occurrence time. The policy could be made more permissive by
rv

using less violations, increasing the required occurrences, or by decreasing the occurrence time.
pe

ThreatRadar Geolocation and IP Forensics

Im

The ThreatRadar Geo Location and IP Forensics data feeds meet a separate goal from the data feeds discussed so
far. Instead of identifying a list of known bad actors, the Geo Location and IP Forensics feeds provide geographical
17

insights into the source of violations. The ThreatRadar IP Forensics feed is responsible for resolving a geographical
location from the clients source IP. The ThreatRadar Geo Location feed resolves the country of origin from the
20

clients IP address.

Initially, these feeds will prove helpful for investigating alerts or violations from the Securesphere security event logs
©

and for use in alerts and violations reports. As patters of unwanted activity become clear, the ThreatRadar Geo
Location and IP Forensics feeds can inform custom security policies through the Source GeoLocation Match Criteria.
The Source GeoLocation Match Criteria allows resolution of source IP address to a country of origin and can prove
immensely useful in highly customized security policies. For example, a government motor vehicles office may use
the Source GeoLocation to block international clients from specific areas of the web application.

© 2017 Imperva, Inc. All rights reserved 6-13 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

The following SuperVeda example shows a policy configuration designed to prevent international login attempts to
the SuperVeda Administration website.

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In

Figure 6-11 - Security Policy using Source GeoLocation Match Criteria

a,

ThreatRadar Intelligence (Community Defense) Feeds

rv
pe

ThreatRadar Intelligence (Community Defense) feeds are built from data provided by other SecureSphere customers
and comes with different licensing. Imperva customers have full control over the data submitted back to the
Im

Intelligence (Community Defense) system. Licensing fees are waived for customers who are able to contribute data
back to the community. For organizations that cannot provide this information, they can still receive the Intelligence
(Community Defense) data by purchasing the appropriate license.
17

The status of the Intelligence (Community Defense) contributions are visible from the ThreatRadar Dashboard >
20

Intelligence (Community Defense) service, Manage Tab.

ThreatRadar Intelligence (Community Defense) is automatically enabled for SecureSphere versions 11.5 and 12.0.
©

For SecureSphere version 12.0, this is enabled during the upgrade process, or during the license upload, for new
deployments. For version 11.5 Community Defenese is enabled by patch (Q1-2017 patch or later).

The ThreatRadar Intelligence (Community Defense) settings can be verified from the ThreatRadar Dashboard as
follows:

© 2017 Imperva, Inc. All rights reserved 6-14 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

From Main > ThreatRadar > Dashboard select Intelligence (Community Defense). On the details pane, select the
Manage tab to display the collection and submission settings.

.
ed
rv
se
re
SecureSphere provides detailed controls over the data collected and the collected data can be reviewed to help

s
ensure sensitive information are not accidentally captured and sent to the Intelligence (Community Defense)

ht
system.

ig
Data Element Types:

• Header
lr
Al
• Parameter
• Cookie
c.

• Event Part – Destination IP Address

In

• Event Part – Destination Geo Location

• Event Part – Destination Host Name
a,

• Event Part – Session ID

• Event Part – Server Group
rv

Masking Options:
pe

• Hash
• Hide first 12 chars
Im

• Remove
17

Hashing is irreversible and is used by the Intelligence (Community Defense) system to correlate malicious activity
while preventing exposure of potentially sensitive information. By default, hashing is used for the destination IP,
20

destination Host Name, and the Server Group name. Hide first 12 characters masks the first 12 characters and
allows the remaining information to be sent to the Intelligence (Community Defense) system. This is particularly
©

useful when the expected input is normally rather short, like a user’s login name. Injection and buffer overflow
attempts will be preserved and available for analysis in the Intelligence (Community Defense) system. Remove will
not send the data at all. By default the Referrer, Cookie and Authorization headers use the Remove masking action.

To participate in providing data to the Intelligence (Community Defense) system, several steps are required.

• Select Collect Violation Information to start reviewing the collected information.

© 2017 Imperva, Inc. All rights reserved 6-15 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

• Review the collected data, looking for potentially sensitive information that should be masked.
• Configure Masking to address collection issues and review results.
o Continue to review and mask until satisfied with the masking rules.
• Select Send Collected Information to begin participating in Intelligence (Community Defense).

Configuring Intelligence (Community Defense) data masking in the SuperVeda Environment

1. Select Main > ThreatRadar > Dashboard

.
ed
2. Select the Intelligence (Community Defense) Service, Manage tab.

rv
se
re
s
ht
ig
lr
Al
3. Select Collect Violation Information and save changes to begin Collecting Data.
c.
In
a,
rv

4. In a production environment, wait for a new violation to occur. In a testing environment, generate traffic that
will create a violation.
pe

5. Click the Show button under Data Sample to view the results.
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 6-16 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

6. The Data Sample for Sharing window will appear with the details for a single violation.

.
ed
rv
se
re
s
ht
ig
lr
Al
7. Review the handling of sensitive values:
c.

a. Are values set the Remove masking operation properly masked? The following example shows a cookie
In

properly masked: "cookies":[{"name":"Privileges","maskingType":"Remove","origLength":4}

b. Are values set to be hashed properly masked? The following example shows a Destination IP address
properly masked:
a,

"destAddr":{"ip":"b1a41444e0edda0ab9de3e330d971e2c","port":80,"ipVer":"4","maskingType":"Hash","ori
rv

gLength":14}
pe

Tip
Im

In sensitive deployments, such as with financial institutions or governmental organizations,

extended testing and analysis may be necessary. Imperva Professional Services can help with
the masking and verification process to ensure sensitive information is not being sent to the
17

Intelligence (Community Defense) system.

20

8. If any sensitive values were incorrectly masked, modify the Masking Configuration rules to ensure proper
masking.
©

a. Under Masking Configuration, click the Edit button and the Intelligence (Community Defense) Masking
Configuration window will appear.

© 2017 Imperva, Inc. All rights reserved 6-17 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

9. The Intelligence (Community Defense) Masking Configuration controls the handling of data identified in the
violation.

.
ed
rv
se
re
s
ht
ig
lr
Al
10. Click the New button to add custom masking rules and configure as needed.
c.
In
a,
rv
pe
Im
17

Important
20

When masking web page parameters, create two rules. One rule should match the element
type Parameter, and the second rule should match the element type Header. This will ensure
©

matching for both GET and PUT HTTP methods.

11. Click save to save your changes.
12. Review new violations to ensure masking is operating correctly.
13. Continue to review and update until confident the sensitive information is properly masked.
14. In a lab environment, collected data should not be sent to Intelligence (Community Defense). If this were a
production environment, the next step would be enable sharing with the Send Collected Information option.

© 2017 Imperva, Inc. All rights reserved 6-18 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

Important
Please do not select the Send Collected Information option in the training environment. All
activity in the training lab are simulated and will not benefit the ThreatRadar Intelligence
(Community Defense) system.

ThreatRadar Anti Automation (Bot Protection)

.
ed
Starting in version 11.0 Imperva introduced ThreatRadar Bot Protection, a sophisticated tool to classify clients and
bots. Bot is short for robot and is an automated browsing program. Some bots are desirable, such as the indexing

rv
spiders used by search engines. Allowing search engines is crucial to ensure users can find the organization’s
website. Other bots may be malicious, such as those used in botnets discussed earlier. Classification good bots is

se
general not difficult but malicious bots may be very difficult to identify.

re
Attackers that manage botnets go to great lengths to disguise their bots. They continually adapting connection
information provided by the bots to appear as if the request came from a human using a normal browser. This

s
presents particular challenges for security systems because any standard set of identification tools, like matching

ht
the User-Agent header, quickly becomes outdated.

ig
SecureSphere addresses the challenge with specific ThreatRadar feeds for bot identification and the Bot Protection
lr
policy type. SecureSphere Bot Protection performs a two-stage analysis of clients to ensure accurate classification.
Al
First signature pattern matching is performed on the client request which rapidly identifies most trustworthy bots.
Clients that remain unidentified are then presented with a JavaScript challenge specifically designed to fail when
c.

performed by bots. The ThreatRadar Bot Protection feed regularly updates both the signatures and JavaScript
challenges, ensuring the attackers cannot adapt to the identification process used by SecureSphere and ensuring
In

accurate bad bot identification.

a,

ThreatRadar Bot Protection is an advanced analysis process and has the following requirements:
rv

• ThreatRadar must be properly licensed

pe

• The MX server must be able to reach the ThreatRadar update servers

• The Gateway is deployed in an Inline Bridge or Reverse Proxy deployment mode.
Im

• The Server Group must be in Active mode

• A ThreatRadar Bot Protection Policy has been created and assigned to Sites Tree Application objects
• Disable any Bot Mitigation policies for the Applications. ThreatRadar Bot Protection conflicts with the Bot
17

Mitigation policy.
20

With ThreatRadar Bot Protection configured and the Server Group active, SecureSphere will identify clients and
build statics on client connections.
©

ThreatRadar Bot Protection classifies clients into the following categories:

Classification Details
White Listed Bot A bot originating from an IP address/User Agent combination included in the ThreatRadar -
Trusted Bots Global Object
Crucial Bot A bot identified by SecureSphere as trusted, for example a known search engine.

© 2017 Imperva, Inc. All rights reserved 6-19 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

Bad Bot A bot identified by SecureSphere as malicious.

General Bot A bot identified by SecureSphere with no malicious reputation.
Human Not a Bot, but a browser.
Unknown A client that SecureSphere was not able to classify
Table 6-3 - Bot Classifications

Bots identified as Bad Bots are further classified by the following malicious activities:
Bad Bot Classification Details

.
ed
Click Bot A bot that visits (clicks on) on a site's ad links.
Comment Spammer Bot A malicious bot that posts comments that include text and graphics.

rv
Crawler A bot that visits sites for various purposes; most of these are not malicious.

se
Feed Fetcher A bot that retrieves a site's RSS feeds; usually not malicious.
Hacking Tool Software that can be used for hacking purposes

re
Masking Proxy A web proxy that masks a request's origin
Search Bot A bot that visits sites in order to index them

s
Spam Bot A bot that posts spam comments and sometimes extracts email addresses; always

ht
malicious.

ig
Vulnerability Scanner A bot that visits sites in order to detect their vulnerabilities
Worm A self-replicating program that injects malicious code into sites or scrapes them;
always malicious.
lr
Al
Site Helper Various management assistance tools
DDos Tool An automatic tool or a botnet that generates Distribute Denial of Service attacks.
c.

Typically malicious.
In

Table 6-4 - Bad Bot Classifications

Bot Protection CAPTCHA service

a,

SecureSphere version 11.5 introduces the ThreatRadar Bot Protection CAPTCHA service. CAPTCHA is a service that
rv

protects your website from spam and abuse. CAPTCHA uses an advanced risk analysis engine and adaptive
CAPTCHAs to keep automated software from engaging in abusive activities on your site. It does this while letting
pe

your valid users pass through with ease.

Im

The CAPTCHA service is based on Google reCAPTCHA and requires the Site and Secret keys from the Google admin
console for configuration.
17

SecureSphere provides the two following CAPTCHA security policies:

20

Policy Type Details

CAPTCHA Event Based This policy defines the events that trigger a CAPTCHA challenge that is then
presented to the end user. The policy also prevents access to the protected resources
©

until the challenge is passed. The challenge is presented only when the current page
is changed (via page reload or navigation action). When suspicious activity is
detected, the configured action and followed action is applied and an alert is issued.
CAPTCHA Activity Based This policy defines the actions (such as button clicks) and locations in the Web
application that trigger a CAPTCHA challenge that is then presented to the end user.

© 2017 Imperva, Inc. All rights reserved 6-20 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

An enforcement policy (usually a Web Custom policy) is also required to block

requests from sessions that did not pass the challenge to the protected resources.
Table 6-5 - CAPTCHA Security Policy Types

ThreatRadar Emergency Feed

Due to the increasing sophistication of attackers and criminal organizations, newly discovered vulnerabilities and
exploits can be acted on very rapidly. SecureSphere provides protections against these threats through the ADC

.
ed
Updates which provide Signatures to identify and block the exploit behavior. However, ADC Updates are released
once every two weeks. While this time is necessary for testing to ensure the signature updates do not create false

rv
positive or performance issues, the delay is problematic with rapidly emerging threats.

se
The Threat Radar Emergency Feed balances the need to rapidly respond to emerging threats with the need to
ensure new signature updates are sufficiently tested and refined before general distribution. The feeds allow an

re
organization vulnerable to a zero-day or rapidly emerging exploit to immediately apply protective signatures which
are provided through ThreatRadar updates. Importantly, the organization can also disable the feed or associated

s
security policy if performance or accuracy issues are suspected. This allows Imperva to make defensive signatures

ht
rapidly available during an emergency without excessive risk for established deployments.

ig
By default, the Emergency Feeds are disabled.
lr
Al
c.
In
a,

Figure 12 - ThreatRadar Emergency Feed Initially Disabled

rv

Enabling ThreatRadar Emergency Feeds

pe

Enabling the ThreatRadar Emergency Feeds is a twostep process. First the feed itself is enabled, so the Lookup Data
Im

Sets will be populated with the latest signatures. Second, the corresponding security policy is applied to the relevant
Sites Tree Objects to protect the web application under consideration.
17

1. Select and Right-Click the relevant Emergency Feed.

20
©

2. The ThreatRadar Emergency Feed will begin getting updates.

3. Next locate the corresponding Security Policy to assign it to the relevant Sites Tree Object:
a. Select Main > Policies > Security.

© 2017 Imperva, Inc. All rights reserved 6-21 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

b. Use the basic filter to filter by Type – Web – Service Level – HTTP Protocol Signatures.

.
ed
rv
se
re
c. Locate and select the policy corresponding to the feed previously enabled, in this case it is the
ThreatRadar – Emergency – Authenticated Sessions Signatures policy.

s
ht
ig
lr
Al
c.
In
a,

d. From the Apply To tab, assign the policy to the relevant sites tree object and save changes.
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 6-22 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

4. The security policy is now active, but non-blocking. Allow the security policy to run for a short period of
time to ensure the signatures do not have any performance or accuracy issues. The time will vary based
on the volume of web traffic and the organization’s requirements.
5. Finally, after a sufficient test period has elapsed, the policy action can be set to block.

.
ed
rv
se
re
6. Save changes.

s
7. Periodically review the Alerts and Violations while the Emergency Feed Policy is in place.

ht
ig
ThreatRadar Fraud Prevention Services lr
Al
ThreatRadar provides two forms of Fraud Prevention services that may be appropriate for highly sensitive web
applications. First, SecureSphere Fraud Prevention provides connectors to best-in-class fraud prevention services
c.

allowing seamless integration of fraud prevention without modification of the underlying applications. Second,
SecureSphere version 11.5 introduces ThreatRadar Account Takeover Protection which detects and mitigates
In

unauthorized site access in real time by leveraging credential/device threat intelligence. Additional licensing
required.
a,
rv

ThreatRadar Fraud Prevention Service integration requires site specific information beyond the scope of this course.
Organizations interested in utilizing Fraud Prevention Services are advised to work with Imperva Sales and
pe

Professional Services for these configurations.

Im

Review Questions
17

1. Which ThreatRadar feed requires configuration in order for the lookup data set to be populated? Why?
2. Which predefined ThreatRadar security policies could be safely set to block for most deployments?
20

3. Which predefined ThreatRadar Security Policies may be better left in the default, non-blocking, configuration
for some web applications?
©

4. What recommendation would you give to if an organization wanted to be certain that business partners do not
get blocked by any of the ThreatRadar Security Policies?

© 2017 Imperva, Inc. All rights reserved 6-23 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

Exercises
Prerequisite:

Important
Before beginning the exercises, refer to the steps detailed in the following class interactive sections.
1. ThreatRadar Lookup Data Sets.
2. Configuring ThreatRadar Phishing URLs.

.
ed
Exercise 1

rv
Configure the ThreatRadar Phishing URLs feed with the hostname admin.superveda.local and www.superveda.local

se
(if this was not done during lecture). First identify the relevant hostnames by checking the Learned Hosts in the
Profile.

re
s
ht
ig
(Screenshot on next page) lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 6-24 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

How to identify hostnames from the Profile Learned Hosts:

• Select Main > Profile > Application View

.
ed
• Expand the Sites Tree and select SuperVeda - Web Application.

rv
se
re
s
ht
ig
lr
Al
c.
In

• Select thhe Learned Hosts view.

• Use any hostnames listed (ignore any IP addresses if present).
a,

• Repeat the above for the Vedaadmin – Web Application.

rv
pe

Exercise 2
Configure the ThreatRadar Malicious IPs Security Policy to block and SYSLOG the violation to Veda DB.
Im

Note: Use the SV – Violation – Send to VedaDB Syslog followed action.

17

Exercise 3
20

Create a custom blocking policy that correlates a client from an Anonymous Proxy IP address with 5 or more
significant security violations in under a minute.
©

Answers to Review Questions

1. Which ThreatRadar feed requires configuration in order for the lookup data set to be populated? Why?
a. Phishing URLs. The Phishing URLs feed is based on the URLs of the protected web applications and requires
the Hostname of the protected servers to retrieve the relevant URLs.

© 2017 Imperva, Inc. All rights reserved 6-25 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

2. Which predefined ThreatRadar security policies could be safely set to block for most deployments?
a. For most deployments setting the following policies to block is usually safe: Malicous IPs, Phishing URls,
Comment Spam IPs, Remote File Inclusion, SQL Injection IPs and Scanner IPs.
3. Which predefined ThreatRadar Security Policies may be better left in the default, non-blocking, configuration
for some web applications?
a. Blocking with the ThreatRadar Anonymous Proxies and TOR IPs security policies may be overly aggressive for
web applications that allow anonymous clients, such as news sites.
4. What recommendation would you give to if an organization wanted to be certain that business partners do not

.
ed
get blocked by any of the ThreatRadar Security Policies?
a. Create a list of the Partner IP addresses and add the IP addresses to the relevant ThreatRadar Whitelist

rv
Lookup Data Sets. Listing the IP addresses in a text file (one IP per line) and using the CSV upload option can
simplify the data input.

se
Answers to Exercises

re
Exercise 1

s
From the SuperVeda - Web Application profile, and the Vedaadmin – Web Application profile, you should find the

ht
two following hostnames:

ig
• www.superveda.local
• admin.superveda.local lr
Configuring the Phishing URLs ThreatRadar Feed:
Al
1. Select Main > ThreatRadar > Dashboard.
c.

2. Close the ThreatRadar Welcome message. If you want, you may select “Don’t Show this again” to prevent the
welcome from displaying again.
In
a,
rv
pe
Im
17
20
©

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 6-26 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

3. From the Service table, select the Phishing URLs ThreatRadar Reputation Services feed.

.
ed
rv
se
re
s
4. In the Phishing URLs window, select the Manage Tab and the configuration pencil for the ThreatRadar –

ht
Phishing URLs Lookup Data Set.

ig
lr
Al
c.

The Lookup Data Set: ThreatRadar – Phishing URLs window will appear.
In

5. Select the Configuration tab and Configure button.

a,
rv
pe
Im
17

The ThreatRadar Lookup Data Set Configuration window will appear.

20

Note
©

A GUI bug prevents the configure button from working with some versions of the Firefox
Browser. If so, use the Chrome or Internet Explorer browsers for this lab exercise.

© 2017 Imperva, Inc. All rights reserved 6-27 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

6. Click the plus two times to add two rows to the table. Add one hostname in each row and click Update to save
your changes.

.
ed
rv
se
re
s
ht
ig
lr
Al
7. Close the Lookup Data Set: ThreatRadar – Phishing URLs window.
c.

8. By default ThreatRadar Intelligence Phishing URLs feed is updated once every hour. This can be verified by
selecting the scheduling tab:
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 6-28 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

9. You can wait for the Phishing URLs feed to update automatically or manually run the update from Admin > Job
Status.

.
ed
rv
se
10. Later in the day you should see the Phishing URLs warning change to the green check.

re
Warning:

s
ht
OK:

ig
lr
Exercise 2
Al
Configure the ThreatRadar Malicious IPs Security Policy to block and email the security administrator.
c.

Select Main > Policies > Security.

In

Find and select the ThreatRadar - Malicious IPs policy.

a,

Hint: This policy is grouped under Web Service Custom policies. Filter for policies applied to the SuperVeda Http
rv

Service object.
pe

Configure as follows:
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 6-29 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

Save changes.

Exercise 3
Create a custom blocking policy that correlates a client from an Anonymous Proxy IP address with 5 or more
significant security violations in under a minute.

.
ed
New Policy: Web Service
SV - TR Anonymous Proxies Correlated Blocking
From Scratch

rv
Type: Web Service Custom

se
Select the following Match Criteria:

re
• Lookup Data Set Search (2x)
• Number of Occurrences

s
• Violations

ht
ig
lr
Al
c.
In
a,
rv
pe

(Continued on next page)

Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 6-30 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

Configure as Follows:

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

Your selected violations may differ.

© 2017 Imperva, Inc. All rights reserved 6-31 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

Quick-View Tables
Table 6-1 - ThreatRadar Reputation and Intelligence (Community Defense) data feeds ................................................ 4
Table 6-2 - ThreatRadar Policy Recommendations ......................................................................................................... 10
Table 6-3 - Bot Classifications.......................................................................................................................................... 20
Table 6-4 - Bad Bot Classifications .................................................................................................................................. 20
Table 6-5 - CAPTCHA Security Policy Types ..................................................................................................................... 21

.
ed
Table of Figures

rv
Figure 6-1 - ThreatRadar Dashboard Location .................................................................................................................. 4

se
Figure 6-2 - ThreatRadar Emergency Activation ............................................................................................................... 4
Figure 6-3 - ThreatRadar Data Feeds Status ..................................................................................................................... 5

re
Figure 6-4 - ThreatRadar Feed showing update issue ......................................................... Error! Bookmark not defined.
Figure 6-5 - ThreatRadar Anonymous Proxies Summary tab ............................................................................................ 5

s
Figure 6-6 - Anonymous Proxy Manage Tab ..................................................................................................................... 6

ht
Figure 6-7 - Locating Threat Radar Data Feed Configuration Details From Threat Radar Dashboard ............................. 6
Figure 6-8 - Locating Threat Radar Data Feed Configuration Details From Global Objects ............................................. 7

ig
Figure 6-9 - ThreatRadar Anonymous Proxies Security Policy ........................................................................................ 11
lr
Figure 6-10 - Predefined ThreatRadar Security Policy Match Criteria Logic .................................................................. 12
Figure 6-11 - Custom Policy for Anonymous Proxies and TOR IPs Data Feeds............................................................... 13
Al
Figure 6-12 - Security Policy using Source GeoLocation Match Criteria......................................................................... 14
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 6-32 Lesson 6: ThreatRadar

SecureSphere 12.0 Web Application Security Course Manual

Alerts, Violations and Monitoring

Chapter Overview
Alerts, Violations and Monitoring are a central part to Web Application Security deployments. Collectively they
provide visibility into the concerning traffic identified by SecureSphere during traffic inspection. In this chapter, we
will discuss monitoring of all SecureSphere activity with the Dashboard, Understanding Alerts and Violations,

.
Analyzing details of client activity with Alerts and Violations, and discuss strategies for differentiating attack activities

ed
versus potential false positive matches.

rv
Chapter Objectives

se
• Use Violations and Alerts to identify false positives, attacks, and tuning opportunities.
•

re
Use the “Add as Exception” and “add to profile” buttons to tune policies and profiles.
• Use SecureSphere’s alert flags (Acknowledged, Dismissed, Important, Unread) to manage alerts.
• Configure appropriate reports to help administrators analyze alerts and violations.

s
• Configure appropriate reports to find opportunities to tune SecureSphere’s configuration and security.

ht
(frequency of high severity violations, “top 10” reports)

ig
SuperVeda Lab Preparation lr
In preparation to work with Alerts and Violations additional simulated web traffic is required.
Al
1. From Client PC, start the Putty SSH tool and connect to the SecureSphere Gateway.
c.

Field Value
In

IP Address 192.168.51.201
Username imperva_user
a,

Password Impuser123
rv

Note
pe

Be certain to connect to the SecureSphere Gateway. The script used is not present on the Management Server.
Im

2. At the command prompt enter the command admin and re-enter the password.
17

login as: imperva_user

[email protected]'s password: <- Impuser123
20

Welcome to SecureSphere Shell

Type “help” for a list of commands
©

SecureSphere> admin
[root@veda-gw ~]#

3. From the CLI, run the following command.

honeypot_attack.sh; replay_pcap.sh

© 2017 Imperva, Inc. All rights reserved 7-1 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

This will take several minutes to complete and you will see new alerts added to the logs while the scripts are
running.

Alerts, Violations and Monitoring – Overview

Alerts and Violations are the security event logs that record concerning activity identified during traffic inspection

.
and are located under Main > Monitor > Alerts and Main > Monitor > Violations. Each log provides a slightly different

ed
view into the logged security events and together provide insight into attacks against the protected web
applications. These logs particularly useful when analyzing concerning events, but they are less useful when trying to

rv
gain a top-level overview of the health and operation of the SecureSphere deployment. Fortunately, SecureSphere

se
provides a Dashboard view to give visibility into the overall health and performance of SecureSphere.

re
Dashboard
The Dashboard is the central monitor for the SecureSphere deployment and is located on Main > Monitor >

s
Dashboard and provides visibility into the major components and activities in the SecureSphere deployment.

ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17

Figure 7-1 - Main > Monitor > Dashboard - Sections Identified

20

Important:
User idle-time logout is suspended on the Dashboard page. This allows the page to be used in operations centers.
©

SecureSphere users should be aware their sessions will not be automatically ended by SecureSphere when on this
page.

Each section of the dashboard provides visibility into system health, performance or recent activity.

Dashboard Section Information Provided

ThreatRadar ThreatRadar licensing details and feed update status

© 2017 Imperva, Inc. All rights reserved 7-2 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

Gateways List of gateways and CPU utilization for each gateway

Server Groups (Tab) List of all Server Groups including status warnings, connections, and SQL /
HTTP Hits
Selected Gateway Info (Tab) List of Server Groups assigned to a particular gateway. Status, Connections
and Hits information provided for each Server Group. This requires selecting a
Gateway from the Gateways section.
Graph - CPU Load & Hits/sec Graph display load or hits per second
Graph – Connections/sec & Graph displays Connections per second or throughput

.
ed
Throughput
Alerts per Severity (Filtered) Pie chart graph of alerts by severity

rv
Latest Alerts Listing recent security alerts/violations, filtering available.
Latest System Events Listing of recent System Events.

se
Table 7-1 - Dashboard Sections Explained

re
The Dashboard is particularly useful for daily usage and will be discussed again during the Tuning lesson.

s
Alerts

ht
ig
Alerts are notifications consisting of one or more security policy violations grouped by the type of attack. Attacks can
rapidly generate tens, hundreds, or even thousands of violations over a short period of time and the sheer volume
lr
create significant challenges for analysis and investigation. Viewing events in a sequential order almost guarantees
Al
that critical but infrequent events will be lost in the sea of low-importance ‘noise.’
c.

SecureSphere Alerts address this challenge by grouping multiple violations into a single Alert based on the
underlying attack type. By grouping the Violations by their attack type, Alerts present a broader view of the attack
In

patterns directed at the protected web applications. Alerts allow easy access to the underlying violations, giving
investigators access to full attack details whenever the analysis requires it.
a,
rv

The Alerts also provide visibility into the grouping process, providing details on the underlying attack.
Alerts identify traffic details common to all of the underlying violations as well as the details that have some
pe

variability within the grouped violations.

Im

Viewing Alerts
To view Alerts, select Main > Monitor > Alerts. The Alerts window shows the Filter Pane, Alerts Table, Details Pane
17

and the Geographic Alerts Map.

20
©

(Screenshot on next page)

© 2017 Imperva, Inc. All rights reserved 7-3 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

.
ed
Figure 7-2 - Main > Monitor > Alerts - Sections Identified

Selecting the Geographic Alerts Map button displays the Geographic Alerts Map window with the top ten countries

rv
by number of alerts heat map.

se
re
s
ht
ig
lr
Al
c.
In
a,

Figure 7-3 - Geographic Alerts Map Example

rv

The Filters Pane provides a Quick, Basic and Advanced Filter.

pe
Im
17
20
©

Figure 7-4 - Filter Panel Sections Identified

Note

© 2017 Imperva, Inc. All rights reserved 7-4 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

The Basic and Advanced Filters are overlapping. An applied Basic or Advanced filter will be visible in both. The
Quick Filter, however is independent. The active filter is the most recently applied but if you are unsure, consider
clearing both the Quick Filter and the Basic / Advanced filter and then defining the desired filter.

Alert Table
The Alerts Table provides a filtered list of recent alerts for analysis.

.
ed
rv
se
re
s
ht
Figure 7-5 - Alerts Table Example

ig
Note
lr
The visible alerts in your lab environment are likely to differ from the screenshots.
Al
The Alerts Table columns are selectable and by default the table does not show every column. Adding or removing
c.

columns from the display is managed with Action > Select Columns.
In
a,
rv
pe
Im
17

Figure 7-6 - Selecting Alerts Table Columns from Action Menu

20

The Select Columns window will appear. The columns showing on the right side will show in the Alerts Table.
©

© 2017 Imperva, Inc. All rights reserved 7-5 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
Figure 7-7 - Alert Table Select Columns Window.

re
The Alerts Table provides the following information:
Column Description

s
No. Alert Number: Alerts are numbered sequentially. This number increments to the next

ht
thousands value on Management server restart.

ig
Blocking Violation. The security policy rule is set to Block.
Severity. This column shows the violation severity for the alert.
lr
Type Icon indicates the type of attack. The possible attack types include:
Al
- Anti Automation - Profile
- Correlation - Protocol
c.

- Custom Correlation - Signature

In

- Firewall - Worm
a,

Updated Time and Date of the most recent violating event in the alert.
# Number of violations aggregated into the alert.
rv

Alert Description A short description of the alert. It may contain the name of the policy, rule or
pe

signature that triggered the violation. Additionally, information regarding aggregation

may also be included
Im

Server Group The server group to which the alert relates.

Service The service to which the alert relates.
Source IP The IP which caused the alert to be generated. Displays Multiple when violations from
17

more than one Source IP address have been aggregated into the alert.
Source Geo Location Geo Location of Source IP by country when possible. If violations from multiple
20

countries have been aggregated, it displays Multiple. IPv4 private addresses are
identified by Internal network.
©

Source of Activity N/A. This column is for SecureSphere Database deployments and does not apply to
Web Application Security.
Table 7-2 - Alert Table Columns

© 2017 Imperva, Inc. All rights reserved 7-6 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

Changing the Default Time Frame for Event Filtering

By default, the last 3 days of alerts are displayed. This can be changed in the SecureSphere user preferences.

1. Select Preferences > Preferences.

.
ed
rv
Update the Default Time Frame for Event Filtering (days): with the desired number of days.

se
re
s
ht
ig
lr
Al
c.
In
a,

2. Save the changes.

rv
pe

Alert Details
Im

An Alert may contain one or more underlying violations. Alerts with only one violation are called Individual Alerts,
while Alerts containing more than one violation are called Aggregated Alerts. We will look at Aggregated Alerts first.
17

Aggregated Alerts
Selecting an Aggregated Alert from the Alerts Table displays information on the Alert in the Details Pane.
20
©

(Screenshot on next page)

© 2017 Imperva, Inc. All rights reserved 7-7 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

.
ed
Figure 7-8 - Selecting an Alert for Display in the Details Pane

The Alert Details Pane provides extensive details on the Alert and underlying violations. The following figure shows

rv
an Alert consisting of multiple violations occurring over the few hours. Each part of the alert will be explained below.

se
Viewing Aggregated Alert Details

re
Select Main > Monitor > Alerts and choose an alert from the Alerts Table.

s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20

1. Alert Number and Short Description.

©

2. Actions: This section displays the Action and Followed Actions. If the action is Immediate Block but the Server
Group mode is set to Simulation the block action did not occur and this is indicated with (Simulation Mode).

In this example the Action is Immediate Block and the Followed Action is SV – Security Event – Email Admin

© 2017 Imperva, Inc. All rights reserved 7-8 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

3. Policy: Indicates the Security Policy that triggered on the concerning event.

The link opens the policy in a new window.

4. Alerts Distribution Graph: This graph represents the aggregated violations for this alert distribution over time.
Each bar represents 30 Minutes, starting from the hour or half hour.

.
ed
rv
The graph title indicates the first and last events that have been aggregated into the alert. Clicking the
magnifying glass icon provides information on the conditions applied for aggregation.

se
re
s
ht
ig
5. Alert Aggregated By: This section displays the details common to the underlying violations that have been
lr
aggregated into this alert
Al
c.
In

6. Statistical Information: This section lists the details that have some variability between the underlying
a,

violations aggregated into this Alert.

rv
pe
Im
17

Clicking on the magnifying glass present a chart of the differences in a new window.
20
©

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 7-9 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

In this example, the Sessions graph appears as follows.

.
ed
rv
se
7. Violations: The violations section provides examples of violating events that have been aggregated into this

re
alert. Each listed violation can be expanded for further analysis.

s
ht
ig
The details provided for violations is not affected by aggregation and will be shown in the context of Individual Alerts
discussed shortly. lr
Al
Alert Aggregation Process
c.

Alert aggregation is performed on the MX. The following diagram shows the steps of the aggregation process. For a
In

given Alert, aggregation continues for up to 12 hours as long as new events occur at least once per hour.
a,
rv
pe
Im
17
20
©

Figure 7-9 - Alert Aggregation Flow Chart

© 2017 Imperva, Inc. All rights reserved 7-10 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

Individual Alerts
When an alert consists of just one violation, no aggregation information is available and the Alert Details only show
the Actions, Policy and violation detail. The following figure shows an example of an Individual Alert:

.
ed
rv
se
re
s
ht
ig
lr
Al
c.

Figure 7-10 - Individual Alert Example

In
a,

Analyzing Violation Events within Alerts

rv

1. Select Main > Monitor > Alerts.

pe

2. Event ID, Name, Quick-Actions and Event Key: The event ID, Name and Quick-Actions are on a single line at the
top. Each event, or violation, is given an unique ID at the time of inspection.
Im
17

a. Event ID
b. Event Name
c. Quick-Actions: The following Quick-Actions are possible
20

Icon Name Description

Knowledge Base Clicking this opens a knowledge base article on the current violation.
©

Clicking this adds an exception for the current action to the Advanced tab of
Add Exception the Security Policy. Exceptions are added with as much detail as possible and
should be reviewed after adding.
Open the Web Profile for the current URL in a new window. This icon only
Show Profile
appears with profile policy violations.

© 2017 Imperva, Inc. All rights reserved 7-11 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

Add the character(s) identified in this violation to the Web Profile so they
Add to Profile will be treated as acceptable characters in the relevant parameter and URL.
This icon only appears with profile policy violations.
d. Event Key:

.
ed
The Event Key displays standardized information about the violation.
3. Event Details

rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe

a. Event Details – SecureSphere Information: Time of Event, Gateway & Sites Tree information. The Icon
Im

identifies fields that can be used in the filter.

b. Event Details - Client Connection: Clicking the IP Address opens the Geo Location map for the address.
c. Event Details – Server Response: Details on the server response are displayed.
17

d. Event Details – HTTP Request Headers: The full HTTP Request Headers are displayed, providing visibility into
the client request.
20

4. Parameters: The webpage parameters submitted in the client request are identified here.
©

Note the yellow highlighting. When possible, SecureSphere identifies the characters or strings that matched
the signature or policy rule. In the above example the double-encoded value in the parameter is highlighted.

© 2017 Imperva, Inc. All rights reserved 7-12 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

5. Cookies: Displays cookies submitted by the client.

6. Enrichment Data: If enrichment is in use, enrichment data is identified here.

.
ed
7. Additional Violations: If additional violations are associated with the current request, they are listed in the

rv
additional violations table.

se
re
s
ht
Alert Table Actions

ig
lr
SecureSphere supports the management of Alerts with Alert Flags. Alert Flags are manually assigned status
indicators that are assigned from the Alerts Table. Assign an Alerts Flag by Right-Clicking on the alert in the Alerts
Al
Table.
c.
In
a,
rv
pe
Im
17

Figure 7-11 - Assigning Alerts Flag in the Alerts Table

20

The available flags are described in the following table:

Icon Name Purpose
©

Important Identifies the Alert has been viewed and deemed important by the reviewer.
Acknowledged Identifies the Alert has been viewed, but the importance is not yet established.
Dismissed Identifies the Alert has been viewed and is not important, or the underlying issue is
resolved.
N/A Clear Flag Menu option to clear a flag previously set
Table 7-3 - Alert Flags Explained

© 2017 Imperva, Inc. All rights reserved 7-13 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

When set, the flags appear next to the Alert Number in the No. column.

.
ed
Figure 7-12 - Example Alert Flags in No. Column

Alert Management Workflow

rv
se
The Alerts Flags support event review workflows like the following example:

1. The security admin filters for High Severity Alerts.

re
2. All new high severity alerts are analyzed and flagged as follows:
a. Important – The Alert identified an attack and additional study or mitigation is required.
b. Acknowledged - The security admin has seen this alert and is determined it requires further analysis.

s
c. Dismissed – The Alert has been determined to be acceptable. This could be because SecureSphere blocked

ht
the request and no further actions are required, or because the Alert was important initially but has been

ig
mitigated.
3. Review of flagged alerts is aided by the following saved Basic Filters:
a. High Severity Alerts that are not flagged.
lr
Al
c.
In
a,
rv
pe
Im
17

b. High Severity Alerts marked Important.

20

c. High Severity Alerts marked Acknowledged

d. High Severity Alerts marked Dismissed.
4. (Optional) Delete older Alerts, Marked Dismissed.
©

a. Apply the High Severity Alerts marked Dismissed Filter.

b. From the Action Menu, Select Deleted Filtered Alerts. Note, this only deletes the alert, not the underlying
violations. The actual violation events cannot be manually deleted.
Note
Both Alerts and Violations logs are rotated for space and performance requirements. Depending on the level of
traffic and number of violations, this typically takes between two and four years.

© 2017 Imperva, Inc. All rights reserved 7-14 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

Violations
Violations in a sequential list, allowing investigations into the order specific Violations occurred in. The Violations
display is particularly helpful when tracking down the activity of a particular user, or for identifying what other users
were doing at the time of a particular violation.

To view Violations, select Main > Monitor > Violations. The Violations window display is very similar to the Alerts
window. The Violations window is composed of a Filter Pane, Violations Table, and Details Pane.

.
ed
rv
se
re
s
ht
ig
Figure 7-13 - Main > Monitor > Violations - Sections Identified

The Violations Table provides the following information:

lr
Al
Column Description
Time Timestamp for the Violation.
c.

ID Unique ID for the Violation.

In

Severity. This column shows the violation severity.

Type Icon indicates the type of attack. See - Alert Table Columns above.
a,

Source Geo Location Geo Location of Source IP by country, when possible.

Source IP The IP which caused the Violation to be generated.
rv

Source of Activity N/A. This column is for SecureSphere Database deployments.

pe

Username Name of the Application User, when identified though the profile Web Application
User Tracking.
Im

Dest. IP Destination IP Address of the client request.

Violation Description A short description of the Violation. It may contain the name of the policy, rule or
signature that triggered the violation.
17

Server Group The server group to which the Violation relates.

Service The service to which the Violation relates.
20

Violated Item Identifies Parameter, URL or other detail where the Violation occurred when
applicable.
©

Table 7-4 - Violations Table Columns

Violation Details Pane

The Violation Details Pane provides further information for each Violation. Depending on the type of violation, the
Details Pane will show one to three tabs.

© 2017 Imperva, Inc. All rights reserved 7-15 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

Figure 7-14 - Violation Details Pane - Tabs Highlighted

.
ed
1. Details: Details on the Violation itself. This is the same information provided in the Alerts and discussed earlier
with one exception. In Alerts, Additional Violations are listed in the event details while in Violations, Additional
Violations are a separate tab. For further information on the data presented in the Details tab, see the

rv
Individual Alerts topic discussed previously.

se
2. Additional Violations: Additional Violations are displayed on this tab. The Additional Violations tab provides
some additional detail compared to Alerts.

re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20

3. Response: Some security policies monitor the server response and can be configured to capture the response
page returned to the client. If the policy action is set to block, the response is not delivered to the client. When
©

enabled, the response page is displayed in the Response tab.

The following shows the results when a Policy is not configured to retain response data:

© 2017 Imperva, Inc. All rights reserved 7-16 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

The following shows a Policy that captures response data:

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

Note
As a precaution, SecureSphere displays the captured response in plain-text. This is a protection against the
unlikely scenario that an attacker injects malicious code in a way that is then included in the server response. If
this were to happen and SecureSphere displayed the Response HTML format, the administrator’s browser could
inadvertently run the malicious code. By display the response in plaintext, this unlikely but theoretically possible
attack vector is eliminated.

© 2017 Imperva, Inc. All rights reserved 7-17 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

Event Analysis Tips

Analyzing concerning events with the Alerts and Violations logs can be complex work. The Alerts and Violations are
entirely dependent on the protected applications, applied security policies and inspected traffic. Analysis of events is
not a formalized, step-by-step, process. Instead it is more like an investigation that assembles small details into a
picture of the event.

The following scenarios cover some common Alerts and provide visibility into the details used to understand the

.
ed
underlying client activity.

rv
Alert Analysis Scenarios:
Analysis - Alert has a very high number of aggregated events Implies - False Positive

se
Strength of evidence Low. However, it increases with increased event count. Very strong if event
count is notable percentage of total web traffic. (See Exceptions)

re
Reasons Attack activity is usually a very small percentage of total web activity. Alerts
with high event counts are more easily be generated by a false positive match

s
affecting many users, in comparison to all of the activities of an attacker.

ht
Exceptions High volume attacks like Denial of Service (DoS), web site scanning, password

ig
brute-force, etc.

Analysis - Alert identified as Distributed

lr Implies - False Positive
Al
Strength of evidence Very Low, but increases with high number of aggregated events.
Reasons Attacks from multiple IP addresses tends to be hard to pull off so they are less
c.

common.
Exceptions All distributed attacks like Distributed Denial of Service (DDoS), distributed
In

brute-force, distributed scanning, etc.

a,

Analysis – Aggregation Graph - Events occur steadily over time Implies - False Positive
rv

Strength of evidence Medium to Strong

Reasons Usually attackers vary the attack over time and generate many alerts with
pe

some activity instead of one alert with much activity.

Exceptions All ThreatRadar Alerts and any attacks on critical URLs like login, purchase,
Im

registration, etc. Some web site scanning or web site fuzzing attacks may also
have steady activity over time.
17
20

Analysis – Numerous Web Profile Violations Implies – False Positive

Strength of evidence Varies.
©

New Deployment: Strong

Un-tuned Profile: Very Strong
During web application updates: Very Strong
Established and tuned Profile: Low to very low

© 2017 Imperva, Inc. All rights reserved 7-18 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

Reasons Initially during learning no alerts are generated. After sufficient learning takes
place, all URLs are switched to protect and traffic can generate alerts and
violations. If the deployment is new, un-tuned, or the web application is
updated, the alerts are very likely false-positives.

If the profile is established and well-tuned and the web application is not
undergoing changes, the likelihood of a false positive is low.
Exceptions The increase in Profile Alerts matches increases in other attack indicators like

.
ed
ThreatRadar violations, Invalid characters in URL/Parameters/Headers, web
site scanning, etc.

rv
Analysis – Aggregation Graph – Many events initially, but quickly diminish to zero Implies – Attack

se
Strength of evidence Low to Medium
Reasons Most attackers vary the attack as they search for vulnerabilities. Due to Alert

re
Aggregation, the attacker’s activity is grouped by attack types resulting in
many alerts with small numbers of events as the attacker tries different

s
strategies. Alerts with activity concentrated at the start are a common result.

ht
Exceptions DoS and DDoS attacks may simply flood the server with the same attack type

ig
over and over again. Also, some vulnerability scanning attempts may fuzz the
web application. Fuzzing is the process of sending random data into all input
lr
fields in the attempt to find an unknown defect in the target application.
Al
c.

Analysis – Alert identified as Multiple Implies – Attack

Strength of evidence Low to Medium
In

Reasons Most attackers vary the attack as they search for vulnerabilities. Due to Alert
Aggregation, the attacker’s activity is grouped by attack types resulting in
a,

many alerts with small numbers of events as the attacker tries different
rv

strategies. Alerts with activity concentrated at the start are a common result.
Exceptions DoS and DDoS attacks may simply flood the server with the same attack type
pe

over and over again. Also, some vulnerability scanning attempts may fuzz the
web application. Fuzzing is the process of sending random data into all input
Im

fields in the attempt to find an unknown defect in the target application.

17
20
©

(Continued on next page)

Alerts Reports

© 2017 Imperva, Inc. All rights reserved 7-19 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

Follow the steps below to create a custom Top 10 WAF Violations report.

1. Select Main > Reports > Manage Reports

2. Click create and select Alerts
3. Configure Create Alerts Report window as follows:
a. Name: SV – Top 10 WAF Violations
b. Select: Use Existing – Daily Top 10 WAF Violations

.
c. Click

ed
4. The Report Window will show the settings for the new report
5. Select the General Details tab

rv
6. Select Format: PDF and Page Orientation: Landscape

se
re
s
ht
ig
7. In the Keywords section, select the SuperVedaWeb keyword and move it to the Report Keywords column with
the arrow lr
Al
8. Select the Data Scope tab and use the arrow to move Applications report field into the Enabled Fields
section.
9. Expand the Applications Field and select both the SuperVeda and Vedaadmin web applications.
c.

10. Select the Scheduling tab.

In

11. Schedule the report to run monthly, select:

a. Occurs: Recurring, Daily
a,

b. Starting from: Today

c. At Time: 2 AM
rv

12. Save the changes.

pe

13. Select General Details and click .

Im

Download and review report.

17
20
©

© 2017 Imperva, Inc. All rights reserved 7-20 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

Review Questions
Given the following alert scenarios, do you think the underlying events are valid traffic, False Positive, or the events
are attack traffic, meaning the alert correctly identified an attack:

1. An alert with a very high number of aggregated events, reaching approximately 10% of all web activity. The
events arrive consistently throughout the day.
a. Given just this information, how would you classify the alert:
1. False Positive – Likely

.
ed
2. False positive – Possible
3. Cannot say
4. Attack – Possible

rv
5. Attack – Likely

se
b. What reasoning backs up this classification?
2. An HTTP protocol violation alert is generated every four hours. The client is coming from an internal IP address
that is located the server network. Between 100 and 300 events are aggregated within the first 30 minutes and

re
then there is no activity until a new alert is generated 4 hours later.
a. Given just this information, how would you classify the alert:

s
1. False Positive – Likely

ht
2. False positive – Possible
3. Cannot say

ig
4. Attack – Possible
5. Attack – Likely lr
b. What reasoning backs up this classification?
Al
c. What additional information would help make a determination?
3. Many alerts are occurring with Web Profile violations, mostly regarding Parameters like Unknown Parameter,
Parameter Type Violation, and Parameter Size Violation. All of the Alerts are being identified as Distributed in
c.

the Alert Description.

a. Given just this information, how would you classify the alert:
In

1. False Positive – Likely

2. False positive – Possible
a,

3. Cannot say
4. Attack – Possible
rv

5. Attack – Likely
pe

4. Same as Question 3 but…

a. You also noticed the number of Alerts for ThreatRadar Malicious IP increased during the same time, how
would you classify the alert:
Im

1. False Positive – Likely

2. False positive – Possible
3. Cannot say
17

4. Attack – Possible
5. Attack – Likely
20

6. What reasoning backs up this classification?

5. Same as Question 3 but…
a. The web developers announced updates to the web application over the next several weeks, what
©

conclusion would you draw?

1. False Positive – Likely
2. False positive – Possible
3. Cannot say
4. Attack – Possible
5. Attack – Likely
6. What reasoning backs up this classification?

© 2017 Imperva, Inc. All rights reserved 7-21 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

Exercises
Prerequisite:

Important
Before beginning the exercises, you must complete the steps detailed in the following class interactive sections.
1. SuperVeda Lab Preparation.
2. Dashboard.

.
3. Viewing Alerts.

ed
4. Alert Table.
5. Viewing Aggregated Alert Details.

rv
6. Analyzing Violation Events within Alerts.

se
7. Alert Table Actions.
8. Violations.

re
Exercise 1:

s
ht
Find a Suspicious Response Code Alert. Review the originating policy, the policy description, and details from the
Violations to better understand this alert.

ig
Which direction is the web traffic going in these alerts? lr
Al
Exercise 2:
c.

Review several of the violations in the Suspicious Response Code violation. Are all of the violations clearly attacks,
In

false positives, or a mixture?

a,

What details helped with this determination?

rv

Exercise 3:
pe

From one of the violations in the Suspicious Response Code Alert, Select the Filter icon to filter the alerts by the IP
address 192.168.55.200.
Im

Can you find clear indications of malicious or attack activity from this IP address in the Alerts or Violations logs?
17

Provide the Alert, or Violation Names used to justify your answer.

20
©

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 7-22 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

Answers to Review Questions

1. An alert with a very high number of aggregated events, reaching aprroximately 10% of all web activity. The
events arrive consistently throughout the day.
a. Given just this information, how would you classify the alert:
1. False Positive – Likely
b. What reasoning backs up this classification?
Alerts with high event counts are more commonly false positives, and as the number of events increase, the
likelihood increases. 10% of total traffic is a very large percentage so a cause of False Positive is likely,

.
ed
(Excluding possible DoS, DDoS, and scanning attacks is still required).
2. An HTTP protocol violation alert is generated every four hours. The client is coming from an internal IP address

rv
that is located the server network. Between 100 and 300 events are aggregated within the first 30 minutes and
then there is no activity until a new alert is generated 4 hours later.

se
a. Given just this information, how would you classify the alert:
1. False Positive – Likely or False positive – Possible (both good)

re
b. What reasoning backs up this classification?
The consistent nature of these alerts, and the fact they appear to originate from a sever in the server network
imply that this is a regularly scheduled operation. Perhaps it is an API call, or a content update, or an internal

s
security scan. The Alert type of HTTP Protocol Violation, could be consistent with this scenario as well.

ht
c. What additional information would help make a determination?
What Protocol violation are we seeing, if it is a large parameter size, perhaps the application was designed

ig
that way? Looking for additional violations would help as would reviewing the details of the request for invalid
data or attack patterns. lr
3. Many alerts are occurring with Web Profile violations, mostly regarding Parameters like Unknown Parameter,
Al
Parameter Type Violation, and Parameter Size Violation. All of the Alerts are being identified as Distributed in
the Alert Description.
a. Given just this information, how would you classify the alert:
c.

1. Cannot say (Best Answer), False Positive – possible (Also OK)

In

It depends on the accuracy of the profile from learning and tuning. If the profile is well tuned then this is
more likely an attack.
b. If you also noticed the number of Alerts for ThreatRadar Malicious IP increased during the same time, how
a,

would you classify the alert:

rv

1. Attack – Likely
2. What reasoning backs up this classification?
pe

The fact that the activity of known malicious IP addresses increased at the same time the profile violations
increased is strong evidence for a distributed attack. If the attacker was using a botnet, some of the bot IP
addresses may be new and unknown. The web profile policy will still identify any abnormal activity from the
Im

unknown attack IPs.

c. If the web developers announced updates to the web application over the next several weeks, what
17

conclusion would you draw?

1. False Positive – Likely
2. What reasoning backs up this classification?
20

Changes to the web application may require the profile to re-learn the URLs and parameters where the
changes were made.
©

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 7-23 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

Answers to Exercises
Exercise 1:

Find a Suspicious Response Code Alert. Review the originating policy, the policy description, and details from the
Violations to better understand this alert.

.
Which direction is the web traffic going in these alerts?

ed
A: This is return traffic from the server to the client.

rv
se
Exercise 2:
Review several of the violations in the Suspicious Response Code violation. Are all of the violations clearly attacks,

re
false positives, or a mixture?
A: Almost all are violations.

s
ht
What details helped with this determination?

ig
A: Reviewing violation details within the alerts.
lr
Al
Exercise 3:
c.

From one of the violations in the Suspicious Response Code Alert, Select the Filter icon to filter the alerts by the IP
In

address 192.168.55.200.
a,

Can you find clear indications of malicious or attack activity from this IP address in the Alerts or Violations logs?
rv

A: Yes, however answers will vary. This client is performing a vulnerability scan of the destination server.
pe

Provide the Alert, or Violation Names used to justify your answer.

A: Answers vary. Discuss with the class and Instructor.
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 7-24 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 7-25 Lesson 7: Alerts, Violations and Monitoring
SecureSphere 12.0 Web Application Security Course Manual

SecureSphere Web Application Firewall Tuning

Chapter Overview
Tuning is an essential step in any SecureSphere deployment, improving both system performance and accuracy. In
this lesson we will discuss the tuning of SecureSphere Web Application Firewall deployments including Profile
Tuning, Alerts and Violations Tuning, Reports used for tuning, policy exceptions and policy changes.

.
ed
Chapter Objectives

rv
• Tune SecureSphere to minimize false positives, streamline profiles, improve policies and reduce non-essential
alerts.

se
o Configure reports in addition to the alert/violation reports, to identify where to tune SecureSphere.
o Explain how the profile optimization wizard can assist in tuning profiles.

re
o Explain the impact and trade-offs of profile tuning options.
 “add to profile” button

s
 Parameter prefixes

ht
 URL Patterns
 Plug-ins (advanced)

ig
o Impact of adjusting policies (best practice, using copies of default/built-in policies).
 Adjustments to default / built-in policies are very broad in scope; tuning a default policy for 1 application
lr
may have unintended impact on other applications.
 Changes / adjustments to custom policies with highly targeted criteria / specific applications have a more
Al
narrow scope, but may need to be manually repeated across many policies.
o Impact of policy adjustments on Correlation Policies
c.

 Changes to built-in policies may alter how Correlation policies work.

 No alert vs. disabling rules/policies
In

o Signature and Dictionary tuning impact

 Writing new patterns – using “part” not only regex to save CPU cycles.
a,

 Using Match Criteria other than only regex, to save CPU cycles.
o Missing hostnames in alerts may indicate a need to fix GW DNS settings.
rv

o Web Scanner / Pen Test IPs may need access through SecureSphere, or they may be testing SecureSphere’s
pe

security – be sure to make exception for IPs, if necessary.

Im

Tuning Overview
Tuning is an essential step for all SecureSphere deployments. Tuning improves both performance and accuracy of
17

the deployment. When tuned, the most critical security events can be quickly identified from the Alerts and
Violations logs or in the corresponding reports. Tuning may require adjustments to the Sites Tree, to the Web
20

Application Profiles, and to the web security Policies.

©

Policy Accuracy
When discussing the accuracy of Security Policies, the terms False Positives and False Negatives are often used.
These terms are from statistics and used to describe the four possible results when it is possible that the test itself
came to the incorrect answer.

© 2017 Imperva, Inc. All rights reserved 8-1 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

Rule Action Client Browses Web Site (Good Behavior) Hacker Attacks Web Site (Attack Behavior)
Policy Rule Matches False Positive – Valid Traffic is blocked True Positive – Correct Action, Attacker
Blocked
Policy Rule Does Not True Negative False Negative – Attacker Not Blocked
Match Correct Action – Valid Traffic Allowed
Table 8-1 - False Positives and False Negatives Explained
For Web Application Security False Positive events can have significant and obvious impacts because legitimate
activity is being identified as an attack. If the policy rule is set to block, clients may be unable to use the web site.

.
ed
False Negative errors can also very serious impacts because they are attack events that were missed. SecureSphere
tuning is the process of resolving both false positive and false negative events.

rv
Tuning Workflow

se
The following workflow is recommended to address the most common tuning requirements.

re
1. Verify SSL Traffic is being properly decrypted by SecureSphere
2. Exclude Trusted Traffic with Source Restrictions

s
ht
3. Web Application Profile Tuning
a. Review Alerts and Violations for profile tuning opportunities.

ig
b. Use Profile Optimization.
c. Common Profile Tuning Actions lr
1. Parameter Prefixes – password1 and password2 on the registration page
Al
2. Creating URL Patterns for dynamic web applications
3. Options when prefix or suffix matches are insufficient (Plugins)
c.

4. Alerts and Violations Tuning

a. Review the Top 10 WAF Violations report to identify the most frequent sources of violations
In

b. Identify and tune high frequency False Positive violations

c. Identify and block high frequency attack behavior
a,

d. Review Gateway Performance in Admin > System Performance

rv

SuperVeda Lab Preparation

pe

In order to demonstrate the tuning process, the following preparation steps need to be performed in the SuperVeda
Im

lab environment first.

17

Preparing the SuperVeda Lab for Tuning

The following steps are required to prepare the SuperVeda lab for the following tuning activities.
20

1. Verify Gateway Performance Monitoring is enabled:

a. Select Main > Setup > Gateways.
©

© 2017 Imperva, Inc. All rights reserved 8-2 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

b. Select the Gateway Group veda-gw,IMPVHA Bridge, Imperva(1).

.
c. In the Gateway Group Details pane, Performance Profiling section, select Enable. This may have been done

ed
during the Administration class.

rv
se
re
s
ht
ig
lr
Al
c.
In

d. Save changes.
a,

2. Protect all profiled URLS on the SuperVeda - Web Application

a. Select Main > Profile > Application View.
rv
pe
Im
17
20

b. Use the Select Application window to select the SuperVeda - Web Application.
Note: if an application is automatically displayed, use the Change Application button to bring up the Select
©

Application window.

© 2017 Imperva, Inc. All rights reserved 8-3 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

c. Select URLs (Tree View) and expand the entry SuperVeda Web SG – SuperVeda Http – Service – SuperVeda
Web Application to locate the folder /(root directory).

.
ed
d. Right click on the /(root directory) folder and select Switch Mode.

rv
se
re
s
ht
ig
lr
e. Configure the Switch Directory Status window as follows:
Al
Select: All URLs in This Directory and in all subdirectories
Select: Protect
c.
In
a,
rv
pe
Im

f. Click Switch to apply the changes.

3. Protect all profiled URLS on the Vedaadmin - Web Application
a. Repeat Steps B-G from above.
17

4. Verify all URLS are protected for both the SuperVeda - Web Application and the Vedaadmin - Web Application
a. Select Main > Profile > Overview
20

b. Expand the SuperVeda Web SG and SuperVeda – Http – Service from the Profile Sites tree
c. Verify the numbers in the URLs Total and Protected columns are the same for both the SuperVeda – Web
Application and the Vedaadmin – Web Application.
©

© 2017 Imperva, Inc. All rights reserved 8-4 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
The number of URLs in your environment may differ.

ig
5. Initiate Traffic simulation scripts on the SecureSphere Gateway:
a. Log into the SecureSphere Gateway CLI via the console or SSH.
lr
b. As root, run the following CLI commands:
Al
waf-tuning-1.sh
c.
In

It will take several minutes for the script to finish.

Verifying SSL Traffic Decryption

a,
rv

SSL traffic is decrypted by the SecureSphere Gateway at the time of inspection. This process requires the SSL keys
used by the protected web applications and are installed during the initial configuration. Normally verifying the SSL
pe

Keys is performed at the time of installation under Main > Monitor > Dashboard, or Main > Monitor > Alerts. The
Alert or identifying problems with SSL traffic is the Untraceable SSL Sessions and is a rule in the Network Protocol
Im

Validation security policy.

17

SSL untraceable events occur for one of three reasons:

1. The SecureSphere gateway did not see the initiation of the SSL connection.
20

2. SecureSphere has no access to the server's private key used to establish this session.
3. The SSL cipher method used for this session is not supported by SecureSphere.
©

As mentioned earlier, the first reason generally resolves itself rapidly. It is most commonly associate with a gateway
restart but it can also occur during a gateway High Availability failover, or when a service is first added to the Sites
Tree.

© 2017 Imperva, Inc. All rights reserved 8-5 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

The last two causes of Untraceable SSL Sessions are more concerning because they indicate a problem that could
make all encrypted traffic indecipherable. SecureSphere will be unable to inspect this traffic and unable to protect
against attacks.

Missing SSL Keys / Unknown Server Certificate

When SecureSphere is missing an SSL Key, Alerts like the following will be visible.

.
ed
rv
se
re
s
ht
ig
lr
Al
Figure 8-1 - Untraceable SSL Sessions: Unknown Server Certificate
c.

The missing certificate is identified under the Certificate Column. To further identify the certificate the certificate,
In

this value can be copied from the alert and entered into a certificate decoding program. Alternatively it can be saved
as a CRT text file and viewed from the workstation.
a,
rv

Tip
pe

In windows, you can save the certificate as a CRT file. Copy the full line and paste it into notepad.
Surround the certificate with -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----.
Im
17
20
©

Save the file with a CRT extension and open the resulting file.

In windows, once open select the Details tab to view the certificate details.

© 2017 Imperva, Inc. All rights reserved 8-6 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
SSL Cipher Method / Unsupported Cipher

s
The last type of SSL Untraceable event is caused by an unsupported cipher. Unsupported Ciphers are encryption

ht
ciphers that are either weak or are technically incompatible with inline analysis. Weak ciphers are unsafe for use and

ig
should be disabled on the protected servers. Ciphers presenting technical incompatibilities affect SecureSphere
Gateways deployed in the Inline Bridge or the Sniffing network configurations. The primary example of this is the
lr
Diffie-Hellman Cipher. By design, the Diffie-Hellman cipher cannot be analyzed by a device in the middle of the
Al
traffic stream. This is a design feature and affects all inline systems.
c.

The following Alert was generated due to a Diffie-Hellman unsupported cipher.

In
a,
rv
pe
Im
17
20
©

Figure 8-2 - Untraceable SSL Sessions: Unsupported Certificate (Diffie-Hellman)

Notice that the cipher name contains DHE which indicates the cipher is based on Diffie Hellman.

Note

© 2017 Imperva, Inc. All rights reserved 8-7 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

Not all Untraceable SSL Violations are due to missing certificates. Some SSL Based attacks may also generate
Untraceable SSL Alerts. When unsure, filter the alerts or violations by the client IP address. If other violations are
present, in particular network or HTTP Protocol violations, the client was likely testing for a vulnerability on the
protected web application.

Resolutions for Unsupported Ciphers

.
The general solution for Unsupported Ciphers is to disable the ciphers on the protected web server. This is especially

ed
important for weak ciphers, which do not provide adequate security for the client’s traffic. If strong Diffie-Hellman
ciphers are in use, and disabling them is not an option, there is an alternative. The SecureSphere Gateway can be

rv
deployed in Reverse Proxy mode, which allows the Gateway to terminate the client session. However, this may

se
require network architecture redesign and reconfiguration.

re
Exclude Trusted Traffic with Source Restrictions
In many SecureSphere deployments, traffic from some sources is considered trustworthy and can be ignored. The

s
ht
most common source of trustworthy traffic for Web Application Firewall deployments is from trusted web
vulnerability scanners. Excluding this trusted traffic allows the vulnerability scanner to have an unobstructed view of

ig
the protected web applications. An unobstructed view is important because when SecureSphere is set to Active it
lr
will block the vulnerability exploit patterns used by the scanner to assess the vulnerabilities present on the web
application. While this does provide an accurate view of the effective security provided by SecureSphere, it
Al
interferes with an accurate understanding of the security of the protected web applications.
c.

Having an incomplete view of the vulnerabilities limits the organizations ability to correct the problems in the web
applications. When vulnerabilities are not identified and resolved, the following problems can easily arise:
In

• Web developers may mistakenly believe the underlying code is safe and introduce new vulnerabilities through
a,

code reuse.
• Due to a lack of awareness of vulnerabilities, the web application is perceived to be safe enough go
rv

unprotected for a ‘short’ maintenance period. With automated vulnerability scanning by attackers, this is not a
pe

safe assumption.
• Unidentified vulnerabilities increase the possible impacts of uncommon but damaging attacks. For example, a
Im

malicious insider attacking from an adjacent server could leverage unidentified vulnerability in an attack.
17

Configuring Source Restrictions to Ignore Trusted Clients

20

1. Select Main > Setup > Sites.

2. Expand the Sites Tree as needed to select the relevant Service Object.
3. From the Service Object window, select the Definitions tab.
©

© 2017 Imperva, Inc. All rights reserved 8-8 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

4. Locate and expand the Source Restrictions section.

.
ed
5. For the Ignore IP Group option, click the icon to create an IP Group. The Configure IP Groups window will

rv
appear.
6. Click to create a new IP Group, provide an appropriate name and click create.

se
re
s
ht
ig
lr
For this SuperVeda training lab example the name is SV – Web Vulnerability Scanner.
Al
7. Configure the IP Group with the relevant IP addresses to exclude from inspection.
c.
In
a,
rv

In the SuperVeda training lab, the internal vulnerability scanner IP is 192.168.51.215.

8. Save changes and close the Configure IP Groups window.
pe

9. For the Ignore IP Group option, select the newly created IP Group.
Im
17

For this SuperVeda training lab example select SV – Web Vulnerability Scanner.
20

10. Save changes.

Note
©

Choose Ignored IP Addresses with care since all traffic from ignored IPs will be allowed without any inspection by
SecureSphere.

Common Web Profile Problems

© 2017 Imperva, Inc. All rights reserved 8-9 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

The Web Application Profile is incredibly powerful at highlighting abnormal client activity when properly trained.
However, if left unattended during the learning process it can generate significant numbers of false positive Alerts
and Violations.

The most common web profile problems are:

• Web Profile Policy false positive Alerts and Violations

• Incomplete or inaccurate learning due to dynamic content

.
ed
Web Profile False Positive Tuning

rv
A key aspect to tuning is the Web Application Profile. Profile violations can surprise Security Administrators because
no alerts are generated for URLs in learning. Over time, individual pages are switched to protect which causes a few

se
Profile violations to occur. However, the surprise occurs when the global Switch to Protect thresholds are reached
and all remaining pages and cookies are switched to protect.

re
If the profile was unattended during learning, it is very common to have many URLs with incomplete or incorrect

s
learning. When switched to protect, many alerts can be generated daily.

ht
ig
During the initial configuration lesson, the Switch to Protect thresholds were set to very low values to allow the
switch to protect to occur during class and this may have already occurred. However, new learning events restart
lr
the timer and the global Switch to Protect thresholds still may not have been reached. For this reason, we manually
Al
set all URLs to protect before running the waf-tuning-1.sh script.
c.

Tuning Web Profile Policy False Positives Alerts and Violations

In

The following process walks through the analysis of two profile alerts to identify Profile tuning opportunities. The
following workflow will be followed in the analysis and tuning process.
a,

1. Identify an Alert or Violation that may provide a tuning opportunity.

rv

2. Rule out attack activity:

a. Identify the Alert Type and the number of events in the alert.
pe

b. Review the Alert details for signs of an attack

c. Filter the Alerts and Violations logs to identify other actions from the client that may indicate an attack
Im

d. If still unsure, work with the web developers for verification

3. Resolve the false positive by tuning the profile
17

a. Tuning the profile with the Add to Profile button

b. Tuning the profiled URLs from the Application View
20

Web Profile Policy Alert Analysis

1. Select Main > Monitor > Alerts
©

2. Using the Basic Filter locate the Alert – Parameter Type Violation mode in attack.superveda.local/register.asp.

© 2017 Imperva, Inc. All rights reserved 8-10 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

a. Locate and expand the By Alert Type and By URL Basic Filter search fields.

.
ed
rv
se
re
s
ht
ig
lr
Al
b. For the By Alert Type field, select Profile.
c.
In
a,
rv
pe
Im
17

c. Configure the By URL search field as follows:

Operation: Equals
20

Value: /register.asp
©

d. Apply the filter.

3. Locate and select the Parameter Type Violation mode in attack.superveda.local/register.asp Alert from the
Alerts Table. If more than one Alert has the same description is visible, select the Alert with the highest

© 2017 Imperva, Inc. All rights reserved 8-11 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

number of events.

.
ed
rv
se
a. At this point the alert looks like a good candidate for being a false positive for the following reasons:

re
1. The Alert type is a Profile Violation type, the deployment is new, and the Profile URLs were very recently
switched to protect.

s
2. The Alert has a large number of events in comparison to other events from around the same time.

ht
b. Profile false positive events usually impact many clients and are identified as Distributed during the
aggregation process. If this Alert is description was “Distributed Parameter Type Violation…” instead of just

ig
“Parameter Type Violation…” the case for this being a false positive would be further strengthened.
lr
c. The Alert aggregated by table will also provide insights into commonalities between the underlying
violations grouped in this alert. Note that Source IP is one of the distinct values used for aggregation.
Al
c.
In
a,
rv
pe

d. A single source IP address and is inconsistent with the most common types of Profile false positives.
Im

However, a high volume parameter type violations could occur if a business partner, or remote office was
accessing an infrequently used URL, for example thorough a set of API calls. The SuperVeda organization has
a small office in London England. Next use Geo-IP If this request is from London, then it could still be a false
17

positive.
20
©

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 8-12 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

e. From the Alert details pane, expand the first Violation shown and click the source IP address link.

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In

f. IP Address 117.89.105.98 IP Forensics map results:

a,
rv
pe
Im
17
20

g. The country of origin is China which contradicts the possibility of a business partner, or remote office
©

triggering the alerts. At this point the activity does not look like a false positive, instead it is beginning to
look like an attack.
h. Next look for other concerning activity from the source 117.89.105.98. Uncertainty with the initial Alert can
often be resolved by finding other examples of obviously bad behavior from the client that occurred near
the time of the original Alert. This helps avoid over analysis of the original Alert.

© 2017 Imperva, Inc. All rights reserved 8-13 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

1. From Violations area of the Alert, locate the IP 117.89.105.98 under Connection and click the Funnel icon
to filter the alerts by the Client IP address. Select Change current filter according to this field.

.
ed
2. Briefly review other Alerts from the Alerts List to identify potential attack activity from this client. Pay
attention to Alerts marked as High Severity and especially Alerts with an Action of Immediate Block or

rv
Immediate Block (Simulation Mode).
3. Looking through other alerts from this source IP address shows many different attack patterns:

se
a. Many examples of traversal attempts, for example:

re
b. Many examples of SQL Injection attempts:

s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im

This example is especially telling, since PG_SLEEP appears to be a command for PostgreSQL databases
but the SuperVeda Web site based on MSSQL.
17
20
©

© 2017 Imperva, Inc. All rights reserved 8-14 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

c. Numerous additional examples of Cross Site Scripting (XSS), Remote Command Execution, and
Directory Traversal can be found under the Multiple Signatures from 117.89.105.98 Alert.

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,

i. With the quantity and severity of related Alert activity from the source IP, it is safe to conclude the
rv

Parameter Type Violation Alert was correct in Alerting on the client activity.
4. In the SuperVeda environment, the most frequent Parameter Type violations appear to be actual attacks, but it
pe

is possible that other Parameter Type violations contain false positive events. Next us filters to focus on other
Parameter Type Violations to identify potential False Positives:
Im

a. Select the Advanced filter and configure it as follows:

Enabled Field Name Setting

17

Alert Type Operation: Equals

20

Selected: Profile
Last Few Days Last: 3 days
Source IP Operation: Not Equals
©

Values: 117.89.105.98
b. Once configured, Apply the filter.

© 2017 Imperva, Inc. All rights reserved 8-15 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
c. Review the resulting Alerts list which will look similar to the following figure.

ig
lr
Al
c.
In
a,
rv
pe
Im

d. The First entry in this list is from the internal web vulnerability scanner on IP 192.168.51.215. This is a false
17

positive and is resolved by Source Restrictions – Ignored IP Group settings, discussed earlier.
e. Review the other Alerts to identify two IP addresses in the 192.168.51.0/24 network range. Which two IP
20

addresses did you find? (192.168.51.31 and 192.156.51.40).

f. The 192.168.51.31 IP address is the Veda Client workstation. Since both valid and attack traffic has
originated from here, we’ll focus on the other IP address for now.
©

© 2017 Imperva, Inc. All rights reserved 8-16 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

g. The IP address 192.168.51.40 is from a client browsing the SuperVeda Web Application. Review the alert
titled: Parameter Type Violation string in www.superveda.local/dosearch.asp

.
ed
rv
se
h. Analyze the alert details and try to identify if the violations are false positives or attacks.

re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

i. Take a moment to review other violations from the client at 192.168.51.40.

1. Search the Alerts and Violations logs for potential attacks from this IP address.
2. Review the Alerts or Violations for any Suspicious Response Code Alerts from this client. The client could
be performing a fuzzing attack which tries to identify vulnerabilities in the web application by sending

© 2017 Imperva, Inc. All rights reserved 8-17 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

random data to every parameter on the page. Fuzzing attacks generate many Suspicious Response Code
Violations.
3. Review the Alerts or Violations for any Web Protocol or Network Protocol violations from this client. Thje
client could be performing a Web Vulnerability scan, which will also generate numerous protocol
violations.
5. Did you find obvious signs of attack activity for the client at 192.168.51.40? (No).
6. The activity from the client at 192.168.51.40 is legitimate and the Profile Violations for this user are false
positives.

.
ed
Tuning the Web Profile to Eliminate False Positives
When a web profile policy false positive is identified it can be addressed directly from the Alerts or Violations logs,

rv
as well as from the Profile itself.

se
The following Alert shows several Violations due to unexpected characters in the returned parameters.

re
s
ht
ig
lr
Al
c.
In
a,
rv
pe

Figure 8-3 - Web Profile Policy Alert showing parameter values and types

The profile can be updated directly from the Alerts or Violations details. The icon in the Alerts and Violations
Im

details pane adds the missing character types to the profile for the relevant URL and parameter.
17
20
©

Figure 8-4 - Alert Details Pane, Violation details with the Add To Profile icon highlighted.

The changes can be confirmed from Main > Profile > Application View. Select the relevant application, URL and the
parameter Value Type link.

© 2017 Imperva, Inc. All rights reserved 8-18 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
Figure 8-5 - Profile URL, Parameter and Value Type Link identified
lr
The Configure Value Type window will show the acceptable characters. In the following figure, note that both
Al
Comma and Parenthesis characters are now allowed due to clicking the Add to Profile button earlier.
c.
In
a,
rv
pe
Im
17
20
©

Figure 8-6 - Configure Value Type window showing Comma and Parenthesis selected

© 2017 Imperva, Inc. All rights reserved 8-19 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

The Add to Profile Icon works for other Profile Violations like parameter size violations, cookie violations, and more.

Tuning the Profiled URLs from the Application View

Correcting profile learning from the Alerts and Violations logs is easy with the Add to Profile button and works well
as long as the number of URLs is limited. However, tuning from the logs becomes cumbersome as the number of
URLs increases. At some point, it will make more sense to tune from the Application View. The following table
provides some suggestions for profile tuning as the number of problematic URLs increases.

.
ed
Number of URLs Causing Recommendation Details

rv
Profile False Positives
Manually tune the profile from false positive events in

se
Small – Less than Twenty
Manual Tuning the Alerts or Violations logs. Make use of reports to
URLs (approx.)
ensure all URLs are identified and to track progress.

re
Option 1: Restart Learning When sufficient URLs require several adjustments to
(Select URLs Only) eliminate false positives, it can be faster to switch the

s
select URLs into learning manually.

ht
Medium – less than one The Automatic Profile Update (APU) thresholts can
Option 2: Adjust APU

ig
hundred URLs automate the switching of URLs into learning.
Thresholds
Lowering the threshold values may be appropriate.
lr The overhead of identifying and switching URLs back
Al
Option 3: Restart Learning to learning can be significant. If so, consider manually
(All URLs) switching all URLs to learning to address significant
false positive events across many URLs.
c.

If hundreds to thousands of URLs are generating false

In

Option 1: Restart Learning positives, consider switching all URLs into learning.
(All URLs) and Adjust APU The APU thresholds should be also lowered to allow
a,

Large – Hundreds to Thresholds. pages to more rapidly switch to learning on their

rv

Thousands own.
For large web applications with many false positives
pe

Option 2: Empty Profile and

on many URLs, clearing the profile and starting fresh
Restart Learning
may be the best option.
Im

Table 8-2 - Web Profile False Positive tuning strategies for small, medium and large numbers of URLs

Note
17

Do not empty the profile in your SuperVeda lab environment at this time. If you would like to see the process, it
20

can be performed after all other lab exercise are complete.

©

Emptying the profile and restarting learning should be avoided if possible. However, when a large number of
profiled URLs generate numerous false positive violations, it can be the most efficient option. It is done by first
selecting the relevant application under Main > Profile > Application View and then selecting the URLs (Tree View).

© 2017 Imperva, Inc. All rights reserved 8-20 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

Expand the URLs tree, right click the /(root directory) folder and select Empty Directory from the menu.

.
ed
rv
se
Figure 8-7 - Emptying /(root directory) to clear all learned URLs to restart learning

re
Web Profile Learning Problems

s
ht
Modern web applications are complex collections of software and can present challenges to the learning process.

ig
The SecureSphere Web Profile has a URL centric view of the protected application. This URL centric view can run
lr
into problems with Dynamic Web Applications or with very large applications containing many hundreds of URLs. A
Dynamic Web Application is a web application is built from web page templates that are dynamically populated with
Al
data at the time of the request. For example, a news site may appear to have a unique URL for each news day.
However, the web server may use a single page and populate the day’s news based on the URL requested by the
c.

client.
In

SecureSphere includes an automatic Profile Optimization process which can help identify such learning problems
and provides recommended solutions.
a,
rv

Profile Optimization
pe

Profile Optimization automatically analyzes the profile for potential learning problems and suggests solutions. The
Im

Optimization analysis runs automatically when sufficient learning has occurred in SecureSphere. It can also be run
manually.
17

Manually Initiating Profile Optimization

20

Select Main > Profile > Application View and select the relevant application.
©

© 2017 Imperva, Inc. All rights reserved 8-21 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

Select Optimization then the Detect Optimization Issues button. Click through the confirmation windows.

.
ed
rv
se
re
s
ht
ig
lr
Al
c.

The optimization process depends on the profile size and may take some time to complete.
In

When complete potential issues are listed. Selecting an issue highlights recommended adjustments that could
a,

potentially resolve the issue.

rv
pe
Im
17
20
©

In the above example, the potential profile optimization issue of Large Number of Similar Alerts was detected from
the Alerts log. In this case the parameters can be directly adjusted from the recommended Adjustments window by

© 2017 Imperva, Inc. All rights reserved 8-22 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

clicking the Go button.

.
ed
rv
se
re
s
ht
If the recommended changes are appropriate click the Save button to update the profile accordingly.

ig
Incomplete learning due to profile size limits
lr
The Profile Size Limits can be viewed under Admin > System Definitions in the Dynamic Profiling folder.
Al
c.
In
a,
rv
pe
Im
17
20
©

Figure 8-8 - Admin > System Definitions, Profile Size Limits, WAF Size Limits Highlighted

© 2017 Imperva, Inc. All rights reserved 8-23 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

Although the size limits can be increased, this rarely solves the problem of hitting the size limits. In a dynamic web
application, additional dynamic pages rapidly fill up the additional space. In very large web applications the total
number of URLs remaining to be profiled likely exceeds any reasonable threshold. However, profile tuning can
address these challenges.

Tuning for Dynamic Web Applications

For dynamic web applications, profile tuning not only addresses the size limits, it also provides key benefits. The

.
ed
SecureSphere Web Profile analyzes client submissions to web page parameters looking for inconsistencies in the
data type, size, required or read only status. In a dynamic web application, the data type and structure are defined
by webpage page templates. The number of templates is a tiny fraction of the apparent pages seen by users. When

rv
a template is protected, all of the pages based on it are also protected. Another benefit is an increase in the speed

se
and accuracy of the learning process due to the volume of unique client requests all associated with the template.

re
Dynamic web pages appear in the Web Profile as many URLs that appear to follow a consistent pattern. In the
following example shows dynamic pages in the customers directory.

s
ht
ig
lr
Al
c.
In
a,

Figure 8-9 - Dynamic Web Application Impact on Profile

rv

The following options are available for profile tuning with dynamic web applications
pe

• URL Patterns
Im

o URL Prefix - Treat all URLs starting with the pattern as a single URL
o URL Suffix – Treat all URLs ending with the pattern as a single URL
• Web Plugins
17

From the Above case, the customer home pages can be consolidated the following URL Pattern:
20

URL Pattern: /customers/c_home

Type: Prefix
©

© 2017 Imperva, Inc. All rights reserved 8-24 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

.
Figure 8-10 - Create New URL Pattern for URL Prefix /customers/c_home

ed
After creating, the URL Pattern shows in the URL Patterns list.

rv
se
re
Figure 8-11 - URL Patterns List

s
After creating the URL pattern, the previously learned URLs matching the pattern are consolidated into the URL

ht
pattern and cleared from the cleaned from URL tree and list views.

ig
lr
Al
c.
In
a,
rv
pe

Figure 8-12 - URLs Tree view after URL Pattern consolidation

Im

URL Patterns work well when the dynamic patter occurs at the beginning or ending of the URL. If the dynamic web
application URLs are more complex, more advanced manipulation of the URLs and parameters is available with
17
20
©

© 2017 Imperva, Inc. All rights reserved 8-25 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

Plugins. The following example shows a collection of dynamic web pages that are best resolved with plugins.

.
ed
rv
se
re
s
ht
ig
Figure 8-13 - Dynamic URLs best resolved with Plugins.

lr
Using a prefix filter of /customers/ would consolidate two unrelated web pages, home.html and mail.html.
Consolidating unrelated pages should be avoided when possible. Plugins can resolve many dynamic URLs problems.
Al
Plugins are included in SecureSphere and do not need to be uploaded or installed but do need to be configured to
work.
c.
In

The configuration of plugins is application specific and is beyond the scope of this class. However, detailed
information on plugins is available in the Imperva SecureSphere v11.5 Web Security Users Guide. Imperva
a,

Professional Services can also assist with plugin configuration and tuning for complex web applications.
rv
pe

(Continued on next page)

Tuning for Very large Web Applications

Im

Profile tuning for very large web applications quickly exceed profile size limits. Identification and resolution of any
dynamic URLs is a critical first step, and in most cases resolves the profile size limit issues.
17

If size limits continue to be exceeded, a few additional options are available:

20

• Configure URL Learning Settings

• Map large applications to multiple Web Application objects
©

• Disabling We Profiling

Configuring URL Learning Settings

Option Set URL Learning to: All except static URLs with no Parameters, or Only URLs with Parameters

© 2017 Imperva, Inc. All rights reserved 8-26 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

Benefit The Profile only learns pages that contain parameters. Static content like static HTML pages and
style sheets, and images are not learned by the profile.
All except static URLs with no parameters: Learn all URLs, except for static URLs (files) in GET and
HEAD requests that have no parameters.
Only URLs with parameters: If a URL in a GET or HEAD request has no parameters, do not learn it
in the profile.
Consideration HTML pages without parameters are typically static content and presents fewer attack
opportunities compared to URLs accepting user supplied content. However, static pages are

.
ed
implicated in some attack strategies such as Cross Site Scripting. Configuring SecureSphere to
only profile URLs that contain parameters may be appropriate choice if the application exceed

rv
the capacity of the profile. Alternatively, large and critical web applications can be protected
with multiple applications in the site tree. For details see: Mapping large applications to multiple

se
Web Application objects

re
Table 8-3 - Configuring URL Learning Settings

s
The URL Learning Settings are configured in the Web Application Object as follows:

ht
1. Select Main > Setup > Sites, expand the Sites Tree and select the relevant Web Application object.

ig
2. With the application selected locate the Advanced settings on the Definitions tab.
lr
Al
c.
In
a,
rv
pe

3. Locate the URL Learning settings in the Advanced Settings area.

Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 8-27 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

4. Select the desired learning setting

5. Save changes.

Mapping large applications to multiple Web Application objects

Large applications can be profiled by identifying major functional areas of the application and mapping those areas
to separate Application objects in the SecureSphere Sites Tree.

Option Map application to multiple Web Application Objects.

.
ed
Steps:
1. Identify logical segments of the protected web application

rv
2. Define URL Groups Global Objects based on those segments
3. Create additional Web Application Objects in SecureSphere

se
4. Configure Application Mapping with URL Groups to direct traffic to the relevant Web
Application Sites Tree objects.

re
Benefit Allows profiling of large web applications that could not be profiled otherwise.

s
Consideration Configuration requires research and planning. This may require additional ongoing maintenance

ht
for the SecureSphere deployment.

ig
Table 8-4 - Mapping Large Web Applications
lr
The process for mapping large applications to multiple SecureSphere Web Application objects can be demonstrated
in the SuperVeda lab. Although the SuperVeda Web Application is not large by any measure, it does have the
Al
unfortunate design flaw of hosting both the E-commerce application as well as the site administration pages on the
same server. This is a bad security practice because an attacker who successfully compromises the public facing
c.

website is very likely to get access to the site administration as well.

In

Profiling can further improve the security position of SuperVeda if all E-commerce traffic and site administration
a,

traffic can be profiled separately. However, the basic Application Mapping performed earlier, Lesson 3, is not
sufficient.
rv
pe

The issue with the original mapping can be seen by attempting to go to the URL: www.superveda.local/vedaadmin/.
This request works and brings up the SuperVeda website administration page.
Im

Looking at the current Host/URL Application Mapping reveals the issue:

17
20
©

Since the requested host was www.superveda.local the traffic will be directed to the SuperVeda – Web Application
instead of VedaAdmin – Web Application.

© 2017 Imperva, Inc. All rights reserved 8-28 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

Defining URL Groups Global Objects

1. From the SecureSphere Web Interface, select Main > Setup > Global Objects.
2. From Scope Selection, select URL Prefixes/Directory Groups.

.
ed
rv
se
re
s
ht
ig
lr
3. Create a new URL Prefix / Directory Group, providing a relevant name.
Al
c.
In
a,
rv

4. In the URL Prefix / Directory Groups window, click create to add rows to the URL Prefix table and configure the
pe

rows as needed.
Im
17

5. Save Changes.
20

Configure Application Mapping with the use of URL Groups

1. Select Main > Setup > Sites
©

2. Expand and select the relevant Service Object from the Sites Tree and on select the Applications tab from the
HTTP Service pane.

© 2017 Imperva, Inc. All rights reserved 8-29 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

3. Configure the Host/URL Application Mapping as needed. In the case of SuperVeda, the following will correctly
map all administrative activities to the Vedaadmin – Web Application.

4. Save changes.

.
ed
Alerts and Violations Tuning

rv
We’ve already seen a sneak preview of tuning while looking at the profile alerts. However, with profiling, we were

se
using the alerts and violations to identify false positive events. The number of events aggregated into an alert was
merely evidence to help identify potential false positives.

re
When tuning Alerts and Violations in general, the focus still starts with the number of events. However, in this case

s
our concern is to reduce the total number of alerts and violations so critical events are easily identified in the logs.

ht
ig
While it is possible to tune SecureSphere by reviewing events in the Alerts and Violations logs, tuning from the alerts
and violations logs can distract from addressing the most critical alerts and violations first. Instead, it is better to
lr
begin the tuning process with Top Ten Alerts reports. The top ten violations reports provides an unbiased view of
Al
the most frequent violations and allows focusing your tuning efforts on the most frequent issues.
c.

When working from the top ten report, your tuning efforts will focus on the biggest issues first and provide the
biggest positive impacts when tuned.
In
a,

Steps to Review the Top Ten Alerts:

1. Schedule the Top Ten WAF Alerts report to run daily.
rv

2. Analyze the report:

pe

a. Review the Breakdown by Alert Name Graphs

1. What is the top alert type?
Im

b. Review the Breakdown by Source IP Graph

1. Are any trusted IP address listed in the results?
c. Review the Breakdown by URLs Graphs
17

1. Identify commonly attacked URLs

d. Review the Breakdown by User Graphs
20

1. Identify user accounts associated with attacks, or false positives.

2. Significant activity with a user could indicate a compromised account.
©

3. Analyze the single most frequent Alert type and classify as:
a. False Positive
b. Attack Activity
c. Mix of False Positives and Attack Activity
4. Resolve the alert as follows:
a. False positives: Use the Alerts and Violations logs to identify a tuning option to eliminate the false positives.

© 2017 Imperva, Inc. All rights reserved 8-30 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

b. Attack activity: If the number of alerts is high, consider a short or long IP block policy. This will essentially
quarantine bad actors. If the number of alerts is sufficiently low, acknowledged the alert and move on.
c. Mixed False Positive and Attack Activity: Analyze the alerts and violations logs to identify commonalities
between the false positive events. Add an exception to the Security policy based on those commonalities.
5. Repeat steps 2 and 3 on the remaining nine alert types, from highest to lowest frequency.
6. Work through the top 10 report each day for two weeks or for a total of ten days.
7. After two weeks, schedule the Top Ten WAF Alerts report to run weekly. Maintenance tuning can be
performed weekly.

.
ed
Questions

rv
se
1. Why is the Untraceable SSL Session: Unknown Server Certificate Alert cause for concern if the severity is only
Informative?

re
2. How are Untraceable SSL Session: Unsupported Cipher Alerts resolved?
3. Give a possible consequence of having an incorrect IP address in the Source Restrictions - Ignored IP group

s
settings?

ht
4. What advantage does a Long Session Block Followed Action have over a Long IP Block Followed Action? (Hint –
Think about possible problems with blocking all traffic from an IP address)

ig
5. What advantage does a Long IP Block Followed Action have over a Long Session Block Followed Action? (Hint –
Think of how an attacker will respond to being blocked)
lr
6. If a new application quickly hits the web profile size limits, why is it a bad idea to just adjust the profile size
Al
limits under Admin > System Definitions?
c.
In

Exercises
a,

Prerequisite:
rv

Important
pe

Before beginning the exercises, you must complete the steps detailed in the following class interactive sections.
1. SuperVeda Lab Preparation.
Im

2. Configuring Source Restrictions to Ignore Trusted Clients.

3. Web Profile Policy Alert Analysis.
4. Tuning the Web Profile to Eliminate False Positives.
17
20

Exercise 1:
©

Locate the Parameter type Violations in www… Alert generated by the client from IP 192.168.51.40.

Tune the alert for this client, being certain to correct all character classes identified as Unexpected Groups (This will
require tuning several underlying violations within the alert).

© 2017 Imperva, Inc. All rights reserved 8-31 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

Exercise 2:

Run the Profile Optimization for the www.superveda.local application.

Select one issue from the list of optimization issues and review the Alerts and Violations for the issue.

Suggest a recommended action for the profile optimization issue.

.
ed
Exercise 3:

rv
Review activity coming from the malicious IP Address 117.89.105.98 in China. Create a security policy that identifies

se
numerous Violations from this client. Set the policy to block and assign a Short IP Block Followed Action to the policy.

re
Policy Level: Web Application
Name: SV - Short IP Block Persistent Attacks

s
Type: Web application Custom

ht
ig
Apply the policy to both SuperVeda - Web Application and Vedaadmin - Web Application.

Exercise 4:
lr
Al
Re-run the waf-tuning-1.sh from the Gateway CLI to see how traffic is handled.
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 8-32 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

Answers to Questions
1. Why is the Untraceable SSL Session: Unknown Server Certificate Alert cause for concern if the severity is only
Informative?
A: The Untraceable SSL Session: Unknown Server Certificate Alert indicates that SecureSphere is unable to
decrypt some or all encrypted traffic directed to the protected server. Without decrypting the traffic,
SecureSphere is blind to any activity, including attacks.

.
ed
2. How are Untraceable SSL Session: Unsupported Cipher Alerts resolved?
A: Untraceable SSL Session: Unsupported Cipher Alerts are resolved by disabling the unsupported ciphers on

rv
the protected application servers. This prevents the unsupported ciphers from being used by clients.

se
3. Give a possible consequence of having an incorrect IP address in the Source Restrictions - Ignored IP group

re
settings?
A: All traffic from the Ignored IP group IP addresses is ignored. If an attacker gained access to a system on the

s
‘incorrect’ IP address the attack activity would be unmonitored and unprotected.

ht
ig
4. What advantage does a Long Session Block Followed Action have over a Long IP Block Followed Action? (Hint –
Think about possible problems with blocking all traffic from an IP address)
lr
A: If multiple users are behind a single IP address and one user triggers the IP block, all clients behind the IP
Al
address are affected. This can occur with employees connecting from the company network, all employees
appear to come from the network firewall IP address. The Session Block Followed Action blocks traffic based
on the client’s Session ID, which allows blocking the bad actor even though other clients may share the same IP
c.

address.
In

5. What advantage does a Long IP Block Followed Action have over a Long Session Block Followed Action? (Hint –
a,

Think of how an attacker will respond to being blocked)

A: If an attacker is blocked, they will often attempt to adjust their attack and the Session ID is one detail they
rv

can modify. Followed Action Blocks by Session will target individuals more accurately but may be easier to
pe

evade by attackers. Modifying the source IP address is virtually impossible. This is one reason attackers
attempt to distribute attacks via Anonymous Proxies and Botnets
Im

6. If a new application quickly hits the web profile size limits, why is it a bad idea to just adjust the profile size
limits under Admin > System Definitions?
17

A: If the application quickly hit the limit, this indicates that the application has dynamic content, or is very
large. In both cases, any increase in the size limits is likely to be quickly filled.
20
©

Answers to exercises
Exercise 1:

Locate the Parameter type Violations in www… Alert generated by the client from IP 192.168.51.40.

© 2017 Imperva, Inc. All rights reserved 8-33 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

Tune the alert for this client, being certain to correct all character classes identified as Unexpected Groups (This will
require tuning several underlying violations within the alert).
Use the Quick Filter or Basic Filter to filter alerts based on the IP address 192.168.51.40.

Quick Filter:

.
ed
Basic filter:

rv
se
From the Policies List, select the Parameter type Violations in www… Alert.

re
s
Review the underlying Violations in the Alert Details window. Make an exception for each distinct Unexpected

ht
Group.

ig
lr
Al
c.
In
a,
rv
pe
Im

For each violation with a distinct group, expand the Violation and then use the button to add the character type
to the profile.
17
20
©

Exercise 2:
Run the Profile Optimization for the www.superveda.local application.

© 2017 Imperva, Inc. All rights reserved 8-34 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

Select one issue from the list of optimization issues and review the Alerts and Violations for the issue.

Suggest a recommended action for the profile optimization issue.

Select Main > Profile > Application View and select the relevant application.

.
ed
rv
se
re
s
Select Optimization from the views pane.

ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17

Select Detect Optimization Issues.

20
©

Select an issue:

© 2017 Imperva, Inc. All rights reserved 8-35 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

Review alerts based on the URL, in this case /login.asp.

Select Main > Monitor > Alerts and use the Quick Filter for the URL.

.
Review Alerts to determine if the traffic is an attack or not. In the case of login.asp, the following violations can be

ed
found in the alerts:

rv
se
re
Note the user name is invalid. This is an OS injection pattern and it provides strong evidence the client activity is

s
malicious or at least unwanted.

ht
ig
Returning to the Profile Optimization Recommendations, the first recommendation seems more appropriate here.

lr
Al
c.
In
a,
rv
pe

Recommendation: Create custom policy to correlate repeated activity from an IP address for blocking, (see exercise
3).
Im

Exercise 3:
17

Review activity coming from the malicious IP Address 117.89.105.98 in China. Create a security policy that blocks
repeated bad activity from this client. Set the policy action to Block and assign a Short IP Block Followed Action to
20

this security policy.

©

Filter the alerts by the concerning IP address. Estimate the approximate rate of activity from this IP address. This will
be later used to help with the Number of Occurrences match criteria thresholds.

© 2017 Imperva, Inc. All rights reserved 8-36 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
Approximately 420 violations have occurred within the first 30 minutes, this averages to about 14 violations per
minute. However, the alert description begins with Distributed, meaning that the count of events may not be limited

s
to the source IP address in question. For SuperVeda, however, taking ½ of this value is a reasonable starting point

ht
for the policy being created.

ig
lr
client activity were desired, It would be possible to use reporting to get a more accurate measure of the rate of
Al
activity. take a lower value than calculated. In this example, we will take a value ½ the rate of observed violations.

Also note the types of alerts generated by this IP address:

c.

• Automated Vulnerability Scanning

In

• Null character in Parameter Values

•
a,

Illegal Byte Code Character in URL

• Etc…
rv

Create the custom policy with this threshold information.

pe

Policy Level: Web Application

Im
17

Name: SV - Short IP Block Persistent Attacks

20

Select: From Scratch

Type: Web application Custom
©

© 2017 Imperva, Inc. All rights reserved 8-37 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
Match Criteria:

• Number of Occurrences

s
• Source GeoLocation

ht
• Violations

ig
Use the speed calculation from before to identify the speed of activity of the attacker.
lr
Use the country or countries seen in the attack behavior in the Source GeoLocation Match Criteria.
Al
Locate available Violations from the common violation types seen in the alerts log.
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 8-38 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,

Your Number of Occurrences and Violations Match Criteria may differ.

rv

Apply the policy to both SuperVeda - Web Application and Vedaadmin - Web Application.
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 8-39 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

Note:
If a more accurate measure of the rate of bad behavior was necessary, reports would be an excellent tool for the
job. The following example provides some general ideas for designing the policy based on information from an ad-
hock report.

Example report:
Data Scope – Limit’s report to the last day & source of concern.

.
ed
rv
se
re
s
ht
ig
lr
Al
Tabular – Number of columns selected is limited to minimize the rows returned and ensure useful totals are
provided by the Num. of Events column.
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 8-40 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

Data Analysis View – In this particular example, the data analysis view will be helpful for getting a quick
understanding of the relative magnitude of different activities from the same source of concern.

.
ed
rv
se
re
s
ht
ig
lr
Al
c.

Report Result:
In

The Data analysis view identifies HTTP Signature Violations as the primary activity for this client. Using HTTP
a,

Signature Violations.
rv
pe
Im
17
20
©

The Tabular Results provide visibility into the number of attempts for each Alert, and because of the inclusion of
Session ID, it also indicates how many times the client used a new connection to the web server during the attack.

© 2017 Imperva, Inc. All rights reserved 8-41 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

If all, or nearly all the Alerts were tied to just a few Session IDs, then using a followed action of Short Session Block
would also be an alternative to the Short IP Block recommended in this exercise.

.
ed
rv
se
From the example report, three unique sessions were used during the HTTP Signature Violation activities and the

re
bulk of concerning behavior did have a Session ID associated with it. Under these circumstances, using a Short
Session Block would also be an option for the followed action. However, since the exercise specified a short IP
Block, that will be used for the custom policy.

s
ht
From the report, the most effective thing to correlate on would be the Signature Violations. Unfortunately the

ig
Signatures Match Criteria requires manually selecting the relevant signatures, which can be time consuming
lr
depending on how many unique signatures need to be included.
Al
With a little more investigation, either through the Alerts log or with reports, the most common type of signature
violation from 117.89.105.98 can be identified as Directory Traversal. Fortunately, locating and adding the full
c.

group of Directory Traversal Signatures to the custom security policy will be relatively easy.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 8-42 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

Creating a custom policy from the following investigation may result in Match Criteria looking similar to the
following:

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im

Exercise 4:
17

Re-run the waf-tuning-1.sh from the Gateway CLI to see how traffic is handled.
20

The following shows a mistake with tuning the traffic from 192.168.51.40. Several violations continued to occur.
©

This could be further resolved by reviewing the additional violations and excluding the remaining unexpected groups

© 2017 Imperva, Inc. All rights reserved 8-43 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

The following shows the custom policy triggering on the test traffic.

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 8-44 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 8-45 Lesson 8: WAF Tuning
SecureSphere 12.0 Web Application Security Course Manual

Active Blocking
Chapter Overview
Active Blocking can be enabled once a full configuration and at least only tuning cycle is complete. This allows
SecureSphere to intercept and block malicious requests, preventing attackers from doing damage. In this lesson we
will cover the process of enabling active blocking, verifying the error page presented to blocked clients, and the

.
configuration off error page policies to present different error pages for specific situations.

ed
Chapter Objectives

rv
se
• Configure SecureSphere to enforce the tuned configuration.
o Move SecureSphere from Simulation to Active Blocking mode.

re
o Verify the non-default error page is working.
o Identify and manage Followed Action Block events.
o Configure additional Web Error Page Groups as needed.

s
ht
Preparing for Active Blocking

ig
The following preparation will help ensure the switch to active blocking is uneventful.
lr
1. Verify the Web Error Page has been modified from the from default value.
Al
2. Determine the acceptable accuracy for blocking policy rules.
For example, a web application receiving around 10 K requests per day. Blocking Alerts with less than ten
c.

events may be acceptable to ignore. Even if every block was a false positive, the effective hit rate would be
In

0.1% or less.
3. Determine the number of error free days required to be sure Active Blocking will be safe for all normal client
a,

traffic.
For example, an organization may require accurate traffic handling for one or two weeks before enabling
rv

active blocking.
pe

4. If the number of alerts is hard to manage, focus only on Alerts that have an action of Block.
5. If false positive events are identified, tune them and restart the error free days count.
Im

6. When the error free day count is reached without errors, enable Active Blocking.

Enabling and Verifying Active Blocking

17

Active Blocking can be enabled as follows:

20

1. Select Main > Setup > Sites.

2. Expand Sites Tree and select the relevant Server Group object.
©

3. In the Server Group window, select the Definitions tab.

© 2017 Imperva, Inc. All rights reserved 9-1 Lesson 9: Active Blocking
SecureSphere 12.0 Web Application Security Course Manual

4. Set the Server Group Mode to Active.

.
ed
5. Save Changes.

rv
6. Verify SecureSphere is actively blocking by navigating to the protected web application and trigging a block.

se
a. In the SuperVeda lab, blocking can be verified by searching for cmd.exe in the SuperVeda search page.
b. The block page should look similar to the following figure:

re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17

Blocking Followed Actions

When Security policies apply a blocking followed action, all activity from the client will be blocked for a set period of
20

time. This is particularly helpful for blocking malicious activity and can help with small denial of service attacks.
©

SecureSphere is preconfigured with six blocking Action Sets for use as Followed Actions.

1. Short IP Block.
2. Short Session Block
3. Short User Block
4. Long IP Block
5. Long Session Block

© 2017 Imperva, Inc. All rights reserved 9-2 Lesson 9: Active Blocking
SecureSphere 12.0 Web Application Security Course Manual

6. Long User Block

By Default, Short Blocks have a duration of 180 Seconds (3 Minutes), while Long Blocks have a duration of 3600
second (1 Hour).

Blocking Followed Actions are a powerful tool for thwarting attacks and is especially helpful with attacker
reconnaissance activities as well as with all types of automated attacks. However, if the security policy happens to
generate a false-positive, the blocking Followed Action will extend a single blocked request into a complete ban for

.
the originating client. If the offending activity happens to be part of normal maintenance operation the impacts can

ed
be especially painful. For example, a caching server may periodically synchronize data with the protected web
application. If a Long IP Block were accidentally applying to this maintenance operation the overall web service

rv
would likely experience significant degradation.

se
With IP Block Followed Actions, false positives can be prevented with the Trusted IPs setting. This relies on a

re
previously defined IP Group Global Object.

s
ht
ig
lr
Al
c.

Figure 9-1 - Trusted IPs Setting for Short IP Block Selected Action
In

For User and Session Followed Action blocks, critical false positives can be avoided by excluding service accounts or
a,

content networks, as seen in the following two examples. These exclusions should be limited to specific policies
because general usage could leave an opening for attacks from a compromised system.
rv
pe
Im
17

Figure 9-2 - Security Policy service account exclusion with Application User Match Criteria.
20
©

© 2017 Imperva, Inc. All rights reserved 9-3 Lesson 9: Active Blocking
SecureSphere 12.0 Web Application Security Course Manual

.
ed
Figure 9-3 - Security Policy Content Development Network Exclusion with Source IP Match Criteria.

rv
Identify and Managing Followed Action Block events

se
Followed Action block events are identified in the Alert details, Actions area.

re
s
ht
ig
lr
Al
c.
In
a,
rv
pe

Current and recent Followed Action block events are also visible on Main > Monitor > Blocked Sources.
Im
17
20
©

If it is necessary to unblock a source before the block duration is reached, this can be done by selecting the blocked
client(s) from the Blocked Sources list and then selecting Action\> Release Blocked Sources.

© 2017 Imperva, Inc. All rights reserved 9-4 Lesson 9: Active Blocking
SecureSphere 12.0 Web Application Security Course Manual

Web Error Page Policies

.
ed
SecureSphere supports the conditional application of block pages based on details in the client request. For
example, an organization may provide employees additional information the block event as an opportunity to

rv
troubleshoot possible false-positive events.

se
re
Configuring an Error Page for SuperVeda Employees:

1. Select Main > Setup > Global Objects

s
2. Set Scope Selection to: Web error page groups

ht
3. Select the Web error Page folder and click to create a new Web Error Page.

ig
4. Configure the Create Error Page window as follows:
Name: SV – Employees Error Page.
Select: From Scratch.
lr
Al
c.
In
a,
rv
pe

a. Click .
5. Select the SV – Employees Error Page and customize the employee error page.
Im
17
20

a. Replace:
©

This page can't be displayed. Contact support for additional information.<br/>The incident ID is:
$(SESSION_ID).

© 2017 Imperva, Inc. All rights reserved 9-5 Lesson 9: Active Blocking
SecureSphere 12.0 Web Application Security Course Manual

b. With:
Your request was blocked. Please contact support: <br/>

.
ed
Requested Host: $(HOST)<br/>
Session ID: $(SESSION_ID)<br/>

rv
Event ID: $(EVENT_ID).

se
re
s
c. Click to Save Changes.

ht
6. Select the Web Error Page Policies folder and click to create a new Error Page Policy.

ig
a. Configure the Create Web Error Page Policy window as follows:
lr
Al
c.
In
a,

Name: SV – Employee Error Page Policy.

rv

Select: From Scratch

pe

b. Click .
c. Click to add a rule to the SV – Employee Error Page Policy and configure as follows:
Im
17
20

Name: SV - Event Origin from SuperVeda Networks

©

Priority: 1
Error Page: SV – Employee Error Page
d. Click to Save Changes.

© 2017 Imperva, Inc. All rights reserved 9-6 Lesson 9: Active Blocking
SecureSphere 12.0 Web Application Security Course Manual

e. Click the Rule link.

f. Locate the Source IP Addresses Match Criteria and click the arrow to select it and configure as follows:
g. Configure the Source IP Addresses Match Criteria as follows:

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv

Operation: At Least One

(IP Groups) Selected: SuperVeda Networks
pe

h. Click the Save button to Save Changes.

7. Click to save the changes to the SV – Employee Error Page Policy.
Im

8. From Main > Setup > Sites, expand the sites tree and select SuperVeda – Http – Service.
17
20
©

© 2017 Imperva, Inc. All rights reserved 9-7 Lesson 9: Active Blocking
SecureSphere 12.0 Web Application Security Course Manual

9. From the Service Definitions tab, expand the Error Page section to locate the Web Error Page Polices list.

.
ed
rv
se
re
10. Click to add a row to the Web Error Page Policies list and select the SV – Employee Error Page Policy.

s
ht
ig
11. Save changes.
lr
Al

Questions
c.
In

1. Can SecureSphere protect a web application without Active Blocking?

2. Should Active Blocking be postponed until you can be certain blocking rules never trigger on false positives?
a,
rv

Exercises
pe

Prerequisite:
Im

Important
Before beginning the exercises, refer to the steps detailed in the following class interactive sections.
1. Enabling and Verifying Active Blocking.
17

2. Identify and Managing Followed Action Block events.

3. Web Error Page Policies.
20

Exercise 1
©

Verify the custom Web Error Page by generating a block page and verifying the SV – Employee Error Page is
displayed.

© 2017 Imperva, Inc. All rights reserved 9-8 Lesson 9: Active Blocking
SecureSphere 12.0 Web Application Security Course Manual

Exercise 2
Modify the SV - Short IP Block Persistent Attacks policy for local testing and observe the impact of IP Block followed
actions.

Policy Adjustments:

1. Change the Followed Action from Short IP Block to Long IP Block.

2. Remove the Source Geolocation Match Criteria.

.
ed
3. Set the Number of Occurances to match at 5 or more events.
4. Add the following Violations to the Violations Match Criteria:
SQL Injection

rv
Parameter Type Violation

se
Using Internet Explorer, attempt to attack the SuperVeda web application with any of the following following attack

re
patterns.

s
ht
‘or 123=123--

ig
‘or “a”=”a”--
cmd.exe!

Verify the Long IP Block

lr
Al
Exercise 3
c.

Clear the IP Block on Veda Client from Main > Monitor > Blocked Sources.
In
a,

Exercise 4
rv

Add the SuperVeda Network range to the Trusted IPs setting for both the Short IP Block Action Set and the Long IP
Block Action Set.
pe

Repeat the attacks from exercise 1 to verify the Long IP block is no longer applied to Veda Client’s activity.
Im

Answers to Questions
17

1. Can SecureSphere protect a web application without Active Blocking?

20

a. Generally no. Without active blocking, SecureSphere only logs activity but does not block attacks.
2. Should Active Blocking be postponed until you can be certain blocking rules never trigger on false positives?
Probably not. This is a case of balancing benefits and considerations. The amount of time and effort to
©

eliminate all possible false positives generally outweighs the benefits. Also, you always know what could be a
false positive. It’ is better to decide on acceptable thresholds of accuracy early in the process and switch to
active when the thresholds are reached.

Answers to Exercises

© 2017 Imperva, Inc. All rights reserved 9-9 Lesson 9: Active Blocking
SecureSphere 12.0 Web Application Security Course Manual

Exercise 1
Verify the custom Web Error Page by generating a block page and verifying the SV – Employee Error Page is
displayed.

Using Internet Explorer, open the SuperVeda website and select the Search page.
Enter a search term that will be blocked, like cmd.exe.

.
Verify the Error message matches the custom SV – Employee Error Page Policy.

ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe

Exercise 2
Im

Modify the SV - Short IP Block Persistent Attacks policy for local testing and observe the impact of IP Block Followed
Actions.
17

1. Select Main > Policies > Security.

20

2. Quckly locate the SV - Short IP Block Persistent Attacks with the following Basic Filter:
a. Filter Criteria: Policy Origin
©

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 9-10 Lesson 9: Active Blocking
SecureSphere 12.0 Web Application Security Course Manual

b. Select: User Defined (Only)

.
ed
rv
se
re
s
c. Click Apply

ht
3. Locate and select the SV - Short IP Block Persistent Attacks Security Policy.

ig
4. Update the policy based on the reqiurements:
a. Change the Followed Action from Short IP Block to Long IP Block.
lr
b. Remove the Source Geolocation Match Criteria.
Al
c. Expand the Number Of Occurances Match Critera and set the Occurred More Than value to 5.
5. Expand the Violations Match Criteria
c.

a. Move Paramter Type Violation and SQL injection to the Selected area.
6. Add the following Violations to the Violations Match Criteria:
In

SQL Injection
Parameter Type Violation
a,

7. Save changes.
rv
pe

Using Internet Explorer, attempt to attack the SuperVeda web application with any of the following following attack
patterns.
Im

‘or 123=123--
17

‘or “a”=”a”--
cmd.exe!
20

The Long IP Block can be verified when the browser times out on the web request. This indicates that SecureSphere
©

is blocking the request at the network level.

(Continued on next page)

© 2017 Imperva, Inc. All rights reserved 9-11 Lesson 9: Active Blocking
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
Exercise 3 lr
Clear the IP Block on Veda Client from Main > Monitor > Blocked Sources.
Al
c.

1. Select Main > Monitor > Blocked Sources.

In

2. From the Blocked Source Filters, select Currently Blocked Sources.

a,
rv
pe
Im

3. On the Blocked Sources Window, locate and select the row showing the Veda Client IP address 192.168.51.31.
17
20

4. From the Action Menu, select Release Blocked Sources.

©

© 2017 Imperva, Inc. All rights reserved 9-12 Lesson 9: Active Blocking
SecureSphere 12.0 Web Application Security Course Manual

Exercise 4
Add the SuperVeda Network range to the Trusted IPs setting for both the Short IP Block Action Set and the Long IP
Block Action Set.

1. Select Main > Policies > Action Sets.

2. Locate and select the Short IP Block Action Set.
3. Expand the Block an IP (IP Block > Short IP Block) Selected Action.

.
ed
4. Under Trusted IPs, select SuperVeda Networks.

rv
se
re
s
ht
ig
5. Click to Save Changes
6. Repeat Steps 2 – 5 for the Long IP Block Action Set. lr
Al
Repeat the attacks from exercise 1 to verify the Long IP block is no longer applied to Veda Client’s activity.
c.

Perform 6 test attacks to verify Veda Client no longer receives a Long IP Block.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 9-13 Lesson 9: Active Blocking
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 9-14 Lesson 9: Active Blocking
SecureSphere 12.0 Web Application Security Course Manual

Web Scanner Integration

Chapter Overview
SecureSphere integrates with best of breed web vulnerability scanners, allowing the management and mitigation of
web vulnerabilities directly from SecureSphere web interface. SecureSphere can mitigate vulnerabilities with
automatically created mitigation policies to virtually patch vulnerable web applications. In this lesson, you will learn

.
to create a mitigation policy. Upload the vulnerability report, manage vulnerabilities through the SecureSphere web

ed
interface, and virtually patch vulnerabilities with the mitigate tool.

rv
Chapter Objectives

se
• Integrate external web scanner data with SecureSphere and manage identified vulnerabilities.
o Import 3rd party vulnerability scans

re
o Manage identified vulnerabilities
 Configure Virtual Patching where possible

s
o Compare newer scan results against previous scans to confirm vulnerabilities have been mitigated and/or

ht
identify new potential issues as web applications change over time.

ig
Web Scanner Integration lr
A critical element in any network security strategy must include a regular vulnerability scan of all potentially
Al
vulnerable areas of an enterprise. Custom web applications, and third party add-ons are often insufficiently tested,
which increases the likelihood of undiscovered vulnerabilities. Dynamic web technologies like AJAX and application
c.

communication delivered by SOAP or similar web services are also particularly vulnerable to malicious manipulation.
In

Identifying web application vulnerabilities changes as web application technologies change and Imperva web
scanning technical partners provide sophisticated analysis of web applications identifying weaknesses available to
a,

attackers.
rv

Many regulatory compliance requirements, like PCI, require periodic vulnerability scans and prioritized mitigation of
identified vulnerabilities based on severity or risk. SecureSphere supports the overall vulnerability management
pe

process with reportable tracking of vulnerability identification, analysis, and mitigation. Additionally, with mitigation
policies, SecureSphere provides the ability to virtually patch identified vulnerabilities providing immediate
Im

protection for identified vulnerabilities.

17

Vulnerability Assessment Imports

20

Importing vulnerability assessments into SecureSphere requires the following steps:

1. Perform vulnerability scan using supported technology alliance partner product
©

Review Vulnerability scan results, remove duplicates and false positives.

2. Export Vulnerability results in XML format.
a. Some exports require XML tuning.
3. Create a Web Scanner Integration Policy
4. Import XML formatted vulnerability scan results into SecureSphere
5. Manage Vulnerabilities in SecureSphere

Steps 1 and 2 are performed outside of SecureSphere.

© 2017 Imperva, Inc. All rights reserved 10-1 Lesson 10: Web Scanner Integration
SecureSphere 12.0 Web Application Security Course Manual

Creating Web Scanner Integration Policy

1. Select Main > Risk Management > Web Scanner Integration

2. From the Scanner Integration Policies list, click to create a new web scanner integration policy.

.
ed
rv
se
re
s
ht
ig
3. Configure the Create New Policy window as follows:
a. Name: SV – Vulnerability Scan lr
b. Description: <Optional>
Al
c. Module: New Web Vulnerability Management
d. Followed Action: <Optional>
c.
In
a,
rv
pe
Im
17

e. Click .
4. From the SV – Vulnerability Scan window, select the Details tab.
20
©

© 2017 Imperva, Inc. All rights reserved 10-2 Lesson 10: Web Scanner Integration
SecureSphere 12.0 Web Application Security Course Manual

5. Locate and click the Upload File button under Policy Parameters.

.
ed
rv
se
re
6. From the Upload File window, select Browse…

s
ht
ig
lr
Al
7. Select \\vedafile\Imperva-lab-files\Tools-v11.5\Training Classes\scanner\superveda_2010_appscan.xml
c.
In
a,
rv
pe
Im
17
20
©

8. Select Open.
9. Select Upload

© 2017 Imperva, Inc. All rights reserved 10-3 Lesson 10: Web Scanner Integration
SecureSphere 12.0 Web Application Security Course Manual

10. Once the file is uploaded, select OK.

.
11. Apply the Scanner Integration Policy to the SuperVeda Web Application.

ed
rv
se
re
s
ht
ig
12. Save and select Action > Run Now to being the vulnerability analysis process.
lr
Al
c.
In
a,

13. The Run Now window will appear, showing the import progress.
rv

14. If present, review any warnings found during the import process.
pe
Im
17

a. Vulnerabilities that cannot be imported may require review on the scanning system.
20

15. Click Ok.

The imported vulnerabilities are ready for analysis.
©

Vulnerability Management
Web Vulnerabilities are managed under Main > Risk Management > Risk Console and the Vulnerability Management
Scope Selection.

© 2017 Imperva, Inc. All rights reserved 10-4 Lesson 10: Web Scanner Integration
SecureSphere 12.0 Web Application Security Course Manual

.
ed
Figure 10-1 - Main > Risk Management > Risk Console, Scope - Vulnerability Management

rv
The Vulnerability Management Scope facilitates review and management of the vulnerabilities identified in the
imported scan report.

se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe

Figure 10-2 - Risk Console > Vulnerability Management Scope – Sections Identified
Im

Vulnerability Views
17

Vulnerability analysis and mitigation is handled with the Vulnerability Management Views. Graphical Vulnerability
views provide insight into the current and past vulnerabilities while the Workbench tabular view allows
20

management of the vulnerabilities.

©

Commonly Used Graphical Views

Summary View
The Summary view provides an overview of open vulnerabilities and assists in getting an overall picture of the status

© 2017 Imperva, Inc. All rights reserved 10-5 Lesson 10: Web Scanner Integration
SecureSphere 12.0 Web Application Security Course Manual

of your system. It shows a list of vulnerabilities by age, by service type and by most vulnerable services.

.
ed
rv
se
re
s
ht
ig
Figure 10-3 - Vulnerability Management Summary View

Severity Distribution
lr
Al
Displays vulnerabilities in a number of charts by severity including by service type, status and priority.
c.
In
a,
rv
pe
Im
17
20
©

Figure 10-4 - Vulnerability Management Severity Distribution

Common Vulnerability Types

The common Vulnerability Types view highlights the most frequent type of vulnerability

© 2017 Imperva, Inc. All rights reserved 10-6 Lesson 10: Web Scanner Integration
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Figure 10-5 - Vulnerability Management Common Vulnerability Types
Al
Mitigated Vulnerabilities View
Displays mitigated vulnerabilities in a number of charts including by service type, severity, and vulnerability type
c.
In
a,
rv
pe
Im
17
20
©

Figure 10-6 - Vulnerability Management Mitigated Vulnerabilities

© 2017 Imperva, Inc. All rights reserved 10-7 Lesson 10: Web Scanner Integration
SecureSphere 12.0 Web Application Security Course Manual

Vulnerability Workbench
The Vulnerability Management Scope > Workbench view allows for review and management of individual
vulnerabilities.

.
ed
rv
se
re
Figure 10-7 - Vulnerability Management Scope > Workbench View

The Vulnerabilities Workbench displays the list of the vulnerabilities identified by the scan. Selecting a vulnerability

s
from the workbench displays the information for the vulnerability in the Details pane.

ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20

Figure 10-8 - Vulnerabilities Workbench and Details Pane

©

Vulnerabilities Workbench
The Vulnerabilities Workbench presents the relevant vulnerabilities for review. Filtering of vulnerabilities is available
if needed.

The Vulnerabilities Workbench table provides the following information:

Column Name Description

© 2017 Imperva, Inc. All rights reserved 10-8 Lesson 10: Web Scanner Integration
SecureSphere 12.0 Web Application Security Course Manual

No. A sequential number assigned to vulnerabilities as they are discovered

ID number as determined by the Common Vulnerabilities and Exposures (CVE) Standard.
CVE This item is a hyperlink. To view a description of the CVE, click the link.
Type Name of the vulnerability type associated with the CVE ID.
Type of service on which the vulnerability is located.
Service Type
Status of the vulnerability. Automatically assigned as opened until otherwise modified.
Status
Possible statuses include Open, Closed, or Excluded.

.
Priority of the vulnerability. Manually assigned by clicking the priority button in the

ed
Priority vulnerability toolbar. Possible priorities include Low, Medium and High. Default:
Medium.

rv
Severity of the vulnerability. Automatically assigned by SecureSphere using CVE scoring.

se
Severity Possible severities include Low, Medium and High.
Tracking Whether the vulnerability is new or assigned, been accepted or rejected

re
Creation Date Date the vulnerability was initially detected.
Updated Date some aspect of the vulnerability was last updated, for example status or tracking.

s
Date vulnerability management is due to be completed.

ht
Due Date
Number of times this vulnerability was observed. Identical vulnerabilities in

ig
# SecureSphere are aggregated into a single vulnerability in the Vulnerabilities window. For
lr
more information regarding Vulnerability aggregation, see Vulnerability Aggregation.
Asset The server on which the vulnerability was discovered.
Al
Table 10-1 - Vulnerability List Columns
c.

Vulnerability Details
In

The Vulnerability Details pane provides information on the selected vulnerability.

a,

Overview:
rv
pe
Im
17
20
©

Figure 10-9 - Vulnerability Details - Overview

© 2017 Imperva, Inc. All rights reserved 10-9 Lesson 10: Web Scanner Integration
SecureSphere 12.0 Web Application Security Course Manual

Recommended Fix:

.
ed
Figure 10-10 - Vulnerability Details – Recommended Fix

When possible, a recommendation for fixing the vulnerability is provided.

rv
Activity Log:

se
re
s
ht
ig
lr
Figure 10-11 - Vulnerability Details - Activity Log
Al
Vulnerability status changes are tracked by SecureSphere and can be viewed in the Activity Log as well as in
c.

vulnerability reports.
In

Advanced:
a,
rv
pe
Im
17
20
©

Figure 10-12 - Vulnerability Details - Advanced

© 2017 Imperva, Inc. All rights reserved 10-10 Lesson 10: Web Scanner Integration
SecureSphere 12.0 Web Application Security Course Manual

Details on the vulnerability observation dates and assigned keywords are available on the Advanced tab.

Vulnerability Mitigation
Vulnerability mitigation is performed using the icons across the top of the Vulnerabilities Workbench.

.
ed
rv
se
Figure 10-13 - Vulnerability Management Buttons

re
Vulnerability Management Buttons

s
Icon Description

ht
Manual Status Indication.
Values: Opened, Closed, Excluded

ig
Deletes the Vulnerability
Assign a priority to the vulnerability
lr
Al
Assign the vulnerability to a SecureSphere User
Mitigate the vulnerability
c.

Options:
In

Automatic (Securesphere) – Generates Mitigation Policy or Virtual Patch

Manual: Marks vulnerability Mitigated. Used for vulnerabilities resolved directly on the
a,

affected system.
Provides management workflow tracking.
rv

Values: New, Assigned, Accepted, Rejected

pe

Assigns a due date to the vulnerability

Create a PDF report based on the selected vulnerability or vulnerabilities
Im

Adds a comment to the vulnerability management history. Comments are visible under the
vulnerability Activity Log tab as well as in reports.
17

Sends details about the vulnerability to the vulnerability Owner.

Table 10-2 - Vulnerability Management Buttons Explained

20

Mitigation Methods
©

Create Mitigation:

• Automatic (SecureSphere): Creates Mitigation Policy

• Manual Mitigation: Classifies the vulnerability as mitigated. Mitigation was performed directly on the affected
server.

© 2017 Imperva, Inc. All rights reserved 10-11 Lesson 10: Web Scanner Integration
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
Figure 10-14 - Create Mitigation Window

re
Immediate Action Options:

s
• Block

ht
• None

ig
Mitigating a vulnerability through SecureSphere creates a mitigation security policy that is able to block client traffic
lr
that could exploit the vulnerability. For the Mitigation Policy to protect the application vulnerability the Immediate
Action must be Block and the Server Group must be in Active mode. However, in some environments it may be
Al
appropriate to create the mitigation policy with an action of None to be certain the policy will not generate false
positive events. After a short period of time, the policy Immediate Action can be set to block in order to protect the
c.

application vulnerability.
In

Once mitigated, the mitigation policies are visible in the Vulnerability Overview – Mitigation table. The mitigation
a,

polices and date of the policies is displayed.

rv
pe
Im
17
20
©

Figure 10-15 - Vulnerability Details with Mitigation Highlighted

© 2017 Imperva, Inc. All rights reserved 10-12 Lesson 10: Web Scanner Integration
SecureSphere 12.0 Web Application Security Course Manual

Mitigation Policies
Mitigation Policies can be seen from the Vulnerability Overview – Mitigation table. The link opens the Mitigation
Policy window.

.
ed
rv
Figure 10-16 - Vulnerability Mitigation Close-up

Mitigation Policies can also be accessed from Main > Security > Policies. Mitigation Policies can be quickly identified

se
by filtering.

re
s
ht
ig
lr
Al
c.
In
a,
rv

Figure 10-17 - Security Policy Basic Filter for Mitigation Policies

pe

Mitigation Policy window.

Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 10-13 Lesson 10: Web Scanner Integration
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
Figure 10-18 - Example of Mitigation Policy

s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 10-14 Lesson 10: Web Scanner Integration
SecureSphere 12.0 Web Application Security Course Manual

Questions
1. Will mitigating a vulnerability in SecureSphere protect the Web Application when the Server Group Mode is set
to Simulation?
2. What benefits are provided by importing vulnerability scan results into SecureSphere?
3. Describe a scenario that would be best to use Mitigation Policies to virtually patch a vulnerable web
application:
4. Describe a scenario that would be best to fix vulnerabilities on the application server instead of creating a

.
ed
virtual patch:

Exercises

rv
se
Prerequisite:

Important

re
Before beginning the exercises, refer to the steps detailed in the following class interactive sections.

s
1. Creating Web Scanner Integration Policy.

ht
ig
Exercise 1
lr
Following the lecture instructions, import the superveda_2010_appscan.xml vulnerability scan for the SuperVeda
Al
Web Application and review the vulnerabilities.
c.

Exercise 2
In

Locate a high severity vulnerability (score of 9 or higher) and mitigate the vulnerability.

Exercise 3
a,

Verify the Mitigation policy with the Mitigation Policy link and from Main > Policies > Security.
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 10-15 Lesson 10: Web Scanner Integration
SecureSphere 12.0 Web Application Security Course Manual

Answers to Questions
1. Will mitigating a vulnerability in SecureSphere protect the Web Application when the Server Group Mode is set
to Simulation?
A: No. The Mitigation Policy will identify the event but simulation mode prevents the gateway from interfering
with traffic directed to the relevant Web servers.
2. What benefits are provided by importing vulnerability scan results into SecureSphere?
A: The vulnerability management process can be tracked and reported on in SecureSphere. If a vulnerability

.
ed
will be difficult to fix, virtually patching with a Mitigation Policy can reduce the risk of an attack while the
vulnerability is addressed on the application server.

rv
3. Describe a scenario where it would be best to create a Mitigation Policy to virtually patch a vulnerable web
application:

se
A: Many scenarios apply. One example would be an organization that recently acquired another company and
a legacy web application riddled with vulnerabilities. Using virtual patching addresses all of the vulnerabilities

re
immediately and frees developers to focus on a fresh build of the application based on current company
standards. Without virtual patching, significant developer time would be spent on an application that may be

s
targeted for decommissioning.

ht
4. Describe a scenario that would be best to fix vulnerabilities on the application server instead of creating a

ig
virtual patch:
A1: Some Vulnerabilities identify issues that are not well protected by blocking access. A basic example of this
lr
would be a vulnerability identifying missing patches or updates to the web server. Knowing that a patch should
Al
be applied is not helpful at separating attacks or normal users. Blocking all traffic to a web server that has not
been patched clearly will not help. In such cases, it is best to fix the vulnerabilities directly.
c.

A2: Another possible example is in strict change control environments. In such cases, low severity
In

vulnerabilities may be best addressed directly by the web developers due to the overhead change control adds
to all activities. However, even in change control environments, some vulnerabilities may still be appropriate to
a,

virtually patch with Mitigation Policies.

rv

Answers to Exercises
pe

Exercise 1
Im

Following the lecture instructions, import the superveda_2010_appscan.xml vulnerability scan for the SuperVeda
17

Web Application and review the vulnerabilities.

20

1. Select Main > Risk Management > Web Scanner Integration.

2. Configure the Create New Policy window as follows:
©

Name: SV – Vulnerability Scan.

Description: Vulnerability Scan of SuperVeda Web Application.
Module: New Web Vulnerability Management.

© 2017 Imperva, Inc. All rights reserved 10-16 Lesson 10: Web Scanner Integration
SecureSphere 12.0 Web Application Security Course Manual

Followed Action: SV – Send to VedaDB syslog.

3. From the Upload File window, select Browse…

.
ed
rv
se
re
4. Select \\vedafile\Imperva-lab-files\Tools-v11.5\Training Classes\scanner\superveda_2010_appscan.xml
5. Upload the file.

s
ht
ig
lr
Al
c.

6. Apply the Scanner Integration Policy to the SuperVeda Web Application.

In
a,
rv
pe
Im
17

7. Save and select Action > Run Now to being the vulnerability analysis process.
20
©

8. When the import process completes select Main > Risk Management > Risk Console.

© 2017 Imperva, Inc. All rights reserved 10-17 Lesson 10: Web Scanner Integration
SecureSphere 12.0 Web Application Security Course Manual

9. From the Scope Selection pane, select Vulnerability Management.

10. Verify the Vulnerabilities window shows new vulnerabilities.

.
ed
rv
se
re
Exercise 2

s
ht
Locate a high severity vulnerability (score of 9 or higher) and mitigate the vulnerability.

ig
1. Select Main > Risk Management > Risk Console – Vulnerability Management Scope Selection.
lr
2. Locate and select Vulnerability with 9 or greater in the Severity column.
Al
c.

(Screenshot on next Page)

In
a,
rv
pe
Im
17
20
©

3. Note the URL in the vulnerability details window, Overview tab. In this example the URL is /getstates.jsp.

© 2017 Imperva, Inc. All rights reserved 10-18 Lesson 10: Web Scanner Integration
SecureSphere 12.0 Web Application Security Course Manual

4. Click the button and the Create Mitigation window will appear.

5. Configure the Create Mitigation window as follows.

Mitigation Method: Automatic (SecureSphere)

.
ed
Immediate Action: Block
Comment: Mitigating High Severity Vulnerabilities.

rv
se
re
s
ht
ig
lr
Al
6. Click OK.
c.
In

Exercise 3
a,

Verify the Mitigation policy with the Mitigation Policy Link and from Main > Policies > Security.
rv

1. Select Main > Risk Management > Risk Console – Vulnerability Management Scope Selection.
pe

2. Locate the Vulnerability mitigated in exercise 2.

Im
17
20
©

3. In the Vulnerability Details pane, select the Vulnerability Overview tab.

© 2017 Imperva, Inc. All rights reserved 10-19 Lesson 10: Web Scanner Integration
SecureSphere 12.0 Web Application Security Course Manual

4. Locate the Mitigation table and click the Mitigation link.

5. The Mitigation Policy Window will appear.

.
ed
6. Review the created Policy settings.

rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20

7. Close the Policy Details window and select Main > Policies > Security.
©

8. Filter for Mitigation Policies with the Basic Filter as follows.

a. Expand the Policy Origin criteria.

© 2017 Imperva, Inc. All rights reserved 10-20 Lesson 10: Web Scanner Integration
SecureSphere 12.0 Web Application Security Course Manual

b. Select Mitigation Policies and de-select the other policy origins.

.
ed
c. Click .
d. From the Policies List pane, review the mitigation policies.

rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 10-21 Lesson 10: Web Scanner Integration
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 10-22 Lesson 10: Web Scanner Integration
SecureSphere 12.0 Web Application Security Course Manual

Slide 1

.
Lesson 11:

ed
rv
SecureSphere Web Application Security 12.0

se
re
s
ht
ig
© 2017 Imperva, Inc. All rights reserved.
lr
Al
Slide 2
c.
In
a,

Lesson 12: Configuring Reverse Proxy

rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved.

© 2017 Imperva, Inc. All rights reserved 11-1 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 3

Reverse Proxy (In-line) Deployment

• Used in WAF only (not DAM or FAM Gateways)

.
ed
• Replacement for legacy reverse proxy appliances
• Header / content modification features

rv
– URL rewriting Data Center

se
– Cookie signing SecureSphere
– SSL termination

re
– Response rewriting (ARP only)

Switch

s
ht
SecureSphere

ig
lr • Reverse Proxy Deployment
Al
c.

What is Reverse Proxy?

In

A reverse-proxy is a "backwards" proxy-cache server; it is a proxy server that allows Internet users to
indirectly access certain internal servers. The reverse-proxy server is used as an intermediary by Internet
users who want to access an internal website, by sending it requests indirectly. With a reverse-proxy, the
a,

web server is protected from direct outside attacks, which increases the internal network's strength. A
rv

reverse-proxy's cache function can lower the workload of the server it is assigned to, and for this reason
is sometimes called a server accelerator. Finally, the reverse-proxy can distribute the workload by
pe

redirecting requests to other, similar servers; this process is called load balancing.

SecureSphere is often deployed as a direct replacement for legacy reverse proxy appliances. In most
Im

cases, customers choose to configure SecureSphere as a bridge because it fits into the existing
architecture and reduces the operational burden associated with Web proxies. However, in some cases,
customers deploy SecureSphere as in proxy mode to meet architectural requirements or for content
17

modification. Proxy configurations offer content modification, including cookie signing and URL rewriting.
20
©

© 2017 Imperva, Inc. All rights reserved 11-2 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 4

Reverse Proxy Types and Modes

• SecureSphere supports 2 types of reverse proxy

.
ed
– Transparent Reverse Proxy (TRP): mix of inline bridge with selective kernel reverse proxy
functionality.
– Kernel Reverse Proxy (KRP): Imperva’s reverse proxy using a higher-performance kernel

rv
inspection and packet manipulation.

se
re
s
ht
ig
© 2017 Imperva, Inc. All rights reserved.
lr
Al
c.

Note: The KRP modes is non-transparent. The Hybrid mode combines the best KRP performance
In

for general web traffic, plus ARP added inspection for specific traffic as configured by the
SecureSphere administrator.
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 11-3 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 5

Transparent Reverse Proxy (TRP)

• In bridge mode

.
ed
but functions
as reverse

rv
proxy
• Can be

se
used for all
Web servers

re
or selected
server

s
groups

ht
ig
lr
Al
c.

In Transparent Reverse Proxy mode, the client is unaware of the reverse proxy, and connects directly
In

to the server. The SecureSphere gateway is not visible to the client or to the server, which see each
others’ real IP addresses.
a,

The SecureSphere gateway is in bridge mode, but additionally functions as a reverse proxy for the
rv

servers specified in the SecureSphere web interface. All other traffic is still bridged. In this way, the same
SecureSphere gateway protecting many web and database server groups can act as a reverse proxy for
pe

some or all of the web server groups it protects, and as a bridge for the other server groups.

The client begins the session by sending packets to the server’s IP address (12.1.1.10). The
Im

SecureSphere gateway intercepts connections destined for the server, inspects them and forwards them
on to the server. The server sees the connections as coming from the client’s IP address (70.1.1.50) and
replies to that address. The return connection passes through the SecureSphere gateway, which inspects
17

them and forwards them on to the client.

20

Transparent Reverse Proxy—Selected Web Servers

In the lower deployment model depicted in the slide above, the SecureSphere gateway acts as a bridge,
protecting all the servers (the two Web servers and the database server), but for one of the Web servers,
©

the SecureSphere gateway also acts as a Transparent Reverse Proxy.

© 2017 Imperva, Inc. All rights reserved 11-4 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 6

Kernel Reverse Proxy (KRP) - Non-Transparent Reverse Proxy

• Non-Transparent Reverse Proxy

.
ed
• Clients connect to IP of SecureSphere Gateway
– Advantages:

rv
• SSL off loading
• Terminate SSL Sessions

se
• Reduce Web server load
• Cookie signing and encryption

re
• Protect web servers located in multiple subnets

s
ht
ig
lr
Al
c.

In non-Transparent Reverse Proxy modes, clients connect to the IP address of the SecureSphere
In

gateway, which acts as a reverse proxy for the web servers it protects. In contrast to transparent
deployments, in non-transparent deployments the SecureSphere gateway is visible to both client and
server, while the client and server are not directly visible to each other. The SecureSphere gateway does
a,

not act as a bridge; rather, the non-Transparent Reverse Proxy listens on the specified ports and ignores
rv

all other traffic.

pe

Among the advantages of non-Transparent Reverse Proxies are:

•SSL off-loading: the ability to terminate SSL sessions, reducing the load on the server
•the ability to sign and encrypt cookies
Im

•the ability to protect web servers located in multiple subnets, not necessarily close to each other
or to the gateway
17

SecureSphere non-Transparent Reverse Proxy is called Kernel Reverse Proxy (KRP).

20
©

© 2017 Imperva, Inc. All rights reserved 11-5 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 7

Kernel Reverse Proxy (KRP)

• Kernel Reverse Proxy:

.
ed
• Improved proxy functionality
– Improved Performance

rv
– Connection termination
– SSL termination

se
• From client’s view, server is SecureSphere gateway’s inbound IP

re
• From server’s view, client is the gateway’s outbound IP

s
ht
ig
lr
Al
c.

In a Kernel Reverse Proxy deployment, the client begins the session by sending packets to the
In

SecureSphere gateway’s inbound IP address. The SecureSphere gateway inspects the packets and, based
on the rules, opens a second connection to the server, changing the packet’s source IP address to the
SecureSphere gateway’s outbound IP address and the destination IP address to the real IP address of the
a,

server. The server sends the return packets to the SecureSphere gateway, which inspects the packets
rv

and forwards them to the client, changing the source IP address to the SecureSphere gateway’s inbound
IP addresses, and the destination IP address to that of the client. From the client’s point of view, the
pe

server is the SecureSphere gateway’s inbound IP address. From the server’s point-of-view, the client is
the gateway’s outbound IP address.
Im

A “one arm” Kernel Reverse Proxy deployment is one where the inbound and outbound interfaces
are the same. This configuration simplifies routing.
17

Some of the advantages of Kernel Reverse Proxy mode are:

•improved proxy functionality (connection termination, including SSL termination)
20

•improved proxy performance

©

© 2017 Imperva, Inc. All rights reserved 11-6 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 8

Steps to Configure TRP

• If the gateway is not already in bridge mode, then in impcfg, configure the

.
ed
gateway as a bridge.
• In the SecureSphere web interface, go to Main > Setup > Sites.

rv
• In the Sites Tree pane, select a server group and then a Web service.

se
• In the HTTP Service pane, in the Transparent Reverse Proxy section of the
Reverse Proxy tab, select Enable Transparent Reverse Proxy.

re
• Next, create a decision rule which defines how to handle incoming Web traffic
by clicking the Create New icon to the right of the words Server IP.

s
• Enter the parameters (listed below).

ht
ig
© 2017 Imperva, Inc. All rights reserved.
lr
Al
c.

Parameter Definitions:
In

Server IP - The IP address of the Web server for which this SecureSphere gateway acts as a
Transparent Reverse Proxy.
a,

Ports - A comma-separated list of port numbers on which the Transparent Reverse Proxy listens.
Certificate Select the certificate which SecureSphere should present to the client from the list of
rv

the certificates uploaded for the gateway. For more information, see Adding SSL Keys on page
pe

80.
Server Side Port - The port on the Web server to which to direct Web traffic.
Im

Encrypt Server Connection - Select Encrypt to encrypt the connection

17

Notes:
• All traffic not directed to one of the specified Ports on Server IP address is bridged and
20

inspected according to the server group, service and application applied rules.
• In the event of a conflict between a Transparent Reverse Proxy rule and another service’s
port configuration, the Transparent Reverse Proxy rule takes precedence.
©

• Ignore IP Group and Limit monitoring to IP group are ignored for Reverse Proxy.

Slide 9

© 2017 Imperva, Inc. All rights reserved 11-7 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Steps to Configure KRP

• In impcfg, configure the Gateway appliance as a Kernel Reverse Proxy.

• In the SecureSphere web interface

.
• Configure the Gateway:

ed
– Configure External and Internal IP addresses on the Gateway
– Configure Alias on Gateway – (mapping of external & internal IP addresses)

rv
• Configure the Sites Tree:

se
– Do not assign protected IP address
– Create new entry in Reverse Proxy table

re
• Enter the Decision Rule parameters (listed below).
– Expand the Reverse Proxy Entry and create a Reverse Proxy Decision rule.
• Enter the Decision Rule parameters (listed below).

s
ht
ig
© 2017 Imperva, Inc. All rights reserved.

lr
Al
Aliases:
An alias represents the inbound IP address and the outbound IP address for the KRP. Since networks tend to be
c.

dynamic, IP address allocation may change from time to time. Aliases eliminate the need to configure changes in
two places (on the Gateway and on the Management Server). For multiple end points (servers), you can use port
In

mapping (one Gateway IP address with multiple ports). Alternatively, use an alias representing a Reverse Proxy IP
address per server so that whenever an alias is addressed, the communication will be forwarded to the
a,

corresponding server.
rv

Note:
pe

• For information on how to configure aliases and routing for KRP, see the "Gateways" chapter in the
SecureSphere Administration Guide.
Im

Alias Parameter Definitions:

Gateway IP Alias - From the drop-down menu, select one of the aliases that were defined for this gateway
Gateway Ports - Enter the port number on which the Kernel Reverse Proxy listens.
17

If the Kernel Reverse Proxy listens on more than one port, and they are all encrypted or all not encrypted, then you
can enter a comma-separated list of the ports. Otherwise, you must define a separate row for each port. You can
20

use the same Gateway IP Alias name for more than one port.
Server Certificate - Select the certificate which SecureSphere should present to the client from the list of the
certificates uploaded for the gateway.
©

Client Authentication Authorities - Select a Certificate Authority Group to associate with this web server. In order
you do this, you need to have imported Public Certificate Authority certificates and assigned them in a Certificate
Authority Group.
Report forwarded client IP in HTTP header - If selected, traffic forwarded to the Web server will include the client
IP address in the header specified in Header Name. If not selected, the Web server will see this Reverse Proxy as
the client.

© 2017 Imperva, Inc. All rights reserved 11-8 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Note:
• Connections that do not match the specified parameters are ignored by the Gateway.
• For more information regarding Server Certificates, see Adding SSL Keys in the Web Security User Guide.
• For more information regarding Client Authentication Authorities, see Associating Client Certificate Validation in the
Web Security User Guide.

Decision Rule Parameter Definitions:

Priority - The decision rule’s priority. You can define any number of decision rules, and they are evaluated
sequentially in order of their priorities. You must assign different priorities to each rule in the group, in order to

.
ed
avoid ambiguity in the order of their application. Also, it is recommended that you assign priorities in multiples of
ten, that is, 10, 20, 30 and so on, so that you can insert additional decision rules between the original decision rules
at a later date, if required.

rv
External Hostname - Specify the host name for which this rule will be applied, or select Any for all hosts.
Note: This field is understood by SecureSphere as a regular expression. So to specify "www.site.com" you should

se
enter "www\.site\.com". "www\.site\.(org|co)\.uk" means "www.site.co.uk" or "www.site.org.uk". Wildcards (for
example, "*" and "?") cannot be used in this field.

re
URL prefix - Specify the prefix of URLs (for example, /login/) for which traffic is to be directed to Server IP, or select
Any for all URLs.

s
Internal IP / Hostname - The IP address or the hostname of the Web server to which traffic that meets the Host

ht
and URL prefix conditions is forwarded. If you specify the hostname you must configure the DNS service on the
Gateway (see Name Resolution).

ig
Server port - The port number on the Web server to which traffic that meets the Host and URL prefix conditions is
forwarded. lr
Encrypt - Select Encrypt to encrypt the connection between the SecureSphere gateway and the backend (the real)
Web server.
Al
Client Authentication Rules - When working with client certificate authentication, select the Client Authentication
Rules that determine the course of action taken when certificate validation succeeds or fails.
c.

Notes:
In

• For more information regarding Regular Expressions, see Regular Expressions in the Web Security User Guide.
• For more information regarding Client Authentication Rules, see Configuring Client Authentication Rules in the Web
a,

Security User Guide.

• When using the External Hostname and URL prefix together, the operation between them is AND. Typically, the operation
rv

between match criteria is OR.

pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 11-9 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 10

Configuring KRP –– Adding IP Addresses to the Gateway

• Main > Setup > Gateways - Select KRP Gateway

.
ed
• On Gateway Details Click IP Addresses

rv
se
re
s
ht
ig
© 2017 Imperva, Inc. All rights reserved.
lr
Al
c.

Slide 11
In
a,

Configuring KRP –– Add external and Internal IP Adresses

rv
pe

• External – Client Facing IP • Internal – Server Facing IP

Im
17
20
©

11

© 2017 Imperva, Inc. All rights reserved 11-10 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 12

Configuring KRP – Create Alias on Gateway

• The Alias defines the relation between the External and Internal IP addresses.

.
ed
rv
se
re
s
ht
ig
12
lr
Al
c.

Slide 13
In
a,

Configuring KRP – Sever Group

rv
pe

• Kernel Reverse Proxy does not use protected IP Addresses

• Configuration is on HTTP Service Object
Im
17
20
©

13 © 2017 Imperva, Inc. All rights reserved.

© 2017 Imperva, Inc. All rights reserved 11-11 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 14

Configuring KRP - HTTP Service Object Settings

.
ed
rv
se
re
s
ht
ig
© 2017 Imperva, Inc. All rights reserved.
lr
Al
c.

Slide 15
In
a,

Configuring KRP - Verification

rv
pe

• After Configuring KRP on the Service Object, the settings are summarized on
the Server Group > Definitions tab.
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved.

© 2017 Imperva, Inc. All rights reserved 11-12 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 16

URL Rewrite and URL Redirection

.
ed
rv
se
re
s
ht
ig
© 2017 Imperva, Inc. All rights reserved.
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 11-13 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 17

URL Rewrite

• Rewrite host name and/or path in Web URLs and headers

.
• Redirect Web traffic to another server

ed
• Uses

rv
• Web site name change
• Hide web servers and site structure

se
re
s
ht
ig
lr
Al
c.

URL Rewrite
SecureSphere’s URL Rewrite feature can be used in two situations:
In

• To rewrite host name and/or path in web traffic URLs and headers. In this case the web client is
unaware that the traffic is being diverted.
a,

• To redirect web traffic to another server. In this case, response code 302 is sent to the web client,
which then accesses the new URL in a new request.
rv

With URL rewrite, the web client remains unaware of the redirection. This feature can be used for several
pe

purposes, for example:

• When a web site’s name has been changed, but applications accessing the site have not been updated
Im

to use the new name.

• To hide web servers and web site structure from clients.
17
20
©

© 2017 Imperva, Inc. All rights reserved 11-14 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 18

URL Rewrite Groups

• Defined in Main > Setup > Global Objects

.
ed
– Create URL Rewrite Group, Add URL Rewrite Rules

rv
se
• Applied in Main > Setup > Sites

re
– Sites Tree > HTTP Service object > Reverse Proxy tab

s
ht
ig
© 2017 Imperva, Inc. All rights reserved.
lr
Al
c.

The SecureSphere administrator defines URL Rewrite rules that define how to rewrite or redirect
In

responses and/or requests. URL Rewrite rules are organized in groups, and these groups are applied to
web services.
a,

Rules in a group are evaluated sequentially in order of their priorities. All matching rules are applied, but
rv

there is significance to priorities because each rule operates on the output of the previously applied rule.
pe

For example, if a group consists of the following rules:

• Rule 20: rewrite www.X.com/ to www.Y.com/
• Rule 30: rewrite www.Y.com/forms to www.Z.com/
Im

Rule 20 does not hide Rule 30. Rule 30 is applied to Rule 20’s output, if it matches. So www.X.com/forms
would become www.Z.com.
17

If more than one URL Rewrite Group is applied to a web service, then the highest priority rules among all
20

the groups are applied first, followed by the second highest priority rules among the groups, and so on.
©

© 2017 Imperva, Inc. All rights reserved 11-15 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 19

Configuring URL Rewrite Rules

• Go to Main > Setup > Global Objects

.
ed
– URL Rewrite Group

rv
se
re
s
ht
ig
lr
Al
c.

Rewrite rules come in pairs, one rule for incoming traffic and an inverse rule for outgoing traffic so that
In

the web client is unaware of the URL rewrite.

In the Create URL Rewrite Rule window, enter the following data:
a,

Name: Enter a name for the rule.

rv

Apply To: Select Request or Response.

Priority: Enter a priority.
pe

Rules in a group are evaluated sequentially in order of their priorities. All matching rules are
applied, but there is significance to priorities because each rule operates on the output of the
previously applied rule.
Im

Tip: It is highly recommended to assign different priorities to each rule in the group, in order to
avoid ambiguity in the order of their application. Also, it is recommended that you assign
priorities in multiples of ten, that is, 10, 20, 30 and so on, so that you can insert additional rules
17

in between them at a later date, if required.

Find what: Enter Host and Path strings to search for.
20

Note: In the Path, you can specify a regular expression. So to match “default”, write “default$”,
otherwise “default/xxx” will also be matched.
Replace with: Enter Host and Path strings with which to replace the Host and Path under Find what.
©

URL Redirection: Select Redirect Client Requests, if needed.

With URL Rewrite rules, as opposed to URL Redirection rules, you must define rules in pairs: one
rule for Request traffic and an inverse rule for Response traffic.
If you selected Response under Apply To, then Redirect Client Requests.
Select HTTP, HTTPS or Original.

© 2017 Imperva, Inc. All rights reserved 11-16 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Note: Whether the rule is a Replace or Redirect rule, always specify the protocol below Redirection.
You can leave the connection as the original protocol or force HTTP or HTTPS as needed. For example,
financial institutions may want to ensure the connections are forced to HTTPS protocol.

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 11-17 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 20

URL Redirection

• Intercepts Web client requests and returns a 302 response, redirecting the

.
ed
Web client to another URL
• Uses

rv
• Web site reorganized

se
• Force clients to use https

re
s
ht
ig
lr
Al
c.

With URL redirection, when the SecureSphere gateway is configured in Reverse Proxy mode, intercepts
In

Web client requests and returns a 302 response, redirecting the Web client to another URL.

URL redirection can be used for several purposes, for example:

a,

• When a Web site has been reorganized, but Web users may still be accessing the now obsolete URLs
rv

• When Web site administrators want to force Web clients to use HTTPS, even if they access a HTTP URL
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 11-18 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 21

URL Rewrite and Redirection Configuration

• URL Rewrite and URL Redirection are configured

.
ed
in the same way
• Only single parameter being different

rv
se
re
s
ht
ig
lr
Al
c.

Both URL Rewrite and URL Redirection are configured in the same way, with only a single parameter in
In

the Create URL Rewrite Rule window being different. Because URL Rewrite and URL Redirection intercept
and modify Web traffic, they are available only when the SecureSphere gateway is configured in the
Reverse Proxy modes.
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 11-19 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 22

Web User Tracking: Client Certificates

.
ed
rv
se
re
s
ht
ig
© 2017 Imperva, Inc. All rights reserved.
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 11-20 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 23

What is SSL Client Authentication?

.
ed
rv
Certificate

se
re
s
SSL Tighter
Login

ht
Certificate Security

ig
lr
Al
c.
In

Two factor authentication (2FA) is a security process in which the user provides two means of
identification, one of which is typically a physical token, such as a card, and the other of which is typically
a,

something memorized, such as a security code. In this context, the two factors involved are sometimes
spoken of as something you have and something you know. According to proponents, two-factor
rv

authentication could drastically reduce the incidence of online identity theft, phishing expeditions, and
other online fraud, because the victim's password would no longer be enough to give a thief access to
pe

their information.
Im

Client authentication lets you authenticate users who are accessing the server by exchanging a client
certificate and entering a password. The client certificate is vouched for by either an external Certification
Authority (CA), such as VeriSign, or by you as an internal CA, so you can be assured that the person
17

represented by the certificate is the person you expect.

20
©

© 2017 Imperva, Inc. All rights reserved 11-21 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 24

Validating SSL Client Certificates

• Works with Kernel Reverse Proxy mode.

.
ed
• Configure global objects.
– Go to Main > Setup > Global Objects.

rv
– Certificate Authorities.
– CA Groups (optional).

se
– CRLs (optional).
– Client Certificate Parameter Set.

re
• Complete configuration on HTTP service object.
– Go to Main > Setup > Sites Tree > Server Group > HTTP Service

s
ht
ig
© 2017 Imperva, Inc. All rights reserved.
lr
Al
c.

SecureSphere enables you to validate client certificates in Kernel Reverse Proxy mode, which
In

authenticates users before enabling them to access web applications.

To configure client certificate validation, a number of objects need to be prepared. Once all the objects
a,

have been created, you complete configuration on the SecureSphere web service that is hosting the
rv

traffic you want to validate. Global objects that may need to be configured include:
Certificate Authorities
pe

CA Group
Certificate Revocation Lists (CRLs)
Client Certificate Parameter Set
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 11-22 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 25

SSL Client Authentication Flow (RP Only)

ClientHello

.
ServerHello

ed
Certificate

CertificateRequest

rv
ServerhelloDone

se
Certificate

ClientKeyExchange
User

re
CertificateVerify SecureSphere

ChangeCipherSpec

s
Finished (encrypted)

ht
ChangeCipherSpec

Finished (encrypted)

ig
© 2017 Imperva, Inc. All rights reserved.
lr
Al
c.

Initial Client Message to Server

In

• Client Hello. The client initiates a session by sending a Client Hello message to the server. The
Client Hello message contains: Version Number, Randomly Generated Data, Session Identification (if
any), Cipher Suite, Compression Algorithm
a,
rv

Server Response to Client

• Server Hello. The server responds with a Server Hello message. The Server Hello message
pe

includes: Version Number, Randomly Generated Data, Session Identification (if any), Cipher Suite,
Compression Algorithm
• Server Certificate. The server sends its certificate to the client. The server certificate contains the
Im

server’s public key. The client will use this key to authenticate the server and to encrypt the
premaster secret. The client also checks the name of the server in the certificate to verify that it
matches the name the client used to connect. If the user typed www.contoso.com as the URL in the
17

browser, the certificate should contain a subject name of www.contoso.com or *.contoso.com.

Internet Explorer will warn the user if these names do not match.
20

• Server Key Exchange. This is an optional step in which the server creates and sends a temporary
key to the client. This key can be used by the client to encrypt the Client Key Exchange message
later in the process. The step is only required when the public key algorithm does not provide the
©

key material necessary to encrypt the Client Key Exchange message, such as when the server’s
certificate does not contain a public key.
• Client Certificate Request. This is an optional step in which the server requests authentication of
the client. This step might be used for Web sites (such as a banking Web site) where the server must
confirm the identity of the client before providing sensitive information.
• Server Hello Done. This message indicates that the server is finished and awaiting a response from
the client

© 2017 Imperva, Inc. All rights reserved 11-23 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Client Response to Server

• Client Certificate. If the server sent a Client Certificate Request, the client sends its certificate to the
server for client authentication. The client’s certificate contains the client’s public key.
• Client Key Exchange. The client sends a Client Key Exchange message after computing the
premaster secret using both random values. The premaster secret is encrypted by the public key from
the server’s certificate before being transmitted to the server. Both parties will compute the master
secret locally and derive the session key from it. If the server can decrypt this data and complete the
protocol, the client is assured that the server has the correct private key. This step is crucial to prove

.
the authenticity of the server. Only the server with the private key that matches the public key in the

ed
certificate can decrypt this data and continue the protocol negotiation. This message will also include
the protocol version. The server will verify that it matches the original value sent in the client hello

rv
message. This measure guards against rollback attacks. Rollback attacks work by manipulating the
message in order to cause the server and the client to use a less secure, earlier version of the

se
protocol.
• Certificate Verify. This message is sent only if the client previously sent a Client Certificate message.

re
The client is authenticated by using its private key to sign a hash of all the messages up to this point.
The recipient verifies the signature using the public key of the signer, thus ensuring it was signed with

s
the client’s private key.
• Change Cipher Spec. This message notifies the server that all messages that follow the Client

ht
Finished message will be encrypted using the keys and algorithms just negotiated.

ig
• Client Finished. This message is a hash of the entire conversation to provide further authentication
of the client. This message is the first message that the record layer encrypts and hashes.

Server Final Response to Client

lr
Al
• Change Cipher Spec Message. This message notifies the client that the server will begin encrypting
messages with the keys just negotiated.
c.

• Server Finished Message. This message is a hash of the entire exchange to this point using the
session key and the MAC secret. If the client is able to successfully decrypt this message and validate
In

the contained hashes, it is assured that the SSL/TLS handshake was successful, and the keys
computed on the client machine match those computed on the server.
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 11-24 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 26

SSL Client Authentication Flow

.
ed
X-Client-Cert: FAIL

rv
Failure: Block

se
Failure: Block & Send Error Page

X-Client-Cert: PASS
User SecureSphere

re
Data Center

s
• Failure = Missing, Invalid or Expired certificate

ht
ig
© 2017 Imperva, Inc. All rights reserved.
lr
Al
c.
In

The Alert Sub-Protocol

a,

The alert sub-protocol is a component of the Handshake protocol that includes event-driven alert
messages that can be sent from either party. Following an alert message the session is either ended or
rv

the recipient is given the choice of whether or not to end the session. The alerts are defined in the TLS
specification in RFC 2246, located at https://www.ietf.org/rfc/rfc2246.txt.
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 11-25 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 27

Configure Client Certificate User Tracking

• Main > Setup > Sites - HTTP Service Object

.
ed
• Enable Client Certificate Validation in User Tracking

rv
se
re
s
ht
ig
© 2017 Imperva, Inc. All rights reserved.
lr
Al
c.
In

Enable Client Certificate Validation in User Tracking by selecting the Client Certificate check box. This
a,

enables the import of certificates from a certificate authority (such as Verisign), which are then used for
validation.
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 11-26 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 28

Configuring Certificate Authorities

• Download certificates from relevant certificate

.
ed
authority
• Create Certificate Authorities Global object

rv
• Add certificates

se
re
• Upload PEM file

s
ht
ig
© 2017 Imperva, Inc. All rights reserved.
lr
Al
c.
In

Configuring Certificate Authorities

a,

Certificate Authorities enable users to download certificates containing a public key from valid certificate
authorities and then use this public key to validate traffic. The first step in this process is downloading
rv

the required public keys into the Certificate Authorities global object.
pe

Download certificates from relevant certificate authority

Im

From the Setup > Global Objects window, select Certificate Authorities > Certificate Authorities.

Click the plus icon to add a new CA certificate. The upload new certificate window is displayed. Click
17

browse and navigate to the location where you downloaded the relevant certificates. Click Upload.

Note: SecureSphere supports the .pem (privacy enhanced mail) certificate format. The PEM format is the
20

most common format that Certificate Authorities issue certificates in. PEM certificates usually have
extensions such as .pem, .crt, .cer, and .key.
©

© 2017 Imperva, Inc. All rights reserved 11-27 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 29

Configuring Certificate Authorities

.
ed
rv
se
re
s
ht
ig
© 2017 Imperva, Inc. All rights reserved.
lr
Al
c.

If you want to overwrite an existing certificate, select the Overwrite Existing Certificate From Same Issuer
In

checkbox. Click Upload. The certificate is uploaded.

a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 11-28 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 30

Certificate Revocation Lists (CRLs)

– Lists of certificates that have been revoked which are used to check the validity of a

.
certificate

ed
– Go to Main > Setup > Global Objects.
– Scope Selection > Certificate Authorities.

rv
– Globals Tree > Certificate Revocation Lists.

se
re
s
ht
ig
© 2017 Imperva, Inc. All rights reserved.
lr
Al
c.

Configuring Certificate Revocation List (CRL)

In

Certificate Revocation Lists (CRL) are lists of certificates that have been revoked which are used to check
the validity of a certificate. SecureSphere allows you to download CRLs from Certificate Authorities in the
form of .crl files, which are then used by SecureSphere during the process of validation.
a,
rv

To import CRLs into the CRL global object:

• Download one or more Certificate Revocation Lists (CRLs) from the relevant certificate authority.
pe

• From the Setup > Global Objects window select Certificate Authorities > Certificate Revocation Lists.
Existing Certificate Revocation Lists are displayed.
• In the heading of the Details pane, click New. The Upload New CRL window opens.
Im

• Type a Name for the CRL list.

• Select a Certificate Authority with which to associate the CRL list.
17
20
©

© 2017 Imperva, Inc. All rights reserved 11-29 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 31

Importing Clients Revocation Lists (CRLs)

• Creating CRL Global Object enables import of CRLs from CA.

.
ed
• Go to Main > Setup > Global Objects.

rv
se
re
s
ht
ig
© 2017 Imperva, Inc. All rights reserved.
lr
Al
c.

Note: CRLs contain a list of revoked certificates associated with a certificate authority. If no certificate
In

authority is selected, users with bad certificates will not be filtered.

a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 11-30 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 32

Certificate Authorities Group

• Go to Main > Setup > Global Objects.

.
ed
• Create CA Group if your application accepts traffic from more than one CA.

rv
se
re
• Groups security certificates together which then can be selected via Reverse
Proxy settings.

s
ht
ig
© 2017 Imperva, Inc. All rights reserved.
lr
Al
c.

CA Group
In

If your application accepts traffic from more than one CA, you can add these certificates to a certificate
group. This object groups a number of security certificates together which then can be selected in a Web
service’s Reverse Proxy settings.
a,
rv

If you configure more than one Certificate Authority, you can group them for use in a Certificate
Authority Group. Certificate Authorities Groups enable you to group related certificates to be used in a
pe

specific environment. Once group has been configured, you associate it with a Web Service under its
Reverse Proxy settings.
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 11-31 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 33

Creating CA Groups

• Go to Main > Setup > Global Objects.

.
ed
rv
se
re
s
ht
ig
© 2017 Imperva, Inc. All rights reserved.
lr
Al
c.

To configure a new Certificate Authority Group:

In

• From the Setup > Global Objects window select Certificate Authorities > Certificate Authority Groups.
Existing Certificate Authority Groups are displayed.
• From the upper right-hand corner of the Globals pane, click New. The Create Certificate Authority
a,

Group window opens.

rv

• Type a Name for the Certificate Authority Group.

• Click Create. The group is created.
pe

• Move the desired certificates to the Group Members pane by clicking the right arrow.

Note: Certificate Authority Public Certificates are assigned to the default group if no groups are manually
Im

configured.
17
20
©

© 2017 Imperva, Inc. All rights reserved 11-32 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 34

Configuring Authentication Rules

• Determines how SecureSphere will handle traffic when certificate validation

.
ed
has succeeded and failed.
• When successful, determines information passed on to web server.

rv
• Go to Main > Setup > Global Objects.

se
re
s
ht
ig
© 2017 Imperva, Inc. All rights reserved.
lr
Al
c.

Configuring Client Authentication Rules

In

A Client Authentication Rule determines various factors regarding how SecureSphere will handle traffic
when a certificate validation has succeeded, and failed. And when successful, determines what
information is passed on to the web server.
a,
rv

To configure Client Authentication Rules:

• Go to Go to Main > Setup > Global Objects window select Certificate Authorities > Certificate
pe

Authentication Rules. Existing Certificate Authentication Rules are displayed.

• From the upper right-hand corner of the Globals pane, click New. The Create Client Authentication
Rule window opens.
Im

• Type a Name for the client authentication rule, then click Create. The new rule is created and its
options are displayed. Select the action to be taken On Failure. Options include:
Block: Blocks the connection
17

Block and Send Error Page: Blocks the connection and displays the selected error page to users.
Select an error page to use by clicking the dropdown list, or create a new one by clicking the edit
20

button
Don’t Block and send in header: Does not block the connection and sends the configured information
in the header. Select an item to be sent in the header On Success. Options include:
©

Nothing: Doesn’t send anything to the web server if authentication was successful.
Subject CN: Sends the Common Name (CN) in the subject field to the web server.
Subject Email: Sends the e-mail of the in the subject field to the web server.
Entire Certificate: Sends the entire certificate to the web server.
• If required, modify HTTP Header Name: by default, the HTTP Header name is: X-Client-Cert.
• Click Save. You can now use the Client Authentication Rule to configure client certificate validation.

© 2017 Imperva, Inc. All rights reserved 11-33 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 35

Associating Rules to Certificates

• Reverse Proxy tab.

.
ed
• Select CA Group.
• Select Client Authentication Rules.

rv
se
re
s
ht
ig
© 2017 Imperva, Inc. All rights reserved.
lr
Al
CONFIDENTI
c.

Associating Client Certificate Validation

In

Once all the required global objects containing information regarding Certificate Authorities, Client
Authentication Rules, and if relevant Certificate Revocation lists have been configured, you need to
associate them with the desired web service in order to activate client certificate validation.
a,

Notes:
rv

Authenticating a client certificate requires specifying both a CA and a Server Certificate.

When configuring a Reverse Proxy Rule to authenticate a client certificate, initiating an encrypted
pe

connection for the rule always requires the client to present a certificate.

To configure Client Certificate Validation:

Im

• Configure the Certificate Authority, Certificate Authority Group, Certificate Revocation List (if desired),
and Client Authentication Rules global objects
• Configure the desired web service for Reverse Proxy support.
17

• In the Go to Main workspace, select Setup > Sites. The Sites window appears.
• In the Sites window, select Server Group, and Web Service you want to configure to support client
20

certificate validation. That web service’s details are displayed.

• Click the Reverse Proxy tab. Reverse Proxy options are displayed.
• If you are adding Client Authentication to an existing Reverse Proxy configuration, under Client
©

Authenticating Authorities, select the Client Authority Group you previously configured.
• If you are assigning priority, under Client Authentication Rules, select the Rules you previously
created.
• Click Save.

© 2017 Imperva, Inc. All rights reserved 11-34 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 36

IP Ignore on XFF

.
ed
rv
se
re
s
ht
ig
© 2017 Imperva, Inc. All rights reserved.
lr
Al
c.

Slide 37
In
a,

What is XFF?
rv
pe

• Stands for X-Forwarded-For

• Field in IP packet header that lists packet’s source IP address, before it was
Im

changed by load balancer or proxy

17
20
©

© 2017 Imperva, Inc. All rights reserved 11-35 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 38

Handling XFF

• If IP is a proxy IP, delay packet until source IP is identified

.
ed
• Re-evaluate source IP rules after parsing XFF header
• Delaying packets is done only in required cases

rv
• Address identified as the source IP is first client that appears after one or

se
more proxies

re
s
ht
ig
lr
Al
c.

Slide 39
In
a,

Identifying Original IP and Proxy IPs

rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved.

© 2017 Imperva, Inc. All rights reserved 11-36 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Slide 40

Questions?

.
ed
rv
se
re
s
ht
ig
© 2017 Imperva, Inc. All rights reserved.
lr
Al
c.

Slide 41
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved 11-37 Lesson 11: Reverse Proxy
SecureSphere 12.0 Web Application Security Course Manual

Lab Environment and SecureSphere Web UI

Chapter Overview
Imperva’s training classes utilize either a cloud-based training environment, or a local VMWare Workstation
environment. This document provides information to familiarize students with the training environments and the
basics of using SecureSphere’s Web User Interface (Web UI).

.
ed
Objectives

rv
• Become familiar with the presentation of the training materials.

se
• Learn to use the Imperva training portal to find supplemental course materials.
• Become familiar with the lab environment, topology, and user accounts.

re
• Become familiar with the SecureSphere Web UI’s major components and navigating the Web UI.
• Learn how to use SecureSphere’s Basic, Advanced, and Quick Filters in the Web UI.

s
• Become familiar with setting Criteria in Policies.

ht
Presentation of Training Materials

ig
lr
The order in which information is presented throughout the Courseware is modeled after an enterprise workflow
that incorporates a separation of duties between System Administrators and Security Administrators.
Al
With this workflow, System Administrators are responsible for tasks such as configuring and maintaining the
c.

SecureSphere Operating System, ensuring proper network connectivity and monitoring, and building objects that
In

require accounts to external systems, such as Windows Domain objects, to which a Security Administrator may not
have access.
a,

Once SecureSphere is initially built and configured, the System Administrator continues to monitor and ensure the
rv

availability of the SecureSphere appliances while Security Administrators become the primary users, creating
policies, monitoring and securing traffic to protected applications, and generating reports for business owners.
pe

The SecureSphere Administration Course corresponds to the System Administrator role, and the Web Application
Im

Security and Database Security and Compliance Courses primarily correspond to the Security Administrator role;
however, Security Administrators also need to know many of the topics covered in the Administration Course.
17

Supplemental Videos
20

Occasionally, the training materials refer to Supplemental Videos that further illustrate a concept or process
described in the Course Manual. Where supplemental videos are available, they are marked with the movie reel
©

image in the left margin, and a caption in the format Video ch#--video # - Title of Video, as shown here:
Video 0-1 – Example of Supplemental Video Nomenclature

Students can find these videos in the LMS system and watch them at their convenience.
1. Enter http://www.imperva.com/login into your Web browser and select the Log In link.

© 2017 Imperva, Inc. All rights reserved A-1 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
2. Sign in to either the Customer or Partner Portal.

se
a. If you are an Imperva customer, enter your username and password into fields below the
Customer Support Portal portion of the page. Click the Log In button.

re
b. If you are an Imperva partner, enter your username and password into fields below the Partner
Portal portion of the page. Click the Log In button.

s
3. If you experience trouble signing into the site, please contact [email protected].

ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20

4. Select the Training tab, and click the Calendar button

©

© 2017 Imperva, Inc. All rights reserved A-2 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

5. Find the class in which you are enrolled. Classes in which you have enrolled will appear in green. If you have
not yet registered or enrolled for class, please contact [email protected] if you need assistance or
instructions. You must be enrolled before accessing the documents.

6. Click the course link.

.
ed
rv
se
re
s
ht
ig
7.
lr
On the details tab of the course, you will see links to lessons and lab materials associated with the course.
Al
Click the link to open the resource.
c.
In
a,
rv
pe
Im
17
20
©

8. Some resources may prompt for a password. Enter the password, SecureSphere120.

© 2017 Imperva, Inc. All rights reserved A-3 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

Review Questions and Lab Exercises

To help reinforce students’ understanding and retention, the end of each lesson presents students with review
questions and lab exercises.
Answers for some of the review questions come directly from the text; answers for other questions may require the
student to analyze the material presented and/or consider general security principles that may not be expressly
stated in the lesson. Answers to the questions are provided, and students are encouraged to consider how answers
may vary according to their organization’s policies and procedures.

.
ed
It is very important for students to complete the lab exercises at the end of a lesson. Hands-on implementation

rv
greatly enhances understanding and retention of the materials, and brings out nuances of the material and Web UI
that may not be expressly stated in the lecture material. Additionally, as the class progresses, many exercises

se
depend on successful completion of prior exercises.

re
The Cloud-Based Lab Environment

s
At the beginning of class, students receive an email that includes links to a speed test, connectivity checker, access

ht
troubleshooting guide, and their unique lab environment. Click the link to launch the lab environment. If you
experience problems accessing or using the environment, verify your network speed, and use the connectivity

ig
checker and troubleshooting guide as needed. If you are unable to successfully connect to your lab environment, let
the instructor know. lr
Al
After clicking the link to your lab environment, the browser displays the environment:
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved A-4 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe

Figure 0-1 - The cloud-based lab envrionment controls

Im

The page shows several sets of controls to pause or stop the VMs. During the class day, if your environment idles for
more than an hour, it will suspend. Use the Whole Environment controls at the top right of the page to start your
environment. You can also use these controls to suspend your environment, when you are done with it for the day.
17

If needed, you can use the checkboxes to select or un-select individual VMs, and use the Controls for Selected VMs
20

to suspend or reboot the selected VMs, or use the Controls for Individual VMs to work with a single VM.
©

Click the VM’s monitor icon to access it. After selecting a VM, the browser displays the VM, and a toolbar at the top
of the VM:

Figure 0-2 - A Cloud-Based Lab’s Virtual Machine toolbar

From left to right, the controls include the following options:

© 2017 Imperva, Inc. All rights reserved A-5 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

• Select which VM to control.

• Suspend / resume / shutdown the VM.
• Send key combinations to the VM or pull up a virtual keyboard and use the mouse to send key presses.
• Paste Username / Passwords to the VM.
• Fit the VM to the browser window or change the VM’s display resolution.
• Verify network quality and adjust display options to optimize bandwidth.
• Get help with accessing VMs.

.
In your environment, select the Help icon (?) on the right side of the toolbar, to get detailed assistance with the

ed
controls. At the time of writing, the help button open this link: http://help.skytap.com/SmartClient_Help_Page.html,
which includes a link to get further details about the toolbar: http://help.skytap.com/VMClient.html#SRDC.

rv
se
Local Workstation Lab Environment

re
When participating in a training class that offers local VMWare Workstation VMs, the background image of the host
PC displays the network topology. When first using the host PC, start VMWare Workstation and each of the VMs.

s
To start VMWare Workstation, double-click the VMWare Workstation icon on the desktop.

ht
Once VMWare Workstation is started, start each VM listed in the Library. To start a VM:

ig
1. Click the VM in the Library. The VM’s tab opens.
2.
lr
In the VM’s tab, click Power on this virtual machine.
Al
c.
In
a,
rv

When powering on the Virtual Machines for the first time, VMWare Workstation asks whether the VMs were moved
or copied. For each VM, select the I moved it button:
pe
Im
17
20
©

Warning
When starting the virtual machines in VMWare Workstation, it is CRITICAL that you select I moved it. Selecting I
copied it will break the lab network.

© 2017 Imperva, Inc. All rights reserved A-6 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

When using VMWare Workstation, click the tab of the VM you wish to access, to select the VM.

To use one of the VMs, click in the display area of the VM. Clicking the display area of a VM captures the keyboard
and mouse input to that VM. Press CTRL + ALT to release the keyboard and mouse back to the host workstation.

.
ed
Start Your Lab Environment Now

rv
• If your class uses the cloud-based environment, click the link provided to start the lab environment.

se
• If your class uses the VMWare Workstation environment, launch VMWare Workstation and start all of the
lab machines now.

re
• If you need assistance, please ask the instructor.

s
Introduction to SuperVeda

ht
SuperVeda is a fictitious company and network environment that is used throughout the training materials. The

ig
word “Veda” is actually an acronym for: Vulnerable E-commerce Database Application. The next few sections
lr
introduce you to the network’s topology, application servers, and account credentials.
Al
SuperVeda Lab Topology
c.

The lab topology consists of three primary networks:

In

• Management Contains SecureSphere’s management interfaces and a workstation to access them.

• DMZ Contains the web server.
a,

• Secure Contains the database and file servers.

rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved A-7 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In

Figure 0-3 - The SuperVeda Network Topology

a,

Unless specified otherwise in the text, students connect to SecureSphere and the SuperVeda web application from
rv

the Veda Client workstation.

pe

The Veda DB server contains the back end database for the SuperVeda web application, and also runs an FTP server
and syslog server for use in the labs.
Im

The Veda File server is SuperVeda’s AD domain controller, DNS server (superveda.local domain), and file server.
17

Additionally, the firewall (shown at the top of the diagram) connects to the Internet, routes between the internal
networks, runs a secondary DNS server, and runs a mail server for the lab environment. The firewall is not student
20

accessible.

The SecureSphere Gateway, vedagw, contains 2 bridges:

©

• Br0 bridges 2 segments of the DMZ network, 192.168.53.0/24.

o One segment contains only the Firewall’s NIC for this DMZ network.
o The other segment contains only the web server.
• Br1 bridges 2 segments of the Secure network, 192.168.54.0/24.
o One segment contains only the Firewall’s NIC for this Secure network.
o The other segment contains the database server and the domain controller/file server.

© 2017 Imperva, Inc. All rights reserved A-8 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

The SecureSphere MX, SecureSphere Gateway, and Veda Client all connect to a non-bridged management network,
along with an interface from the Firewall.

The SuperVeda Application

SuperVeda corp. runs a Web-based E-commerce application that consists of a front-end web server, and an MsSQL
back end database. The application is not written with the best security practices, allowing students to generate
some successful attacks in the lab and then verify the effectiveness of their work with SecureSphere, to protect

.
against attacks.

ed
To help understand the network topology, here is the network path when accessing the SuperVeda web site from

rv
the Veda Client system:

se
• On Veda Client, a browser initiates a connection to http://www.superveda.local.
• Packets travel from Veda Client to the Management NIC of the Firewall.

re
• The Firewall routes packets out it’s DMZ NIC to one interfaces of SecureSphere’s br0 bridge.
• SecureSphere’s br0 bridges the packet out it’s other interface to the Veda Web server.

s
• The SuperVeda Web application initiates a new connection to the Veda DB server.

ht
• Packets travel from Veda Web to one interface of SecureSphere’s br0 bridge.

ig
• SecureSphere’s br0 bridges the packet out it’s other interface to the Firewall’s DMZ NIC.
•
•
lr
The Firewall routes the packet out its Secure Network NIC to one interface of SecureSphere’s br1 bridge.
SecureSphere’s br1 bridges the packet it’s other interface to the Veda DB server.
Al
SuperVeda User Accounts
c.

The following table displays the user account credentials for the lab systems:
In

Account Type User Name Password

Windows OS Accounts
a,

SuperVeda domain admin administrator Barbapapa1

rv

Local Windows admin administrator Barbapapa1

SecureSphere domain account sspheresvc Impuser123
pe

MsSQL Accounts
SuperVeda MsSQL DB admin sa sa12
Im

SuperVeda Web App to DB login VEDA_App VEDA_Pass

SecureSphere “service” account sspheresvc Impuser123
17

FTP Server Accounts

SecureSphere service account sspheresvc Impuser123
20

SecureSphere Linux Accounts

SecureSphere MX and GW bootloader (no account) bootload12
©

SecureSphere MX and GW root root root123

SecureSphere MX and GW std. user imperva_user Impuser123
SecureSphere MX database user system system12
SecureSphere MX and GW intra- secure secure12
communications / impcfg user
SecureSphere GW agent registration imperva secure
SecureSphere Web UI

© 2017 Imperva, Inc. All rights reserved A-9 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

Default local administrator admin Impuser123

Secondary administrator admin1 Impuser123
Table 0-1 - SuperVeda lab environment user accounts

Note
SecureSphere has been hardened so that the root account can only login directly on the appliance’s console.
When connecting via SSH, login using the imperva_user account, then run the admin command to obtain root

.
privileges.

ed
rv
The SecureSphere Web User Interface

se
Administrators manage SecureSphere by accessing the MX’s Web User Interface (Web UI) from a web browser,
using the HTTPS protocol to connect to port 8083 of the MX’s IP address or hostname, for example:

re
https://192.168.51.200:8083 or https://vedamx.superveda.local:8083

s
After logging in, SecureSphere displays the Sites menu. The image on the next page shows the Sites menu and

ht
enumerates the major components of the SecureSphere Web UI. Details of the enumerated Web UI components
follow the image.

ig
lr
Al
c.
In
a,
rv
pe
Im
17
20

Figure 0-4 - Major Components of the SecureSphere Web UI

©

1. Workspaces
SecureSphere’s Web UI is organized into four Workspaces. The following table provides an overview of the
Workspaces:

Workspace Description
Main The primary Workspace, where users configure sites, policies and supporting objects to secure
applications and monitor alerts.

© 2017 Imperva, Inc. All rights reserved A-10 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

Admin The Workspace where administrators configure the SecureSphere infrastructure.

Preferences The Workspace where users configure their personal preferences, such as the user’s default Web
UI configuration page and how many days’ alert data to display.
Tasks The Workspace where users create “to-do” type tasks with reminders and follow-up actions to
help meet various compliance regulations.
Table 0-2 - Descriptions of SecureSphere's Workspaces

2. Tabs

.
ed
Workspaces are subdivided into Tabs which further categorize the components of the Workspace. In
Figure 5 above, the Setup Tab of the Main Workspace is selected.

rv
3. Menus

se
Tabs are subdivided into Menus which further categorize the components of the Tab. In Figure 5 above, the
Sites Menu of the Setup Tab is selected.
4. User drop-down menu

re
The User drop-down menu provides a short-cut to the User Details menu located in
the Preferences Workspace, and the option for the user to Log out.

s
ht
5. Action drop-down menu

ig
The Action drop-down menu provides context-sensitive actions for the selected
object. For example, when working within the Sites sub-menu, the available actions
lr
are to Export or Import. When a report is selected in the Reports menu, the action is
Run Report.
Al
6. Help Button
c.

The Help button launches SecureSphere’s online help. The online help contains
the content of SecureSphere’s user’s guides in an easily searchable format.
In

7. Object Pane
a,

As a general design principle throughout the Web UI, the left-hand window pane contains a list of objects
relevant to the current Tab and Menu.
rv
pe

In Figure 5 above, the Sites Tree, containing the Sites, Server Groups, Services, and Applications, displays in
the Object Pane, and the Unidentified – Servers SG server group is selected.
Im

8. Object Details Pane

As a general design principle throughout the Web UI, the right-hand window pane displays the details of
17

the object currently selected in the Object Pane.

20

In Figure 5 above, the Unidentified – Servers SG server group’s details display in the Object Details Pane,
and its Definitions Tab is selected.
©

Note
Some objects, such as objects in the Site Tree contain many configuration options. For such objects, the Details
Pane contains multiple Tabs to help organize all of the configuration options.

9. Save Button /

© 2017 Imperva, Inc. All rights reserved A-11 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

As a general design principle throughout the Web UI, when an editable object is selected, the Save button
appears in the top-right corner of the relevant window pane.

When changes are pending and a user attempts to navigate away from the current page in the web UI,
SecureSphere presents the following window to confirm the user’s intent:

.
ed
rv
Figure 0-5 - The Confirm Window

se
The following table lists how SecureSphere responds to each of the Confirm window’s options:
Option SecureSphere’s Response

re
Yes SecureSphere saves the pending changes to the MX’s database then continues to the web UI page
that the user selected.
No SecureSphere discards pending changes then continues to the web UI page that the user selected.

s
ht
Cancel SecureSphere maintains the changes in a pending state, and then returns the user to the original
web UI page.

ig
Table 0-3 -SecureSphere’s responses to the Confirm window options
lr
Navigating in the Web UI
Al
This training uses the following convention when providing directions to a location in the Web UI:
c.

Select Workspace > Tab (if any) > Menu

In

For example, the instruction to navigate to the default Web UI page, the Sites Tree, is written as:
Select Main > Setup > Sites.
a,
rv

Step – by – step, the actions taken in the Web UI are:

pe

1. Click the Main Workspace

Im

2. Click the Setup Tab

3. Click the Sites Menu

17

Note
20

For the Admin and Preferences Workspaces, there are no Tabs. These interface pages are identified by Workspace
> Menu. For example, Admin > Users & Permissions represents the Admin Workspace, Users & Permissions Menu.
©

© 2017 Imperva, Inc. All rights reserved A-12 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

Changing the Default Menu

Users can set their default menu as desired. While
setting up the site, the default Setup > Sites Menu is
probably the best choice; however, users can
customize this from Preferences > Preferences.
(Click the Preferences Workspace, then click the
Preferences Menu.)

.
ed
rv
se
Tip

re
Different user roles may benefit from setting different SecureSphere Web UI default pages. Consider your

s
organization’s roles and responsibilities and try to answer the following questions for your production

ht
environment. If needed, review the list in the Default Home Page drop-down menu when answering.

ig
What default page might an Auditor prefer? (Main workspace is assumed)
lr
What default page might the Security Operations team prefer?
Al
What default page might the SecureSphere project leader prefer?

Global Objects
c.
In

Global Objects are objects created once and maintained in a central location that are used globally with a number of
SecureSphere features. Global objects provide an additional level of granularity that assists in focusing on a specific
a,

set of IP addresses, or advanced functionality such as rules that guide the rewriting of URLs for use with load
balancers.
rv

For example, one of the applications SecureSphere is protecting is a

pe

Web server. You decided that traffic from a specific group of hosts in
internal-only company networks is not a threat (Pen-Test machines
Im

that need full access through SecureSphere to the end web server).
The traffic between these source IPs and the protected Web Server
does not need to be monitored.
17

SecureSphere enables you to configure a global object called an IP

group with a list of all the IP addresses of the Pen-Test hosts. Then
20

you can later use this IP group when configuring a Server Group, to
tell SecureSphere to ignore traffic from this IP Group to the
protected server, reducing the number of false-positive alerts, and
©

the hardware resources needed by SecureSphere.

As demonstrated in the preceding example, Global Objects are

typically not stand alone features; rather they are containers for
information used in larger or more complex configuration tasks.
Global Objects are located at Main > Setup > Global Objects.

© 2017 Imperva, Inc. All rights reserved A-13 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

Some configurations require multiple steps or have dependencies upon other objects. Throughout the Web UI the
Edit Object button provides a shortcut to simplify the process. In the image below, clicking the Edit Object
button opens the Windows Domain Global Objects, which can also be accessed by selecting Setup > Global Objects
and then setting the Scope to Windows Domains:

.
ed
rv
se
re
s
ht
Hanging Tabs

ig
In some menus, such as Monitor > Alerts, and Policies > Security, there are additional, vertical, Hanging Tabs on the
lr
left and right side of the web interface. The Hanging Tabs allow users to toggle between showing and hiding certain
window panes in the Web UI. When a window pane is hidden, it provides the user more space on the monitor to
Al
display the window pane(s) that are still visible.
The Main > Monitor > Alerts, Main > Monitor > Violations, and Main > Monitor > System Events Web UI pages have a
c.

Filter Pane on the left side, the Item List Pane in the middle, and the Details Pane on the right side. The Filter and
In

Details Panes can be toggled on or off by clicking Filter Hanging Tab (1), or Details Hanging Tab (2), respectively:
a,
rv
pe
Im
17
20
©

Figure 0-6 - The Web UI's Hanging Tabs

Viewing and Filtering System Events

© 2017 Imperva, Inc. All rights reserved A-14 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

SecureSphere generates large amounts of alert data. Filtering the alerts helps to quickly find specific alert data of
interest. SecureSphere provides a Quick Filter, and the Basic and Advanced filters.

When viewing events (Main > Monitor > System Events) in your lab, most of the current events in the log will pertain
to updating Threat Radar and user logins and logouts, as shown in the following image:

.
ed
rv
se
re
s
ht
Figure 0-7 - The System Events log

ig
Use the navigation buttons lr
above the log to scroll through different pages of logs.
Optionally, enter a page number in the navigation area, and press Enter, instead of moving one page at a time.
Al
The lab does not have a significant amount of System Events; however, production environments generate
c.

thousands of events every day. Finding specific events by manually scrolling through the logs and viewing the
In

Messages column is inefficient. SecureSphere provides three different methods to filter the logs, to help find specific
logs: The Basic filter, the Advanced filter, and the Quick filter. The filters work similarly when viewing Violations and
a,

Alerts, though offering significantly more criteria, as violations and alerts log more complex conditions and
messages.
rv

The Basic Filter

pe

The Basic Filter provides several categories of criteria, each containing several specific, individual criteria that toggle
Im

on and off to filter events. To apply a filter, expand the categories as to view the individual criteria, and check the
checkbox next to the criteria to enable it. Multiple criteria across multiple categories may be selected. System
17

Events that match all the selected criteria will display when the filter is applied.
20

Once all the desired criteria are set, at the bottom of the Basic Filter, click the Apply button to filter the System
Event logs according to the selected criteria. Click the Clear button to remove the filter and display all System
Events. Administrators can also save filters for quick recall and application at a future time. With the filter applied,
©

click the Save button and provide a name for the saved filter.

The image below shows a Basic Filter applied with the criteria High Severity and Config Subsystem selected. The By
Subsystem category is collapsed; however, the icon appears, indicating that the category contains selected

© 2017 Imperva, Inc. All rights reserved A-15 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

criteria. Additionally note the Subsystem and Severity columns in the log only display events that match both
selected criteria, High Severity and the Config Subsystem.

.
ed
rv
se
Figure 0-8 - The System Events log, with a Basic Filter applied

re
The Advanced Filter

s
When selecting criteria to build a Basic Filter, SecureSphere adds the criteria to the Advanced Filter. The Basic Filter

ht
is really the same filter as the Advanced Filter, but selections made in the Basic Filter are not as granular. In the

ig
Advanced Filter, search criteria are called Fields. Click the Advanced button at the bottom of the Basic
Filter to open the Advanced Filter. lr
Al
The image on the following page shows the Advanced Filter that is built when selecting criteria in the Basic Filter:
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved A-16 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.

Figure 0-9 - The High-sev Config events filter, shown in the Advanced Filter window
In

The Advanced Filter contains a list of Enabled Fields and Available Fields. Use the Up and Down buttons to
move the fields between enabled and available lists. Use the Left and Right buttons to select and de-
a,

select the Predefined Values with a Field.

rv

The following table describes the components of the Advanced Filter Fields:
pe

Filter Field Parameter Description

Operation Equals – The filter matches the Selected values.
Im

Not Equals – The filter omits the Selected values.

Values Depending on the Field, this may be:
17

• A list of predefined values from which the administrator selects values

• A free-form text input box, where administrators manually enter a value
20

• A table allowing multiple free-form text entries

• A combination of a list and the ability to freely enter text
©

• Context-specific data, such as entering a date range in the Time Frame field

Table 0-4 - Filter Field Parameter descriptions

When selecting multiple values within a Field, the filter matches System Events when the event contains ANY of the
values entered in the Field (a logical OR operation between values). When building a filter with multiple Fields, the
filter matches System Events that match ALL Fields (a logical AND operation between fields).

© 2017 Imperva, Inc. All rights reserved A-17 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

For example, if an administrator wants to review Medium and High severity events, except items from the Config
subsystem, configure the Advanced Filter like the following image:

.
ed
rv
se
re
s
ht
ig
Figure 0-10 - An Advanced Filter with logic: (Severity = Medium OR High) AND (Subsystem != Config)
lr
You can save a filter before or after it is applied, by clicking the Save button at the bottom of the Edit Filter window.
Al
Note
c.

When you save filters, they are available to all SecureSphere users with permissions to user interface page where
In

the filter was created. As a best practice, Imperva recommends implementing a naming convention for saved
filters. For example, Team name – Filter name.
a,

Note
rv

The Basic and Advanced Filters are available throughout most of SecureSphere’s Web UI to help users find specific
pe

Alerts, Policies, Audit Data, Reports, etc. In each of SecureSphere’s menus, the Basic Filter provides context-
specific categories and the Advanced Filter provides context-specific Match Criteria; however, the filters are
configured and applied in the same manner described for filtering System Events.
Im

The Quick Filter

17

In the System Events Menu, the Quick Filter is located at the top of the System Events list.
20
©

Figure 0-11 - The Quick Filter, located above the System Events

© 2017 Imperva, Inc. All rights reserved A-18 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

Use the Quick Filter to perform simple, literal, text matching searches on the Message column by entering the text in

the Quick Filter and then pressing Enter, or clicking the Search button.

Tip
Many search engines allow user to specify exact phrases by enclosing them in quote marks, for example, “search
this exact phrase”. However, SecureSphere’s Quick Search performs these exact, literal searches by default. When
users enter a space or a quote mark in the Quick Search, SecureSphere looks for those to literally appear exactly

.
as entered in the Quick Search field, within the Message itself.

ed
To remove the filter, click the Remove Filter button. Either the standard Basic/Advanced Filter, or the Quick

rv
Filter is active; SecureSphere does not apply both filters at the same time.

se
Note

re
The Quick Filter is only present in some of SecureSphere’s menus.

s
ht
When using the Quick Filter from either the Alerts or Violations menus, you can also limit the Quick Filter to search
specific criteria, such as a Source IP or User. The following table shows the syntax to use for the criteria supported

ig
by the Quick Search:
Criteria
Number
Syntax
number:xyz
Description lr
Number assigned to the alert.
Al
Session ID session:xyz Session ID that generated the alert.
Source IP ip:w.x.y.z IP address that was the source of the generated alert
c.

Event ID event:xyz Event ID that generated the alert.

In

Alert type type:xyz Type of alert: Firewall, Signature, Protocol, Correlation, Custom.
Server Group server group:xyz Any server groups configured in SecureSphere and to which the
a,

logged in user has permission to view.

Violation violation:xyz Type of violation that was detected.
rv

User user:xyz User with whom the alert is associated.

pe

Description description:xyz Description provided by the alert.

Table 5 - Quick Filter Search Criteria for Alerts and Violations
Im

For example, if you want to see all alerts generated by IP address 192.168.51.31, enter ip:192.168.51.31 in the
Quick Filter text box, and click the Search button.
17

Setting Criteria in Policies

20

When working with SecureSphere’s policies of any type, the policy’s Available Match Criteria functionally equates to
the Available Fields in SecureSphere’s Advanced Filter, showing the list of Criteria that can be used in the policy. To
©

make any of the Criteria active, move the Criteria from Available Match Criteria up to Match Criteria, in the same
manner that you would move a Filter field from Available Fields up to Enabled Fields. The following image shows the
Alert Filter on the left, compared against policy Match Criteria on the right:

© 2017 Imperva, Inc. All rights reserved A-19 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

.
ed
Figure 0-12 - Similarity of selecting Filter Fields and Policy Match Criteria

rv
When selecting multiple Match Criteria, the same logic applies as when selecting multiple Filter Fields. When
selecting multiple values within a Criteria, the Criteria matches when the data contains ANY of the values entered in

se
the Criteria (a logical OR operation between values). When building Match Criteria with multiple Criteria, the policy
matches data that matches ALL selected Match Criteria (a logical AND operation between fields).

re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved A-20 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

Exercises
Exercise 1 – Login to the SecureSphere Web UI
In the SuperVeda lab environment, from the Veda Client VM, open Firefox (Click the Firefox icon in
Windows’ Taskbar). When Firefox opens, it connects to the MX’s Web UI by default.

Note

.
ed
If Firefox’s default home page was not set to the MX’s Web UI, you would manually enter one of the URLs:
https://192.168.51.200:8083 or https://vedamx.superveda.local:8083 to access the Web UI.

rv
se
In the lab environment, login now, using the admin credentials, user: admin; password: Impuser123.

re
s
ht
ig
lr
Al
c.
In
a,
rv
pe

Exercise 2 – Configure User Specific Preferences

Im

Users can set their default home page as desired. While setting up the site, the default Setup > Sites home page is
probably the best choice; however, perform the following steps in the lab environment to see additional choices:
17
20

1. Select Preferences > Preferences. (Click the Preferences Workspace, then click the Preferences Menu.)

2. In the Customize User Interface Settings section, click the Default Home Page drop-down menu and review
©

the list of possible default pages. After reviewing the list, leave the Default Home Page set to Sites.

(See image on next page)

© 2017 Imperva, Inc. All rights reserved A-21 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
Tip
lr
Al
Different user roles may benefit from setting different SecureSphere Web UI default pages. Consider your
organization’s roles and responsibilities and try to answer the following questions for your production
c.

environment. If needed, review the list in the Default Home Page drop-down menu when answering.
In

What default page might an Auditor prefer? (Main workspace is assumed)

a,

What default page might the Security Operations team prefer?

What default page might the SecureSphere project leader prefer?
rv
pe

3. Set the Default Time Frame for Event Filtering (Days) to 365. This will be helpful for reviewing older, pre-
configured example alerts in the training environment.
Im
17
20

4. Click the Save button.

5. Select Preferences > User Details and review the information you can set for the user.
©

© 2017 Imperva, Inc. All rights reserved A-22 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

6. In the Email: text, enter: [email protected].

.
ed
rv
se
7. Click the Save button.

re
Note

s
ht
In the lab environment, traffic is not continually generated; instead the labs contain traffic that was generated at
the time of their development. In your production environment, if you do not set the Default Time Frame for

ig
Event Filtering (days) far enough back, you may not see the oldest alerts when just clicking the Alerts Menu.
lr
Al
Exercise 3 – Create an IP Group Global Object
Create an IP Group Global Object that contains SuperVeda’s networks. You will use this IP Group in later labs:
c.

1. Select Main > Setup > Global Objects.

In

2. In the Scope Selection drop-down menu, select IP Groups.

a,
rv
pe
Im
17
20
©

3. Click the Create New button in the Globals Tree pane. The Create IP Group window opens.

© 2017 Imperva, Inc. All rights reserved A-23 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

4. Enter the following Name: SuperVeda Networks and click Create:

.
ed
The newly created IP Group is created and selected in the Globals Tree,

rv
pane, as shown to the right:

se
5. In the IP Group details pane, add 3 new rows to the table by clicking the Create New button3 times.

re
In the Type column for all rows, set the drop-down to Network.

s
6. Enter the Network (CIDR Notation) columns as follows:
192.168.51.0 / 24

ht
192.168.53.0 / 24

ig
192.168.54.0 / 24
lr
Al
c.
In
a,

7. Click the Save button.

rv
pe

Note
Im

The Create New and Delete buttons appear throughout SecureSphere’s Web UI. In general, when you’re
instructed to create or delete an object, or to add or remove a row from a table, use the Create or Delete buttons.
When deleting items, you must first select the item or row, then click the Delete button.
17
20

Exercise 4 – Create and Save a System Events Filter

From Main > Monitor > System Events, apply a Basic Filter with the criteria High Severity
©

and Config Subsystem selected.

1. In the Basic Filter, Expand the By Severity category and select High.
2. Expand the By SubSystem category and select Config.
3. Click the Save button at the bottom of the filter.
4. When prompted, enter the name, High-sevb Config events.

© 2017 Imperva, Inc. All rights reserved A-24 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

Saved filters are stored in the Saved Filters tab, next to the Basic Filter tab. Click
the Saved Filter to apply it.

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved A-25 Appendix A: Lab Environment and Web UI
SecureSphere 12.0 Web Application Security Course Manual

.
ed
rv
se
re
s
ht
ig
lr
Al
c.
In
a,
rv
pe
Im
17
20
©

© 2017 Imperva, Inc. All rights reserved A-26 Appendix A: Lab Environment and Web UI