Zen 2.0

[via random thoughts, by Fox Business]

Some key points:

• Sridhar talks about the ZOHO applications as cloud applications.
• Cost of delivering is much lower.
• Consumer offering is a loss leader, makes $$ from businesses.
• Turned down Salesforce.com acquisition offer.
• Recruit from non-brand name schools and put them through internal training system.

CIO.com has an interesting article on The Truth About Software as a Service (SaaS). It highlighted the fact that most CIOs are still quite cautious when it comes to adopting SaaS.

Here’s when SaaS doesn’t make sense:

• If the application is a competitive differentiator, because everyone will get the same application;
• If heavy customization is required;
• If high availability is required; (this mainly reflects the fact that SaaS providers don’t current guarantee any SLAs, not the fact that SaaS providers not knowing how to keep the systems up. Suprisingly, as the article states, 85% of the SaaS apps have no SLAs.)
• If many points of complex integrations are required.

Other areas of concerns include Service level agreement and Security.

However, there are definitely advantages to SaaS, including:

• Faster deployment time
• Lack of up-front licensing and infrastructure cost
• Ability to address vanilla business processes
• Easier access to current technology
• Fewer bugs
• Potentially lower costs for the enterprise

The article also showed a chart on SaaS adoption by application and vertical market.

Read related articles on why management costs need to be part of SaaS ROI calculations and three approaches for on-demand computing.

Throughout the CloudCamp sessions, most people discussed cloud computing as infrastructure in the cloud. People talk about the advantage of not having to procure and configure physical servers. People talk about the elasticity and utility factors of the cloud. People talk about scalability of the cloud. But not once, at least in my conversations, did people talk about the applications in the cloud. The one time that I raised the question that related SaaS to cloud computing, I was immediately told that SaaS is not cloud computing. Some even questioned wether Google App Engine is considered to be a cloud.

During Reuven Cohen’s “What is Cloud Computing?” session at CloudCamp, the first question I asked the group after Reuven did the introduction was, “What is Computing?”

Wikipedia defines it as the activity of developing and using computer technology, including computer hardware and software.

Computing Curricula 2005[1] defined computing: (via Wikipedia)

In a general way, we can define computing to mean any goal-oriented activity requiring, benefiting from, or creating computers. Thus, computing includes designing and building hardware and software systems for a wide range of purposes; processing, structuring, and managing various kinds of information; doing scientific studies using computers; making computer systems behave intelligently; creating and using communications and entertainment media; finding and gathering information relevant to any particular purpose, and so on. The list is virtually endless, and the possibilities are vast.

Based on these definitions, it would seem like running and using any type of application, including SaaS applications, would be considered “computing.”

So then what is cloud computing?

Gartner defines cloud computing as, “a style of computing in which massively scalable IT-enabled
capabilities are delivered ‘as a service’ to multiple customers using Internet technologies.”

I am generally fine with this definition. It is sufficiently vague that it can cover many different things. It’s also not that different from how Reuven Cohen defined it, “Internet centric software.” So let’s for the time being accept this as the definition.

However, I will try to go a bit further here. In the computer industry, there’s always been the notions of platforms and applications. Wikipedia says that

In computing, a platform describes some sort of hardware architecture or software framework (including application frameworks), that allows software to run. Typical platforms include a computer’s architecture, operating system, programming languages and related runtime libraries or graphical user interface.

and

Application software is a subclass of computer software that employs the capabilities of a computer directly and thoroughly to a task that the user wishes to perform. … Typical examples of software applications are word processors, spreadsheets, and media players.

This is no different in the cloud computing world. In the cloud computing world, there are “Cloud Platforms” and “Cloud Applications.” Cloud platforms include offerings such as Amazon’s EC2 and S3, or Joyent’s Accelerator. Cloud applications include offerings such as Salesforce.com, NetSuite, SuccessFactor and many others.

So, is SaaS cloud computing?

Absolutely!

Since using applications is considered to be computing, and that SaaS is basically providing application software in the cloud, then using SaaS should be considered cloud computing.

Jason Stamper also says “yes” and sees no difference whatsoever.

Interesting enough, Gartner says “no” and calls it a myth that people consider SaaS to be cloud computing. Why they say no is a mystery to me. If you look at Gartner’s definition on cloud computing, there’s absolutely nothing there that would exclude SaaS.

What do you think? Is SaaS Cloud Computing?

This is part 2 of the tough security questions for SaaS providers. In part 1 of the series, we asked the following questions:

1. Data Locality – Where’s my data?
2. Data Segregation – How is my data segregated with other customers, potentially my competitors?
3. Data Access – Who can access my data in your company?
4. Access Audit – Who has accessed my data and where’s my access logs?

We are continuing this discussion with the following questions in part 2.

5. How are the users authenticated and authorized?
6. Web Application Security – How secure is the SaaS provider’s web application?
7. Data Breaches – How do you protect my data from insider breaches?
8. PCI DSS – Are you compliant with PCI DSS?

5. How are the users authenticated and authorized?

Companies have spent hundreds of man years and millions of dollars trying to setup single-sign-on systems inside the corporate firewalls. Most companies, if not all, are storing their employee information in some type of LDAP servers. In the case of SMB companies, a segment that has the highest SaaS adoption rate, Active Directory seems to be the most popular tool for managing users. In many cases, companies have designed their IT infrastructure so that all authentication, including VPN, web proxy, file server, and others will go through this single infrastructure. The process of employee onboarding and termination is much easier this way.

Just as companies start to have some success, the advent of the SaaS model changes the scenario again. With SaaS, the software is hosted outside of the corporate firewall. Many times user credentials are stored in the SaaS providers’ databases and not part of the corporate IT infrastructure. This means SaaS customers must remember to remove/disable accounts as employees leave the company and create/enable accounts as come onboard. In essence, having multiple SaaS products will increase IT management overhead.

SaaS customers will start asking questions on identity and access integration and providers would be wise to design such features in early on. For example, SaaS providers can provide delegate the authentication process to the customer’s internal LDAP/AD server so that companies can retain control over the management of users.

6. Web Application Security – How secure is the SaaS provider’s web application?

One of the “must-have” requirements for a SaaS application is that it has to be used and managed over the web (in a browser.) This creates an interesting scenario. In the on-premise scenario, when a vulnerability is found, at least you have your firewall protecting the application so you may get a bit more time to patch it (assuming the application vendor provides the patch in a timely fashion.) However, in the SaaS world, there is no such luxury. Any vulnerability identified can potentially have detrimental impact on all of the customers. Even leading security companies aren’t immune to security holes in their web applications.

Web application security is quite a hot topic these days and it’s discussed by many security researchers such as rmogull and RSnake. Here’s an interesting article on “What web application security really is“.

Verizon Business recently released their Verizon Business 2008 Data Breach Investigations Report. Of all the breaches, 59% of the breaches involve hacking, with the following breakdown:

• Application/Service layer -39%
• OS/Platform layer – 23%
• Exploit known vulnerability -18%
• Exploit unknown vulnerability – 5%
• Use of back door -15%

Attacks targeting applications, software, and services were by far the most common technique, representing 39 percent of all hacking activity leading to data compromise. This follows a trend in recent years of attacks moving up the stack. Far from passé, operating system, platform, and server-level attacks accounted for a sizable portion of breaches. Eighteen percent of hacks exploited a specific known vulnerability while 5 percent exploited unknown vulnerabilities for which a patch was not available at the time of the attack. Evidence of re-entry via backdoors, which enable prolonged access to and control of compromised systems, was found in 15 percent of hacking-related breaches. The attractiveness of this to criminals desiring large quantities of information is obvious.

Currently there’s really no mandate or requirement for SaaS providers to provide detailed security analysis of the SaaS application. However, it would be wise for the SaaS providers to start considering something similar to what PCI DSS has required of the merchants:

1. 6.5 Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines. Review custom application code to identify coding vulnerabilities. Cover prevention of common coding vulnerabilities in software development processes, to include the following:
   1. 6.5.1 Unvalidated input
   2. 6.5.2 Broken access control (for example, malicious use of user IDs)
   3. 6.5.3 Broken authentication and session management (use of account credentials and session
      cookies)
   4. 6.5.4 Cross-site scripting (XSS) attacks
   5. 6.5.5 Buffer overflows
   6. 6.5.6 Injection flaws (for example, structured query language (SQL) injection)
   7. 6.5.7 Improper error handling
   8. 6.5.8 Insecure storage
   9. 6.5.9 Denial of service
   10. 6.5.10 Insecure configuration management
2. 6.6 Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:
   • Having all custom application code reviewed for common vulnerabilities by an organization
     that specializes in application security
   • Installing an application layer firewall in front of web-facing applications.

Additional sources of information provided as a starting point for more information on web application security would include

• OWASP Top Ten
• OWASP Countermeasures Reference
• OWASP Application Security FAQ
• Build Security In (Dept. of Homeland Security, National Cyber Security Division)
• Web Application Vulnerability Scanners (National Institute of Standards and Technology)
• Web Application Firewall Evaluation Criteria (Web Application Security Consortium)

Trey Ford of Security Spin Control has a fairly good explanation of the recently released PCI information supplement on requirement 6.6.

SC Magazine also has an article on Deconstructing PCI 6.6 for the management folks.

7. Data Breaches – How do you protect my data from insider breaches?

In the Verizon Business breach report blog, Verizon Business stated that

While criminals more often came from external sources, and insider attacks result in the greatest losses, criminals at, or via partner connections actually represent the greatest risk. This is due to our risk equation: Threat X Impact = Risk

• External criminals pose the greatest threat (73%), but achieve the least impact (30,000 compromised records), resulting in a Psuedo Risk Score of 21,900
• Insiders pose the least threat (18%), and achieve the greatest impact (375,000 compromised records), resulting in a Pseudo Risk Score of 67,500
• Partners are middle in both (73 39% and 187,500), resulting in a Pseudo Risk Score of 73,125

Many SaaS advocates claim that SaaS providers can do a better job at protecting the customers’ data. Unfortunately, just because the data is now in the cloud, it does not reduce the risk of insider breaches. Insiders still have access to the data, they are just accessing it a different way. Just because the data is in the cloud, the responsibility of segregation of duties and access authorization still fall on the customers, not the SaaS or cloud computing providers. So yes, it may reduce the chance of insiders getting direct access to, say, a database, it does not in any way reduce the risk of insider breaches. In fact, it may even increase the possibility as you now have to take into consideration of the cloud or SaaS providers’ employees. They have access to a lot more information and a single incident could expose information from many customers.

SaaS providers should be prepared to answer questions on what tools and processes are utilized to ensure segregation of duties and protect from insider breaches. Remember, in the case of the mult-billion dollar insider incident at Société Générale, IT management had implemented all of the controls recommended by auditors, but nobody was monitoring them. So it’s extremely critical to be able to show the processes around these security controls.

8. PCI DSS – Are you compliant with PCI DSS?

PCI DSS has a specific section for hosting providers (including SaaS providers):

Requirement A.1: Hosting providers protect cardholder data environment

As referenced in Requirement 12.8, all service providers with access to cardholder data (including hosting providers) must adhere to the PCI DSS. In addition, Requirement 2.4 states that hosting providers must protect each entity’s hosted environment and data. Therefore, hosting providers must give special consideration to the following:

A.1 Protect each entity’s (that is merchant, service provider, or other entity) hosted environment and data, as in A.1.1 through A.1.4:

1. A.1.1 Ensure that each entity only has access to own cardholder data environment
2. A.1.2 Restrict each entity’s access and privileges to own cardholder data environment only
3. A.1.3 Ensure logging and audit trails are enabled and unique to each entity’s cardholder data environment and consistent with PCI DSS Requirement 10
4. A.1.4 Enable processes to provide for timely forensic investigation in the event of a compromise to any hosted merchant or service provider.

A hosting provider must fulfill these requirements as well as all other relevant sections of the PCI DSS. Note: Even though a hosting provider may meet these requirements, the compliance of the entity that uses the hosting provider is not necessarily guaranteed. Each entity must comply with the PCI DSS and validate compliance as applicable.

Simply put, SaaS providers must be compliant with PCI DSS in order to host merchants that must comply with PCI DSS.

We will continue with our tough security questions in part 3 of this series.

Good set of slides from Slideshare, by John Overton, on best practices for building a SaaS company, via bitcurrent.

| View | Upload your own

Moving to SaaS

Another slide deck from bitcurrent. It looks at the perils and best practices of moving an application from internally-run to software-as-a-service.

| View | Upload your own

Navigating the Labyrinth

Found another one that’s by Rackspace, but probably more vendor pitchy…

| View | Upload your own

IT Finance Connection had an interesting podcast with Ariel Kelman, Salesforce.com’s senior director of platform product marketing. Ariel made a number of interesting points in the podcast: SaaS is good for companies and IT organizations that want to increase focus from infrastructure to innovation. IT organizations should consider SaaS applications just like other applications and [...]

We will be writing a series of blog posts on the tough questions that SaaS providers can expect to get from customers or they should ask themselves. The questions will span many different areas including security, compliance, sales, marketing and operations. This is Part 1 of the security questions. As we mentioned previously here, one [...]

Computerworld has an interesting article titled Survey attempts to answer why companies still shun SaaS. (I believe it’s originally from CIO.com.) A late 2007 survey of North American and European software IT decision-makers found that just 16 percent of respondents said they were already using or currently piloting SaaS applications. Conversely, more than 80 percent [...]

Saas Week just posted a new podcast on Common SaaS Misconceptions with Chris Cabrera, CEO of Xactly. Download file here. Chris, in the podcast, talked about 3 major misconceptions: security, integration and legacy concerns. Security (and data privacy for that matter) has been, and will likely continue to be, the biggest concern. Chris argued that [...]

So why are we defining all these terms here again when everyone else has already defined them here, here, here, here, here, here, here, here, here, etc? Heck, there’s even a definition for Web 3.0 and beyond. Wait, let’s not forget the authoritative definitions from Wikipedia on Cloud Computing, Software-as-a-Service and Platform-as-a-Service! Whew…are we there [...]