Get Started with Tenable Web App Scanning

There are several viable ways to operate a web application scanning program based on dynamic application security testing (DAST) technology. Most programs use some combination of each approach to meet different needs for each site. The following list gives Tenable supported scan templates:

• Scan: The complete set of available checks which includes all other pre-built templates, except for the API scan.

• Overview: A simplified version of the “Scan” template without several active tests to lower its impact and speed up the scan.
• PCI: A special template used as part of the attestation offering that Tenable provides for the payment card industry (PCI) security standard. Only submissions to attestation consume PCI licenses; otherwise, this template is a simplified version of the "Scan" template.

• SSL/TLS: A health check scan focused on the current state of the web server encryption settings and certificate state (for example, the remaining time on the certificate).

• Config Audit: A compliance audit that detects externally viewable web server settings that external audit providers commonly review to evaluate the health of a security program.

• API Scan: A special template requiring more configuration to describe the application programming interface (API), so that the scanner can successfully detect relevant vulnerabilities This includes some similar tests in the “Scan” template but adds others unique to API endpoints.

You typically use the “SSL_TLS” or “Config Audit” scan templates to run a rapid test — often lasting only minutes — on a more regular basis than in-depth scans to give you an overview of surface-level checks such as any certificate-type and encryption-type issues with a given site or commonly exposed configuration parameters that are not best practice.

• Untuned Detailed Scans: Without requiring tuning or refinement, this approach uses the “Scan” template to optimize detection of most vulnerabilities, and simulates drive-by style attacks that sites commonly experience. These scans deploy quickly and return valuable incremental visibility from the scan target while using basic validation to avoid obvious scan errors. However, this approach may run into timeouts (such as the eight-hour default in Tenable Vulnerability Management), or miss more complex sections of a site that requires authentication or fine-tuning for correct scans. These drawbacks are common with sites that have forums, blogs, large product volume, multiple languages, or a high number of pages.

• Authenticated Detailed Scans: While similar to the Untuned Detailed scan, this approach uses authentication. You can do this in the scan configuration page or in the Chrome extension from Tenable. In addition to the benefits of an untuned scan, authenticated scans log on as a user to test for potential issues. Tenable recommends that you never log on as an admin user, especially in production (see the "Key Considerations" section). Authentication requires you to create and maintain the test user account and to update any unique site configurations.

• Tuned Detailed Scans: In addition to authentication, you can use other methods to optimize scans for speed or complexity (see “Key Considerations”). These refinements involve an initial time investment before deployment and may require semi-regular adjustments depending on the frequency of the site updates.

To limit scanner impact on a production site and maintain 100 percent uptime, you can consider integrating scans using the Tenable Vulnerability Management API to trigger a scan based on a weekly or monthly build, or a pre-production location on a regular schedule. This protects the more exposed production site which may differ from internal builds. This scanning approach works to varying degrees with most mature organizations and often depends on-site criticality and resource availability.

Organizations are increasingly adopting APIs to power web applications, B2B transactions, mobile applications, and automation scenarios. You can assess these potential exposures by using the API scanning template within Tenable Web App Scanning to provide critical visibility into more cyber risks. In general, high risk and exposure are drivers for mature programs or organizations to scan APIs more frequently. Ultimately, as the security program develops, many organizations proactively identify all vulnerable locations to ensure full coverage. This type of scan can require more input from development staff and rely on an OpenAPI file to provide the endpoint definitions for the scanner to communicate to the API itself.

Most programs start with a few scans based on the “SSL_TLS” or “Config Audit” templates to familiarize vulnerability managers with how to establish scans and review results. Then, they progress into running an untuned scan using the Tenable Web App Scanning scan template.

Timeouts are common when you first build out your program. The default scan completion timeout in Tenable Vulnerability Management is eight hours, and extending this may not “complete” the scan; this may only be achievable via tuning for greater speed.

It is viable to run a program based on untuned scans while accepting the timeout. As many web application vulnerabilities span multiple pages containing the same vulnerability, it is likely that a scan automatically detects a significant proportion of vulnerabilities within the first several hours. Tenable's own monitoring can confirm this. Tuned scans typically improve scan efficiency and accuracy by only a small degree and cost more time to refine the scan configuration.

Most mature organizations tune scans on their most critical sites, which involve 10-20 minutes of effort per site and improves with operator experience. An organization’s level of knowledge and resource availability can determine the percentage of sites that undergo detailed tuning. It is rare to see all sites tuned, especially in organizations with many websites. This is due partly to the dynamic nature of websites; they often expand or change significantly every few years, and this requires a review of scan settings to adapt to the development pace of the test site.

• Focus on the process first: Start with the Tenable Web App Scanning “Scan” (a complete set of checks) or an “Overview” scan (fewer checks but lower impact) templates. Familiarize yourself with the scanner output and work with your teams to incorporate the findings into your workflows. Develop your mitigation and resolution programs.

• Dig deeper into critical areas: Once you have established some of the baseline procedures and identified the right owners within your organization for the output from the scanner, start investing time in more advanced-tuned scans to gain better visibility into your most important sites.

• Take action: The scans return a significant amount of data to drive organizational action. Consider the potential consumers of the data. Developers want details to identify necessary fixes and improve over time. Management must know which sites contribute the greatest risk to the business, and therefore allocate resources. Security leadership needs general category information such as the OWASP vulnerability categories for all sites to focus on a specific classification of vulnerabilities.

Note: Tenable Professional Services offers a highly recommended quick-start program for new users of Tenable Web App Scanning scanning to help establish the mechanics of developing a new program. Also, the ProServe team runs a workshop to establish the internal processes and initial goals of developing a broader vulnerability management program. These services help organizations get a solid foundation and understanding of effective cybersecurity programs and familiarization with the product. Contact your Tenable sales representative at [email protected].

1. Identify where the location of the web application:

   • Public Websites

     You can scan external websites from Tenable Vulnerability Management using the internet-based Tenable Web App Scanning or an on-premises scanner.

   • Private Websites

     You can scan internal or intranet web applications from Tenable Vulnerability Management using an on-premises Tenable Web App Scanning Scanner.

2. Ensure that the scanner has a network route to the target:

   If the scanner cannot reach the web application, or cannot deliver an input and retrieve results, scanning fails. Network constraints such as latency can affect scanning or network controls (for example, host-based firewalls, network firewalls, network segregation, etc.). Always include internal web application scanners on your "allow" list.

3. Scanner location can impact latency or server response times

   If there are too many timeouts during a scan, the session terminates. Choose a scanner located as close as possible to the targets. Review the sitemap plugin attachments to check for long page load times or timeouts. This can occur with too many concurrent tests on a slower server, a scanner that’s not close enough to the web application (such as scanning Australia from a US scanner), or the site setup that may lead to longer load times. Changing your scanner location can help to prevent readjustments for advanced settings that slow the scanner down. Counter-intuitively, slowing the scan speed settings can speed up results on a site that responds slowly, by lowering the rate of queries and adding less variability to the returned queries.

4. The scanner acts as a user:

   The scanner can follow links, press buttons, and simulate the actions of a user based on what it can access. There can be undesired interaction on the site as a result of its site discovery phase. For example, if a user can send an email, the scanner can fill out forms and press the “send email” button potentially more than once. The scanner has no context for any specific button action, unless you teach it or exclude either the whole page or page element to prevent it from pressing a button unintentionally. (For more information, view our documentation on Scope Settings.) Keep in mind that excluding page elements to prevent such actions lowers the accuracy of the scan, so consider plans to scan sites like this in pre-production on a regular schedule.

5. The scanner acts as many users:

   With its default settings, the scanner can operate as several users navigating the website at the same time. On servers with good capacity, there is typically minimal impact from this activity. However, if the state of the server is unknown, you can de-tune the speed of the scan — at least for the first test — to alert to any potential site impact from simultaneous sessions. For more details on configuring such a test, see Advanced Settings.

6. Customize tuning for each site; it requires effort, but it is optional.

   Customized tuning generally applies to most websites because each web application is different. There are unique structures, sitemaps, third-party libraries, components, and custom code working together. Your investment in tuned scans depends on resource availability, criticality of the site, and impact to the business.

7. When tuning for authentication, never run a Tenable Web App Scanning scan as a web site administrator in production – only in test or pre-production environments.

   Running a web application scan with administrator credentials could create or delete users, or perform other undesired administrative functions.

8. When tuning for speed, a rudimentary understanding of your sites can help accelerate DAST scans.

   1. Review the sitemap plugin and associated file attachment.

   2. Configure your settings: Increase “Network Timeout,” or lower “Max Simultaneous Requests” and “Requests per Second,” if you experience significant page timeouts, or discover higher than five-second average page response times in the sitemap attachment.

   3. Consider speeding up your scan settings if you obtain sub one-second responses and only minimal impact to the web server.

   4. Deduplicate site content: The scanner does not test site text, image, and video content — only input fields and interactions. If you have redundant pages, such as a site that uses multiple languages but has the same underlying code, you only need to test one language version of the site.

   5. Add more binary exclusions: Tenable Web App Scanning does not “test” text, images, or videos and decide which file extensions to exclude. The scan scope section provides a default set that you can adapt for a specific site.

   6. Prioritize critical URLs: Identify the critical portions of the application, such as those ones forms that can return sensitive data. Add those URLs to the scope of your testing, either via “include” in the scan scope section, or through a manual crawl script. You can also consider whether these sites require testing in pre-production.

9. When tuning for complexity, use session recordings to train the scanner.

   You can do this either by using the Tenable Chrome extension or Selenium IDE, and adding within the scope section of a scan configuration. With this process, you can perform manual crawling to ensure that the scanner can test a highly complex location within a site. For example, a site can require a specific series of button presses and a specific set of correct input values to reach a page that isn’t available any other way. You can record the steps to enable the scanner to play it back.

10. Map out whether there is a web application firewall (WAF), web proxy, or load balancer between the scanner and the target:

    Some network devices can interfere with the scanning or completely invalidate the results. You may think it’s sufficient to receive only the “remote” view of results filtered by the firewall; however, it’s possible the WAF’s built-in protections only prevent one or two methods of executing the flaw. Gaining a full picture of the true state of the site is imperative to make risk-based decisions. Configure your WAF to support bypass functionality to allow specific IPs or a combination of IP and agent header strings to prove and authorize the incoming scan. A list of Tenable scanner IP ranges is available here.

11. Some sites can require specific browser identities:

    Check whether the application is compatible with the default user agent (configured as “WAS/%v” by default). If not, it may need a specific or commonly available header from a standard browser, such as Mozilla/5.0. Some server-side protections or a web application firewall can require a specific set of results. In this case, you can copy the user agent string from a known browser that can access the site successfully.

12. Target critical sites with greater care at the outset:

    Is the target site production-facing, or in any other way critical? What is the business impact if the web application scanner causes a service disruption? Always perform the first scan of a site in a controlled manner, either with staff on-hand or within a pre-production environment. Once you understand the nature of the site, you can begin full automation.