Cloud Security FUD - Worrying

Apparently, according to a Computer Weekly article:

http://www.computerweekly.com/news/2240230281/Cloud-FUD-far-removed-from-realities-finds-research?asrc=EM_MDN_34048363&utm_medium=EM&utm_source=MDN&utm_campaign=20140915_Cloud%20FUD%20far%20removed%20from%20reality,%20finds%20research_

there is a lot of FUD surrounding security problems in the cloud.

Let me start by saying that I believe that there are many good ways in which cloud offerings can be secured.  Some will be inadequate, some will be adequate, some will be very good and some will be so secure that it really should be called a private network and not a cloud.

But this article claims that there should be little concern about security.  But its not a good article to prove the premise, in fact it actually does the opposite.

In particular, this line concerns me:  "only 2% of organisations admitted to experiencing a cloud service-related data security breach".

2% admitted to a problem.  That's 1 in 50 companies.  1 in 50.  To me, this heightens concerns about security, it certainly does nothing to make me comfortable.  Given that many organisations may not want to admit to security breaches in a survey, then the number is probably higher than is declared here.  So is it 1 in 25 companies?  1 in 10?

The survey reported in the article appears to be promoted by the Cloud Industry Forum.  I thought this was a reasonably reputable body.  Is this article and the CIF's lack of concern over 2% of companies experiencing data breaches really doing the industry any good?  Or CIF itsself?

How Will You Cope With A Cloud Disaster?

What happens when a cloud service fails?

What happens when a cloud provider has a disaster?

How does your business continue?

Why does my internal IT cost me so much more than buying a few VMs from a cloud provider?

I've recently read some interesting points on this topic (they are paraphrased below and the authors will not be named), which gives me cause to think about the approaches that businesses are taking to cloud services, and some of the areas which appear to be adding risk to their business for their business critical IT services.  Here are a couple of examples and why they're not correct:

"One of the benefits of cloud is that IT service continuity becomes the problem of the service provider".  No!  This is one of the most concerning statements I've seen recently.  Service continuity is never the problem for the service provider.  It is always the concern of the business consuming that service.  It is possible that the way in which the service continuity is provided is within the remit of the service provider, but the continuity of the service itself is the problem of the consuming business.  Your business must ensure that the right provisions are in place, either through contractual arrangements (guaranteed service level agreements, recovery point objectives, recovery time objectives all with penalties which are commensurate with the business you will be loosing if these are not met) or, your business needs to think about service design as part of adopting cloud. See thoughts further down this article.

"public clouds do not offer disaster recovery".  That's also not strictly true.  By default, most probably don't.  However, many will offer the option to add such services.  Also, if you have an application that can run in multiple sites to provide high availability (HA) facilities, by agreeing with your service provider that they guarantee to run your application in multiple sites, then your HA can become your disaster recovery (DR) approach.  Also, the public cloud could be your DR facility - more later.

So a cloud strategy, just like any other IT strategy, needs back ups and DR plans. To dismiss public cloud as not providing DR is missing some of the options, equally to just assume that the service provider will look after DR is equally problematical. There are many approaches to this, and I'll suggest some below, but this isn't a comprehensive list or guide, its here to provoke some thoughts and some ideas.

By default, public cloud usually does not include DR in the traditional sense. However, by carefully selecting multiple cloud providers for a single business process or a cloud provider who can guarantee your systems will run in multiple sites, DR can be achieved - as long as your application is also designed with multi-site capabilities. In this case, DR is essentially just an extension of your HA approach.

Additionally, cloud can be part of your DR strategy. For example, you can run all your systems in house and upload data and source code up to cloud services on a regular basis. With the right process design and cloud service provider contract you can then invoke your DR by running that code and using that data that is stored in the cloud wherever your cloud provider has the capacity available.

So be careful how you design your service provision.  Think about the options, of which these are some:

- multiple physical locations offered by your service provider (make sure your data is still geographically compatible with relevant regulations, and your applications are designed for multi-site use);
- service provider provisioning of DR processes and facilities.  Make sure the design and contractual arrangements meet the business criticality of the system.  Where contractual penalties are agreed, make sure an hour of penalties equals or exceeds an hour of lost business, and this is maintained as business volumes fluctate;
- choose multiple service providers for the same service on a continuous basis - make sure they don't share data centre facilities;
- choose one service provider to provide the service on an ongoing basis, and another to provide quick burstable capacity for use in a DR situation.  Design processes to ensure that the second service provider has current copies of your systems and regular updates of data, commensurate with your recovery point and recovery time objectives;
- use the cloud as your DR strategy for your in-house systems.  Regular copies of systems and data up to the cloud provider with a contract that allows you to start up your systems very quickly.  Treating the cloud provider as your second "warm" standby data centre is a viable approach.

Make sure you use one of the above, or a similar approach to ensuring your business can continue when there's an IT disaster and make sure that each of the above can meet your security requirements. And test them frequently to make sure whichever approach you choose, actually delivers to the design parameters and service requirements.  Remember that when to invoke, how to invoke and who is responsible for what during invocation is just as important as the IT elements.  Also cover what happens when the disaster is over and you need to return to your regular service provision - getting back to normal can be just as hard or harder than invoking disaster recovery.

When comparing the costs of your internal IT with the cost of buying a few VMs from a cloud provider, remember that you are unlikely to be comparing apples with apples - make sure the capacities, performance and guarantees of up time and recovery time are equal.  Only then will costs of the insurance service provided by most internal IT teams become more apparent.  Its surprising how quickly the cost of a cloud service escalates when you truly match the service levels to existing provision.  This is one of the greatest risks with shadow IT services - they are often not comparable to internal services and are often putting critical business processes at risk.

Or choose to take the risk of course - that's always an option, as some business services are not critical to the business - if you can afford for service to be unavailable for a few days or weeks, then its probably appropriate not to pay for contingency planning up front.

What Are The Top 3 Benefits of Cloud?

 Thanks to linked in user Brian Murphy for raising the following question:

What are the top 3 benefits of cloud computing?

Here are my musings:
The top 3 benefits will vary by customer size, complexity, maturity, market vertical etc.  What do I mean by this?
Well, for an SMB, lower cost may be number 1, but they'll only get that if they buy from public cloud - they won't achieve lower cost if they build a private cloud from scratch until they reach a critical mass..



For a large organisation's dev and test teams, agility, low cost of entry, ability to tear the environment down when they've finished etc., will be a great benefit.  If they're doing that in a public cloud offering, that could well be acceptable for that particular use case.  But for a production environment in the same organisation's highly regulated market place (where regulators are notoriously difficult to pin down when they use the term "adequate"), a private on site solution (cloud or not) could be the most cost effective and / or lowest risk approach to meeting regulatory requirements.

For a large and complex organisation that needs agility, that might be their number 1 benefit, but it doesn't apply if the main business of a large and complex organisation is doing the same business activity over and over again and they're busy refining their processes to eek out every last cent of efficiency.  However, that organisation might choose to sell their super-efficient process as a "cloud" offering to other companies...

And so it goes on.  I wish you luck with your video, but I do find that there are many attempts to simplify "the cloud" that business execs are exposed to (e.g. airline magazines) which really don't cover off the basics of going back to what the organisation needs to achieve and then mapping the right approach specific to their needs, be that public, private, hybrid or no cloud at all.  Missing this fundamental point and doing cloud because an article, video or other source says you should do cloud because its a "good thing" is a mistake.

When Should You Not Go To The Cloud?

This post is in response to a question posed on LinkedIn by Paul Calento Chief Executive Officer at TriVu Media Top:

Disclosure:  I work for Dell - we sell data centre products and services to end user organisations and to cloud / service provider organisations.

There are many factors in the decision to use or not use cloud.  For the purposes of responding to your question, I'm going to assume you are questioning the use of public cloud vs internal provision.

Scale / Cost:
If you are very large enterprise, there is every reason for you to be capable of delivering an internal cloud that rivals or betters an external cloud in terms of performance, cost and security.  So if you have the scale, with the skills, then the potential is there to do something better within your organisation.
We should also consider the scale of individual projects.  For the dev, test, and small scale production, external cloud can make sense. Pay as you grow models at the lower end of the scale are attractive.  However, the "$ per GB" model (as an example) of quick to deploy commodity compute environments are initially very attractive - but because costs scale linearly with consumption, there is the real chance that, at some point, the multiples of unit cost are going to gross up to a total cost that exceeds the costs of providing the service in a more traditional way.  So it makes sense to fully understand what you expect a service to consume in 18 months or 3 years time, when deciding to go external cloud or more traditional route.  You also need to consider that, over time, the cost / benefit model will change through growth, or shrinking of the scale of the service.  So what originally made sense internally might become smaller over time, or less critical to the business and should eventually be farmed out to a commodity cloud provider.  And vice-versa, what initially might've been an experimental service to "see how it goes" could grow into something large scale and upon which you are now spending more than you could provide that service internally.  Typically I don't see much reference to this kind of change over time in the cloud discussion, which is a high risk strategy.
For those organisations with a large investment in existing systems, the business case for ANY change (whether it involves cloud or not) must take into account the value of the existing service provision.  For example, it's likely to be difficult to justify the business case for migrating a service to the cloud, if you've just made a multi-million dollar investment in the existing platform, and that needs to be depreciated over 4 or 5 years.  Similarly, if you have a very large data centre facility - as you migrate services out to the cloud, the unit cost per square metre of data centre space becomes significantly larger for each of those services that remain in the data centre.  So if team A move their service out to the cloud to save 25% on their costs, but it increases the running costs of teams B and C that stay behind by 30% then the holistic business case doesn't stack up.  So be careful about the big picture, not just the individual services.

Control and Risk:
For some, control and security of data is paramount to their business - particularly in heavily regulated environments.  Whilst many public cloud offerings now offer the potential for good security, for some this just isn't enough, as any compromise is potentially ruinous to their business, including the risk of hosting customer data outside appropriate geographic boundaries.  The more a company needs to have an iron-grip on who accesses data, where that data lives, how they can have audit rights to that data and when they need to guarantee physical separation, all of that heavily weighs against a public cloud service.  The economics of cookie-cutter services, shared infrastructure etc. of the public cloud don't stack up as soon as you start to add customization.
I would also suggest, for many companies, that if they put something into an external cloud service then it may be wise to use more than one provider, if that is practical.  This has the benefit of keeping the providers in competition with each other, and provides a measure of protection in the event that one provider ceases to exist, under-performs, over-charges or removes that service from their offerings.

Integration Complexity:
Some organisations are struggling to cope with the complexity of their internal systems and how they all interact with each other, often not having full documentation.  This means they struggle to understand what service impacts will occur when they un-pick old systems, or add in new functionality.  If you then add to that the need to include external connectivity and industry standard APIs, then its not easy.  The cost of change may well exceed the benefits of hooking existing services to new external services.  Requirements such as single customer view, which are required for some regulations, encourages organisations to keep services internal to ensure that the data remains under control and accurate, moving large volumes of data up and down external connections doesn't always make much sense in these situations.

Management:
Many larger companies who have outsourced services (including management of on-premises services) such as networks, data / storage management, some commodity processing applications, have found managing the interfaces to these providers to be complex and onerous.  Getting all these providers to work together for the benefit of the company who is buying the services can be something that needs a great deal of management time and rigorous processes, and that's just when everything is going smoothly.  When there are service issues and those issues cross boundaries then who is at fault and who needs to rectify the issues can be complex to identify and resolve at best, and can end up with long and expensive legal disputes at worst.  Add the potential for multiple cloud service vendors into that mix and you can see how quickly the costs of managing such an environment (and by that I don't just mean the operational costs, but also the risk / cost to customer services and regulatory compliance) could outweigh the expected benefits.

Some of the above issues can be mitigate with a rigorous management approach (which is not happening in the grey IT economy) and/or the right tooling (such as Dell Boomi or Dell Multi-Cloud Manager).  This is why internal IT needs to become the conduit for IT services - so control to meet the organisation's objectives can be maintained whilst ensuring that IT services are provided in the most effective way - internally, private cloud or public cloud.  The correctly balanced mix will be the best solution for many organisations.  One size fits all is not likely to lead to a good res

The First Musing

This blog will be about thoughts that occur to me as I go about my daily role. Currently I work for Dell in the UK, in a mixed infrastructure architecture / design role for our largest global customer organisations. Much of the time I'm working on specific virtualisation / cloud solutions for specific customers or helping them develop their strategic direction. This gives me a good insight into the common challenges I see across a number of customers in different markets, which allows the development of reference architectures that we can take as solutions to many or our customers.

Brief career history, prior to Dell (most recent first):

• Head of x86 Server Infrastructure Architecture, Lloyds Banking Group: 5 year overall infrastructure strategy & Direction; 3 year investment planning and ownership of architecture assets for x86 server, Windows server, VMware and Linux OS; Team of 11 architects; design of VMware platform for bank merger – 1100 host servers. 
• Head of x86 Infrastructure Architecture for HBOSplc – role as above. 
• Head of Infrastructure for Bank of Scotland Corporate Banking 
• Head of IT Audit for Bank of Scotland 
• Several roles in Civil Service IT