WhiteHat Security
Sentinel Service
User Guide
Version 3.0 September 2010
Contents
Preface... 4
Intended audience ...4
How to use this guide ...4
Administrators ...4 Security Operators...4 Developers...4 Viewers ...5 Need help?...5 Resources...5
WhiteHat Security Customer Support...5
Getting Started... 6
Task overview ...6
Logging in to Sentinel...7
Navigating in Sentinel ...8
Creating and managing site groups...10
Setting up and managing user accounts...11
User roles ... 11
Managing users... 12
Creating a new user ... 13
Modifying a user’s settings... 14
Deleting a user ... 14
Editing your Sentinel account settings ...15
Email preferences ... 15
Public Key ... 15
API Web Key ... 15
Managing Your Sites... 17
Interpreting site findings...19
Site Summary info boxes... 19
Hostnames and links... 19
Setting up your site credentials ...20
F5 Web Application Firewall (WAF) Credentials... 22
Adjusting a site's priority level, scan speed, and industry ...22
Managing Sentinel Scans... 24
WhiteHat Security IP Addresses...24
How long do scans take to complete? ...24
Scheduling scans...25
Editing a scan ... 27
Stopping a Scan ... 27
Exporting scan schedules ...27
Viewing recent scan activity...28
Viewing site vulnerabilities ...37
Retesting site vulnerabilities ...39
Generating Reports ... 40
Creating a new vulnerability report...41
Using the Sentinel Open XML API ... 44
Glossary ... 45
Sentinel interface terms ...45
Business logic vulnerabilities ...48
Technical vulnerabilities...52
F5 Web Application Firewall (WAF) terms ...57
Preface
Intended audience
This guide shows assigned Administrators, Security Operators, Developers, and Viewers how to use WhiteHat Sentinel to find and fix vulnerabilities on their website.
How to use this guide
Depending on your assigned role, this guide helps you: • Get in and around WhiteHat Sentinel
• Set up Sentinel user accounts
• Manage your sites and user site access • Schedule scans and manage scan credentials • Interpret scan reports
• Perform optional operations, such as managing your F5 WAF credentials and using the WhiteHat Sentinel open XML API
Administrators
If you are an assigned Administrator, you have full control of all of your Sentinel operations and this entire guide applies to your activities.
Security Operators
If you are a Security Operator, you may want to read:
• Getting Started: Logging in to Sentinel, Navigating Sentinel • Editing your Sentinel account settings
• Managing Your Sites • Managing Sentinel Scans
• Managing Your Site Vulnerabilities • Generating Reports
• Using the Sentinel Open XML API
Developers
If you’re a Developer, you may want to read:
• Getting Started: Logging in to Sentinel, Navigating Sentinel, Editing your Sentinel account settings
• Managing Your Site Vulnerabilities: Retesting site vulnerabilities • Generating Reports
Viewers
If you’re a Viewer, you may want to read:
• Getting Started: Logging in to Sentinel, Navigating Sentinel, Editing your Sentinel account settings
• Generating Reports
Need help?
ResourcesFor more help, you can:
• Look up terms in the Glossary at the end of this user guide.
• Log in to your Sentinel account and click the Resources tab for a complete glossary, FAQs, white papers, API integration instructions, and other information about web security.
• Click the info buttons on each web page for help on certain topics.
WhiteHat Security Customer Support
To contact WhiteHat Security Customer Support:
• Go to the WhiteHat Support Portal: https://whitehatsec.supportportal.com • Send us email at:
• Call 408-343-8340 from 6:00 AM – 7:00 PM Pacific Time, Monday through Friday (excluding holidays).
• WhiteHat Support Plus is available in three service levels – the Standard Support level is free, and you can upgrade to Silver Support or Gold Support according to your needs. To see what level is best for you, go to:
Getting Started
Ensure scanning success in 3 steps!
Who can do this? Administrator and Security Operator
You have received your confirmation email and created a password – you’re in! Right? Well, yes. But scanning doesn’t start until you tell it to and let us in. There are three important steps you absolutely must take to get scans running on your sites.
Be sure to:
Log in to the Sentinel Interface.
Configure your sites, including setting up credentials – to allow us to scan.
(Administrator only)
Set up a scan schedule for each site – to start and continue scanning.
Task overview
The basic steps for setting up and using WhiteHat Sentinel are:
1. Log in as a new user. This is initially done by the first assigned Administrator and by additional users as defined by their roles.
2. Manage your sites, including setting up credentials and site groups.
(Administrator)
3. Set up user accounts. (Administrator)
4. Schedule and start scans. (Administrator and Security Operator) 5. Review vulnerabilities. (All users)
6. Generate reports. (All users)
7. Integrate our open XML API into your ticketing system. (Optional – Administrators and Security Operators)
8. Manage F5 WAF credentials. (Optional – Administrators and Security Operators) Getting Started takes you through steps one through four.
Logging in to Sentinel
Who can do this? All users, after the initial Administrator logs in and sets up user accounts
(For browser requirements, from Resources, click the FAQ link.)
Here is how to log in to Sentinel when your organization subscribes and assigns you as the initial Administrator or the Administrator has assigned you a user role.
1. You receive an email from WhiteHat Security Support to establish access to your account.
2. Follow the link and instructions in the email. Your username is the email address the Administrator used in setting up your access.
Note: This link is valid for 48 hours from the time the email was sent.
3. To ensure username security, you receive a second email with a URL to establish your password.
4. Follow the link and. enter your password information. Note: Your username and password are case sensitive.
After set-up, here is how to log in: 1. Go to:
https://sentinel.whitehatsec.com
2. Enter your username and password. If you have problems logging in, check:
• Username and password. Both are case-sensitive in the Sentinel login screen.
• Spam filter settings. If you changed your password recently, make sure your spam filter settings in your email account do not filter out the
[email protected] address that sends the password confirmation email.
Navigating in Sentinel
Who can do this? All users
When you log in to Sentinel, you land on your Summary page. The options and menus on your page depend on your role. (For example, only Administrators see an Admin tab, and only Administrators and Security Operators see the scan schedule as a menu.)
Click a tab to take you to:
• Summary: An overview of your sites’ security.
• Findings: A list of all security problems Sentinel found in your sites. • Schedule: A list of all scheduled events (such as scans).
• Reports: A place to input criteria for vulnerability reports.
• Account: Your Sentinel account information, including email options. • Admin: Editable user details such as roles and site accessibility. (Only
Administrators can see this tab.)
• Resources: An API Reference, white papers, a glossary, and other help and industry references.
The Pending Messages link, located next to the subject tabs and also under the Admin tab, takes you to the Account Messages page. Here you’ll find info about the latest on releases and other general messages from WhiteHat Security, along with any alerts you may have about the status of your scans.
Creating and managing site groups
Who can do this? Administrators
You can create site groups and manage user roles according to your organization’s needs.
Note: The Rename Group and Delete Group buttons appear when you select a group name. 1. Click the Admin tab.
2. Click Site Management.
Grouping Sites
3. Below Site Groups, click Add New Group. A new entry is added to the Site Group list.
4. Name the site group.
5. Drag and drop sites from the All Sites list to the new group. The added sites appear below the group name.
After you create a group name, you can:
• Add or remove sites to or from a site group: Drag the site name to or from the site group.
• Rename a site group: Select the group name and click Rename Group. • Delete a site group: Select the group name and click Delete.
Note: If an administrator deletes a site group, users no longer have access to that site group.
Setting up and managing user accounts
Who can do this? Administrators
User roles
The Administrator defines user roles with corresponding site access and privileges, as described below: • Administrator (Admin) • Security Operator • Developer • Viewer User Privileges Task Admin Security
Operator Developer Viewer Manage users X
Manage roles X Create site groups X
Schedule/start scan X X Configure scan X X Retest vulnerabilities X X X Generate reports X X X X Schedule reports X X X X View vulnerabilities X X X X Set up F5 WAF credentials X X
Set up open API XML X X
Each service subscription can include multiple administrators. The highest privilege level within Sentinel is an administrator with ‘All Sites’ access. Administrators who do not have access to all sites are limited to creating site groups and granting site access to sites that they administer. When your organization subscribes to Sentinel, WhiteHat Security creates an administrator with access to all sites, and that administrator can give all-site permissions to other administrators. Depending on your Sentinel set-up and
Each user can have only one role and corresponding privileges to one or more sites. For example, if you are an Administrator, you have admin privileges for all sites you access; if you are a Viewer, you have Viewer privileges for all sites you access, and so on.
Managing users
You can add, edit, and remove the following user information from Admin > User
Management.
• User email (used as the username and is case sensitive) • Title
• Phone number • Cell phone number • Time zone
• Country
• Vulnerability summary email options • Role (defines privilege level)
Creating a new user
To create a new user: 1. Click the Admin tab.
Creating a New User
2. In the User List, click New.
3. In Add New User, enter the new user’s information, including the role and site(s) the user can access under that role.
• The user’s email address must be unique. Once set up, an account email address cannot be edited or reused. However, if the account is deleted, it can be reactivated by having the account main point of contact call WhiteHat Security Support.
• Select All, None, or one or more site name. To select more than one site: On a PC, press the Control key and select the site names. On a Mac, press the Command key and select the site names.
4. Click Create User.
Modifying a user’s settings
You can modify any settings other than the user’s email address: 1. Click the Admin tab.
2. In the User List, click the username. 3. In User Details, enter the new information. 4. Click Save.
Since the user’s email address is used as their username, to change the email address, you need to delete the account and create a new one with the correct email address:
1. Click the Admin tab.
2. In the User List, click the username. 3. Click Delete.
4. Follow the instructions for creating a new user, including re-establishing their roles and sites.
Deleting a user
Once deleted, a user cannot access Sentinel. If the user tries to log in and clicks the
Forgot Username or Password? link on the log in screen, they are granted access to a
WhiteHat Security demo account with no displayed websites. The administrator must create an account with a new email address or contact White Hat Security Support to re-establish the previous account.
To delete a user:
1. Log in to your Sentinel account. 2. Click the Admin tab.
3. In the User List, click the username. 4. Click Delete.
Editing your Sentinel account settings
Who can do this? All users
From the Account tab, you can modify your account information, including: • Contact information
• Time zone
• Email preferences • Password
• Public key (Administrators and Security Operators only)
• Open XML API web key (Administrators and Security Operators only) To edit your account settings:
1. Log in to your Sentinel account. 2. Click the Account tab.
3. Modify your account information and click Save.
• If you’re generating a Web API key, click Save and Generate Web API Key. • You can use session cookies as an alternative to using a Web API key. For
details, go to Resources > API Reference > API Cookie Authentication or go here:
https://sentinel.whitehatsec.com/help/api.html#whid_cookie Email preferences
In the Email Preferences field, choose how often you want to receive status email summaries.
• Select Daily to receive email summaries every day, including weekends. • Select Weekly to receive email summaries once a week.
• Select Monthly to receive email summaries once a month.
• Select whether to include your host names in your e-mail summaries. (Deselect this option for added security.)
Public Key
In the Public Key field, you can create or edit a key that allows you to send a scheduled report via encrypted email. If your mail server uses PGP (Pretty Good Privacy) keys to send secure data across unsecured networks, click Edit Key to paste or edit your PGP key.
API Web Key
Who can do this? Administrators and Security Operators
If you are integrating the open XML API into your system, you need a Web API key to authenticate your API requests. Your key is generated automatically when you go to
Account and click Save and Generate Web API Key.
Never share your Web API key with anyone. This key could allow others to access your vulnerability information. Our support team will never ask for your Web API key.
You can also validate API requests by presenting a valid authentication cookie in your API requests. Upon a successful login, the browser returns a cookie named ‘APID’. The APID cookie expires at the end of a session (upon logout).
Managing Your Sites
Who can do this? Administrators
Before scheduling your first vulnerability scan, review your account site information. Additional information may be required before Sentinel can scan your sites, such as a set of credentials to gain access to secure sites.
You can set the scan schedule and time zone for all sites from Summary > Executive
Summary > Site Overview.
For individual site information and activity, from the Summary page, click the site name. This brings you to the Site Summary page, where you can view and adjust the site’s summary, including site credentials, vulnerability findings, and site-specific activities.
Interpreting site findings
Site Summary info boxesThe boxes at the top of each site’s summary page give you a quick overview of your site’s completed scan number, priority, global rank, and industry rank.
Scans completed in last 30 days: The number of scans that have finished in the
preceding 30 days.
Priority: The site’s importance to your business, on a scale of 1 to 10. A change in
priority affects the score of all vulnerabilities found on this site.
Global rank: Indicates your site’s approximate percentile rank against all sites that have
been scanned at least twice. The percentage represents the percentage of sites that contain more vulnerabilities than your site. For example, if your site’s global ranking is 20%, then 80% of all WhiteHat-scanned sites are more secure. Sites that have not yet been globally ranked are labeled ‘Unranked.’
Industry rank: Indicates your site’s approximate rank against all sites within your
vertical market that have been scanned at least twice.
Note: This box appears only if WhiteHat Security has scanned at least 10 sites in your industry more than once.
To change the priority, scan speed, or industry rank:
1. From the Site Summary page, click the Settings link. 2. Adjust the settings.
3. Click Update.
Hostnames and links
The hostname is the base URL that we have under contract for a site. The scanner finds and tests only links that have the same base URL. This keeps scanning for your account to approved sites. For example, if a site has a hostname of ‘www.site.com,’ only links that follow the ‘www.site.com’ structure are tested. (For example: ‘www.site.com/login,’ ‘www.site.com/contact,’ and so on.)
A site may also have one or more associated hostnames. An associated hostname is a URL that is different from the base URL, but is part of or the same as the application found on the main hostname. For example, a site may have sign-on and user account management pages on a URL such as ‘secure.site.com,’ when the main hostname we have for the account is simply ‘www.site.com.’ In this case, ‘secure.site.com’ must be added as an associated hostname since it is considered to be part of the same account. To create an associated host name, contact WhiteHat Security Support.
As your website continues to add features and functions, when you create links from the original site, the scanner finds them and marks them for testing during the next
scheduled scan. All findings from this testing are reported in the next scan. For this and other reasons, we strongly recommend that you set scan schedules to run frequently and until completion. This ensures ongoing site coverage as you add new web code.
Setting up your site credentials
WhiteHat Security uses credential sets to log in to your sites and reach pages and forms that are not accessible to unauthenticated end users.
Credential sets include: • Username • Password
• Login Entrance URL
• Destination URL (after a successful login)
• Other Login Notes (information about this site or users that WhiteHat Threat Research Center (TRC) engineers will need when setting up scanning or doing business logic testing)
There are two uses for the credential sets:
Scanning Credentials (all users). WhiteHat's automated scanning technology covers
pages and forms throughout the site. Scans are limited to only one credential, so we encourage you to provide a ‘super user’ login that allows us to visit the entire site.
Business Logic Credentials (Sentinel PE users only). WhiteHat’s Threat Research
Center (TRC) engineers use these credentials to manually verify vulnerabilities, examine interactions among user roles, and see if website information leaks from one user to another. For instance, your site may behave differently for admin users, returning customers, prospects, or high-value shoppers. Labeling each credential pair (‘admin,’ ‘gold-card-customer,’ and such) helps our TRC engineers match credentials to business situations.
The number of credentials you enter and how they are used depends on whether you have a Sentinel BE, SE, or PE account. Credentials should allow maximum access (such as admin or super user) to the site functions. Credentials are optional, but provide better scan coverage than having no credential. We strongly recommend assigning credentials.
• Sentinel Basic Edition (BE) account users enter one credential. This is used for automated scanning.
• Sentinel Standard Edition (SE) account users can enter one or two credentials, both used for automated scanning. The second credential is recommended as back up in case the first credential isn’t accepted during scanning.
• Sentinel Premium Edition (PE) account users can enter one or more credentials. The first is used for automated scanning; the second is recommended as back up in case the first credential isn’t accepted. Subsequent credential sets are used by WhiteHat’s TRC engineers to perform Business Logic analysis.
Entering Credentials
4. Enter a Username and Password.
5. In the Login Entrance URL field, enter the URL where the scanner will enter these credentials.
6. In the Destination URL field, enter the URL that displays after a successful login, if applicable. (Not all websites change the URL as part of their
authentication methodology.)
7. (Optional) In the Other Login Notes field, enter information to distinguish this account from others that have varying levels of access to the web application. (Examples: “You need to have cookies turned on” or “Site asks for your pet’s name. Answer: Lassie.”)
8. Click Done, or click Add a Credential if you have more than one credential for the scanner to use.
• You can now enter the second half of the pair, with a different username and password but similar permissions.
• PE users can also assign roles and credential pairs for Business Logic testing.
Site Credentials (Example)
After you have set up credentials, the Credential page includes the following state information:
• ‘Valid’ means we have confirmed that these credentials work.
• ‘Under Review’ means we have not yet tested these credentials or put them to work in automated scans.
• ‘Invalid’ means we have had trouble logging into your site, or otherwise cannot get the login to work.
• The last user to change/edit information, and when changes were made.
F5 Web Application Firewall (WAF) Credentials
Who can do this? Administrator, Security Operator
WhiteHat Sentinel integrates with the F5 Application Security Manager (ASM), a web application firewall that applies a security policy to protect against website attacks. Sentinel users can update their F5 ASM security policy on a per-vulnerability basis from within the Sentinel interface, which mitigates the risk of website exploitation while the vulnerability is addressed with an application code or system update.
To add or modify F5 WAF credentials, go to Account > Manage F5 Credentials link. • To add a new F5 ASM device and proper credentials, click the New
credential link.
• To modify credentials, from the Actions column, click Edit.
Adjusting a site's priority level, scan speed, and industry
You can specify your site’s priority level, scanning frequency, and the industry to which your site belongs.
3. Click the Settings link.
4. In the Priority field, select a level from 1 (Low) to 10 (Urgent). Level 5 is the default for all sites added to Sentinel.
Note: Changing this number also affects the Score of all individual vulnerabilities discovered on this site.
5. In the Scan Speed field, select whether you want the scanner to send: • Slow: Up to two HTTP requests per second
• Medium: Up to four requests per second (default) • Fast: Unlimited requests per second
6. In the Industry field, select the closest match to your site's vertical market. 7. Click Update.
Managing Sentinel Scans
Who can do this? Administrators and Security Operators
WhiteHat Security IP Addresses
To enable us to scan your website, your security team may need our IP addresses: • 209.10.217.224/27: This is a range of 30 addresses for Sentinel Service PE
testing, disaster recovery ranges, and so on.
• 63.251.227.208/30: This is a range of two addresses. These IP ranges are used for backup/disaster recovery:
• 64.94.92.240/28: This is a range of 14 addresses. • 67.207.113.224/28: This is a range of 14 addresses.
How long do scans take to complete?
WhiteHat Sentinel scans run "low and slow," meaning they should have no discernible effect on your website's performance. WhiteHat Security scans some of the most complex and mission critical websites in the world without causing performance issues. Scan time depends on various factors, such as:
• Size and complexity of the website • Input number
• The number of pages to assess • Web server speed (page load time)
• Amount of business logic within the website • Length of scan windows provided by the customer
Initial scans for the average WhiteHat-monitored site may take a day or less, but very large sites may take as long as a few weeks to complete.
Note: Sentinel SE and PE users, keep in mind that findings appear in your interface after they have been verified by a TRC engineer.
Scheduling scans
For your first few scans, we recommend scheduling your scans to run during non-peak hours and continuously during the weekend.
Once you have confirmed that there is no impact by scans during those time periods, we recommend running scans continuously, which means 24 hours a day, with a fresh scan starting as soon as the current one completes.
Schedules take effect right away. If your schedule allows scanning in the current hour, it will start (or continue). It can take up to 10 minutes for scans to stop or start. You will see the current scan status (after you refresh your browser window) as it changes. If you turn off scanning in the current hour, it will start again the next time an allowable hour arrives. There are no options for fractional hour scheduling or setting scans to start on a future calendar date.
For simplicity, we have included primary global time zones, but not every unique combination of time zone/savings time. Contact [email protected] to log an enhancement request for additional time zones.
To schedule a scan:
1. Go to one of the following areas: • Summary > Executive Summary
• Summary > Executive Summary > Site Overview <site name> • Schedule
2. For the selected site, in the Scan Schedule column, select a schedule.
• Continuous: Enables scanning at all times. This is the recommended option. • Nights and Weekends, 8P-6A: Enables scanning between 8:00 PM and
6:00 AM during weekdays and continuously during weekends. Be sure you select a corresponding time zone to determine exactly when 8:00 PM is in that geography. The time zone option defaults to the time zone you picked for yourself on the Account tab, but can also be set for each site from the Time Zone column to the right of the Scan Schedule column.
• Not Scheduled/Stopped: When you first set up your sites, they are set to ‘Not scheduled/Stopped.’ Be sure to schedule regular scans for each site, so WhiteHat Sentinel can continue to monitor for any threats.
• Customize: You can create your own custom scan schedule, as follows. When you select Customize, you can either create a schedule (recommended) or run the scan once.
Schedule scanning time
A grid shows all of the hours in a week. The rows represent days (starting with Sunday) and the columns represent hours (starting with 0:00 - 0:59, or Midnight to 1:00 AM).
Customizing Scan Times
By default, all hours show a green check mark, specifying that scanning is permitted
during that hour. If you leave all cells with green check marks, this is the same as a
continuous scan.
You can click individual cells, changing them to red X's. Red X's signify that scanning is
not permitted during that hour.
To change multiple cells, you can:
• Click and drag your mouse around the interface.
• Click a row or column header to change an entire row/column.
• Click a second time to toggle between green check marks and red X’s. The time zone selected should match where your system is or the clock to which your hours refer. The default is the time you chose in your user profile on the Account page. For example:
You work in New York and the time zone under the Account tab is set for Americas/New York. Your web server is in Americas/Los Angles.
If you leave the setting defaulted to New York, the scan will run/not run in Eastern Standard Time. If you change it to Los Angeles, the scan will run/not
Once you create a schedule, it appears on the list as long as one or more sites are using it. Custom schedules created for one site can be re-used for additional sites.
Editing a scan
To edit an established scan:
1. From the Scan Schedule list, select Customize. 2. Edit the schedule as necessary.
3. Save the schedule under the previous name or give it a new name.
Scanning only once
Note: We recommend against scanning once without an ongoing schedule, since this leaves your site unprotected after that single scan completes.
When you select this option, all hourly/daily scheduling windows are disabled. The scan starts immediately and runs continuously until it completes, for one time only.
To run one scan, from Scan Schedule > Customize, click Run scan once
continuously until completion. Stopping a Scan
To disable all scanning for a site, or stop a running scan, select Not scheduled/
Stopped. You cannot pause and restart a scan while it is running. A status of Not
scheduled/Stopped leaves your site unprotected, so we do not recommend leaving sites in this state. You may get frequent reminders that this site needs a new scan schedule.
Exporting scan schedules
For a comma-separated values (CSV) file with schedule information for all of your sites: 1. Click the Schedule or Summary tab.
2. Below the Site Overview, click the Download CSVlink.
Download CSV Link
By default, the file is named ‘scheduled_scans.csv’. This file may show more than one row for each site, since it lists each contiguous block of hours that the scan will run. For instance, each nightly scan window may have its own entry.
Viewing recent scan activity
As described below, you can view the following scan activity details for all of your sites or each site individually:
• ‘Vulnerability scan started’ indicates a newly scheduled scan cycle has begun.
• ‘Vulnerability scan completed’ indicates the total scan cycle has finished. • ‘Vulnerability scan paused, end of scan period reached’ appears only for
scans that run during limited hours, and indicates the scheduled time duration has reached its limit for the day. For instance, a scan scheduled to run from midnight to 6 a.m. pauses at 6 a.m. It automatically resumes during the next window of time in your scan schedule (such as midnight in the above
example).
• ‘Vulnerability scan paused by WhiteHat Security’ means that the WhiteHat Security TRC team paused the scheduled scan.
• ‘Vulnerability scan resuming’ is also used for limited-hour scans, and indicates the scheduled time in which the paused scan picked up where it left off.
All sites
WhiteHat Sentinel tracks all activities and events related to your account. To view a list of activities for all sites on your account in the last 90 days:
1. Click the Summary tab.
2. Click the Recent Activities link.
3. View your list of activities, listed by date. For a full archive, click the see
complete history link. Individual sites
To view activities for individual sites:
1. From the Summary page, click the name of the site. 2. From the Site Summary page, either:
• Click the Activities link. You see the site's scan activity over the past 90 days. To view all activity, click see complete history.
• Scroll to the bottom of the page to view the site's 10 most recent activities. To view the 90-day history, click the show all . . . see complete history link. From there, to view the complete archive, click see complete history.
Tested URLs and additional hostnames Sentinel discovered
1. Go to Summary > [site name].
2. On the site summary page, in the box next to the last chart (the site name is at the top of the list), scroll down to the Link Info section.
3. To see if a particular part of your site has been tested, click View all links found
in your current scan or View all pages tested in your current scan. If the
section of the site you are concerned with appears in any of these URL lists, it has been tested.
Scan status indicators
Sometimes issues come up that can prevent WhiteHat Security from effectively accessing and scanning a site, and may require action by you to resolve.
For each of your site(s), the Summary and Site Summary pages indicate scan status to let you know if scans are running and if you need to take action. Problems are reported by priority, with more urgent/important items showing above less urgent/important items.
• The Urgent icon indicates a condition that prevents successful scans, potentially preventing the site from being fully assessed. You need to address urgent items immediately.
• The Warning icon provides a warning or advance notice about an issue. If it requires action, address warning items at your earliest convenience.
• The OK icon indicates that scanning is working and you do not need to take action.
In Summary > Site Overview, scan status is displayed in the last column.
Scan Status on the Summary Page
If there is more than one alert for a site, only the highest priority item is shown. If the site has more than one issue, clearing the highest priority item may reveal another issue. (To see all of them at once, click the site name to go to the Site Summary page.)
To address the issue, click the status description next to the icon. This takes you to a page that describes the issue and how to address it.
Some corrective actions can only be performed by specific Sentinel user roles. If you do not have the corresponding role, only the required action is displayed. Contact a Sentinel Administrator to provide you with the appropriate role or for completion of the requested action.
The Site Summary page shows a list of all scan status alerts for that site. If, for instance, there are three scan status issues, all three are shown, with links to relevant details.
The following table lists all current possible status indicators. Scan status indicators may change over time. Contact [email protected] if you need information about a scan status indicator.
Scan Status Indicators
Icon Status
Description
Situation/Problem Action Required
Site Disabled WhiteHat has stopped all scanning as specified by your account Administrator.
Urgent: If you have not requested
that this site be disabled, contact [email protected] and request that scans be resumed.
Need Credentials
You need to provide one set of credentials for a BE account and at least one and preferably two for SE and PE accounts.*
Urgent: Click the Need
Credentials label and enter the
credential information.
Invalid Credentials
The site has an SE or PE service level, and none of the provided credentials are working.**
Urgent: Click the Need Credentials label and ensure
that the credential input is correct.
Need Scan Schedule
This site has no scans scheduled.
Urgent: In the Scan Schedule
column, pull down the menu and select a schedule. Contract
Expired
The service contract for this site has expired, and is not set for auto-renewal. Service may be terminated at any time.
Urgent: Contact Customer
Support to renew your contract and/or arrange for
auto-renewal. BE Link Limit
Exceeded
The BE service has an upper limit on the number of pages and links it covers. This site needs more coverage than BE provides.
Warning: Talk with Customer
Support about upgrading to SE or PE so that the entire site can be protected.
Contract Expiring in X Days
The service contract for this site is expiring soon, and is not set for auto-renewal.
Warning: Contact Customer
Support to extend the contract. Configuration
in Progress
Our TRC engineers are setting up login handlers, configuring scans, or otherwise changing scan details.
Warning: Wait for TRC to
complete its tasks. Contact Customer Support for additional information.
Reviewing Credentials
TRC is verifying that credentials work.
OK: No action required.
Scan Running
This site is currently being scanned.
OK: No action required.
Paused Per Schedule
This site's schedule identifies the current hour/day as outside the selected scanning period.
Icon Status Description
Situation/Problem Action Required
on the schedule. Scan
Scheduled
This site has a scan
scheduled for a future time.
OK: No action required.
Scanning (no credentials)
The Administrator has set this site to be scanned without any credentials, or unauthenticated. Only external pages/forms will be tested.*
OK: No action required unless
you want to re-enable
authenticated scans. If so, click
Scanning (no credentials),
deselect Do not need
credentials, and enter valid
credentials.
*Selecting Do not need credentials disables all scan status warnings about missing credentials, while scans run unauthenticated (without credentials). We strongly
discourage enabling unauthenticated scans, since that may leave sites unprotected from attacks on internal forms and pages.
**A site with many credentials may have some marked as ‘Invalid’ or ‘Not working’. You may receive alerts or action items elsewhere in Sentinel and in support emails to request that you fix these credentials. You only see an Urgent status if every credential for that site is invalid.
Here is an example of time/event activities as reported by scan status alerts.
Sample Time/Event Sequence Reported by Scan Status Alerts
Time/Event Icon Status Description Current Action
1 Scan Running This site is currently being scanned. 2 Configuration in
Progress
While the scan was running, it notified TRC of needed configurations. TRC is making these changes,
3 Scan Running Configuration completed. This site is currently being scanned.
4 Paused Per
Schedule
This site's schedule identifies the current hour/day is outside the selected
scanning period. Scanning will resume based on the schedule.
5 Scan Running This site came out of the blackout period and resumed being scanned.
6 Need Scan
Schedule
The scan from Time/Event 5 above was a one-time scan and has finished. There is no scan scheduled after that.
7 Scan Scheduled A reoccurring scan schedule was provided and it is waiting for the next scan time slot to occur.
8 Invalid Credentials The scheduled scan started and the scanner found the provided site credentials have changes and are no longer allowing login.
9 Reviewing
Credentials
The customer has updated the site credentials and TRC is verifying that credentials work.
10 Scan Running Credentials were validated and the site
is currently being scanned.
11 Scan Scheduled Due to the action in Time/Event 7 the scanner has finished the scan and is waiting for the next scan time slot to occur to start a new scan.
Scan status alerts and action items
If you need to take action on a scan issue, you may see this along with other tasks in
Pending Messages > Action Items.
• Some Urgent scan status issues do not generate action items. For
instance, sites with no credentials will show an Urgent alert labeled ‘Need Credentials,’ even though no action items have been generated.
• Also, some action items are not reflected in scan status. For instance, if a site has many credentials, some ‘Valid’ and others ‘Invalid,’ this does not force an Urgent alert, since scans are still running based on valid credentials.
Action items are still created, requesting that you update/replace those credentials that are not working.
If a site has not been scanned
If you see that a site has not been scanned in a while:
• The site may have been scheduled for a one-time, immediate scan, which does not repeat.
• Click the Pending Messages link (next to the navigation tabs on each page) and scroll down to Action Items for actions that must be taken for a scan to run, such as credentials that need updating or a scan with no schedule.
Managing Your Site Vulnerabilities
As Sentinel identifies vulnerabilities, it classifies them according to the 24 Web Application Security Consortium (WASC) vulnerability classes such as Cross-Site Scripting, Directory Traversal, and SQL Injection.
Each class is assigned a Threat and Severity level, represented by info boxes at various data sections of the Sentinel interface.
For Sentinel SE and Sentinel PE accounts, Threat Research Center (TRC) engineers verify all vulnerabilities before they reach your Sentinel interface, which ensures that you do not see false positives.
Note: Vulnerability verification is performed during normal business hours in Pacific Standard Time (PST). So it is possible to run a scan at night and not see vulnerabilities reported until the next business day during PST.
What vulnerabilities does Sentinel scan for?
Sentinel scans for vulnerabilities based on your subscription level. (See the Glossary for vulnerability definitions.)
All subscriptions levels scan for the following vulnerabilities.
Command Execution
• Buffer Overflow • Format String Attack • LDAP Injection • OS Commanding • SQL Injection • SSI Injection • XPath Injection Information Disclosure • Directory Indexing • Information Leakage • Path Traversal
• Predictable Resource Location
Client-Side
• Content Spoofing
• Cross-site Scripting (XSS) • HTTP Response Splitting
Sentinel PE also scans for the following business logic flaws: Authentication • Brute Force • Insufficient Authentication • Weak Password • Recovery Validation
• Cross-Site Request Forgery
Authorization
• Credential/Session Prediction • Insufficient Authorization • Insufficient Session Expiration • Session Fixation
Logical Attacks
• Abuse of Functionality • Denial of Service
• Insufficient Anti-automation • Insufficient Process Validation
Viewing site vulnerabilities
Who can do this? All users
To view all of your site vulnerabilities at once, click the Findings tab. The Findingspage contains a list of vulnerabilities and their details. Alternatively:
• To see the most recently identified vulnerabilities for all your sites, go to
Summary > Executive Summary > Vulnerability Overview > Recently Identified Vulnerabilities.
• To see the most recently identified vulnerabilities for a specific site, go to
Summary > Executive Summary > Site Overview > [site name] > Scan Statistics > Recently Identified Vulnerabilities.
Click the icon in the Details column to see the Vulnerability Viewerpage.
Vulnerability Viewer
The Vulnerability Viewer includes the following information:
• The vulnerability as defined by the WASC class (example: Cross-Site Scripting).
• The vulnerability’s Severity, Threat, Priority, and Score.
• A retest button enabling you to run a retest or request a manual retest (based on the nature of the vulnerability).
• A link to ask a question about this vulnerability. (Questions are generally answered within 24 hours.)
• The VulnID (the unique number assigned to the vulnerability). • The vulnerability URI (in the Located in field).
• The Site name.
• The date and time it was opened (identified), and the duration it has been open.
• The current status (open or closed).
• A list of open and closed attack vectors according to the parameter sent in the HTTP request. (Click the Details icon for the complete record of the
Retesting site vulnerabilities
Who can do this? Administrators, Security Operators, and Developers
To retest a vulnerability, follow these steps from the Vulnerability Viewer page. Below the info boxes, click the retest button. Depending on the vulnerability, it will be labeled in one of two ways:
• Request Manual Retest means that only manual retesting can be performed on this specific vulnerability. Click this button to send a request to the TRC team. The status of the vulnerability changes to ‘Manual Retest Pending’ until the retest is finished.
• Retest Now means that the vulnerability is eligible for automatic retest. The retest begins immediately.
To retest more than one vulnerability, follow these steps from the Findings tab: 1. In the Retest column, select the vulnerabilities to retest.
Generating Reports
Who can do this? All users
You can create customized vulnerability reports for one or more of your sites in HTML or PDF (and schedule the PDF to be emailed periodically).
Sentinel reports include levels of information based on report type. (The HTML web report is available only as a Vulnerabilities Details Report.)
• The Executive Summary Report provides executive management with an illustrated overview of the security risk profile of their organization's sites. It contains a summary of vulnerability totals across multiple sites broken up by risk levels and vulnerability categories.
• The Site Summary Report provides management with a comprehensive, illustrated view of the specific security risk exposure of individual sites under their responsibility. It has an overview of each site's vulnerabilities by
category, the trends of vulnerabilities discovered by month over the past year, and each site's vulnerability findings prioritized by their risk and severity level, and the priority level of the site.
You can filter this report by site.
• The Vulnerability Detail Report provides security team members and development managers with a detailed listing of the vulnerabilities found on their organization's websites. It groups the findings by category for each website selected for the report. Each chapter contains a description of the vulnerability class with remediation instructions, followed by a list of specific instances of the vulnerability on each site.
You can filter this report by site, class, date range, and current state. You can add an Attack Vector list to each vulnerability detail.
• The Attack Vector Detail Report provides security team members and developers with a detailed list of all instances of vulnerabilities found on their organization's sites. It details every vulnerability instance found on selected sites.
You can filter this report by site, class, date range, and current state. You can add a response body to each vulnerability detail so that
your developers can easily replicate the problem.
• The PCI Report measures a website's compliance with the Payment Card Industry's Data Security Standard (PCI-DSS). The PCI standard ensures that sites are built to the secure coding guidelines of the OWASP Top Ten
Vulnerability Classes and are routinely checked for vulnerabilities. You can filter this report by site.
Creating a new vulnerability report
To create a vulnerability report: 1. Click the Reports tab.
2. Click either PDF Reports or Web Reports.
The Web Report form creates a Vulnerability Detail report. The PDF Reports page offers all report formats.
3. For PDF, from the Options field, select the report type. 4. Select the site(s) you want to see, or select All Sites.
• To select site names in the list: On a PC, press Shift and click the site names; on a Mac, press Command and the click the site names.
The rest of your options depend on the report type and your account level. Some of the options include:
• Vulnerability Class. You can select one or more Vulnerability Class, or select All Classes. (See ‘Typesof site vulnerability scans’ to see which scans are covered for your account level and the Glossary for report type definitions.)
• Start and End dates. The start date should be early enough to include the actual discovery date of the vulnerability (vulnerabilities discovered prior to that date range are not included in the report).
• By default, reports are set to include only vulnerabilities opened in the last seven days. To report a full list of vulnerabilities, open a new browser tab, log in to Sentinel, and click Findings > Opened Date. In the report form, click
Filter by Date and enter a date that is equal to or one day before the oldest
date.
• To find your oldest closed vulnerabilities, in the separate browser tab, go to
Findings > Closed Date. In the report form, click Filter by Date and enter a
date that is equal to or one day before the oldest date.
• Open/closed/both. Choose whether to report vulnerabilities that are still open, closed, or both. We recommend choosing both to indicate progress in remediating vulnerabilities over a period of time.
• Delivery options. Choose how this report should be delivered.
• If you are in the Web Reports view, you will automatically receive an HTML view of the report when you click Generate Report.
• If you are in the PDF Reports view, select Show report immediately or
Schedule a delivery time. You will need a public key (PGP) to enable
Sentinel to periodically e-mail a PDF report. If you have not done so, go to the Account tab and generate a public key.
Using the Sentinel Open XML API
Who can do this? Administrators and Security Operators
The Sentinel open XML API is a set of functions that support HTTP requests, allowing your developers to work directly with your own Sentinel vulnerability data. Vulnerability, site, and schedule information, retrieved in XML format, can be integrated into your developer defect tracking systems or security informationmanagement systems (SIMS).
For instructions on using the open XML API: 1. Click the Resources tab.
2. Click the API Reference link. Or, from outside Sentinel, go to:
https://sentinel.whitehatsec.com/help/api.html
and log in.
Glossary
Sentinel interface terms
Attack VectorA test consisting of HTTP requests and responses that indicate the presence of a vulnerability. Because injection-based attacks usually target specific parameter injection points, attack vectors for vulnerabilities such as Cross-Site Scripting (XSS) and SQL Injection are grouped by each vulnerable parameter.
All open attack vectors must be resolved in order to close a vulnerability. The same attack vectors will be re-sent during a retest. If the vulnerability can no longer be found, the attack vectors (and thus the vulnerability) will be closed. Should future scans reveal new or re-opened attack vectors, the closed vulnerability may be re-opened.
Global Rank
A percentile rank indicating your site's approximate rank against all sites that have been scanned at least twice. The percent shown in the box represents the percentage of sites that contain more vulnerabilities than your site. For example, if your Global Rank is 20%, then 80% of all scanned sites are more secure. Sites that have not yet been globally ranked are labeled ‘Unranked.’
Hostname
An identifying domain name assigned to a host computer, usually a combination of the host's local name with its parent domain's name.
Industry Rank
A percentile rank indicating your site's approximate rank against all sites within your vertical market that have been scanned at least twice.
Priority
On a scale of 1 to 10, a customer-determined level of value or importance of a site. Priority is initially set to the default level of 5, but can be modified from Site Summary >
Settings. A change in Priority additively affects the Score of all vulnerabilities found in
Severity
The potential business impact if a specific vulnerability is exploited. The levels of severity are based on the same conditions factored into the PCI Security Scan report ratings, but the definitions below are clarified for Web application security concerns.
Level 5 - Urgent
• Attacker can assume remote root or remote administrator roles
• Exposes entire host to attacker; backend database, personally identifiable records, credit card data
• Full read and Write access, remote execution of commands • Example Business Vulnerability: Insufficient Authorization
• Example Technical Vulnerability: Format String Attack, SQL Injection, Directory/Path Traversal
Level 4 - Critical
• Attacker can assume remote user only, not root or admin • Exposes internal IP addresses, source code
• Partial file-system access (full read access without full write access)
• Example Business Vulnerability: Insufficient Authentication, Session Fixation, Abuse of Functionality, Credential/Session Prediction, Insufficient
Authentication, Cross-Site Request Forgery (CSRF)
• Example Technical Vulnerability: Cross-Site Scripting (XSS), Server Side Include (SSI) Injection, OS Command Injection
Level 3 - High
• Exposes security settings, software distributions and versions, database names
• Example Business Vulnerability: Weak Password Recovery Validation, Denial of Service, Insufficient Process Validation, Brute Force
• Example Technical Vulnerability: Information Leakage, Content Spoofing, Predictable Resource Location, LDAP Injection, Directory Indexing, HTTP Response Splitting
Level 2 - Medium
• Exposes precise versions of applications
• Sensitive configuration information may be used to research potential attacks against host
• Example Business Vulnerability: Insufficient Session Expiration, Insufficient Anti-automation
• Example Technical Vulnerability: XPath Injection Level 1 - Low
Threat
A measure of feasibility in which a specific Vulnerability can be exploited. Criteria can include the skill level required of the attacker, the context of the attack surface, the transience of the vulnerable code, and the dependencies for access to the vulnerability. Threat level is one of the factors used to calculate the Score of a vulnerability. The higher the threat level, the greater the ease of exploitation for the vulnerability.
Threat levels of some vulnerability classes are subject to change on a case-by-case basis.
Level 5 - Urgent
• Very low time, resources, and skill levels are needed for execution • Easily exploitable
• Can be accidentally triggered by unsuspecting, non-technical user • Authentication may not be required
• Details of past exploits and demonstrations are widely available
• Extensive educational materials have been published about this vulnerability class
• Large, almost universal attack surface with many entry points Level 4 - Critical
• Little time and few resources are needed for execution • Some background knowledge may be required for execution • Remotely exploitable
• Authentication, if required by the Web application, is easily defeated • Details of past exploits somewhat available
Level 3 - High
• Tools to automate the attack are available, but require some background knowledge
• A moderate amount of time and resources are required
• Proofs-of-concept and a few real-world exploits have occurred, but details may not be known
Level 2 - Medium
• At least one proof-of-concept has been demonstrated, but there are no records of real world attacks
• Considerable technical skill is required
• Attack vector is moderately transient and conditional • Attack vector is moderately deep in the code
Level 1 - Low
• Attack method is obscure, brand-new, or strictly a theory
• Distributed systems knowledge (or insider status) required for execution • Origin of attack is typically local
• Authentication is required
• Attack vector is highly transient, conditional, and located deep in the code • Extremely narrow attack surface
Score
The sum total of the Threat and Severity levels of an identified vulnerability, plus the
Priority of the site. Scores range from 3 to 20.
• For example, a Cross-Site Scripting vulnerability with a Severity level of 5 and a Threat level of 5 on a Priority 10 site results in a Score of 20.
• Priority is initially set to the default level of 5. If you increase the Priority for a site that has been scanned, the Score for any vulnerability found on that site automatically updates.
• Threat and Severity levels have default levels that can be overridden by WhiteHat Security on a case-by-case basis. Each vulnerability's Score is indicated in the Vulnerability Summary and Findings pages.
Site Credentials
A username and password a customer provides in order for scanners to perform tests as a logged-in user. This feature is required if your site requires user accounts. We
recommend creating two accounts for each access level (two users, two administrators, and so on), pre-populated with example test data, to ensure a thorough scan.
In the Site Credentials page, you can enter the credentials of multiple accounts to represent different roles, such as users and administrators, to test various permission and access levels.
The Site Credentials page indicates whether existing credentials, if any, have been used for testing. In some cases, separate "sites" are created for each credential set. You can add, change, or delete the credentials for a given site by selecting the site in the
Executive Summary page, and then clicking the Site Credentials link.
Vulnerability
An instance of weakness in a Web application that can result in harm to the Web application, its operations, or its end users, especially when exploited by a malicious individual or script.
VulnID (Vulnerability Identification)
A unique identifier of a specific vulnerability in your account.
Business logic vulnerabilities
Abuse of FunctionalityAn attack that uses a website's own features and functionality to consume, defraud, or circumvent access control mechanisms. Some functions including security features may be abused to cause unexpected behavior, annoy other users, or perhaps defraud the system entirely.
that turns a web search function into a remote web proxy. Abuse of Functionality attacks are also commonly used as a force multiplier. For example, an attacker can inject a
Cross-Site Scripting snippet into a web-chat session, then use the built-in broadcast function to propagate the malicious code site-wide.
Brute Force
An automated process of trial and error used to guess a person's username, password, credit-card number or cryptographic key. Many systems will allow the use of weak
passwords or small cryptographic keys. An attacker can cycle though the dictionary word by word, generating thousands or potentially millions of incorrect guesses searching for the valid password.
There are two types of brute force attacks: normal brute force and reverse brute force. A normal brute force attack uses a single username against many passwords. A reverse brute force attack uses many usernames against one password. In systems with millions of user accounts, the odds of multiple users having the same password dramatically increases.
Insufficient Anti-automation
Insufficient Anti-automation can happen when a website permits an attacker to automate a process that should only be performed manually. Certain website functionalities should be protected against automated attacks.
Left unchecked, automated robots or attackers could repeatedly exercise website functionality attempting to exploit or defraud the system. An automated robot could potentially execute thousands of requests a minute, causing potential loss of performance or service.
Insufficient Authentication
Insufficient Authentication can happen if a website permits an attacker to access sensitive content or functionality without having to properly authenticate. Web-based administration tools are a good example of websites providing access to sensitive functionality. Depending on the specific online resource, these Web applications should not be directly accessible without the user required to properly verify their identity. To get around setting up authentication, some resources are protected by "hiding" the specific location and not linking the location into the main website or other public places. However, this approach is nothing more than ‘Security Through Obscurity.’ It is important to understand that simply because a resource is unknown to an attacker, it still remains accessible directly through a specific URL. The specific URL could be discovered through a Brute Force probing for common file and directory locations (/admin for
example), error messages, referrer logs, or perhaps documented in Help files. These resources, whether they are content or functionality driven, should be adequately protected.
Insufficient Authorization
A vulnerability that permits access to sensitive content or functionality that should have increased access restrictions.
website activity according to policy. Sensitive portions of a website may need to be restricted to everyone except to an administrator.
Insufficient Process Validation
A vulnerability that permits an attacker to bypass or circumvent the intended flow control of a Web application. If the user state through a process is not verified and enforced, the website could be vulnerable to exploitation or fraud.
When a user performs a certain website function, the Web application may expect the user to navigate through a specific order sequence. If the user performs certain steps incorrectly or out of order, a data integrity error occurs. Examples of multi-step
processes include wire transfer, password recovery, purchase checkout, account sign-up, and so on. These processes will likely require certain steps to be performed as expected.
For multi-step processes to function properly, websites are required to maintain user state as the user traverses the process flow. Websites will normally track a user’s state through the use of cookies or hidden HTML form fields. However, when tracking is stored on the client side within the Web browser, the integrity of the data must be verified, otherwise an attacker may circumvent the expected traffic flow by altering the current state.
Insufficient Session Expiration
A vulnerability that enables an attacker to reuse old session credentials or session IDs for authorization. Insufficient Session Expiration increases a website's exposure to attacks that steal or impersonate other users.
Since HTTP is a stateless protocol, websites commonly use session IDs to uniquely identify a user from request to request. Consequently, each session ID's confidentiality must be maintained in order to prevent multiple users from accessing the same account. A stolen session ID can be used to view another user's account or perform a fraudulent transaction.
Weak Password Recovery Validation
A vulnerability that permits an attacker to illegally obtain, change or recover another user's password. Conventional website authentication methods require users to select and remember a password or passphrase. The user should be the only person that knows the password and it must be remembered precisely. As time passes, a user's ability to remember a password fades. The matter is further complicated when the average user visits 20 sites requiring them to supply a password. Thus, Password Recovery is an important part in servicing online users.
Examples of automated password recovery processes include requiring the user to answer a "secret question" defined as part of the user registration process. This question can either be selected from a list of canned questions or supplied by the user. Another mechanism in use is having the user provide a "hint" during registration that will help the user remember his password. Other mechanisms require the user to provide several