Web application vulnerability is a weakness or design flaw of web applications that attackers can exploit to:
- Steal confidential personal or company information.
- Delete millions of tables in thousands of databases.
- Log keystrokes over the airwaves.
- Act as a proxy server to conceal the attackers' identities.
Businesses and industries rely on popular vulnerability scanners (free and commercial) to identify web application vulnerabilities. Often, the same company may find different scanners running on different client workstations.
A better approach is to access an Software as a Service (SaaS)-oriented vulnerability scanner to ensure consistency of vulnerability assessment and remediation.
Since the number and content of the applications to be tested for vulnerabilities vary among SaaS users, a SaaS-oriented web application vulnerability mitigation policy is needed. Users may want to test:
- Only one specific application (patient progress reports) that has been patched up.
- A suite of applications (patient tracking, hospital supplies) developed for one website (in the health care industry).
- Applications across websites (in health care, chemical engineering, procurement) for vulnerabilities.
This article describes the SaaS model view in theory and in reality and shows you how to craft a SaaS-oriented web application vulnerability mitigation policy.
The SaaS model view
With the SaaS model, the only control a SaaS end user has is to access the AppScan OnDemand or AppScan OnDemand Production Site Monitoring from a desktop or a laptop. One drawback of this model is the end user is not allowed to control applications, operating systems, storage, and networking. Only IBM, as the SaaS provider, controls them.
Who are the SaaS users?
SaaS users are broadly divided into three groups: non-technical users, application developers, and website maintainers. Each group has different needs from the SaaS model:
- Non-technical users use the SaaS model to check a specific web application. This application can be the one that has been patched up or upgraded.
- Application developers in a team use the SaaS model to check applications they move from the development phase to testing phase of a life cycle management. These developers might be in different geographical locations.
- Website maintainers use the SaaS model to monitor production websites across multiple applications and domains for vulnerabilities. They look for vulnerabilities introduced after developers launch applications posted to production sites.
Rational AppScan OnDemand
Non-technical users can use Rational AppScan OnDemand to proactively prevent vulnerabilities after identifying and prioritizing vulnerabilities of a specific application. Application developers can use it to check a suite of applications they have developed for vulnerabilities before they post them to web production sites.
Rational AppScan OnDemand Production Site Monitoring
Website maintainers use the SaaS model to prevent vulnerabilities by continuously identifying and prioritizing security risks inherent in dynamic web content across multiple applications and domains. Rational AppScan OnDemand Production Site Monitoring provides role-based reporting access and scan permissions and utilizes a non-intrusive subset of AppScan test policy with no logins to ensure safe scanning of production sites.
When combined with another Rational AppScan solution for code testing or for pre-production web application scanning, Rational AppScan OnDemand Production Site Monitoring completes a strategy for testing security throughout the application life cycle.
The SaaS model view in reality
When business requirements change, user and threshold requirements for the SaaS model change. Whether you are using Internet Explorer® or Firefox to access the SaaS model, each has its own pitfalls.
Changing user requirements
The only control the SaaS users have is to access the SaaS application, the number of non-technical users that can concurrently access the application is limited by a user license. The SaaS subscriber could negotiate with the provider to change user requirements by raising the maximum limit of concurrent users in a new license. Non-technical users are not allowed to change the applications to be tested for vulnerabilities
Since the application developers have the control over the business life cycle of application development, they can change or add tasks the SaaS users want in an application or a website. For each change in application or website behavior, developers should conduct on-demand vulnerability detection, scanning, and remediation.
Website maintainers have control over the websites. They should respond to changing user requirements of non-technical users and application developers after the developers launched new or upgraded applications. The website maintainers should change site configurations to allow for expanding the resources that can be dynamically scaled up and down. The non-technical users and application developers are not allowed to make changes to website configurations.
Changing threshold requirements
SaaS subscribers should have control over user threshold requirements that set the number of concurrent users accessing the application up to the limit specified in a user license from the provider below or at the threshold level. They should negotiate with the provider to raise the user limit in the user license.
The provider has control over resource threshold policy that ensures resource consumption is balanced dynamically for applications to be tested for vulnerabilities. The SaaS subscriber should negotiate with the provider on the amount of dynamic resources allocated to each user depending on the role of each user (non-technical users, application developer, website maintainer).
The provider has control over data request thresholds that ensures data requests to the application can be processed immediately below or at the threshold level. The SaaS subscriber should negotiate with the provider on changing maximum number of data requests. The maximum that can be increased depends on role of each user and the allocation of resources to SaaS users.
Avoid pitfalls with IE and Firefox
Internet Explorer and Firefox are two most popular browsers used in accessing Rational AppScan OnDemand and Rational AppScan OnDemand Production Site Monitoring. Browser choice is a user preference.
While Firefox is faster than Internet Explorer in loading pages when it starts, one pitfall is that it could result in high memory consumption. Firefox can add up memory usage faster than that for the Internet Explorer. When Firefox is idle, it does not stop increasing memory consumption.
How much memory Firefox would consume is influenced by these variables:
- What add-ons and extensions you have included in Firefox.
- How long you use Rational AppScan to test web applications and monitor web sites for vulnerabilities.
- How long Firefox is idle when you are not using it.
- What other applications you are using on your desktop or laptop.
- How many CPUs and what the maximum amount of memory for each.
- The total time an SaaS user is using Rational AppScan to test applications for vulnerabilities.
When the memory approaches the maximum limit of the CPUs, the browser begins to slow down.
To avoid pitfalls of Firefox's high consumption of memory usage, follow seven suggested steps:
- Immediately log off from the Rational AppScan OnDemand and Rational AppScan OnDemand Production Site Monitoring when you are done with testing for vulnerabilities.
- Bring up Windows Task Manager.
- Go to the Processes tab.
- Look for firefox.exe (and iexplore.exe) images (and see how memory consumption increases for each).
- Highlight over the Firefox processes.
- Click the End Process button at the bottom of the task manager.
- Click the End Process button again when you are prompted whether you still want to end the process.
And then restart your browser. Permissions are needed to install Firefox plugins/Active X Controls.
How would you craft a policy for this?
Since web applications to be tested for vulnerabilities can vary based on the group the user belongs to (non-technical users, application developers, and website maintainers), you need to craft a SaaS-oriented web application vulnerability mitigation policy that can be applied to all SaaS users.
In this simplified scenario of crafting the policy, here are some hints for each checklist item you should include in the policy:
- Purpose: What's it about?
- Scope: Draw a boundary around your policy.
- Background: Want to know more?
- Actions: Roll up your sleeves.
- Constraints: Work with them.
To reach the goal of implementing the security policy, briefly state what the security policy is intended to do. You can use a template like this to give you an idea how to state the purpose:
The purpose of the policy is to help implement security policy for the use of SaaS-oriented Rational AppScan OnDemand and Rational AppScan OnDemand Production Site Monitoring by end users — non-technical users, application developers, and website maintainers. The policy focuses on threshold levels, user requirements and vulnerability identifications, and monitoring as part of the policy.
Scope: Draw a boundary around your policy
Define the scope by "drawing" a boundary around the security policy. Within its boundaries, specify which end users are covered in the policy and whether they represent businesses or government agencies. Specify what the maximum and optimal user, data, and resource threshold levels are, what user requirements must be satisfied, and how the vulnerabilities are identified and monitored.
The provider needs to find out if the consumer will stay within the fence (comply with the terms of the security policy on access controls) when accessing Rational AppScan OnDemand and Rational AppScan OnDemand Production Site Monitoring. If the consumer strays out of the fence after agreeing to comply, the mobile device user runs the risk of violating the policy. In this case the provider must indicate the consequences of not complying to make sure the consumer stays within the fence.
Here is a template to use when you state the scope:
This policy applies to all SaaS end users who use Rational AppScan OnDemand and Rational AppScan OnDemand Production Site Monitoring. They must consent to all of the provisions of this security policy and agree to comply with all of its terms and conditions on access controls. Any end user, developers, and website maintainers whose actions violate this policy, IT policy, and regulations shall be subject to limitations or loss of service with the provider.
Background: Look what's behind the policy
The first things a consumer wants to know are whether the provider is internal or external and what the boundaries of controls management between the provider and an SaaS user are (for example, the SaaS end user has the least control), how the provider would manage access controls, provide data protection, manage virtual machines, and respond to cloud security attacks or incidents on mobile devices.
The SaaS user wants to know how the security policy covers the issues of restoring the system (and user, data, and resource threshold levels) to laptops and how quickly he gets credits, free time, or the right to terminate as set forth in the SLA.
The SaaS user wants to know how to access the IBM Security Bulletin on possible vulnerabilities of any Rational AppScan products and the remediations to eliminate those vulnerabilities.
Here is a template you can use to give you an idea of what to include.
Rational AppScan OnDemand and Rational AppScan OnDemand Production Site Monitoring are hosted externally by IBM, a member of the telecommunication industry.
If a surge in workload demands will cause system performance to slide down from the guaranteed levels of availability for 30 days, the provider must give SaaS users credits, free time, or the right to terminate the service as set forth in the SLA.
The provider must notify the consumer of the exceptions or constraints to the threshold and vulnerability mitigation policies.
A user license contains three types of maximum limits:
- Users accessing concurrently the application.
- Resource instances to be allocated to each user.
- Data requests the user can handle during a surge in workload demands.
Actions: Roll up your sleeves
Here are 7 suggestions for actions to take to make consumers happy:
- Action #1. Send consumers copies of the SaaS-oriented web application vulnerability mitigation policy for review and questions to be resolved before the consumer signs up for Rational AppScan OnDemand and Rational AppScan OnDemand Production Site Monitoring.
- Action #2. Indicate in a SaaS user license the maximum limit on concurrent users, resource instances for those users, and data requests each user can handle.
- Action #3. Indicate what vulnerability types that Rational AppScan OnDemand and Rational AppScan OnDemand Production Site Monitoring can scan.
- Action #4. Require background checks on all intended cloud users before granting them access to the cloud. The depth of background checks depend on the type of application to be tested for vulnerabilities and the type of industry the intended users represent.
- Action #5. Require training programs for approved cloud users on security awareness and labeling and handling of data after completing vulnerability tests.
- Action #6. Give advanced notice on scheduled maintenance or upgrades to the infrastructure of hardware, software, and networks underlying the SaaS-based model.
- Action #7. Give notice to use dummy or test data when testing software for vulnerabilities. Use of sensitive data is prohibited.
Here are some templates you can use:
Security training: The provider sets minimum requirements for security training for approved SaaS users on vulnerability awareness and mitigation.
Scheduled maintenance: The provider sets a schedule of maintenance including upgrades.
Background checks: The provider sets requirements for background checks for intended cloud users.
SaaS user license: The provider sets maximum limit on:
- Users that can concurrently access the application.
- Resource instances that users can use to access and run the application.
- Data requests that users can send and receive concurrently using the available resource instances.
Test data: The provider sets the minimum requirements for running test data with the application to be tested for vulnerabilities.
Constraints: Work with them
There will most probably be some constraints in your way, such as:
- Service priority issues to different groups of consumers, depending on the roles assigned by the organization to consumers. An end user with administrative privileges has a higher priority over the end user that does not have administrative privileges in accessing a SaaS application.
- Change management governance groups. To reflect changes, update the security policy, threshold policies, and SLA.
- Service exceptions to a cloud service type. Here's a hint: Accidental of cutting fiber optics not within direct control of the provider, scheduled maintenance (planned and unplanned), and scheduled proactive behavioral upgrades to applications.
- Security penalties for not complying with all of the security policy's terms and conditions. Specify the consequences of noncompliance with the security policy and IT policy regulations.
Here are some templates you can use.
SaaS end user who functions as an administrator of a user license has a higher priority over other end users in accessing a licensed application.
Due to recent organization change, policy governance group moved from Department FGH to Department RST. This requires an update to the SaaS-oriented web application vulnerability mitigation policy.
Service exceptions currently cover:
- Scheduled proactive application behavioral changes or upgrades.
- Botnet attack against the provider's host.
- Provider's scheduled maintenance.
- Provider's normal service availability from 7AM to 6PM and restricted service availability from 8PM to 11PM.
Crafting any security policy requires planning ahead of time to resolve the issues on how purpose, scope, and background of the policy should be stated: Since data obviously stands more of a chance being exposed in a cloud environment, building a cogent web application security policy is a given.
Developers should communicate with the both the cloud service consumer and provider on the issues of how much control a consumer should have, what actions the provider should take and what constraints to the policy are. Most important of all, the consumer should get a copy of the security policy (as well as those copies of the threshold policies) from the provider for review and questions to be resolve before negotiating with the provider.
- The author discusses the four variables that shape a cloud mobile security policy in the article "Craft security policy for mobile devices."
- Learn more about IBM Rational AppScan OnDemand and Production Site Monitoring.
- The author discusses threshold policy in the articles "Balance workload in a cloud environment: Use threshold policies to dynamically balance workload demands," "Cloud computing versus grid computing: Service types, similarities and differences, and things to consider," and Build proactive threshold policies on the cloud."
- The author discusses proactive vs. reactive ways of making application changes when you migrate them to the cloud in the article "Change app behavior: From in house to the cloud."
- The author discusses cloud service security and how to mitigate risks to cloud services to ensure high uptime availability in the article "Cloud services: Mitigate risks, maintain availability."
- The author discusses three proactive steps to ensure cloud performance — monitoring, testing, and policy-building — in the article "Craft a cloud performance metrics policy."
- In the developerWorks cloud developer resources, discover and share knowledge and experience of application and services developers building their projects for cloud deployment.
- In the developerWorks Rational developer resources, discover and share knowledge and experience of technical resources and best practices for the Rational software delivery platform. There is a sub-section for Rational AppScan technologies.
- More developerWorks resources that match this article can be found at SOA and web services at developerWorks and industries at developerWorks.
- Find out how to access IBM SmartCloud Enterprise.
Get products and technologies
- See the product images available for IBM SmartCloud Enterprise.
- Join a cloud computing group on developerWorks.
- Read all the great cloud blogs on developerWorks.
- Join the developerWorks community, a professional network and unified set of community tools for connecting, sharing, and collaborating.
Dig deeper into Cloud computing on developerWorks
Exclusive tools to build your next great app. Learn more.
Crazy about Cloud? Sign up for our monthly newsletter and the latest cloud news.
Deploy public cloud instances in as few as 5 minutes. Try the SoftLayer public cloud instance for one month.