Applies To:

Show Versions Show Versions

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

The Policy Builder is the 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. If you have several security policies for a web application, you run the Policy Builder for each security policy.
The Policy Builder parses requests and responses and populates the security policy with the entities that it finds, including object types, objects, flows, parameters types and extractions, and meta characters. This action tightens the security policy. Once you make this security policy the active security policy, when the Application Security Manager receives a similar request, the system does not issue violations against the request, or block the request (if the enforcement mode is blocking).
With the Policy Builder, you have two options for the source of the traffic that the Policy Builder analyzes: live traffic and system-generated traffic. 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.
When you are setting up the Policy Builder the first thing you decide is which traffic source to use. This determines the remaining configuration options for the Policy Builder.
Live traffic is the typical client-server traffic for a web application. Live traffic can be from trusted clients or untrusted clients. Trusted clients are those from whom you know the traffic is not malicious. Typical sources of trusted traffic are internal test groups, employees, or other users in a controlled environment. For information on how the Policy Builder recognizes trusted clients, see Configuring Trusted IPs for live traffic. Untrusted clients can be anyone who can access the web application.
When you run the Policy Builder using system-generated traffic as the traffic source, the Policy Builder uses system-generated traffic to extract the web application entities from the web application. Use this mode when you do not have any recorded traffic, and you want the Policy Builder to automatically fetch requests (browse) against the web application, process the responses, and use all the outgoing links. The Policy Builder uses the collected information to update the security policy to accept all of the generated traffic.
The Policy Builder has three security templates. The security templates provide the guidelines by which the Policy Builder creates or updates the security policy. You select a security template regardless of the traffic source for the Policy Builder.
Basic
When you use the Basic security template, the Policy Builder creates a security policy that enforces request lengths, header lengths, meta characters in headers, cookie lengths, and attack signatures, and adds object types and global parameters to the security policy.
Typical
When you use the Typical security template, the Policy Builder creates a security policy that enforces the options of the Basic template, and also adds objects and object parameters to the security policy.
Comprehensive
When you use the Comprehensive security template, the Policy Builder creates a security policy that enforces the options of the Typical template, and also adds flows and flow parameters to the security policy. Note that you can configure an advanced flow mode security policy only when the traffic source is system-generated traffic.
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 object types, web objects, 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, then the Policy Builder makes corresponding changes in the security policy. Heuristics analysis reduces the workload of building a security policy. Heuristics analysis also helps reduce the workload of building and maintaining a security policy.
This is particularly helpful in the case of parameters. When the Policy Builder is running heuristics on responses, it can determine the parameter type. For example, the web application may have a parameter that the heuristics algorithms initially determine is a static parameter. If, over time, the heuristics algorithms detect more that 20 different values for that parameter, then the Policy Builder changes the parameter type to user-input. This reduces the false positives for this parameter because the Policy Enforcer no longer expects a parameter value from a finite list.
When you run the Policy Builder in live traffic mode, there are many configuration options, and an input filter, to customize the traffic analysis. There are both a basic and an advanced configuration for the Policy Builder. The Advanced mode provides additional configuration settings, to further refine how the Policy Builder processes the live traffic.
1.
On the Main tab of 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 Basic or Advanced.
If you select Advanced, the screen refreshes to display additional configuration options.
4.
For the Traffic Source setting, select Live Traffic.
5.
For the Continuous Mode setting, select either Run continuously or Run once on gathered traffic. See Configuring the Continuous Mode for live traffic, 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.
7.
In the Configuration area, configure the remaining settings as required. The settings are described in the sections following.
9.
Click the Start button (below the Input Filter area).
The screen refreshes, and displays the Automatic Policy Building Status screen, where you can monitor the progress of the Policy Builder.
The Continuous Mode for live traffic specifies 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. The Continuous Mode options are:
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.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Continuous Mode setting.
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 the analyzed traffic contains entities that are different from those in the current active security policy. You do this by enabling the Track Site Changes setting. If you disable the Track Site Changes setting, then 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.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Track Site Changes setting.
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 objects that belong to the web application, and objects 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 7.1 shows the mapping.
Then the Policy Builder domain setting is:
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 Management.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Domains setting.
a)
In the Domain box, type the fully-qualified domain name of the web server.
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.
3.
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 select the ASM Session source, the Policy Builder extracts the session information associated with the ASM cookie.
Cookie
When you select the Cookie source, the Policy Builder extracts the session information associated with the cookie that you specify.
Parameter
When you select the Parameter source, the Policy Builder extracts the session information associated with 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, then type a cookie name in the Cookie name box.
If you select Parameter, then 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 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.
If you are running the Policy Builder using trusted client traffic, you can configure the IP addresses of the trusted clients in the Trusted IPs setting. The Policy Builder processes traffic from trusted clients differently from untrusted clients. For trusted clients, the Policy Builder automatically updates the security policy with any entity changes or updates that it discovers. 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.
If the web application for which you are building a security policy contains JavaScript code, then you can configure the Policy Builder to process the code. This is useful if the scripts contain references to links that can be followed, or if the scripts include form fields that need to be filled.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Analyze JavaScript setting.
The Input Filter options 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 7.2 provides a description of the filter options.
When you run the Policy Builder in the system-generated traffic mode, the system emulates client traffic browsing through the web application. There are several configuration options for this mode that help the system browse the web application. While you do not have to configure any of these options, we recommend that you configure, at minimum, the Domains settings.
1.
On the Main tab of the Application Security navigation pane, click Policy.
The Security Policy Properties 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 Policy Builder.
The Policy Builder screen opens.
4.
Above the Configuration area, select Basic or Advanced.
If you select Advanced, the screen refreshes to display additional configuration options.
5.
For the Traffic Source setting, select System-Generated Traffic.
The screen refreshes, and displays the configuration options that are available for this traffic mode.
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.
7.
For the Domains setting, configure the domain information for the web application. See Configuring domains for system-generated traffic, for more information.
8.
In the Configuration area, configure the remaining settings as required. The settings are described in the sections following.
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.
If you select the Comprehensive security template, then you configure the Flow Mode setting in the Policy Builder. The flow mode specifies how the security policy manages the navigational relationships between the entities that make up the web application. When you specify the simple flow mode, the Policy Builder defines all objects as entry points. In other words, the simple flow mode ignores the navigational relationships of the web application entities. When you specify the advanced flow mode, the Policy Builder maps the navigational relationships of each and every web application entity. For example, the navigational relationships for each button, graphic file, HTML page, form input field, and hyperlink are all part of the application flow. Using the web browsers Back and Forward buttons is also part of the application flow, if these actions are permitted within the web application.
Note: We recommend that you use the simple flow mode. If you need the additional security of the advanced flow mode for a particular aspect of your web application, we recommend that you define a flow parameter. For additional information on flow parameters, see Working with flow parameters.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, for the Security Template setting, select Comprehensive.
The screen refreshes, and displays the Flow Mode setting.
2.
For the Flow Mode setting, select Simple or Advanced.
The Policy Builder uses the Domain setting to differentiate between objects that belong to the web application, and objects 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.
Important: When you run the Policy Builder in the system-generated traffic mode, you must configure a Policy Builder domain.
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 7.3, following, shows the mapping.
Then the Policy Builder domain setting is:
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 Management.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, for the Domains setting, configure the following settings.
a)
In the Domain box, type the fully-qualified domain name of the web server.
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.
2.
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 select the ASM Session source, the Policy Builder extracts the session information associated with the ASM cookie.
Cookie
When you select the Cookie source, the Policy Builder extracts the session information associated with the cookie that you specify.
Parameter
When you select the Parameter source, the Policy Builder extracts the session information associated with the parameter that you specify.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Session ID setting.
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.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Start Points setting.
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.
3.
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, we recommend 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 logs out of the web application before it has fully scanned the application. For example, many web applications have an Exit or Logout link right on the home page, which would cause the Policy Builder to exit the application as soon as it enters. You can prevent this behavior by using the Logout Pages setting to identify 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 use the Form Fillers general setting to define form parameters and values that the Policy Builder then uses to fill in forms. For example, if your web application has a login form, you can define the user name and password parameters, and their corresponding values.
When you run the Policy Builder 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 name of the parameter, for example, username.
3.
In the Parameter Type box, select the appropriate type. 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 reaches the specified parameter. 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 do 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 object that the Policy Builder searches 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 Page Not Found Criteria 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, there are several configuration options that determine the general behavior of the Policy Builder. Table 7.4 lists these configuration options and their purpose.
Specifies whether the Policy Builder creates back flows in the security policy for referrer objects. You can use the back flow information to impose rules on navigating backwards, which occurs when the visitor uses the browser Back button.
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 threads to be used by the policy builder
This option also relates to simultaneous probe activity. A smaller number of threads decreases the Policy Builders bandwidth consumption, which keeps more bandwidth available for actual visitors.
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 objects, 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 pre-defined parameter values included in it. For example, a list containing ten objects 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 objects 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, then you can use the HTTP Authentication settings to configure the login 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, locate 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 number of new and updated web objects, parameters, and flows. 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.
On the Main tab of 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.
Tip: While the Policy Builder is running, it automatically refreshes the status information every 30 seconds. If you want to see updated status information more frequently, click the Refresh button (near the bottom of the screen).
1.
On the Main tab of 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 status information, click the Stop button.
The system stops the Policy Builder, the screen refreshes, and you see a summary of the Policy Builder data collection.
Once you have stopped the Policy Builder, we recommend that you review any learning suggestions that the Policy Builder may not be able to resolve. See Processing learning suggestions that the Policy Builder cannot process, for more information.
For a few violations, the learning suggestions do not represent an update to the security policy. Instead, the violations are indicative of an issue that requires user interpretation. The Policy Builder cannot resolve these violations, and displays them on the Automatic Policy Building Report screen.
For these violations, we recommend that you review the violations, and determine whether they represent legitimate violations or false positives. You can disable these violations if they are not applicable to your web application, which turns off the blocking policy so that you are no longer notified of requests that trigger the violation. Alternately, you can clear the learning suggestions, and the Learning Manager continues to issue learning suggestions for the requests.
Important: The Learning Manager does not generate learning suggestions for requests that cause non-existent object violations if the web server sends an HTTP response with status codes in the 400-499 and 500-599 range.
If you do not want the system to display the violations that require user interpretation, you can disable the violation. When you disable a violation, the Policy Enforcer disables all of the blocking actions (the Learn, Alarm, and Block flags) for the violation. The system then ignores future instances of the violation, and passes the requests on to the web application resources.
Tip: The Automatic Policy Building Report screen displays learning suggestions only if the traffic has triggered a violation.
1.
On the Main tab of the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration screen opens.
2.
From the menu bar, choose Report.
The Automatic Policy Building Report screen opens.
4.
Next to the violation name, check the Select box, and then click the Disable button.
A confirmation popup screen opens.
5.
Click OK.
The screen refreshes, and you no longer see the violation.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
A confirmation popup screen opens.
7.
Click OK.
The system applies the updated security policy.
When you clear a violation, the system deletes the violation, but does not update the security policy. The Policy Enforcer continues to generate alarms for future instances of the violation, and the Learning Manager continues to generate learning suggestions relative to the violation.
1.
On the Main tab of the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration screen opens.
2.
From the menu bar, choose Report.
The Automatic Policy Building Report screen opens.
4.
In the list, check the box next to a violation, and then click Clear.
A Confirm Delete popup screen opens.
5.
Click OK.
The system deletes the learning suggestion.
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)