Applies To:

Show Versions Show Versions

Manual Chapter: Building a Security Policy Automatically with the Policy Builder
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

The Policy Builder is the automated tool with which you create a security policy. You can run the Policy Builder to build a new security policy, or to update an existing security policy. A web application can have only one active security policy at a time.
Note: To create a security policy for a new, unconfigured web application, F5 Networks recommends that you use the Deployment wizard. For more information on using the Deployment wizard, refer to the BIG-IP® Application Security Manager: Getting Started Guide.
The Policy Builder examines requests and responses and populates the security policy with the entities that it finds in the traffic. This action tightens the security policy. The entities may include file types, URLs, and parameter types.
When you use live traffic as the traffic source, the Policy Builder analyzes logged requests to, and responses from, the web application. When you use system-generated traffic as the traffic source, the Policy Builder emulates user behavior by browsing the web application.
Live traffic is typical client-server traffic for a web application. F5 Networks recommends using live traffic as the traffic source to develop the security policy.
Live traffic can come from trusted or untrusted clients. Traffic from trusted clients is traffic you generally trust. Typical sources of trusted traffic are internal test groups, employees, or other users in a controlled environment. For information on how to add trusted clients, see Configuring trusted IP addresses for live traffic. Untrusted clients can be anyone who can access the web application.
When you use system-generated traffic as the traffic source, the Policy Builder uses system-generated traffic to extract the web application entities from the web application.
You can specify the security policy template that the system uses to evaluate changes and verify compliance before making those changes. You should choose a security template based on the structure of your site, and the level of maintenance in terms of the web element granularity that you want.
Global Level
When you use the Global Level security template, the Policy Builder creates a security policy that detects evasion techniques and checks for RFC compliance for the HTTP protocol. It also checks for file types, global parameters, request lengths, header lengths, meta characters in headers, cookie lengths, and attack signatures.
URL Level
When you use the URL Level security template, the Policy Builder creates a security policy that enforces the options of the Global Level template, and also adds explicit URLs and configures the parameters at the URL level instead of at the global level.
Flow Level
When you use the Flow Level security template, the Policy Builder creates a security policy that enforces the options of the URL Level template, and also adds new flows to the security policy.
The Policy Builder has built-in algorithms that analyze web application traffic according to the security template that you select. From that analysis, the Policy Builder updates the corresponding security policy with web application entities that it finds. The entities may include file types, URLs, meta characters, parameters, parameter values, and parameter types. This analysis process is called heuristics.
As the Policy Builder runs, the heuristics algorithms scan all of the web application traffic, and detect additions and change to the web application entities. When the heuristics analysis reaches a point of decision in the algorithm, the Policy Builder makes corresponding changes in the security policy. Heuristics analysis reduces the workload of building and maintaining a security policy.
1.
In the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Configuration area, select Advanced if you want to display additional configuration options.
4.
Check that the Traffic Source setting is set to Live Traffic.
5.
For the Continuous Mode setting, select either Run continuously or Run once on gathered traffic. See Configuring which live traffic to analyze, following, for more information.
6.
For the Security Template setting, select the security template that you want the Policy Builder to use. See Understanding the security templates for the Policy Builder, for more information.
9.
Click the Start button (at the bottom).
The screen displays the Automatic Policy Building Status screen, where you can monitor the progress of the Policy Builder.
You can specify whether the Policy Builder runs all the time and processes all traffic, or whether the Policy Builder processes only requests and responses that have already been logged. You do this using the Continuous Mode options:
Run continuously
When you select this option, the Policy Builder runs from the time you start it until you click the Stop button.
Run once on gathered traffic
When you select this option, the Policy Builder analyzes only traffic that the system has already received, and stops once that analysis process is complete. This is the default setting.
1.
In the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration screen opens.
2.
For the Continuous Mode setting, select the mode that is appropriate for your web application and environment.
If, for the Continuous Mode setting, you select the Run continuously option, you can also specify whether the Policy Builder automatically updates and applies the security policy whenever it discovers new entities in the analyzed traffic. You do this by using the Track Site Changes setting (enabled by default).
If you disable the Track Site Changes setting, the system generates a learning suggestion whenever there is a discrepancy between the security policy and the traffic, and you evaluate the associated requests to determine whether you need to update the security policy with the changed entity.
1.
In the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration screen opens.
2.
Make sure the Track Site Changes box is checked to enable the automatic security policy updates and activation.
Note: This setting is available only if you have selected Run continuously for the Continuous Mode setting.
The Policy Builder uses the Domain setting to differentiate between URLs that belong to the web application and URLs that do not belong to the web application (but to which the web application contains links). You can leave the domain list empty and instruct the Policy Builder to analyze only relative links, or supply all the domain names that are associated with your site. For example, the home page in your web application may contain a link to an external partner site or search engine. When you configure a Policy Builder domain, the Policy Builder updates the security policy with entities from your web application, and does not update the security policy with entities that belong to the external site.
The Policy Builder domain settings should match the client SSL and server SSL settings for the local traffic virtual server with which the application security class is associated. Otherwise, the Policy Builder cannot gain direct access to the web server that is hosting the web application.
Note: For more information about the local traffic virtual server options, and the Client SSL and Server SSL profiles, refer to the Configuration Guide for BIG-IP® Local Traffic Manager.
1.
In the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration screen opens.
2.
Above the Configuration area, select Advanced.
The screen refreshes to display additional configuration options.
3.
For the Domains setting, configure the following options:
a)
In the Domain box, type the fully qualified domain name of the web server that hosts the web application.
b)
For the Protocol setting, select the appropriate protocol option for your web application.
c)
In the IP Address box, type the address of the web server.
d)
In the Port box, type the port for the HTTP service, typically 80.
4.
Click the Add button.
The system adds the domain to the Domains list.
The Policy Builder uses the session ID source to keep track of traffic from the same client-server session. The Policy Builder extracts the session ID from one of the following sources:
ASM Session
Each request and response that the Application Security Manager processes contains an ASM cookie. When you use the ASM Session source, the Policy Builder extracts the session information associated with the ASM cookie. (This is the default setting.)
Cookie
When you select the Cookie source, the Policy Builder extracts the session information from the cookie that you specify.
Parameter
When you select the Parameter source, the Policy Builder extracts the session information from the regular expression parameter value of the parameter that you specify.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Session ID setting.
If you select Cookie, type a cookie name in the Cookie name box.
If you select Parameter, type a parameter name in the Parameter name box.
Every time the Policy Builder runs for a security policy, it collects the heuristics data. (For more information on heuristics, see Understanding heuristics.) If you want the Policy Builder to delete all previously collected data and start a new data collection process, you can reset the heuristics data. If you run the Policy Builder for a specific security policy more than once, you can include existing heuristics data in the analysis process.
Important: Resetting heuristics and including existing heuristics are mutually exclusive actions. In other words, if you reset the heuristics, the Policy Builder cannot include them in a future analysis.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Heuristics setting.
2.
Click the Reset Statistics button.
The system clears any previously collected data from the heuristics database for the security policy.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Include Previously Collected Heuristics setting.
2.
Check the box to enable the Policy Builder to use any existing heuristics, along with any new heuristics, in the current analysis.
If you are running the Policy Builder using trusted client traffic, you can configure the IP addresses of those trusted clients in the Trusted IPs setting of the Policy Builder configuration. Examples of a trusted IP configuration are:
All sources: 0.0.0.0 - 255.255.255.255
Specific subnet: <trusted.subnet>.1.0 - <trusted.subnet>.1.255
The Policy Builder processes traffic from trusted clients differently than traffic from untrusted clients. For trusted clients, the Policy Builder automatically updates the security policy with any entity changes or updates that it discovers without running heuristics. Additionally, if traffic from the trusted clients triggers any attack signatures, the system automatically disables those signatures within the security policy.
Tip: See Using live traffic as the traffic source, for more information on using trusted clients.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Trusted IPs setting.
By default, the Policy Builder analyzes JavaScript functions found in responses to locate outgoing links. You can disable the Analyze JavaScript setting to prevent those JavaScript functions from running.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Analyze JavaScript setting.
2.
Click to clear the Analyze JavaScript check box.
If you are configuring the Policy Builder to use either the URL Level or Flow Level security template, the Policy Builder detects and analyzes parameters, and sets the parameter type. If the web application contains dynamic parameters, you can configure the Policy Builder to identify them.
Dynamic parameters are parameters whose set of accepted values can change, and usually depend on the user session. For more information on dynamic parameters, refer to Working with dynamic parameters and extractions.
The No dynamic parameter definitions option:
The Identify dynamic parameters by heuristics option:
Adds dynamic parameters to the security policy based on traffic to the web application that meets the internal heuristic criteria.
Tracks sets of values for the parameter in responses (HTML sources) to determine whether to add it to the security policy as a dynamic parameter. If the Policy Builder has insufficient statistics, it set the parameter type to alphanumeric user-input.
The Define Hidden fields as dynamic parameters option:
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Identify Dynamic Parameters setting.
You can use the Input Filter to determine from which requests the Policy Builder extracts the web application information that it uses to build or update the security policy. You can use any combination of filter options, or you can run the Policy Builder with the default options. Table 6.1 describes all of the filter options.
The File Types Associations screen provides a list of file types that are frequently used in web applications, and their most common usage in the web application. In this list, you can configure how the Policy Builder processes a certain file type or URL for the corresponding security policy, thus saving tedious manual configuration in the security policy. For example, image files would not typically be a link, so you can use the file types associations settings to instruct the Policy Builder to define all image files (*.bmp, *.gif, *.jpg, and so on) as files that are not referrers.
The default settings provided in the file type associations list cover the most common file types and associations, and you can adapt them to your needs by checking or clearing boxes. Table 6.2 provides a description of the default file types and their corresponding file type associations.
This option specifies whether all URLs of this type can be entry points to the web application. The system does not specify a default entry point.
This option specifies whether URLs of this type may contain references to other files. For example, an HTML page that contains an HREF link or a CGI file that calls another file, are referrers. Picture and sound files cannot be referrers because these URLs never contain links to other URLs, and are not web pages.
If your web application contains file types that are not included in the default File Types Associations list, you can create custom file type associations, and add them to the list.
1.
In the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration screen opens.
2.
On the menu bar, click File Types Associations.
The File Types Associations screen opens.
3.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
4.
Above the File Types Associations area, click Create.
The New File Type screen opens.
5.
In the File Type box, type the file type extension for the new file type. Note that file type names are not case-sensitive.
7.
8.
If you do not want the system to verify requests referring to new URLs of this type, check the Ignore URL box.
9.
Click OK.
The screen refreshes, and the new file type appears in the File Types Associations list.
10.
In the File Types Associations area, check any flags for properties that you want to associate with the new file type.
11.
Click the Save button below the File Type Associations list to save any changes you have made.
12.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
You can easily remove any extra or unnecessary file types, and their corresponding associations, from the File Types Associations list. Note that you can delete both custom file types, and the default file types.
1.
In the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration screen opens.
2.
On the menu bar, click File Types Associations.
The File Types Associations screen opens.
3.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
4.
Check the box (in the Select column) to the left of the file type that you want to delete from the File Types Associations list.
5.
Below the File Types Associations area, click the Delete button.
The system removes the file type from the list.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
If you have modified the File Types Associations list, and you want to remove those changes from the list entirely, you can restore the default settings. Restoring the default settings returns the File Types Associations list to its original state by removing any user-added file types and resetting all of the associations for the default file types.
1.
In the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration screen opens.
2.
On the menu bar, click File Types Associations.
The File Types Associations screen opens.
3.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
4.
Below the File Types Associations area, click Restore Defaults.
A confirmation popup screen opens.
5.
Click OK.
The screen refreshes and the system restores the default settings for the File Types Associations list.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
You can configure the Policy Builder to build a security policy using system-generated traffic that emulates client traffic browsing through the web application.
Important: Although you do not have to configure all of these options, at minimum you must configure the Domains and Start Points settings.
1.
In the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Configuration area, select Advanced.
The screen refreshes to display additional configuration options.
4.
For the Traffic Source setting, select System-Generated Traffic.
The screen refreshes and displays the configuration options that are available for this traffic mode.
5.
For the Security Template setting, select the security template that you want the Policy Builder to use. See Understanding the security templates for the Policy Builder, for more information.
6.
For the Domains setting, configure the domain information for the web application. See Configuring domains for system-generated traffic, for more information.
7.
For the Start Points setting, configure the start points information for the web application. See Configuring the web application start point, for more information.
9.
Click the Start button.
The screen refreshes and displays the Automatic Policy Building Status screen, where you can monitor the progress of the Policy Builder.
The Policy Builder uses the Domain setting to differentiate between URLs that belong to the web application and URLs that do not belong to the web application (but to which the web application contains links). For example, the home page in your web application may contain a link to an external search engine. When you configure a Policy Builder domain, the Policy Builder updates the security policy with entities from your web application and does not update the security policy with entities that belong to the external search engine.
The Policy Builder domain settings should match the client SSL and server SSL settings for the local traffic virtual server with which the application security class is associated. Otherwise, the Policy Builder cannot gain direct access to the web server that is hosting the web application. You can configure the Policy Builder domain settings to use any combination of HTTP and HTTPS. Table 6.3 shows the mapping.
HTTP or HTTPS
Note: For more information about the local traffic virtual server options, and the Client SSL and Server SSL profiles, refer to the Configuration Guide for BIG-IP® Local Traffic Manager.
1.
In the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Configuration area, select Advanced.
The screen refreshes to display additional configuration options.
4.
For the Domains setting, configure the following settings.
a)
In the Domain box, type the fully qualified domain name of the web server that hosts the web application.
b)
For the Protocol setting, select the appropriate protocol option for your web application.
c)
In the IP Address box, type the address of the web server.
d)
In the Port box, type the port for the HTTP service, typically 80.
5.
Click the Add button.
The system adds the domain to the Domains list.
The Policy Builder uses the session ID source to keep track of traffic from the same client-server session. The Policy Builder extracts the session ID from an ASM session, a cookie, or a parameter.
1.
In the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Configuration area, select Advanced.
The screen refreshes to display additional configuration options.
4.
For the Session ID setting, select the session ID source that is appropriate for your web application:
ASM Session
Each request and response that the Application Security Manager processes contains an ASM cookie. When you select this source, the Policy Builder extracts the session information associated with the ASM cookie.
Cookie
When you select this source, the Policy Builder extracts the session information associated with the cookie that you specify.
Parameter
When you select this source, the Policy Builder extracts the session information associated with the parameter that you specify.
When you run the Policy Builder using system-generated traffic, the Policy Builder starts the data collection process for a web application from a URL. This URL is known as the start point. The start point is usually the web application's home page. If the web application has several start points, you can instruct the Policy Builder to scan the application from each start point, separately.
For example, an online banking site has a public area, which anyone can access, and a secure area that requires a unique login. When a customer logs in to the secure area, they may be redirected to a different web application. To successfully map the entire web application, the Policy Builder must know about all of these start points.
1.
In the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Configuration area, select Advanced.
The screen refreshes to display additional configuration options.
4.
For Start Points, configure the following settings.
a)
In the Domains List box, select the Policy Builder domain for which you are creating a start point.
b)
In the Start Point box, type the address of the default start page of the application, for example, http://siterequest.example.com/index.html
Important: Every start point must reference a Policy Builder domain.
5.
Click the Add button.
The system adds the start point to the Start Points list.
Tip: If your web application has more than one start point, F5 Networks recommends that you run the Policy Builder one or more times to scan the public access areas of the web application, and then run the Policy Builder with the login information configured, to scan the secure areas of the web application.
If the web application contains a page designed to log a visitor out of the web application, you need to instruct the Policy Builder not to follow the logout link. Otherwise, when you run the Policy Builder, it may log out of the web application before it has fully scanned the application. For example, many web applications have an Exit or Logout link on the home page, which would cause the Policy Builder to exit the application prematurely. You can prevent this behavior by identifying the logout points that the Policy Builder should avoid.
Note: If you configure the Policy Builder to recognize (and ignore) a logout page in a web application, the system adds this page to the security policy.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Logout Pages setting.
2.
In the Logout Pattern box, type the relative path of the logout page.
3.
Click the Add button.
The system adds the new logout page to the Logout Pages list.
You can define form filler parameters with values that the Policy Builder uses to fill in forms. For example, if your web application uses a login form, you can define the user name and password parameters, and their corresponding values.
When you build a security policy using system-generated traffic, the Policy Builder populates the form fillers parameters automatically. You can then review the form filler parameters to provide the appropriate values.
Tip: Sometimes the parameter names are not self-explanatory, and you may need to consult with the web application programmer. If it is available to you, you can also search the HTML source code for this information.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Form Fillers setting.
2.
In the Parameter Name box, type the parameter name that the Policy Builder should search for in forms of this web application, for example, username.
3.
For the Parameter Type setting, select the appropriate type of parameter that the Policy Builder should search for in forms of this web application. Note that if you select password, the system displays asterisks instead of clear text in the Form Fillers list.
4.
In the Parameter Value box, type the value that you want the Policy Builder to enter when it finds the specified parameter in the form. If the parameter type is password, the system requires you to confirm the value.
5.
Click the Add button.
The system adds the new form filler parameter to the Form Fillers list.
When a request to a non-existent web page comes in, web applications typically return a standard HTTP 404 response page, with a page not found error message. This response page may be exploited to stage attacks. To prevent attacks, some web applications may use customized error pages that use the HTTP 200 status code in the response, instead of the HTTP 404 status code. Web application designers do this so that their content can be controlled and verified.
By default, the Policy Builder adds pages that use the HTTP 200 Status OK message to the security policy, and ignores pages that generate the HTTP 404 message. If you do not define the Page Not Found Criteria setting, the Policy Builder attempts to identify it by itself. If your web application uses customized error pages (those that do not return the HTTP 404 status code), you need to supply a text string that the pages contain, so that the Policy Builder can identify them as valid error message pages, and avoid adding them to the security policy. The Policy Builder can recognize an error page by its file name, or by text strings that are found in the HTML tags, <TITLE> or <BODY>.
Tip: The Policy Builder always follows the redirect link, if one is configured. The Policy Builder identifies the page behind the link, and avoids the link if the identified page is included in the Page Not Found list.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Page Not Found Criteria setting.
2.
In the Apply To box, select the URL that the Policy Builder examines to identify the error page.
3.
In the Search Item box, type the header or string that the Policy Builder searches for.
4.
Click the Add button.
The system adds the page not found criteria to the list.
Every time the Policy Builder runs for a security policy, it collects the heuristics data. (For more information on heuristics, see Understanding heuristics.) If you want the Policy Builder to delete all previously collected data and start a new data collection process, you can reset the heuristics data. If you run the Policy Builder for a specific security policy more than once, you can specify that the Policy Builder includes existing heuristics data in the analysis process.
Important: Resetting heuristics and including existing heuristics are mutually exclusive actions. In other words, if you reset the heuristics, the Policy Builder cannot include them in a future analysis.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Heuristics setting.
2.
Click the Reset Statistics button.
The system clears any previously collected data from the heuristics database for the security policy.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Include Previously Collected Heuristics setting.
2.
Check the box to enable the Policy Builder to use any existing heuristics, along with any new heuristics, in the current analysis.
When you run the Policy Builder using system-generated traffic, several configuration options determine the general behavior of the Policy Builder. Table 6.4 lists these configuration options and their purpose.
Specifies whether the Policy Builder creates back flows in the security policy for referrer URLs. You can use the back flow information to impose rules on navigating backwards, which occurs when the visitor uses the browser Back button.
Specifies whether the Policy Builder creates flows in the security policy for URLs that a web browser can cache, for example, image files.
Minimal delay between worm requests to web application (milliseconds)
Running the Policy Builder using system-generated traffic is similar to a central unit sending out multiple simultaneous probes to the different areas of the web application in order to register web application entities. Each probe exercises the web application by following links and filling in forms, similar to an actual user. This process increases the traffic to the web application.
The Policy Builder can send the probes in quick or slow succession. Quicker bursts create more traffic. A burst is measured in terms of the number of seconds to wait before sending the next probe. If your web application is active and currently serving visitors, consider increasing this value in order to slow down the Policy Builder.
Number of times the Policy Builder fetches requests with the same structure
For this property, specify the number of samples that are sufficient for the Policy Builder to scan when it discovers identical structures. Applications may contain many identical structures within URLs, where only the parameter values differ. The following examples illustrate identical structures that differ only by the parameter values:
To reduce the policy building time (and the accompanying traffic), you can instruct the Policy Builder to scan only a few (and not all) of such identical structures, assuming that all others behave in the same way.
Note: A higher value yields a more accurate security policy, however, it takes a longer amount of time for the Policy Builder to complete the process.
Maximum number of requests generated for each form by the form iterator
When the Policy Builder encounters a form, it processes it as many times as the number of predefined parameter values included in it. For example, a list containing ten URLs causes the Policy Builder to process the form ten times. You can reduce crawling time and traffic, however, by instructing the Policy Builder to process only a few of the URLs and not all of them.
For this property, specify the number of samples you deem it sufficient for the Policy Builder to process from the same form with different values. A higher value yields a more accurate policy with longer crawling times.
The Policy Builder uses this property to select the User-Agent header data when it scans the web application.
If the web application uses HTTP authentication, you can use the HTTP Authentication setting to configure the logon criteria. The Policy Builder accepts all RFC 2617 authentication formats, as well as the Microsoft® NTLM authentication format.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, scroll down to the HTTP Authentication setting.
2.
In the HTTP Authentication Username box, type the user name for the web server. For Microsoft NTLM authentication, type the user name in the following format:
3.
In the HTTP Authentication Password box, type the password for the web server.
The Policy Builder Status screen provides information about the running status of the Policy Builder. The Status screen displays information about the Policy Builder session, and also displays graphs that compare the number of new and updated entities.
When you run the Policy Builder, the system generates a series of graphs on the Policy Builder Status screen. The graphs display the processed requests, URLs, file types, and parameters. You can use the graphs to help decide when to stop the Policy Builder. When the updates reach zero, the Policy Builder has added all of the entities that it can find.
1.
In the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
On the menu bar, click Status.
The Automatic Policy Building Status screen opens, and displays the Policy Builder status information.
When the Policy Builder runs, it generates log entries for all events and actions taken for the security policy it is building (or updating). The Policy Builder log contains a description of the reason for a security policy change, the related entity, and any action taken; information about thresholds reached for the number of requests for an entity, traffic volume, or number of sessions; and file type events.
For more information on logging in general, refer to the TMOS® Management Guide for BIG-IP® Systems, which is available in the Ask F5SM Knowledge Base, https://support.f5.com.
Because the Policy Builder log file size can grow to be quite large, you can limit the result set returned using either predefined filters or a custom filter.
The Policy Builder log filter has two filter groups: Basic and Advanced. You can use the Basic filter group to display all log events from the selected web application security policy. The Advanced filter group lets you limit the result set by selecting more granular criteria. Table 6.5 lists the log filter options.
Displays a limited the result set by providing further narrowing options from the following categories:
1.
In the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration screen opens.
2.
On the menu bar, click Log.
The Automatic Policy Building Log screen opens.
3.
In the editing context area, ensure that the edited web application and security policy are those for which you want to view log transactions.
4.
In the Filter area, configure the filter settings to view the logs you want to see.
5.
Click the Go button.
The screen refreshes, and displays the Policy Builder log file for the web application and security policy that you selected.
1.
In the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
On the menu bar, click Status.
The Automatic Policy Building Status screen opens.
4.
Below the Policy Builder Status area, click the Stop button.
The system stops the Policy Builder, the screen refreshes, and you see a summary of the Policy Builder data collection.
After you stop the Policy Builder, you can review any learning suggestions provided, and use them to fine-tune the security policy. See Chapter 14, Refining the Security Policy Using Learning, for more information. You can also review the security policy, and specifically look at any wildcards with the tightening flag enabled and consider removing the wildcards that are no longer needed.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



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

Additional Comments (optional)