IBM Security AppScan Enterprise EditionScan configuration best practices

Madhusudhan Rajappamadhu.sudhan@in.ibm.com

Daniel Andersondanielan@us.ibm.com

May 10, 2014

Abstract: IBM Security AppScan Enterprise Edition (AppScan) offers advanced application security testing and risk management with a platform that drives governance, collaboration, and security intelligence throughout the application life cycle. While configuring and running scans using Appscan, novice security testers may encounter problems such as improper scan coverage, excessive scan times, failed or suspended scans, communication errors, and so on. The practices described here will help security testers configure and run more successful scans with IBM Security Appscan Enterprise Edition.

• Table of Contents1Best practices―Pre-scan..........................................................................................................................4

1.1Understanding web application security vulnerabilities..................................................................41.2Test environment considerations......................................................................................................4

1.2.1Perform testing in a test environment.......................................................................................41.2.2Back up before testing..............................................................................................................41.2.3Select a test policy....................................................................................................................41.2.4User credentials for scanning....................................................................................................51.2.5Other test environment requirements........................................................................................5

1.3Understanding the web application..................................................................................................51.3.1Consultations............................................................................................................................51.3.2The walk-through......................................................................................................................5

2Best practices―Configuring scans .........................................................................................................72.1Configure manual explores..............................................................................................................82.2Configure logins ..............................................................................................................................92.3Configure in-session detection.........................................................................................................92.4Configure the environment definition............................................................................................102.5Configure exclusions......................................................................................................................112.6Configure explore options..............................................................................................................122.7Configure parameters and cookies.................................................................................................122.8Configure automatic form fill.........................................................................................................13

3Summary................................................................................................................................................144Resources...............................................................................................................................................145About the authors...................................................................................................................................14

• Table of FiguresFigure 1: What to scan...............................................................................................................................8Figure 2: Login management ....................................................................................................................9Figure 3: Demo........................................................................................................................................10Figure 4: Environment definition.............................................................................................................11Figure 5: Exclude paths and files.............................................................................................................11Figure 6: Explore options.........................................................................................................................12Figure 7: Parameters and cookies............................................................................................................13Figure 8: Parameter and cookies > Edit parameter or cookie definition.................................................13Figure 9: Automatic form fill...................................................................................................................14

1 Best practices―Pre-scanBefore configuring and running a content scan job in AppScan, you should take several steps. These pre-scan steps will help you to better understand web application vulnerabilities and ensure that you have an appropriate test environment and understand the functioning of the application being tested. This phase of testing will enable you to properly configure AppScan.

1.1 Understanding web application security vulnerabilities

First, it is important to have a basic understanding of, and the ability to recognize, the various sorts of vulnerabilities that AppScan will be looking for as it tests. The best place to gain this understanding is from the Open Web Application Security Project (OWASP), which maintains an excellent website that includes detailed information on a variety of common web application security vulnerabilities. (SeeResources.) Additional and complementary sources include IBM X-Force, the SANS Institute, and the MITRE Common Vulnerabilities and Exposures (CVE) and Common Weakness Enumeration (CWE) projects.

1.2 Test environment considerations

Before you begin to configure or test a web application using AppScan, there are some environment considerations that you should verify.

1.2.1 Perform testing in a test environment

Web vulnerability testing with AppScan Enterprise includes sending a variety of web transactions to theweb application. These transactions can store, delete, and modify data in persistent data stores, bring down applications, affect server performance, and so on.

It is possible to create minimal, limited-purpose scan configurations that are safe to run in production environments (for example, checking SSL/TLS quality or looking for security-related cookie attributes). However, the general tradeoff between scans that are minimal enough to be safe to run on production servers and scans that are aggressive enough to provide useful, impactful results is such thatwe generally recommend testing to occur only on non-production test servers.

1.2.2 Back up before testing

It is a good practice to make a complete backup of the environment prior to testing. This backup is useful in the event that AppScan corrupts data stores or configurations during testing. It is also useful in helping you more easily recover the environment to a known good state after testing is completed.

1.2.3 Select a test policy

It is a good practice to understand the goals of your organization and to select or craft a test policy that targets those goals. Another developerWorks article―“Introduction to AppScan Policies,” by Nasser, Hoyos, and Anderson―has covered selecting a test policy at length. See “Resources” below for a link.

1.2.4 User credentials for scanning

If the web application has different roles and privileges for different accounts, it should be tested with

user accounts at each of the different privilege levels. Using multiple test accounts will ensure a more comprehensive test of the web application.

1.2.5 Other test environment requirements

Before configuring and running the scan, make sure that the test application has the proper connectivitywith the AppScan Enterprise server.

Also, ensure that the application is configured so that it is not capable of impacting external services and users (for example, sending mass email).

It is also important, in most circumstances, to ensure that the test system is not being actively protected by intrusion prevention systems (IPS) or web application firewalls (WAF), as these systems might trigger security alerts and tend to block the sorts of transactions sent by AppScan Enterprise during testing.

Finally, the test application should be verified to be fully functional, be free of known defects, and havereasonable performance.

1.3 Understanding the web application

Once you have an appropriate test environment available, the next step is to understand how the application that is to be tested is implemented on a functional basis. This understanding should includebasic navigation, parameter purposes and usage, login method and session management, test data requirements, and so on.

1.3.1 Consultations

One way to gather this sort of information is to consult with the application architects, developers, and functional testers.

The application architects can generally provide an overview of the purpose of the application, its architecture, the roles and access levels, support for multiple languages and browsers, and the types (and sensitivities) of the data being processed.

It is good to make contact with the developers early in the process, as they can be invaluable sources ofdetailed information if the need arises later on. Developers can also often fill in for the architect when the architect is unavailable for consultation (which can frequently happen, especially on legacy systems).

Functional testers often are particularly rich sources of information. They frequently will have detailedfunctional test plans that describe the steps and data necessary to fully test the functionality of the application. This can serve as a roadmap to increase the security test coverage. Functional testers may also be a source of useful tips generated by their experience in testing the application (including the configuring of automated functional testing tools).

1.3.2 The walk-through

Armed with the information that you gained from your consultations with the application team, you areready to conduct a walk-through, the most important way to get an understanding of the application. The walk-through is a semi-structured manual exploration of the application.

Tools

While a walk-through utilizing only a browser is helpful, the use of additional tools can help you gain adeeper understanding of the application. Some examples of such tools include:

• OWASP ZAP, Burp Suite, and Fiddler

• These tools are intercepting web proxies that can be used to view or edit web transactions (among other more advanced functionality).

• Browser plugins

• Tamper Data―A Firefox plugin that is functionally similar to intercepting proxies. Can be used to view or edit web transactions.

• Web Developer―A Firefox plugin that adds a number of tools that are useful during thisphase, including viewing/managing cookies, clearing caches, and so on.

Information to gather

During the walk-through, you should be prepared to identify and noteseveral key aspects of the application:

• Which pages, content, and functionality are available withouta login?

• How does the login process work? What are the associatedroles, technology, and artifacts (cookies, parameters, etc.)?

• Which technologies (e.g., Flash, AJAX, Java, extensive useof JavaScript, modern HTML5 functionality) are in use?

• Which functionality and pages are available only to specificroles and permission levels?

• What distinguishes a page? (Does each page of theapplication have a distinct URL? Or do the pages all share acommon URL and rely on parameters for navigation?)

• Which parameters are functional, which are navigational, and which are data related?

• Which pages represent different functions and which are simply different data records? How arethey distinguished?

• Are there many pages? Are there lots of parameters on each page? Estimate how large the scan will be.

• Which functionality needs specific test data to be explored and tested?

• Which functionality is accessible only via specific navigation paths through the application? Is there specific different functionality to handle different languages? Is there specific different functionality to handle different browsers (including mobile)? Does the application utilize any web services? Does any functionality require servers or services on different servers or in different domains?

• How does the application/server respond to requests for pages that do not exist?

• On large sites, where could the scan be divided into smaller jobs?

Tip: A common source for missed functionality during scans is the absence of proper test data in the application at the time of testing. For example, if an application has standard create, read, update, and delete (CRUD) functionality,when there is no test data in the system, read, update, and delete functionality may be expected to be missed.

• Which pages, if any, should be excluded from the scan?

While this list may initially seem intimidating, examining applications for these characteristics will become much easier as you gain experience performing this information-gathering step. By obtaining this information prior to beginning the scan configuration, you will be better prepared to configure the scan for improved accuracy and scan coverage while reducing total scan time.

2 Best practices―Configuring scans Once you are comfortable with web application vulnerabilities, have a proper test environment, and have gained an understanding of the web application to be tested, now it is time to open up AppScan and begin to configure the content scan job. While this article is not a tutorial on setting up a scan job, the following is our advice on configuring successful scans.

• Give your scan jobs meaningful names and fill in the description fields. Over time, these fields become more important as reminders of the purpose, date, and scope of the test configuration. These fields are set on job creation and are editable on the Job Properties page.

• Provide the correct starting URL(s) of the test application in AppScan Enterprise. This is usually the front page of your application.

• As shown in Figure 1: What to scan, check In starting domains, only scan links in and below the directory of each starting URL if links only in and below directories need to be scanned inthe starting URL. Leave that box unchecked if the links above the directory in the starting URL also need to be scanned.

• If there are domains outside the starting URLs having content that need to be scanned―for example, if link http://www.example.com changes to http://www.support.example.com when accessed―then provide the additional domain (http://www.support.example.com).

Figure 1: What to scan

2.1 Configure manual explores

• Manual explores should be used to navigate through the web application to add pages that need user interaction, such as form fills and pages that may be missed by an automatic scan. Examples of the latter include such pages as those that use Web 2.0 features using AJAX, pages that require specific inputs, or those having embedded JavaScript or links found in Flash components. You may record manual explore data (and recorded login data) in any of three different ways:

• With the manual explore browser plug-in

• With the AppScan manual explore tool

• With AppScan Standard Edition (via the embedded browser or external browsers or by using AppScan as a proxy directly)

• If you select the AppScan manual explore tool or AppScan Standard for manual explores, you can save the results of your explore (or recorded login). This capability can save you time later if you need to modify your explore to accommodate changes to your scan configuration or create a similar scan job.

• Prior to manual explores (or recording logins), it is a good idea to clear any pre-existing cookiesfrom your web browser.

• During the manual explore (or login recording) process, make sure that all other browser windows are closed.

• You should clean up manual explores (and recorded logins) by removing any extraneous URLs or domains before running the scan. You can remove URLs and domains by selecting the checkbox next to the item and pressing the Delete button (marked with an X).

• If your application requires that the pages be accessed in a particular sequence, this may be configured as a multi-step operation. However, multi-step operations can add significant work to the scan job and should be as small as possible to limit their impact.

• You can find remaining pages that require additional manual exploring by using the “Pages withUnfilled Forms” report after your scan job completes.

2.2 Configure logins

With the exception of applications that use only HTTP Basic or Digest authentication, “Recorded” logins are usually the best choice. See Figure 2: Login management .

2.3 Configure in-session detection

• We cannnot stress enough the importance of properly configuring in-session detection. In-session detection is how AppScan checks to see if the scan job is properly logged in to the application throughout the test.

• The in-session page should, ideally, be a GET transaction after the login (generally a POST transaction). GET transactions are often more reliable and have lower impact on the application. You can generate a GET transaction by placing your mouse cursor into the address bar and pressing the Enter key.

• The in-session pattern should be a unique pattern that does not exist on the in-session page when the in-session page is loaded while the scan is out of session. It is a good idea to avoid single words such as Welcome.

• Add more context, including HTML, to the in-session string to ensure that it is unique between the in-session and out-of-session states. In the example in Figure 3: Demo, while Hello may not be sufficiently unique, Hello John Smith probably is.

Figure 2: Login management

2.4 Configure the environment definition

You can improve performance and the accuracy of the results by configuring the environment definition: for example, by entering the Web server type, Application server type, Database type, and soon. See Figure 4: Environment definition.

Figure 3: Demo

2.5 Configure exclusions

You can configure exclusions and exceptions to exclusions to limit the scan.

An exclusion/exception pattern that often works well is to exclude all URLs with “regexp:.*” and then make exceptions to this rule for the specific content that you wish to scan (in this case, using the prefix of “http://demo.testfire.net”). See Figure 5: Exclude paths and files.

Figure 4: Environment definition

Figure 5: Exclude paths and files

2.6 Configure explore options

In addition to using manual explore, configure a test with automatic explore, which will perform spidering and locate pages that might have been missed in the manual explore. (See Configure manual explores above.) This will enable greater scan coverage.

The best coverage of an application will result from a scan with extensive manual exploration and which is allowed to spider.

2.7 Configure parameters and cookies

There are two sections of tunable parameters for parameter normalization: the standard parameter default normalization (on the main configuration screen; Figure 7) and the normalization options set in the specific definition of the parameter (if so configured; Figure 8). After you have determined which parameters are data related and which are navigational, these settings should be adjusted to reduce unneeded redundant testing.

Properly tuning for normalization is almost always worth the effort―with time savings well in excess of the configuration time and effort required for tuning.

Figure 6: Explore options

2.8 Configure automatic form fill

• Automatic form fill should generally be enabled for security testing to be useful. See Figure 9: Automatic form fill.

• If your application has parameters that require specific values, you should configure those

Figure 7: Parameters and cookies

Figure 8: Parameter and cookies > Edit parameter or cookie definition

values either on this configuration page or through exhaustive manual exploring.

• Use of the default value for parameters should be considered the last resort.

3 SummaryThe above suggestions are tried and tested best practices. They will help security testers configure security scans with IBM Security Appscan Enterprise with greater coverage and better accuracy in the results.

4 Resources• Participate in the Open Web Application Security Project (OWASP), an open community

focused on web application security.

• Read "Introduction to AppScan Policies," a developerWorks article by Nadar Nassar, Carlos Hoyos, and Daniel Anderson, for an overview of IBM Security AppScan policies.

• Visit the IBM Security AppScan website to find out more about the IBM Security AppScan family of products.

5 About the authors

Madhusudhan Rajappa is an Advisory System Analyst in IBM. He works as a Technical Lead in designing and hosting the IBM Security Scanning Service (ISSS), a centralized AppScan Enterprise-based security scanning service platform within IBM. He is IBM Certified Specialist - Appscan Standard. He has also presented Appscan Enterprise scanning best practices at the IBM Quality Software Engineering (QSE) forum.

Figure 9: Automatic form fill

Daniel Anderson is a managing security and privacy consultant with IBM Security Services. He has over 20 years of experience in information security, system administration, and software development. Dan is an IBM Certified Specialist for Rational AppScan Standard Edition and holds other security industry certifications including the CISSP, CISA, and CIPP/US. Dan is a veteran of the United States Air Force and a graduate of the University of Nebraska - Omaha.