Craft a SaaS-oriented web application vulnerability mitigation policy

Organizations depend on web-based software to run business processes, conduct transactions, and deliver services to customers; when deadlines loom, the business may get frantic and sacrifice security features in order to move the application more quickly into production. This reaction often results in a substandard application. A more proactive solution is to establish a Software as a Service (SaaS)-oriented web application vulnerability mitigation policy (complete with a SaaS-based app-vulnerability scanner) that anticipates application trouble spots and contains several pre-configured solutions to repair them. The author provides a roadmap to such a policy and illustrates using a scanner tool in the form of IBM® Rational® AppScan products.

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.



27 June 2012

Also available in Chinese Japanese Portuguese

A cloud service measurement policy is for cloud service providers to use to track virtualized resources and the state of the physical infrastructure under extreme dynamics and scale. The extent to which a cloud service user can negotiate with the provider on measurement policy for use with the service level agreement depends on the extent of control the user has — the more the user controls a cloud service, the more variables there are in crafting the policy.

This article describes the SaaS model view in theory; in reality you'll see how to craft a SaaS-oriented web application vulnerability mitigation policy.

SLA: Virtual resources

The cloud service type determines the availability of virtualized resources to be tracked or measured for use with the service level agreement (SLA) that say, requires a guaranteed 99 percent availability of service. Both the cloud service type and availability of virtualized resources influences what variables should be included in crafting a cloud service measurement policy.

SaaS-based virtual resources

SaaS users are broadly divided into three groups:

  • Non-technical users
  • Application developers
  • Website maintainers

Each group has different needs from the SaaS model:

  • SaaS user: The only control an end user has is to access the provider's application from a laptop, network, or a mobile device. The user does not have the access to measurement tools.
  • SaaS provider: At a minimum, the provider controls virtualized resources including operating systems, hardware, network infrastructure, application upgrades, and patches. The provider controls measurement tools.

PaaS-based virtual resources

The availability of Platform as a Service (PaaS)-based virtualized resources is reflected in the SLA the PaaS subscriber negotiates with the provider. The SLA focuses on the availability of service provided by virtual resources used to protect data in addition to managing access to the applications.

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 (AppScan Monitoring) provides role-based reporting access and scan permissions and utilizes a non-intrusive subset of the 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, AppScan 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 Windows® Internet Explorer or Mozilla Firefox to access the SaaS model, each has its own pitfalls.

Changing user requirements

The only control 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 can 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 launch new or upgraded applications. 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 of the most popular browsers used in accessing Rational AppScan OnDemand and AppScan Monitoring (at publishing time, I'm not sure of the usage statistics of Google Chrome, although it is probably on the rise). Browser choice is a user preference.

While Firefox is faster than Internet Explorer in loading pages when it starts, one pitfall is that it can 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 can consume is influenced by these variables:

  • What add-ons and extensions you've included in Firefox.
  • How long you use Rational AppScan to test web applications and monitor websites for vulnerabilities.
  • How long Firefox is idle when you're not using it.
  • What other applications you're using on your desktop or laptop.
  • How many CPUs and what the maximum amount of memory are consumed 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 these seven suggested steps:

  1. Immediately logoff from Rational AppScan OnDemand and AppScan 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 End Process at the bottom of the task manager.
  7. Click End Process 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 do 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:

Purpose: What's it about?

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 AppScan 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 seven 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 AppScan 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 AppScan 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 is a template 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; constraints 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 is a template 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

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=823041
ArticleTitle=Craft a SaaS-oriented web application vulnerability mitigation policy
publish-date=06272012