Manual Chapter : Using WhiteHat Sentinel for a Security Policy

Applies To:

Show Versions Show Versions

BIG-IP ASM

  • 11.6.5, 11.6.4, 11.6.3, 11.6.2, 11.6.1
Manual Chapter

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 adding a virtual server, configure the new or existing virtual server, and click Next.
    • If creating a new virtual server, specify the protocol, name, virtual server destination address and port, and pool member IP address and port.
    • If using an existing virtual server, it must have an HTTP profile and cannot be associated with a local traffic policy.
    • 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 name of the virtual server becomes the name of the security policy. The Select Deployment Scenario screen opens.
  5. For Deployment Scenario, select Create a policy using third party vulnerability assessment tool output and click Next. The Configure Security Policy Properties screen opens.
  6. 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.
  7. 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.
  8. 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.
  9. If you do not want the security policy to distinguish between HTTP and HTTPS URLs, clear the Differentiate between HTTP and HTTPS URLs check box. Otherwise, leave it selected.
  10. Click Next. The Vulnerability Assessments Settings screen opens.
  11. From the Vulnerability Assessment Tool list, select WhiteHat Sentinel.
  12. 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.
  13. If you want to use automatic policy building, leave the Real Traffic Policy Builder check box selected.
    Note: In some cases, running the Real Traffic 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 selected, the system runs the Policy Builder when you finish creating the policy.
  14. Click Next. The Security Policy Configuration Summary screen opens.
  15. 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.
  16. Verify that the Vulnerability Assessment Tool is set to WhiteHat Sentinel.
  17. 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.
  18. 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.
  19. 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.
  20. On the menu bar, click Vulnerabilities.
  21. Next, import the vulnerabilities from the WhiteHat Sentinel server. Click Import. The Import WhiteHat Sentinel Verified Vulneabilities popup screen opens.
  22. 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.
  23. 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. 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 Description
    All Displays all vulnerabilities found by the scanner.
    Resolvable Displays all vulnerabilities that are resolvable either automatically or manually.
    Resolvable (Automatically) Displays vulnerabilities that ASM can resolve.
    Resolvable (Manually) Displays vulnerabilities that can be resolved with some manual intervention.
    Not Resolvable Displays vulnerabilities that are not resolvable
    Vulnerabilities with option Description
    Any Displays vulnerabilities in any state.
    Closed Displays vulnerabilities that no longer exist and were resolved by the application (not by ASM).
    Mitigated Displays vulnerabilities that ASM has mitigated, or those which have been fixed and marked as mitigated..
    Open Displays 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 Description
    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 Description
    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. If using WhiteHat Sentinel, 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.

Fine-tuning a security policy

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: If you are using the Policy Builder to add elements to the security policy, you can skip this task. This option is primarily for building a security policy manually.
  1. On the Main tab, click Security > Application Security > Policy Building > Manual Traffic Learning. The Manual Traffic Learning screen opens, and lists violations that the system has detected.
  2. In the Traffic Learning area, click each violation hyperlink, then review and handle learning suggestions:
    Option Description
    Accept Select a learning suggestion, click Accept, and then click Apply Policy. The system updates the security policy to allow the file type, URL, parameter, or other element.
    Clear Select a learning suggestion, and click Clear. The system removes the learning suggestion and continues to generate suggestions for that violation.
    Cancel Click Cancel to return to the Manual Traffic Learning screen.
    By default, a security policy is put into a staging-tightening period for seven days. During this time, you can examine learning suggestions and adjust the security policy without blocking traffic.
  3. To find out more about a violation and its occurrences, when you click a violation hyperlink and see what caused the violation, click the number in the Occurrences column. The Requests List popup screen opens, and you can see the requests that caused the violation including a violation rating of the request. (Ratings are from 1 to 5, where is the most severe.)
  4. To decide whether the request is an attack or a false positive, look at the violation rating.
    1. Click Violation Rating on the Request List screen.
    2. Look at the bar chart that displays the violation rating and number of occurrences.
    3. If the violation rating is 1 or 2, it is most likely a false positive and you can close the Requests List, select the violation, and click Accept. This accepts the learning suggestion to the security policy. What this means depends on the violation. It could be to allow a parameter or URL that looks suspicious but is allowed on your web site, it might mean to unselect certain security failures, or it might mean to disable an attack signature.
    4. If the violation rating is 4 or 5, it is most likely an attack and you can close the Requests List, select the violation, and click Clear. You probably do not want to change the policy to accept a suggestion that would allow an attack, so you would clear the suggestion without changing the policy.
    5. If the violation rating is 3, the request needs further investigation. You can go back to the Requests List and click the request to examine it more closely.
  5. On the Manual Traffic Learning screen, review the violations and consider whether you want to permit any of them (for example, if a violation is causing false positives). Select any violations you do not want the system to trigger, and click Disable Violation. A popup screen opens, and you can verify that you want to disable the violations or cancel the action.
  6. To put the security policy changes into effect immediately, click Apply Policy.
  7. On the Main tab, click Security > Overview > Application > Action Items. The Action Items screen opens.
  8. Examine the Action Items screen for information about recommended actions that you need to complete.
    1. Review the Suggested Action Items area, which lists system tasks and security policy tasks that should be completed.
    2. Click the links in the Suggested Action Items area to go to the screen where you can perform the recommended action.
    3. In the Quick Links area, click any of the links to gain access to common configuration and reporting screens.
The security policy now includes elements unique to your web application.
It is a good idea to periodically review the learning suggestions on the Manual Traffic Learning screen to determine whether the violations are legitimate, or if they are false positives that indicate a need to update the security policy.

Enforcing a security policy

You only need to enforce a security policy if it was created manually (not using the automatic policy builder), and 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 > Blocking. The 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. For each violation, review the settings so you understand how the security policy handles requests that cause the violation, and adjust if necessary.
    Option Description
    Learn If selected, the system generates learning suggestions for requests that trigger the violation.
    Alarm If selected, the system records requests that trigger the violation 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 If selected (and the enforcement mode is set to Blocking), the system blocks requests that trigger the violation.
    Tip: Click the information icon preceding a violation for a description of it.
  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 Properties screen opens.
  8. To change the number of days the security policy remains 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 block traffic that causes violations, you need to enforce violations. One way to do this is:
    1. Set the Enforcement Readiness Period to 0.
    2. Click Save.
    3. On the Main tab, click Security > Application Security > Policy Building > Enforcement Readiness.
    4. Click Enforce Ready.
  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.