Applies To:

Show Versions Show Versions

Manual Chapter: Configuration Guide for BIG-IP® Application Security Management: 5 - Working With the Security Policy
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>


5

Working With the Security Policy


What is a security policy?

The core of the Application Security Manager's security functionality is the security policy. The security policy is a map of the web application itself. When the Application Security Manager receives an incoming HTTP or HTTPS request for the web application, the system compares the request to the active security policy. If the request does not comply with security policy, the Application Security Manager processes the request according to the blocking mode: either the system issues a security alert and lets the request through; or the system issues a security alert, blocks the request, and sends a blocking response and support ID to the client. In both cases, the system reports the security policy violation, and records the request in the Forensics information. You can then review the violation to decide if it really was a legitimate request. If the request is legitimate, then you can update the security policy accordingly.

Chapter overview

This chapter contains information about the following aspects of the security policy.

  • Security policy properties
    The security policy properties determine the overall characteristics and behavior of the security policy. The security policy properties specify how the security policy interacts with the security policy entities. The security policy properties also specify how the security policy processes and responds to security policy violations.
  • Security policy entities
    The security policy entities compose the security policy. The security policy entities can include web objects, object types, parameters, flows, character sets, and regular expressions.
  • Managing the security policy
    Security policies may need to be modified over time, as the protected web application changes. In addition to the tools that you can use to build and refine a security policy (the Policy Builder and the Learning process), you can manually add, edit, or delete almost every entity in the security policy.

Working with the security policy properties

Before you configure the security policy entities, which are the map of the web application, you configure the policy properties of the security policy. The policy properties are the general configuration options and settings that determine the overall behavior and functionality of the security policy. Note that not all policy properties apply to all security policies. Some are applicable only if you configuring a security policy that uses the high security level. (See Configuring the security level , for more information on security levels.)

The policy properties include the following options:

  • General policy properties
    The general policy properties specify the general characteristics of the security policy.
  • Policy Builder
    The Policy Builder is a set of automated tools that you can use to build and refine the security policy entities. See Chapter 6, Building a Security Policy With the Policy Builder , for additional information on the Policy Builder.
  • Blocking response page
    The blocking response page specifies the content of the response that the system sends when the security policy blocks a client request from accessing the web application.
  • Sensitive parameters
    You can use the sensitive parameters property to protect sensitive user input, such as a password or a credit card number, in a validated request.
  • Allowed modified cookies
    The allowed modified cookies property specifies any HTTP cookies that the security policy should ignore, even if the cookies do not meet the expected criteria.
  • Allowed methods
    The allowed methods property specifies the HTTP methods that are acceptable within the context of the web application.
  • Navigation parameters
    The navigation parameters property specifies parameters within an HTTP request that the system treats as if they are part of the URL, even though they are not.

The following sections of this chapter describe the security policy properties in detail.

Important

Any time you make a change to a security policy, no matter how small, you must apply the security policy to make it the active security policy. Once you set the active security policy, the Policy Enforcer enforces any changes you have made. To set the active policy, refer to Setting the active policy for a web application , for detailed information.

Working with the general policy properties

You use the general policy properties to configure the general attributes of the security policy, including the security level.

To configure the general policy properties for a security policy

  1. On the Main tab of the navigation pane, expand the Application Security section, and then click Web Applications.
    The Web Application Groups screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List area, in the Security Policy Name column, click the name of a security policy.
    The Policy Properties screen opens.
  4. In the Policy Properties area, make changes to the general security policy properties as required. For additional information on the settings, click the Help tab in the navigation pane.
  5. Click the Save button to save any changes you may have made to the general security policy properties.
  6. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.

Configuring the security policy name and description

Each security policy that you configure has a unique name, which you configure on the Policy Properties screen as part of the general properties. At minimum, a new security policy must have a name. You can change the security policy name at any time. You can also provide a description of the security policy, to help you better identify the security policy.

To configure the security policy name

  1. On the Main tab of the navigation pane, expand the Application Security section, and then click Web Applications.
    The Web Application Groups screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List area, in the Security Policy Name column, click the name of a security policy.
    The Policy Properties screen opens.
  4. In the Policy Properties area, for the Security Policy Name setting, type a unique name for the security policy.
  5. Optionally, in the Policy Description box, type a description, as required.
  6. Click the Save button to save any changes you may have made.
  7. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.

Viewing the security policy's corresponding web application

From the Policy Properties screen, you can easily review the corresponding web application.

To view the web application for a security policy

  1. On the Main tab of the navigation pane, expand the Application Security section, and then click Web Applications.
    The Web Application Groups screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List area, in the Security Policy Name column, click the name of a security policy.
    The Policy Properties screen opens.
  4. In the Policy Properties area, click the name of the web application in the Web Application setting.
    The Web Application Properties screen opens, where you can view the details of the web application.

Configuring the security level

There are three system-supplied security policy levels: standard, enhanced standard, and high security (also known as APC). The security level determines the degree of granularity to which the security policy protects the web application. The security levels are cumulative in nature, for example, an enhanced standard security policy provides all the protection of a standard security policy, and also protects a subset of entities that you specify. Note that as you increase the granularity of protection, you also increase the maintenance commitments for the security policy.

Each security level offers its own advantages.

  • Standard
    A standard level of security protects against common, known attacks. A security policy that uses the standard security level contains the object types and character sets for the web application. A standard security policy also includes a negative regular expressions pool that the system uses to detect known attack patterns. In a standard security policy, each page of the web application is an entry point. A standard security policy primarily uses negative security logic to protect the web application.
  • You can configure the standard security policy to protect the application against attacks in the following areas:

    • SQL injection
    • Cross-site scripting
    • Cookie poisoning
    • Buffer overflow
    • Parameter tampering (lengths and meta characters)
    • Forceful browsing (file type enforcement)
    • Stealth commanding
    • Back-door and debug options
    • Third-party misconfiguration
  • Enhanced Standard
    An enhanced standard level of security is based on the protection offered by a standard security policy, but uses high security to protect a small subset of objects in the application. For example, a security policy that uses the enhanced standard security level might include flows or user-input parameters, in addition to the object types, meta characters, and negative regular expressions that are in a standard security policy. An enhanced standard policy protects the web application with a combination of positive and negative security logic.
  • High Security (APC)
    An APC security policy protects against common, known attacks (like a standard security policy does), and also protects individual parameters within the application, their associated web objects, and any flows to or from the objects. When you have fully configured an APC security policy, and put it into blocking mode, it applies mostly positive security logic. (See Understanding positive security logic for more information.) The APC security level requires a longer setup time, as the security policy configuration is more closely tied to specific entities in the application.
  • Custom
    Whenever you modify any of the default settings on the Blocking Policy screen, and you save the modifications, the system saves the security level as Custom. You can modify the default settings for any of the system-supplied security levels (Standard, Enhanced Standard, or High Security) to create a custom security level. Note that you can create only one custom security policy.

To edit a system-supplied security level

  1. On the Main tab of the navigation pane, expand the Application Security section, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List, in the Security Policy Name column, click the name of the security policy that you want to update.
    The Policy Properties screen opens.
  4. In the Policy Properties area, for the Security Level setting, click the Edit button.
    The Blocking Policy screen opens.
  5. Make any changes on this screen that are pertinent to your web application.
  6. Click Save to save any changes you may have made to the Blocking Policy settings.
  7. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.
Note

On the Blocking Policy screen, the default settings change depending on the security level of the security policy. For full details on working with the Blocking Policy screen, refer to Working with the Blocking Policy settings .

Configuring the blocking mode

There are two blocking modes for a security policy: transparent and blocking. When the system receives an incoming HTTP request that does not comply with the security policy, the system logs the HTTP request and generates alarms for the violations. If the security policy is in transparent mode, the system then forwards the request to the web application. If the security policy is in blocking mode, the system does not forward the request to the web application. Instead, the system sends the blocking response page to the client, which advises the client that the request was blocked, and provides a support ID number for the violating request.

To configure the blocking mode

  1. On the Main tab of the navigation pane, expand the Application Security section, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List, in the Security Policy Name column, click the name of the security policy that you want to update.
    The Policy Properties screen opens.
  4. In the Policy Properties area, check or clear the Disable Blocking check box, as required.
    • For transparent mode, check the box.
    • For blocking mode, clear the box.
  5. Click Save to save any changes you may have made to the security policy properties.
  6. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.

Using the Learning process to determine when to enable Blocking mode

During the Learning process, the alarms for policy violations should diminish over time as you refine the security policy. When the alarms are almost non-existent, you can be confident that all missing entities have been added to the security policy, and other attributes are attuned to real-life traffic requirements. At this point, you can transition the security policy from transparent mode to blocking mode. After you activate the security policy in blocking mode, illegal requests may continue to generate learning suggestions, if, on the Blocking Policy screen, you have the Learning flag enabled for the violation type.

Tip


You can specify whether a violation triggers a learning suggestion on the Blocking Policy screen. See Configuring the Learn, Alarm, and Block flags , for more information.

You activate blocking mode at the point in time when you can reasonably assume that the security policy is accurate; meaning, all resources are present and all attribute values meet the requirements of legitimate real-life traffic and, therefore, any further alarms should be considered suspicious. Note that you can activate blocking mode, and enable the Block flags in phases. For example, you can enable blocking for only the illegal HTTP format and RFC violations first, and then slowly enable blocking for the remaining applicable violations.

Note

We advise you not to activate blocking mode until the security policy does not generate any alarms over several days.

Configuring the maximum HTTP header length

You specify a maximum HTTP header length so that the system knows the acceptable maximum length for the HTTP header in an incoming request. The system applies the length check to header names and value. The default maximum length is 8192 bytes. You can use this setting to help prevent primary buffer overflow attacks.

To configure the maximum HTTP header length

  1. On the Main tab of the navigation pane, expand the Application Security section, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List, in the Security Policy Name column, click the name of the security policy that you want to update.
    The Policy Properties screen opens.
  4. In the Policy Properties area, for the Max HTTP Header Length setting, select one of the following options:
    • Select Any to have the system accept HTTP headers of any length.
    • Select Length, and type a value, to accept HTTP headers up to a certain length.
  5. Click Save to save any changes you may have made to the security policy properties.
  6. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.

Configuring the maximum cookie header length

You specify a maximum cookie header length so that the system knows the acceptable maximum length for any cookie headers in the incoming HTTP request. As with the maximum HTTP header length setting, you can use this setting to help prevent primary buffer overflow attacks.

To configure the maximum cookie header length

  1. On the Main tab of the navigation pane, expand the Application Security section, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List, in the Security Policy Name column, click the name of the security policy that you want to update.
    The Policy Properties screen opens.
  4. In the Policy Properties area, for the Max Cookie Header Length setting, select one of the following options:
    • Select Any to have the system accept cookie headers of any length.
    • Select Length, and type a value, to accept cookie headers up to a certain length.
  5. Click Save to save any changes you may have made to the security policy properties.
  6. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.

Configuring the flow mode

The flow mode specifies how the security policy treats the objects that make up the web application. When you specify the simple flow mode, the Policy Builder and the Learning process define all objects as entry points. In other words, the simple flow mode ignores the navigational relationships of the web application objects. When you specify the advanced flow mode, the Policy Builder and the Learning process map the navigational relationships of each and every web application object. For example, the navigational relationships for each button, graphic file, HTML page, form input field, and hyperlink are all part of the application's flow. Using the web browser's Back and Forward buttons is also part of the application flow, if these actions are permitted within the web application.

Note

We recommend that, for most web applications, you use the simple flow mode. If you need the additional security of the advanced flow mode for a particular aspect of your web application, we recommend that you define a flow parameter. For additional information on flow parameters, see Working with flow parameters .

To configure the flow mode

  1. On the Main tab of the navigation pane, expand the Application Security section, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List, in the Security Policy Name column, click the name of the security policy that you want to update.
    The Policy Properties screen opens.
  4. In the Policy Properties area, for the Flow Mode setting, select Simple or Advanced.
  5. Click Save to save any changes you may have made to the security policy properties.
  6. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.
Important

Always maintain the same flow mode that was used to initially create a specific policy. We do not recommend that you switch back and forth between Simple and Advanced flow modes.

Working with the negative regular expressions pool

Each security policy has its own set of negative regular expressions that define known attack patterns. The system applies the regular expressions (regexps) to incoming requests to look for known attacks and threats, such as known worms and Trojan horses, cross-site scripting attacks, SQL injection attacks, and others. If an incoming request contains a component that matches a negative regular expression in the security policy, then the system generates an alarm (and blocks the request if in blocking mode).

You can apply the negative regular expressions to the following components of the incoming request: an object type, a parameter and value pair, and the HTTP header itself. You can also apply a negative regular expression to an HTTP response, if you want the security policy to filter responses.

Note

The regular expression pool that is associated with a security policy is derived from a system-supplied default pool. The default regular expression pool is independent of any security policy or web application. For information on managing the default regular expression pool, see Working with the system-supplied regular expressions .

Viewing the negative regular expressions pool for a security policy

You can review the regular expressions that are associated with a security policy from the Negative RegExps screen.

To view the negative regular expressions pool for a security policy

  1. On the Main tab of the navigation pane, expand the Application Security section, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List, in the Security Policy Name column, click the name of the security policy that you want to update.
    The Policy Properties screen opens.
  4. In the Policy Properties area, for the Negative RegExps setting, click the Edit button.
    The Negative RegExps screen opens, where you can review the negative regular expressions for the security policy.

Tip


Click a regular expression name to view the syntax for the regular expression.

Adding a negative regular expression to the pool for a security policy

While the default pool includes regular expressions to catch most known attack patterns, there may be situations in which your security policy requires one or more user-defined regular expressions. You can create user-defined regular expressions as part of the system-supplied default pool, which is independent of any security policy. For information on creating and validating a user-defined regular expression, see Creating a user-defined regular expression , and Validating a user-defined regular expression . Once you have created the user-defined regular expression, you can then add the user-defined regular expression to the security policy pool.

To add a user-defined regular expression to the security policy pool

  1. On the Main tab of the navigation pane, expand the Application Security section, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List, in the Security Policy Name column, click the name of the security policy that you want to update.
    The Policy Properties screen opens.
  4. In the Policy Properties area, for the Negative RegExps setting, click the Edit button.
    The Negative RegExps screen opens.
  5. Above the Negative RegExps area, click the Add button.
    The Create New Negative RegExp screen opens.
  6. In the Add Negative RegExp to Policy area, from the RegExp Name list, select the user-defined regular expression that you want to add to the pool.
  7. From the Applies to list, select the policy entity to which the regular expression applies.
  8. Click the Add button.
    The system updates the configuration with any changes you may have made.
  9. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.

Editing the entity to which the regular expression applies

The Application Security Manager can apply the negative regular expressions to the following entities: web object URIs, header values, parameter key and value pairs, or responses. You can configure the system to apply the same regular expression to one or more of these entities, however, you make each association separately.

Table 5.1 describes how the system applies the negative regular expressions to each entity.

 

Table 5.1 How the system applies negative regular expressions to entities
Entity
Applies the regular expression to
Object
The object and path in the URI of the request.
Response
The response headers and content.
Header value
The value of the HTTP headers in the request.
Parameter=Value Pairs
The parameter key and value pairs included in the request, either in the query string or in the POST data.

 

To change the entity to which a regular expression applies

  1. On the Main tab of the navigation pane, expand the Application Security section, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List, in the Security Policy Name column, click the name of the security policy that you want to update.
    The Policy Properties screen opens.
  4. In the Policy Properties area, for the Negative RegExps setting, click the Edit button.
    The Negative RegExps screen opens.
  5. In the Negative RegExps area, in the Select column, check the box next to the regular expression for which you want to change the entity association, and then click the Edit button below the list.
    The Edit Negative RegExp screen opens.
  6. In the Edit Negative RegExp area, from the Applies to list, select the policy entity to which the regular expression applies.
  7. Click the Update button.
    The system updates the configuration with any changes you may have made.
  8. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.

Removing a regular expression from the pool for a security policy

The Application Security Manager has a large pool of default negative regular expressions. You can choose to use some or all of them to protect your web application. For example, you can configure a security policy to use a set of regular expressions to detect SQL injection attacks if your web application uses a database. You can also use a set of regular expressions to detect cross-site scripting attacks that a hacker may try to insert into any text form within your application. For additional information on the system-supplied regular expressions, refer to Working with the system-supplied regular expressions .

Depending on the requirements for securing your web application, you may not need all of the default regular expressions that are in the negative regular expressions pool for the security policy. You can easily remove those that do not apply to the security policy. Removing a regular expression from the security policy pool does not permanently delete the regular expression from the system configuration. If you want to restore a regular expression that you have removed from the security policy pool, you can re-add the regular expression to the system default pool. See Restoring the negative regular expressions pool to the default settings , for more information.

To remove a regular expression from the security policy pool

  1. On the Main tab of the navigation pane, expand the Application Security section, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List area, in the Security Policy Name column, click the name of the security policy that you want to update.
    The Policy Properties screen opens.
  4. In the Policy Properties area, for the Negative RegExps setting, click the Edit button.
    The Negative RegExps screen opens.
  5. In the Negative RegExps area, in the Select column, check the box next to the regular expressions that you want to delete from the security policy pool, and then click the Remove button below the list.
    A confirmation popup screen opens.
  6. Click OK.
    The screen refreshes, and the system removes the selected regular expressions.
  7. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.

Overview of the Policy Builder

The Application Security Manager provides the Policy Builder to automate building the map of the web application within a security policy. If you were to build the security policy manually, it would be a tedious undertaking, especially if the web application is updated frequently. You can use the Policy Builder to build the security policy based either on real traffic (both requests and responses), or on system-generated traffic. See Chapter 6, Building a Security Policy With the Policy Builder , for detailed information on using the Policy Builder.

Working with the Blocking Response Page property

The Application Security Manager has a default response page that it returns to the client when the client request, or the response returned by the web server, is blocked by the security policy. This page is the blocking response page. Note that the system uses the blocking response page only when the security policy is in blocking mode. To configure the Blocking Response Page property, you can do one of the following:

  • You can use the default response page.
  • You can customize the default blocking response page.
  • You can upload a custom blocking response page.
  • You can provide a URL for redirection.

Customizing the blocking response page

You can customize the blocking response page by modifying the default text, or by uploading a custom HTML file. Alternately, you can redirect the client to another resource by providing a redirect URL. These options are explained in the following task.

To customize the blocking response page

  1. On the Main tab of the navigation pane, expand the Application Security section, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List area, in the Security Policy Name column, click the name of the security policy that you want to update.
    The Policy Properties screen opens.
  4. Above the Blocking Response Page area, click the Edit button.
    The Blocking Response Page popup screen opens.
  5. From the Response Type list, select the response that the system returns when it blocks a client request.
    • Default Response: Specifies that the system returns the system-supplied blocking response page. Note that you cannot edit HTML code on the default response page.
    • Redirect URL: Specifies that the system returns a redirect URL.
    • Custom Response: Specifies that the system returns a user-defined response page.
    Note: The remaining settings on this popup screen change depending on the selection that you make for the Response Type setting.
  6. In the Response Code box, type the HTTP response code that is returned to the client in the HTTP response header. The default setting is 200. We recommend that you do not change this setting.
  7. If you selected the Redirect URL option in step 4, then in the Redirect URL box, type the URL to which the system redirects the client. The URL that you configure should be for a page that is not within the web application itself.
  8. If you selected the Custom Response option in step 4, perform one of the following tasks to create a custom blocking response page.
    • In the Paste HTML Code box, type the text that you want the system to send in the custom blocking response page. Note that you should use standard HTML syntax.
    • For the Upload HTML File setting, either type a path to an HTML response page in the box, or click Browse and navigate to an HTML response page. Click Upload when you are finished.
  9. Click OK to save any changes you may have made, and close the popup screen.
  10. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the Policy Properties screen.

Viewing the blocking response page

Once you have configured the Blocking Response Page property, you can view the page to see how it appears to those who receive it. You can view the blocking response page from the Policy Properties screen.

To view the blocking response page

  1. On the Main tab of the navigation pane, expand the Application Security section, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List, in the Security Policy Name column, click the name of the security policy that you want to update.
    The Policy Properties screen opens.
  4. Above the Blocking Response Page area, click the Show button.
    The Blocking Response Page popup screen opens, where you can view the text as it appears to recipients.

Working with the Sensitive Parameters property

The Application Security Manager stores incoming requests in plain text format. Some requests may include sensitive data, such as a password or a credit card number, that you may not want the system to store once the request has been processed. You can avoid storing any sensitive data as plain text by adding the names of the input fields to the Sensitive Parameters property. The system then replaces the sensitive data, in the stored request, with a series of Xs.

Configuring a sensitive parameter affects only how the Application Security Manager stores and displays information in requests and responses. It does not affect the requests or responses sent to the web application or the client.

Note

The Application Security Manager automatically creates a sensitive parameter called password for every new security policy.

To create a sensitive parameter

  1. On the Main tab of the navigation pane, expand the Application Security section, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List, in the Security Policy Name column, click the name of the security policy that you want to update.
    The Policy Properties screen opens.
  4. Above the Sensitive Parameters section, click the Create button.
    The Create New Sensitive Parameter popup screen opens.
  5. In the Parameter box, type the name of the user-input parameter, exactly as it occurs in the HTTP request, for which you do not want the system to store the actual value. In the following example, account is the sensitive parameter:
  6. http://www.siterequest.com/bank.php?account=12345
  7. Click OK.
    The popup closes, and on the Policy Properties screen, you can see the newly-created sensitive parameter in the Sensitive Parameters list.
  8. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.

In addition to creating sensitive parameters, you can also edit or delete existing sensitive parameters, as required by changes in the web application. Simply check the box next to an existing sensitive parameter, and click either the Edit or Delete button below the Sensitive Parameters section.

Working with the Allowed Modified Cookies property

You can configure the security policy to ignore certain cookies that are included in an HTTP request, even if they do not meet the expected criteria, and would otherwise trigger a security policy violation. You use the Allowed Modified Cookies property to manage the list of cookies that you want the security policy to ignore.

To define an allowed modified cookie

  1. On the Main tab of the navigation pane, expand the Application Security section, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List, in the Security Policy Name column, click the name of the security policy that you want to update.
    The Policy Properties screen opens.
  4. Above the Allowed Modified Cookies area, click the Create button.
    The Create New Allowed Cookies popup screen opens.
  5. In the Cookie Name box, type the name of an allowed cookie.
    Enter the name of the cookie exactly as it is expected to appear in the request.
  6. Click OK.
    The popup closes, and on the Policy Properties screen, you can see the newly-created allowed cookie in the Allowed Modified Cookies list.
  7. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.

In addition to creating allowed cookies, you can also edit or delete existing allowed cookies, as required by changes in the web application. Simply check the box next to an existing allowed cookie, and click either the Edit or Delete button below the Allowed Modified Cookies section.

Working with the Allowed Methods property

The Application Security Manager accepts certain HTTP methods by default. The default methods are GET, POST, and HEAD. The system treats any incoming HTTP request that uses an HTTP method other than the allowed methods as an invalid request. If your web application uses HTTP methods other than the default allowed methods, you can use the Allowed Methods property to manage them.

To specify additional allowed methods

  1. On the Main tab of the navigation pane, expand the Application Security section, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List, in the Security Policy Name column, click the name of the security policy that you want to update.
    The Policy Properties screen opens.
  4. Above the Allowed Methods area, click the Create button.
    The Create New Allowed Method popup screen opens.
  5. From the Method list, select the new method that you want to add to the allowed methods list.
  6. In the Act as Method box, select one of the following options.
    • GET: Specifies that the request does not contain any HTTP data following the HTTP header.
    • POST: Specifies that the request contains HTTP data following the HTTP header.
  7. Click OK.
    The popup closes, and on the Policy Properties screen, you can see the additional allowed method in the Allowed Methods section.
  8. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.

In addition to creating allowed methods, you can also edit or delete existing allowed methods, as required by changes in the web application. Simply check the box next to an existing allowed method, and click either the Edit or Delete button below the Allowed Methods section.

Working with the Navigation Parameters property

If you want the security policy to differentiate between pages in the web application that are generated by requests with the same object name but with different parameters, and to build the appropriate flows, you need to specify the exact names of the parameters that triggered the creation of theses pages in the web application. You specify these parameter names in the Navigation Parameters section.

To specify a navigation parameter

  1. On the Main tab of the navigation pane, expand the Application Security section, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List, in the Security Policy Name column, click the name of the security policy that you want to update.
    The Policy Properties screen opens.
  4. Above the Navigation Parameters area, click the Create button.
    The Create New Navigation Parameter popup screen opens.
  5. If the new navigation parameter applies to every page in the web application, select Any Object.
  6. Alternately, if the navigation parameter applies to only one page in the web application, select Object Path, and type a URL.
  7. In the Navigation Parameter box, type the name of the parameter passed to the web server for page-building purposes.
  8. Click OK.
    The popup closes, and on the Policy Properties screen, you can see the navigation parameter in the Navigation Parameters section.
  9. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.

In addition to creating navigation parameters, you can also edit or delete existing navigation parameters, as required by changes in the web application. Simply check the box next to an existing navigation parameter, and click either the Edit or Delete button below the Navigation Parameters section.

Working with the security policy entities

The security policy entities are the map of the web application. The security level of the security policy determines which entities are applicable for the security policy. (Refer to Configuring the security level , for more information on security levels.) When the Application Security Manager receives an incoming HTTP request for the web application, it compares the entities in the request to the security policy entities. If one or more entities in the request do not match the security policy entities, the system generates an alarm for the violation, and then processes the request based on the Blocking Policy settings. (See Working with the Blocking Policy settings , for more information.)

Working with the Object Types entity

The Object Types entity lists the file extensions for all of the general file types that make up the web application. The object type flags specify the legitimate behavior and properties of each object type. Additionally, the security level of the security policy affects which object type flags are relevant for the particular security policy. (See Configuring the security level , for more information.) Based on the object types list, the security policy knows which file types are legitimate for a web application, as well as how to process those file types.

Important

Object types are case-sensitive. As a result, the security policy processes JPG and jpg files as separate object types.

Table 5.2 describes the object type flags, and lists the applicable security level.

 

Table 5.2 Object type characteristics and corresponding security level
Object type flags
Description
Security Level
Check objects
Specifies, when checked, that if an incoming request contains an object of the corresponding object type, the security policy validates the specific object against the Web Objects list for the security policy. If the specific object is not in the Web Objects list, the security policy logs a violation event, and if in blocking mode, blocks the request.
Applies to high security (APC)
Check flows
Specifies, when checked, that the security policy validates the flows to web objects of the corresponding object type.
Applies to high security (APC)
Is Referrer
Specifies that the object type can include references to other object types. For example, an HTML file may contain references to image files. Therefore, the HTML file is a referrer.
Applies to high security (APC)
Object Length
Specifies the acceptable length, in bytes, for an object of this object type, in the context of an HTTP request.
Applies to all security levels
Request Length
Specifies the maximum acceptable length, in bytes, for the HTTP request that contains the object type.
Applies to all security levels
Query String Length
Specifies the maximum acceptable length, in bytes, for the query string portion of a URL that contains the object type.
Applies to all security levels
POST Data Length
Specifies the maximum acceptable length, in bytes, for the POST data of an HTTP request that contains the object type.
Applies to all security levels
Check Response
Specifies that the system validate the web server response to the incoming HTTP request that contains the object type.
Applies to all security levels

 

You can build the list of object types entities in the security policy in three ways:

Note

When you run the Policy Builder to detect object types, the system automatically creates a no_ext object type in the following cases: objects with no file extension, and objects with file extensions longer than eight characters.

To manually create an object type for a security policy

  1. On the Main tab of the navigation pane, expand Application Security, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List area, in the Security Policy Name column, click the name of a security policy.
    The Policy Properties screen opens.
  4. On the menu bar, click Object Types.
    The Object Types screen opens.
  5. Above the Object Types list, click the Create button.
    The Create New Object Type popup screen opens.
  6. In the Object Type box, type the file extension for the object. For example, to add the GIF image file type to the security policy, type GIF.
  7. Click the Get Defaults button to apply the system's default attributes for the object type. Alternately, you can specify the attributes that apply to your web application.
  8. Click Create.
    The popup closes, and on the Policy Properties screen, you can see the new object type in the Object Types Associations list.
  9. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.

Modifying object types

You can modify any of the object type flags, or characteristics, depending on the needs of the web application. For example, if you are configuring a security policy that uses the standard security level, the security policy does not perform checks on individual objects. Therefore, you can disable the Check Objects flag for all of the object types.

To modify the object type characteristics

  1. On the Main tab of the navigation pane, expand Application Security, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List area, in the Security Policy Name column, click the name of a security policy.
    The Policy Properties screen opens.
  4. On the menu bar, click Object Types.
    The Object Types screen opens.
  5. In the Object Types list, make any changes, as required, to the object type flags for the object type that you are modifying.
    The system automatically checks the Select box to the left of the object type.
  6. Click the Save button below the list.
    The system saves the changes to the security policy.
  7. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.

Removing object types

Since web applications can change on a regular basis, you may find that the object types list contains file types that are no longer used in the web application. You can remove the object type, and any related web objects (if applicable), in one step.

To remove an object type

  1. On the Main tab of the navigation pane, expand Application Security, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List area, in the Security Policy Name column, click the name of a security policy.
    The Policy Properties screen opens.
  4. On the menu bar, click Object Types.
    The Object Types screen opens.
  5. In the Object Types list, click the Select box to the left of the object type that you want to remove from the list.
  6. Click the Delete button below the list.
    The system removes the object type from the configuration, and also removes any specific web objects of this type.
  7. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.

Creating an allowed objects regular expression for an object type

You can define regular expressions that specify a group of web objects of a certain object type. If you define a regular expression for an allowed object, and the Application Security Manager does not find a requested object in the Web Objects list, the system then checks whether the object matches the regular expression in the Allowed Objects RegExp list. If the web object matches the regular expression in this list, then the Application Security Manager applies the security policy to the request's contents. If the web object does not match the regular expression in the Allowed Objects RegExp list, then the Application Security Manager generates a non-existent object alert, and performs a negative logic check. If you have enabled the Blocking flag for non-existent object violations, then the system generates an alert, and blocks the request.

Note

For more information on using regular expressions in the Application Security Manager, see Working with the negative regular expressions pool , and also see Working with the system-supplied regular expressions .

To define a regular expression for a set of possible objects

  1. On the Main tab of the navigation pane, expand Application Security, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List area, in the Security Policy Name column, click the name of a security policy.
    The Policy Properties screen opens.
  4. On the menu bar, click Object Types.
    The Object Types screen opens.
  5. On the Object Types list screen, above the Allowed Objects RegExp list, click the Create button.
    The Create New RegExp popup screen opens.
  6. In the RegExp box, type the regular expression.
  7. Optionally, in the Description box, type a description of the regular expression.
  8. Click Create.
    The popup closes, and on the Object Types screen, you can see the new regular expression in the Allowed Objects RegExp list.
  9. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.

Tip


You can validate a user-defined regular expression before you add it to the Allowed objects RegExp list. See Validating a user-defined regular expression , for more information.

Modifying an allowed objects regular expression

If you have created an allowed object regular expression, you may occasionally need to edit the regular expression.

To edit an allowed objects regular expression

  1. On the Main tab of the navigation pane, expand Application Security, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List area, in the Security Policy Name column, click the name of a security policy.
    The Policy Properties screen opens.
  4. On the menu bar, click Object Types.
    The Object Types screen opens.
  5. On the Object Types list screen, in the Allowed Objects RegExp list, check the Select box next to the regular expression that you want to edit, and then click the Edit button.
    The Edit RegExp popup screen opens.
  6. In the RegExp box, make any changes to the regular expression that are required.
  7. Optionally, in the Description box, type a description of the regular expression.
  8. Click Update.
    The popup closes, and on the Object Types screen, you can see the updated regular expression in the Allowed Objects RegExp list.
  9. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.

Removing an allowed objects regular expression

When you no longer need an allowed objects regular expression, you can easily remove the regular expression from the configuration.

To remove an allowed objects regular expression

  1. On the Main tab of the navigation pane, expand Application Security, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List area, in the Security Policy Name column, click the name of a security policy.
    The Policy Properties screen opens.
  4. On the menu bar, click Object Types.
    The Object Types screen opens.
  5. On the Object Types list screen, in the Allowed Objects RegExp list, check the Select box next to the regular expression that you want to remove, and then click the Delete button.
    A confirmation popup screen opens.
  6. Click OK.
    The popup closes, and on the Object Types screen, the regular expression is no longer in the Allowed Objects RegExp list.

Working with the Web Objects entity

The Web Objects entity lists the specific web application objects in the protected Web site. The Web Objects entity is not relevant if you are configuring a standard security policy.

An important policy decision to make at this stage is to decide whether a certain object is an entry point. If you are configuring a security policy using the simple flow mode, then most web objects should be entry points.

An entry point is a page through which a visitor can enter the web application; for example, by typing a URL in the browser's address box, or by selecting a URL from a favorites list. A web application may have several entry points.

Adding a web object

You can add web objects manually, or you can use the Policy Builder to populate the web objects. If you want to use the Policy Builder, refer to Chapter 6, Building a Security Policy With the Policy Builder , for details. If you want to add web objects manually, use the following procedure.

To add a web object manually

  1. On the Main tab of the navigation pane, expand Application Security, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List area, in the Security Policy Name column, click the name of security policy.
    The Policy Properties screen opens.
  4. On the menu bar, click Web Objects.
    The Web Application Objects (Site Map) screen opens.
  5. Above the Web Application Objects list, click the Create button.
    The Create New Object popup screen opens.
  6. In the Object Path box, type the full resource path starting with the slash [/] character.
  7. In the Protocol list, select the protocol to be used to access the object.
  8. To get the default object type associations for this web object, click the Get Defaults button.
  9. Click Create.
    The popup closes, and on the Web Objects screen, you can see the new web object in the list.
  10. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.

Removing a web object

Web applications can change over time. As such, you may need to remove obsolete web objects from the security policy.

To remove a web object

  1. In the Web Application Objects list, check the Select box to the left of the objects to be removed.
  2. Click the Remove button.
    A confirmation popup screen opens, where you confirm the deletion of the web object.
  3. Click OK.
    The popup closes, and the system removes the web object from the security policy.
  4. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.

Viewing the properties of a web object

You can review and modify the properties of an individual web object. Simply click the name of the web object in the Web Application Objects list. The Object Details screen for that object opens.

Tip


If the web object name is in gold letters, the web object is a referrer. Referrers call other web objects within the web application.

Working with the Parameters entity

A parameter is an item of information within a web application. Parameters can be configured as global parameters, web object parameters, or flow parameters. The following are a few examples of parameters: user name, address, credit card number, phone number, search boxes, and so on. See Chapter 7, Working With Parameters , for detailed information on working with parameters.

Working with the Flows entity

The application flow is the defined access path leading from one object to another object within the web application. For example, on a basic web page, you may have a graphic and a hyperlink to another page within the application. The calls to these other objects from the basic page make up the flow. Because flows can be quite complex, we recommend that you use the Policy Builder and the Learning process to help you maintain the accuracy of the flows. The Policy Builder generates a map of the flows from within the web application, by scanning the links and references within the objects. The Learning process maps new and changed flows, once the Policy Builder has initially mapped the web application. Note that you can also manually add and edit the application flows, however, we recommend that you use the automated tools to help you maintain the flows configuration.

Note

Application flows do not apply to security policies that use the standard level of security.

Viewing the entire application flow

You can view the application flow in its entirety, or you can view the flow for an individual web object. The flow mode that you set in the Flow Mode property determines the flow characteristics. See Configuring the flow mode , for more information.

To view the entire application flow

  1. On the Main tab of the navigation pane, expand Application Security, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List area, in the Security Policy Name column, click the name of the security policy whose flows you want to review.
    The Policy Properties screen opens.
  4. On the menu bar, click Flows.
    The Flows screen opens, where you can review all of the flows in the application.

Viewing the flow from a web object

When you view the flows for a particular web object, the system displays the flow from the web object. The system does not display the flow to the particular web object.

Note

If the Flow Mode is simple, then the system treats all web objects as entry points, and there is no flow information on the Flows screen for the web object.

To view the flow from an individual web object

  1. On the Main tab of the navigation pane, expand Application Security, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List area, in the Security Policy Name column, click the name of a security policy.
    The Policy Properties screen opens.
  4. On the menu bar, click Web Objects.
    The Web Application Objects screen opens.
  5. In the Select column, check the Select box for the web object whose flows you want to view, and then click the Show Flows button below the list.
    The Flows screen for the web object opens.

Adding a new application flow manually

We recommend that you use the Policy Builder and the Learning process to create and maintain the application flow. Alternately, you can create a flow for an object manually.

To manually create a flow

  1. On the Web Objects screen, in the Web Application Objects (Site Map) list, click the name of the object for which you want to create a flow.
    The Object Details screen opens.
  2. Above the Flows to Object list, click the Create button.
    The Create a New Flow popup screen opens.
  3. In the Referrer Object box, select one of the following:
    • Entry Point: Specifies that the client can enter the application from this object. Note that for most policies, objects are entry points.
    • Object Path: Specifies the URI for the object, if the object is not an entry point.
  4. In the Protocol list, select the appropriate protocol.
  5. In the Method list, select the appropriate HTTP method.
  6. In the Frame Target box, type the frame in which the web object belongs, if the web application uses frames. If you leave this option blank, the system supplies a default setting of 1.
  7. If this flow can contain a query string or POST data, check the Allow QS/PD box.
  8. If you want the system to verify query strings or POST data for this flow, check the Check QS/PD box.
  9. Click OK.
    The popup closes, and on the Object Details screen, you see the new flow in the Flows to Object list.
  10. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.

Working with the Character Sets entity

You can configure the security policy to allow only certain characters to appear in certain sections of a request. For example, you can allow letters, digits and the slash (/) in a path to an object but exclude the @ character from it. Such exclusion causes the Application Security Manager to apply the Alarm/Blocking policy to the request that contains the excluded character. Character sets are unique to each security policy, and apply to headers, object paths, parameter names, and parameter values.

Understanding the actions for the character set

You can define acceptable character sets for header values, object paths, parameter names, and parameter values. For each character and meta character within the character set, there is a corresponding action. The action determines how the system processes the character or meta character. Table 5.3 explains the character set actions, and indicates the entities to which the action applies.

 

Table 5.3 Character set actions and corresponding entities
Action
Description
Applies to
YG
The security policy allows the character or meta character wherever it occurs.
Header values, object paths, parameter names, parameter values
NG
The security policy never allows the meta character, and the Policy Enforcer generates an Illegal meta character violation when it encounters the meta character in a request.
Header values, object paths, parameter names, parameter values
Y
Note: This action has a three-part verification.
1. If the parameter is not defined in the security policy, then the Policy Enforcer allows the meta character.
2. If the parameter is defined in the security policy, and the parameter definition does not allow the meta character, then the Policy Enforcer generates an Illegal meta character in parameter value input violation.
3. If the parameter is defined in the security policy, and the parameter definition allows the meta character, then the Policy Enforcer allows the meta character.
Parameter values
N
Note: This action has a three-part verification.
1. If the parameter is not defined in the security policy, then the Policy Enforcer does not allow the meta character, and generates an Illegal meta character in parameter value violation.
2. If the parameter is defined in the security policy, and the parameter definition does not allow the meta character, then the Policy Enforcer generates an Illegal meta character in parameter value input violation.
3. If the parameter is defined in the security policy, and the parameter definition allows the meta character, then the Policy Enforcer allows the meta character.
Parameter values

 

Modifying the actions for a character set

When you set the language encoding for the web application, the Application Security Manager automatically configures a default character set. You can modify the default settings to optimize the character sets for your web application by changing the action for the characters.

To change the actions for a character set

  1. On the Main tab of the navigation pane, expand Application Security, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List area, in the Security Policy Name column, click the name of a security policy.
    The Policy Properties screen opens.
  4. On the menu bar, click Charsets.
    The Character Sets screen opens.
  5. In the Character Sets area, from the Select Character Set list, select the character set that you want to modify. When you select an option from the list, the screen refreshes to display the entire character set for that option.
  6. In the Actions area, in the Action column for each character, you can either leave the action at the default setting, or you can modify the action.
  7. Click Save to save any changes you may have made.
  8. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.

Tip


To restore the default character set definitions, you can click the Restore Defaults button at any time.

A note about non-printable characters

The Application Security Manager displays and processes non-printable characters, that is, control characters, in the same manner as it displays and processes other characters. For example, the system displays the Space character as 0x20.

Setting the active policy for a web application

At any given time, the Application Security Manager enforces only one security policy for a web application. The security policy that is currently protecting the web application is called the active security policy. The active security policy is marked with the Active icon in the Security Policies List for the web application.

To activate a security policy

  1. On the Main tab of the navigation pane, expand Application Security, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of the web application for which you are activating a security policy.
    The Web Application properties screen opens.
  3. In the Web Application Properties section, in the Active Security Policy list, select the security policy that you want to be the active security policy for the web application. Note that the system automatically checks the Apply Policy setting when you change the Active Security Policy setting on this screen.
  4. Click Update.
    The screen refreshes, and in the Security Policies List, you see the Active Policy icon next to the new active security policy.

You can also set the active security policy from most of the screens throughout the Application Security Manager. Simply click the Apply Policy button that is near the top of most screens.

Determining when to set the active security policy

Every time you change the configuration in a security policy, you must activate the security policy before the changes take effect. Throughout the Configuration utility, the following icons appear, and are there to let you know the state of a security policy.

  • The Active icon next to a security policy name indicates the active security policy. You may also see an A in square brackets [A] to indicate the active security policy. Only one security policy can be the active security policy.
  • The Modified icon next to a security policy name indicates that the security policy has been modified. You may also see an M in square brackets [M] to indicate a modified security policy.

You need to set the active security policy in the following cases:

  • Before opening the web application to any user traffic, either for testing or for regular business.
  • Every time that you make a change in the security policy. If you do not re-activate the security policy, the latest changes are not reflected to the web application.
  • Whenever you change the active security policy for a web application.

Working with the Blocking Policy settings

The Blocking Policy screen is where you configure how the security policy reacts to a request that does not comply with the security policy. The security policy has two blocking modes: transparent and blocking. In transparent mode, the system generates an alarm and allows the request, if the request violates some aspect of the security policy. In blocking mode, the system generates an alarm, does not allow the request, and instead returns the blocking response page to the client. On the Blocking Policy screen, you configure for which violations the system generates learning suggestions and alarms, and if you are using blocking mode, for which violations the system blocks the violating request. You can also set the blocking mode from the Blocking Policy screen.

Note

The blocking mode that you use determines the default Blocking Policy settings.

To set the blocking mode from the Blocking Policy screen

  1. On the Main tab of the navigation pane, expand Application Security, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application properties screen opens.
  3. In the Security Policies List, in the Security Policy Name column, click the name of the security policy for which you want to change the blocking mode.
    The Policy Properties screen opens.
  4. Next to the Security Level list, click the Edit button.
    The Blocking Policy screen opens.
  5. Clear the Disable Blocking check box to change the blocking mode to blocking. Note that when you clear this check box, the check boxes in the Block column become active.
  6. Alternately, you can check the Disable Blocking box to change the blocking mode to transparent.
  7. Click the Save button to save any changes you may have made on this screen.
  8. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.

Configuring the Learn, Alarm, and Block flags

On the Blocking Policy screen, you can view, and enable or disable, the Learn, Alarm, and Block flags for most violations. The flags determine how the system processes requests that trigger the corresponding violation. The default settings on the Blocking Policy screen are determined by the security level (see Configuring the security level , for more information about the security level).

The system takes the following actions when the flags are enabled:

  • Learn flag
    When the Learn flag is enabled for a violation, and a request triggers the violation, the system generates learning suggestions, and logs the request in the Forensic information. Note that there are some violations for which the system cannot generate learning suggestions. These violations have the Log Only notation next to the Learn flag.
  • Alarm flag
    When the Alarm flag is enabled for a violation, and a request triggers the violation, the system logs the request in the Forensic information, and also logs a security event on the Statistics >> Events screen.
  • Block flag
    When the Block flag is enabled for a violation and the security policy is in blocking mode, the system performs the Alarm flag actions when a request or response triggers the violation. Additionally, the system does not forward the request to the application, and sends the blocking response page (which contains a Support ID to identify the request) to the offending client. If a response from the web application triggers a violation for which blocking is enabled, the system sends the blocking response page to the client instead of the response.
Note

When the Block flag is enabled, the system automatically enables the Alarm flag, too.

To customize the Learn, Alarm, and Block flags for security policy violations

  1. On the Main tab of the navigation pane, expand Application Security, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application properties screen opens.
  3. In the Security Policies List, in the Security Policy Name column, click the name of a security policy.
    The Policy Properties screen opens.
  4. Next to the Security Level list, click the Edit button.
    The Blocking Policy screen opens.
  5. Review each violation adjust the Learn, Alarm, and Block flags as required.
  6. Click Save to save any changes you may have made on this screen.
  7. To put the security policy changes into effect immediately, click the Apply Policy button near the top of the screen.

How the Policy Enforcer enforces security policies

The Policy Enforcer applies the active security policy to each request for the web application. If the request complies with the security policy, the Policy Enforcer forwards the request on to the web application. If the request does not comply with the security policy, the Policy Enforcer generates a violation (or violations), and then either forwards the request or blocks the request, depending on the blocking mode of the security policy.

The Policy Enforcer can also check responses from the web application. If you enable the Check Responses setting on a object type, the system verifies that the response received from the web application matches the security policy. If the response complies with the security policy, the system sends the response to the client. If the response does not comply with the security policy, the Policy Enforcer generates the relevant violation (or violations), and then either forwards the response or blocks the response, depending on the blocking mode of the security policy.

Understanding security policy violations

The Blocking Policy screen displays all of the possible security policy violations for which the system can generate learning suggestions, generate alarms, or block requests. The violations fall into the following categories.

  • RFC violations
  • Access violations
  • Length violations
  • Input violations
  • Cookie violations
  • Negative security violations

The following sections describe the violations. For information on setting the alarms and blocking, see Configuring the Learn, Alarm, and Block flags .

Overview of RFC violations

The Application Security Manager reports RFC violations when the format of an HTTP request violates the HTTP RFCs. RFC documents are the general specifications that summarize the standards used across the internet and networking engineering community. RFCs, as they are commonly known, are published by the International Engineering Task Force (IETF). (For more information on RFCs, see http://www.ietf.org/rfc). Table 5.4 lists the RFC violations.

 

Table 5.4 RFC violation types
RFC violation types
Description
Illegal HTTP format
The format of the incoming request does not comply with the standards as specified in the RFCs for HTTP. Note that the local traffic parser may prevent certain poorly-formed requests from reaching the Application Security Manager. In these cases, the system does not generate this violation.
Non-RFC request
The request does not comply with the RFC for the HTTP protocol.
Not RFC compliant cookie
The format of the Cookie header in the request does not comply with the standards as specified in the RFCs for HTTP.

 

Important

The Application Security Manager does not generate learning suggestions for RFC violations. The system does, however, log requests that generate RFC violations in the Forensics information for the web application.

Overview of access violations

Access violations occur when an HTTP request tries to gain access to an area of a web application, and the security policy detects a reference to one or more entities that are not defined in the security policy as part of the web application. The access violations are listed in Table 5.5 .

Table 5.5 Access violation types
Access violation type
Description
Illegal entry point
The incoming request references an object that is not defined as an entry point.
Illegal flow to object
The incoming request references a flow that is not found in the security policy.
Illegal object type
The incoming request references an object type not found in the security policy.
Illegal method
The incoming request references a HTTP request method that is not found in the security policy.
Non-existent object
The incoming request references an object that is not found in the security policy.

 

Overview of length violations

Length violations occur when an HTTP request contains an entity that exceeds the length setting that is defined in the security policy.

Table 5.6 Length violation types
Length violation type
Description
Illegal cookie length
The incoming request includes a Cookie header that exceeds the acceptable length as specified in the security policy.
Illegal header length
The incoming request includes an HTTP header that exceeds the acceptable length as specified in the security policy.
Illegal object length
The incoming request references an object whose length exceeds the acceptable length as specified in the security policy.
Illegal POST data length
The incoming request contains POST data whose length exceeds the acceptable length as specified in the security policy.
Illegal query string length
The incoming request contains a query string whose length exceeds the acceptable length as specified in the security policy.
Illegal request length
The incoming request length exceeds the acceptable length as specified in the security policy.
Request length exceeds defined buffer size
The incoming request is larger than the buffer for Policy Enforcer parser.

 

Overview of input violations

Input violations occur when an HTTP request includes a parameter that contains data or information that does not match, or comply with, the security policy. Input violations most often occur when the security policy contains defined user-input parameters. Table 5.7 lists the types of input violations.

Table 5.7 Input violation types
Input violation type
Description
Failure to convert character
The incoming request contains a character that does not comply with the encoding of the web application (the character set of the security policy), and the Policy Enforcer can not to convert the character to current the encoding.
Forbidden Null in request
The incoming request contains a NULL character (0x00).
Illegal dynamic parameter value
The incoming request contains a dynamic parameter value that does not comply with the security policy
Illegal empty parameter value
The incoming request contains a parameter whose value is empty when it must contain a value.
Illegal meta character in parameter value (defined parameter)
The incoming request includes a defined parameter whose value contains a meta character that is not allowed according to the parameter's definition.
Illegal number of mandatory parameters
The incoming request contains either too few or too many mandatory parameters on a flow. Note that only flows can contain mandatory parameters.
Illegal parameter
The incoming request contains a parameter that is not defined in the security policy.
Illegal parameter data type
The incoming request contains a parameter for which the data type does not match the data type that is defined in the security policy. This data types that this violation applies to are integer, email, and phone.
Illegal parameter numeric value
The incoming request contains a parameter whose value is not in the range of decimal or integer values defined in the security policy
Illegal parameter value length
The incoming request contains a parameter whose value length does not match the value length that is defined in the security policy. Note that this violation is relevant only for user input parameters.
Illegal Query-String or POST data
The incoming request contains a query string or POST data that is not found in the security policy.
Illegal static parameter value
The incoming request contains a static parameter whose value is not defined in the security policy.
Malicious parameter value
The incoming request includes a parameter whose value contains a pattern that matches a negative regular expression (attack pattern) in the security policy.
Null in multi-part parameter value
The incoming multi-part request has a parameter value whose contains a NULL character (0x00).
Parameter value doesn't comply with regular expression
The incoming request contains an alphanumeric parameter value that does not match the expected pattern specified by the regular-expression field for that parameter.
Value too long for pattern checks
The incoming request contains a parameter value that is too long for the Policy Enforcer to apply regular expressions.

 

Note

The Policy Enforcer cannot distinguish between dynamic parameters that have been defined incorrectly, and dynamic parameters that actually contain bad values. In both cases, the system issues the Illegal parameter violation. It is up to the user to evaluate the request, to determine what caused the violation.

Overview of cookie violations

Cookie violations occur when the cookie values in the HTTP request differ from those defined in the security policy. Most of the cookie violations are related to longer client sessions. Table 5.8 lists the cookie violation types.

Table 5.8 Cookie violation types
Cookie violation type
Description
Expired timestamp
The time stamp in the HTTP cookie is old, which indicates that a client session has expired.
Illegal session ID in URL
The incoming request contains a session ID value that does not match the session ID value from a previous request from the same client.
Modified ASM cookie
The incoming request contains an Application Security Manager (ASM) cookie that has been modified or tampered with.
Modified domain cookie(s)
The domain cookies in the HTTP request do not match the original domain cookies or are not defined as allowed modified domain cookies in the security policy.
Wrong message key
The incoming request contains an ASM cookie that was created in another session.

 

Overview of negative security violations

Negative security violations occur when an incoming request contains a character that does not match the security policy's defined character set, or contains a string pattern that matches a regular expression in the security policy's negative regular expressions pool.

Note

For more information on the negative regular expressions pool, see Overview of the default negative regular expressions pool for security policies .

Table 5.9 lists the negative security violations.

 

Table 5.9 Negative security violation types
Negative security violation type
Description
Illegal HTTP status in response
The server response contains an HTTP status code that is not defined in the security policy.
Illegal meta character in header
The incoming request includes a header whose value contains a meta character that is not defined in the security policy. Note that if you accept the meta character that caused the violation, the Application Security Manager updates the character set for header values to include the meta character.
Illegal meta character in object
The incoming request includes an object that contains a meta character that is not defined in the security policy.
Illegal meta character in parameter name
The incoming request includes a parameter name that contains a meta character that is not defined in the security policy.
Illegal meta character in parameter value (< parameter)
The incoming request includes a parameter that is not defined in the security policy, and whose value contains a meta character that is not allowed, according to the security policy character set.
Illegal pattern in header value
The incoming request includes a header whose value contains a pattern that matches a negative regular expression (attack pattern) in the security policy.
Illegal pattern in object
The incoming request includes an object that contains a pattern that matches a negative regular expression (attack pattern) in the security policy.
Illegal pattern in parameter=value pairs
The incoming request includes a parameter and value, which together contain a pattern that matches a negative regular expression (attack pattern) in the security policy
Illegal pattern in response
The HTTP response contains a pattern that matches a negative regular expression (attack pattern) in the security policy.

 

Maintaining a security policy

Security policies can change and evolve over time. As the nature of the web traffic through the web application changes, you adjust the security policy as required. Several options exist to facilitate the maintenance of the security policy. You have the option to:

  • Copy a security policy
  • Export a security policy
  • Import a security policy
  • Merge two security policies
  • Remove a security policy
  • Restore a deleted a security policy
  • View the history of a security policy

Editing an existing security policy

Editing a security policy is an efficient way to update the security policy over time. The easiest way to access a security policy for editing is from the Web Application properties screen.

To choose a security policy to edit from the Web Application properties screen

  1. On the Main tab of the navigation pane, expand Application Security, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of the web application for which you want to restore the security policy.
    The Web Application properties screen opens.
  3. In the Security Policies List, click the name of the security policy that you want to edit.
    The Policy Properties screen opens.
  4. Make any changes that are required.
Important

Remember that if you make any configuration changes in the security policy, the changes do not take effect until you set the active policy. See Setting the active policy for a web application for more information.

Copying a security policy

You can copy a security policy to quickly duplicate policies or create policies that differ only in a few details.

Note

When you copy a security policy, the system does not export the data from the Policy Builder log. See Working with the Policy Builder log for information on the Policy Builder log.

To copy a security policy

  1. On the Main tab of the navigation pane, expand Application Security, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of the web application for which you want to restore the security policy.
    The Web Application properties screen opens.
  3. In the Security Policies List, select the security policy that you want to copy, and click the Copy button below the list.
    The Copy Policy screen opens.
  4. In the New Security Policy Name box, type a name for the security policy, and then click Copy.
    The system displays a success message when the copy is completed.
  5. Click OK.
    The screen refreshes, and you see the new security policy in the Security Policies List.
Important

In the Security Policies List, the Active icon next to a security policy indicates that this policy is active. The Modified icon indicates that the security policy has been modified, and you must click the Set Active Policy button to implement any changes in the security policy.

Exporting a security policy

There are different reasons for exporting a security policy. For example, you may want to export a security policy for one web application so that you can use the exported policy as a baseline for a new web application. You can also export a security policy to archive it on a remote system before you upgrade the system software, to create a backup copy, or to use the exported security policy in a policy merge. (See Merging two security policies , for more information on merging policies.)

Note

When you export a security policy, the system does not export the data from the Policy Builder log. See Working with the Policy Builder log for information on the Policy Builder log.

To export a security policy

  1. On the Main tab of the navigation pane, expand Application Security, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of the web application for which you want to restore the security policy.
    The Web Application properties screen opens.
  3. In the Security Policies List, select the security policy that you want to export, and click the Export button below the list.
    A file download screen opens.
  4. Click Save.
    A Save As popup screen opens.
  5. Navigate to the remote location where you want to save the security policy, and click Save.
    The system exports the security policy and saves it in the remote location.

Merging two security policies

You can use the policy merge option to combine two security policies. For example, you can use the policy merge option to merge a security policy that you have built offline into a security policy that is on a production system.

The merge mechanism is somewhat lenient when it merges the second security policy into the first security policy. The merge action does not delete anything from the target security policy. Where there are conflicts, the system retains the setting of the target security policy. If there are unresolved conflicts, the system reports them in the Merge Report. The Merge Report contains the following information about the merge:

  • The number of records added to the target security policy from the merged security policy
  • Any conflicts that occurred and their resolution
  • A list of unresolved conflicts

If you enable verbose logging for the merge, the Merge Report also contains the following information:

  • Entities that are in the target security policy only
  • Entities in the target security policy whose values are different from those in the merged security policy (If this occurs, the system does not change the target security values.)

Once the merge is complete, you have the option of saving the Policy Merge Report as a text file (*.txt), so that you can review the details of the merge, and resolve any conflicts, or errors, that may have occurred.

To merge two security policies

  1. On the Main tab of the navigation pane, expand Application Security, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of the web application for which you want to restore the security policy.
    The Web Application properties screen opens.
  3. In the Security Policies List, select the security policy that is the target security policy (the one into which the system merges the second security policy), and click the Merge button below the list.
    The Merge Policies screen opens.
  4. In the Merge Policies area, for the Policy To Be Merged setting, either type a path, or click the Browse button, and navigate to the file that you want to merge into the target security policy.
  5. If you want to save a pre-merge copy of the target security policy, check the Backup Target Policy setting.
  6. If you want the merge action to include additional details about the merge, check the Verbose Mode setting.
  7. Click the Merge button.
    The system merges the second security policy into the target security policy, and produces the Merge Report.
  8. Click the Download Full Report button to open or save the entire Merge Report.

Importing a security policy

You can import a security policy to quickly apply a security policy to a new web application. You can also use the import option to restore a security policy from a remote system.

To import a security policy

  1. On the Main tab of the navigation pane, expand Application Security, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of the web application for which you want to import a security policy.
    The Web Application properties screen opens.
  3. Below the Security Policies List, click the Import button.
    The Import Policy screen opens.
  4. In the Choose File box, type the path to the security policy that you want to import. Alternately, click the Browse button and navigate to the security policy that you want to import.
  5. Click Import.
    The system displays a success status message when the operation is complete.
  6. Click OK.
    The screen refreshes, and the imported security policy is in the Security Policies List.
Important

The names of security policies must be unique within the Application Security Manager. If the imported policy already exists in the current the Application Security Manager environment, the system renames imported security policy by adding a sequential number to the end of the name.

Deleting a security policy

You can delete a security policy from the configuration, provided that the security policy is not active.

To delete a security policy

  1. On the Main tab of the navigation pane, expand Application Security, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of the web application for which you want to delete a security policy.
    The Web Application properties screen opens.
  3. In the Security Policies List, select the security policy that you want to delete, and click the Delete button below the list.
    A confirmation popup screen opens, to confirm that you want to delete the security policy.
  4. Click OK
    The screen refreshes and you no longer see the security policy in the Security Policies List.
Important

You cannot remove a security policy that is currently active. The active policy for a web application has the Active icon next to the name in the Security Policies List.

Restoring a deleted security policy

If you delete a security policy, and later decide that you did not want to do that, you can restore the security policy from the Policy Recycle Bin.

To restore a security policy

  1. On the Main tab of the navigation pane, expand Application Security, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of the web application for which you want to restore the security policy.
    The Web Application Properties screen opens.
  3. Below the Security Policies List, click the Import button.
    The Import Policy screen opens.
  4. In the Policy Recycle Bin list, select the security policy that you want to restore, and then click the Restore button.
    A confirmation popup screen opens, where you confirm that you want to restore the security policy.
  5. Click Restore.
    The system restores the security policy, and displays a success message.
  6. Click OK.
    The screen refreshes, and you see the restored security policy in the Policies List.

Viewing and restoring an archived security policy

The Application Security Manager keeps an archive of security policies that have been set to active. Every time you make a security policy the active security policy, the system saves a version of that security policy, and archives it. The system retains up to fifty archived versions. You can restore any of the archived security policies, and make it the active security policy.

Tip


In the Security Policies List, on the Web Application Properties screen, the security policy version number is in square brackets next to the security policy name.

To view and restore an archived security policy

  1. On the Main tab of the navigation pane, expand Application Security, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of the web application for which you want to restore the security policy.
    The Web Application Properties screen opens.
  3. Below the Security Policies List, click the History button.
    The History for policy <policy_name> screen opens, where you can see version history for the security policy.
  4. If you want to restore an archived security policy, select the version, and then click the Restore button below the list.
    The Restore Policy <policy_name> As popup screen opens.
  5. In Security Policy Name box, change the name as required.
  6. If you do not want the restored security policy to be immediately active, clear the Apply Policy box.
  7. Click OK.
    The popup screen closes, and on the Web Applications Properties screen, you see the restored security policy in the Security Policies List area.

Viewing the security policy using the security policy audit tools

Since viewing all the security policy in one screen is quite impossible, the Application Security Manager includes several audit tools that enable you to query a security policy in order to find the information you are looking for. Some of these audit tools can be used to analyze suspicious policy states (for example, an object without flows, or parameters with zero length). Each report isolates a pre-defined state, and helps you identify conflicts and errors in the security policy.

To use the security policy audit filters

  1. On the Main tab of the navigation pane, expand Application Security, and then click Web Applications.
    The Web Applications list screen opens.
  2. In the Name column, click the name of a web application.
    The Web Application Properties screen opens.
  3. In the Security Policies List area, in the Security Policy Name column, click the name of a security policy.
    The Policy Properties screen opens.
  4. Click Audit Tools on the menu bar.
    The Policy Audit Tools screen opens.
  5. From the Tool Type list, select an audit tool, and then click Go.
    The screen refreshes, and the system displays the information according to the audit tool properties.



Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)