I prepared the following must have check list based on Cloud Computing Alliance Guide (v1.0) document. “SaaS Provider” mentioned is the vendor providing the cloud computing service and “Consumer” is the client or end user of the “SaaS Provider”.

Governance and Enterprise Risk Management

1. SaaS Provider must provide at least SAS 70 Type II or equivalent certifications (e.g. Agreed Upon Procedures) SAS70 Type 2 is a mandatory requirement if the service is a SOX critical or within financial statement audit scope.  If Credit card information is involved, PCI DSS compliant certification is required.
2. SaaS Provider must provide Consumer listings of all third party relationships that it have; and similar audit assurance requirements as above are applicable.  The vendor is expected to obtain such audit assurance from 3rd party subcontractors and provide to MFC upon request.
3. SaaS Provider must divulge policies, procedures and processes comprising its Information Security Management System (ISMS)

Legal

1. Consumer must have authority to define Service Level Agreements with SaaS Provider
2. SaaS Provider must incur all costs for both an expected and unexpected termination of the relationship and for an orderly return or secure disposal of Consumer assets.
3. All of Consumer’s data must be destroyed from the SaaS Provider systems and environments upon the termination of the contract/services and upon completion of the transition and conversion to Consumer’s chosen platform and receipt of confirmation of the same from Consumer’s executive sponsor and/or legal counsel.
4. Consumer information assets must not be used for secondary purpose including use of Consumer asset as test data.
5. SaaS Provider must host all Consumer information assets in a country that Consumer is confortable with (based on regulations that Consumer is subjected to).
6. SaaS Provider must accept all costs related to data breaches if possible including recovery costs
7. SaaS Provider must not share Consumer information assets with a third party or government entity without prior consent.
8. Consumer must have escrow arrangement of SaaS Provider software and applications

Electronic Discovery

1. Consumer must have authority to define roles and responsibilities related to Electronic Discovery, including such activities as litigation hold, discovery searches, who provides expert testimony.
2. Compliance and Audit
3. Consumer must have authority to define type of control that will be applied to locations where data will be stored.
4. Consumer must have authority to audit SaaS Provider on demand
5. Consumer must have authority to perform external risk assessments, including a Privacy Impact Assessment on the SaaS Provider

Information Lifecycle Management

1. SaaS Provider must retain and destroy Consumer information asset per Consumer security policies and standards.
2. Consumer must have authority to perform regular backup and recovery tests to assure that logical segregation and controls are effective
3. All regular backup must be received at a data warehouse owned by Consumer.
4. SaaS Provider must have logical segregation of duties of personnel.

Portability and Interoperability

1. Consumer must receive regular data extractions and backups to a format that is not proprietary and is reusable by Consumer
2. Traditional Security, Business Continuity and Disaster Recovery
3. Consumer must have authority to define business continuity and disaster recovery requirements
4. Consumer must have authority to perform onsite inspections of SaaS Provider’s facilities whenever required
5. Consumer must have authority to inspect SaaS Provider disaster recovery and business continuity plans

Data Center Operations

1. SaaS Provider must demonstrate comprehensive compartmentalization of systems, networks, management, provisioning and personnel.
2. Consumer must have authority to perform test on SaaS Provider’s customer service function regularly to determine their level of mastery in supporting the services.

Incident Response, Notification and Remediation

1. Consumer must receive application layer logs to provide granular details of incidents specific to Consumer.
2. SaaS Provider must at least have application level firewalls, proxies and other application logging tools that are key capabilities currently available to assist in responding to incidents in multi-tenant environments.
3. SaaS Provider must use third party monitoring tools such as HP Cloud Assure or McAfee VA
4. Consumer must receive timely notification of any related incident at SaaS Provider including change in personnel working on Consumer assets.

Application Security

1. Consumer must have authority to conduct acceptance test on any new changes introduced by SaaS Provider
2. SaaS Provider must have separate environment for development, testing and production deployment of applications.
3. SaaS Provider must always maintain an application instance for Consumer logically segregated from other instances of SaaS Provider customers.
4. SaaS Provider must construct a registry of application owners by application interface (URL, SOA service, etc.)
5. Consumer must receive third party binary code analysis report (e.g. Veracode report) on SaaS Provider application

Encryption and Key Management

1. Consumer must have authority to stipulate encryption requirements (algorithm, key length and key management at a minimum) for any data classified as restricted or regulated.
2. Cryptographic keys used by SaaS Provider must be hosted by a third party that Consumer is comfortable with.

Identity and Access Management

1. SaaS Provider must use standards enabling federation: primarily SAML, WS-Federation and Liberty ID-FF federation
2. SaaS Provider must support strong authentication natively or via delegation.
3. SaaS Provider must support robust password policies that meet and exceed Consumer security policies and standards

Storage

1. SaaS Provider must provide details of storage architecture and abstraction layers to verify that the storage subsystem does not span domain trust boundaries
2. SaaS Provider must provide the list of storage geographical location.
3. SaaS Provider must provide details of controls that are used during storage provisioning to partition multiple customers
4. Data search capabilities of SaaS Provider must not violate Consumer information classification and handling security standards.
5. At storage, SaaS Provider must utilize strong storage encryption that renders data unreadable when storage is recycled, disposed of, or accessed by any means outside of authorized applications.
6. SaaS Provider must use unique encryption key for Consumer purposes to encrypt Consumer information assets or data.
7. SaaS Provider must meet Consumer data retention policies for long term archival. Decryption and associated technologies should still be useable on the data after several years later.

Virtualization

1. Virtualized operating systems of the SaaS Provider must be augmented by third party security technology to provide layered security controls and reduce dependency on the platform provider alone.
2. SaaS Provider must assure secure by default configurations by following or exceeding available industry baselines for all its VM platforms.
3. SaaS Provider must monitor or enable Consumer to monitor traffic crossing VM backplanes, which will be opaque to traditional network security controls.
4. Administrative access and control of virtualized operating systems is crucial and SaaS Provider must include strong authentication integrated with enterprise identity management, as well as tamper proof logging and integrity monitoring tools.

Feel free to post your thoughts or suggestions. Don’t feel shy

UPDATE: January 2010 – Cloud Security Alliance have a new version of the guide. I will review the document shortly to make necessary changes soon.

Happy Holidays and New Year

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.

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.

Bruce Schneier

by Bruce Schneier

In computer security, a lot of effort is spent on the authentication problem.  Whether it’s passwords, secure tokens, secret questions, image mnemonics, or something else, engineers are continually coming up with more complicated — and hopefully more secure — ways for you to prove you are who you say you are over the Internet.

This is important stuff, as anyone with an online bank account or remote corporate network knows.  But a lot less thought and work have gone into the other end of the problem: how do you tell the system on the other end of the line that you’re no longer there?  How do you unauthenticate yourself?

My home computer requires me to log out or turn my computer off when I want to unauthenticate.  This works for me because I know enough to do it, but lots of people just leave their computer on and running when they walk away.  As a result, many office computers are left logged in when people go to lunch, or when they go home for the night.  This, obviously, is a security vulnerability.

The most common way to combat this is by having the system time out.  I could have my computer log me out automatically after a certain period of inactivity – five minutes, for example.  Getting it right requires some fine tuning, though.  Log the person out too quickly, and he gets annoyed; wait too long before logging him out, and the system could be vulnerable during that time.  My corporate e-mail server logs me out after 10 minutes or so, and I regularly get annoyed at my corporate e-mail system.

Some systems have experimented with a token: a USB authentication token that has to be plugged in for the computer to operate, or an RFID token that logs people out automatically when the token moves more than a certain distance from the computer.  Of course, people will be prone to just leave the token plugged in to their computer all the time; but if you attach it to their car keys or the badge they have to wear at all times when walking around the office, the risk is minimized.

That’s expensive, though.  A research project used a Bluetooth device, like a cellphone, and measured its proximity to a computer.  The system could be programmed to lock the computer if the Bluetooth device moved out of range.

Some systems log people out after every transaction.  This wouldn’t work for computers, but it can work for ATMs.  The machine spits my card out before it gives me my cash, or just requires a card swipe, and makes sure I take it out of the machine.  If I want to perform another transaction, I have to reinsert my card and enter my PIN a second time.

There’s a physical analogue that everyone can explain: door locks.  Does your door lock behind you when you close the door, or does it remain unlocked until you lock it?  The first instance is a system that automatically logs you out, and the second requires you to log out manually.  Both types of locks are sold and used, and which one you choose depends on both how you use the door and who you expect to try to break in.

Designing systems for usability is hard, especially when security is involved.  Almost by definition, making something secure makes it less usable. Choosing an unauthentication method depends a lot on how the system is used as well as the threat model.  You have to balance increasing security with pissing the users off, and getting that balance right takes time and testing, and is much more an art than a science.

Automatic logout:
http://www.schneier.com/blog/archives/2009/06/protecting_agai.html

Proximity logout:
http://www.matthew.ath.cx/projects/bluemon/

This essay originally appeared on ThreatPost.
http://threatpost.com/blogs/difficulty-un-authentication-128

In my previous blog, I pointed out the difference between ASP and SaaS. However, it would help to step back a little and give some background. SaaS is a delivery model in which a commercial software vendor builds the software application, host it at an environment that it comfortable with and expose its services to its customers through web-based interfaces. The interface could be browser based or through web-services.

SaaS is one of the three types of cloud computing services available in the market today. Platform-as-a-Service (PaaS) and Infrastructure-as-a-Service (IaaS) being the others.

Examples of SaaS include Salesforce.com CRM and Google Apps. http://www.saas-showplace.com gives a list of SaaS providers.

Unlike Application Service Provider (ASP)s, SaaS accommodates multiple tenants. The exposed services are common to all its users and is centrally managed, maintained and supported by the provider. Since the service is exposed through the web, it can be utilized by anyone across the globe. Once a user signs up with the provider, all services are available immediately and there is no wait for customization. An amateur user goes through the same training and orientation as an advanced user since the exposed service is the common to all type of users. The user is charged on a as-use basis instead of a fixed monthly charge.

Since the solution is centrally managed, the service level agreements (SLA) would be common to all and may not be flexible at all. Except for the data or information of the user, everything else belongs to the provider. So is the performance of the application too. User data or information is at a location of provider’s discretion and at their mercy. Since the software is built for SaaS model on the web, it may not be available to purchase from a retailer. This prevents the user to independently try out the software or host the software application elsewhere.

Since the software application is completely accessed over the web, it is also exposed to the threats that any other service on the web is exposed. Malicious code attacks and denial of service attacks are some to name.

User need to be concerned about the confidentiality and integrity of data or information that is passed on to the provider. This includes intellectual and confidential information. Sometimes part of the provider operation may be outsourced to another provider that the user may not be aware of. The provider need to ensure that user data or information should neither be accessed by unauthorized personnel nor by other users of the service.

User need to ensure that the data or information that they pass on to the provider is hosted in a compliant jurisdiction. Data originating from certain countries like China cannot be hosted in another country due to legal restrictions. Certain types of data, for example Personal Identifiable Information (PII), are subject to local regulations which prevent it to be hosted in another country. A good example is Canadian Privacy Regulation (PIPEDA). There are others subject to regulations such as HIPAA and GLBA.

User should ensure that there are proper security controls in place at the provider that is compliant with security policies and standards of the user. User should be given the right to audit and monitor the provider periodically.

There should be proper understanding of reporting any issues and their ownership of issues in case of a security incident. User should also consider what happens if the contract with the provider is terminated. Providers may not be able to give back the data in the same model that is expected by the user.

Before signing up with a provider, user may need to verify how resilient the provider is, their security posture, customer support, track record and reputation.

So can we sign up for SaaS? It all depends on the classification and business criticality of data or information that will be passed on to the SaaS provider. If we are subject to laws and regulations that prevent data leaving from our perimeter, then SaaS is not a solution. However, there are other types of information that can very well be managed by a SaaS provider and should be passed on to them so that we can reduce our operational cost.

Saas is Software-as-a- Service and ASP is Application Service Provider.

Though some in the industry say SaaS is a subset of ASP and is one of the ASP delivery model, others say they are completely different.

Here is what I think from a user or customer’s perspective -

ASP

1. Single-tenant approach
2. Customized solution for each user
3. User has authority on the solution hosted by the vendor and can demand the type of service required.
4. User data could be hosted at any jurisdiction per user’s requirement
5. SLA is unique to user
6. Cost is based on user’s unique needs
7. Monthly subscription on an as-used basis
8. Borrowed (third party) software used
9. User has the luxury to pull out of the ASP, buy the software from a third party retailer and host it somewhere else
10. Once signed up, the vendor may take long time to customize
11. Each user requires customized training and orientation which makes its usability cumbersome
12. Solution need not be internet based

SaaS

1. Multi-tenant approach
2. Same features and functionality to all users
3. Solution is centrally managed, maintained and supported by provider. User is at the mercy of the provider and cannot demand any individual changes
4. User data is hosted at a jurisdiction that the provider is comfortable
5. Service Level Agreements (SLA) common to all
6. Comparatively minimized cost than ASP
7. Monthly subscription on an as-used basis
8. Custom built software that is not available anywhere else is used
9. User is unable to buy the software from a third party retailer and is limited to the SaaS vendor always
10. Once signed up, the service is available immediately
11. All users go through the same training and orientation making it easy to use
12. Solution is always internet based

With all these sweet things that we hear about SaaS, should we look forward for “SaaS as a Strategy”? Not necessarily it depends on the type of application and the jurisdiction of the origin of data.

Operator : “Thank you for calling Pizza Hut . May I have your…”

Customer: “Heloo, Heloo, can I order..”

Operator : “Can I have your multi purpose ID card number first, Sir?”

Customer: “It’s he…,hold……….on……889861356102049998-45-54610″

Operator : “OK… You’re… Mr Singh and you’re calling from 17 Jal Vayu. Your home number is 22678893, your office 25076666 and your mobile is 09869798888. Today morning you landed in India at IG International Airport. Welcome back, Sir. Which number are you calling from now Sir?”

Customer: “Home! How did you get all my phone numbers?

Operator : “We are connected to the system , Sir”

Customer: “May I order your Seafood Pizza…”

Operator : “That’s not a good idea ,Sir”

Customer: “How come?”

Operator : “According to your medical records, you have high blood pressure and even higher cholesterol level Sir”

Customer: “What?… What do you recommend then?”

Operator : “Try our Low Fat Pizza. You’ll like it”

Customer: “How do you know for sure?”

Operator : “You borrowed a book entitled “Popular Dishes” from the National Library last week Sir”

Customer: “OK I give up… Give me three family size ones then, how much will that cost?”

Operator : “That should be enough for your family of 05, Sir. The total is Rs 500.00″

Customer: “Can I pay by! Credit card?”

Operator : “I’m afraid you have to pay us cash, Sir. Your credit card is over the limit and you owe your bank Rs 23,000.75 since October last year. That’s not including the late payment charges on your housing loan, Sir..”

Customer: “I guess I have to run to the neighbourhood ATM and withdraw some cash before your guy arrives”

Operator : “You can’t Sir. Based on the records, you’ve reached your daily limit on machine withdrawal today”

Customer: “Never mind just send the pizzas, I’ll have the cash ready. How long is it gonna take anyway?”

Operator : “About 45 minutes Sir, but if you can’t wait you can always come and collect it on your Nano Car…”

Customer: ” What!”

Operator : “According to the details in system ,you own a Nano car,…registration number GZ-05-AB-1107..”

Customer: ” ????”

Operator : “Is there anything else , Sir?”

Customer: “Nothing… By the way… Aren’t you giving me that 3 free bottles of cola as advertised?”

Operator : “We normally would Sir, but based on your records you’re also diabetic……. ”

Customer: #$$^%&$@$% ^

Operator : “Better watch your language Sir..Remember on 15th July 2010 you were convicted of using abusive language on a policeman…?”

Customer: [Faints]

Here is an excellent use case for a badly implemented identity system. Thanks to my friend Lakshmi K (last name purposely not given) who forwarded this joke to me.  I couldn’t resist posting it to this boring security blog. I guess some humor adds some spice!

The Unique Identification Authority of India, or the UIDAI, is an agency of the Government of India responsible for implementing the envisioned Multipurpose National Identity Card or Unique Identification card (UID Card) project in India. It was established in February 2009, and will own and operate the Unique Identification Number database. The authority will aim at providing a unique number to all Indians, but not smart cards. The authority would provide a database of residents containing very simple data in biometrics. [Wikipedia]

I would like to remember only one password for all applications in the enterprise instead of writing each one down whenever its time to change it. The frequency of changing the password may vary from application to application, so does the password rules.

If you look at it from the cost perspective, every call to help desk to manage password costs an estimated $25 – according to Help Desk Institute. So having a password doesn’t come cheap, especially when you have multiple applications at various domains. Imagine this cost coupled with the cost of maintaining the credentials at various applications.

So why not use a software like Bruce Schneier’s Password Safe (http://www.schneier.com/passsafe.html )? That type of software is good for personal use when I have the luxury of time to dig through my list of domains and their credentials. They are not good for an enterprise that is regulated by various statutory requirements. It still does not solve my pain of signing in to multiple applications.

How about Singe Sign On? According to experts in the field, not many enterprises were successful in implementing in this area with single sign on. With all the acquisitions and mergers, it is found better implemented at the divisional or business unit level. However a more realistic approach would be to have reduced sign on.

This is not an easy job for architects as they need to consider stronger authentication mechanisms based on risk policies while consolidating application and reducing the number of access challenges.

One of the major constraints to reduced sign on is the multiple identity and policy domains that exist in the enterprise. They can be handled by having a primary authentication point which will facilitate background authentication with other policy domains. A user is challenged by a single primary system, while that primary system takes care of authenticating with other system in the background without the user’s knowledge.

Some of the options in consolidating sign on are extending network operating system login and centralized LDAP. However, they do have their own limitations. For example, network operating system login cannot be extended to external users and there could be multiple LDAPs within the enterprise that need to be consolidated.

Implementations such as E-SSO where multiple logins can be integrated to one single system is preferred for reduced sign on, however it is a large undertaking and requires time. Similar is the case with federated authentication using protocols such as SAML.

One of the easiest and quick fix to manage this nightmare is to have a password management system. Whenever a user changes the password, it is synchronized with all applications and tools such as LDAP and Active Directory using the password management system. In this way, I have only one password, possibly one user-id, for accessing all system in the enterprise. This still does not reduce my multiple sign on, however it’s the right step in the right direction.

However, if I have to advertise everyone of my single moment, that’s like having someone follow me everywhere. I need to have my own privacy. Of course I am a social being, but there is a limit to which I can allow others to interfere with what I do. So far, the value I found in Twitter is to have someone follow me everywhere, which I don’t favor much. It may help an enterprise to advertise their new products or update their users with product updates. However, it may not suitable for an individual who values privacy.

So far, I am happy with other social networking tools. With recent DoS attack, I am just curious about Twitter’s maturity. Can it protect my identity on it?

This is my first blog in August, decompressed after the Burton Group Catalyst conference.