Shaheen N Abdul Jabbar

In my quest to understand the evolution of SaaS, I started going back a little bit. A few years back, companies use to call a similar delivery model as ASP (Application Service Provider) which is confused with SaaS model. Senior management in the IT world who are used to ASP model started questioning – “So, what’s the difference?”.

According to a research by Alexander Factor, who later published a book called “Analyzing Application Service Providers”, ASP is a business that (1) delivers application services over the network, (2) delivers services to many customers with a wide range of requirements, (3) charges rental or subscription-based fees, and (3) provides customer-specific service guarantees.

So ASP services could be delivered over any type of network, not just through the internet, to many customers with unique rental fee per customer-specific Service Level Agreements (SLA). We could track this model way back to the days when Mainframes were accessed via dumb terminals.

Now, how is this different from SaaS? To understand the difference, we must first go to the basics of Cloud Computing.

According to Cloud Security Alliance (CSA), Cloud Computing is defined as the set of disciplines, technologies, and business to render IT capabilities as an on-demand, scalable, elastic service.

There are some unique characteristics that could be attributed to Cloud Computing:

1. Abstraction of Infrastructure – The compute, network and storage infrastructure resources are abstracted from the application and information resources as a function of service delivery model.

2. Resource Democratization – Provides the capability for pooled resources to be made available and accessible to anyone or anything authorized to utilize them using standardized methods for doing so.

3. Service Oriented Architecture – Provides a services oriented architecture where resources may be accessed and utilized in a standard way. In this model, the focus is on the delivery of service and not the management of infrastructure.

4. Elasticity/Dynamism – Capability to rapidly expand or contract resource allocation to service definition and requirements using a self-service model that scales to as-needed capacity. Since resources are pooled, better utilization and service levels can be achieved.

5. Utility Model of Consumption & Allocation – Provide an “all-you-can-eat” but “pay-by-the-bite” metered utility-cost and usage model. This facilitates greater cost efficiencies and scale as well as manageable and predictive costs.

There are three major types of cloud computing services – SaaS, PaaS and IaaS

Software as a Service (SaaS) – These are applications running on a cloud infrastructure and accessible from various client devices through a thin client interface such as Web browser (e.g. web based email). Technologies such as SOA and Web 2.0 enable this model. Some of typical solution includes desktop publishing, sales, financials, CRM, HR and collaboration.

Platform as a Service (PaaS) – This service will help deploy consumer–created applications using programming languages and tools supported by the provider (e.g. java, python, .Net). Application Servers and ESB tools enables this model which are used in solutions such as Business Intelligence and application development.

Infrastructure as a Service (IaaS) – Consumer of this service could rent processing, storage, networks, and other fundamental computing resources where the consumer is anle to deploy and run arbitrary software, which can include operating systems and applications. Some of the basic ASP enabling technologies high bandwidth network, redundant storage and multi-core CPUs enable this model. Consumers use this model for solutions such as storage and high computing demand.

SaaS is the comprehensive cloud computing model that includes Paas and Iaas. It differs from ASP in its characteristics.

While the infrastructure of an ASP is unique and customized for the consumer, infrastructure is abstracted and is common to all SaaS consumers.

Unlike an ASP, all resources except consumer information or data are common to all consumers. ASP consumers usually have their resources customized for their unique needs.

In the ASP model, the ASP buys third party software on behalf of the consumer, customize it and host it on behalf of the consumer. However in SaaS model, the SaaS provider develops their own application that will not be available in the retail market. The developed applications built by SaaS providers are usually based on industry standards so that they can be widely available through multiple interfaces.

A consumer of an ASP always has the luxury to dictate Service Level Agreements with the ASP provider that is unique and based on their needs. This is not applicable with a SaaS provider. SLAs are usually common and are non-negotiable in SaaS model.

Both ASP and SaaS providers charge their consumers for renting their space and resources. However, the rental fee paid to an ASP provider is usually a flat amount agreed upon for the entire term of the contract for the allocated space and resource. In the SaaS model, the consumer pays the provider based on the usage of the space and resources. For the first month, you may end up paying more for using large space and computing resources and for the later months your payment may decrease as the usage decreases. In the ASP model, you pay the same amount every month, no matter how whether you use the resource to the maximum allocated or not.

Acknowledgement – Thanks to Jim Reavis at Cloud Security Alliance for validating my illustration.

Where do you put vulnerability assessment (VA) scanners in a very distributed network? Consider a scenario where a company has presence in North America, Europe and South Asia. As part of its annual penetration testing environment, the company wants to conduct vulnerability assessment at all its demilitarized zones (DMZ). North America may have DMZs in Delaware and Texas, Europe may have only one DMZ in London while South Asia may have in Bangalore, Calcutta and Hyderabad.

There are some architects who believe that the VA scanners should be caged within each DMZ while others who think a VA scanner can be placed anywhere other than the untrusted zone and a firewall rule that allows only the VA scanner access all of the DMZs. While there are benefits for both extremes, we need to prepare a strategy balancing cost and benefits. The time constraint does not permit to conduct the VA scan in phases (DMZ by DMZ).

There are four options:

1. A Scanner  Per DMZ

Here a scanner is placed in each of the DMZ of the corporate. From a security risk perspective, this is the best strategy. However, is it cost effective? It may not be.

2. A Scanner in one DMZ Per Site

How about placing a scanner at one of the DMZ for each site? This will reduce the cost the scanner. However firewalls made need to be open between neighbouring DMZs so that scanner have access to all the DMZ in a site. It’s fine as long as the rest of the DMZs trust the DMZ where the scanner is located. There is always the risk of a hacker compromising the scanner and getting access to neighbouring DMZ. However there is no need to open traffic to the trusted zones.

3. A Scanner in Trusted Zone Per Site

Another way is to put the scanner in the trusted zone of each site and open the firewall for the scanner to each DMZ in the site. A hacker need to compromise the DMZ and need access to the trusted zone before messing up with the scanner. It’s as good as compromising other systems in the trusted zone. Here is no need to open traffic between the DMZs.

4. A Scanner in the Corporate Network Cloud

What about having just one scanner in the corporate network cloud and it accessing all of the DMZs? If the sites are located very far, there could be latency issues as well as issues with the performance of the scanner itself. If the scanner gets compromised, then a hacker may be able to get access to all of the DMZs but not beyond that.