Multiplex IBM Security AppScan Enterprise

A how-to guide for sharing AppScan Enterprise across multiple departments

IBM Security AppScan® Enterprise is a powerful tool that lets web application developers scan their web applications for vulnerabilities. Because different business units use different applications and have different needs, Security AppScan Enterprise installations are often segmented by business unit. However, a large enterprise might consist of multiple business units, making separate installations costly in hardware, maintenance, and labor. That's where a feature called multiplexing comes in. In this article, learn how to design and implement a multiplexing solution for a centralized IBM Security AppScan Enterprise setup.

Share:

Lalitha Saravana Prasad (lsaravan@in.ibm.com), Team Lead, IBM Security Scanning Service, IBM

Lalitha Saravana Prasad has over 13 years of experience in the areas of networking, protocol testing, security product testing, and web application security testing. She is the team lead in designing and hosting the IBM Security Scanning Service (ISSS), a centralized AppScan Enterprise-based security scanning service within IBM. She has also presented ASE best practices in the Quality Software Engineering (QSE) forum.



Adarsh Thampan, Development Manager, IBM

Adarsh Thampan has worked on designing, implementing, and managing the IBM Security Scanning Service (ISSS). He has published a white paper on "Porting applications to Linux on IBM System z" and is also co-author of the developerWorks article "Implement POSIX Semaphore APIs using System V Semaphores APIs."



22 October 2013

Introduction

Trying out IBM Security AppScan

You can download and try a full-featured trial of IBM Security AppScan Standard, a desktop-client member of the AppScan family of IBM application security products. This Windows application enables you to test its scanning features on a special test website.

A large enterprise might consist of multiple business units (BUs) where each unit is responsible for ensuring web application security. Each business unit could scan its web assets with IBM Security AppScan Enterprise to find any vulnerabilities. However, setting up separate installations of AppScan Enterprise for each business unit can be costly in terms of hardware, maintenance, and labor. Fortunately, IBM Security AppScan Enterprise provides a capability called multiplexing that allows an organization to make optimum use of its hardware resources while minimizing associated labor costs. In this article, learn how to design and implement a multiplexing solution for the Dynamic Analysis Security Testing (DAST) agent servers on a typical IBM Security AppScan Enterprise installation. This multiplexing solution will enable you to serve multiple business units with efficient hardware resource utilization and optimal performance.

Centralized AppScan Enterprise architecture is divided into three main parts: the AppScan Enterprise server, the dynamic analysis agent, and the SQL server database. Each of these main components is further divided into subcomponents, as shown in Figure 1.

Figure 1. Sample Enterprise topology with centralized scanner
An illustration showing a sample implementation of a centralized ASE architecture

The three parts of an AppScan installation are:

  • AppScan Enterprise server, the control center, has two functions:
    • User administration
    • Enterprise console, the main user interface, supporting administration, scan configuration, and reporting
  • The DAST agent, which runs the agent service and the scan, consisting of:
    • A local database, which holds the information for each job the scanner runs and sends the data to the main SQL Server database when the scan is completed.
    • One or more agent servers, which monitor the SQL Server database for jobs to perform.
    • The agents, which are Windows® processes spawned by an agent service when a job is ready to be performed. While a scan job is in progress, the agent records the scan information in the database. If alerts have been configured, the alerting service informs the relevant users when specific events occur during the job.
  • The SQL database server, the central repository for information gathered during a job, including statistics, scan logs, and polling for activity events. This database contains the following data:
    • All data gathered by the agents
    • Information about the scope applied to report data
    • Summarized historical reporting data
    • Agent configuration, scheduling, status, and alerting information
    • User configuration and permission information

In addition, interacting with AppScan Enterprise, as shown in Figure 1, are the following:

  • Target business unit applications, which can be from any business units within the organization (for example, BU-A, BU-B, and so on)
  • Business unit users, which can include web application testers, QA managers, system auditors, or any other personnel from any of the business units

After the AppScan Enterprise and agents are deployed with the proper configuration, each business unit will have its own console to log in to start a scan. For example, BU-A end users will log in to https://domainname.com/BU-A; BU-B end users will log in to https://domainname.com/BU-B, and so on.

A scan job (sometimes called a content scan job or content job) is nothing more than a scan configuration that defines the URLs to be dynamically scanned for a particular web application. Based on this scan job, the AppScan Enterprise scans the target web application and provides a report on vulnerabilities of that application along with recommendations for fixing them.


Design requirements for a multiplexed agent server environment

A typical enterprise consists of multiple business units that require their applications to be scanned by a centralized scanner available across all BUs. Multiple agent servers must be installed to scan jobs from multiple BUs. Based on the load from each BU at any particular point in time, the AppScan Enterprise Administrator should be able to allot agent servers, thereby using the hardware resources efficiently and also serving the business unit's scan jobs.

The following guidelines can help in designing the multiplex environment:

  • Understand the organization's need to be able to scan web assets. For example, ask yourself the following: How many business units wish to take advantage of this service? Do they all build web applications? Are those applications internal or external facing? What is your organization's policy regarding the scanning of web applications?
  • Understand the volume of scans for each business unit, including the approximate number of projects handled in each BU, the frequency of scans they might have, and the volume of each scan.
  • Understand the hardware resources in terms of memory and storage needed. What is the maximum number of scans the agent can handle? What will be the utilization of hardware resources such as memory and hard disk for medium-sized scans (that is, those around 200 to 400 pages)?
  • Based on the answers to the above questions, design a table mapping the agent servers to the business units. (See Table 1.)
  • Tune the scan jobs per agent server according to the need to accommodate the scans for better use of hardware resources and also for fulfilling the scanning requirements of the organization.

Agent server multiplexing

Agent Server Multiplexing is the assignment of agent servers to business units in such a way that the hardware resources in agent servers are optimally utilized and also maintain redundancy between agent servers. At any point in time, the AppScan Enterprise administrator can manage the scans across business units with as few agent servers as possible and also minimize the number of scans that are in waiting state due to lack of availability of a free agent server.

Some business units may require more agent servers than others, depending on the size and complexity of the applications they need to scan. Therefore, you need a mechanism to assign different numbers of agent servers to different business units. Also, because the scanning needs of business units change over time, the AppScan Enterprise administrator should be able to multiplex the agents among them as needed.

In our example, the DAST agent server configuration matches up business units' scan jobs with agent servers to ensure that at least two agent servers are allocated per business unit to support redundancy, as shown in Figure 2.

Figure 2. Agent server multiplexing
An illustration of how scan jobs can be paired with agent servers using multiplexing

In this way, if one of the allocated agent servers goes down, the affected business units can still execute scan jobs on the other agent servers that have been allotted.

Here three agent servers are multiplexed across three business units (BU-A, BU-B, BU-C) in such a way that at any point at least two agent servers are available for any single business unit. The scan jobs for BU-A are served by agent servers 1 and 2; for BU-B, agent servers 2 and 3 are allocated; and agent servers 1, 2, and 3 are allocated to BU-C.

Apart from allotting the agent servers, the AppScan Enterprise administrator also has to define the number of content scan jobs that each agent server can run on behalf of each business unit. Allotting scan jobs to the agent servers using AppScan Enterprise administration so that each business unit can run a minimum number of scan jobs simultaneously is called scan job allocation. To see how scan job allocation is done, look at a sample table the administrator of our example has created, based on the number of business units and the expected scan volume.

Table 1. Sample scan job allocation
BURSMPILOT1(Agent Server1)RSMPILOT2(Agent Server2)RSMPILOT3(Agent Server3)Total scan jobs per BU
BU-A2204
BU-B0134
BU-C2114
Concurrent scan jobs per agent server444

In this example, each business unit of the enterprise needs to be able to run a minimum of four simultaneous scan jobs. The AppScan Enterprise administrator has allotted to BU-A two agent servers (Agent Server1 and Agent Server2), each agent server running two scan jobs. Similarly, BU-B has Agent Server2 and Agent Server3, running one and three scan jobs respectively.

After an end user creates a job, it is automatically routed to the agent servers allotted to that business unit. If one of the agent servers is busy, then the job is automatically allotted to another agent server. However, the AppScan Enterprise administrator can temporarily move or add scan jobs across agent servers to manage sudden peak load across business agents. Suppose a business unit experiences a sudden increase in scan load. The choice of which agent server is allocated additional scan jobs needs to be based on which of the available agent servers is comparatively less utilized. While increasing the count of scan jobs, the AppScan Enterprise administrator can optimize the hardware utilization of the agent servers.

Consider this example: During continuous monitoring of the scans on the AppScan Enterprise console, the AppScan Enterprise administrator finds that BU-A scan jobs are in a waiting state, meaning that four jobs are running and two or three jobs are waiting. The administrator can increase the scan job count on Agent Server1 or agent Agent Server2 based on their utilization across other business units. If Agent Server1 has only two concurrent scans running out of four (assume that BU-C has no scan jobs running on Agent Server1), then the administrator can increase the scan jobs on that agent server to four on BU-A's console. Increasing or decreasing the count of the scan jobs on an agent server is explained in "Allotting scan jobs for each business unit."


Implementing multiplex

The following instructions are intended for the AppScan Enterprise administrator. To implement multiplex, you need to set up the agent servers by running the server configuration wizard on the agent servers allotted for each business unit.

Setting up the AppScan agent servers

On each agent server allotted to each business unit (in the example in Figure 1, the agent servers are RSMPILOT1, RSMPILOT2 and RSMPILOT3), install the AppScan Dynamic Analyzer (ASE_DASSetup_8.7.exe) and run the server configuration wizard. The default setting needs to be based on the agent multiplexing requirement (see Table 1). For example, in Table 1 the agents allotted for BU-A are agent1 and agent2. Therefore, you need to run the server configuration wizard only on agent server 1 and agent server 2, setting BU-A as the console or instance name. See Figure 3.

Figure 3. Specifying the instance―or console―name
A screenshot displaying where a console name is entered

Uncheck the option Use Default Name and specify BU-A as the instance name. Choose Next.

The first time the agent server sees BU-A, it will pop up a window requesting to configure it. See Figure 4.

Figure 4. Configuring the instance
A screenshot showing the dialog box requesting that a console be configured

Fill in the details of the name of the SQL server and the database for that business unit, as shown in Figure 5.

Figure 5. Specifying the SQL server and the database name
A screenshot showing where the SQL server and the database name are entered

Specify the SQL server on which the BU-A database has been created (see Figure 1) and set BU-A as the database name. The database will have already been created on the SQL server database (here, abcsql is the SQL Server). As explained previously, the SQL server database has all the databases created for each business unit. Our example has three databases: BU-A, BU-B, and BU-C.

Click Next. Then on the screen that follows, click Finish.

You have completed the server configuration for BU-A. Similarly, run the Server Configuration wizards for BU-B and BU-C on the respective agent servers.


Allotting scan jobs for each business unit

After you have run the server configuration wizard on all the agents, it is time to configure the number of scan jobs to be run for each business unit on each agent server.

As the AppScan Enterprise administrator, log in to a business unit's console, as shown in Figure 6.

Figure 6. The Agent Servers panel
A screenshot showing the Agent Servers panel on a business unit console

Under Administration > Agent Servers, choose the agent and assign the number of scan jobs to be run on each agent server. RSMPILOT1 and RSMPILOT2 are the agent servers that are allotted to BU-A.

Choose RSMPILOT1 and change the number of content scan jobs as required on each console. For example, as shown in Table 1, on BU-A the number of jobs for both agent server 1 (RSMPILOT1) and agent server 2 (RSMPILOT2) is two. Therefore, allocate a maximum of two content jobs by choosing the agent server and entering the number of jobs. See Figure 7.

Figure 7. Allocating the number of content jobs
A screenshot showing where the number of content jobs is allocated

Similarly, for BU-B, login to the BU-B console (https://domainname.com/BU-B) and choose the agent servers RSMPILOT2 and RSMPILOT3. As indicated in Table 1, configure one job for RSMPILOT2 and three jobs for RSMPILOT3. After doing the same for each business unit, you have completed the multiplexing setup.


Conclusion

The agent server multiplexing capability in IBM Security AppScan Enterprise enables an enterprise to use a few agent servers in an efficient way by optimally using the hardware resources on the agent server. This capability gives greater flexibility to the AppScan Enterprise administrator to allocate agent servers to the business units on an as-needed basis. If the deployment is well planned, this flexibility provides a significant advantage in that it requires minimum manual intervention after deployment.

Resources

Learn

Get products and technologies

  • Download a full-featured trial of IBM Security AppScan, a desktop-client member of the AppScan family of IBM application security products.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Security on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Security
ArticleID=948881
ArticleTitle=Multiplex IBM Security AppScan Enterprise
publish-date=10222013