Applies To:

Show Versions Show Versions

Manual Chapter: Using WhiteHat Sentinel for a Security Policy
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Overview: Vulnerability assessment policy building

Application Security Manager™ (ASM) integrates with services, such as IBM® Rational® AppScan®, Cenzic® Hailstorm®, and QualysGuard®, as well as WhiteHat Sentinel, that perform vulnerability assessments of web applications. Vulnerability assessment services identify, classify, and report 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 a vulnerability assessment tool. By using vulnerability assessment tool output, the system suggests updates to the security policy that can protect against the vulnerabilities that the tool found. You can choose which of the vulnerabilities you want the security policy to handle, retest to be sure that the security policy protects against the vulnerability, and then enforce the security policy when you are ready.

Creating a security policy integrated with WhiteHat Sentinel

Before you can integrate WhiteHat Sentinel with Application Security Manager™ (ASM™), 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
  • Web application name or URI of the site you want to scan
  • Recent Sentinel scan of the web application you want to protect
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 on a system that does have access, then save the results of the scan as an XML file.

You need to complete the basic BIG-IP system configuration tasks including defining a VLAN, a self IP address, a local traffic pool, an application security class, and a virtual server, according to the needs of your networking environment. You also need to configure a DNS address ( System > Configuration > Device > DNS) , and restart ASM (at the command line, type tmsh restart /sys service asm).

Note: If you have a standalone Application Security Manager system, you can optionally create an application security class, a virtual server, and a local traffic pool as part of creating a security policy using the Deployment wizard.
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 Application Security > Security Policies. The Active Security Policies screen opens.
  2. Click the Configure Security Policy link for the application security class you created.
  3. For Deployment Scenario, select Create a policy using third party vulnerability assessment tool output and click Next.
  4. From the Application Language list, select the language encoding of the application and click Next.
    Important: You cannot change this setting after you have created the security policy.
    The Vulnerability Assessments Settings screen opens with WhiteHat Sentinel selected as the vulnerability assessment tool.
  5. For WhiteHat Web API Key, type the key generated and supplied by WhiteHat Sentinel for your web application.
  6. 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 URI or name of the application web site in the Custom WhiteHat Site Name box.
  7. Click Next. The Security Policy Configuration Summary screen opens.
  8. 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 Import Vulnerabilities screen.
  9. Next, import the vulnerabilities from the WhiteHat Sentinel server. For Import Method, select how to import a 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.
    Upload file previously saved vulnerabilities file Upload a previously downloaded vulnerability file to the Application Security Manager. Type the name of the file, or click Browse to search for it.
  10. 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 or enforce the policy.
Note:

When integrating with WhiteHat Sentinel, Application Security Manager has to recognize whether a request is coming from the WhiteHat server. This allows ASM™ to return header information to WhiteHat Sentinel so it can mark the vulnerability 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 ASM 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 internal parameters 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
  • Web application name or URI of the site you want to scan
  • 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 or URI 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

You can resolve vulnerabilities only on a security policy that was created using the Vulnerabilities Assessments deployment scenario.
When you resolve vulnerabilities, Application Security Manager™ (ASM™) configures the security policy to protect against them.
  1. On the Main tab, click Application Security > Security Policies. The Active Security Policies list opens.
  2. Click the name of the security policy integrated with your vulnerability assessment tool. The security policy Properties screen opens.
  3. From the Vulnerability Assessments menu, click Vulnerabilities. The Vulnerabilities screen opens and lists the vulnerabilities that the vulnerability assessment scan discovered.
  4. In the Vulnerabilities Found and Verified area, review the vulnerabilities that the assessment tool has detected and verified.
    Tip: Click a row in this table to display details about the vulnerability.
  5. For the vulnerabilities that are shown as Resolvable, 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 again 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 again 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.
    BIG-IP® 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, if appropriate.
  6. Click Apply Policy to save the changes to the security policy. The system updates the security policy to prevent the handled vulnerabilities from reoccurring.
  7. If using WhiteHat Sentinel, select all of the vulnerabilities you dealt with and click Retest to have the WhiteHat Sentinel service check whether the vulnerability still exists.
The security policy for your web application protects against the vulnerabilities that the vulnerability assessment tool discovered and which you resolved.
You can also review vulnerabilities that ASM cannot resolve and update the security policy manually to protect against them.

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.
  1. On the Main tab, click Application Security > Policy Building > Manual. The Traffic Learning screen opens, and lists violations and learning suggestions that the system has found based on real traffic.
  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 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. On the 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 operation.
  4. To activate the updated security policy, on the top right of the screen, click Apply Policy, then click OK to confirm.
The security policy now 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, or if they are false positives that indicate a need to update the security policy

Enforcing a security policy

To perform enforcement tasks, the security policy must be operating in transparent mode, and have been created manually. Traffic should be moving through Application Security Manager™, and users have access to the web application for which you set up the security policy.
When you enforce a security policy, the system to blocks requests that cause violations that are set to block.
  1. On the Main tab, click Application Security > Policy > Blocking. The Settings screen shows the violations that can be detected, and how the security policy responds to requests that cause those violations (whether the system learns information from the illegal request, generates an alarm, or blocks the request).
  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 each violation, review the settings so you understand how the security policy handles requests that cause the violation.
    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 ( Reporting > Charts ), the Syslog (/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.
  4. On the Main tab, click Application Security > Policy.
  5. For the Enforcement Mode setting, select Blocking.
  6. To change the number of days the security policy remains in staging, change the value in the Staging-Tightening Period field. For details, see the online help.
  7. Click Save.
  8. In the editing context area, click Apply Policy to immediately put the changes into effect.
  9. For a quick summary of system activity, look at the Overview screen ( Application Security > Overview ).
After the staging 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 >>

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)