Manual Chapter : Managing Application Security Policies in Web Application Security

Applies To:

Show Versions Show Versions

BIG-IQ Centralized Management

  • 7.0.0
Manual Chapter

Managing Application Security Policies in Web Application Security

About application security policies in Web Application Security

Web Application Security imports BIG-IP Application Security Manager (ASM) application security policies from discovered BIG-IP devices, and lists them on the Web Application Security policy editor Policies screen. Each security policy is assigned a unique identifier that it carries across the enterprise. This ensures that each policy is shown only once in the Policies screen, no matter how many devices it is attached to. In the Web Application Security repository, policies are in XML format.

About subcollections in policies

Subcollections
are groups of like objects related to the Web Application Security policy. Not all subcollections are visible in the Web Application Security policy editor. Other subcollections can be imported and deployed without being displayed. Generally, you can import subcollections from a BIG-IP device and then deploy them without editing. Note that you cannot manage wildcard ordering for subcollections using the BIG-IQ Centralized Management user interface.
Following is a list of the supported versions of the BIG-IQ Centralized Management system and the BIG-IP device for each subcollection. Refer to the release notes for BIG-IQ Centralized Management for detailed information on BIG-IP device and BIG-IQ Centralized Management system support, such as the minimum F5 TMOS® version supported for this release.
Subcollection
Discovery and Deployment Support
Edit Support using BIG-IQ GUI
Minimum BIG-IP Device Version Support
Comments
Policy and properties
Yes
Yes
Any
Character Sets
Yes
Yes
Any
The BIG-IQ Centralized Management user interface can be used to edit parameter names and parameter values.
Data Guard
Yes
Yes
Any
File Types
Yes
Yes
Any
IP Address Exceptions
Yes
Yes
Any
Parameters
Yes
Yes
Any
Extractions
Yes
Yes
11.6.0
Response Pages
Yes
Yes
Any
Learning using the Central Policy Builder is not applicable for use with response pages.
Signatures
Yes
Yes
Any
Signature Sets and attack signature configuration
Yes
Yes
Any
Filter-based sets are supported, manual sets are not.
Blocking settings - violations
Yes
Yes
Any
No support for user defined violations.
Blocking settings - evasions
Yes
Yes
Any
Blocking settings - HTTP protocol compliance
Yes
Yes
Any
Blocking settings - web services securities
Yes
Yes
Any
Policy Builder
Yes
Yes
Any
Learning using the Central Policy Builder is not applicable for use with the local Policy Builder.
Central Policy Builder
Yes
Yes
13.1.0
Learning using the Central Policy Builder is not supported with GWT content profiles, and is non-applicable for response pages, local policy builder, web scraping, and brute force attack prevention.
Allowed methods
Yes
Yes
Any
Headers
Yes
Yes
Any
Cookies
Yes
Yes
Any
Host names
Yes
Yes
Any
Geolocation enforcement
Yes
Yes
11.6.0
IP Intelligence
Yes
Yes
11.6.0
Redirection protection
Yes
Yes
11.6.0
Sensitive parameters
Yes
Yes
Any
Web scraping
Yes
No
12.0.0
Learning using the Central Policy Builder is not applicable for use with web scraping.
CSRF protection
Yes
Yes
11.6.0
When editing policies deployed to BIG-IP device versions earlier than 13.1, URLs added to the CSRF URLs list must have the following settings:
  • Method
    setting of
    Any
  • Enforcement Action
    setting of
    Verify CSRF Token
  • Required Parameters
    setting of
    At Least One
JSON Content Profiles
Yes
Yes
11.6.0
XML Content Profiles
Yes
Yes
11.6.0
Schemas and WSS are not supported.
GWT Content Profiles
Yes
No
11.6.0
Learning using the Central Policy Builder is not supported with GWT content profiles.
Plain Text Content Profiles
Yes
Yes
12.1.0
URLs
Yes
Yes
Any
Flow configuration for URLs is not supported, such as referrer, check flows, check pd/qa, allow pd/qs, or isEntryPoint.
Websocket URLs
Yes
Yes
12.1.0
Login Pages
Yes
Yes
11.6.0
Login Enforcement
Yes
Yes
11.6.0
Brute Force Attack Preventions
Yes
Yes
11.6.0
Learning using the Central Policy Builder is not applicable for use with brute force attack prevention.
Session Tracking Configuration
Yes
Yes
11.6.0
Only configuration is supported, there is no support for online tracking data.
Layered Policy
Yes
Yes
13.0.0
Inheritance Settings
Yes
Yes
13.0.0
Enforcement Readiness
Yes
Yes
Any
Server Technologies
Yes
Yes
13.1.0

Overview of layered policies and inheritance

You can use Web Application Security to create and manage two layers of security policies: parent policies and child policies. This feature is new with BIG-IP version 13.0 and BIG-IQ Centralized Management version 5.2. Parent policies include mandatory policy elements, and child policies inherit those attributes from the parent. When the parent policy is updated, the associated child policies are automatically updated.
With parent policies you can:
  • Create and maintain common elements and settings.
  • Impose mandatory elements on child policies.
  • Push a change to multiple child policies.
You can specify which parts of the security policy must be inherited, which are optional, and which are not inherited. This allows you to keep child policies synchronized with the changes in the global mandatory policies and still allow the child policies to address their own unique requirements.
You establish the parent and child policy relationship as follows:
  1. Identify the current policy as a parent policy.
    On the General Properties screen for the policy, set the
    Policy Type
    to
    Parent Policy
    . Navigate to
    Configuration
    SECURITY
    Web Application Security
    Policies
    , then click the policy to edit, and click
    POLICY PROPERTIES
    General Properties
  2. Set a policy to be the child policy of the parent policy.
    On the Inheritance Settings screen for the policy, select the parent policy for a child policy by selecting the parent policy name in the
    Parent Policy
    setting. Navigate to
    Configuration
    SECURITY
    Web Application Security
    Policies
    , then click the policy to become a child policy and click
    POLICY PROPERTIES
    Inheritance Settings
    .
  3. Click
    Save
    to save this policy as a child policy and display the inheritance properties.
  4. Continue to use the Inheritance Settings screen to accept or decline what is to be inherited from the parent policy.
By default, the
Parent Policy
field is set to
None
, and there is no layered policy use (no child or parent policies).
Refer to the
BIG-IP Application Security Manager: Getting Started
guide for additional information on using parent and child layered policies.

How do I determine what permissions to apply to roles accessing child and parent policies?

When adding or modifying the role type permissions associated with a Web Application Security policy, you need to be aware of whether the policy is a standalone policy without inheritance, a parent policy, or a child policy. You define access to policies using the New Role Type properties screen.
  1. Click
    System
    ROLE MANAGEMENT
    Custom Role Types
    .
  2. Click
    Add
    . The New Role Type properties screen opens.
  3. Select Web Application Security (ASM) as the service. Those object types are displayed.
  4. Select
    Policies: Web Application Security
    as the object type, and click
    Add Selected
    .
  • To define access to standalone policies that do not use inheritance, select from the permissions without the Child or Parent prefix: Read, Add, Edit, or Delete.
  • To define access to only child policies, select permissions with the Child prefix: Child Create, Child Delete, or Child Edit.
  • To define access to only parent policies, select permissions with the Parent prefix: Parent Create, Parent Delete, or Parent Edit.
If you assign general permissions (Read, Add, Edit, or Delete) to a child or parent policy, you are assigning access to both parent and child policies. For example, assigning the Delete permission to a role allows that role to delete standalone policies, parent policies, and child policies. But, assigning the Child Delete permission to a role allows that role to delete only child policies, and not parent or standalone policies.
Regardless of the type of policy, you should always allow users Read access to the policy.

Overview of central policy building

Central Policy Builder can predict how to best fine-tune your web application security policy that is shared over multiple BIG-IP devices. You can use the Central Policy Builder feature to perform traffic learning, by receiving the ASM traffic log messages, for the all the policy's BIG-IP devices, and consolidating the traffic learning suggestions.
How the Central Policy Builder works:
  • Each BIG-IP device sends learning suggestions for a particular policy to the BIG-IQ data collection devices (DCD).
    When enabling policy building, it is recommended to that you have an ASM log profile that logs all requests. This allows you to review the requests that may have triggered a policy suggestion.
  • The policy learning suggestions from all BIG-IP devices are combined so that you can view and manage them on the BIG-IQ Centralized Management system.
  • As suggestions are accepted, and the policy is tuned, you can choose to deploy the policy to one or more of the BIG-IP devices configured to use that policy.

About automatic deployments with central policy building

You might see deployments named
Auto-Deploy of policies
in the list of Web Application Security deployments. Automatic policy deployments occur when you have these policy building settings:
  • You have enabled centralized policy building by setting the
    Policy Building Mode
    setting to
    Central
    .
  • You have enabled automatic deployment by setting the
    Auto-Deploy Policy
    setting to
    Real Time
    or
    Scheduled
    .
The BIG-IQ system purges successful automatic deployments from the list of deployments after an hour, and retains failed deployments for a week so that the failure can be resolved if needed. If the deployment task has nothing to deploy, the BIG-IQ system purges it from the list immediately after finishing.

Configuring central policy building

To configure and use central policy building, you need:
  • A BIG-IP version 13.1 or later device with ASM provisioned and licensed.
  • A BIG-IQ Web Application Security service installed and the BIG-IP device discovered and imported.
  • Data collection devices (DCD) configured to your BIG-IQ.
  • (Recommended) BIG-IP devices are attached to an Application Security logging profile configured to store all requests. This allows you to review any request that triggered a policy suggestion. To view the status of your logging profile, go to
    Configuration
    SECURITY
    Shared Security
    Logging Profiles
    , and select the logging profile configured for application security. Ensure that the
    Request Type
    field in the Storage FIlter area is set to
    All Requests
    .
You use central policy building to combine policy learning suggestions from multiple BIG-IP devices to have more sources for policy suggestions. You configure central policy building by configuring both the data collection devices and the policies that will use central policy building.
  1. Configure the data collection devices to be used to collect suggestions from BIG-IP devices.
    1. Click
      System
      BIG-IQ DATA COLLECTION
      BIG-IQ Data Collection Devices
      .
    2. Click the name of the data collection device you want to use for central policy building.
      The data collection device properties screen opens.
    3. On the left, click
      Services
      , and then on the right, in the Web Application Security area, for the
      Activate Service
      setting, click
      Activate
      .
    4. Save your work.
    5. Repeat this process for each data collection device you want to use for central policy building.
  2. Verify that learning mode is enabled in the Web Application Security policy.
    Learning mode must be enabled when using either local or centralized policy building.
    1. Click
      Configuration
      SECURITY
      Web Application Security
      Policies
      .
    2. Click the name of the policy you want to use with central policy building, and then on the left click
      POLICY PROPERTIES
      General Properties
      .
      The general properties screen opens.
    3. For the
      Learning Mode
      setting, select either
      Automatic
      or
      Manual
      if one is not already selected.
    4. If you made any changes, save your work.
  3. Enable centralized policy building for the Web Application Security policy.
    1. Click
      Configuration
      SECURITY
      Web Application Security
      Policies
      .
    2. Click the name of the policy you want to use with central policy building, and then on the left click
      POLICY BUILDING
      Settings
      .
      The Settings screen opens.
    3. For the
      Policy Building Mode
      setting, select
      Central
      .
      When local policy building is configured, this value is set to
      Local
      .
    4. Save your work.
    5. Repeat this process for each policy that you want to use with central policy building.
Central policy building is now enabled for this policy.

Edit application security policies

You modify application security policies to customize how they protect your web application server. Application security policies can be created in Web Application Security. But more often, they are created on BIG-IP devices and come into the Web Application Security configuration when you discover the devices.
  1. Navigate to the Policies screen: click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of a policy you want to edit.
    The policy is placed under administrative lock. Policy objects that you can view or edit are listed on the left.
  3. Edit the properties of each policy object as needed.
    Consult the documentation for each policy object to edit it individually.
  4. Click
    Save
    to save the modifications to each object and unlock the policy.
Changes to the policy object are saved in the working configuration of the BIG-IQ Centralized Management system. Assuming the policy is assigned to a virtual server, the next deployment sends the new configuration to one or more BIG-IP devices.

Edit general property settings

Application security policies are often created on BIG-IP devices and come into the BIG-IQ Web Application Security configuration when you discover the devices. You can view and modify the properties of individual application security policies.
  1. Go to the General Properties screen: click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the policy to modify, and then on the left click
    General Properties
    .
  3. Edit the properties as appropriate.
  4. Save your changes to the general properties of the policy.
The system saves changes in the working configuration of the BIG-IQ Centralized Management system.

General property settings

These properties are the general configuration options and settings that determine the overall behavior and functionality of the application security policy.
Property
Description
Name
Unique name of the security policy. You can set the
Name
only when you create the policy.
Partition
Partition to which the security policy belongs. Only users with access to a partition can view the objects that it contains. If the policy resides in the
Common
partition, all users can access it.
Description
Optional description of the security policy. Type in any helpful details about the policy.
This field is limited to 255 characters.
Full Path
Full path to the security policy.
Policy Type
Indicates the type of policy.
  • Security Policy
    specifies a policy that does not use inheritance, or that uses inheritance and is a child policy.
  • Parent Policy
    specifies a policy that uses inheritance, and is a parent policy.
Parent Policy
Specifies the parent policy associated with this policy, if any.
  • Select
    None
    to indicate that there is no parent policy.
  • Select the appropriate parent policy from the list if there is a parent policy.
Application Language
A language encoding for the web application, which determines how the security policy processes the character sets. The default language encoding determines the default character sets for URLs, parameter names, and parameter values.
Security Policy is case sensitive
If enabled, the security policy treats file types, URLs, and parameters as case-sensitive. When this setting is disabled (not checked), the system stores these policy elements in lowercase in the policy configuration.
Application Templates
Specifies options for using the policy with application templates.
  • To make this policy the default for application templates, select
    Default Policy for Application Templates
    .
  • To make this policy available to application templates, select
    Make available in Application Templates
    .
A default policy for application templates is provided with the BIG-IQ system named
templates-default
.
Event Correlation Reporting
If enabled, events are reported in groups (correlated), rather than as individual transactions. You can only disable this setting for BIG-IP devices version 13.1 or later.
Learning Mode
Select one of the options to indicate how the policy learns:
  • Automatic
    : The system examines traffic, makes suggestions, and enforces most suggestions after sufficient traffic over a period of time from various users make it reasonable to add them. A few suggestions must be enforced manually.
  • Manual
    : The system examines traffic and makes suggestions on what to add to the security policy. You manually examine the changes and accept, delete, or ignore the suggestions.
  • Disabled
    : The system does not do any learning for the security policy, and makes no suggestions.
Enforcement Mode
Specifies how the system processes a request that triggers a security policy violation.
  • Transparent
    specifies that when the system receives a request that violates a policy parameter, the system logs the violation event, but does not block the request.
  • Blocking
    specifies that when the system receives a request that violates a policy parameter, the system logs the violation event, blocks the request, and responds to the request by sending the Blocking Response page and Support ID information to the client.
Enforcement Readiness Period
Indicates the number of days in the period. The default is 7 days.
Both security policy entities and attack signatures remain in staging mode before the system suggests you enforce them. The system does not enforce policy entities and attack signatures in staging. Staging allows you to test the policy entities and the attack signatures for false positives without enforcing them.
Mask Credit Card Numbers in Request Log
When enabled, they system masks credit card numbers in the request log. If disabled (cleared), credit card numbers are not masked.
Maximum HTTP Header Length
Specifies the maximum length of an HTTP header name and value that the system processes. The default setting is 8192 bytes. The system calculates and enforces the HTTP header length based on the sum of the length of the HTTP header name and value. To specify a value for length, type a different value in the field. To specify that any length is acceptable, clear the field. An empty field (a value of any) indicates that there are no restrictions on the HTTP header length up to 8192 bytes.
Maximum Cookie Header Length
Specifies the maximum length of a cookie header name and value that the system processes. The default setting is 8192 bytes. The system calculates and enforces a cookie header length based on the sum of the length of the cookie header name and value. To specify a value for length, type a different value in the field. To specify that any length is acceptable, clear the field. An empty field (a value of any) indicates that there are no restrictions on the cookie header length up to 8192 bytes.
Allowed Response Status Code
Specifies which requests the security policy permits, based on the HTTP response status codes they return. Click the gear icon to add or delete response codes.
Dynamic Session ID in URL
Specifies how the security policy processes URLs that use dynamic sessions. Click the gear icon to change the setting or create a custom pattern.
  • Disabled
    : The policy does not enforce dynamic sessions in URLs.
  • Default pattern
    : The policy uses the default regular expression for recognizing dynamic sessions in URLs. The default pattern is (\/sap\([^)]+\)). Note that you cannot edit the default regular expression.
  • Custom pattern
    : Specifies a user-defined regular expression that the security policy uses to recognize dynamic sessions in URLs. Type an appropriate regular expression in the
    Value
    field, and a description in the
    Description
    field.
Trigger ASM iRule Events
When enabled, specifies that Web Application Security activates ASM iRule events. Specifies, when disabled, that Web Application Security does not activate ASM iRule events. The default setting is disabled. Leave this option disabled if you either have not written any ASM iRules® or have written iRules that are not ASM iRules. iRule events that are not ASM are triggered by the Local Traffic Manager. Enable this option if you have written iRules that process ASM iRule events, and assigned them to a specific virtual server.
Trust XFF Header
When set to
No
(the default), specifies that the system does not have confidence in an XFF (X-Forwarded-For) header in the request. Leave this option disabled if you think the HTTP header may be spoofed, or crafted, by a malicious client. With this setting disabled, if Web Application Security is deployed behind an internal proxy, the system uses the internal proxy’s IP address instead of the client’s IP address. If Web Application Security is deployed behind an internal or other trusted proxy, you can click the gear icon to change the setting and specify that the system has confidence in an XFF header in the request.
Select the
Trust XFF Headers
check box and add a required custom header (use a-z, A-Z, no whitespace allowed). The system then uses the IP address that initiated the connection to the proxy instead of the internal proxy’s IP address.
Handle Path Parameters
Specifies how the system handles path parameters that are attached to path segments in URIs.
  • As parameter
    : The system normalizes and enforces path parameters. For each path parameter, the system removes it from URLs as part of the normalization process, finds a corresponding parameter in the security policy (first at the matching URL level, and if not found, then at the global level), and enforces it according to its attributes like any other parameters.
  • As URL
    : The system does not normalize nor enforce path parameters. Path parameters are considered an integral part of the URL.
  • Ignore
    : The system removes path parameters from URLs as part of the normalization process, but does not enforce them.
    The maximum number of path parameters collected in one URI path is 10. All the rest of the parameters (from the eleventh on, counting from left to right) are ignored as parameters, but are still stripped off the URI as part of the normalization process.
    Path parameters are extracted from requests, but not extracted in responses.

Edit inheritance settings

You use the Inheritance Settings screen to change the properties that are part of a policy by editing the inheritance settings of a child or parent policy.
  1. Navigate to the Inheritance Settings screen: click
    Configuration
    SECURITY
    Web Application Security
    Threat Campaigns
    .
  2. Click the appropriate policy name to display the policy properties screen.
  3. Click
    Inheritance Settings
    .
  4. Review or modify the inheritance settings.
    The contents of this screen differ depending on whether the policy is a parent policy, a child policy, or neither.
  5. If the current policy is neither a parent policy nor a child policy, the
    Parent Policy
    list is set to
    None
    , and no other properties are shown on the screen.
  6. If the current policy is a child policy or will be a child policy, do the following.
    1. From the
      Parent Policy
      list, review or select a parent policy. By default, the setting is
      None
      .
    2. Review the list of properties that are displayed, and where needed, select
      Accept
      or
      Decline
      .
    3. Optionally, you can add comments about the inheritance settings by clicking the comment icon in the Comments column and then typing text in the space provided.
  7. If the current policy is a parent policy, do the following.
    • In the Inheritance column, review or change the inheritance settings for each property in each property row.
      • If the property must be inherited by a child policy, click
        Mandatory
        .
      • If the property is optional for a child policy, click
        Optional
        .
      • If the property is not available to the child policy, click
        None
        .
    • The Accepted, Declined, Unread, and Comments columns show the number of child policies for each category for that property. Optionally, you can click the number to display additional information on the Child Policy Overview screen.
  8. Click
    Save
    to save your changes.
The inheritance settings for the policy are updated.

Edit child policy overview settings

You can edit the inheritance settings for child policies associated with a parent policy. A parent policy can be associated with multiple child policies.
  1. Navigate to the Child Policy Overview screen: click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the policy you want to review, and click
    Child Policy Overview
    .
  3. Review the inheritance settings for child policies associated with the parent policy.
    • Click
      All
      to view all properties that could be inherited by a child policy.
    • Click
      Declined
      to view only the properties that a child policy declined to inherit.
  4. Expand each policy section in the list to review the inheritance status (declined or accepted) for each child policy.
  5. Indicate whether you have reviewed declined inheritance properties. In the Policy Section row for a child policy property:
    • Click
      Mark as Read
      to indicate that you have reviewed a declined property for a child policy.
    • Click
      Mark as Unread
      to indicate that you have not reviewed a declined property for a child policy.
    • Click
      Mark All as Read
      to indicate that you have reviewed all declined properties within that heading.
    • To enter a comment, click the comment icon in the row. To remove all comments in a section, click
      Clear All
      in the heading row for a policy section.
  6. Click
    Save
    to save your changes.
The child policy overview is updated.

Response page editing

You can review and change the settings on various types of response pages. Response page settings specify the response content that the system sends to the user when the security policy blocks a client request.

Edit Ajax response page settings

You use the Ajax Response Page screen to view and edit the settings for the Ajax response page, which is one of several response pages. Response page settings specify the content of the response that the system sends to the user when the security policy blocks a client request.
  1. Go to the Ajax Response Page screen: click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click a policy name, and then click
    RESPONSE PAGES
    Ajax
    .
  3. In the
    AJAX Blocking
    setting, click the
    Enabled
    check box to view and edit settings.
    When this is checked (enabled), the system injects JavaScript code into responses.
    You must enable this check box to configure an ASM Ajax response page which is returned when the system detects an Ajax request that does not comply with the security policy.
  4. From the
    Default Response Page Action
    list, select an action. Your selection determines the settings.
    Popup Message
    The screen displays a sample pop up message which you can edit. Click
    Preview On
    to preview the response.
    Custom Response
    The screen displays the default response page which you can edit to create a custom response. Alternatively, you can upload the response.
    • You click
      Choose File
      to select the file containing the response, and then click
      Upload
      to insert it.
    • Click
      Preview On
      to preview the response.
    • If you want to return to the original default response text, click
      Paste Default Response Body
      .
    Redirect URL
    The system redirects the user to a specific web page instead of displaying a response page. You must enter a URL for the redirect.
  5. In the
    Login Page Response Action
    list, select an action.
    Your selection determines the settings. The actions are the same as those for the
    Default Response Page Action
    list.
  6. In the
    Failed Login Honeypot Page Response Action
    list, select an action.
    Your selection determines the settings. The actions are the same as those for the
    Default Response Page Action
    list.
  7. When you are finished, save your changes.
The response page settings are updated.

Edit CAPTCHA response page settings

You use the CAPTCHA Response Page screen to view and edit the settings for CAPTCHA responses. Response page settings specify the response content that the system sends to the user when the security policy blocks a client request.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click a policy name, on the next screen, on the left click
    Response Pages
    and then for the Response Pages type, click
    CAPTCHA Fail
    .
  3. For the
    Response Type
    setting, specify whether to use the default or a custom response.
    • To use the displayed response header and response body, select
      Default Response
      .
    • To use a modified response header or response body, select
      Custom Response
      .
    Selecting
    Custom Response
    makes editing options available.
  4. In the
    Response Header
    setting, review or change the response header.
    • If you selected the default response type, you can review but not modify the response header.
    • If you selected the custom response type, you can modify the response header by editing the header text.
    • To replace your modifications with the default response header, click
      Paste Default Response Header
      .
  5. For the
    Response Body
    setting, review or change the response body.
    • If you selected the default response type, you can review but not modify the response body.
    • If you selected the custom response type, you can modify the response body by editing the body text directly or by importing a file with that text. To import the response body:
      1. Click
        Choose File
        .
      2. In the displayed Open dialog box, select the file to import and click
        Open
        . The Open dialog box closes.
      3. Click
        Upload
        . The contents of the file are now in the response body text box.
    • To replace your modifications with the default response body, click
      Paste Default Response Body
      .
  6. For the
    Preview
    setting, specify whether to see a preview of the response body.
    • To see a preview of how the response is displayed, click
      Preview On
      .
    • To skip the preview, click
      Preview Off
      .
  7. When you are finished, save your changes.

Edit CAPTCHA fail response page settings

You use the CAPTCHA Fail Response Page screen to view and edit the settings for CAPTCHA Fail responses. Response page settings specify the response content that the system sends to the user when the security policy blocks a client request.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click a policy name, on the next screen, on the left click
    Response Pages
    and then for the Response Pages type, click
    CAPTCHA Fail
    .
  3. For the
    Response Type
    setting, specify whether to use the default or a custom response.
    • To use the displayed response header and response body, select
      Default Response
      .
    • To use a modified response header or response body, select
      Custom Response
      .
    Selecting
    Custom Response
    makes editing options available.
  4. For the
    Response Header
    setting, review or change the response header.
    • If you selected the default response type, you can review but not modify the response header.
    • If you selected the custom response type, you can modify the response header by editing the header text.
    • To replace your modifications with the default response header, click
      Paste Default Response Header
      .
  5. For the
    Response Body
    setting, review or change the response body.
    • If you selected the default response type, you can review, but not modify, the response body .
    • If you selected the custom response type, you can modify the response body by editing the body text directly or by importing a file with that text. To import the response body:
      1. Click
        Choose File
        .
      2. In the displayed Open dialog box, select the file to import and click
        Open
        . The Open dialog box closes.
      3. Click
        Upload
        . The contents of the file are now in the response body text box.
    • To replace your modifications with the default response body, click
      Paste Default Response Body
      .
  6. In the
    Preview
    setting, select whether to see a preview of the response body.
    • To see a preview of how the response is displayed, click
      Preview On
      .
    • To skip the preview, click
      Preview Off
      .
  7. When you are finished, save your changes.

Edit default response page settings

You use the Default Response Pages screen to view and edit the settings for the default response page, which is one of several response pages. Response page settings specify the content of the response that the system sends to the user when the security policy blocks a client request.
  1. Go to the Default Response Page screen: click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click a policy name, and then click
    RESPONSE PAGES
    Default
    .
  3. Select a
    Response Type
    from the list. Your selection determines the additional settings.
    Default Response
    The screen displays the default response header and response body. The system sends the response body to the client as shown. You cannot edit these fields. Click
    Preview On
    to preview the response.
    Custom Response
    The screen displays the default response header and response body which you can edit to create a custom response. Alternatively, for the response body, you can upload a response.
    • Click
      Choose File
      to select the file containing the response body, and then click
      Upload
      to insert it.
    • Click
      Preview On
      to preview the response.
    • If you want to return to the original default response text for the header or the body, click
      Paste Default Response Header
      or
      Paste Default Response Body
      .
    Redirect URL
    The system redirects the user to a specific web page instead of displaying a response page. You must enter a URL in the
    Redirect URL
    field.
    Soap Fault
    The system blocks a SOAP request due to an XML-related violation.
    The system displays the system-supplied response written in the SOAP fault message structure. You cannot edit this text.
    Click
    Preview On
    to preview the response.
    Erase Cookies
    The system deletes all client side domain cookies. This is done in order to block web application users once, and not from the entire web application. The system displays this text in the response page. You cannot edit this text. The response header and response body are shown. Click
    Preview On
    to preview the response.
  4. When you are finished, save your changes.
The response page settings are updated.

Edit failed login honeypot response page settings

You use the Failed Login Honeypot screen to view and edit the settings for the Failed Login Honeypot response page. Response page settings specify the response content that the system sends to the user when the security policy blocks a client request.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click a policy name, on the left of the next screen, click
    Response Pages
    then for the Response Pages type, click
    Failed Login Honeypot
    .
  3. For the
    Response Type
    setting, specify whether to use the default or a custom response.
    • To use the displayed response header and response body, select
      Default Response
      .
    • To use a modified response header or response body, select
      Custom Response
      .
    Selecting
    Custom Response
    makes editing options available.
  4. For the
    Response Header
    setting, review or change the response header.
    • If you selected the default response type, you can review, but not modify the response header.
    • If you selected the custom response type, you can modify the response header by editing the header text.
    • To replace your modifications with the default response header, click
      Paste Default Response Header
      .
  5. For the
    Response Body
    setting, review or change the response body.
    • If you selected the default response type, you can review, but not modify the response body.
    • If you selected the custom response type, you can modify the response body by editing the body text directly or by importing a file with that text. To import the response body:
      1. Click
        Choose File
        .
      2. In the displayed Open dialog box, select the file to import and click
        Open
        . The Open dialog box closes.
      3. Click
        Upload
        . The contents of the file are now in the response body text box.
    • To replace your modifications with the default response body, click
      Paste Default Response Body
      .
  6. For the
    Preview
    setting, specify whether to see a preview of the response body.
    • To see a preview how the response is displayed, click
      Preview On
      .
    • To skip a preview, click
      Preview Off
      .
  7. When you are finished, save your changes.

Edit cookie hijacking response page settings

You use the Cookie Hijacking Response Page screen to view and edit the settings for the Cookie Hijacking response page. Response page settings specify the response content that the system sends to the user when the security policy blocks a client request.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click a policy name, on the left of the next screen, click
    Response Pages
    , and for the Response Pages type, click
    Cookie Hijacking
    .
  3. For the
    Response Type
    setting, specify the type of response to use.
    • To use the default response header and body, select
      Default Response
      .
    • To use a modified response header or body, select
      Custom Response
      .
    • To use the SOAP fault response header and body, select
      SOAP Fault
      .
    • To use the erase cookies response header and body, select
      Erase Cookies
      .
    The response header and body change based on the response type you select. Selecting
    Custom Response
    makes editing options available.
  4. For the
    Response Header
    setting, review or change the response header.
    • If you did not select
      Custom Response
      as the response type, you can review but not modify the response header.
    • If you selected
      Custom Response
      as the response type, you can modify the response header by editing the header text.
    • To replace your modifications with the default response header, click
      Paste Default Response Header
      .
  5. For the
    Response Body
    setting, review or change the response body.
    • If you did not select
      Custom Response
      as the response type, you can review but not modify the response body.
    • If you selected the custom response type, you can modify the response body by editing the body text directly or by importing a file with that text. To import the response body:
      1. Click
        Choose File
        .
      2. In the displayed Open dialog box, select the file to import and click
        Open
        . The Open dialog box closes.
      3. Click
        Upload
        . The contents of the file are now in the response body text box.
    • To replace your modifications with the default response body, click
      Paste Default Response Body
      .
  6. For the
    Preview
    setting, specify whether to see a preview of the response body.
    • To see a preview how the response is displayed, click
      Preview On
      .
    • To skip a preview, click
      Preview Off
      .
  7. When you are finished, save your changes.

Edit mobile application response page settings

You use the Mobile Application Response Page screen to view and edit the settings for the mobile application response page. Response page settings specify the response content that the system sends to the user when the security policy blocks a client request.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click a policy name, on the left of the next screen click
    Response Pages
    and for the Response Pages type, click
    Mobile Application
    .
  3. for the
    Response Type
    setting, specify whether to use the default or a custom response.
    • To use the displayed response header and response body, select
      Default Response
      .
    • To use a modified response header or response body, select
      Custom Response
      .
    Selecting
    Custom Response
    makes editing options available.
  4. For the
    Response Header
    setting, review or change the response header.
    • If you selected the default response type, you can review but not modify the response header.
    • If you selected the custom response type, you can modify the response header by editing the header text.
    • To replace your modifications with the default response header, click
      Paste Default Response Header
      .
  5. For the
    Response Body
    setting, review or change the response body.
    • If you selected the default response type, you can review but not modify the response body.
    • If you selected the custom response type, you can modify the response body by editing the body text directly or by importing a file with that text. To import the response body:
      1. Click
        Choose File
        .
      2. In the displayed Open dialog box, select the file to import and click
        Open
        . The Open dialog box closes.
      3. Click
        Upload
        . The contents of the file are now in the response body text box.
    • To replace your modifications with the default response body, click
      Paste Default Response Body
      .
  6. For the
    Preview
    setting, specify whether to see a preview of the response body.
    • To see a preview how the response is displayed, click
      Preview On
      .
    • To skip a preview, click
      Preview Off
      .
  7. When you are finished, save your changes.

Edit login response page settings

You use the Login Pages Response Page screen to view and edit the settings for the login page response page, which is one of several response pages. Response page settings specify the content of the response that the system sends to the user when the security policy blocks a client request.
  1. Go to the Login Pages Response Page screen: click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click a policy name, and then click
    RESPONSE PAGES
    Login Page
    .
  3. Select a
    Response Type
    from the list. Your selection determines the additional settings.
    Default Response
    The screen displays the default response header and response body. The system sends the response body to the client as shown. You cannot edit these fields. Click
    Preview On
    to preview the response.
    Custom Response
    The screen displays the default response header and response body which you can edit to create a custom response. Alternatively, for the response body, you can upload a response.
    • Click
      Choose File
      to select the file containing the response body, and then click
      Upload
      to insert it.
    • Click
      Preview On
      to preview the response.
    • If you want to return to the original default response text for the header or the body, click
      Paste Default Response Header
      or
      Paste Default Response Body
      .
    Redirect URL
    The system redirects the user to a specific web page instead of displaying a response page. You must enter a URL in the
    Redirect URL
    field.
    Soap Fault
    The system blocks a SOAP request due to an XML-related violation.
    The system displays the system-supplied response written in the SOAP fault message structure. You cannot edit this text.
    Click
    Preview On
    to preview the response.
    Erase Cookies
    The system deletes all client side domain cookies. This is done in order to block web application users once, and not from the entire web application. The system displays this text in the response page. You cannot edit this text. The response header and response body are shown. Click
    Preview On
    to preview the response.
  4. When you are finished, save your changes.
The response page settings are updated.

Edit XML response page settings

You use the XML Response Page screen to view and edit the settings for the XML response page, which is one of several response pages. Response page settings specify the content of the response that the system sends to the user when the security policy blocks a client request.
  1. Go to the XML Response Page screen: click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click a policy name, and then click
    RESPONSE PAGES
    XML
    .
  3. Select a
    Response Type
    from the list. Your selection determines the additional settings.
    Custom Response
    The screen displays the default response header and response body which you can edit to create a custom response. Alternatively, for the response body, you can upload a response.
    • Click
      Choose File
      to select the file containing the response body, and then click
      Upload
      to insert it.
    • Click
      Preview On
      to preview the response.
    • If you want to return to the original default response text for the header or the body, click
      Paste Default Response Header
      or
      Paste Default Response Body
      .
    Soap Fault
    The system blocks a SOAP request due to an XML-related violation.
    The system displays the system-supplied response written in the SOAP fault message structure. You cannot edit this text.
    Click
    Preview On
    to preview the response.
  4. When you are finished, save your changes.
The response page settings are updated.

Edit policy building overview settings

You can review or change various overall aspects of policy building using the Policy Building Overview screen.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the policy you want to edit, and on the left of the new screen, click
    POLICY BUILDING
    Overview
    .
  3. To review the status of the devices being used for central policy building, expand Devices of Central Policy Building.
    The screen lists the devices and their status. You can click
    Refresh
    to update the device information.
  4. To review or change enforcement readiness for various policy entities, expand Enforcement Readiness Summary.
    The screen shows a summary list of entities in the security policy that can be enforced, along with their status.
  5. For additional information, you can click the links shown in the summary table.
    • In the Entity Type column, click the name of the policy entity type to review a list of suggestions for it, if any exist.
    • In the Learn New Entities column, you can see the learning status for the policy entity.
    • In the Total, Not Enforced, or Not Enforced And Have Suggestions columns, click the number of entities link to be taken to the appropriate policy screen. Entities that are not enforced are in staging, or have wildcard entities configured so that the security policy learns all explicit entities that match them.
    • In the Ready to be Enforced column, review the numbers. To enforce these entities, select the check box to the left in the row and click
      Enforce Selected Entities
      .
    • To update the data shown, click
      Refresh
      .
  6. To review the suggestions used to reduce false positive alerts, expand Suggestions To Reduce Potential False-Positive Alerts.
    In this area, you see three lists: Top Violations, Top Violating Meta Characters, and Top Matched Signatures. You may need to scroll down to see all three.Each list contains suggestions for the entities listed, if there are any.
    • To see the suggestions associated with a listed entity, such as one of the top violations, click the name.
    • To update the data shown, click
      Refresh
      .
  7. To review suggestions to add to new entries, expand Suggestions To Add New Entries.
    • You can review the new suggestions. These are listed by entity type.
    • To update the data shown, click
      Refresh
      .
  8. Save your work.
Your changes are applied to the security policy.

Edit policy building suggestion settings

You can view policy building suggestions and decide how to respond to each suggestion, such as accepting, ignoring, or deleting the suggestion.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the policy you want to edit, and on the left, click
    POLICY BUILDING
    Suggestions
    .
  3. To accept a suggestion, select it, click
    Actions
    , and select one of the accept options.
    • To accept a suggestion and have it added to the policy entity, select the
      Accept
      action.
    • To accept this suggestion and have it added to the policy entity in staged mode, select the
      Accept and Stage
      action.
    • To accept this suggestion and have it added globally at the policy level, select the
      Accept Globally
      action.
    Not all options are available for all suggestions. Unsupported options for a suggestion are not selectable. For example, the
    Accept and Stage
    option is only available for policy entities that support staging, such as signatures and URLs.
  4. To delete a suggestion, select the check box to the left of the suggestion and click
    Delete
    .
    The policy builder can suggest a deleted suggestion again.
  5. To ignore a suggestion, select the check box to the left of the suggestion and click
    Ignore
    .
    Once a suggestion is ignored, the policy builder will not suggest it again.
  6. To see additional details about the suggestion, click the name of the suggestion.
    The additional details for the suggestion vary, but may include other related suggestions and the list of samples.
  7. To add a comment to a suggestion, click the icon in the Comment column for that suggestion, and type your comment in the text box that opens.
  8. To list either all suggestions or only a subset of the suggestions, select one of the options in the filtering area in the upper left of the screen, such as
    Pending Suggestions
    or
    Ignored Suggestions
    .
  9. To perform a simple search of the suggestions, type the text to search for in the search area in the upper right of the screen.
    You cannot use the simple search when looking for a violation or a refinement. You must use an advanced search filter instead and select the violation or refinement.
  10. To perform an advanced search using a filter, click the icon to the left of the search area in the upper right of the screen. The filter dialog box opens.
    • To use an existing filter, click the filter name. The filter is applied.
    • To create a new filter, click
      Create
      . The New Filter dialog box opens.
      1. In the
        Filter Name
        setting, type a name for the filter.
      2. In the Query Parameter area, specify values for the parameters you want to use to create the search filter. As you select parameters, the system creates the query in the Query Expression area.
      3. When you are done, click
        Save & Apply
        to save your changes and apply the filter.

Edit policy building settings

You can view and edit the application security policy building settings to specify how the system responds (learn, alarm, or block) to a request that contains each type of illegal request, and to control the policy building process. You edit the blocking settings for each policy object individually.
  1. Go to the Blocking Settings screen: click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of a policy, and from the list on the left select
    POLICY BUILDING
    Settings
    .
  3. Click the arrows to open or close each category and display specific violation types available to configure for that category.
  4. Edit the settings to meet your requirements.
  5. When you are finished, save your work.
This updates the blocking settings in the application security policy.

Policy building settings properties

You configure the settings of the security policy to specify how the system responds to a request that contains each type of illegal request.
Blocking Setting
Description
Enforcement Mode
Specify whether blocking is active or inactive for the security policy.
  • Transparent
    . Specifies that blocking is disabled for the security policy. This disables blocking for all options on the screen, and the
    Block
    check boxes are unavailable.
  • Blocking
    . Specifies that blocking is enabled for the security policy, and you can enable or disable blocking for individual violations.
Learning Mode
Specify how learning is, or is not, performed.
  • Automatic
    has the system examine traffic, make suggestions, and enforce most suggestions after sufficient traffic over a period of time from various users make it reasonable to add them. A few suggestions must be enforced manually.
  • Manual
    has the system examine traffic and make suggestions on what to add to the security policy.
  • Disabled
    has the system do no learning for the security policy, and make no suggestions.
Policy Building Mode
Specify how policy building is performed. The option you select changes the other settings that are available.
  • To have policy building occur on the local BIG-IP device, select
    Local
    .
  • To have policy building occur on a central policy builder device that can take information from multiple BIG-IP devices, select
    Central
    .
Policy Building Device
Specify which central policy building device to use. This option is available only when central policy building mode is selected. The policy building device is also a data collection device.
  • To have the central policy building device chosen automatically, select
    Auto Select
    .
  • To manually choose the device to use for central policy building, select the device.
Auto-Deploy Policy
Specify when learning is automatically applied to the policy, and the policy is automatically deployed.
  • To have learning applied to the policy and deployed as it occurs, select
    Real Time
    .
  • To have learning applied to a policy and deployed at a scheduled time, select
    Scheduled
    , and then specify that time and day.
    • To have learning applied and deployed at any time during the day, select
      All Day
      .
    • To have learning applied and deployed at a certain time during the day, select
      Specific Time
      and provide that time.
    • To have learning applied and deployed every day of the week, select
      All Week
      .
    • To have learning applied and deployed on selected days of the week, select
      Specific Days
      and specify the days.
  • To have the system not apply learning and deploy the security policy, select
    Disabled
    .
Learning Speed
Select the speed the Policy Builder uses for learning.
  • To have the Policy Builder learn traffic from a small number of requests, sessions, and IP addresses, select
    Fast
    . Using this setting, there is a high chance that the Policy Builder will add false entities to the security policy.
  • To have the Policy Builder learn traffic from a medium amount of requests, sessions, and IP addresses, select
    Medium
    . Using this setting, there is a medium chance that the Policy Builder will add false entities to the security policy.
  • To have the Policy Builder learn traffic from a large number of requests, sessions, and IP addresses, select
    Slow
    . Using this setting, there is a low chance that the Policy Builder will add false entities to the security policy.
  • To have the Policy Builder use custom settings in the policy, select
    Custom
    . The
    Custom
    option is selected automatically when you customize settings in the policy.
All Violations
Select the
Learn
,
Alarm
or
Block
check boxes in this row to have those selections apply to all the violations in this group. You can select or clear these check boxes in the violation rows to change the behavior for individual violations, or groups of violations.
  • Learn
    specifies that when a request triggers this violation, the system learns the request.
  • Alarm
    specifies that if a request triggers this violation, the system records the request.
  • Block
    specifies that if this violation occurs, the system takes these actions:
    • Records the request.
    • Blocks the request that triggered the violation.
    • Returns the blocking response page to the client who sent the request.
Policy General Features
Expand this setting to see the contained violations. Click the information icon next to each violation for more information about it.
Select
Learn
,
Alarm
, or
Block
for each, as appropriate for your policy.
HTTP protocol compliance failed
Expand this setting to see the sub-violations, and click the information icons for more information.
Either select the
Enable
or
Learn
check box at the top of the section to select all HTTP protocol compliance failed sub-violations at once, or select the
Enable
or
Learn
check box to the left of each sub-violation to specify that the system enforces the sub-violation. When the check box is cleared, the system does not enforce this sub-violation. This category contains the following sub-violations.
  • Bad HTTP version
    . When checked (enabled), the system inspects requests to see whether they request information from a client using a legal HTTP protocol version number (0.9 or higher). The default setting is enabled
  • Bad host header value
    . When checked (enabled), the system inspects requests to see whether they contain a non RFC compliant header value. The default value is enabled.
  • Bad multipart parameters parsing
    . When checked (enabled), the system examines requests to see whether the content-disposition header field matches the format,
    name=“param_key”;\r\n
    . The default setting is enabled.
  • Bad multipart/form-data request parsing
    . When checked (enabled), the system examines requests to see whether the content-disposition header field contains the required parameters,
    name=“param_key”
    . The default setting is enabled.
  • Body in GET or HEAD requests
    . When checked (enabled), the system examines requests that use the GET or HEAD methods to see whether the requests contain data in their bodies, which is considered illegal. The default setting is disabled.
  • CRLF characters before request start
    . When checked (enabled), the system examines requests to see whether they begin with the characters CRLF, which is not permitted. The default setting is enabled.
  • Check maximum number of headers
    . When checked (enabled), the system compares the number of headers in the requests against the maximum number you specify here. Type a number in the field to specify how many headers are allowed. The default setting is enabled with a maximum of 20 headers unless the policy is based on an Application-Ready security policy template. In this case, the default value depends on which template you are using.
  • Check maximum number of parameters
    . When checked (enabled), the system compares the number of parameters in the request against the maximum number you specify here. A request that contains more parameters than allowed by the policy should be considered a possible attack on the server. Type a number in the field to specify how many parameters are allowed. The default value is enabled set to a maximum of 500 parameters.
  • Chunked request with Content-Length header
    . When checked (enabled), the system examines chunked requests for a content-length header, which is not permitted. The default setting is enabled.
  • Content length should be a positive number
    . When checked (enabled), the system examines requests to see whether their content length value is greater than zero, which is required. The default setting is enabled.
  • Header name with no header value
    . When checked (enabled), the system checks requests for valueless header names, which are considered illegal. The default setting is enabled.
  • High ASCII characters in headers
    . When checked (enabled), the system inspects request headers for ASCII characters greater than 127, which are not permitted. The default setting is disabled.
  • Host header contains IP address
    . When checked (enabled), the system verifies that the request’s host header value is not an IP address. The default setting is disabled.
  • Multiple host headers
    . When checked (enabled), the system examines requests to ensure that they contain only a single Host header. The default value is enabled.
  • No Host header in HTTP/1.1 request
    . When checked (enabled), the system examines requests sent by a client using HTTP version 1.1 to see whether they contain a host header, which is required. The default setting is enabled.
  • Null in request
    . When checked (enabled), the system inspects requests to see whether they contain a Null character, which is not allowed. The default setting is enabled.
  • POST request with Content-Length 0
    . When checked (enabled), the system examines POST method requests for no content-length header, and for a content length of 0. The default setting is disabled.
  • Several Content-Length headers
    . When checked (enabled), the system examines each request to see whether it has more than one content-length header, which is considered illegal. The default setting is enabled.
  • Unparseable request content
    . When checked (enabled), the system examines requests for content that the system cannot parse, which is not permitted. The default setting is enabled.
Attack Signatures
The system examines HTTP messages for known attacks by comparing them against known attack patterns. Click the
Edit Settings
link to edit the properties of that signature set.
Evasion technique detected
Expand this setting to see the evasion technique sub-violations and click information icons for more information.
Either select the
Enable
or
Learn
check box at the top of the section to select all sub-violations at once, or select the
Enable
or
Learn
check box to the left of each sub-violation to specify that the system enforces the sub-violation. When the check box is cleared, the system does not enforce this sub-violation. This category contains the following sub-violations.
  • %u decoding
    . Indicates that the system performs %u decoding (%UXXXX where X is a hexadecimal digit). For example, the system turns a%u002fb to a/b. The system performs this action on URI and parameter input.
  • Apache whitespace
    . Indicates that the system discovers the bytes 0x09, 0x0b, or 0x0c (a non-RFC standard of using tab for a space delimiter). The violation applies to URI input. However, for this violation, the system does not change the input.
  • Bad unescape
    . Indicates that the system discovers illegal URL-encoding. For example, if the two bytes after % are not hexadecimal characters, or if the four bytes after %u are not a hexadecimal characters. This violation applies to URI and parameter input. However, for this violation, the system does not change the input.
  • Bare byte decoding
    . Indicates that the system discovers characters higher than ASCII-127. This violation applies to URI input. However, for this violation, the system does not change the input.
  • Directory traversals
    . Indicates that the system clears self references and performs directory traversals so that attackers cannot try to access restricted Web server files residing outside of the Web server’s root directory. For example, the system turns a/b/../c to a/c and a/./b to a/b. The system performs this action on URI input.
  • IIS Unicode codepoints
    . Indicates that, when XXXX is greater than 0x00FF, the system decodes %u according to an ANSI Latin 1 (Windows 1252) code page mapping. For example, the system turns a%u2044b to a/b. The system performs this action on URI and parameter input.
  • IIS backslashes
    . Indicates that the system turns backslashes (\) into slashes (/). The system performs this action on URI input.
  • Multiple decoding
    . Indicates that the system performs multiple decoding. Use the decoding passes drop-down control to specify the number (up to 5) of decoding passes. For example, the system can turn a%252fb to a/b (since %252f becomes %2f after one pass, and / after the second pass). The system performs this action on URI and parameter input. Select a number to specify how many decoding passes the system performs, and the level at which the system responds with the appropriate Alarm or Block action. For example, if you set this to
    3
    , the system performs two decoding passes, and when it performs the third decoding pass, it takes the action specified by the Learn/Alarm/Block settings of the Evasion technique detected category.
File Types
Expand this setting to see the file type sub-violations, and click information icons for more information. When enabled, the system checks that the requested file type is configured as a valid file type or not configured as an invalid file type. This category contains the following sub-violations.
  • Illegal query string length
    . The incoming request contains a query string whose length exceeds the acceptable length specified in the policy.
  • Illegal POST data length
    . The incoming request contains POST data whose length exceeds the acceptable length specified in the policy.
  • Illegal request length
    . The incoming request length exceeds the acceptable length specified in the policy per the requested file type.
  • Illegal file type
    . The incoming request references file types not found in the policy.
  • Illegal URL length
    . The incoming request includes a URL whose length exceeds the acceptable length specified in the policy.
In the
Learn New File Types
setting, select under which circumstances the Policy Builder adds, or suggests you add, explicit file types to the security policy. As you select the setting, additional information about the setting is displayed below it.
In the
Maximum Learned File Types
setting, type the maximum number. The default value changes based on the value of the
Learn New File Types
setting.
URLs
Expand this area to see the URL sub-violations and click the information icons for more information on each.
  • In the
    Learn New HTTP URLs
    setting, select under which circumstances the Policy Builder adds, or suggests you add, HTTP URLs to the security policy. As you select the setting, additional information about the setting is displayed below it.
  • In the
    Maximum Learned HTTP URLs
    setting, type the maximum number. The default value changes based on the value of the
    Learn New HTTP URLs
    setting.
  • In the
    Learn New WebSocket URLs
    setting, select under which circumstances the Policy Builder adds, or suggests you add, WebSocket URLs to the security policy. As you select the setting, additional information about the setting is displayed below it.
  • In the
    Maximum Learned WebSocket URLs
    setting, type the maximum number,
  • In the
    Classify Request Content of Learned HTTP URLs
    setting, use the
    Enabled
    check box to specify whether it should be enabled. When enabled, if the Policy Builder detects legitimate XML or JSON data to URLs configured in the security policy, the Policy Builder adds XML or JSON profiles to the security policy and configures their attributes according to the data it detects.
  • In the
    Classify Client Message Payload Format of Learned WebSocket URLs
    setting, use the
    Enabled
    check box to specify whether it should be enabled. When enabled, if the Policy Builder detects legitimate plain text or JSON data to WebSocket URLs configured in the security policy, the Policy Builder adds Plain Text or JSON profiles to the security policy and configures their attributes according to the data it detects.
  • In the
    Learn Allowed Methods on HTTP URLs
    setting, use the
    Enabled
    check box to specify whether it should be enabled. When enabled, if the Policy Builder detects a method used in a request that is not in the security policy’s list of generic methods, the Policy Builder adds the new method to the security policy and associates it to the specific requested URL.
  • In the
    Collapse many common HTTP URLs into one wildcard HTTP URL
    setting, use the
    Enabled
    check box to specify whether it should be enabled. When enabled, the system collapses many common explicit URLs into one wildcard URL with a common prefix and suffix. The Policy Builder collapse only URLs in the same directory (with the same prefix path), and if they have the same file extension. You can also type the number of occurrences and the depth.
  • In the
    File types for which wildcard HTTP URLs will be configured
    setting, select which file types to add or delete.
Parameters
Expand this area to see the parameter sub-violations and click the information icons for more information on each.
  • In the
    Learn New Parameters
    setting, select under which circumstances the Policy Builder adds, or suggests you add, explicit parameters to the security policy. As you select the setting, additional information about the setting is displayed below it.
  • In the
    Maximum Learned Parameters
    setting, type the maximum number of parameters that the security policy allows.
  • In the
    Parameter Level
    setting, select how the Policy Builder determines on which level to add, or suggest you add, parameters to the security policy. Select
    Global
    or
    URL
    , and review the information displayed about each.
  • In the
    Collapse many common Parameters into one wildcard Parameter
    setting, select the check box to specify that the system collapses many common parameters into one wildcard parameter. In the field, type how many explicit parameters the Policy Builder must detect (the number of occurrences) before collapsing them to one wildcard parameter.
  • In the
    Classify Value Content of Learned Parameters
    setting, when enabled, specifies that if the Policy Builder detects legitimate XML or JSON data to parameters configured in the security policy, the Policy Builder adds XML or JSON profiles to the security policy and configures their attributes according to the data it detects.
  • In the
    Learn Integer Parameters
    setting, specifies, when enabled, that the Policy Builder learns integer parameters.
  • In the
    Learn Dynamic Parameters
    setting, you specify the conditions under which the Policy Builder adds dynamic parameters to the security policy.
Sessions and Logins
Expand this area to see the session and login sub-violations, and click the information icons for more information on each violation.
In the
Detect login pages
setting, select the
Enabled
check box to have the Policy Builder detect login pages by examining traffic to the web application.
Cookies
Expand this area to see the cookie sub-violations and click the information icons for more information on each violation.
  • In the
    Learn New Cookies
    setting, select the circumstances the Policy Builder adds, or suggests you add, explicit cookies to the security policy. As you select the setting, additional information about the setting is displayed below it.
  • In the
    Maximum Learned Cookies
    setting, type the largest number of cookies that the policy allows.
  • In the
    Learn and enforce new unmodified cookies
    setting, specify, when the
    Enabled
    check box is selected, that the system enforces new cookies as long as they were not modified by the client. This option only appears if the
    Learn New Cookies
    option is set to
    Selective
    and the * wildcard cookie is of type
    Allowed
    .
  • In the
    Collapse many common Cookies into one wildcard Cookie
    setting, you specify, when the
    Enabled
    check box is selected, that the system collapses many common cookies into one wildcard cookie. Type in the box how many explicit cookies the Policy Builder must detect (the number of occurrences) before collapsing them to one wildcard cookie.
Content Profiles
Expand this area to see the content profile sub-violations, and click the information icons for more information on each violation.
In the
Collapse many common Content Profiles into one wildcard Content profile
setting, you specify, when the
Enabled
check box is selected, that the system collapses many common content profiles into one wildcard content profile. Type in the field how many explicit content profiles the Policy Builder must detect (the number of occurrences) before collapsing them to one wildcard content profile.
Web Services Security Failure
Expand this area to see the web services security failure sub-violations.
At the top of the list of sub-violations, select either the
Enable
or
Learn
check box to select all sub-violations at once, or select the
Enable
or
Learn
check box to the left of each sub-violation to specify that individual sub-violation.
  • Certificate Error
    . When checked (enabled), the system learns, logs, or blocks responses when the client certificate extracted from the document is invalid. The default setting is enabled. Possible causes include the following instances.
    • The client certificate structure is invalid, and cannot be parsed.
    • The client certificate is not found in the keystore.
  • Certificate Expired
    . When checked (enabled), the system learns, logs, or blocks responses when the client certificate extracted from the document has expired. The default setting is enabled. Possible causes include the following instances.
    • The client certificate structure is invalid and cannot be parsed.
    • The client certificate is not found in the key-store.
    The system does not perform this check if the
    Save Expired/Untrusted Certificate
    option is enabled when you add the certificate to the system’s certificate pool.
  • Decryption Error
    . When checked (enabled), the system learns, logs, or blocks requests when an encrypted section in the request could not be decrypted. The default setting is enabled. Possible causes include the following instances.
    • The message could not be decrypted since no key information was found.
    • The encryption algorithm is not supported.
  • Encryption Error
    . When checked (enabled), the system learns, logs, or blocks responses when the system cannot encrypt a section requested by the user. For example, the message cannot be encrypted if no key information was detected in the request. The default setting is enabled.
  • Expired Timestamp
    . When checked (enabled), the system learns, logs, or blocks requests when the timestamp has expired. The default setting is enabled.
  • Internal Error
    . When checked (enabled), the system learns, logs, or blocks requests and/or responses when the system’s web services security offload engine confronts an unexpected scenario. For example, if a resource fails to allocate. The default setting is enabled.
  • Invalid Timestamp
    . When checked (enabled), the system learns, logs, or blocks requests when the timestamp is not formatted according to the specifications. The default setting is enabled.
  • Malformed Error
    . When checked (enabled), the system learns, logs, or blocks requests and/or responses when the system’s web services security offload engine confronts a malformed document. For example, if the document contains characters that are illegal according to the W3C XML 1.0 recommendation. The default setting is enabled.
  • Missing Timestamp
    . When checked (enabled), the system learns, logs, or blocks requests when the timestamp is missing from the document. The default setting is enabled.
  • Signing Error
    . When checked (enabled), the system learns, logs, or blocks responses when the underlying crypto library failed to digitally sign the document, or the response contains an unknown or unsupported algorithm. The default setting is enabled.
  • Timestamp expiration is too far in the future
    . When checked (enabled), the system learns, logs, or blocks requests when the timestamp lifetime is greater than configured. The default setting is enabled.
  • UnSigned Timestamp
    . When checked (enabled), the system learns, logs, or blocks requests when the timestamp is not digitally signed. The default setting is enabled.
  • Verification Error
    . When checked (enabled), the system learns, logs, or blocks requests when the underlying crypto library failed to perform digital signature verification, or there is information missing in the payload. The default setting is enabled.
CSRF Protection
Expand this area to see the cross-site request forgery (CSRF) protection sub-violations.
Cross-site request forgery (CSRF)
is an attack that forces a user to execute unwanted actions on a web application in which the user is currently authenticated. When this setting is enabled, the system protects the web application against CSRF attacks. This category contains the following violations.
  • CSRF authentication expired
    . The incoming request may be a Cross-Site Request Forgery (CSRF) attack. The request may come from a clicked link, embedded malicious HTML, or JavaScript in another application, and may involve transmission of unauthorized commands through an authenticated user.
  • CSRF attack detected
    . The incoming request includes an expired cross-site request forgery (CSRF) session cookie.
IP Addresses / Geolocations
Expand this area to see the IP address and Geolocation sub-violations, and click the information icons for more information on each violation.
Headers
Expand this area to see the header sub-violations and click the information icons for more information on each violation.
In the
Learn Host Names
setting, Select the
Enabled
check box to specify that the Policy Builder suggests you add host names that have not yet been added to the policy.
Redirection Protection
Expand this area to see the redirection protection sub-violations, and click the information icons for more information on each violation.
In the
Learn New Redirection Domains
setting, select under which circumstances the Policy Builder adds, or suggests you add, explicit redirection domains to the policy. As you select the setting, additional information about the setting is displayed below it.
In the
Maximum Learned Redirection Domains
setting, type the largest number of redirection domains that the policy allows.
Bot Detection
Expand this area to see the WebSocket sub-violations. The Bot Detection category contains the
Web scraping detected
violation, which detects when the web client, or user agent, does not demonstrate human behavior.
Data Guard
Expand this area to see the Data Guard sub-violations. The Data Guard category specifies which information the system considers sensitive, including credit card numbers, U.S. Social Security numbers, custom patterns, and file content. This category contains the
Data Guard. Information leakage detected
violation.
WebSocket protocol compliance
Expand this area to see the WebSocket protocol compliance sub-violations, and click the information icons for additional information about each violation.
Antivirus Protection
Expand this area to see the antivirus protection sub-violations, and click the information icons for additional information about each violation.

Edit policy building process settings

You can view and edit the building process settings for the application security policy to specify how Web Application Security builds policies.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of a policy, and on the left, click
    POLICY BUILDING
    Settings
    .
  3. Scroll to near the bottom of the settings properties screen, expand the Policy Building Process area, and specify settings as needed.
  4. In the
    Trust IP Addresses
    setting, you specify IP addresses that the Policy Builder considers safe.
    • Select
      All IP Addresses
      to indicate that all IP addresses are safe.
    • Select
      Address List
      to indicate that all IP addresses in the displayed list are safe.
    • Click
      Edit IP Addresses
      to add IP addresses to the list.
  5. For the
    Loosen Policy
    setting, you specify the number of sources that the system must detect during a specified time period, in order for the Policy Builder to accept and learn a policy change from traffic.
    For example, when the Policy Builder detects the same file type, URL, parameter, or cookie from enough different user sessions and IP addresses over time, it adds the entity to the security policy. You can configure values for both untrusted traffic and for trusted traffic.
  6. For the
    Tighten Policy (stabilize)
    setting, you specify the number of requests and the amount of time that must pass for the Policy Builder to stabilize the policy element.
    Stabilizing the policy element may mean tightening it by deleting wildcard entities, removing entities from staging mode, and enforcing violations that did not occur, depending on the element.
  7. For the
    Minimize false positives (Track Site Changes)
    setting, you specify whether, after stabilizing the policy, the Policy Builder remains enabled, and if enabled, how it handles trusted and untrusted traffic to minimize false positives.
    • Select
      Enable
      to specify that after the Policy Builder stabilizes the policy, the Policy Builder remains enabled, and may still make changes to the policy by loosening it, usually as a result of changes to the web application. Specifies, when cleared (disabled), that after the Policy Builder stabilizes the policy, it disables itself and makes no more changes to the policy, even if it detects that changes were made to the web application.
    • Select
      From Trusted and Untrusted Traffic
      to specify that the Policy Builder loosens the policy based on traffic from trusted and not trusted sources. This setting is available only if
      Enable
      is selected.
    • Select
      Only from Trusted Traffic
      to specify that the Policy Builder loosens the policy based on traffic from trusted sources. Click
      IP Address Exceptions
      to define a trusted IP addresses. This setting is available only if
      Enable
      is selected.
    You configure values for trusted and untrusted traffic separately.
  8. For the
    Options
    setting, you can establish options that determine what type of entities the Policy Builder adds to the policy.
    • When enabled,
      Learn from responses
      specifies that the Policy Builder adds elements found in responses to the policy, when either of the following circumstances is true:
      • The Policy Builder trusts the request IP address (because the request IP address appears in the Trusted IP Addresses list).
      • The Policy Builder does not trust the request IP address (because the request IP address does not appear in the Trusted IP Addresses list), but the request is legal and fully enforced.
        Legal
        means that the request does not trigger any violations, suggestions to learn explicit entities, and staging suggestions.
        Fully enforced
        means that the system is not currently determining whether URLs and parameters found in the request are to be parsed as JSON or XML and should be assigned to content profiles.
      If the Policy Builder learns from responses, it uses the trusted traffic thresholds configured on this screen. This does not include learning from violations in responses. In that case, the thresholds are determined by whether the client IP address is trusted or untrusted.
      Specifies, when
      Learn from responses
      is cleared (disabled), that the Policy Builder never adds elements found in responses to the policy. Violations occurring in responses are learned according to the learn flag of each violation and do not depend on this setting.
      This setting applies only to what can be learned from the response content such as occurrences of URLs and parameters. It does not apply to learning from violations that occur in responses, such as Data Guard leakage. Learning from these violations is determined by the Learn flag of the respective violation.
    • When enabled,
      Suggest to delete policy entity if it was not observed in traffic for more than
      specifies that a suggestion to delete a policy entity should be made if that entity hasn't been observed in traffic for the specified number of days.
    • Select
      Full Policy Inspection
      to specify that the Policy Builder learns all policy elements. Specifies, when cleared (disabled), that you are limiting the number of entities the Policy Builder learns.
      Do not disable this check box unless F5 Support advises it.
    • In the
      HTTP Response Status Codes used to learn traffic
      setting, you can specify that the Policy Builder extracts information from traffic based on transactions that return specific HTTP response status codes. In the field type the response code that must be returned in order for the Policy Builder to extract information from that traffic.
      Click
      Add
      to add the response status code to the response status codes list. You may enter either a specific response code number from 0 to 599, or a generic code, for example,
      4xx
      . The response status codes list displays the response codes allowed by the Policy Builder and in the policy.
      Click the
      X
      to the left of the response code to remove the selected response status code from the response status codes list and to make it disallowed by the Policy Builder.
  9. When you are finished, save the modifications.
The policy building process settings are updated in the application security policy.

Edit server technologies settings

You can add server technologies to your security policy so that your policy can be automatically associated with the correct attack signature sets for the technology. Server technologies can be server-side applications, frameworks, programs, web servers, operating systems, and so on.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the policy you want to edit, then on the next screen, on the left, click
    Server Technologies
    .
  3. Select the server technology from the list.
    A confirmation dialog box opens listing the changes that will be made to the policy.
  4. Confirm that you want to add the server technology by clicking
    OK
    in the dialog box.
    The technologies are added to the list of selected server technologies.
  5. To remove a server technology entry, click the
    X
    to the left of that entry.
  6. Save your work.

Edit Data Guard settings

You can view and edit Data Guard settings to specify which information the system considers sensitive, including credit card numbers, U.S. Social Security numbers, custom patterns, and file content.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click a policy name, and on the left click
    Data Guard
    .
  3. In the Data Guard setting, select
    Enabled
    so that you can modify the other settings.
    When this setting is disabled, the system sends the response, including the sensitive information, to the user.
  4. Modify the settings as needed to specify how the system treats sensitive data:
    Protect credit card numbers
    Specifies that the system considers credit card numbers as sensitive data. The system returns asterisks to the client instead of the sensitive data.
    Protect U.S. security card numbers
    When selected, the system considers U.S. security card numbers as sensitive data.
    Mask sensitive data
    When selected, the system masks sensitive data returned by the web server by returning asterisk ( * ) characters to the client instead of the sensitive data.
    Custom Patterns
    When selected, specifies that the system recognizes customized patterns as sensitive data.
    In the field, type a pattern that you want the system to consider as sensitive data, and click
    Add
    . Use PCRE regular expression syntax for the pattern, for example,
    999-[/d][/d]-[/d][/d][/d][/d]
    . To delete a selected pattern, click
    X
    .
    Exception Patterns
    When selected, the system recognize exception patterns as not being sensitive data.
    In the field, type a pattern that you want the system to consider as an exception to sensitive data, and click
    Add
    . Use PCRE regular expression syntax for the pattern, for example,
    999-[/d][/d]-[/d][/d][/d][/d]
    . To delete a selected pattern, click
    X
    .
    File Content Detection
    When this is selected, you specify the possible types of content the system could consider as sensitive data. The system checks responses for the selected file content, and if it finds it, that content is not returned,
    Enforcement Mode
    Specify whether the listed URLs should be enforced or ignored by Data Guard.
    • Select
      Enforce URLs in List
      to have Data Guard protect these URLs even if they are not in the policy.
    • Select
      Ignore URLs in List
      to have Data Guard protect all URLS except those in this list.
    Add a URL to the list by typing it in the field and clicking
    Add
    .
    When adding URLs, you can type either explicit (
    /index.html
    ) or wildcard (
    *xyz.html
    ) URLs.
  5. When you are finished, save your work.
The policy is updated to use the new Data Guard settings.

Edit CSRF protection settings

You can enable and modify CSRF protection properties in your security policy to better protect your applications from a CSRF attack.
Cross-site request forgery
(CSRF) is an attack method that exploits a pre-existing relationship of trust and forces a user to run unwanted actions on a web application in which the user is currently authenticated.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of a policy, and from the list on the left, select
    CSRF Protection
    .
  3. For the
    CSRF Protection
    setting, select the
    Enabled
    check box.
    The screen displays the other property settings.
  4. For the
    SSL Only
    setting, select the
    Enabled
    check box.
  5. For the
    Expiration Time
    setting, select the
    Enabled
    check box, then provide the expiration time in seconds in the area provided.
  6. Use the CSRF URLs area to add, remove, or modify CSRF URLs to be protected.
    Existing URLs are listed in their evaluation order at the bottom of the screen.
    For BIG-IP device versions earlier than 13.1, URLs added to the CSRF URLs list must have the following settings:
    • Specify the
      Method
      setting as
      Any
      .
    • Specify the
      Enforcement Action
      setting as
      Verify CSRF Token
      .
    • Specify the
      Required Parameters
      setting as
      At Least One
      .
  7. To add a new URL to the list:
    1. In the
      Method
      setting, select the method type.
    2. In the
      URL
      setting, type the URL to be protected.
    3. In the
      Enforcement Action
      setting, select the type of enforcement.
    4. In the
      Required Parameters
      setting, specify whether there are any required parameters, and if needed, provide them.
    5. Click
      Add
      .
  8. To edit existing CSRF URLs:
    • To modify a URL, change the required parameters or enforcement action in the list at the bottom of the screen.
    • To change the evaluation order of a URL, drag the URL row to a new position in the list.
    • To delete a URL from the list, click the
      X
      to the left of the URL.
  9. Save your work.

Add or edit brute force attack prevention settings

You can protect login URLs against brute force attacks. A
brute force
attack is an outside attempt by hackers to access post login pages of a website by guessing user names and passwords. Brute force attacks are performed when a hacker tries to log in to a URL numerous times, running many combinations of user names and passwords, until he successfully logs in. The
Default
login URL is used for all defined login URLs that do not have their own brute force configuration.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of a policy, and on the left click
    ANOMALY DETECTION
    Brute Force Attack Prevention
    .
  3. Specify the action to take for brute force attack prevention settings:
    • To add a login URL to the security policy, click
      Add
      .
    • To modify the brute force prevention properties for a login URL, click the name of the login URL.
    The brute force prevention properties display.
  4. Supply the general properties for brute force attack prevention for the login URL.
    1. In the
      Login Page
      setting, select a login page, or create a login page by clicking
      Create login page
      .
    2. In the
      Configuration Support
      setting, specify whether to use current or legacy settings. The other available properties differ based on this setting.
      • Select
        Current
        when managing a BIG-IP device version later than 13.0.
      • Select
        13.0 And Prior
        when managing a BIG-IP device version 13.0 or earlier.
    3. In the
      IP Address Whitelist
      setting, review the settings or add new settings. To add an IP address, click the
      IP Address Whitelist
      setting link.
  5. In the Source-based Brute Force Protection area, supply the source-based protection settings.
    This area is available only when
    Configuration Support
    is set to
    Current
    .
    1. In the
      Detection Period
      setting, type the number of minutes the detection period should last.
    2. In the
      Maximum Prevention Duration
      setting, type the number of minutes the prevention period should last.
    3. For each of the other settings in this section, set the trigger and the action:
      • In the
        Trigger
        setting, specify when the trigger for the action occurs by selecting either
        Never
        or
        After
        a specified value is reached.
      • For the
        Action
        setting, select the action that occurs when the trigger is reached.
  6. In the Distributed Brute Force Protection area, supply the distributed protection settings.
    This area is available only when
    Configuration Support
    is set to
    Current
    .
    1. In the
      Detection Period
      setting, type the number of minutes for detection.
    2. In the
      Maximum Prevention Duration
      setting, type the number of minutes for maximum prevention duration.
    3. In the
      Detect Distributed Attack
      setting, select when the distributed attack detection occurs.
      • Select
        Never
        to have no distributed brute force attack protection.
      • Select
        After x failed login attempts
        to have distributed brute force attacks detected if x failed logins are detected within the
        Detection Period
        configured previously.
    4. In the
      Detect Credential Stuffing
      setting, select when the detection should occur.
      • Select
        Never
        to have no credential stuffing detection.
      • Select
        After x login attempts that match stole credentials dictionary
        to have it reported when the configured conditions are met.
    5. In the
      Mitigation
      setting, select the distributed brute force protection mitigation option to use.
  7. In the Session-based Brute Force Protection area, supply the session-based protection settings.
    This area is available only when the
    Configuration Support
    setting is set to
    13.0 And Prior
    .
    • In the
      Login Attempts from the Same Client
      setting, type the number of attempts to allow.
    • In the
      Re-enable Login After
      setting, type the number of seconds.
    • In the
      Use Device ID
      setting, specify whether it is enabled.
  8. In the Dynamic Brute Force Protection area, supply the dynamic protection settings.
    This area is available only when the
    Configuration Support
    setting is set to
    13.0 And Prior
    .
    • For the
      Operation Mode
      setting, select one of the modes:
      Off
      ,
      Alarm
      , or
      Alarm and Block
      .
    • In the
      Measurement Period
      field, type the number of seconds.
    • In the
      Detection Criteria
      field, type the values that define when a problem is detected.
    • For the
      Prevention Policy
      setting, select one or of the options to use for the policy. When
      Source IP-Based Client Side Integrity Defense
      is selected, the
      Suspicious Criteria (per IP address)
      setting is displayed and can be modified.
    • In the
      Suspicious Criteria (per IP address)
      setting, type the values that define when failed login attempts become suspicious.
    • In the
      Prevention Duration
      setting, select the duration. This setting is displayed only when
      Source IP-Based Client Side Integrity Defense
      is selected in the
      Prevention Policy
      setting.
      • To have no limit on the duration, select
        Unlimited
        .
      • To have a maximum duration, select
        Maximum
        and type a value for the number of seconds.
  9. Save your work.

Add methods

In the application security policy, you can specify methods that other web applications may use when requesting a URL from another domain. All security policies accept standard HTTP methods by default. If your web application uses HTTP methods other than the default allowed methods (GET, HEAD, and POST), you can add them to the security policy.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the policy name, and then click
    HEADERS
    Methods
    .
  3. Click
    Add
    to add a method.
  4. From the
    Method
    list, select a method.
  5. When you are finished, click
    Save
    .
    The new method is added to the list on the Methods screen. The method appears in blue, meaning that you can edit it. The check box to the left indicates that you can also delete it.
The system updates the policy to use the new methods.

Add or edit HTTP header settings

In the application security policy, you can specify a list of HTTP request headers that other web applications hosted in different domains can use when requesting this URL.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the policy name, and then on the left, click
    HEADERS
    HTTP Headers
    .
  3. Select whether to add a new HTTP header or view or modify an existing HTTP header.
    • Click
      Add
      to add a new header.
    • Click the name of the header to view or modify the properties.
    Only HTTP headers that are displayed in blue can be modified or viewed.
  4. Provide or modify the header settings as appropriate.
    • Name
      . When adding a new header, select the name of the HTTP header from the list. When modifying a header, the name cannot be changed.
    • Type
      . Specifies
      explicit
      or
      wildcard
      . The only wildcard header in the system is the default pure wildcard header (*).
    • Mandatory
      . If enabled, requires this header to appear in requests.
    • Check Signatures
      . If this is enabled, the system performs attack signature checks on this header.
    • Base64 Decoding
      . When enabled, specifies that the security policy checks the parameter’s value for Base64 encoding, and decodes the value. The default is disabled.
    • Normalization
      . Specifies whether the system normalizes headers. Select the options for which type of normalization the system should perform on headers. There is a performance trade-off when using normalization, so use it only when needed.
      • Percent Decoding
        : Specifies, when enabled, that the system performs the following actions on header content:
        %XX
        and
        %uXX
        , bad unescaping, Apache whitespace, IIS Unicode codepoints, and plus to space.
      • URL Normalization and Percent Decoding:
        Specifies, when enabled, that the system performs the these actions on header content: multiple slashes, directory traversal, backslash replacement, and path parameter removal, and all
        Percent Decoding
        checks.
      • HTML Normalization:
        Specifies, when enabled, that the system performs the following actions on header content: removes all non-printables, whitespaces and the “+” character, skips comments, decodes HTML entities, performs hex decoding, decimal decoding, 0xXX decoding, style sheet escaping, and removes backslashes.
    • Evasion Techniques Violations
      . Specifies, when enabled, that the system logs and/or suggests learning suggestions for evasion violations detected during the normalization process if there are problems during the normalization of the specific header. The default is disabled.
    • Overridden Security Policy Settings
      . If used, select the signature override from the list and then enable or disable it by clicking
      Enabled
      or
      Disabled
      .
  5. When you are finished, click
    Save
    .
The system updates the policy to use the new settings.

Edit host name settings

You can review, add, and delete host names from the policy using the Host Names screen. This list of host names is used by several features of the application security policy.
  1. Navigate to the Host Names screen: click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Then click the name of the appropriate policy, and on the left click
    HEADERS
    Host Names
    .
  3. Review the list of host names.
    If no host names are listed, you can add them by clicking the
    Add
    .
  4. To modify a host name, click the name of the host name.
    The Host Name properties screen opens.
  5. Review the Host Name.
  6. To allow users to be redirected to a sub-domain of this host name, select the
    Include Sub-domains
    check box.
  7. To set the policy to transparent mode and forward all responses, select the check box for
    Policy is always transparent for this host
    .
  8. Click
    Save
    to save your changes.
The host name settings for the policy are updated.

Add or edit cookie settings

You can review, add, and remove cookies from a policy, and re-order cookie wildcards using the Cookies screen. You use the same process to modify or add a cookie. The only difference is that when you modify a cookie, the
Cookie Name
properties already exist and you cannot change them.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the appropriate policy, and on the left click
    HEADERS
    Cookies
    .
    The screen displays a list of cookies.
  3. To add a new cookie, click
    Add
    , or click a cookie name to modify an existing cookie.
    You use the same process to modify or add a cookie. However, you can specify some properties only when adding a cookie, and not modifying an existing cookie.
  4. Type or review the
    Cookie Name
    , and specify whether it is
    Explicit
    or is a
    Wildcard
    expression.
    You can specify a cookie name only when adding a new cookie.
  5. Specify the
    Cookie Type
    :
    • Select
      Allowed
      to indicate the client may change the cookie.
    • Select
      Enforced
      to indicate that the cookie cannot be changed by the client.
    Allowed
    provides additional options.
  6. Select the settings for the cookie.
    • For
      Perform Staging
      , select the
      Enabled
      check box to indicate that the cookie is placed in staging.
    • For
      Insert HTTPOnly attribute
      , select the check box to insert the attribute in the domain cookie response header.
    • For
      Insert SameSite attribute
      , specify whether the attribute should be set to
      None
      ,
      Strict
      , or
      Lax
      . Only
      None
      can be selected for BIG-IP devices earlier than version 13.1.
    • For
      Insert Secure attribute
      , select the check box to insert the attribute into the domain cookie response header.
    • For
      Base64 Decoding
      , select the check box to enable decoding of Base64 strings. (This setting is displayed only if the
      Cookie Type
      is set to
      Allowed
      .)
    • For
      Attack Signatures Check
      , select the check box to verify attack signatures and display attack signature override settings. (This setting is displayed only if the
      Cookie Type
      is set to
      Allowed
      .)
    • For
      Attack Signature Overrides
      , select a signature from the list, and then click
      Enabled
      or
      Disabled
      to indicate whether each signature should be overridden.
  7. To remove a cookie from staging, select the check box for the cookie and click
    Enforce Selected
    .
  8. To filter the list of cookies by their enforcement readiness, select an option from the
    Enforcement Readiness
    setting.
    Enforcement readiness is the state of enforcement for each cookie, such as not enforced,, has a suggestion, or is ready to be enforced.
    • To list all cookies, select
      All
      .
    • To list cookies that have one or more suggestions, select
      Has suggestion
      .
    • To list cookies that are not being enforced, select
      Not enforced
      .
    • To list cookies that are ready to be enforced, select
      Ready to be enforced
      .
  9. Click
    Save
    to save your changes.
The cookie settings for the policy are updated.

Edit redirection protection settings

You can enable redirection protection and list those domains that are allowed by your security policy, using the Redirection Protection screen. By enabling redirection protection, you can help prevent users from being redirected to questionable, phishing, or malware websites.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the appropriate policy, and on the left click
    HEADERS
    Redirection Protection
    .
  3. For the
    Redirection Protection
    setting, select the
    Enabled
    check box.
    The screen displays other property settings.
  4. For
    Domain Name
    , type the domain name that is allowed by the security policy.
  5. To have the security policy also allow sub-domains of the domain, select the
    Include Sub-Domains
    check box.
  6. To add the domain to the
    Allowed Redirection Domains
    list, click
    Add
    .
  7. To delete a domain from the
    Allowed Redirection Domains
    , click the
    X
    to the left of that domain name.
    The domain is removed without confirmation.
  8. Save your work.

Edit header character set settings

You can configure the security policy to allow or disallow certain characters in the value field of an HTTP header and in uncommon header names.
  1. Navigate to the Character Set screen: click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the appropriate policy, expand
    HEADERS
    and click
    Character Set
    .
  3. Review the list of characters, and for each, determine whether it should be allowed.
    You can use the View options to select which group of characters are displayed.
    • To allow characters in a header, select the check box in the
      Allowed
      column of the table row .
    • For characters that should not be allowed in a header, clear the check box in the
      Allowed
      column of the table row.
  4. Click
    Save
    to save your changes.

Edit IP addresses list settings

You can view and edit configured IP address exceptions and characteristics.
  1. Navigate to the IP Address screen: click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Select a policy name, expand
    IP ADDRESSES
    , and select
    IP Addresses List
    .
  3. Click
    Add
    .
  4. Type an
    IP Address
    that you want the system to trust.
    To add a route domain, type
    %n
    after the IP address where
    n
    is the route domain identification number.
  5. Type a
    Netmask
    .
    If you omit the netmask value, the system uses a default value of
    255.255.255.255
    .
  6. Select whichever of the following options should be enabled.
    • Select the
      Policy Builder Trusted IP
      check box to specify that the Policy Builder considers traffic from this IP address to be legitimate. The Policy Builder automatically adds to the security policy data logged from traffic sent from this IP address.
    • Select the
      Ignore in Anomaly Detection and do not Collect Device ID
      check box to specify that the system considers traffic from this IP address to be safe. The security policy does not take this IP address into account when performing brute force prevention and web scraping detection.
    • Select the
      Ignore in Learning Suggestion
      check box to specify that the system not generate learning suggestions from traffic sent from this IP address.
    • Select the
      Never log traffic from this IP Address
      check box to specify that the system not log requests or responses sent from this IP address, even if the security policy is configured to log all traffic.
    • Select the
      Ignore IP Address Intelligence
      check box to specify that the system considers traffic from this IP address to be safe even if it matches an IP address in the IP Address Intelligence database.
  7. In the
    Block this IP Address
    setting, select one of the blocking options.
    • Select
      Policy Default
      to use the policy blocking settings.
    • Select
      Never Block This IP
      to not block this IP address.
    • Select
      Always Block This IP
      to block this IP address.
    If
    Always Block This IP
    is selected, many of the options become invalid and are removed from the screen.
  8. Type a brief description for the IP address.
  9. When you are finished, click
    Save
    to save the modifications and unlock the policy.
The IP Address settings are updated to use the new configured IP address exceptions, and any changes made are put into effect in the working configuration of the BIG-IQ Centralized Management system.

Edit IP address intelligence settings

You can review and modify IP address intelligence settings. An
IP intelligence database
is a list of IP addresses with questionable reputations. Refer to the ASM documentation or online help for more information on IP address intelligence.
  1. Navigate to the IP Address screen: click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Select a policy name, expand
    IP ADDRESSES
    , and select
    IP Address Intelligence
    .
  3. Select the
    IP Address Intelligence
    Enabled
    check box.
    Other properties display; you can review the descriptions of the properties for additional information.
  4. For the
    IP Address White List
    setting, type the IP address and subnet mask for each IP address that should be whitelisted, and click
    Add
    after each addition.
  5. In the
    IP Address Intelligence Categories
    area, specify the categories that you want to alarm or block.
    • Select the
      Alarm
      check box to specify that whenever a request is sent from a source IP address that matches the category, the system logs the IP Intelligence data.
    • Select the
      Block
      check box to specify that the system stops requests sent from a source IP address that matches the category.
      In order for the system to block requests, the security policy must be in Blocking mode.
  6. Click
    Save
    when you are done.
The IP address intelligence settings are updated.

Add or edit HTTP URL settings

You can view, add, modify, and remove HTTP URLs that are either allowed or disallowed in an application security policy.
Allowed URLs
are URLs that the security policy accepts in traffic to the web application being protected.
Disallowed URLs
are URLs that the security policy denies.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the appropriate policy, then on the left expand
    URLs
    , and click
    HTTP
    .
    The screen displays the list of HTTP URLs. You can add, delete, or reorder the HTTP URLs that are allowed or disallowed.
  3. To add an allowed or disallowed HTTP URL to a policy, click
    Add
    for the allowed or disallowed list.
    Allowed HTTP URLs are listed at the top of the screen and disallowed HTTP URLs are listed at the bottom. The Add URL screen displays the properties, which differ between allowed URLs and disallowed URLs.
    • For disallowed HTTP URLs, specify whether the protocol is HTTP or HTTPS, and type the URL name.
    • For allowed HTTP URLs, specify whether the URL is explicit or a wildcard, whether the protocol is HTTP or HTTPS, and type the URL name or wildcard. Specify or modify additional properties for the allowed HTTP URL as needed.
  4. Save your work.
  5. To review or edit the properties of a URL, click the URL to open the Properties screen.
    Allowed URLs are listed in the Allowed URL column in the upper table of URLs. Disallowed URLs are listed in the Disallowed URL column in the bottom table of URLs.
  6. To change the processing order of allowed URLS with the wildcard type, click
    Wildcards Order
    .
    The Wildcard Order screen opens, where you can move the wildcard entries in the list to change their sequence, and save your work.
  7. To remove an HTTP URL from staging, select the check box for the HTTP URL and click
    Enforce Selected
    .
  8. To filter the list of HTTP URLs by their enforcement readiness, select a value from the
    Enforcement Readiness
    setting.
    • To list all HTTP URLs, select
      All
      .
    • To list HTTP URLs that have one or more suggestions, select
      Has suggestion
      .
    • To list HTTP URLs that are not being enforced, select
      Not enforced
      .
    • To list HTTP URLs that are ready to be enforced, select
      Ready to be enforced
      .
  9. To delete an allowed or disallowed HTTP URL from the policy, select the check box in the row for that HTTP URL and click
    Delete
    in the upper or lower portion of the screen, whichever is appropriate.

Add or edit WebSocket URL settings

You can view, add, modify, and remove WebSocket URLs that are either allowed or disallowed in an application security policy.
Allowed URLs
are URLs that the security policy accepts in traffic to the web application being protected.
Disallowed URLs
are URLs that the security policy denies.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the appropriate policy, then on the left expand
    URLs
    and click
    WebSocket
    .
    The WebSocket URLs screen opens where you can add, or edit, WebSocket URLs.
  3. To remove the WebSocket URL from staging, select the check box for the WebSocket URL and click
    Enforce Selected
    .
  4. To edit the properties of a WebSocket URL, click the URL in either the
    Allowed WebSocket URLs
    or
    Disallowed WebSocket URLs
    column.
    The WebSocket URL properties screen opens, and you can change the properties (as described in the details for adding a URL of that type).
  5. To add a WebSocket URL to a policy, determine whether it is an allowed or disallowed WebSocket URL.
    • To add an allowed WebSocket URL, click
      Add
      in the upper portion of the screen. This opens the Add Allowed WebSocket URL screen, where you can supply the needed properties.
    • To add a disallowed WebSocket URL, click
      Add
      in the lower portion of the screen. This opens the Add Disallowed WebSocket URL screen, where you can supply the needed properties.
  6. For disallowed WebSocket URLs:
    1. Specify whether the protocol is
      WS
      or
      WSS
      .
    2. Type the URL name.
  7. For allowed WebSocket URLs, supply the needed properties.
    1. In the Properties area, supply or modify the overall properties for the WebSocket URL.
    2. In the Message Handling area, supply or modify the message handling properties for the WebSocket URL.
    3. For wildcard URLs, expand the Meta Characters area to specify how meta characters are handled.
      • For
        Check Signatures on this URL
        , select the
        Enabled
        check box.
      • For
        Check characters on this URL
        , select the meta characters from the list and then click
        Allow
        or
        Disallow
        as needed.
    4. In the HTML5 Cross-Domain Request Enforcement area, supply or modify the HTML5 cross-domain request enforcement properties for the WebSocket URL.
  8. To filter the list of WebSocket URLs by their enforcement readiness, select an option from the
    Enforcement Readiness
    list.
    • To list all WebSocket URLs, select
      All
      .
    • To list WebSocket URLs that have one or more suggestions, select
      Has suggestion
      .
    • To list WebSocket URLs that are not being enforced, select
      Not enforced
      .
    • To list WebSocket URLs that are ready to be enforced, select
      Ready to be enforced
      .
  9. Save your work.

Edit URL character set settings

You can view and edit how the security policy responds to each character contained in a URL.
  1. Navigate to the Character Sets URL screen: click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the appropriate policy, on the left expand
    URLs
    , and click
    Character Sets
    .
  3. Review the list of characters, and for each, determine whether it should be allowed.
    You can use the View options to select which group of characters are displayed.
    • To allow characters in a URL, select the check box in the
      Allowed
      column of the table row.
    • For characters that should not be allowed in a URL, clear the check box in the
      Allowed
      column of the table row.
  4. Click
    Save
    to save your changes.

Add or edit file types settings

You can add and configure settings for file types that are allowed (or disallowed) in traffic to the web application being protected. These settings determine how the security policy reacts to requests referring to files with these extensions.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the policy to change, and on the left, click
    File Types
    .
    The screen displays a list of file types.
  3. To remove the file type from staging, select the check box for the file type and click
    Enforce Selected
    .
  4. To add a file type to the policy, click
    Add
    in either the Allowed File Types area at the top of the screen, or in the Disallowed File Types area at the bottom of the screen.
    • Use the Allowed File Types area to add file types that the security policy considers legal, and to view information about each file type.
    • Use the Disallowed File Types area to add file types that the security policy considers illegal, and to exclude file types that are included in allowed wildcard file types.
    The screen displays fields applicable to your selection.
  5. If you chose to add Disallowed File Types, fill in the name.
  6. If you chose to add Allowed File Types, fill in these settings.
    1. For
      File type
      , select whether the file type is a wildcard or is explicit, and type a wildcard name or an explicit name.
    2. For
      Perform Staging
      , select the
      Enabled
      check box to have the system perform staging.
    3. For
      URL Length
      , type the maximum acceptable length, in bytes, of a URL containing this file type.
    4. For
      Request Length
      , type the maximum acceptable length, in bytes, of the request containing this file type.
    5. For
      Query String Length
      , type the maximum acceptable length, in bytes, for the query string portion of a URL that contains this file type.
    6. For
      POST Data Length
      , type the maximum acceptable length, in bytes, for the POST data of an HTTP request that contains the file type.
    7. For
      Apply Response Signature Staging
      , select the check box to apply response signature staging.
  7. To filter the list of file types by their enforcement readiness, select an option from the
    Enforcement Readiness
    setting.
    • To list all file types, select
      All
      .
    • To list file types that have one or more suggestions, select
      Has suggestion
      .
    • To list file types that are not being enforced, select
      Not enforced
      .
    • To list file types that are ready to be enforced, select
      Ready to be enforced
      .
  8. When you are finished, save your work.
The file types settings are updated to use the new settings, and any changes you made are put into effect in the working configuration of the BIG-IQ Centralized Management system.

Edit or add JSON content profile settings

You use JSON content profile properties to define what the application security policy enforces and considers legal when it detects traffic that contains JSON data.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the policy you want to modify, then on the left expand
    CONTENT PROFILES
    , and click
    JSON Profiles
    .
  3. Click the name of the JSON profile to modify, or click
    Add
    to create a new one.
  4. Review the existing name, or type a
    Profile Name
    for the new profile.
  5. Revise or type an optional
    Description
    for the profile.
  6. In the
    Maximum Total Length Of JSON Data
    field, type or revise the longest length, in bytes, allowed by the security policy of the request payload, or parameter value, where the JSON data was found.
    To have no length restriction, you can leave this field blank.
  7. In the
    Maximum Value Length
    field, type or revise the maximum acceptable length, in bytes, of the longest JSON element value in the document allowed by the security policy.
    To have no length restriction, you can leave this field blank.
  8. For
    Maximum Structure Depth
    , type or revise the greatest nesting depth found in the JSON structure allowed by the security policy.
    To have no depth restriction, you can leave this field blank.
  9. In the
    Maximum Array Length
    field, type or revise the largest number of elements allowed for arrays.
    To have no array length restriction, you can leave this field blank.
  10. For
    Tolerate JSON Parsing Warnings
    , specify whether to enable response signature staging.
    • Select the
      Enabled
      check box to specify that the system does not report when the security enforcer encounters warnings while parsing JSON content.
    • Clear the check box to specify that the security policy reports when the security enforcer encounters warnings while parsing JSON content.
  11. For
    Parse Parameters
    , specify whether to enable parameter parsing.
    • To enable parsing, select the
      Enabled
      check box.
    • When this setting is disabled, the system displays more main areas (such as Attack Signature Overrides, Meta Characters, and Sensitive Data Configuration) with additional properties for review and modification.
  12. Expand the Attack Signatures Overrides area to select any signature overrides. (This area is displayed only when
    Parse Parameters
    is disabled.)
    • For the
      Attack Signatures Check
      setting, select the
      Enabled
      check box.
    • For the
      Attack Signatures Overrides
      setting, select the signature from the list and then click
      Enabled
      or
      Disabled
      as needed for that signature.
  13. Expand the Meta Characters area to select how meta characters are handled. (This area is displayed only when
    Parse Parameters
    is disabled.)
    • For the
      Check Characters
      setting, select the
      Enabled
      check box.
    • For the
      Overrides
      setting, select the meta characters from the list and then click
      Allowed
      or
      Disallowed
      as needed.
  14. Expand the Sensitive Data Configuration area to select how sensitive data is handled. (This area is displayed only when
    Parse Parameters
    is disabled.)
    1. In the
      Sensitive Data
      setting, type an element name within the JSON data whose values the system should consider sensitive.
    2. Click
      Add
      to add the element name to the sensitive data list.
  15. Click
    Save
    to save your changes.

Edit or add XML content profile settings

You use XML content profile properties to define what the application security policy enforces and considers legal when it detects traffic that contains XML data.
  1. Navigate to the XML Profiles screen: click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the policy you want to work with, then, on the left, expand
    CONTENT PROFILES
    , and click
    XML Profiles
    .
  3. Click the name of the XML profile to modify, or click
    Add
    to create a new one.
  4. Review the existing name or type a
    Profile Name
    for the new profile.
  5. Review, revise, or type an optional
    Description
    for the profile.
  6. For the
    Use XML Blocking Response Page
    property, select the type of response page to send when the security policy blocks a client request that contains URL XML content that does not comply with the settings of this XML profile.
    • To have the system send an XML response page, select the
      Enabled
      check box.
    • To have the system send the default response page, do not select the
      Enabled
      check box.
  7. To configure the validation and defense settings of an XML profile, expand the XML Firewall Configuration area and modify those settings as needed.
  8. To configure the system to perform attack signature checks on the XML profile, expand the Attack Signatures area and modify those settings as needed.
  9. To change the security policy settings for specific meta characters in XML values on the XML profile, expand the Meta Characters area and modify those settings as needed.
  10. Expand the Sensitive Data Configuration area to program the system to mask sensitive data that appears in an XML document, as shown in the BIG-IP device configuration interface and internal Application Security logs.
  11. Click
    Save
    to save your changes.

Edit or add plain text content profile settings

You use plain text content profile properties to define what the application security policy enforces and considers legal when it detects traffic that contains plain text data.
  1. Navigate to the Plain Text Profiles screen: click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the policy you want to modify, at the left, expand
    CONTENT PROFILES
    , and click
    Plain Text Profiles
    .
  3. Click the name of the plain text profile to modify, or click
    Add
    to create a new one.
  4. Review the existing, or type a
    Profile Name
    for the new profile.
  5. Review, revise, or type an optional
    Description
    for the profile.
  6. In the
    Maximum Total Length
    field, type the longest length, in bytes, allowed by the security policy.
    You can leave this field blank to have no length restriction.
  7. In the
    Maximum Line Length
    field, type the longest line length, in bytes, allowed by the security policy.
    You can leave this field blank to have no length restriction.
  8. If you want the system to perform percent decoding, select the
    Perform Percent Decoding
    Enabled
    check box.
  9. To configure attack signature overrides, expand Attack Signatures Overrides and supply the needed values.
    1. In the
      Attack Signatures Check
      setting, select the
      Enabled
      check box.
    2. In the
      Attack Signatures Overrides
      setting, select one or more attack signatures to override.
    3. For each attack signature, select whether the override is enabled or disabled.
  10. To change the security policy settings for specific meta characters in values on the plain text profile, expand Meta Characters and supply the needed values.
    1. In the
      Check Characters
      setting, select the
      Enabled
      check box.
    2. In the
      Overrides
      setting, select one or more meta characters to override.
    3. For each meta character, select whether the override is allowed or disallowed.
  11. Click
    Save
    to save your changes.

Edit character set JSON settings

You can configure the security policy to allow or disallow certain characters if they appear in JSON values.
  1. Navigate to the JSON screen: click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the policy you want to work with, and on the left expand
    CONTENT PROFILES
    and
    CHARACTER SETS
    , then click
    JSON
    .
  3. Review the list of characters, and for each, determine whether it should be allowed or not.
    • To allow characters, select the check box in the Allowed column of the table row.
    • For characters that should not be allowed, clear the check box in the Allowed column of the table row.
    Use the View options to select which characters are displayed.
    • Click
      All Characters
      to display all characters.
    • Click
      Allowed
      to display only characters that are marked as allowed.
    • Click
      Disallowed
      to display only characters that are not allowed.
  4. Click
    Save
    to save your changes.

Edit character set plain text settings

You can configure the security policy to allow or disallow certain characters if they appear in plain text values.
  1. Navigate to the Plain Text screen: click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the appropriate policy, and on the left expand
    CONTENT PROFILES
    and
    CHARACTER SETS
    , then click
    Plain Text
    .
  3. Review the list of characters, and for each, determine whether it should be allowed or not.
    • To allow characters, select the check box in the Allowed column of the table row.
    • For characters that should not be allowed, clear the check box in the Allowed column of the table row.
    Use the View options to select which characters are displayed.
    • Click
      All Characters
      to display all characters.
    • Click
      Allowed
      to display only characters that are marked as allowed.
    • Click
      Disallowed
      to display only characters that are not allowed.
  4. Click
    Save
    to save your changes.

Edit character set XML settings

You can configure the security policy to allow or disallow certain characters if they appear in XML values.
  1. Navigate to the XML screen: click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the appropriate policy, and on the left expand
    CONTENT PROFILES
    and
    CHARACTER SETS
    , then click
    XML
    .
  3. Review the list of characters, and for each, determine whether it should be allowed or not.
    • To allow characters, select the check box in the Allowed column of the table row .
    • For characters that should not be allowed, clear the check box in the Allowed column of the table row.
    Use the View options to select which characters are displayed.
    • Click
      All Characters
      to display all characters.
    • Click
      Allowed
      to display only characters that are marked as allowed.
    • Click
      Disallowed
      to display only characters that are not allowed.
  4. Click
    Save
    to save your changes.

Add or edit parameter settings

You can add or edit settings for parameters that the security policy permits in requests, such as the parameter type and whether the parameter is allowed to contain an empty value. The default parameter is displayed for all policies, and can be edited. It is indicated by
*
(asterisk).
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click a policy name, and on the left, click
    PARAMETERS
    Parameters
    .
  3. You can add a new, or edit an existing, parameter.
    • To add a new parameter, click
      Add
      .
    • To edit an existing parameter, click the parameter name.
    The properties screen opens for the new or existing parameter.
  4. To remove the parameter from staging, select the check box for the parameter and click
    Enforce Selected
    .
  5. For a new parameter, for the
    Name
    setting, select the type, and then type a name for the new parameter.
    • Select
      explicit
      if this is a regular named parameter.
    • Select
      wildcard
      if any parameter name that matches the wildcard expression is permitted by the security policy. (For example, typing the wildcard
      *
      specifies that the security policy allows every parameter.) The syntax for wildcard entities is based on shell-style wildcard characters.
    • Select
      no name
      if this parameter does not have a name. The system automatically names the parameter
      no name
      and it behaves the same as an explicit parameter.
    The name setting cannot be changed once the parameter is created.
  6. For
    Level
    , select the level of parameters to be displayed.
    • Select
      global
      to display global parameters not associated with flows or URLs.
    • Select
      URL
      to display parameters associated with flows or URLs, select
      HTTP
      or
      HTTPS
      as the protocol, and then select the URL.
    If the security policy is configured to differentiate between HTTP and HTTPS URLs, then you can additionally filter URL parameters by the HTTP and HTTPS protocols.
  7. To enable or allow any of these settings, click the
    Enabled
    check box for the setting:
    • Select
      Perform Staging
      to display the staging status on this parameter.
    • Select
      Allow Empty Value
      to allow empty values.
    • Select
      Allow Repeated Occurrences
      to allow repeated occurrences.
    • Select
      Sensitive Parameter
      to, in a validated request, protect sensitive user input, such as a password or a credit card number. The contents of sensitive parameters are not visible in logs or in the user interface.
  8. Specify the
    Value type
    for the parameter.
    The value type you specify might display additional fields. You cannot change the value type after it is created.
    • Select
      dynamic-content
      for parameters whose data is dynamic.
    • Select
      ignore
      for parameters whose values the system does not check.
    • Select
      json
      for JSON parameters fetched from the server that are not editable.
    • Select
      static-content
      for parameters whose data is static. In the Parameter Static values area displayed at the bottom of the screen, supply a value in the
      Add New Value
      setting, and click
      Add
      . Add or subtract values as needed.
    • Select
      user-input
      for parameters whose data is provided by user-input. Use the
      Data type
      setting to provided additional information about the user input.
    • Select
      xml
      for XML parameters fetched from the server that are not editable. In the XML Profile area displayed at the bottom of the page, select an XML profile.
  9. For the
    Data type
    setting, select the data type to use for the user input.
    • Select
      email
      to specify that the data must be text in email format only. In the Data type attributes area, specify a value for the
      Maximum Length
      setting in bytes.
    • Select
      alpha-numeric
      to specify that the data can be any text consisting of letters, digits, and the underscore character.
      • In the Data type attributes area, specify a value for the
        Maximum Length
        setting in bytes, and select whether to enable regular expressions or Base64 encoding. When the
        Regular Exp
        setting is enabled, it specifies that the parameter value includes the specified parameter pattern. This is a positive regular expression that defines what is legal.
      • In the Value Meta Character area, select the
        Enabled
        check box and then select which meta character to allow or disallow as a value.
      • In the Attack Signatures area, select the
        Enabled
        check box and then select which attack signature overrides to enable or disable.
    • Select
      integer
      to specify that the data must be whole numbers only (no decimals). In the Data type attribute area, specify values for the
      Minimum Value
      ,
      Maximum Value
      , and
      Maximum Length
      settings.
    • Select
      decimal
      to specify that the data is numbers only and can include decimals. In the Data type attributes area, specify values for the
      Minimum Value
      ,
      Maximum Value
      , and
      Maximum Length
      settings.
    • Select
      phone
      to specify that the data can be text in telephone number format only. In the Data type attributes area, specify a value for the
      Maximum Length
      setting.
    • Select
      file upload
      to specify there is no text limit for the data (length checks only). In the Data type attributes area, specify a value for the
      Maximum Length
      setting, and specify whether to disallow file uploading or enable Base64 encoding.
  10. To filter the list of parameters by their enforcement readiness, select an option from the
    Enforcement Readiness
    setting.
    • To list all parameters, select
      All
      .
    • To list parameters that have one or more suggestions, select
      Has suggestion
      .
    • To list parameters that are not being enforced, select
      Not enforced
      .
    • To list parameters that are ready to be enforced, select
      Ready to be enforced
      .
  11. When you are finished, save your work.
The application security policy is updated to use the new settings.

Add or edit extraction settings

You use extraction settings to manage how the system extracts dynamic values for dynamic parameters from the responses returned by the web application server. An
extraction
is a subcollection that isolates a parameter from an object. Other subcollections (such as parameters) reference extractions by name (not by URL).
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies.
  2. Click the name of the policy and then on the left, click
    PARAMETERS
    Extractions
    .
  3. You can add a new or edit an existing extraction.
    • To add a new extraction, click
      Add
      .
    • To edit an existing extraction, click the extraction name.
    The properties screen opens for the new or existing extraction.
  4. For a new extraction, specify the
    Name
    of the dynamic parameter for which the system extracts values from responses.
    • For a named parameter, select
      New
      and type the name in the field.
    • For the
      UNNAMED
      parameter, select
      no name
      .
    The name setting cannot be changed once the extraction is created.
  5. In the Extracted Items Configuration area, specify the items from which the system should extract the values for dynamic parameters.
    Extract From
    • File Types
      . Specifies, when checked (enabled), that the system extracts the values of dynamic parameters from responses to requests for file types that exist in the security policy. To add a file type to be extracted, select an file type from the list, and click
      Add
      .
    • URLs
      . Specifies, when checked (enabled), that the system extracts the values of dynamic parameters from responses to requests for the listed URLs. To specify the URLs from which the system extracts dynamic parameter values, select either
      HTTP
      or
      HTTPS
      from the list, type the URL in the adjacent field, and click
      Add
      . If you enter a URL that does not yet exist in the security policy, the URL is added to the security policy.
    • RegEx
      . Specifies, when checked (enabled), that the system extracts the values of dynamic parameters from responses to requests that match the listed pattern (regular expression). Type the regular expression in the field.
    Extract From All Items
    Specifies when selected (enabled), that the system extracts the values of the dynamic parameters from all URLs found in the web application. Specifies when cleared (disabled), that the system extracts the values of the dynamic parameters from limited items found in the web application.
  6. In the Extracted Method Configuration area, specify the methods by which the system extracts the values for dynamic parameters.
    Search in Links
    Specifies, when checked (enabled), that the system searches for dynamic parameter values within links that appear in the response body.
    Search Entire Form
    Specifies, when checked (enabled), that the system searches for dynamic parameter values in the entire form found on a web page.
    Search Within Form
    Specifies, when checked (enabled), that the system searches for dynamic parameter values in a specific location within forms found on a web page that contains the dynamic parameter. You must provide all of this information:
    • Form Index
      . Type the HTML index of the form that contains the dynamic parameter.
    • Parameter Index
      . Type the HTML index of the input parameter within the form that contains it.
    Search Within XML
    Specifies, when checked (enabled), that the system searches for dynamic parameter values within the URL’s XML. Type the XPath specification in the
    XPath
    field.
    Search Response Body
    Specifies, when checked (enabled), that the system searches for dynamic parameter values in the body of the response. Use the additional options to further refine the search. You can specify one or more of the following options, but you must specify the RegEx value if you enable this setting.
    • Number of Occurrences
      .
      • All
        specifies a search for all incidences of the parameter values in the body of the request.
      • Number
        specifies that the search is restricted to the number you type in the box.
    • Prefix
      specifies that the system extracts values only if they are preceded by the HTML segment you type in the box.
    • Match Regular Expression Value
      specifies that the system extract must match the parameter pattern (regular expression) you type in the box. The default is
      .+?
      .
    • Suffix
      specifies that the system extracts values only if they are followed by the HTML segment that you type in the box.
  7. When you are finished, save your work.
The application security policy is updated to use the new settings.

Edit character set parameter name settings

You use character set parameter name settings in the security policy to allow or disallow certain characters in parameter names.
  1. Go to the Policies screen: Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Continue to the parameter name screen: Click the name of the policy and then, on the left, click
    PARAMETERS
    CHARACTER SETS
    Parameter Name
    .
  3. Review the list of characters, and for each, determine whether it should be allowed or not.
    • Select the
      Allowed
      check box for characters that should be allowed.
    • Clear the
      Allowed
      check box for characters that should not be allowed.
    Use the View options to select which characters are displayed.
    • Click
      All Characters
      to display all characters.
    • Click
      Allowed
      to display only characters that are marked as allowed.
    • Click
      Disallowed
      to display only characters that are not allowed.
  4. Click
    Save
    to save your changes.
The system updates the security policy to use the new character set parameter name settings.

Edit character set parameter value settings

You use character set parameter value settings in the security policy to determine whether the security policy allows those values in a request.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the policy and then, on the left, click
    PARAMETERS
    CHARACTER SETS
    Parameter Value
    .
  3. Review the list of characters, and for each, determine whether it should be allowed or not.
    • Select the
      Allowed
      check box for characters that should be allowed.
    • Clear the
      Allowed
      check box for characters that should not be allowed.
    Use the View options to select which characters are displayed.
    • Click
      All Characters
      to display all characters.
    • Click
      Allowed
      to display only characters that are marked as allowed.
    • Click
      Disallowed
      to display only characters that are not allowed.
  4. Click
    Save
    to save your changes.
The system updates the security policy to use the new character set parameter value settings.

Add sensitive parameters settings

You can add and delete sensitive parameters used by your security policy. Some requests include sensitive data, such as account numbers, in parameters. If you create sensitive parameters, the data in those parameters is replaced with asterisks (
***
) in the stored request and in logs.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the appropriate policy, and on the left click
    PARAMETERS
    Sensitive Parameters
    .
  3. Click
    Add
    to add a sensitive parameter.
    The Sensitive Parameter properties screen opens.
  4. In the
    Name
    setting, type the name of the sensitive parameter.
  5. Save your work.

Configure attack signatures

Attack signatures
are rules or patterns that identify attacks or classes of attacks on a web application and its components. You can configure aspects of attack signatures to specify whether the signatures should be put into staging before being enforced, and whether or not to apply signatures to responses.
  1. Go to the Policies screen: Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Continue to the Attack Signatures Configuration screen: Click the name of a policy, and on the left click
    Attack Signatures Configuration
    .
  3. Revise the settings as needed.
    • To enable staging of signatures, select the
      Signature Staging
      Enabled
      check box.
    • To place updated signatures in staging, select the
      Place updated signatures in staging
      Enabled
      check box. New signatures are always placed in staging, regardless of this setting.
    • For
      Attack Signature Set Assignment
      , select one or more signature sets from the list to be assigned to the policy, and then select the appropriate options for that signature set.
      • Select or clear the
        Learn
        ,
        Alarm
        , and
        Block
        options for each signature set.
        • Select
          Learn
          to have the security policy learn all requests that match enabled signatures in the signature set.
        • Select
          Alarm
          to have the security policy logs the request data if a request matches a signature in the signature set.
        • Select
          Block
          , to have the security policy block all requests that match a signature included in the signature set.
      • From the
        Actions
        list, select, if needed, whether to enable or enforce signatures in the signature set.
    • For
      Apply Response Signatures
      , select a file type, if needed. The default wildcard character indicates all file types.
  4. When you are finished, save your work.
The system updates the application security policy attack signatures settings.

View and modify attack signatures

You can view the list of attack signatures that belong to signature sets assigned to the policy, and specify whether they are enabled or in staging.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of a policy, and on the left click
    Attack Signatures
    .
  3. To restrict the number of signatures displayed, use the filter field at the upper right of the screen.
    You can select both basic and advanced filter options by clicking the arrow to the left of the field.
  4. To specify whether or not the attack signature is enabled, select the check box in the Enabled column of the table for that row.
  5. To have an attack signature placed in staging, select the check box in the In Staging column of the table for that row.
  6. When you are finished, save your work.
The system updates any modified attack signature settings.

Edit geolocation enforcement settings

You use geolocation enforcement to select which geolocations the policy does not allow.
  1. Navigate to the Geolocation Enforcement screen: click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the appropriate policy, and on the left, click
    Geolocation Enforcement
    .
  3. Select a geolocation that is not allowed by the policy from the
    Disallowed Geolocations
    list.
    Once you have selected the geolocation, it is listed below the drop-down list.
  4. You remove a selected geolocation from the list by clicking the
    X
    to the left of the geolocation name.
  5. Click
    Save
    to save your changes.
The system updates the list of geolocations that the policy does not allow.

Add or edit login page settings

You can view and manage login page settings for the security policy to better protect the login page URLs used by your web applications.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the policy to manage, and on the left click
    SESSIONS AND LOGINS
    Login Pages
    .
  3. You can add new, or edit existing login page settings.
    • Click
      Add
      to add a login page and settings.
    • Click the name of the login page to edit the settings.
    The Login Page Properties screen opens.
  4. In the
    Login URL
    setting, select the appropriate options for the URL.
    1. Specify whether the URL uses wildcards or is explicitly named. Select
      Wildcard
      or
      Explicit
      .
    2. Specify the URL protocol. Select
      HTTP
      or
      HTTPS
      .
    3. Select the URL to use, or select
      Custom URL
      and specify the URL.
  5. In the
    Authentication Type
    setting, select the type of authentication to use.
  6. In the Access Validation area, specify how the login page should be validated by typing one or more setting values.
    You define validation criteria on the response of the login URL. You must configure at least one of the validation criteria. If you configure more than one validation criteria, then all the criteria must be fulfilled in order to access the authenticated URL.
  7. Save your work.

Add or edit logout page settings

You can view and manage logout page settings for the security policy to better protect the logout page URLs used by your web applications.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the appropriate policy, and on the left click
    SESSIONS AND LOGINS
    Logout Pages
    .
  3. Specify whether you are adding or editing logout page settings.
    • Click
      Add
      to add a logout page and settings.
    • Click the name of the logout page to edit the settings.
    The Logout Page Properties screen opens.
  4. In the
    Logout URL (explicit only)
    setting, select the appropriate options for the URL.
    1. Specify the URL protocol. Select
      HTTP
      or
      HTTPS
      .
    2. Select the URL to use, or select
      Custom URL
      and specify the URL.
  5. In the
    A string that should appear in the response
    setting, type a string that should appear in the request (either the query string or in its payload) to indicate that the request is a logout request.
  6. In the
    A string that should NOT appear in the response
    setting, type a string that should not appear in the request (either the query string or in its payload) to indicate that the request is a logout request.
  7. Save your work.

Add or edit login enforcement settings

You can add and modify login enforcement properties. Login enforcement specifies the authenticated login URLs and logout URLs for the web application.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the appropriate policy, and on the left click
    SESSIONS AND LOGINS
    Login Enforcements
    .
  3. For the
    Expiration Time
    setting, specify whether you want the login session to expire.
    • If you do not want the login session to expire, click
      Disabled
      .
    • If you want the login URL to be valid for a limited time, click the button to the left of the
      Seconds
      field, and type a value, in seconds (1-99999), that indicates how long the session will last. The login session ends after the number of seconds has passed.
  4. For the
    Authenticated URLs
    setting, specify the target URLs that users can access only by using the login URL.
    1. In the provided field, type the target URL name in the format
      /private.php
      .
      Wildcards are allowed.
    2. Click
      Add
      to add the URL to the list of authenticated URLs.
    3. Repeat to add as many authenticated URLs as needed.
      You can remove a URL from the list of authenticated URLs by clicking
      X
      .
  5. Save your work.

Edit session tracking settings

You can enable session hijacking and session tracking to track, enforce, and report on user sessions and IP addresses.
  1. Click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Click the name of the policy to work on, and on the left click
    SESSIONS AND LOGINS
    Session Tracking
    .
  3. To enable session hijack detection, for the
    Detect Session Hijacking by Device ID Tracking
    setting, select the
    Enabled
    check box.
    Review the notes displayed.
  4. To configure session tracking, supply values for the following settings.
    1. Select the
      Session Awareness
      Enabled
      check box.
    2. For the
      Application Username
      setting, select the form of the username.
      • To use no application username, select
        None
        .
      • To use APM usernames and session IDs, select
        Use APM Usernames and Session ID
        .
      • To use individual login pages, select
        Use Individual Login Pages
        and then select the login page in the area provided.
      • To use all login pages, select
        Use All Login Pages
        .
  5. To configure violation detection actions, specify additional settings.
    1. For
      Track Violations and Perform Actions
      , select the
      Enabled
      check box.
    2. For
      Violation Detection Period
      , type the number of seconds for the detection period.
  6. In the Block All area, specify how the system performs when the Block All action is triggered.
  7. In the Log All Requests area, specify how the system performs when the Log All Requests action is triggered.
  8. In the Delay Blocking area, specify how the system performs when the Delay Blocking action is triggered.
  9. Save your work.

Adding security policies

You can use BIG-IQ Web Application Security to add new application security policies for later deployment.
  1. Navigate to
    Configuration
    SECURITY
    Web Application Security
    Policy Editor
    .
    Policies are listed on the Policies screen.
  2. In the Policies screen, click
    Add
    to display a screen for creating a new policy.
    The newly-created policy contains only the editable configuration (the configuration deployed to the BIG-IP device). It acquires the configuration default values from it.
  3. Specify the following information about the new Web Application Security policy:
    1. Type the
      Name
      (required) of the security policy.
    2. Specify the
      Partition
      (required) to which the security policy belongs.
      Only users with access to a partition can view the objects that it contains. If the security policy resides in the
      Common
      partition, all users can access it.
    3. For
      Application Language
      , select the language encoding (required) for the web application, which determines how the security policy processes the character sets.
      The default language encoding determines the default character sets for URLs, parameter names, and parameter values.
    4. For
      Enforcement Mode
      , specify whether blocking is active or inactive for the security policy.
      You can enable or disable blocking for individual violations in the subsequent tables of settings and properties. If
      transparent
      appears, blocking is disabled for the security policy. This disables blocking for all options, and the check boxes to enable blocking are unavailable.
  4. When you are finished editing the properties, click
    Save
    .
    This makes the remaining policy objects available for editing.
  5. In the Policy objects list on the left, click the next object to edit, and then click the
    Edit
    button.
    For the
    Attack Signatures List
    object only, click the
    Attack Signatures List
    object, then in the Name column, click the signature name you want to edit, then click
    Edit
    .
  6. Click
    Save
    to save the modifications to each policy object before moving to another one.
  7. Click
    Save
    when you are finished editing.
The newly-created policy is added to the list of application security policies, and the new policy object exists in the working configuration of the BIG-IQ system. At this point, you can add it to any virtual server object in Web Application Security.

Import application security policies

Before you import a security policy from another system, make sure that the attack signatures and user-defined signatures are the same on both systems. You also need access to the exported policy file.
You can use Web Application Security to import security policies that were previously exported from another BIG-IP Application Security Manager (ASM) system.
  1. Navigate to the Policies screen: click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. On the Policies screen, click the
    Import
    button.
  3. On the Import Policy screen, select the security policy file by clicking
    Choose File
    , and navigating to the file location.
    You can also drag and drop a file to the
    Drop Policy File Here
    field.
  4. Select a policy name for the imported policy if you like.
  5. Click
    Import
    .
After you have imported the policy, the system lists it in the Policies screen. The uploaded policy will have the same name as the XML file, unless you provided a policy name.
If you replaced an existing policy, the imported security policy completely overwrites the existing security policy. Also, the imported policy is then associated with the virtual server and local traffic policy that was previously associated with the policy you replaced. The replaced policy is automatically archived with the inactive security policies.

Export application security policies

You can use Web Application Security to export security policies. You can use the exported security policy as backup, or you can import it onto another system.
  1. Navigate to the Policies screen: click
    Configuration
    SECURITY
    Web Application Security
    Policies
    .
  2. Select the check box to the left of the security policy you want to export.
    The
    Export
    button becomes active.
  3. Click the
    Export
    button to show a list, and select the BIG-IP version to use when exporting this security policy.
The policy is exported.
You can use the exported security policy as a backup, or you can import it onto another system. Note that the exported security policy includes any user-defined signature sets that are in the policy, but not the user-defined signatures themselves.

Removing security policies

BIG-IQ Web Application Security provides a way to remove ASM application security policies from the BIG-IQ database.
  1. Log in to BIG-IQ Security with Administrator, Security Manager, or Web Application Security Manager credentials.
  2. Navigate to the Policies screen: click
    Web Application Security
    Policy Editor
    .
  3. Select the check box to the left of the security policy you want to remove.
    The
    Remove
    button becomes active.
  4. Click the
    Remove
    button.
  5. In the Remove Policies dialog box, confirm the removal by clicking
    Remove
    .
The application security policy is removed from the BIG-IQ system, and can be managed locally.