SaaS Cloud Computing - The Security Question

Earlier today I attended a session at Softworld about Cloud Computing. This had a panel of users and vendors (providers). What was clear when they contradicted each other was that even these "experts" don't know all they need to know about cloud computing - and I mean "need to know", if they (and you) are to gain the benefits without excessive pain at some stage.

That's not a criticism of these people, as the cloud is a relatively new fangled thing. However for those of us who have been using SaaS (Software as a Service) applications in front line business for over ten years, we have had our parts bitten, and know first hand what matters.

One of the comments that remained unchallenged was on the matter of security, in terms of access. This was along the lines of that old chestnut "We've been using internet banking for years, so SaaS is safe." We've also been using SaaS ervices such as Hotmail, and every now and again it and similar systems get hacked.

The difference? Like GoogleMail and many others, Hotmail relies only on a userid and password, where the userid is public knowledge - typically the email address. Many business SaaS systems similarly only use a userid and password. At the other end of the spectrum, the banks have at least one extra level of security, such as random digits from a PIN or second password, and/or the need for a physical device. Chalk and cheese.

So what does a confidential application like payroll use? Dennis Keeling gave the opening keynote address at Softworld this morning. Turns out he is an HR and payroll specialist, as part of a broad knowledge of the packaged software market. He tells me that for larger organisations, remote access to payroll services is typically by userid and password, but always in combination with a "private cloud" secure internet pipe. Without that, he would expect some additional level of security, such as random digits from a pin number (like some of the banks do).

For smaller businesses, here are a number of internet payroll services. These talk about various security methods, such as 128-bit SSL (secure socket layer) encryption, as is used by the banks. Nonetheless.here are some incidents of web payroll systems being hacked, to try and make immediate fraudulent electronic payments.

In an ordinary accounting system, there is often an equivalent mechanism for supplier and staff expenses payments. Good access security in these systems is therefore vital.

IN CONCLUSION

A simple user id and password is not as secure as the internet banking systems, nor as secure as the better payroll systems.

There will be many applications in a business where a userid and password combination is adequate, given the low potential consequences of unauthorised access. But there will also be applications, such as Accounts Payable, where some additional level of access security is a must.

For more "myth busting", see last week's article "SaaS Cloud Computing - The Hype, The Truth and The Wardrobe"

.

SaaS Cloud Computing – Is It Worth The Hype?

As with every other generation of computing, SaaS (Software as a Service) cloud computing is portrayed as wonderful. Best thing since sliced bread. Or at least since silicon chips.

But does it live up to the hype?

It’s clear that there are substantial benefits with SaaS cloud computing. We looked at some of them before, including better remote access, potentially better backup and disaster recovery, and typically quicker to start implementation (though is very similar thereafter).

But is it all a bed of roses? With other types of computing  it’s only by addressing the pitfalls and risks that the benefits can be properly realised. Is SaaS cloud computing any different?

Of course not. Let’s look at what cloud computing really is.

WHAT IS SaaS? 

SaaS is actually “outsourced hosting of packaged software, provided as a service”:

• “Outsourced” means handing control of day to day activities to a third party, with all the benefits and drawbacks that brings, such as needing a clear exit path
• “Hosting” means data will be held somewhere else, potentially overseas. Many SaaS systems are hosted by a company other then the software provider.
• “Packaged software” means it has all the benefits and disadvantages of on-premise packaged software, and has similar characteristics to on-premise software of equivalent complexity
• "Provided as a service" means you do not have to pay for the IT infrastructure, you just pay for use of the system (in one of a number of ways)

There are other forms of cloud computing if you want to develop your own apps and/or host your own apps.

WHAT DOES THIS MEAN?

Firstly it is worth properly understanding  the pros and cons of SaaS cloud before subscribing for any service. That way you can avoid unsuitable providers, and put the right internal practices in place

Secondly don't believe the hype. Statements such as "Security is not an issue" and "Data centre location is not an issue" should be taken with a massive pinch of salt. Next week we'll look at statements like these and the reality behind them.

Thirdly think very carefully about adopting the DiY shortcuts many cloud providers suggest. Change management, project management, data conversion, and many other aspects of an implementation are similar if not identical between SaaS and on-premise solutions:

• Selection Process for SaaS - How Different from On-Premise?
• Implementation Process for SaaS - How Different from On-Premise?

Lastly, if in doubt ask. We're happy to help.

.

Cloud Computing - BIGGER BENEFITS, BIGGER ....

…OPPORTUNITIES. You probably already know that the cloud SaaS (Software as a Service) can provide tremendous benefits to your business. But as Intellect the computing trade body says “While the SaaS model offers significant advantages over on-premise, it does carry potential risks that must also be considered” 


Realistically you’ll only be able to reap the benefits of SaaS on an ongoing basis if the risks are managed down to an acceptable level. Otherwise Sod’s Law says something will go dramatically wrong sooner or later. The consequences are grave embarrassment or major business problems.  Or both.

The good news is that risk management can now be done adequately in all areas, as outlined below. Some risks are very unlikely, but when they happen can be catastrophic. I know the pain - I had to mothball a business in 2006 that was dependent on a cloud-based trading system that I could no longer trust. These days that simply shouldn’t be necessary, working with the right cloud suppliers and with a professional approach from both supplier and user.

I’ve just had a long chat with a senior member of the cloud system vendor community (name and address supplied), focusing on SaaS. He had taken exception to the headline I’d used in a previous article “BIG BENEFITS, BIG RISKS”. Both of us have many years experience in all aspects of on-premise and cloud apps, and we basically agreed on everything – as long as I replaced “BIG RISKS” with “SIGNIFICANT RISKS”. So I dropped it from the headline altogether, as you’ll see above.

With him approaching as a vendor, and me as a user, we specifically agreed:

1. Many people talk of a “hybrid” set of apps using both on-premise and cloud solutions. However there’s no good technical or commercial reason today why it shouldn’t be possible for all apps to be cloud based in any organisation large or small. It’s just a matter of vendor/app quality, plus a suitable approach to using SaaS by the user
2. Given the cost and practical advantages of SaaS, it should be a no-brainer for user organisations to use SaaS solutions for virtually any app, regardless of sensitivity. However buyers need to know which vendors are up to scratch, and also how to handle risks which the vendor can’t handle, such as continuity of user’s telecoms access to the internet
3. Currently “best practice” within the cloud industry does not deliver that vision, and there is significant scope for improvement
4. A lot of purchasers are currently quite rightly wary of SaaS. Personally, given the variety in the quality of vendors out there, I have been and remain “Positive But Cautious”
5. For some apps, the benefits far outweigh the disadvantages and risks. CRM (Customer Relationship Management) is a good example in some situations. Businesses that are using spreadsheets and paper records for customer details probably hold their data less securely than they would  in the cloud, so in that respect would benefit immediately
6. However the key issue for purchasers is loss of control, especially for apps such as accounting that are already (apparently) well-controlled in-house. This is not dissimilar to any outsourcing arrangement, and people have been outsourcing apps like accounting for years. [I’ve worked with the outsourced shared service centre for the BBC, for example, which involved outsourcing not only the system but the whole back office financial processing. I’ve also worked with plenty of business people whose business is their baby, and outsourcing is not something they consider lightly.]
7. Buyers typically have a fear of the unknown – because they simply don’t have the experience of SaaS, or where they have identified a risk and aren’t aware of a practical solution
8. We both would like to see the SaaS industry generally at a “best practice” level that makes buying SaaS a no-brainer, subject to due diligence on the vendor to confirm
9. Vendors need to do better communicating how they handle the risks (as well as understanding and dealing with them better in the first place)
10. If vendors want to make it easy for people to buy, they should also help to educate the user community, and thereby overcome their FUD (Fear, Uncertainty and Doubt). Consultancies such as Camwells can also help, hence this article.

Many people are now familiar with the benefits of cloud SaaS, as vendors are especially good at highlighting them. Key benefits include worldwide access, faster implementation,  typically better disaster recovery, and lower costs. More benefits are in the original Hot Air or Business Reality article.

But as a user, my main concern is that I’ll come in one morning and find one or more of the apps unavailable for some reason. If the app is business critical, that will be a problem, potentially major. Potentially catastrophic. Let’s look at some of the main issues and how to manage them: (see sister article for full details, as this is just a summary)


User Issue - Internet Access

In the user’s red corner is internet access. I’ve quoted Andy Scott before as saying “Loss of Internet = loss of information systems. PERIOD.” Not a comfortable or useful position to be in if your business is reliant on email and the internet to function, especially using cloud applications.

It's worth having at least two methods of getting internet access, choosing from:

1. BT or another broadband providers sharing  BT's cabling, bearing in mind that using two such providers doesn't help. A private connection rather than public provision is preferred, subject to cost
2. Virgin cable. 
3. The new MiFi units, provided you have signal coverage and enough WiFi-enabled laptops and PCs in the office

User Issue – Supplier Resilience

What if the supplier goes out of business? Not necessarily the SaaS vendor, or even the hosting company they use. But are there any other businesses in-between? Stories are coming in of middlemen not paying their hosting bills, and end-users being cut-off with little or no notice.

To avoid problems, first of all you need to carry out due diligence on the vendor chain. Thereafter you can monitor each company in the chain for financial delinquency.

You can also use two separate vendors, with separate vendor chains:

• Perhaps by splitting clients into two groups. 
• Have a second system configured up and ready to go, with a quick data conversion written and tested. You just have to ensure that a data extract is done regularly, at least daily, to facilitate the transfer.

Running two systems lets you choose which is better and possibly replace one with a third if that later proves better.



Vendor Management

It’s worth checking that the management of the SaaS vendor has plenty of experience of software apps. Vendors that do their own hosting, and are in fact principally hosting companies, will not necessarily understand the app issues. In the rush to get releases to market, will they bypass essential beta testing, for example? That’s my experience.


Vendors – Business Continuity

Professional hosting companies know all too well about multi-site redundancy, database mirroring, physical security, disaster recovery and all the other techniques to keep systems running 24x7 without the risk of data loss.

Whilst this cannot be taken for granted without due diligence, this is usually well handled. Certainly it is one of the big benefits of SaaS compared to on-premise, where all too often backup, recovery and disaster recovery arrangements are less than ideal – or non-existent.


Vendors – Access Security

I’ve heard it said that “We’ve been using eBanking systems for years, so security isn’t an issue for SaaS” or words to that effect.

Apples and pears. The eBanking systems have multi-level access that even at its simplest is username and password plus at least one more aspect, such as a PIN, a second password, or a physical card reader. Biometrics such as retina recognition may not be that far off.

For SaaS, in many cases username and password is likely to be sufficient. But does the SaaS vendor offer something more sophisticated for apps you feel need it?


Vendors – Database Encryption & Partitioning

We’re used to sending spreadsheets containing highly confidential or valuable data through internet-based email systems, with no encryption. Or we put data onto dongles and laptops, and then leave them on trains. Madness! But it needn’t be that way.

There are SaaS providers that encrypt the flow of data to and from the user’s device, and also store the data encrypted. This can be done in two ways, depending on performance needs:

• Full encryption – for example for secure data rooms
• Encryption of the wording and definitions, but leave the numbers unencrypted (as they make no sense without labels) – such as for business planning and accounting

In database structure, SaaS systems tend to work in one of two ways:

• Sometimes: Each user’s data is in a separate database
• More commonly: All users (or a significant number) have data in one shared database. This means every input, enquiry and reporting program must reliably only give a user access to that entity’s data. Sod’s Law says that if it can go wrong, it will go wrong, however careful the vendor’s programmers are. Imagine getting a report with all the other users’ data in it, knowing that they can all see yours!

There are also performance disadvantages in having one large database instead of several smaller ones, depending how they are distributed across the servers. Vendors that have dedicated databases, or offer that option, are inherently better.

The key is to understand what you will be buying, taking into account the next topic, which is inter-related.


Vendors – New Releases

New software releases are completely different with SaaS compared to on-premise.

On-premise software is typically updated no more than once a year, perhaps with some extra bug fixes in-between. This is for two reasons

• Distribution of the software via some type of physical disk is a major exercise, although in recent years this has increasingly been done via a datalink
• Every user’s installation is different, and each release may have to be tested in 10, 20 or more different environments.

SaaS systems are far easier:

• There’s only one central system to test
• The vendor can see directly how the software is being used (or how he thinks it is being used)
• Releases can be made more frequently, at a time that has little or no impact on the userbase
• These smaller releases are easier to test
• Users don’t have to bother about upgrades, and keeping on the latest release is marketed as a major benefit of SaaS
• Lower release costs translate into lower software and support fees, another benefit

However users should very carefully understand how upgrades are done as part of the procurement process:

• Do they have a “beta testing” process? Can you take part? Traditional software development involves a small number of real customers trialing new releases. This will find practical issues which the author’s programmers couldn’t be expected to foresee.
• Beta testing also helps to trap new bugs which inevitably creep into any new piece of software, before they go live. The more testers the better. Yes fixes in live SaaS production systems can be made quickly and easily, but that could be too late.
• When do upgrades take place? Many business processes have peaks and troughs. There are times that events or deadlines mean you want no changes to systems, so there is no confusion to staff, and no risk of anything going wrong.
• Can you control the timing of releases?

It was this issue over upgrades that led me to have to drop a SaaS system and, with no credible alternative, close the business that was using it.

Whilst it is rare these days to have an app where there is only one affordable vendor, it is still a major hassle to change systems. A vendor that offers beta testing is therefore highly preferable for any critical applications.

The other issue is timing. Having everybody on the same release makes support so much easier and cheaper. That’s good news for users, assuming it is reflected in lower rental costs. However would it not be possible to have two systems with the old and new releases for a short while, maybe 3 weeks or months? Then:

• Users could decide when best suits them to upgrade
• Users could avoid upgrading until issues found by testing or other live users have been fixed

Talking to a US vendor this week he said “If you want that it will be $25,000”  Prohibitive for a smaller company, but good value for a larger one.

But upgrade flexibility, using just two versions of the software, ought to be a standard offering, albeit as a “gold” version of the service. There has to be technical approaches that deliver this result at little if any extra cost to the vendor or user. Until it is standard, watch out for those vendors that offer upgrade flexibility. They are also more likely to offer better-segregated databases, as the two aspects are inter-related.


Other Issues and Initiatives

I have also been involved with many on-premise systems over the years. Running business-critical systems with reasonable user numbers, I’ve found that we needed to do a number of things (in addition to backup and recovery, which was inter-related):

• For a new software release we didn’t just have to test new software, we needed to understand what new data fields had been introduced that needed to be populated, how existing incomplete sale and purchase transactions would be handled, and revise user procedures where necessary. This needed a separate data partition into which a copy of the live data could be copied to test with the new software
• There were also times when we needed to try out something new in the live system, so set up a separate copy to trial on the live software
• There was also user training. This needed a copy of the latest software (live or in test), but with a dummy set of data.

So we ran four databases (live, trial, train and test) with two software versions, different data sets and facilities to copy data from one to another. Any vendor that doesn’t provide that for business-critical systems of any complexity is not providing what we found was needed. Currently this is not a standard offering in the SaaS market. Some vendors will be prepared to do it for a fee, but not all.

The more proactive vendors are actually going a step further. They are looking at apps in modules that you buy like apps in an AppStore. This requires different database and system designs, and therefore might require a total re-write. This is a golden opportunity to incorporate these other user requirements, where necessary changing the underlying database to one where licensing costs are not prohibitive to this vision..



Other Issues

I haven’t had chance to cover every issue, such as inter-app integration and Data Protection Act constraints. The DPA is an area which is likely to be changing within the time horizon of using a system purchased today, so it’s worth thinking ahead. Further details are in earlier articles


Conclusion


Today “best practice” in the cloud SAaS industry is good enough for non-critical apps, but on the whole the apps are not fit for business-critical situations. Nonetheless a few notable vendors are providing systems that are suitable, and they are leading the way.

User organisations therefore need to approach the use of cloud SaaS apps with some caution, and consider the vendor options carefully. Users also need to be aware that there is much they need to do themselves to cover risks that the vendors cannot do for them.

But with the right vendor and the right approach to cloud SaaS computing, it should be possible to move all apps into the cloud to unlock the substantial practical and cost benefits.

Cloud Computing - On The Rocks?

Having just found a place in the UK which has neither broadband nor cable nor 3G connections to the internet, it set me thinking ...

Firstly what a great place for a holiday, literally getting away from it all!

Secondly not the best place to run an internet business. Nor to rely on the internet for staff or any form of mobile services when people are in the area - and there are plenty more places without fast internet around the wilder parts of the UK.

Thirdly what's it like when a business loses internet and email access for a week, a fortnight, a month? I've previously looked at ways of avoiding dependency on one method of internet access, and the availability of multi-user MiFi access devices. After all, there are several cases of BT lines being out of action for 10 days or more, as I experienced first-hand.

Overcoming Cloud Provider Problems

But what if there's a problem with the provider at the other end? One commentator wrote a few weeks ago "There has NEVER been a documented case of catastrophic data loss with a cloud service." The comment came across as "it hasn't happened, so it won't happen". Nieve? Whilst cloud providers may have always (up to now) been able to recover from backups in the event of data loss due to internal malfunction, there's going to be a first time. After all, there;s the old saying "Past Success Does Not Guarantee Future Performance". And what about a cloud provider going out of business?

There was after all the tiny matter of the demise of Exodus Communications which entered Chapter 11 bankruptcy in 2001. At one point over half of all internet traffic went through its systems, serving as it did he likes of Google, eBay, Yahoo!, PayPal, BestBuy, Weather Channel, Merrill Lynch, American Airlines, Microsoft, Hotmail, Virgin Mobile and O2 Plc from some 46 data centres (sorry centers). To be fair it was bought a couple of months later with probably little or no data loss to its customers. But it could have been much different.

It also highlights that outsourcing IT systems to cloud providers doesn't involve just one company. Word reaches me that a reseller has gone out of business, and the hosting company behind it has shut off access by the end-users to their systems and data. I wonder how many of those customers even knew who the hosting company was, let alone checked them out in advance?

So what can be done? There are three key steps forward:

1. "Due diligence" on each provider in the supply chain for each cloud service. Here are some suggestions from a cloud advocate. These need to be continually applied as the supply chain changes.
2. Making sure you have up-to-date copies of your data and a contingency plan
   
3. Avoiding undue reliance on one provider for each application area.
   

Duplicating systems such as CRM or ecommerce may be rather tricky, time-consuming and could be significantly more expensive. But is it possible at a reasonable cost to have one part of the business on one system, and another part on another system? Then it is possible to have a plan to switch the whole business onto one system in the event of any problems with the other.
What price a good night's sleep?

In any case do comment if you know of any real life examples of cloud data being lost- whether due to bankruptcy, system failure, security breaches or any other reason.

.

Cloud Computing - Summary of Recent Articles

The articles on Cloud Computing have recently covered the following topics:

1. MiFi as Internet Access Contingency Option
2. Internet Access is Everything
3. Why Not For Everyone?
4. Hot Air or Business Reality? - BIG BENEFITS , BIG RISKS
   

I hope you find the articles interesting and useful. By helping you cut cut costs and boost revenues, I hope you also find them above all profitable!

Cloud Computing - Hot Air or Business Reality?

Cloud computing is BIG BENEFITS, BIG RISKS. Is use of the cloud living on a wing and a prayer? Or is the cloud business-ready?

See recent article Hot Air or Business Reality?

.

Cloud Computing – Benefits vs Pitfalls

or

?

Cloud computing has been around for 10 years at least, under the guise of ASP (Application Service Provision) and SaaS (Software As A Service).

In some areas, such as CRM (customer relationship management) it has taken off big time. Infrastructure and services in the cloud such as eMail are becoming increasingly popular. In other areas, such as financial software, take-up is less common. Why?

The key is the balance of benefits to the pitfalls and risks. That assessment will differ by application. Is it core and/or business-critical? It is also dependent on users’ attitude towards identifying and accepting those pitfalls. Or whether users are prepared to wait for in-house systems (be they packaged or bespoke) when cloud applications are immediately available. Perhaps sales directors are inherently more prepared (and driven) to use cloud applications than finance directors!

So what are the key benefits and pitfalls to consider?

Key Benefits

Cloud applications provide several key benefits, which include:

1. Functionality can be shared from any location with an internet connection. This allows remote access from multiple sites, by mobile workers, and collaboration with third parties (including customers and suppliers)
2. Functionality is available that would be completely unaffordable if it had to be run in-house.
3. Otherwise functionality can be available at a lower cost
4. There is no need for the cost (and headcount) of specialist internal resources to maintain the systems, other than basic end-user administration
5. Users only need a compatible web browser on their PC or mobile device
   
6. Services can be up and running in hours or days, not months, by short-cutting the procurement approval and acquisition process
7. The cloud is scalable. A sudden, temporary or ongoing increase in activity can usually be quickly accommodated.
8. Regular upgrades provide new functionality more quickly, without the hassle of installing them
9. Backup and disaster recovery is handled automatically
   
10. Cash flow advantage. Payment is usually made periodically, rather than all up front

Key Pitfalls

On-premise software is not without risks, and these need to be managed. Indeed good cloud systems can address some of those risks.

However there are new pitfalls and risks with cloud computing. These need to be mitigated to an acceptable level if cloud computing is to be a viable option for a specific application. Let’s look at the cloud situation, and compare it to on-premise, to see what to consider when assessing cloud applications and specific offerings:

1. Cloud applications as packaged software
2. Providing internet access to the data
3. Cloud computing as an outsourcing arrangement

Cloud applications as packaged software

The software running in cloud applications is packaged software i.e. standard functions used by a number of different user groups. However using a package in the cloud is different from running one in-house:

• Upgrades: Usually applications are on a “multi-tenant” shared basis, with no option to opt-out of a new release (With on-premise, users often wait to hear if there are any issues with a new release). How often are upgrades planned? Released at sensible times? Will you get a heads-up on changes, such as may affect user procedures? Is there an opportunity to assess and pre-test a new release with a copy of your own configuration and data (and feedback any problems before release)?
• Integration: Integration with other cloud or in-house applications may be more difficult – is this needed and available?
• Configuration: Packaged software usually has a number of configuration options. Will the rush to implement in the cloud bypass the usual help from a specialist, and not produce available benefits? Or raise the risk of a high-speed mess?
• Customisation: If you expect to customise the software now or later, then this is not usually possible with cloud applications, though worth asking
  

Providing internet access to the system

Many organizations allow internet access to their own on-premise systems. Allowing internet access to cloud systems is in principle not much different, but.

• Availability: Internet access is not universally available around the world, or even around the UK. The cloud is only practical if access speed is adequate for everyone that needs it.
• Loss of availability: Internet access can be cut (in some cases literally!). Contingency plans are essential, using 3G services and/or alternative premises
• Access: With on-premise systems there tends to be two-level control – access onto the network and access to specific applications. Internet banking software always has multi-level access control, using additional passwords and physical devices. Is a simple user id and password enough for your application?
• Leavers and transferors: For on-premise software, many users will not have remote access. With a cloud they all do. Are your procedures tight enough?

Cloud computing is an outsourcing arrangement

Outsourcing the IT systems has been common in the corporate world for some time. The use of cloud computing is very similar. Here are some of the issues:

• Trust: Is the cloud provider inherently trust-worthy? Do they promote security, performance and availability as part of their sales process?
• Data visibility: Data is held by the outsourced provider. Does it need to be encrypted, so no-one there can see it? (and potentially be more secure than holding it in-house).
• Access to data: Is it logged and auditable? Is this needed?
  
• Physical security: Are the data centres sufficiently secure?
• Location: Is the data only stored in Europe? If not, are the arrangements acceptable from a Data Protection and compliance perspective (such as the US Patriot Act)?
• Recovery: Are the backup and recovery arrangements adequate? Can they be trusted, at least as much as you could trust internal systems?
• Short of cash?: What if your business goes under, or struggles to pay the fees?
• Loss of service: Lower costs and deferred payment puts more pressure on the cloud supplier. What would happen if the provider went out of business? Or decided to drop the service, perhaps after acquisition? Do they offer a contingency plan?
• Data porting: Can you get your own copy of the data, in a form that could be imported into another application?
• Contingency plan: What other contingency plans can you make yourself?

IN CONCLUSION

It is clear that cloud computing can provide significant practical and cost benefits over on-premise. Cloud systems can reduce some of the risks of on-premise systems. But there are new pitfalls with the cloud which need to be mitigated to acceptable levels for a specific application.

Where that is possible, cloud computing can be a great way to operate. Otherwise, on-premise may be the only acceptable approach.

There are a number of other considerations and solutions, which there isn't chance to include in this article. Do contact me if you would like to discuss the issues, specific situations, or would like to review your approach to cloud computing.