F5 Logo MyF5
Search
  1. MyF5 Home
  2. Knowledge Centers
  3. BIG-IP ASM
  4. BIG-IP Application Security Manager: Getting Started
  5. Using WhiteHat Sentinel for a Security Policy
Manual Chapter : Using WhiteHat Sentinel for a Security Policy

Applies To:

Show Versions Show Versions

BIG-IP ASM

  • 12.1.6, 12.1.5, 12.1.4, 12.1.3, 12.1.2, 12.1.1, 12.1.0
Manual Chapter
Table of Contents | << Previous Chapter | Next Chapter >>

Using WhiteHat Sentinel for a Security Policy

Overview: Integrating WhiteHat Sentinel with ASM

Application Security Manager™ (ASM) integrates with WhiteHat Sentinel to perform vulnerability assessments of web applications. WhiteHat identifies, classifies, and reports potential security holes or weaknesses in the code of your web site.

You can use the vulnerability assessment deployment scenario to create a baseline security policy that is integrated with WhiteHat Sentinel. By using Sentinel scan output, the system suggests updates to the security policy that can protect against the vulnerabilities that WhiteHat Sentinel found. You can choose which of the vulnerabilities you want the security policy to handle, resolve them automatically or manually, retest to be sure that the security policy protects against the vulnerabilities, then enforce the security policy when you are ready.

Task summary

Creating a security policy integrated with WhiteHat Sentinel

Before you can integrate WhiteHat Sentinel with Application Security Manager™ (ASM), you should have the following prerequisites:
  • Up-to-date WhiteHat Sentinel subscription and valid login credentials (sentinel.whitehatsec.com)
  • WhiteHat Sentinel Web API key for your account
  • Site name (as defined in your WhiteHat account)
  • Recent Sentinel scan of the web application you want to protect

If you do not have a WhiteHat account, you will have the opportunity to get a free assessment of your website from WhiteHat Sentinel.

The ASM™ system needs to be able to access the WhiteHat web site to download the results of the vulnerability scan and to perform retests after updating the security. If the BIG-IP® system does not have Internet access, you can run the vulnerability scan from a system that does have access, then save the results of the scan as an XML file on that system and import the vulnerabilities file manually onto the BIG-IP system.

You need to complete the basic BIG-IP system configuration tasks including creating a VLAN, a self IP address, and other tasks according to the needs of your networking environment. You also need to configure a DNS address (go to System > Configuration > Device > DNS) .

The WhiteHat Sentinel service assesses web applications for vulnerabilities. You can create a baseline security policy to protect against the potential problems that a Sentinel vulnerability assessment scan finds.
  1. On the Main tab, click Security > Application Security > Security Policies .
    The Active Policies screen opens.
  2. Click the Create button.
    The Deployment wizard opens to the Select Local Traffic Deployment Scenario screen.
  3. For the Local Traffic Deployment Scenario setting, specify a virtual server to use for the security policy.
    • To secure an existing virtual server that has no security policy associated with it, select Existing Virtual Server and click Next.
    • To create a new virtual server and pool with basic configuration settings, select New Virtual Server and click Next.
    • To create an active but unused security policy, select Do not associate with Virtual Server and click Next. No traffic will go through this security policy until you associate it with a virtual server. The Policy Builder cannot begin automatically creating a policy until traffic is going to ASM through the virtual server.
    The virtual server represents the web application you want to protect.
    The Configure Local Traffic Settings screen opens if you are adding a virtual server. Otherwise, the Select Deployment Scenario screen opens.
  4. If you are adding a virtual server, configure the new or existing virtual server, and click Next.
    • If creating a new virtual server, specify the protocol, virtual server name, virtual server destination address and port, pool member IP address and port, and the logging profile.
    • If using an existing virtual server, it must have an HTTP profile and cannot be associated with a local traffic policy. Specify the protocol and virtual server.
    • If you selected Do not associate with Virtual Server, you will have to manually associate the security policy with a virtual server at a later time. On the policy properties screen, you need to specify a name for the security policy.
    The Select Deployment Scenario screen opens.
  5. For Deployment Scenario, select Create a security policy using third party vulnerability assessment tool output and click Next.
    The Configure Security Policy Properties screen opens.
  6. In the Security Policy Name field, type a unique name for the policy.
  7. From the Application Language list, select the language encoding of the application, then click Next.
    Important: You cannot change this setting after you have created the security policy.
  8. For Enforcement Mode specify whether or not the system blocks traffic that violates the security policy.
    • Leave the value set to Transparent, the default value, if you want to review and fine-tune the security policy before placing it in Blocking mode.
    • If you want the system to enforce the security policy immediately, select Blocking.
  9. If the application is case-sensitive, select the Security Policy is case sensitive check box. Otherwise, leave it cleared.
    Important: You cannot change this setting after you have created the security policy.
  10. If you do not want the security policy to distinguish between HTTP/WebSocket and HTTPS/WebSocket Secure URLs, clear the Differentiate between HTTP/WS and HTTPS/WSS URLs check box. Otherwise, leave it selected.
  11. Click Next.
    The Vulnerability Assessments Settings screen opens.
  12. From the Vulnerability Assessment Tool list, select WhiteHat Sentinel.
  13. In the Configure exceptions for the scanner IP Address setting, specify any IP addresses that you want the security policy to allow (for example, the IP address of the vulnerability assessment tool), and how to deal with them.
    1. Type the IP address and netmask of the vulnerability assessment tool.
      You can add  %n  after an IP address to specify a route domain, where n  is the route domain identification number.
    2. Select the appropriate check boxes for learning suggestions, logging, and blocking traffic from this IP address.
  14. For Learning Mode, select how you want the Policy Builder to build the security policy.
    • If you want the Policy Builder to automatically build the security policy, select Automatic.
    • If you want the Policy Builder to make suggestions and manually decide what to include, select Manual.
    • If you do not want the system to suggest policy changes, select Disabled.
    Note: In some cases, running the Policy Builder may overwrite some of the security policy changes suggested by the vulnerability assessment tool. For example, to prevent false positives, the Policy Builder might adjust some of the entities in the security policy based on examining the traffic.
    If you select Automatic or Manual, the system examines traffic and makes suggestions about how to tighten the security policy. If you are using automatic learning, the system enforces the suggestions when it is reasonable to do so. If you are using manual learning, you need to examine the changes and accept, delete, or ignore them on the Traffic Learning screen. If you disabled this option, the system does not do any learning for this policy, it makes no suggestions, and the Learn flag for all violations becomes inactive.
  15. Click Next.
    The Security Policy Configuration Summary screen opens.
  16. Review the settings for the security policy. When you are satisfied with the security policy configuration, click Finish.
    The system creates the security policy and opens the vulnerability assessment settings screen specific to the tool you are using. For most tools, you can import the results of a vulnerabilities scan in an XML file.
  17. Verify that the Vulnerability Assessment Tool is set to WhiteHat Sentinel.
  18. To share information about the web site structure with WhiteHat Sentinel, select the Share Site Map with Vulnerability Assessment Tool check box, and from the Scheduled Synchronization list, select how often to send the information.
  19. For WhiteHat Web API Key, type the key generated and supplied by WhiteHat Sentinel for your web application.
    Note: If you do not have a web API key, click the Get a free website security assessment from WhiteHat link. A popup screen opens where you can fill in a form to request a free website security assessment. A WhiteHat representative verifies eligibility, then initiates the scan. ASM automatically downloads the results into the security policy, where you can mitigate the vulnerabilities. In this case, you do not have to complete the rest of the steps in this procedure.
  20. Click Refresh WhiteHat Site Names List to populate the WhiteHat Site Name list with the names of web applications configured under the WhiteHat Web API key. If this BIG-IP system cannot communicate with the WhiteHat service, type the application site name (defined in your WhiteHat account) in the Custom box.
  21. On the menu bar, click Vulnerabilities.
  22. Next, import the vulnerabilities from the WhiteHat Sentinel server. Click Import.
    The Import WhiteHat Sentinel Verified Vulnerabilities popup screen opens.
  23. For Import Method, select how to import the vulnerability report:
    Option Description
    Download verified vulnerabilities directly from WhiteHat Sentinel service Download the vulnerability file from the Sentinel server directly to the Application Security Manager.
    Import previously saved vulnerabilities file Upload a previously downloaded vulnerabilities file to the Application Security Manager. Type the name of the file, or click Browse to search for it.
  24. Click Import.
    The system imports the vulnerabilities the WhiteHat Sentinel service discovered during the last scan of the application.
The system creates a baseline security policy for your web application but does not yet protect against the vulnerabilities discovered by WhiteHat Sentinel. The policy type is Vulnerability Assessment.
Note: When integrating with WhiteHat Sentinel, Application Security Manager has to recognize whether a request is coming from the WhiteHat server. This enables ASM to communicate with WhiteHat Sentinel so the WhiteHat portal can mark fixed vulnerabilities as Mitigated by WAF.

ASM identifies requests sent by WhiteHat Sentinel using the published source IP of the WhiteHat Sentinel service. However, ASM does not see the original source IP address of requests if the BIG-IP system is behind a NAT (or NAT firewall), or if you are using a WhiteHat Satellite box. In these configurations, vulnerabilities that ASM protects against are not shown as mitigated in WhiteHat Sentinel.

To resolve this issue, set one or more of the WhiteHatIP# system variables to the redirected source IP addresses or subnets ( Security > Options > Application Security > Advanced Configuration > System Variables ). ASM then treats the address as one of the WhiteHat addresses, and sends WhiteHat information on vulnerabilities that ASM has mitigated.

Next, you need to review and resolve vulnerabilities on the Vulnerabilities screen so that the security policy protects against them.

Creating a vulnerability file

Before you can upload a vulnerability scan file from WhiteHat Sentinel, you need the following:
  • Up-to-date WhiteHat Sentinel subscription and valid login credentials (sentinel.whitehatsec.com)
  • WhiteHat Sentinel Web API key for your account
  • Site name (as defined in your WhiteHat account)
  • Computer with Internet access
If the BIG-IP® system does not have Internet access, you can use WhiteHat Sentinel to run a vulnerability scan on a system that does have access, then save the results of the scan as an XML file. You can then upload the vulnerability file onto Application Security Manager™. If the BIG-IP system does have Internet access, you do not need to follow this procedure.
  1. On a computer with Internet access, open a browser and run the WhiteHat Sentinel vulnerability scan by typing the following command:
    https://sentinel.whitehatsec.com/api/vuln/?display_attack_vectors=1&key=<WhiteHat_web_API_key >&display_param=1&query_site=<website_name>
    Note: Replace <WhiteHat_web_API_key> with the WhiteHat Web API Key, and replace <website_name> with the name of the web site you want WhiteHat Sentinel to scan for vulnerabilities.
    The results of the vulnerability scan appear in the web browser in XML format.
  2. Save the results as an XML file.
You have created the vulnerability scan file that you need to create a security policy using vulnerability assessment. Place it in a location where you can access it from Application Security Manager, and upload it when creating a security policy integrated with WhiteHat Sentinel.

Resolving vulnerabilities when using WhiteHat Sentinel

Before you can resolve vulnerabilities for a security policy, the security policy must be associated with a vulnerability assessment tool (WhiteHat Sentinel, in this case), and have the vulnerabilities file imported to it.
When you resolve vulnerabilities discovered by WhiteHat Sentinel, the security policy protects against them. Application Security Manager™ (ASM) can resolve some vulnerabilities automatically. Others require some manual intervention on your part, and ASM™ provides guidance on what to do.
  1. On the Main tab, click Security > Application Security > Vulnerability Assessments .
    The Vulnerabilities screen opens and lists the vulnerabilities that the vulnerability assessment scan discovered.
  2. In the Vulnerabilities Found and Verified area, you can filter the vulnerabilities that are displayed using the View and Vulnerabilities with lists.
    View Option What it displays
    All All vulnerabilities found by the scanner.
    Resolvable All vulnerabilities that are resolvable either automatically or manually.
    Resolvable (Automatically) Vulnerabilities that ASM can resolve.
    Resolvable (Manually) Vulnerabilities that can be resolved with some manual intervention.
    Not Resolvable Vulnerabilities that are not resolvable.
    Vulnerabilities with option What it displays
    Any Vulnerabilities in any state.
    Closed Vulnerabilities that no longer exist and were resolved by the application (not by ASM).
    Mitigated Vulnerabilities that ASM has mitigated, or those which have been fixed and marked as mitigated.
    Open Vulnerabilities that need to be dealt with.
  3. Review the vulnerabilities that the assessment tool has detected and verified.
    1. Click a row in the table to display details about the vulnerability.
      Below the Vulnerabilities Found table, a list of the specific vulnerabilities is displayed.
    2. To add notes about the vulnerability, click the pencil icon in the ASM Status column.
      The Vulnerability Notes popup opens where you can add notes.
  4. For the vulnerabilities that are shown as Resolvable (Automatically), select the vulnerabilities you want the system to resolve (or ignore), and click the appropriate button.
    Option What it does
    Resolve and Stage Updates the security policy to protect against the vulnerability, and puts parameters in staging. Entities in staging do not cause violations, and this allows you to fine-tune their settings without causing false positives.
    Resolve Updates the security policy to protect against the vulnerability.
    Ignore Changes the ASM Status of the selected vulnerability from Pending to Ignore. If later you decide to protect against this vulnerability, you can select it and click Cancel Ignore.
    ASM reviews the prerequisites and then displays a list of the changes it will make to fix the vulnerability.
  5. If you agree with the changes, click Resolve.
    ASM modifies the security policy to protect against the vulnerabilities for which you clicked Resolve and ignores the rest. In the Vulnerabilities list, the ASM Status column for the vulnerability changes to Mitigated or Mitigated (In Staging), if appropriate.
  6. For the vulnerabilities that are shown as Resolvable (Manually), select the vulnerability you want to work on, and click the appropriate button.
    Option What it does
    Show Resolution Opens a popup that describes the vulnerability and its possible impact, shows the steps required to manually fix the vulnerability, and describes any risks that might result from making the changes.
    Change ASM Status to Mitigated Changes the status of the vulnerability to say Mitigated. Recommended after you manually fix vulnerabilities.
    Ignore Changes the ASM Status of the selected vulnerability from Pending to Ignore. If later you decide to protect against this vulnerability, you can select it and click Cancel Ignore.
  7. Click Apply Policy to save the changes to the security policy.
    The system updates the security policy to prevent the handled vulnerabilities from reoccurring.
  8. Select all of the vulnerabilities you dealt with and click Retest to have the WhiteHat Sentinel service verify that the vulnerability has been dealt with.
The security policy for your web application protects against the vulnerabilities that the vulnerability assessment tool discovered and which you resolved manually or automatically. The ASM Status of vulnerabilities that have been dealt with is set to Mitigated.
You can periodically rescan your system to check for additional vulnerabilities that need to be resolved.

Reviewing learning suggestions

After you create a security policy, the system provides learning suggestions concerning additions to the security policy based on the traffic that is accessing the application. For example, you can have users or testers browse the web application. By analyzing the traffic to and from the application, Application Security Manager™ generates learning suggestions or ways to fine-tune the security policy to better suit the traffic and secure the application.

Note: This task is primarily for building a security policy manually. If you are using the automatic learning mode, this task applies to resolving suggestions that require manual intervention, or for speeding up the enforcement of policy elements.
  1. On the Main tab, click Security > Application Security > Policy Building > Traffic Learning .
    The Traffic Learning screen opens, and lists suggestions based on traffic patterns and violations that the system has detected.
  2. If you want to change the order in which the suggestions are listed, or refine what is included in the list, use the filters at the top of the column.
    You can also list the suggestions by average violation rating of all matching requests, first occurrence, last occurrence, matched entity name, or use the search filter to display specific types of suggestions that you are interested in.
    By default, the suggestions that have the highest learning score (those closest to being ready to be enforced) are listed first. Suggestions have higher learning scores if that traffic has met the conditions in the policy, if it originates from many sources, if it is unlikely to be a violation, or if the traffic comes from a trusted IP address. They may also be suggestions to add an entity the system learns, for example, a new file type, URL, or parameter.
  3. On the Traffic Learning screen, review each learning suggestion.
    1. Select a learning suggestion.
      Information is displayed about the action the system will take if you accept the suggestion, and what caused the suggestion.
    2. You can learn more about the suggestion by looking at the action, the number of samples it is based on, the violations caused and their violation ratings, and if needed, by examining samples of the requests that caused the suggestion.
    3. With a request selected on the left, you can view data about the request on the right, including any violations it generated, the contents of the request itself, and the response (if any). Note that some requests may contain violations related to different suggestions.
      By examining the requests that caused a suggestion, you can determine whether it should be accepted.
    4. To add comments about the suggestion and the cause, click the Add Comment icon and type the comments.
  4. Decide how to respond to the suggestion. You can start with the suggestions with the highest learning scores, or those which you know to be valid for the application. These are the options.
    Option What happens
    Accept Suggestion The system modifies the policy by taking the suggested action, such as adding an entity that is legitimate. If the entity that triggered the suggestion can be placed in staging (file types, URLs, parameters, cookies, or redirection domains), clicking Accept Suggestion displays a second option, Accept suggestion and enable staging on Matched <<entity>>. Click this option to accept the suggestion and place the matched entity in staging.
    Delete Suggestion The system removes the learning suggestion, but the suggestion reoccurs if new requests cause it. The learning score of the suggestion starts over from zero in that case.
    Ignore Suggestion The system does not change the policy and stops showing this suggestion on the Traffic Learning screen now and in the future. You can view ignored suggestions by filtering by status ignored.
    Leave the suggestion You can read the suggestions and wait to handle them until more traffic has passed through, or until you get more information. The suggestion remains in the list and no changes are made to the policy.
    Note: If you are working in automatic learning mode, when the learning score reaches 100%, the system accepts most of the suggestions, or you can accept suggestions manually at any time. If you are using manual learning, when the learning score reaches 100% (or before that if you know the suggestions are valid), you need to accept the suggestions manually.

    If you know that a suggestion is valid, you can accept it at any time even before the learning score reaches 100%. The ones that reach 100% have met all the conditions so that they are probably legitimate entities.

  5. To put the security policy changes into effect immediately, click Apply Policy.
By default, a security policy is put into an enforcement readiness period for seven days. During that time, you can examine learning suggestions and adjust the security policy without blocking traffic. The security policy then includes elements unique to your web application.
It is a good idea to periodically review the learning suggestions on the Traffic Learning screen to determine whether the violations are legitimate and caused by an attack, or if they are false positives that indicate a need to update the security policy. Typically, a wide recurrence of violations at some place in the policy (with a low violation rating and a high learning score) indicates that they might be false positives, and hence the policy should be changed so that they will not be triggered anymore. If the violations seem to indicate true attacks (for example, they have a high violation rating), the policy should stay as is, and you can review the violations that it triggered.

Learning suggestions you must handle manually

Some learning suggestions must be resolved manually even if you are using the Automatic Learning Mode to create a security policy. Suggestions typically require manual intervention if they involve changing an attribute that was manually and deliberately set in the policy, such as a disallowed geolocation or a session ID in a URL. The system does not change the policy unless you accept the suggestion manually.

You can easily see the suggestions that you need to resolve manually because they are marked with an icon on the Traffic Learning screen as shown in the figure. You can also use the advanced filter to view the suggestions the have Learning Mode set to Manual, and this would list the suggestions you need to resolve.

Manually resolvable suggestions

Suggestions that must be resolved manually

If you are using the Manual Learning Mode, you must resolve all of the suggestions manually.

Enforcing a security policy

You only need to enforce a security policy if it was created manually (not using automatic learning), and if it is operating in transparent mode. Traffic should be moving through Application Security Manager™, allowing users to access the web application for which you set up the security policy.
When you enforce a security policy, the system blocks requests that cause violations that are set to block.
  1. On the Main tab, click Security > Application Security > Policy Building > Learning and Blocking Settings .
    The Learning and Blocking Settings screen opens.
  2. In the Current edited policy list near the top of the screen, verify that the edited security policy is the one you want to work on.
  3. For the Enforcement Mode setting, select Blocking.
  4. Review each of the policy building settings so you understand how the security policy handles requests that cause the associated violations, and adjust if necessary. You need to expand most of the settings to see the violations.
    Tip: To the right of Policy Building Settings, click Blocking Settings to see and adjust all of the violations at once.
    Option What happens when selected
    Learn The system generates learning suggestions for requests that trigger the violation (except learning suggestions are not generated for requests that return HTTP responses with 400 or 404 status codes).
    Alarm When selected, the system marks requests that trigger the violation as illegal. The system also records illegal requests in the Charts screen, the system log (/var/log/asm), and possibly in local or remote logs (depending on the settings of the logging profile).
    Block The system blocks requests that trigger the violation when (1) the security policy is in the blocking enforcement mode, (2) a violation occurs, and (3) the entity is enforced. The system sends the blocking response page (containing a Support ID to identify the request) to the client.
  5. Click Save to save your settings.
  6. On the Main tab, click Security > Application Security > Security Policies .
    The Active Policies screen opens.
  7. Click the name of the security policy you want to work on.
    The Policy Properties screen opens.
  8. To change the number of days that the security policy entities and attack signatures remain in staging, change the value in the Enforcement Readiness Period field.
    The security policy does not block traffic during the Enforcement Readiness Period even if violations occur.
  9. If you want to immediately block traffic that causes violations, you need to enforce entities that are ready to be enforced. This is one way to do this quickly:
    1. Set the Enforcement Readiness Period to 0. (Not generally recommended. Use only if you want to speed up the process.)
    2. Click Save.
    3. On the Main tab, click Security > Application Security > Policy Building > Enforcement Readiness .
    4. Click Enforce Ready.
    In most cases, it is better to use a longer Enforcement Readiness Period, such as the default of 7 days. The entities become ready to be enforced after that.
  10. To put the security policy changes into effect immediately, click Apply Policy.
  11. For a quick summary of system activity, look at the Overview screen ( Security > Overview > Application ).
    The Summary screen displays statistical information about Application Security traffic.
After the enforcement readiness period is over and the enforcement mode is set to blocking, the security policy no longer allows requests that cause violations set to block to reach the back-end resources. Instead, the security policy blocks the request, and sends the blocking response page to the client.
Table of Contents | << Previous Chapter | Next Chapter >>
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5 Networks, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information