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
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
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
|BU||RSMPILOT1(Agent Server1)||RSMPILOT2(Agent Server2)||RSMPILOT3(Agent Server3)||Total scan jobs per BU|
|Concurrent scan jobs per agent server||4||4||4|
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."
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
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
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
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
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
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.
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.
- See "Installing the AppScan Enterprise Server upgrade" for a common deployment scenario.
- Find out more about the IBM Security AppScan family.
- Discover technical resources to help you get the most out of Security AppScan Enterprise.
- Watch an "Introduction to Rational AppScan" on-demand demo that will take you through the process of scanning a Web application for security vulnerabilities using Rational AppScan Standard Edition.
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.
- Get involved in the AppScan Standard and AppScan Enterprise community. Connect with other users and the product support and development teams.