(Full disclosure: I work for Quest Software and participate in our Quest OnDemand efforts.)

What’s best is that this is a cloud service – so no local deployment or additional infrastructure is required. You can just go to the website, sign-up for a free trial, download a small agent, and start getting alerts for the events you care about!

Cloud is good for you! Sign-up for a free trial now and have the cloud help you keep your environment secure.

US Department of Health and Human Services (HHS) has just published data on past year data breaches in the medical industry. These only include breaches affecting 500 or more individuals and reaching the “harm” threshold defined by the current rules. Yet, there 166 of those affecting the total of 4,905,768 patients.

PHIPrivacy.net does a good job analyzing the breach data, and you can see that even in the industry which is highly regulated and paranoid about data security and privacy – data being stored locally is getting stolen or lost all the time.

Compare that to a cloud provider (pick any cloud service which you like: Salesforce.com, Microsoft BPOS, Amazon, Google Apps, Quest OnDemand) – have you heard of 166 breaches for any of those? There are good reasons why you have not:

• High security standards of the datacenters: a lot of these are compliant with SAS 70 Type I and Type II and ISO/IEC 27001:2005 – does your datacenter get formally certified that high?
• Clear segregation of duties: people running the datacenter are not your employees, they have no idea what kind of data is getting stored by who and no vested interest in seeing that data,
• Needle in a haystack effect: public clouds have multiple customers, so even if a squad of ninjas attack the datacenter and manage to steel a harddrive it will just have some bits from data from various customers in format specific to a particular application and probably encrypted – making the whole exersize completely meaningless,
• No local device data: your local laptops or mobile devices only work with remote cloud data – so if the device gets lost or stolen you loose the device, not the data.
• Security is in the cloud business model: for any credible SaaS vendor security is number one concern (see for example Quest OnDemand security FAQ). They implement specific security measures such as data isolation, audit trails, and so on.

It is just incredibly hard and costly to set all these measures and maintain them, and I find it hard to see how (apart from really select few companies) these days will have the resources to provide that level of protection and security for on-premise systems. Cloud makes things more secure. Cloud is good for you.

Although new business opportunities can justify a SaaS project, implementation of a new cloud-based offering is not a straightforward task. CTOs, development managers, and sales, marketing and service delivery managers should plan for the far-reaching changes needed across the organization to reach a successful implementation.

…

SaaS-based security products have been gaining popularity and adoption within organizations over the past few years. Although demand for SaaS-based security information event management (SIEM) products is not as high as for other security areas, such as messaging security and remote vulnerability assessment, SaaS-based SIEM is a valuable option for those enterprises that cannot implement security information tools. An on-premises SIEM implementation may not be justified, particularly in those cases where there are limited resources available to be dedicated to deploying and managing SIEM products; the cost of SIEM implementation may be unjustified also in those instances with well-defined but limited technology needs, such as to meet a specific regulatory requirement. As a result, there are interesting market opportunities for SIEM vendors willing to embark on the launch of a SaaS-based log management solution. This Case Study discusses how Quest Software developed and implemented a SaaS-based product offering.

Ruggero goes into the details of why and how Quest went from software to SaaS, what was involved in the transition, and which benefits did this move bring to both the vendor and its customers.

If you work for a software company considering a similar move, or if you are an IT professional considering starting to use SaaS in your environment, I would recommend obtaining and reading the full document here.

One of the leading providers of IT management SaaS – Quest OnDemand – has decided to stop using federation with Live ID as its main user authentication method and switched to simple email address/password way.

In the age of everyone trying to federate with everyone else this move seems to be going into the opposite direction. It turned out that in this particular case – IT professionals signing up for a service – found having to use a third-party identity to be not intuitive and had privacy concerns about the same identity being used for different levels of access to various services from different vendors.

Let’s have a look at what was the rationale behind choosing Live ID initially and then abandoning it. I hope that these lessons learnt will help more thoughtful discussion of when and what kind of federation is the right one to use as opposed to someone one-sided perspective the industry seems to have at the moment.

Why Live ID?

Quest OnDemand is a set of online services for Windows IT professionals. The services currently available include eventlog management and AD backup and recovery. Considering that these are primarily used by IT professionals in the Microsoft world, and that Microsoft uses Live ID (also known as Microsoft Passport or MSN Passport) as a way to authenticate for all Microsoft’s services, it made total sense to let users sign into the new service with their existing Live ID accounts instead of making them register new ones.

When we launched Quest OnDemand in June 2010, anyone interested in any of its services could just come to portal.ondemand.quest.com and sign in with Live ID credentials.

What went wrong?

Once we launched we got overwhelmed by our users telling us how confused and frustrated they were.

The complaints seemed to fall into a few categories:

Confusion about Live ID

Surprisingly enough, a lot of people don’t realize that Live ID is an authentication system which can be used across other web properties from various companies. A lot of people don’t know that what they are using to post to Microsoft’s forums or access their hotmail account is indeed Windows Live ID.

Users signing up or deciding to try a service from your company want that to be a business between them and your company, and are not expecting a third party to get into the mix.

Broken workflow

User experience suffered from users being taken away to another site with different look and feel during their registration process. When user already had a Live ID and used it to sign-in this was not as bad – she was taken back to Quest OnDemand upon authentication. However, if a new ID had to be created user was taken away completely, asked a lot of unrelated questions such as date of birth, and then not brought back to the original site.

If you want your customers to survive your sign-up procedure you need to control the account creation experience – just redirecting them to a third-party site does not work.

Privacy concerns

Even though all Quest OnDemand wanted to know about customers were their Live ID logon names (for example, to be then used as handles for delegation purposes) Live ID in theory holds keys to a lot more data including for example hotmail address book. From the web user interfaces customers could not clearly see that they are not accidentally providing access to their private data and as result did not want to proceed with the delegation.

Using primary ID seems to be a big commitment

Email address is a much smaller commitment for a service sign-up than some sort of credentials you are actively using as your core identity. If I try a service and I don’t like it worst case – the vendor will send me some email from which I will need to unsubscribe. If I share the ID I am actively using it kind of feels like I am committing myself in a bigger way and will not have the flexibility to easily go away, and then maybe come again some other day and so on.

The industry has trained customers to supply email addresses pretty much for any sort of access – now this is what people are expecting to use for sign-ups.

What’s there now?

Starting last Friday, Live ID is gone (obviously with all existing customer profiles and data migrated) and we are back to simple email address and password sign-in process.

The benefit is that although there is indeed yet another password to keep in mind (or to reset every now and then when you forget it), the web site behavior is completely expected and well understood by anyone, and the sign-up process includes way smaller number of steps and is easier to follow.

Is federation dead?

Not at all. There are multiple other cases in which identity federation makes total sense and makes users’ lives easier and solutions more secure. For example, while dropping Live ID, Quest OnDemand still has Active Directory Federation Services (ADFS) authentication option for enterprises federating their local Active Directory with Quest’s cloud. In fact, this is the only way Quest’s own employees (for example, technical support) can log onto Quest OnDemand. In this case, federation has clear advantage because it provides tight access control and ensures that only authorized Quest employees access the service and the access happens under strict corporate control.

There are cases in which federation works great and is the best way to implement user access to your system. There are cases in which it is not. Carefully evaluate your options and find which solutions works best for your customers!

Did you have similar experience on federation either not working or quite opposite solving your problems? If so – please share.

Check out the video here.

Unfortunately most cloud vendors/SaaS-providers still don’t tell enough about the way they protect customer data – which we know is a bad idea.

From that perspective you might find this case study which Microsoft has just posted worth reading: Systems Manager Offers Security-Enhanced, Hosted Solutions with Programming Framework. The case study lists some of the technologies used in Quest OnDemand – Quest Software’s Systems Management as a Service product family.

There’s more to security than just encrypting internet traffic. The case study discusses how latest technology such as Windows Identity Foundation and Active Directory Federation Services 2.0 helped us make sure that customers are always in control of their data, which includes not just protecting data from those who should not have access (including Quest’s own engineers!) to it but also a convenient and secure way to delegate access to those who should.

I hope this helps you get a good overview to one of the approaches to cloud security. Read the case study here.

With these thoughts in mind, I was delighted to find a report by Scott Crawford from Enterprise Management Associates – “The Security Paradox of Cloud: Five Questions for Cloud Providers“.

This is a great report in a sense that it not only talks about that same paradox but also formulates the 5 questions which need to be answered by the cloud vendors to make these happen:

1. “How much visibility do I have into how you manage my risks?”
2. “What risks do your other tenants pose to me… or to you?”
3. “Are your tools and techniques for managing risk mature enough?”
4. “Is my data safe with you?”
5. “How will turning to cloud impact my current approach to management?”

For each of the questions Scott provides a good discussion – so the report is well worth checking out.

Here are a few comments which I had on the paper:

In my opinion, “cloud” is inevitable because it offers better economics than do-it-yourself on-premises approach: think market economy specialization vs. natural household. This does not mean that no IT services will remain on premise but we are most likely up to some kind of hybrid model. How far we go there does depend on the ability by the industry to answer Scott’s questions.

Scott’s notes on how cloud with its separation of duties could also become a more viable security solution are spot on. With proper legal and certification framework cloud approach would let companies split liability risks with the cloud provider – as opposed to having to deal with liability all by themselves. Adhering to retention policies is costly – outsourcing multiyear document/communications retention to Microsoft/Google/etc. and sharing not only storage costs but liability and risks with them is a pretty good deal.

• Certifications (such as SAS 70) are a good step in ensuring better security. Scott seems skeptical about certifications (and rightly so) but these are one of the components of the solution because they provide a vendor-independent common set of standards.
• Publicly disclosed industry-proven identity management, authentication and authorization architectures (such as “Geneva” for example) is another good step – security by obscurity will not cut it here.
• There will probably be a bigger place of encryption/DRM in the picture. These do come at a price though and if the limits are pushed too hard the cloud systems may become useless: not being able to provide valuable functionality without access to data.
• Legal frameworks providing for shared liability.

With all that said, this will not happen overnight. Kids are sick more often than adults, and the cloud industry is still in its infancy so 2009 and 2010 will bring us quite a few outages and security breaches.

Read Scott’s report here.

Technorati Tags:
SaaS, Cloud Computing, Compliance, Analysts, Security
Add to: | Technorati | Digg | del.icio.us | Yahoo | BlinkList | Spurl | reddit | Furl |

A few days ago Google Apps had an issue with some Google Docs became accessible to other Google users beyond the security set on the docs. To quote from Google:

As we noted in the Google Docs Help Forum yesterday, we’ve identified and fixed a bug where a very small percentage of users shared some of their documents inadvertently. The inadvertent sharing was limited to people with whom the document owner, or a collaborator with sharing rights, had previously shared a document… We believe the issue affected less than 0.05% of all documents…

This obviously is not fun, and 0.05% can be a pretty big number of documents and who knows how these got spread across customers. However, what I wonder is whether this is actually an insurance industry rather than just technology opportunity.

Seriously, you install fire alarms, etc. in your house but you probably still insure it against fire (and not, say, live in the middle of a field because houses can burn). Does this make sense?

Tags: business opportunities, Google, Google Apps, SaaS, Security
Add to: | Technorati | Digg | del.icio.us | Yahoo | BlinkList | Spurl | reddit | Furl |

The report is really valuable for anyone either building clouds or cloud-related products, or considering to move sensitive data to a SaaS application.

The key areas they look into are:

• List of typical SaaS applications which have high trust requirements.
• Key security features which such applications should possess.
• Transparency measures which cloud computing/SaaS providers need to implement.

Excellent report: short, to the point, and with material you can use while developing or evaluating SaaS application with trust requirements. Get the report here.