Manual Chapter : Central Policy Building

Applies To:

  • BIG-IQ Centralized Management

    8.4.0, 8.3.0, 8.2.0, 8.1.0

Updated Date: 07/07/2026

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).

    Note: 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.

If your system requires added security for transactions between BIG-IP and the Central Policy Builder (CPB), you must enable the secure setting on your Data Collection Devices (DCDs), and replace the default SSL certificate with a certificate issued by a trusted CA (Certificate Authority). If you do not perform these procedures, the system will not provide policy suggestions. For more information about configuring CBP, see Configuring Central Policy Builder.

Important: The default CPB is enabled once Web Application Security is activated on the DCD’s services. Do not perform these tasks if you do not require additional security for your CPB connection.

To replace the default SSL certificate, review the following article: K52425065 on support.f5.com.

Note: When replacing the SSL certificate use the procedure Generating a new CSR and a new SSL private key . Do not apply a new self-signed certificate.

To enable a secure connection for CPB on your DCDs, go to System > BIG-IQ DATA COLLECTION > BIG-IQ Data Collection Devices and select the link in the Service column. Once you are on the selected device’s SERVICES screen, click ENABLE for the Secure Policy Builder field.

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.

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

    Important: Users who managed devices running Web Application Security that require added protection for the connection between BIG-IP and the Central Policy Builder, must enable Secure Policy Builder and replace the default SSL certificate with a certificate issued by a trusted CA (Certificate Authority). If the SSL certificate is not replaced, the system will be unable to provide policy suggestions under Secure Policy Builder. Users who do not enable a secure connection do not need to perform the certificate replacement task.

    Replace the default SSL certificate with a new certificate signing request (CSR) and a new SSL private key by a trusted CA (Certificate Authority). For more information about generating and new CSR and a new SSL private key (not self-signed), see: K52425065 on support.f5.com.

  • 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.

    Note: *The following is recommended for the learning period before the policy goes into production. Once in production, this process is not recommended, as it is not longer necessary and can consumes a large amount of space.

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.

      Once you activate this service, Central Policy Builder is enabled on the selected DCD.

    4. (Optional) To enable a added security for the connection between BIG-IP and Central Policy Builder, select Enable for the Secure Policy Builder setting.

      Important: If you enable this option please ensure you have completed the pre-requisites for establishing a secure connection with the DCDs.

    5. Save your work.

    6. 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.

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 Daysand 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 URLssetting, 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. Note: 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.

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.

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.

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.

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.

      Note: 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.

      Note: 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.

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.

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.

Note: When adding URLs, you can type either explicit (/index.html) or wildcard (*xyz.html) URLs.
  1. When you are finished, save your work.

The policy is updated to use the new Data Guard 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.