WhiteHat Security Index (WSI) Report
The WhiteHat Security Index (WSI) indicates the overall security profile of a given site. This site specfic value will change as changes are made to the site, vulnerabilities found or remediated, or other factors that security index is based on change.
|The WSI can be calculated only for dynamic sites, not for static applications.|
The WSI provides:
A single numerical metric that usefully measures a single asset’s security
An overall evaluation of the security of an asset for engineering managers and executives
Guidance for the security team in determining which vulnerabilities are most critical
A simple, transparent metric
An understanding of the asset’s security in relation to the relevant industry and to our global set of clients
Sufficient granularity that moderate changes by the client will be reflected in the index
Sufficient stability to ensure that small, short-lived changes do not result in large changes in the score
Easy dimensional modeling and analysis
WhiteHat Security Index Distribution
The following graph shows the general distribution of WhiteHat Security Index values for your sites. (Higher scores reflect improved site security.)
The following graph shows the general distribution of WhiteHat Security Index values for all Sites currently assessed by WhiteHat Security. (Higher scores reflect improved site security.)
|All Sites refers to all the sites currently being scanned by WhiteHat Sentinel.|
The WhiteHat Security Index (WSI) is designed to encourage clients to act in ways that increase security, and to discourage dangerous behaviors and policies, to safeguard the index from deliberate manipulation (gaming the system), and to encourage engagement with WhiteHat Security to improve web application security.
List of Assets
This table describes each sites' security index, recommended actions and security index trend.
Individual Site Reports
The following individual site report shown below gives details for each site. The site-specific pages will show you:
The name and service level for each site.
The current WhiteHat Security Index value for that specific site, and where that falls in the industry and global rankings. (The industry used for comparison purposes is displayed below the percentile scores.)
A chart showing variations in the WhiteHat Security Index value for that site over the last year. Note that if the site has not been under contract with WhiteHat long enough for three full scans to be completed, a trend chart will not be available. In that case, the date the site was created and the number of completed scans will be displayed.
Top recommended actions, which may include specific vulnerabilities to be remediated or actions to be taken such as providing credentials or an assessment schedule for the site in Sentinel.
Running the WhiteHat Security Index Report
The WSI Report runs as a PDF or CSV report for more information on generating this report, please see Reports Section
WSI Report Methodology
The WhiteHat Security Index is based on measuring multiple factors over time. By including the current state and history for each factor, we can evaluate the probability that significant new vulnerabilities will be discovered and remediated appropriately. Additionally, tracking the past performance of an asset helps keep the index value stable when new vulnerabilities are detected so that major releases may introduce new vulnerabilities without causing a drastic change in the model, but failure to remediate those vulnerabilities over time will be reflected by a decrease in the index.
The WhiteHat Security Index is designed to reward security-conscious behavior; the weight given to a vulnerability is based in part on how long it has been exposed, as well as on its rating, and the Index rewards closing vulnerabilities.
Each factor that contributes to the Security Index is calculated using sophisticated statistical analysis, and measures are included to prevent gaming the system.
Factors considered in the Security Index include:
Service Duration: How long has a site been under Sentinel service?
Vulnerability History: What is the site’s history of opened and closed vulnerabilities?
Missing Authentication: Does the site have the necessary authentications?
Scan Frequency: What is the frequency with which a site is scanned, and what resources are allocated for scanning?
PCI Compliance: Is the site PCI Compliant?
Window of Exposure: What is the historical window of exposure for this site?
Site Complexity: How complex is this site?
Omitted Vulnerability Classes: What vulnerability classes are not currently being scanned for this site?
Service Duration reflects the length of time that a site has been under contract as of the date of evaluation. Service Duration is important: the longer we have had the slot under contract the more detail we have collected about it, and the more effective testing is. Service Duration for a slot is compared to the Service Duration across all slots and clients at the same service level (BE, SE, PE, etc.).
Vulnerability History consists of the number of vulnerabilities that are open compared to the number that have been closed as of the date of the evaluation. By including closed vulnerabilities as mitigating factors in this metric, we reward people who are closing vulnerabilities reliably. Closing vulnerabilities is a better indication of security than not having discovered vulnerabilities in the first place because it demonstrates an active security stance that involves seeking out and remediating vulnerabilities.
The longer a vulnerability is open, the more negatively it will affect the WSI; the more promptly a vulnerability is closed, the greater the reward is for closing it. Additionally, vulnerabilities are weighted based on how common they are and the threat and severity associated with the vulnerability.
Slots that need authentication and do not have properly configured login handlers are evaluated as being less secure because sections of that site are not being scanned. If the client has not indicated that login handlers are unnecessary, and the service level for the slot is PE or SE, it is assumed that login handlers are required. (BE slots are presumed not to need login handlers unless they are configured to require one.) The Missing Authentication measure assumes the worst, it defaults to the assumption that the site has a large number of open vulns, because there is no way for WhiteHat to confirm that they do not.
Scan frequency looks at the number of scans completed each week. The more regularly a site is scanned, the more likely vulnerabilities are to be detected before they can be exploited. When scans are performed frequently, even minor changes are reviewed in a timely way. Scan frequency also evaluates whether there are sufficient resources allocated to scanning to allow scans to complete reliably.
PCI compliance is a measure of the historical PCI compliance for a given slot as of the date of evaluation. PCI compliance is largely based on vulnerability category; however, it is also affected by threat and severity values. The service level for a site may limit the nature and type of vulnerabilities that can be detected on a site; a PE site that is non-compliant might be evaluated as being 'compliant' if it were evaluated at the BE service level. Therefore, values for slots with lower service levels will be adjusted to account for the vulnerabilities that may not be discovered at this level.
Window of Exposure
Window of Exposure is a measure of the number of days out of the last 30 days that the site was exposed to a particular vulnerability. Again, a weighting factor is used to adjust for the inconsistencies that may result from differing service levels, and the Window of Exposure is tracked over 180 days not just the number of days out of 30 count in order to monitor a pattern of behavior, rather than only the events of the past month.
Larger and more complicated sites have a larger surface vulnerable to attack and are therefore intrinsically less secure; Site Complexity uses the number of form elements and the number of POST/PUT requests on the site as a rough measure of the attack surface. The size of the site can be estimated based on the number of GET requests made during scanning.
Omitted Vulnerability Classes
Clients can disable the scanning for Predictable Resource Location vulnerabilities; therefore, the index corrects for this by including the effect that could be associated with those vulnerabilities. That is, since scanning for the vulnerability is disabled, the index treats the site as if it were in fact untrustworthy, estimating the number of predictable resource location vulnerabilities to be high.
Using the WhiteHat Security Index
Monitoring Your Security Status
The WSI can be used to monitor the security status of assets. Specifically, you can use the WSI to:
Identify areas of security risk
Provide guidance on what vulnerabilities to fix
Compare security status of sites in an organization
Determine how you are doing relative to global and industry verticals by comparing percentile ratings
Monitor trends in security status of assets and effectively manage application security program
Improving your WhiteHat Security Index Score
Your WSI report recommends a set of actions that site owners can take to improve asset security. This includes an ordered list of top vulnerabilities that need to be fixed to improve the score, along with configuration-related recommendations such as increasing scan frequency, providing a scan schedule, or providing missing credentials.
Prerequisites for a WhiteHat Security Index Score
There are a few prerequisites for the WSI score to be available.
The site must have had at least three completed scans. This allows the scanner to be fully trained on the site.
The site must have been being scanned over at least 30 days following the third completed scan, to provide sufficient history to allow the weighting factors to be calculated and to allow some of the model parameters to be primed.
WSI is available on PE, SE, and BE service levels only.