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 .
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.
-
On the Main tab, click .
The Active Policies screen opens.
-
Click the Create button.
The Deployment wizard opens to the Select Local Traffic Deployment
Scenario screen.
-
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.
-
Configure the new or existing virtual server, and click
Next.
- If creating a new virtual server, specify the protocol, name, IP address
and port, pool 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 new or existing virtual server becomes the name of the
security policy.
The Select Deployment Scenario screen opens.
-
For Deployment Scenario, select Create a
policy using third party vulnerability assessment tool output
and click Next.
The Configure Security Policy Properties screen opens.
-
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.
-
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.
-
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.
-
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.
-
Click Next.
The Vulnerability Assessments Settings screen opens.
-
From the Vulnerability Assessment Tool list, select
WhiteHat Sentinel.
-
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 vulnerabilities assessment tool), and how to
deal with them.
-
Type the IP address and netmask of the vulnerabilities assessment
tool.
You can add %n after an IP address to specify
a route domain, where n is the route domain
identification number.
-
Select the appropriate check boxes for learning suggestions, logging,
and blocking traffic from this IP address.
-
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.
-
Click Next.
The Security Policy Configuration Summary screen opens.
-
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.
-
Verify that the Vulnerability Assessment Tool is set to
WhiteHat Sentinel.
-
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.
-
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.
-
On the menu bar, click Vulnerabilities.
-
Next, import the vulnerabilities from the WhiteHat Sentinel server. Click
Import.
The Import WhiteHat Sentinel Verified Vulneabilities popup screen
opens.
-
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. |
-
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. 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 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 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.