Production Safety

If you prefer to read the entire WhiteHat Service Definition section in PDF format, you can view or print here.

WhiteHat Sentinel services have been designed from the very beginning to be extremely safe for production web applications. Our maxim at WhiteHat Security is "Do no harm" or, put more casually, we like to ask "Is this important?" before running a scan, rather than asking "Was that important?" afterward. By default, WhiteHat Sentinel operates "production-safe." This means that WhiteHat Sentinel only performs tests that will not permanently change the state of the system. So, you can be confident that we will safely scan your production business websites during business or high-traffic hours. To make sure we maintain little to no impact on your application, we’ll need you to let us know if any of the following exists on your application:

  • State-changing functionality performed via GET request

  • Areas of the application or specific functionality you’d like us to refrain from testing

Key Features

In addition, we have implemented three key features that are unique to WhiteHat Security that ensure that our testing remains completely safe for your production websites.

  1. Customized Configuration

    The WhiteHat Threat Research Center (TRC) manually reviews your web application and customizes Sentinel testing for safety and thoroughness. Every input, state changing request (POST request), or sensitive functionality is carefully analyzed by a human TRC engineer. Our engineers check this functionality first for safety, then for depth and coverage.

    This is especially applicable to administrative level functionality—things like create/delete users or groups. This kind of functionality is deemed unsafe to test in an automated fashion and Sentinel will be configured not to place these sensitive requests. Instead, a security engineer can check this functionality by hand in order to ensure little to no impact on the application. Examples of functionality that are commonly deemed unsafe:

    • Creation and deletion of users or data

    • Contact us features that involve sending email

    • Updating/Editing Profile or account data

    • Leaving comments or forum posts (Submit functionality)

      When an input or area of functionality is deemed safe for automated testing, a security engineer configures Sentinel to submit valid data in order to get further into the application.

      Customized Configuration Example: A website has a "create user" page that requires a valid address and email address in order to successfully complete. A security engineer recognizes that these inputs are required and trains Sentinel to submit valid information in order to get through this page. This action is repeated as long as the submitted request is deemed safe until the functionality is thoroughly covered. As part of the configuration process, TRC engineers also examine every link discovered by Sentinel to ensure overall coverage and to streamline the automated assessment for safe and efficient scanning.

  2. Non-Invasive Testing

    Many scanners bombard your site with hundreds or thousands of simultaneous requests, running the risk of negatively affecting or even bringing down the site being tested. Instead, WhiteHat Sentinel uses single-threaded requests during the automated portion of the web application assessment; much like a real user, Sentinel sends a request to your website and waits for a response before submitting the next request. In addition, by default Sentinel will place a maximum of four requests per second for a given set of credentials. (You can control this cap from the Sentinel interface.) This approach ensures that your production sites never receive an unexpected heavy load of requests coming from our scanner.

  3. WhiteHat Sentinel Will Not Execute Live Code

    By leveraging customized testing methodology unique to Sentinel in combination with our TRC’s vulnerability verification process, Sentinel is able to detect vulnerabilities safely without executing live code on your web application. You are guaranteed that Sentinel will never execute live code in an automated fashion on your website. This greatly reduces the chance of negatively impacting the application.

Tracking WhiteHat’s Assessment Activities

On top of these production safety measures, we also provide clients two easy methods of tracking all assessment activity:

  1. Custom Watermark All requests from WhiteHat Sentinel will contain a custom “WhiteHat Security” user agent header. This allows you to create filters to monitor our activity or to exclude certain alerts or warnings. If there is a specific watermark you would like us to use, just let us know, and we can customize the user agent header to include it.

    Sample watermark:

    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OSX 10.7; rv:13.0) Gecko/20100101Firefox/13.0.1WhiteHat Security

IP Address Whitelist All WhiteHat scans or manual work will come from one of our IP addresses or IP address ranges. Which IP addresses should you whitelist?

  • Non-EU Customers: If your company does not reside in the EU and you are not restricting access to US WhiteHat employees, whitelist all IPs within this column.

  • EU Customers: If your company resides in the EU, whitelist all IPs within this column.

    Non-EU Customers EU Customers

    • 52.204.38.40

    • 64.244.165.6

    • 104.45.216.22

    • 162.223.124.0/27

    • 162.244.4.2

    • 162.244.4.3

    • 162.244.4.5

    • 162.244.4.6

    • 162.244.5.2

    • 162.244.5.3

    • 162.244.5.5

    • 162.244.5.6

    • 54.93.186.146

    • 54.229.46.147

    • 148.253.176.50

    • 194.46.129.108

*US customers should remove this IP address range, as these IP addresses are deprecated.