You will learn

How to create a scan and determine vulnerability status in WhiteHat.

Prerequisites

Audience: IT Professional
Difficulty: Intermediate
Time needed: Approximately 15 minutes
Tools required: N/A

For general information & instructions on the use of Remote Providers within ThreadFix, please refer to this page's parent page: Remote Providers. For information on REST API functionality for Remote Providers, please refer to the following: Remote Providers API

Introduction

WhiteHat doesn't manage application scanning in a typical way. There is no concept of a scan file to indicate an atomic scan action with a start and an end, so ThreadFix must artificially create that concept. Additionally, vulnerabilities can evolve over time within WhiteHat with multiple attack vectors being identified. Each attack vector will have its own properties around found and tested dates and will have its own state which could be distinct from the parent vulnerability state. ThreadFix manages all this data in a very specific way as described below.

Application Fetch

The following WH endpoint is used to fetch applications:

https://sentinel.whitehatsec.com/api/site/
More information here

Scan Fetch

WhiteHat does not provide an endpoint to fetch 'scans'.
Instead, it provides an endpoint that is used to fetch all vulnerabilities. We use the following endpoint and parameters to return vulnerabilities for a specific application. For EU region, substitute https://sentinel.whitehatsec.com for https://sentinel.whitehatsec.eu.

Fetch last completed scan based on Site ID

https://sentinel.whitehatsec.com/api/site/{site_id}?display_links_last_completed_scan=1&key={apiKey}

Fetch all vulnerabilities based on Site ID

https://sentinel.whitehatsec.com/api/vuln?key={apiKey}&display_description=1&display_solution=1&display_attack_vectors=1&display_risk=1&display_impact=1&display_likelihood=1&display_custom_risk=1&query_site={site_id}&page:order_by=modified_desc

Vulnerability Parsing

Much like other XML parsers when hitting the 'vulnerability' tag we pull the following data:

Native Id
Vulnerability code
Severity code
URL reference

When the parser hits 'attack vectors', each one is parsed for the following pieces of information:

Tested date
Attack vector state
Found date

These are used to create a DateStatus object, which is used to determine the scan to which each finding belongs.
The scanDateList List is used to create "scans" later.

Initial Scan Creation

The first time you import results for an application in WhiteHat into an application in ThreadFix, scan objects will be created on behalf of WhiteHat in one of two different ways depending on how you configure the Remote Provider connection.

To ensure that the bulk import does not abort prematurely, a remote provider integrations should be setting the latest import status to `NO_SCANS` when an application is found to have no scans.

All Vulnerabilities

If the user selected the "All Vulnerabilities" option when configuring their remote provider, then ThreadFix will create as many artificial "scan" objects as required to encapsulate all historic data for both open and closed vulnerabilities in WhiteHat. The way scans are defined when pulling old data from WhiteHat is based on a grouping we perform around the WhiteHat vulnerabilities and their attack vectors' found and tested dates. Put simply, we bundle WhiteHat vulnerabilities into scans with a scan date based on when an attack vector was found and last tested grouped into calendar days.

Open Vulnerabilities

If instead of "All Vulnerabilities", "Open Vulnerabilities" was selected when configuring the remote provider, ThreadFix will pull in only the open vulnerabilities in WhiteHat, and they'll be bundled into a single initial scan object. ThreadFix will not pull in any data related to closed vulnerabilities in WhiteHat. All subsequent imports will create new scan objects using the method described above for all vulnerability updates after the most recent import.

When there is no scan data to import, a “No scans were found” message will display as the Last Import Attempt Status.

Determining WhiteHat Vulnerability Status

Because of the unique nature of the WhiteHat findings, some logic needed to be employed to map their concept of Vulnerabilities and Attack Vectors to the ThreadFix concept of Findings, taking into account the different States each Attack Vector could have as well as the different Found Dates and Tested Dates. The following table describes how we determine if a WhiteHat Vulnerability is Open, Closed, or a False Positive. It shows a hypothetical WhiteHat Vulnerability with 3 Attack Vectors within it. The statuses of the Vulnerability and the Attack Vectors are listed, with the resultant ThreadFix Finding status listed in the bottom row.

	Status
WH Vulnerability	Open	Closed	Open	False Positive
WH Attack Vector 1	Open	Any Value	NOT Open	Any Value
WH Attack Vector 2	Any Value	Any Value	NOT Open	Any Value
WH Attack Vector 3	Any Value	Any Value	NOT Open	Any Value
ThreadFix Finding	Open	Closed	False Positive	False Positive

Verified Findings

Findings that have been marked as "Verified" in WhiteHat Sentinel will be provided a status of "Scanner Exploitable" in ThreadFix, as highlighted below.

1 You will learn
- 1.1 Prerequisites
- 1.2 Introduction
  - 1.2.1 Application Fetch
  - 1.2.2 Scan Fetch
    - 1.2.2.1 Fetch last completed scan based on Site ID
    - 1.2.2.2 Fetch all vulnerabilities based on Site ID
  - 1.2.3 Vulnerability Parsing
  - 1.2.4 Initial Scan Creation
  - 1.2.5 All Vulnerabilities
  - 1.2.6 Open Vulnerabilities
  - 1.2.7 Determining WhiteHat Vulnerability Status
  - 1.2.8 Verified Findings

ThreadFix Documentation

WhiteHat Sentinel Remote Provider