WhiteHat Dynamic Onboarding
| If you prefer to read the entire WhiteHat Dynamic Onboarding section in PDF format, you can view or print here. |
Required Information
The following provides more detail to supplement the Site Onboarding Overview process diagram. For onboarding your dynamic analysis services, Synopsys needs to know the following information:
-
Web Application Hostname(s) and Associated Host Names
The application hostname establishes the boundaries of the WhiteHat Dynamic assessment. WhiteHat Dynamic will only assess content that is specified by the hostname.
Associated hostnames are those that are considered part of the same application where content is either accessible from a single login entry or without authentication. These hostnames can be added to the assessment scope under the same license, and will allow the assessment to encompass the entirety of the web application. For example:
-
Hostname: www.site.com
-
Associated hostnames: secure.site.com, www.contact.site.com
-
-
Requirements for Associated Hostnames
-
The current application and potential associated hostname should be similar in content and functionality.
-
There should be shared functionality between the current application and the potential associated hostname.
-
The content on the potential associated hostname goes with the content on the current application.
-
The associated hostname shares a session with the base domain.
-
The associated hostname cannot have a separate login function.
-
-
Credentials
Though credentials are not required for your application assessments to begin, they’re important to ensure we’re able to access and test all functionality, specifically for sites that contain authenticated content. Please provide two sets of credentials with access to most or all functionality. One account serves as the primary account for automated testing, while the second account serves as a backup in case the primary account becomes invalid. For PE licenses, two additional test accounts for each user level are needed for business logic testing. For Example:
-
Two administrator accounts
-
Two expert or special user accounts
-
Two standard user accounts
This allows us to perform both horizontal and vertical privilege testing across the various user roles of the application. For Example:
-
Can Imani see Dar’s account profile data?
-
Can a non-administrative user escalate their privileges to an administrative account?
-
Can Shashi rotate through user accounts and perform transactions as another user?
-
-
Assessment Schedule
The assessment schedule is the recurring weekly date and time range where WhiteHat Dynamic is allowed to actively test your application. WhiteHat Dynamic saves its progress between scheduled windows, so if a scan is unable to complete before the scan window concludes, it can pick up where it left off at the beginning of the next scan window. You can set your weekly schedule within the WhiteHat Portal interface, and there are several scheduling options available:
-
Continuous (highly recommended): Assessments run 24x7
-
Nights & Weekends (recommended): Weekdays from 8pm to 6am (based on the time zone you select), and 24 hours a day on weekends
-
Custom Schedule: You can choose to create a custom assessment schedule based on days of the week and hours of each day. If this option is chosen, please ensure at least 40 hours of scan time per week
-
-
IP Address Whitelist All WhiteHat Dynamic scans or manual work will come from one of our IP addresses or IP address ranges. Which IP addresses should you add to your allow list?
-
Non-EU Customers: If your company does not reside in the EU and you are not restricting access to US Synopsys employees, allowlist all IPs within this column.
-
EU Customers: If your company resides in the EU, allowlist all IPs within this column.
Non-EU Customers EU Customers -
104.45.216.22
-
162.223.124.0/27
-
3.72.175.49
-
3.76.244.88
-
18.194.206.33
-
54.93.186.146
-
54.229.46.147
-
148.253.176.50
-
194.46.129.108
-
-
Service Delivery Timeline and Setup
-
Initial URL Crawl (1-3 Weeks)
Once URLs and site credentials (if applicable) are received and a scan schedule has been entered, our TRC engineers create a customized login sequence that teaches WhiteHat Dynamic to assess authenticated portions of the web application. WhiteHat Dynamic will then begin crawling (also called "spidering") your application. Completion time for the initial crawl varies depending on the number and size of pages within the application. During the initial crawl, only GET requests are made.
-
Review of Site Coverage
After the initial URL crawl, TRC engineers will examine all links discovered by WhiteHat Dynamic. If there are pages known to exist that are missing from our scan coverage, an engineer will add them to our testing scope as entry points. Directories or files that are not directly accessible from a link connected to the web application are common examples of pages that may need to be added as entry points.
You can expedite this phase by reviewing the pages found and tested within the WhiteHat Portal and notifying us if sections of your application are missing.
-
Custom Test Configuration (PE and SE only) (1-10 Business Days/Ongoing)
As WhiteHat Dynamic crawls your application, it alerts our Threat Research Center (TRC) of any forms your application contains, so an engineer can make custom test configurations that both allow WhiteHat Dynamic to safely test each form and permit the WhiteHat Dynamic scan to spider pages that lay behind each form. We refer to this step as “form training.” If your application contains several layers of forms, it may take several passes by WhiteHat Dynamic and several rounds of form training to reach all application pages.
During this step, the TRC engineer may also enable URL rules for any template pages contained in your application. These rules instruct WhiteHat Dynamic to test a sample number of pages for each template used, which allows each WhiteHat Dynamic scan to complete more quickly while remaining thorough. As an example, an auction site that contains millions of products and is constantly adding additional products may use a common template. Instead of attempting to assess each individual product page, we will create a URL rule to assess only a subset of them. This reduces scan completion time without sacrificing quality.
Vulnerability Verification
Any time WhiteHat Dynamic finds a vulnerability, it flags the page and attack vector and sends a notification to the Threat Research Center. Using a combination of more than 17 years of data intelligence and human verification, the vulnerability is confirmed as true and actionable before it is posted. Vulnerabilities are grouped by the URL on which they are discovered, and then into the various vulnerability classes found within the Web Application Security Consortium V2 (WASC v2). The various methods to exploit discovered vulnerabilities are categorized by vulnerability parameters known as “attack vectors”.
Business Logic Assessment (5 Business Days/Ongoing)
If you’ve purchased PE Service, you may schedule your BLA for any point during your license period. In the BLA, our TRC engineers will assess your application for vulnerabilities in its business logic. This testing is done by hand and can be scheduled in the WhiteHat Portal, under the "Services" subtab for the specific site.
Initial Assessment Complete
The initial assessment is understood to be complete when the Vulnerability Verification phase detailed above is completed.
At this point, we recommend scheduling a Vulnerability Review call where our TRC engineers can discuss and explain vulnerabilities. This call includes a detailed breakdown of each vulnerability, as well as a live demonstration of the vulnerabilities discovered, and is a great opportunity to involve other members of your security and development teams.
We encourage you to request a Vulnerability Review any time during your subscription term.