Craft a SaaS-oriented vulnerability mitigation policy

Put a policy and tools in place to quickly bring secure apps to production

Many businesses and industries depend on web-based software to run business processes, conduct transactions, and deliver services to customers. When a deadline looms, organizations may get frantic and sacrifice secure features to bring the application into production. This is a fast (and reactive) solution that results in a usually defective application. A better, proactive solution is to create a SaaS-oriented web application vulnerability mitigation policy (and employ a SaaS-based vulnerability scanner) into place that anticipates application vulnerabilities and has several solutions to repair them ready to go. The author will provide a roadmap to such a policy and illustrate using a scanner tool in the form of IBM® Rational® AppScan products.

Share:

Judith M. Myerson, Systems Engineer and Architect

Judith M. Myerson is a systems architect and engineer. Her areas of interest include enterprise-wide systems, middleware technologies, database technologies, cloud computing, threshold policies, industries, network management, security, RFID technologies, presentation management, and project management.



12 January 2012

Also available in Chinese Russian Japanese

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.

One example is QualysGuard, an on-demand vulnerability management and policy compliance solution that follows the SaaS model. It offers network discovery and mapping, asset prioritization, vulnerability assessment reporting, and remediation tracking according to priorities of business risks. The downside is Qualys works best with websites that contain little or no JavaScript.

In contrast, IBM® Rational® AppScan OnDemand Production Site Monitoring, which uses the SaaS model, is well adapted to vulnerability scanning of websites that employ a significant amount of JavaScript. It is the more advanced version of IBM Rational AppScan OnDemand for specific applications. Both are part of Rational AppScan product line designed to provide comprehensive application vulnerability management across the application life cycle from requirements through design, code, and production.

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:

  1. Immediately log off from the Rational AppScan OnDemand and Rational AppScan OnDemand Production Site Monitoring when you are done with testing for vulnerabilities.
  2. Bring up Windows Task Manager.
  3. Go to the Processes tab.
  4. Look for firefox.exe (and iexplore.exe) images (and see how memory consumption increases for each).
  5. Highlight over the Firefox processes.
  6. Click the End Process button at the bottom of the task manager.
  7. 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.

In conclusion

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.

Resources

Learn

Get products and technologies

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 Cloud computing on developerWorks


  • Bluemix Developers Community

    Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.

  • developerWorks Labs

    Experiment with new directions in software development.

  • DevOps Services

    Software development in the cloud. Register today to create a project.

  • Try SoftLayer Cloud

    Deploy public cloud instances in as few as 5 minutes. Try the SoftLayer public cloud instance for one month.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Cloud computing, Rational
ArticleID=784855
ArticleTitle=Craft a SaaS-oriented vulnerability mitigation policy
publish-date=01122012