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:
- Immediately logoff from Rational AppScan OnDemand and AppScan 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 End Process at the bottom of the task manager.
- 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?
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:
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.
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.
- Visit IBM Managed Security Services (cloud computing) for more on 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 on developerWorks SOA and web services and on developerWorks Industries.
- 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.