Managing Application Security Policies in BIG-IQ Web Application Security

Manual Chapter : Managing Application Security Policies in BIG-IQ Web Application Security

Applies To:

Show Versions

BIG-IQ Centralized Management

5.1.0

About security policies in BIG-IQ Web Application Security

BIG-IQ^® Web Application Security imports 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 BIG-IQ 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 user interface.

The following are the supported versions of the BIG-IQ 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 system support, such as the minimum 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 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
Signatures	Yes	Yes	Any
Signature Sets and attack signature configuration	Yes	Yes	Any	No support for manual sets.
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	No	Any
Allowed methods	Yes	Yes	Any
Headers	Yes	Yes	Any
Cookies	Yes	No	Any
Host names	Yes	No	Any
Geolocation enforcement	Yes	No	11.6.0
IP Intelligence	Yes	No	11.6.0
Redirection protection	Yes	No	11.6.0
Sensitive parameters	Yes	No	Any
Web scraping	Yes	No	12.0.0
CSRF protection	Yes	No	11.6.0
JSON Profiles	Yes	No	11.6.0
XML Profiles	Yes	No	11.6.0
GWT Profiles	Yes	No	11.6.0
URLs	Yes	No	Any
Login Pages	Yes	No	11.6.0
Login Enforcement	Yes	No	11.6.0
Brute Force Attack Preventions	Yes	No	11.6.0
Session Tracking Configuration	Yes	No	11.6.0	Only configuration is supported, there is no support for online tracking data.

Editing security policies

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.

Log in to BIG-IQ Security with Administrator, Security Manager, or Web Application Security Manager credentials.
Navigate to the Policies screen: click Web Application Security > Policy Editor .
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.
Edit the properties of each policy object as appropriate. Click the object to edit in the Policy objects list, and click the Edit button on the right.
For the Attack Signatures List object only, click the Attack Signatures List object, then click the signature name to edit in the Name column and click Edit.
Consult the documentation for each policy object to edit it individually.
Click Save to save the modifications to each object and unlock the policy.

Changes to the policy object are saved in the working-config of the BIG-IQ system. Assuming the policy is assigned to a virtual server, the next deployment task sends the new configuration to one or more BIG-IP devices.

Editing properties settings

Log in to BIG-IQ Security with Administrator, Security Manager, or Web Application Security Manager credentials.
Navigate to the Properties screen: click Web Application Security > Policy Editor , select a policy name, and from the Policy objects list, select Properties.
In the Properties screen, click the Edit button.
The policy is placed under administrative lock and fields become editable.
Edit the properties as appropriate.
Click Save to save the modifications to each object and unlock the policy.

The system saves changes in the working configuration of the BIG-IQ system. Assuming the policy is assigned to a virtual server, the next deployment task sends the new configuration to one or more BIG-IP devices.

Properties settings

These properties are the general configuration options and settings that determine the overall behavior and functionality of the security policy.

Property	Description
Name	Unique name of the security policy. The Name field is editable only on policy creation.
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. Note: This field is limited to 255 characters.
Full Path	Full path to which the security policy belongs.
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 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.
Learning Mode	Select one of the options: 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. If 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. If 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	Use the control to indicate 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	If enabled, credit card numbers are masked in the request log. If disabled (cleared), credit card numbers are not masked.
Maximum HTTP Header Length	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	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: 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. Note: 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. Note: Path parameters are extracted from requests, but not extracted in responses.

Editing blocking settings

You can view and edit the application security policy blocking settings to specify how the system responds (learn, alarm, or block) to a request that contains each type of illegal request. You edit the blocking settings for each policy object individually.

Log in to BIG-IQ Security with Administrator, Security Manager, or Web Application Security Manager credentials.
Navigate to the Blocking Settings screen: click Web Application Security > Policy Editor , select a policy name, and from the Policy objects list, select Blocking Settings .
In the Blocking Settings screen, click the Edit button.
The policy is placed under administrative lock and fields become editable.
Click the arrows to open or close each category and display specific violation types available to configure for that category.
Edit the settings to meet your requirements.
When you are finished, click Save to save the modifications and unlock the policy.

The blocking settings are updated to use the new settings and any changes made are put into effect in the working configuration of the BIG-IQ ^®system.

Blocking settings

Blocking Setting	Description
Enforcement Mode	Specifies 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.
General Features	Request length exceeds defined buffer size: The incoming request is larger than the buffer for the Security Enforcer parser. Illegal session ID in URL: The incoming request contains a session ID value that does not match the session ID value from a previous request from the same client. Illegal meta character in value: The incoming request includes a parameter, or content, whose value contains an illegal meta character, according to the security policy. Illegal HTTP status in response: The server response contains an HTTP status code that is not defined in the security policy. Failed to convert character: The incoming request contains a character that does not comply with the encoding of the web application (the character set of the security policy), and the Policy Enforcer cannot convert the character to the current encoding. Virus Detected: The incoming request contains a virus detected by the system. Illegal Base64 value: The incoming request contains data (parameters, cookies, or headers) that does not contain a valid Base64 string in its value.
HTTP protocol compliance failed	When the check box is cleared, the system does not enforce this sub-violation. Content length should be a positive number: Specifies, when checked (enabled), that the system examines requests to see whether their content length value is greater than zero, which is required. The default setting is enabled. High ASCII characters in headers: High ASCII characters in headers: Specifies, when checked (enabled), that the system inspects request headers for ASCII characters greater than 127, which are not permitted. The default setting is disabled. Bad HTTP version: Specifies, when checked (enabled), that 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 Chunked request with Content-Length header: Specifies, when checked (enabled), that the system examines chunked requests for a content-length header, which is not permitted. The default setting is enabled. POST request with Content-Length: 0: Specifies, when checked (enabled), that the system examines POST method requests for no content-length header, and for a content length of 0. The default setting is disabled. Check maximum number of parameters: Specifies, when checked (enabled), that 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 security policy should be considered a possible attack on the server. Type a number in the box to specify how many parameters are allowed. The default value is enabled set to a maximum of 500 parameters. Host header contains IP address: Specifies, when checked (enabled), that the system verifies that the request’s host header value is not an IP address. The default setting is disabled. Header name with no header value: Specifies, when checked (enabled), that the system checks requests for valueless header names, which are considered illegal. The default setting is enabled. Bad multipart/form-data request parsing: Specifies, when checked (enabled), that the system examines requests to see whether the content-disposition header field contains the required parameters, name=“param_key”. The default setting is enabled. Multiple host headers: Specifies, when checked (enabled), that 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: Specifies, when checked (enabled), that 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. CRLF characters before request start: Specifies, when checked (enabled), that 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: Specifies, when checked (enabled), that the system compares the number of headers in the requests against the maximum number you specify here. Type a number in the box to specify how many headers are allowed. The default setting is enabled with a maximum of 20 headers unless the security policy is based on an Application-Ready security policy template. In this case, the default value depends on which template you are using. Several Content-Length headers: Specifies, when checked (enabled), that 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. Body in GET or HEAD requests: Specifies, when checked (enabled), that 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. Bad host header value: Specifies, when checked (enabled), that the system inspects requests to see whether they contain a non RFC compliant header value. The default value is enabled. Null in request: Specifies, when checked (enabled), that the system inspects requests to see whether they contain a Null character, which is not allowed. The default setting is enabled. Bad multipart parameters parsing: Specifies, when checked (enabled), that 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. Unparsable request content: Specifies, when checked (enabled), that 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	When the check box is cleared, the system does not enforce this sub-violation. 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. 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. %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. IIS backslashes: Indicates that the system turns backslashes (\) into slashes (/). The system performs this action on URI 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. 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. Multiple decoding (considered an evasion after a specified number of decoding passes): Indicates that the system performs multiple decoding. 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. Use the decoding passes control to specify the number (up to 5) of decoding passes.
File Types	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. Illegal query string length: The incoming request contains a query string whose length exceeds the acceptable length specified in the security policy. Illegal request length: The incoming request length exceeds the acceptable length specified in the security policy per the requested file type. Illegal URL length: The incoming request includes a URL whose length exceeds the acceptable length specified in the security policy. Illegal file type: The incoming request references file types not found in the security policy. Illegal POST data length: The incoming request contains POST data whose length exceeds the acceptable length specified in the security policy.
URLs	Illegal flow to URL: The incoming request references a flow that is not found in the security policy. Illegal number of mandatory parameters: The incoming request contains either too few or too many mandatory parameters. Illegal meta character in URL: The incoming request includes a URL that contains an illegal meta character, according to the security policy. Click the arrow icon to view and edit the URL character set. Illegal query string or POST data: The incoming request contains a query string or POST data that is not found in the security policy. Illegal URL: The incoming request references a URL that is not found in the security policy. Illegal request content type: The incoming request for a URL contains header content that is not allowed according to the requested URL’s Header-Based Content Profile Parsed As setting. Illegal entry point: The incoming request references an entry point that is not found in the security policy.
Parameters	Illegal empty parameter value: The incoming request contains a parameter whose value is empty when it should have contained a value. Illegal repeated parameter name: The incoming request contains multiple parameters with the same name. Illegal parameter value length: The incoming request contains a parameter whose value length does not match the value length that is defined in the security policy. This violation is relevant only for user input parameters. Illegal value does not comply with regular expression: The incoming request contains an alphanumeric parameter value that does not match the expected pattern specified by the regular-expression field for that parameter. Null in multi-part parameter value: The incoming multi-part request has a parameter value that contains a NULL character (0x00). Illegal parameter date type: The incoming request contains a parameter for which the data type (for example, alphanumeric) does not match the data type that is defined in the security policy. Illegal static parameter value: The incoming request contains a static parameter whose value is not defined in the security policy. Illegal dynamic parameter value: The incoming request contains a dynamic parameter value that does not comply with the security policy. Illegal parameter: The incoming request contains a parameter that is not defined in the security policy. Disallowed file upload content detected: load content detected: The incoming request contains a user-input File Upload parameter whose value contains binary executable content, and the security policy disallows this. Illegal parameter numeric value: The incoming request contains a parameter whose numeric value is not within the range of decimal or integer values defined in the security policy. Illegal meta character in parameter name: The incoming request includes a parameter name that contains an illegal meta character, according to the security policy. Click the arrow icon to view and edit the parameter name character set.
Sessions and Logins	Login URL bypassed: The user accessed the target URL without having first visited the login URL configured in the security policy. Click the arrow icon to view and edit the security policy’s login enforcement configuration. Brute Force: Maximum login attempts are exceeded: The number of times a user tried to log on to a URL is more than what is allowed by the security policy. This indicates an attempt to access secured parts of the website by guessing user names and passwords. Click the arrow icon to view and edit the security policy’s brute force configuration. Access from disallowed User/Session/IP: The system detected that the number of violations from the same User/Session/IP address within the specified time frame is above the configurable limit within session awareness. Click the arrow icon to view and edit the security policy’s session tracking configuration. Login URL expired: The login URL configured in the security policy timed-out. Click the arrow icon to view and edit the security policy’s login enforcement configuration.
Cookies	Cookie not RFC-compliant: The format of the Cookie header in the request does not comply with the standards as specified in the RFCs for HTTP. Illegal cookie length: The incoming request includes a cookie that exceeds its length setting in the security policy. Click the arrow icon to open the Security Policy Properties screen. Modified domain cookie(s): The domain cookie(s) in the HTTP request does/do not match the original domain cookies. ASM cookie Hijacking: The incoming request contains an Application Security Manager (ASM) cookie that was created in another session. Modified ASM cookie: The incoming request contains an Application Security Manager (ASM) cookie that has been modified or tampered with. Expired timestamp: The time stamp in the HTTP cookie is old, which indicates that a client session has expired.
Content Profiles	XML data does not comply with format settings: The incoming request contains XML that does not match at least one of the XML defense configuration settings configured in the security policy. Malformed JSON data: The incoming request contains JSON content that is not formed according to the general JSON formatting rules. Click the arrow icon to view JSON profiles that exist in the security policy. XML data does not comply with schema or WSDL document: The incoming request contains an XML document that does not adhere to the rules of a schema or WSDL document defined in an XML profile configured in the security policy. Malformed GWT data: The incoming request contains data that is not formed according to the general GWT formatting rules. Click the arrow icon to view GWT profiles that exist in the security policy. Malformed XML data: The incoming request contains an XML document whose structure is not formed according to the general XML formatting rules. Click the arrow icon to view XML profiles that exist in the security policy. JSON data does not comply with format settings: The incoming request contains JSON content that does not comply with the request limits of a JSON profile configured in the security policy. SOAP method not allowed: The incoming request invokes an illegal SOAP method according to an XML profile configured in the security policy. Illegal attachment in SOAP message: The incoming request contains a SOAP message in which there is an attachment that is not permitted by the security policy. GWT data does not comply with format settings: The incoming request contains data that does not comply with the various payload limits of a GWT profile configured in the security policy.
Web Services Security Failure	Certificate Error: Specifies, when checked (enabled), that 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. Expired Timestamp: Specifies, when checked (enabled), that the system learns, logs, or blocks requests when the timestamp has expired. The default setting is enabled. Missing Timestamp: Specifies, when checked (enabled), that the system learns, logs, or blocks requests when the timestamp is missing from the document. The default setting is enabled. Verification Error: Specifies, when checked (enabled), that 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. Internal Error: Specifies, when checked (enabled), that 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. Timestamp expiration is too far in the future: Specifies, when checked (enabled), that the system learns, logs, or blocks requests when the timestamp lifetime is greater than configured. The default setting is enabled. Encryption Error: Specifies, when checked (enabled), that 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. Signing Error: Specifies, when checked (enabled), that 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. UnSigned Timestamp: Specifies, when checked (enabled), that the system learns, logs, or blocks requests when the timestamp is not digitally signed. The default setting is enabled. Invalid Timestamp: Specifies, when checked (enabled), that the system learns, logs, or blocks requests when the timestamp is not formatted according to the specifications. The default setting is enabled. Decryption Error: Specifies, when checked (enabled), that 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. Malformed Error: Specifies, when checked (enabled), that 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. Certificate Expired: Specifies, when checked (enabled), that 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.
CSRF Protection	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 enabled, this setting specifies that you want the system to protect the web application against CSRF attacks. Click the arrow icon to view and edit the security policy’s CSRF protection configuration. 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	Access from disallowed Geolocation: The incoming request is sent from a country that is configured as disallowed in the security policy. Click the arrow icon to view and edit the security policy’s geolocation enforcement configuration. Access from malicious IP address: The incoming request is sent from an IP address that is considered high risk according to an IP Address Intelligence database. Click the arrow icon to view and edit the security policy’s IP address intelligence configuration.
Headers	Illegal meta character in header: The incoming request includes a header whose value contains an illegal meta character, according to the security policy. Click the arrow icon to view and edit the security policy’s headers character set. Illegal header length: The incoming request includes a header that exceeds its length setting in the security policy. Click the arrow icon to navigate to the security policy properties screen where you can view and edit the maximum HTTP header length. Illegal method: The incoming request references an HTTP request method that is not found in the security policy. Click the arrow icon to view and edit the security policy’s allowed methods. Mandatory HTTP header is missing: The request does not include an HTTP header that is configured in the security policy as being mandatory.
Redirection Protection	Illegal redirection attempt: The server tries to redirect the user to a target domain that is not defined in the security policy.
Data Guard	Specifies which information the system considers sensitive, including credit card numbers, U.S. Social Security numbers, custom patterns, and file content. Data Guard: Information leakage detected: The response from the web server includes data commonly considered sensitive.

Editing response page settings

You can view and edit the default response page, the login page response, the XML response page, and the AJAX response page.

Response page settings specify the content of the response that the system sends to the user when the security policy blocks a client request. You can also configure a redirect URL so that the system redirects the client to another location instead of displaying a response page. Edit the response pages for each policy object individually.

Log in to BIG-IQ Security with Administrator, Security Manager, or Web Application Security Manager credentials.
Navigate to the Response Page screen: click Web Application Security > Policy Editor , select a policy name, and from the Policy objects list, select Response Page.
In the Response Page screen, click the Edit button to revise the settings as needed.
The policy is placed under administrative lock and fields become editable.
Edit the default response page to specify the content of the response that the system sends to the user when the security policy blocks a client request: Click the Default Response Page tab and from the Response Type list, select one of the options.
- Default Response: Specifies the system-supplied response text written in HTML. You cannot edit this text.
- Custom Response: Specifies a modified response text. The system provides additional options where you can type the response header and response body you prefer. Click Upload to browse to and select a file. When you click Open, the contents of the file are loaded into the Response Body field.
- Redirect URL: Type a URL that the system is to use to redirect the user to a specific web page instead of viewing a response page.
- SOAP Fault: Displays the system-supplied response written in SOAP fault message structure. Use this type when a SOAP request is blocked due to an XML related violation. You cannot edit this text.
Edit the login page response to specify the response that the system sends after the user violates one of the preconditions when requesting the target URL of a configured login page: Click the Login Page tab and select one of the options.
- Default Response: Specifies the system-supplied response text written in HTML. You cannot edit this text.
- Custom Response: Specifies a modified response text. The system provides additional options where you can type the response header and response body you prefer. Click Upload to browse to and select a file. When you click Open, the contents of the file are loaded into the Response Body text box.
- Redirect URL: Type a URL that the system is to use to redirect the user to a specific web page instead of viewing a response page.
- SOAP Fault:Displays the system-supplied response written in SOAP fault message structure. Use this type when a SOAP request is blocked due to an XML related violation. You cannot edit this text.
Click the XML Response Page tab and then select an option from the Response Type list to display and edit settings.
- SOAP Fault: Displays the system-supplied response written in SOAP fault message structure. Use this type when a SOAP request is blocked due to an XML-related violation. You cannot edit this text.
- Custom Response: Specifies a modified response text. The system provides additional options where you can type the response header and response body you prefer.
The system sends the XML response page when the security policy blocks a client request that contains XML content that does not comply with the settings of an XML profile configured in the security policy.
Click the AJAX Response Page tab and then select the Ajax Blocking Enabled check box to display and edit settings.
When enabled, the system injects JavaScript code into responses. You must select this check box to configure an Application Security Manager AJAX response page which is returned when the system detects an AJAX request that does not comply with the security policy. The default setting is disabled.
1. Default Response Page Action: Specifies which content, or URL, the system sends to the client as a response to an AJAX request that does not comply with the security policy. Select from the following actions:
  - - Custom Response: Click the Upload link and select the file containing the text that is to serve as the custom response. The text box is populated with the text.
    - Popup Message: Accept the default text or type a message.
    - Redirect URL: Type a URL (required).
2. Login Page Response Action: Specifies which content, or URL, the system sends to the client after the user sends an AJAX request that attempts to directly access a URL that is allowed to be accessed only after visiting a login page. Select from the following actions:
- Custom Response: Click the Upload link and select the file containing the text that is to serve as the custom response. The text box is populated with the text.
- Popup Message: Accept the default text or type a message.
- Redirect URL: Type a URL (required).
When you are finished, click Save to save the modifications and unlock the policy.

The response page settings are updated to use the new settings and any changes made are put into effect in the working configuration of the BIG-IQ system.

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

Log in to BIG-IQ Security with Administrator, Security Manager or Web App Security Manager credentials.
Navigate to the Policy objects screen: click Web Application Security > Policy Editor , select a policy name, and click Data Guard.
At the right of the screen, click Edit.
The policy is placed under administrative lock and fields become editable.

For the Data Guard setting, select how the system treats sensitive data:

Option	Description
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	Specifies the system considers U.S. security card numbers as sensitive data.
Mask sensitive data	When checked, the system masks sensitive data returned by the web server by returning asterisk ( * ) characters to the client instead of the sensitive data.

When disabled, the system sends the response, including the sensitive information, to the user.

If the policy's enforcement mode is Transparent and the Mask Data check box is selected, the system encodes the sensitive data by returning asterisks to the client instead of the sensitive data. (The system also returns asterisks if the enforcement mode is Blocking, the Data Guard: Information leakage detected violation Block check box is cleared, and the Alarm check box is checked.) If the policy’s enforcement mode is Blocking, and the Block check box for the Data Guard: Information leakage detected violation is checked, the system blocks the response.

To have the system recognize customized patterns as sensitive data, select the Custom Patterns check box and then type in the field a pattern you want the system to consider as sensitive data, and click Add.
Use PCRE regular expression syntax. For example, 999-[/d][/d]-[/d][/d][/d][/d].

To delete a selected pattern, click the x.
To have the system recognize exception patterns as not being sensitive data, select the Exception Patterns check box and then type in the text box a pattern you want the system to consider as an exception to sensitive data, and click Add.
Use PCRE regular expression syntax. For example, 999-[/d][/d]-[/d][/d][/d][/d].

To delete a selected pattern, click the x.
To specify whether or not the system checks responses for file content, and if so, which types of file content are considered as sensitive data (and not returned to users), select the File Content Detection check box. The default setting is cleared (disabled). When checked (enabled), the system displays possible types of content the system could consider as sensitive data. You must select at least one check box.

To specify the URLs for which the system enforces Data Guard protection and the URLs it ignores, select one of the check boxes shown when File Content Detection is checked.

Option	Description
Enforce URLs in List	The system enforces data guard protection only for those URLs in the Enforcement Mode list. It enforces Data Guard protection for these URLs even if they are not in the policy. Type a URL in the text box and click Add. Note: When adding URLs, you can type either explicit (/index.html) or wildcard (*xyz.html) URLs.
Ignore URLs in List	The system enforces data guard protection for all URLs except for those URLs in the Enforcement Mode list (default). Add a URL to the list by typing in the field and clicking Add. Note: When adding URLs, you can type either explicit (/index.html) or wildcard (*xyz.html) URLs.

When finished, click Save to save the modifications and unlock the policy.

The Data Guard settings are updated to use the new settings and any changes made are put into effect in the working configuration of the BIG-IQ^® system.

Editing Headings and Methods settings

In the application security policy, you can view and edit (modify, add, and delete):

Allowed methods. You can specify methods 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.
HTTP headers. You can specify a list of request headers for other web applications hosted in different domains to use when requesting this URL.

Log in to BIG-IQ Security with Administrator, Security Manager, or Web Application Security Manager credentials.
Navigate to the Headers and Methods screen: click Web Application Security > Policy Editor , select a policy name, and from the Policy objects list, select Headers And Methods.
In the Headers and Methods screen, click the Edit button.
The Add and Delete buttons become visible. Settings become editable and the policy is placed under administrative lock.
In the Allowed Methods area, click Add to add a method and specify how it will function.
1. From the Method list, select a method.
2. Specify whether the method should act as the GET method or as the POST method.
  - GET. Specifies that the request does not contain HTTP data following the header part of the request.
  - POST. Specifies that the request contains HTTP data following the header part of the request.
3. When you are finished, click Save.
  The new method is added to the Allowed Methods table. The method appears in blue meaning that you can edit it and you can also delete it.
In the HTTP Headers area, click Add.
The system can perform normalization and attack signature checks on HTTP headers. In this context, headers refers to HTTP request headers, not response headers.
1. Select or modify the settings as appropriate.
  - Name. From the list, select the name of the HTTP header.
  - 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 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.
    Header normalization is a process whereby the Application Security Manager™ buffers the contents of request headers to change them into a standard format that can be more easily checked for discrepancies.
    
    Normalizing deals with special characters (such as percent encoding), non-ASCII text, URL paths and parameters, Base64 encoded binary content, non-printable characters, HTML codes, and many other formats that may be used in headers that could potentially hide malicious code.
    
    You do not need to normalize all headers. You should normalize referer headers, and custom headers containing binary data, URLs, or other encoded information. There is a performance trade-off when using normalization, so implement it only when needed.
    Select the type of normalization to be performed.
  - Evasion Techniques Violations. Coding methods that attackers use to avoid detection by attack signatures and intrusion prevention systems.
2. When you are finished, click Save.

The system updates the Headers and Methods settings to use the new settings, and puts any changes made into effect in the working configuration of the BIG-IQ^® system.

Editing IP address settings

You can view and edit configured IP address exceptions, including particular characteristics, such as:

Never blocking nor logging traffic sent from configured IP address exceptions.
Not generating Learning Suggestions for traffic sent from configured IP address exceptions.
Always allowing traffic sent from configured IP address exceptions.

Log in to BIG-IQ Security with Administrator, Security Manager, or Web Application Security Manager credentials.
Navigate to the IP Address screen: click Web Application Security > Policy Editor , select a policy name, and from the Policy objects list, select IP Address.
In the IP Address screen, click the Edit button.
The policy is placed under administrative lock and fields become editable.
Click Add new IP.
1. Type an IP address.
  Enter the 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.
2. Type a netmask.
  If you omit the netmask value, the system uses a default value of 255.255.255.255.
3. Select Settings as appropriate.
  - Policy Builder Trusted IP. Select 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.
  - Ignore in Anomaly Detection. Select 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.
  - Ignore in Learning Suggestion. Select to specify that the system not generate learning suggestions from traffic sent from this IP address.
  - Never block traffic from this IP Address. Select to specify that the system not block requests sent from this IP address, even if the security policy is configured to block all traffic.
  - Never log traffic from this IP Address. Select 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.
  - Ignore in IP Address Intelligence. Select 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.
4. Enter a brief description for the IP address.
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^® system.

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

Log in to BIG-IQ Security with Administrator, Security Manager or Web App Security Manager credentials.
Navigate to the File Types screen: (click Web Application Security > Policy Editor , select a policy name) and click File Types.
Click Edit, then click Add and specify either:
- Allowed file type: To add file types in the web application that the security policy considers legal, and to view information about each file type.
- Disallowed file type: To add file types in the web application 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.
If you selected Allowed file type, fill in the settings.
1. For File type, select either option and type a name. Explicit: Specifies that the system displays only explicit file types. Wildcard: Specifies that the system displays only wildcard file types.
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, 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.
If you selected Disallowed file type, fill in the name and click Save.
When you are finished, click Save to save the modifications and unlock the policy.

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^® system.

Editing parameters settings

You can view and edit settings for parameters, such as the parameter type and whether the parameter is allowed to contain an empty value. In addition, depending on the parameter type, you can view the parameter’s values, extraction methods, enabled attack signatures, and allowed regular expressions.

The GUI lists the configured parameters in a table of 5 columns: check box, Name, Value Type, Level, Staging. The name of the parameter is a link for entering the detail and/or edit mode for the parameter. A default parameter exists for all policies: * (asterisk). It is a pure wildcard with a value type of user-input, a level of global, and staging enabled.

Use the filter to search the column values of the parameter (Name, Value Type, Level, Staging).

Using BIG-IQ^® Web Application Security's support for extractions, you can:

Define a parameter’s characteristics and add them to the policy by clicking Edit. The policy is placed under administrative lock and the fields become editable. To unlock, click Unlock.
Create a new parameter by first clicking Edit and then Add.
Delete a parameter by clicking Edit to enter edit mode, selecting the check box of the parameter, clicking Delete, and clicking Yes to confirm.
From the parameters list, you can select directly by clicking the parameter or you can select multiple parameters using the selection check box. Once selected, you can delete by clicking clicks Delete and confirming.

Log in to BIG-IQ with Administrator, Security Manager, or Web Application Security Manager credentials.
Navigate to the Parameters screen: click Web Application Security > Policy Editor , select a policy name, and from the Policy objects list, select Parameters.
On the Parameters screen, be sure the Parameterstab is selected.
On the Parameters screen, click the Edit button.
The policy is placed under administrative lock, and the fields become editable.
To add a new parameter, click Add.

In the Parameter details area, specify parameter details.

Option	Description
Name	Note that you cannot change the Name after creation, but you can add a parameter with the same name but a different level. explicit. Specifies that this a regular named parameter. wildcard. Specifies that 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. unnamed. Specifies that this parameter does not have a name. The system automatically names the parameter UNNAMED. Behaves the same as an explicit parameter. The system configures one unnamed parameter per policy. It is an explicit parameter with an empty name.
Level	Specifies whether or not the screen displays the parameters filtered by level. From the list, select global (parameters not associated with flows or URLs) or URL (parameters associated with specific URLs). 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.
Perform Staging	Displays the staging status on this parameter (Enabled if checked or Disabled). Entities in staging do not cause violations, which allows you to fine-tune their settings without causing false positives.
Allow Empty Value	Select to enable (allow empty value).
Allow Repeated Occurrences	Select to enable (allow repeated occurrences).
Sensitive Parameter	In a validated request, protects sensitive user input, such as a password or a credit card number. The contents of sensitive parameters are not visible in logs nor in the user interface. The status is Enabled if checked.
Value Type	Note that you cannot change the Value Type after creation. From the list, select among supported types. user-input. Specifies parameters whose data are provided by user-input. ignore. Specifies parameters whose values the system does not check. XML. Specifies parameters fetched from server and not editable. JSON. Specifies parameters fetched from server and not editable. dynamic-content.
Data Type	Specifies whether the screen displays parameters, whose data is provided by user-input, based on their data type. From the list, select among supported types. email. Specifies parameters whose data must be text in email format only. alpha-numeric. Specifies parameters whose data can be any text consisting of letters, digits, and the underscore character. The system provides additional options for this parameter’s values to contain meta characters, or to match regular expressions. integer. Specifies parameters whose data must be whole numbers only (no decimals). decimal. Specifies parameters whose data is numbers only and can include decimals. phone. Specifies parameters whose data can be text in telephone number format only.

In the Data type attributes area, specify whether or not the screen displays parameters, whose data is provided by user input, based on their data type.

Option	Description
Maximum Length	Specifies that this parameter’s value has a restricted maximum length. The system considers as illegal any request that passes this parameter’s value with a larger length. To set the maximum length, type in the box the maximum length (number of bytes) this parameter’s value may contain. Leave empty to specify Any (no restrictions to the maximum length of this parameter’s value).
Regular Exp.	Specifies, when checked (enabled), that an alpha-numeric parameter value includes a parameter pattern. To define the expression type it in the box. This is a positive regular expression that defines what is legal. The character length limit for this setting is 254. Specifies, when cleared (disabled), that this parameter does not include a pattern. The default is disabled.
Base64 encoding	You can enable the security policy to check whether user input parameter values contain a Base64 encoded string. If the value is indeed Base64 encoded, the system decodes this value and continues with its security checks. This option is available for user input Alpha-Numeric parameters and File Upload parameters. Specifies when enabled that the security policy checks the parameter’s value for Base64 encoding, and decodes the value. The default setting is disabled.

In the Value Meta Character area, configure the security policy to allow or prohibit characters that may appear in the value of a specific parameter. You can override the global parameter value settings for the parameter.
When you enable this setting, the system displays a list, from which you can select and name meta characters.

In the Attack Signatures area, enable Attack Signature Checks (default) to override the security policy settings of an attack signature for the parameter.

Option	Description
Value Meta Character	Specifies when checked (enabled) that you want to override the global parameter value settings for the parameter. After you enable this setting, the system displays a list of characters. The default is enabled.
Select Meta Character	From the list of characters, select your override.

In the Attack Signatures area, change the security policy settings for a specific parameter for this attack signature.

Option	Description
Attack Signature	Specifies when checked (enabled) that you want to override the security policy settings of an attack signature for the parameter. When this setting is enabled, the system displays a list of attack signatures. The default is enabled.
Attack Signature	From the list of characters, select your attack signature.

When you are finished, click Save to save the modifications and unlock the policy.

The parameter settings are updated to use the new settings, and any changes made are put into effect in the working configuration of the BIG-IQ^® system.

Editing extractions settings

You can create and manage defined extractions and extraction properties. An extraction is a subcollection that isolates a parameter from an object. Other subcollections (such as parameters) reference extractions by name (not by URL). Use extractions when creating parameters of type dynamic content value. Using this screen, you can manage how the system extracts dynamic values for dynamic parameters from the responses returned by the web application server.

As with the other policy subcollections, the GUI for extractions displays the Edit button (unless the policy is already locked for edit). Press this button to lock the policy and the system displays the Add, Delete and Unlock buttons. Note that Delete button is disabled until you select at least one extraction.

Use the filter to search the column values of the extraction.

To create an extraction configuration, click Edit. The policy is placed under administrative lock and the fields become editable. For details, consult the following steps. Then, click Add. The system displays the Extraction Configuration screen in with the default values filled in.

Log in to BIG-IQ Security with Administrator, Security Manager, or Web Application Security Manager credentials.
Navigate to the Parameters screen: click Web Application Security > Policy Editor , select a policy name, and from the Policy objects list, select Parameters.
On the Parameters screen, select the Extractionstab.
Click the Edit button.
The policy is placed under administrative lock, and the fields become editable.
To add a new extraction, click Add.

In the Create new extraction area, specify the Name attribute.

Option	Description
Name	Displays the name of the dynamic parameter for which the system extracts values from responses. If you are defining new extraction properties for a dynamic parameter, select one of the following from the list: New. Type a name of the dynamic parameter in the adjacent box. This is the default. no name. Specifies that the extraction is for the parameter UNNAMED.

In the Extracted Items Configuration area, specify the items from which the system should extract the values for dynamic parameters.

Option	Description
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 the Add button. That file type is added. Specifies when cleared (disabled), that the system does not extract values of dynamic parameters from file types. The default is disabled. 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 box, and click the Add button. If you enter a URL that does not yet exist in the security policy, the URL is added to the security policy. Specifies when cleared (disabled), that the system does not extract values of dynamic parameters from URLs. The default is disabled. 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 box. Specifies when cleared (disabled), that the system does not extract values of dynamic parameters from regular expressions. The default is disabled.
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. The default is disabled.

Option

Description

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 the Add button. That file type is added. Specifies when cleared (disabled), that the system does not extract values of dynamic parameters from file types. The default is disabled.
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 box, and click the Add button. If you enter a URL that does not yet exist in the security policy, the URL is added to the security policy. Specifies when cleared (disabled), that the system does not extract values of dynamic parameters from URLs. The default is disabled.
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 box. Specifies when cleared (disabled), that the system does not extract values of dynamic parameters from regular expressions. The default is disabled.

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. The default is disabled.

In the Extracted Items Configuration area, configure the methods from which the system extracts the values for dynamic parameters.

Option	Description
Search in Links	Specifies, when checked (enabled), that the system searches for dynamic parameter values within links that appear in the response body. Specifies when cleared (disabled) that the system does not search for dynamic parameter values within links that appear in the response body. The default is checked (enabled).
Search Entire Form	Specifies, when checked (enabled), that the system searches for dynamic parameter values in the entire form found on a web page. Specifies, when cleared (disabled), that the system does not search for dynamic parameter values in web page forms. The default is checked (enabled).
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 box. Specifies, when cleared (disabled), that the system ignores the URL’s XML. The default is cleared (disabled).
Search Response Body	Specifies, when checked (enabled), that the system searches for dynamic parameter values in the body of the response. Specifies, when cleared (disabled), that the system does not search in the body of the response. Use the additional options to further refine the system’s search. You can specify one or more of the following options, but you must specify the RegExp 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.

The extraction settings are updated to use the new settings, and any changes made are put into effect in the working configuration of the BIG-IQ^® system.

Editing character sets settings

You can view and edit the characters (letters, digits, and symbols) available, and how the security policy responds to each when a request includes that character in parameter values. You configure the security policy to allow or disallow certain characters if they appear in parameter values and/or parameter names.

Log in to BIG-IQ Security with Administrator, Security Manager, or Web Application Security Manager credentials.
Navigate to the Character Sets screen: click Web Application Security > Policy Editor , select a policy name, and from the Policy objects list, select Character Sets.
Click Edit.
The policy is placed under administrative lock and fields become editable.

Select the Parameter Name tab and edit the settings.

Use these check boxes to configure the security policy to allow or disallow certain characters if they appear in wildcard parameter names. You can restore the system defaults even after you have made and saved changes on this tab.

Column label	Description
Hex	Shows the hexadecimal value of each character.
Character	Displays the character itself where applicable, otherwise displays a symbolic representation of the meta character, like TAB.
Allowed	This check box specifies which action the policy takes when it discovers one of these characters in parameter values. Select one of the following actions: If checked (Allowed), the policy permits this character in all incoming requests. If cleared (Disallowed), the policy does not permit this character in incoming requests.

Select the Parameter Value tab and edit the settings.

Use this tab to configure the security policy to allow or disallow certain characters if they appear in parameter values. You can restore the system defaults even after you have made and saved changes on this tab.

Column label	Description
Hex	Shows the hexadecimal value of each character.
Character	Displays the character itself where applicable, otherwise displays a symbolic representation of the meta character, like TAB.
Allowed	This check box specifies which action the policy takes when it discovers one of these characters in parameter values. Select one of the following actions: If checked (Allowed), the policy permits this character in all incoming requests. If cleared (Disallowed), the policy does not permit this character in incoming requests.

When you are finished, click Save to save the modifications and unlock the policy.

The Character Sets settings are updated to use the new settings and any changes made are put into effect in the working configuration of the BIG-IQ^® system.

Editing attack signatures settings

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.

Log in with Administrator, Security Manager, or Web Application Security Manager credentials.
Navigate to the Attack Signatures screen.
Click Edit.
The policy is placed under administrative lock and the fields become editable.
Revise the settings as needed.
1. For Signature Staging select the Enabled check box to enable signature staging on the security policy.
  If cleared (Disabled), then signature staging is disabled on the security policy.
2. Select the Place updated signatures in staging check box to have the system place new or updated signatures in staging for the number of days specified in the enforcement readiness period (specified in Policy properties).
  The system does not enforce signatures that are in staging, even if it detects a violation. Instead, the system records the request information.
3. For Attack Signature Set Assignment, from the list, select one or more signature sets to specify the attack signatures the screen displays. Select or clear the Learn, Alarm, and Block options to customize the settings. You can click the X to the left of any signature set to remove it from the list you are using.
4. For the Apply Response Signatures setting, select a file type, and click the + icon.
When you are finished, click Save to save the modifications and unlock the policy.

The Attack Signatures 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^® system.

Viewing attack signatures lists

Attack signatures are rules or patterns that identify attacks or classes of attacks on a web application and its components. You can view the list of security policy attack signatures that belong to signature sets assigned to the security policy, and you can edit individual attack signatures, including enabling or disabling attack signatures.

Log in with Administrator, Security Manager, or Web Application Security Manager credentials.
Navigate to the Attack Signatures List screen: click Web Application Security > Policy Editor , in the Policy list, click the policy you want to edit, and from the Policy objects list, select Attack Signatures List.
The screen displays a list of attack signatures with these properties:
- Name. Signature name.
- ID. Signature ID number. The system automatically provides the signature ID which cannot be changed.
- In Staging. Yes/No. Specifies whether or not the signatures displayed are in staging, based on each signature’s Perform Staging setting. This option is available only if signature staging is enabled in the policy.
- Enabled. Yes/No. Specifies whether the screen displays signatures based on their Signature State setting. Specifies only whether the signatures displayed are enabled or disabled for the entire security policy, without regard to parameter-specific settings.
To edit an individual signature, click the signature name and then click Edit.
The attack signature is placed under administrative lock. You can now edit the Signature State and Perform Staging settings.
Select the Signature State check box to specify only whether the signature displayed is enabled or disabled for the entire security policy, without regard to parameter-specific settings.
Select the Perform Staging check box to specify whether or not the signatures displayed are in staging.
This option is available only if signature staging is enabled in the policy.
Hover over the Information icon to view additional information.
When finished, click Save to save the modifications and unlock the policy.

Any modified attack signatures settings are updated and put into effect in the working configuration of the BIG-IQ system.

Customizing attack signatures lists

You can use the filter on the Attack Signatures Lists screen to customize which attack signatures the system displays, so you can view only those that you are interested in.

Log in to BIG-IQ Security with Administrator, Security Manager, or Web Application Security Manager credentials.
Navigate to the Attack Signatures screen: click Web Application Security > Policy Editor , select a policy name, and from the Policy objects list, select Attack Signatures Lists.
Type search text in the filter text field and press Enter.

For finer control over the filtering options, click Advanced Filter and specify the appropriate settings.

Option	Description
Containing String	Specify whether the screen displays signatures based on a string found in the signature name. The default empty field indicates that the screen displays all signatures. Type part of the signature name in the field to view signature names that contain a specific string. This search is not case-sensitive.
Signature Type	Specify what type of signatures the system displays: All. Specifies all signatures, which is the default. Request. Specifies signatures that are configured to inspect the client request. Response. Specifies signatures that are configured to inspect the server response.
Risk	Specify the risk level: Low. Indicates the attack may assist the user in gathering knowledge to perpetrate further attacks, but does not cause direct damage or reveal highly sensitive data. Medium. Indicates the attack may reveal sensitive data, or cause moderate damage. High. Indicates the attack may cause a full system compromise, denial of service, and the like.
Enabled	Specify whether the screen displays signatures based on their Enabled setting. This filter specifies only whether the signatures displayed are enabled or disabled for the entire security policy, without regard to parameter-specific settings. All. Specifies all signatures, which is the default. No. Specifies signatures that are disabled. Yes. Specifies signatures that are enabled.
Signature ID	Specify whether the screen displays signatures based on their ID number. (The system automatically provides the signature ID which cannot be changed.) The default empty field indicates that the screen displays all signatures. Type the signature ID in the field to view signatures with a specific signature ID.
User Defined	Specify whether the screen displays signatures based on who created them. All. Specifies all signatures, which is the default. No. Specifies system-defined signatures. Yes. Specifies user-defined signatures.
Accuracy	Specify the accuracy levels: Low. Indicates a high likelihood of false positives. Medium. Indicates some likelihood of false positives. High. Indicates a low likelihood of false positives.
In Staging	Specify whether the screen displays signatures based on each signature’s Perform Staging setting. This filter specifies whether the signatures displayed are in staging or not. This option is available only if signature staging is enabled in the security policy. All. Specifies all signatures, which is the default. No. Specifies signatures currently not in staging. Yes. Specifies signatures currently in staging.

When you have finished making your selections, click Apply Filter.
When you are finished, click Save to save the modifications and unlock the policy.

Any modified Attack Signatures settings are updated and put into effect in the working configuration of the BIG-IQ^® system.

Adding security policies

You can use BIG-IQ^® Web Application Security to add new application security policies for possible later deployment.

Navigate to Web Application Security > Policy Editor .
Policies are listed on the Policies screen.
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.
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.
When you are finished editing the properties, click Save.
This makes the remaining policy objects available for editing.
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.
Click Save to save the modifications to each policy object before moving to another one.
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.

Importing 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 BIG-IQ^® Web Application Security to import security policies that were previously exported from another Application Security Manager™ system.

Log in to BIG-IQ Security with Administrator, Security Manager, or Web Application Security Manager credentials.
Navigate to the Policies screen: click Web Application Security > Policy Editor .
In the Policies screen, click the Import button.
In the Import Policy dialog box, select the security policy file by clicking Choose File or Browse, and navigating to the file location, or you can drag and drop a file to the Drop Policy File Here field.
You can drag and drop a policy file onto the Source File area to view the content of the XML file.
Click Import.

After import, the policy is listed in the Policies screen. The uploaded policy will have the same name as the XML file.

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.

Exporting security policies

You can use BIG-IQ^® Web Application Security to export security policies. The exported security policy can be used as backup, or you can import it onto another system.

Log in to BIG-IQ Security with Administrator, Security Manager, or Web Application Security Manager credentials.
Navigate to the Policies screen: click Web Application Security > Policy Editor .
Select the check box to the left of the security policy you want to export.
The Export button becomes active.
Click the Export button.
In the Export Policy dialog box, from the Compatibility Version list, select a version and click Export.

You can use the exported security policy as 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.

Log in to BIG-IQ Security with Administrator, Security Manager, or Web Application Security Manager credentials.
Navigate to the Policies screen: click Web Application Security > Policy Editor .
Select the check box to the left of the security policy you want to remove.
The Remove button becomes active.
Click the Remove button.
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.

Subscriptions

Product Usage

Trials

Registration Keys

Downloads

Applies To:

BIG-IQ Centralized Management

About security policies in BIG-IQ Web Application Security

About subcollections in policies

Editing security policies

Editing properties settings

Properties settings

Editing blocking settings

Blocking settings

Editing response page settings

Editing Data Guard settings

Editing Headings and Methods settings

Editing IP address settings

Adding file types settings

Editing parameters settings

Editing extractions settings

Editing character sets settings

Editing attack signatures settings

Viewing attack signatures lists

Customizing attack signatures lists

Adding security policies

Importing security policies

Exporting security policies

Removing security policies

Have a Question?

About F5

Education

F5 Sites

Support Tasks

Subscriptions

Product Usage

Trials

Registration Keys

Downloads

Applies To:

BIG-IQ Centralized Management

About security policies in BIG-IQ Web Application Security

About subcollections in policies

Editing security policies

Editing properties settings

Properties settings

Editing blocking settings

Blocking settings

Editing response page settings

Editing Data Guard settings

Editing Headings and Methods settings

Editing IP address settings

Adding file types settings

Editing parameters settings

Editing extractions settings

Editing character sets settings

Editing attack signatures settings

Viewing attack signatures lists

Customizing attack signatures lists

Adding security policies

Importing security policies

Exporting security policies

Removing security policies

Have a Question?

Follow Us

About F5

Education

F5 Sites

Support Tasks