[Sam Johnston] Okay, thanks. So, welcome to the Focus Roundtable. What happens if your cloud service provider goes out of business? Focus.com's five-thousand industry experts help millions of professionals make better business and technology decisions by answering questions, pushing research and speaking at events. Visit Focus.com to learn more and become a member today.
Please visit our event page at www.focus.com/events, post and view comments and/or questions that you might have for this event. So to get started, I'm Sam Johnston. I'm Director of Cloud and IT Services at Equinix over here in EMEA, and I'll be your moderator for today. We've brought together some of the top-focused experts in this area to show you on what happens if your provider goes out of business, and what I'll do first is start by giving people, you know, Starting with Raymond Umerley, the CSO at Innovest Systems.
I hope I've pronounced your name right there Raymond.
[Raymond Umerley] Close enough.
[Sam Johnston] Okay, so if you want to start by introducing yourself. And then we'll get on with the show.
[Raymond Umerley] Sure thing. As Sam said, my name is Ray Emerley, I'm currently the Vice President, Chief Security Officer for Innovest. Innovest is a financial services, software services provider. So, hopefully I can provide some perspective about how, you know, we currently protect our clients. And what our clients are looking for as far as safeguarding their data in the case that the provider should go out of business or disappear.
[Sam Johnston] Okay. Thanks, Ray. And next up, we've got Ben Kepes, who's an industry analyst at Diversity Analysis.
[Ben Kepes] Yeah, thanks, Sam. And my name is Ben Kepes. I'm sitting down here in beautiful New Zealand. I'm a cloud computing commentator, analyst, blogger. Talk about the space generally
[Sam Johnston] And then we have a fellow Citrix alumni, Dave Asprey, who is now VP of cloud security at Trend Micro.
[Dave Asprey] Hi everyone. This is Dave. I'm Trend Micro's main security, kind of thought leader, strategy guy when it comes to cloud and virtualization. I'm pretty well involved with the CSA, as well as the Cloud Security Alliance.
[Sam Johnston] Okay. Alright. Thanks Dave. Look, I'll just give you the quick overview of what we're talking about today from the round table page - trusting a cloud service provider with your data also means understanding what happens to that data if your provider goes out of business.
This roundtable will discuss the importance of developing a strategy to prevent data loss in such and event, and the need to define and retain the ownership, understanding the lack of standards in this area requires significant awareness and due diligence on the part of the data owner.
So let's start by working through the questions from from the roundtable. Starting with: what are the questions that a business should be asking of a cloud provider, with regards to data ownership? And if we can run through everybody I guess in that order to give, you know, one or two ideas of questions that companies should be asking of their cloud service provider.
So let's start with Ray.
[Raymond Umerley] I think a lot of what we're going to be talking about here is going to tie into the concept of data ownership. A lot of the ways that I look at kind of equating the comp service model when it comes to your data is the equivalent of a storage shed provider in a lot of ways. So, you go and you rent some storage space, you put your items within that space and then you pay somebody a monthly fee to secure that, insure that.
You know, nobody else gets into that space. Nobody else has access to your items and whatnot. But, at no point in time do you lose control of those items. Those items in that shed still belong to you, ultimately. So, it's the idea of you can not transfer responsibilities for some of the functions around that, but you can't ultimately transfer accountability.
One of the things that's very important when we're talking about controlling the data is making sure the terms of service are very clear about what do you have as far as, you know, rights to your data, you know, ownership of your data? But also what can the provider do with your data as far as, you know, can they use the metadata for marketing purposes or data mining, that kind of thing.
Those are two very important things that should be detailed out in some sort of terms of service, rest delay, when you're working with your provider and shouldn't be overlooked.
[Sam Johnston] Okay Ben?
[Ben Kepes] Yes, I guess there's two things here. The first is data ownership and that's kind of a reasonably simple nut to crack, you know, the fact is that an organization should own their own data and there should be no argument around that.
But, you know the second part of that is something that I noticed that, you know, unless data is in that format, understand the format that allows me to take their data somewhere else, it actually doesn't matter who owns it because it's not usable by anyone other than the incumbent provider and that incumbent provider ceases to exist, then, you know, to put it technically I'm screwed. So, really I think, you know, data ownership is a secretive discussion after open standards and open formats.
[Sam Johnston] Okay and Dave, do you have anything to add?
[Dave Asprey]You know it's not as much about ownership as it is usage rights. So you may maintain ownership of your data, but if the service provider asserts that they have some rights, but not full ownership to the data. That's important to know. And I would also sort of point out Free or freemium business models oftentimes to rely on data ownership or full out license to the data from the cloud provider.
So, those are the ones to be most cause yourself.
[Sam Johnston] Okay, and I could probably decide a lot by saying that, you know this is one of the most contentious areas, if you look at the terms of services of cloud services today. Where they have obtained a license to publish content on behalf of users. You know, these - It's something users are very sensitive about and users aren't actually assigning copyright laws to get down into kind of a bit of legal details.
Now, when actually assigning a license, I think they to be careful not to open a license. They do assign very broad licenses to the providers to use their content on their behalf. But I think that you need to careful about how broad that license is. So, for example, if I instruct the provider to share a document with Joe, Then, obviously, the provider needs a license to be able to do that and they need to attain that license.
That doesn't mean that [xx] unless I specifically ask them to do that as well. That's a little bit tangential to the discussion today, but I think it's nonetheless an important point. So, I thought we would move along and start looking at the different levels of cloud computing or the different layers. You know we've got the infrastructure layer.
Where we talk about raw computers, computing storage, network. Things like Amazon HC2. We've got the platform layer where we start talking about components that might be interesting for a developer, so things like structured storage databases, cues, payment gateways, this kind of a thing.
And then finally new applications like your Google apps and your Microsoft Office Suites sales. So how about we start at the bottom of the stack and say, look, you know, what are the challenges of the infrastructure layer and then As a secondary part of it, what are the, what are the solutions? So let's go back again and start with Ray.
[Raymond Umerley] All right. The good part is, is the infrastructure's service, in my opinion, and others of the panelists may disagree a little bit, It's probably the simplest of the, of the three to really solve. Primarily because you're going to dealing with echo benz point known formats so that the oracle or sequel on the database ends or some sort of structured or relational database that you're working in but you've probably chosen to install and operate.
So that's the easiest one of the three in my opinion to work with. You have a number of different options here. It can be anything here from data replication, to a different provider, or to your own, you know, internal environment so if you want to set up a co-location or something like that. You could also do exports of those data or backups of those databases, and have those send all like our basis.
That particular model to me isn't going to be as much as what we're going to talk about down the road. It's probably going to be like the software service as far as challenges. That's what I have to add on those.
[Sam Johnston] Okay, Ben.
[Ben Kepes] Yeah, yeah, I agree. Similarly, I concur with the point we've heard before, really.
[Dave Asprey] This is Dave, I think that we have a real easy solution there which is like a policy based encryption key management in the cloud. If you're worried about it, or even if you're not worried one of the well known best practices is to encrypt your data. Which you can easily do with infrastructure as a service.
So whether or not your infrastructure as a service company asserts that they have a right to your data they can't have that data if they don't have the encryption key to it, it doesn't matter.
[Sam Johnston] Okay. So that means example might be storing data in Amazon S3 using Jungle Disk, and encrypting the data before you put it in there. So the effect things cause that you're only relying on them for, sorry, for availability of data. You can verify the integrity by checking signatures and of course you can guarantee the confidentiality by maintaining your own keys.
[Dave Asprey] That's [xx]. There are open questions though about key management in the Cloud. A lot of Cloud instances that I've seen end up using a password with a password file that can be cracked actually using EC2, or they're storing certificates that give them access to a key server that's somewhere else, but if you can copy the machine image in the cloud, you might lose that confidentiality.
So, it becomes a matter of hosting your keys in a secure manner outside in such a way that a stolen virtual machine image from the cloud can't be used to access your keys.
[Sam Johnston] All right. In one of the models that we've seen, that we're starting to see now, is a hardware device with a hardware security module like the ones we used to use in the net scalers that you would keep premise, and that would be kind of the gatekeeper to your cloud. And that makes sense, of course, in lower level isn't just quite right.
You know the simple end of the stack. And how about when we start moving up the stack and we start looking at things like applications in the Cloud. If I have to pull up an application on App Engine or Zeus or Conchords of the Amazon web service's APR's. You know, how does that differ from the relatively simple infrastructure.
Maybe we can start. We try again.
[Raymond Umerley] It's going in order thing. We might just have to start jumping in over top of each other in a sec. Yeah, I think that once we start getting in the platform, the application I think that's where we're going to get into complications because then it's not just about the data any longer, it's about the applications that are accessing the data.
That are reading the data and essentially are enabling that data that actually be useful. So what we run into is, for example, I've been dealing with this since with service provider model. So one of the things that we've gotten used to is the concept of not only a data escrow but a source code escrow.
if you have one without the other it's kind of worthless.
You can provide somebody the application but if they don't have the data then what good does that do? And if you provide them with the data but it's not a reasonable format, they don't have the application to translate it, you know, the same problem.
So, that's really the key. Making sure not only, then at that point, that you have the ability to recover the data but it's also the ability of reconstructing those applications or those IEE's or those environments that you're using to actually to make use of it. And that's something that usually people kind of fall down a lot.
They realize that data is important but they don't necessarily fully grasp the dynamic of how important those applications are as well.
Yeah and this is just one of the issues that we found fairly late in the day in establishing the open initiative, was that, it's one thing to say, OK we've got a full open interfaces so I can programatically access my data in a transparent and format into what I'll call the open office XML problem, which is, you know, if I have [xx] implementations which, talk in XML and we can argue that there's none of those today, but, let's say that we do, and then you know, one of them goes away or tries to bring it in house or move it to another provider who doesn't support those formats.
Then what are my options? And the solution that we came up with, which was promoted by Simon Maudly was to actually require one of the intolerable implementations actually be open source which would allow you to, if you see an open cloud product or service, it would allow you to use that in the confidence.
That, in the end, if you need to export your data, there is also an implementation somewhere that you can install locally. So I think that's a very important point and a very serious one. At the end of the day you could conceive of a situation where a cloud provider will use symmetric encryption to encrypt the files so that you could download them but then they'd be the only ones who could read them.
To take it to the extreme so. I think that's an important point.
[Sam Johnston] Ben or Dave, do you have anything to add?
[Ben Kepes] Yeah, I mean, this speaks to my point about that two-step thing that, you know, having the data available is one thing. Being able to use it is what's important. And especially at an application level where you've actually got end users to that and are trying to do stuff. I like the concept of both data and application escrow to make sure that the provider goes back, that there's still some continuity there, but I think in terms of the concept around ensuring there is something that can be installed on-premise still be.
At the end of the day we rapidly got up against, I guess, some fundamentals of businesses and that is that how much can they actually make open, and how much can they actually provide to users before they put at risk their own potential to actually derive some revenue from their product and that's kind of a difficult space to navigate.
[Raymond Umerley] Can I chime in? I know I'm skipping over Dave for a second if Dave doesn't mind. Ben brings up a really great point; it's something that we've run into, so at the end of the day as we moved from ASP into software as a service. Our source code and our application is our intellectual property and it's really our life's blood.
If it was out in the open and other people will start using it. We do have some serious competitors especially in the financial services base. Yeah, that would be a lot of loss for revenue and other things for us. So, what we found is, especially around the source code escrow, it's critical for a lot of our clients to have that assurance they could then run this application in house because in many cases this is their system of record has direct impact on their financial statements.
But in turn we've had arguments internally, as well as some externally, about how open can we make those escrow accounts, and what type of testing can be done. So for example, if you set up an escrow with let's say Iron Mountain for source code escrow. You know they've been doing that for quite sometime.
Well Iron Mountain has a great number of things that they'll do as far as validating the escrow deposits. They'll also offer to do escrow testing to make sure that everything is, so you can actually go about the environments. Well, then you kind of get into this hairy kind of area where how much of this are you releasing to Iron Mountain?
And what is the exposure there? And then how much of this are you releasing to the customers? So, one of the things that you run into is on the testing end. Because, let's face it, data and application escrow is great, but if you're not validating that it actually works or testing that actually works but you're not really going to accomplish anything at the end of the day.
On the testing, we've actually had to start bringing in our customers now to our location and building the application out for the escrow because we're worried about the exposure of our source code outside of our four walls. So, it is a very real concern and I think as long as you still have commercial, off the shelf products or commercial off the shelf software and service providers, for example.
You're never going to get fully away from that, as much as we'd want to see like an open standard at the bottom. At the end of the day, people are still going to tie things back to revenue models and intellectual property, and I think it's gonna be a very difficult thing to overcome.
[Sam Johnston] OK, so I think that that's a good, let's slip another question in here, and say, is escrow, which I guess I will define as the cloud provider, preemptively, as in prior to failure storing their data to a trusted third party, in order that after the failure when they're long gone, [xx] to that source code to run it yourself.
I would say that, depending I think on the application, I mean, if it's a simple enclosed, contained application, like a web application or something like that then it's fine. But if you start getting into more complex systems, like if I were to start talking about, source code escrow in the context of the Google app, for example.
You know, in order to of the Google products, you would of course need to run the entire Google platform which, you know, in itself is something that I think only Google really can do.
So is it a viable option. I think that kind of depends. I was a customer and I saw source code escrow. Yeah, I'm not sure without actually having seen it running and I get that's where the third party service is, testing an building sound come in. Then I'd probably be pretty hesitant to rely on that.
Does anybody have any thoughts about that?
[Dave Asprey] Yeah, this is Dave. I actually think that source code escrow for any but kind of the simpler web apps, fast type of things, it's not really that viable. It's a way of solving a problem from long ago, but the example of Google apps is really straight forward. It's actually infrastructure plus apps that makes any of the complex, you know, Salesforce.com is
another example, any of the complex things like that. You're not really going to get source code that you can use. What you should ask for, though, is you should ask for a data dictionary and either some sort of logs that you can use to reconstruct your data that are of course secured, or just having API access.
For a lot of these services, could enable pretty simplistic back-up and sort of data recreation things. As well as there is obviously like export things you can do, but if you get some sort of normalized data with the data dictionary, you should be able to input that in any other app that you could purchase without needing code escrow.
I mean, code escrow is a pretty high standard task provider too, and task providers don't write licensable code that's treated the same way as an actual software would do. There are big QA differences.
[Sam Johnston] Ben, do you have anything to add?
[Ben Kepes] Yeah, you know, I absolutely agree to your example about Google apps. Having that on escrow would achieve absolutely nothing, and more and more, it's almost to the point that simple sort of set back that also could work with, doesn't really good, because everything is becoming more complex. But, you know, what do you do at the end of the day; what is the solution if you haven't got to the provider's gonna be around?
If you haven't got escrow, I guess it comes down to open standards, open formats and the ability to at least; the export base of work is high enough, as high a level of information around it or business process around it, that can be meaningful in another provider's system.
[Raymond Umerley] In fact, to your point, I doubt that most SAS providers publish a data dictionary that's detailed enough, or any sort of XML descriptors for their data that you could use in export.
But if you're a particularly large enterprise looking at moving something strategic to a sass offering, it might behoove you to ask for that the dictionary so that then if you do need to export all the data from that provider. You can easily map that to another SAS provider or to an in house app, so you can keep running.
I think that would be a minimum requirement for me if I was working as a CIO right now.
[Sam Johnston] That's how ultimately what you want to look for is a thriving ecosystem built around a standard that is interoperable and complete. And as I guess, is there one of the concerns that I have, is that we'll see and particularly that if we go back to the structural layout, there's the risk that your word document of the cloud forming where there's one or a small number of vendors who part of maintain control of, you know, for example, the virtual machine English format.
How do we think the best way is for us to to achieve standards, in terms that we followed the leader, in terms of following Amazon, doing it by way of an open process. Do we, what is the best approach to actually getting these standards in place?
[Ben Kepes] Well, and the other thing is, that's right Sam, and at an infrastructure level that's complex enough, but you look at an application level, you know, I spend a lot of time looking at cloud-based accounting and financial products, VIP products, and imagine trying to come up with some kind of open standard that had a common declaration for what an invoice information might look like, you know, a specific invoice information.
I mean, there's just so many complexities when you get up and look up applications, that creating a standard is a big, big ask.
[Sam Johnston] Let's look at this specific example though, at the application layer, and let's look at social network, so We look at something like Facebook. The ability to export a zip file containing data, and then on Google side when you look at Google Plus - the ability to export data there.
Now, from what I've seen of these types, at least on the Facebook side (I haven't been able to examine the Google side yet), but you know, information like, for example, unique identifiers for users - you need public identifiers like email and so on - are actually not present in that information, and I believe they actually provide a text file, containing one full name per line, which is certainly not enough for you go and import data into another service.
So what are we...what do we expect? I mean, it's like a lot of these providers are saying, "Ok, we've got, you know, you can take your data out. You can liberate your data" but, how much of that data, how complete do we need to that data to be? Do I need to have it clean, as a background [xx]? Ok, so fire away.
[Ben Kepes] Yeah, I think you're right, Sam, and I think the first thing we're working on the perfect example because at the end of the day, the value of a social network is in those connections. You know the value for a high level set application is in the integrations and the connections without their applications.
So just taking out the data on it's own, and even taking out the data that you can actually work with is again secondary to actually taking out the connections and so, you know. I can export all of my social graph from Facebook. But if my social graph is all around connections with 25,000 or so of my best friends that are there on Facebook, then any sort of export is kind of meaningless without taking them with me.
[Dave Asprey] You also have to look at the motivation of the cloud provider. In this case Facebook wouldn't want you to export all of that information. Because if so you could recreate a Facebook network if you got a good size number of users to export their data and put it on your service, you'd get the interconnections.
It would be remarkably easy for another company to replicate their core value. But, you know, there are companies like Tweet Back-up who use the Twitter API to give you a full back-up of your tweets and let you view it online. It's a free service. It's a pretty good example of how something like can work.
But for complex apps, like ERP for instance, we have Oasis and the XML standards bodies who've defined huge numbers of transactions in industry-specific document formats. And if you're going with an ERP system that's designed for mining, or forestry, or oil or something. There is a format for much of your data already.
You should be able to get useful data out of the system so you can recreate your books or recreate a transaction log using just a data dictionary and using XML formats. [Raymond Umerley] Now I think the one thing I would add to this is echoing everything Ben and David have said. But it's also back to the original point of how do we get those standards in place?
I think it's ultimately going to be in the interest of the consumers and the customers to start requiring and requesting. can those standards be used by the providers. Let's face it, if industry has taught us anything, we're going to have 17 different standards bodies driven by 17,000 different people on the individuals and companies and motives and financial articles, whatever.
At the end of the day, if the consumers themselves don't put the onus on the providers to actually start implementing standards like this and giving them a wage to get the data out in a structured format and a readable format, we're never going to make any headway.
So it's one of those things where it almost sounds like a cop out to say it's on the onus of a cloud user to do this, but really that's the only people that are going to be able to drive change because, as an industry itself, a lot of providers have a great idea and will try to do these things in order to get any sort of movement, it has to be the people that are actually utilizing the services to make that progress.
[Sam Johnston] Okay for the number of providers claiming to have the ability to export data and data liberation and this sort of thing. Are the technical and non barriers to actually obtain that information. So as an example, it's one thing for me to be "okay, you can download your data but if it's not available over [xx]".
There's no point having no programmatic access to transfer of data and equally, so there's no point having programmatic access to uptake data. So in the case, if I want to go out on Facebook, I have to go into my Facebook settings and follow through the pages and click on the download link. And in some cases I've even captured which deliberately make it difficult for you do that programatically.
What are the barriers and what can we do about that?
[Dave Asprey] I think the barriers are mostly business models, where there is no incentive. For many of these companies to truly make the data useful, because they want you to stick with their site. So, there will always be extra clicks and extra things like that unless, perhaps people decided they're willing to pay for the service.
I know I would pay right now if there was some company that would back up my LinkedIn profile, my Facebook, my G+, my Twitter, and all the other stuff I use just onto AWS in an encrypted volume that I can get to whenever I wanted to so we need those cloud providers accidentally delete your account.
Or someone hacks your Facebook password using Malware on your PC, which is a really common thing. You can lose all of your Facebook connections, even if you have thousands and thousands of them, because Facebook's default behavior is just to assign say your business page to one of your users who can then do what they want.
So having all that backup would be enormously valuable. I'd paid for the backup service, but I'm not sure any of those companies would really want me to have it.
[Raymond Umerley] Right. I think I agree with that and I think you'll, technical so you've mentioned the business models. One of the non-technical problems of course, is when you're the most open, you're the most prime to some competitor coming along and.
in the data, especially in the case of social networks. And I think that, in fact, Google have got a very elegant solution to that problem, in that they have, you know, in the same way that there's reciprocity for visas, they came up with the idea of reciprocity for API's.
So, know that basically said, well look, if Facebook won't export to us, then we won't export to Facebook. And I think that's an incredibly powerful incentive for the companies like this that do things on behalf of the user.
[Dave Asprey] The great model there is ISP peering. So, you know, I'll trade bandwidth with you if you'll trade bandwidth with me. So there's a notion of data peering that can emerge here that can be pretty compelling.
[Sam Johnston] No it's true. OK imagine appearing points, let's move on a bit, we do have a standards table in a few weeks.
So, let's focus on what happens if the provider fails. Let's discuss what we can reasonably expect of Cloud providers. to maintain data prior to failure. To give an example we have this, an example that I like to use, is this magnolia setup, which was like a social bookmarking site like delicious.
Uh, that failed all of a sudden. You know, when you have a catastrophic failure it's usually followed very quickly by a business failure and in this case it was revealed that the server was running on a couple of Mac minis and an X server or two, so I guess there's that transparency thing which we'll get to in a second but, what can we expect of them in terms of maintaining your data?
It's assumed that the cloud providers they used renovation and geographically diverse redundancy. But some of you already know that what I was doing at Google was backing up data to tape. So, what's a reasonable level of service to expect from a cloud provider in that area?
[Ben Kepes] I think I will jump in here. I have to say that we really need another cloud provider to go down because the Magnolia example is getting a bit long in the tooth for all of us. But, aside from that, at the end of day you need to step back and look at some of the business perspectives on this. And at the end of the day, if you pay peanuts, you get monkeys.
To a certain a certain extent, if you're not paying for service, and you know we live in this age where anyone can be an entrepreneur, anyone can start something up from the garage and they can spin up a couple of pieces and whatever and do things As consumers and especially as business consumers, we need to be realistic about our expectations and we can't put missing critical stuff (whatever mission critical means) on services that just simply haven't got the scale or the funding or the monetization path to be able to provide that that mission criticality.
[Raymond Umerley] Yeah, I think that is a big part of it. A lot of what we're discussing here we keep talking about. And Dave put it, and I love it, the freemium surfaces. You know the Googles, and the Facebooks, and those kind of things. My expectations for those kinds of services as opposed to say a sales force or something where I'm actually paying some hard cash and there's probably some agreements in place there, you know, it's night and day.
It's the difference between buying a hot dog at the cart and going to a four-star restaurant. You know, I'm going to expect a certain level of quality at one that that I'm not going to get at the other. It would be naive of me to expect the same level of quality of both.
So, particularly for this discussion, I think it's kind of important that we do differentiate that there are the freemium Services that are out there which, in my opinion, are always kind of a use at your own risk and those are the Facebooks the social networking and whatnot. And then there's going to be the ones that are going to be the more business critical applications where you're going to need to make sure that they have API's and ways to get to the data. And export functionality and those kind of things. As part of the service that you're paying for because, at the end of the day, if you're paying for it, it's probably a lot more critical to you than your Facebook.
[Sam Johnston] Okay, so Ben, I will give you another example. I'm just having a look here at Wikipedia at Nirvanix. And these guys had a history as a, I believe, a media group of some variety and had more failures before full branching out into the Nirvanix. I'm kind of hesitant to draw more from that because in March I believe there was actually another provider who, another cloud provider, who actually lost a sense.
I think that it was one of the European ones and then lost a bunch of data. And of course recently this week we've seen we've seen some problems with EDS, where certain blocks have been lost. I'm kind of being more inclined to say well look, these guys have been through it. They've had a large scale failure and yet they say lightening doesn't strike the same place twice.
But you know I don't know how valid of a statement that is. You know, what do you guys think? Is it once somebody has had a large scale failure, is that a sign to move somewhere else? Or is that not necessarily a problem.
[Dave Asprey] Actually, it's kind of funny because these outages have been going on since the dawn of hosting back at Exodus Communications when I was there.
And the solution is pretty straight forward, with infrastructure as a service and things where you control the infrastructure is you have two sides from two different providers and you do real time replication patient and that is what some of the very top properties on the internet do today, in order to insulate themselves from that.
But when you go with Sass you can't do that. So, by definition then, you have to trust that your SASS provider's doing it. And most SASS providers aren't going with that extreme extreme 569s, especially if they're not charging for their service.
[Ben Kepes] At the end of the day, to your question about whether one outage is the end of a relationship, at the end of the day, how many times has; just to use an example. How many times has Amazon had disasters? At the end of the day, what happened a couple of a days ago in Europe. I'm sure there will be a post-mortem about and a lot will come out.
But, to my mind, it's kind of inexcusable when one's availability line goes down, bring it up, take the other two down with it. Does that mean we will never use Amazon again? Clearly it doesn't. At the end of the day, we're, cloud is making sense Happy niche. This stuff is new. And take a step back, and the availability be keep even with Amazon even with their highly publicized outshares is significantly greater than if you would had those couple of megamonies sitting on the ideas.
[Raymond Umerley] I'm sorry, I was going to say using the Amazon example. One, the European outage recently is probably the perfect analogy for the whole "if lightning strikes twice". But going back to, just look at the outage, what, four or five months ago on the east coast when the Virginia area basically went offline.
The whole idea about Chrome and still being new, and a lot of this still coming into maturity.
[Dave Asprey] We learned so much more about how availability zones work and I think a lot of the customers learned about how availablility zones work from that outage, and hopefully are better prepared now for subsequent outages. So whether or not the provider is learning lessons, which, from a business standpoint they have to.
Because otherwise they're not going to be a provider for very long. At least the customers, and this probably more of a soft spot for me in some ways, but the customers are learning. And they're understanding that they need to start thinking about disaster recovery. They need to start thinking about designing for failure.
And a lot of things that they probably didn't consider before. They thought "I put it in the Cloud. It's going to be there all the time. It's highly available, and they've taken care of it for me". I think now that these people are starting to, the naivety that we, that we were talking about earlier is kind of washing away a little bit, and people are starting to understand that just because I put it here doesn't mean that it's always going to be there and always going to be available to me, and I need to take some extra assurances to kind of protect myself.
[Sam Johnston] Ok, so in terms of extra assurances, that brings us to the last of the questions that were posed in the round table,which was: what are the options potentially available to the data owner to safe guard against the disappearing with the data?
[Dave Asprey] I think one thing.
[Ben Kepes] It comes down to due diligence, you know, at the end of the day you know Magnolia was a bit of a gamble. It was a couple of guys or a guy, with a couple of Mac minis under their desk. Amazon, despite its recent outages, were a sales force, you know, with it's issues or whatever. A big, publicly listed, robust and profitable, you know, organization.
And it comes down to a simple business due diligence in my mind. Somebody else want to jump in there?
[Raymond Umerley] I wanted to give Dave the chance because I heard he's ready to talk to her so.
[Dave Asprey] That's alright. I think you covered it.
[Raymond Umerley] Yeah, I want to echo the due diligence thing, and this kind of goes back to a lot of this is going to be about transparency of the providers and a grant that the level of transparency you get is directly proportional to the amount of money that you pay. You talk to some they scream transparency but then they use the old Kimono adage that they don't want to open too much.
And then you get ones that are completely transparent, but generally that equates to the number of dollar signs that you're throwing at them. But the due diligence is important. Understanding what they're doing as far as, you know safe guarding your data, where your data' goes, where your your data's stored, what format it's in.
What are your options for retrieving that data? Both during the life cycle of your relationship and you know, postmortem when that relationship goes away. A lot of people don't necessarily do enough due diligence on that end to understand that, you know . What really happens to my data, you know from data distraction standpoint?
Like, if I left the provider. What if it's the provider leaving me but I'm leaving the provider? You know, how long is my data going to be there? What methods do they go about to remove that data and we can talk about everything from ephemeral storage to what not. There still has to be at least a knowledge from the consumer what exactly is going on in the operations team to ensure that yeah you're protected against both what we're talking here but other usage of your data.
[Sam Johnston] So this was one of the things that we did while I was at Google with video actually went through, you can actually find this video on YouTube, but it goes through everything from the Google legal data sense, so as the physical security it shows things like, you know, they chose things like the tape libraries.
They [xx] shredding of hard drives. So they've really - when I saw that they actually - I saw the video before it was released and when I actually saw it in public on YouTube, you know, I couldn't believe that we were giving out some information about operations. But maybe that something that the providers should do more of is give us more of a view.
So the question then is: what level of transparency can we reasonably expect? Cloud providers in advance of any failure.
[Dave Asprey] There's some technologies, there's some technologies we haven't really talked about yet that I see a lot, a lot of chatter about. And one is homomorphic encryption which allows a source writer to do analysis of your data while keeping the data encrypted. So that it can actually do logical operations.
IBM apparently invented it. And it's coming closer to commercialization. And the other more near term is tokenization. Where you run something locally on your PC or your tablet that changes whatever it is that you're putting into say sales force or some other SAS application so that the souce provider can't use it.
But when you see it on your screen it looks correct. There are limitations to that approach but some companies are using that in production today as I understand it.
[Raymond Umerley] So, two things I wanna bring up real quick. As far as the level of transparency I expect, once again that kinda It goes back to the criticality of the application that I'm using, or the provider I'm using.
What, how do they fit into my business model? How do they impact me financially? If they're a critical service provider, they're providing all of my infrastructure service, or it's a huge software to service application like Salesforce is critical for for our sales team as well as our CRM, I'm going to expect a greater level of transparency probably to the level of understanding everything from what's your instant response policy, to how are you encrypting the data, transmission if you even are, how do I get the data out, et cetera?
A lot of companies are obviously going to be hesitant to do that, because we fall under this approach that security by obscurity model, by if I tell you too much, you'll find holes. Well I'm not asking you for specific versions on your devices or firmware levels or anything like that, I just want to know from an architectural standpoint - am I protected, are you following best practices, can I look at this design and at least does it make sense to me, as a security professional?
And I understand that not everybody has that kind of level of knowledge but does it make sense to me that, at the end of the day my data is going to be secure and it's going to be highly available? The other thing I do want to point out real quick. I just saw a tweet that Breeola put up about that this coming down to service agreements, with the service providers.
And renewing the contracts. Be very, very careful about putting too much onus into service level agreements, and to contracts, and those kind of things. A lot of times those provisions while they will give you some recourse at the end of the day. They will never, ever, ever cover the impact of lost data as far as the soft costs time, reputation, loss of work, loss of knowledge.
Those things can't necessarily be equated to a dollar value that ties back to how much service you're supposed to have or four nines or anything like that. So be very careful about putting too much stock into those. Especially if you're using it as a substitution for due diligence.
[Sam Johnston] Look I'll take that one step further.
I think that the agreements in general in a Cloud environment are a complete and utter waste of time. So it's one thing to have like a service level object, but at the end of the day if the cloud service fails, and remember we are talking about incredibly cheap services here, we are talking on the order of, for a full communication, collaboration suite like Google apps, you're talking about 50 US dollars per year, which is in the realm of one-tenth of the cost of an equivalent mailbox on a traditional legacy system.
So, when you've got a knowledge worker, or all of your knowledge workers who've been down for a day and come back and give you one day out of 365 worth of fifty dollars. That's a lot of money. So I think one, it hurts the provider, because what little income they services they lose. And two, it does absolutely nothing to you.
If you want to best risk strategy to cloud, is to assign the risk to somebody else by taking out insurance against it. And I think that basically applies to everything we discussed today. And the end of the day as well. Another thing I would add to that is is that it comes most of you people yourselves, You know what I mean?
We've got almost a hundred data centers now and people are deploying stuff, of course you do lose many benefits of cloud computing in terms of multiple infinity and so on. But if it's that important to you, then inevitably cost is not the thing you're necessarily looking for.
Does anyone have anything to add. We are going to be getting pretty close to time. So maybe another one or two questions. Anything to add to that? All right, so let's move on and now let's assume that the apocalypse happened. And what should you do if you wake up and your providers are gone. You know, what are these practices then?
Right to start this since you're at the top of the list.
[Raymond Umerley] Great, I got that one by default. Really at that point if your provider disappears, this needs to be something that gets addressed at a higher business lever. It can't just be the infrastructure guy, can't just be the security guys that are trying to figure this out. You need to get your legal people involved, your contract people involved, start looking at what your service agreements do state as much as, you know, I don't have a lot of onus in this but let's face it that a service agreement is different than what we're necessarily talking about here.
So you can start looking into what your contractual recourses are. Is there some sort of escrow situation that you then can call upon? You know, who do you need to contact? What do you need to start looking at? That needs to be done in very near future, like twenty-four to forty-eight hours, like start rolling the bar on that because what generally happens in so you need to be careful.
Depending on what happened to the company or to the fund that is going out of business. And the service provider that you're using. If it's something where, that there's potential that the equipment is being liquidated. If there's potential that it's being repossessed. That time. Anything could be happening in a very quick period of time.
You need to make sure that you've gotten your legal recourse and your people involved absolutely as soon as possible, as soon as you're aware of this. So if there is something going on you can at least do some sort of injunction. Stop that process from happening before your data is irreparably lost, because that is a very real threat.
If the servers walk out the door, you may never get your data back.
[Dave Asprey] This has actually happened. It was a while ago by a company called Pilot Networks that specialized in secure web hosting for enterprises went out of business with no warning, fired all of their employees and locked the doors and was basically moving the servers out the back door. I think they were located somewhere in the Bay Area, Pleasanton maybe.
And yeah, a lot of customers just lost their data and the servers weren't even necessarily owned at that time by the cloud provider. So that's the equivalent of an airplane hitting a data center. So you should have a plan that says what if my cloud provider goes down and is just unreachable? And that is why you have disaster recovery.
Why you have at a minimum data backup like we talked about at the beginning of the conversation. You need to be ready for that to happen. SLAs won't help there.
[Raymond Umerley] Yeah, and I would go a step further with that, Dave. and say that this should be, if you are using cloud providers for critical services this should be a part of your DRP. This should be documented. There should be procedures in place. There should be no question of if X goes down or is someway becomes unavailable, and there is no rhyme or reason to it, here's what we need to start doing because time is of the essence here.
But this should really be, if cloud is part of your critical infrastructure, it needs to be included in your DRP, not just about human safety and resources, those are all very important, but this needs to be specified in there. There needs to be procedures to follow, and it needs to become part of your DNA.
[Dave Asprey] Amen. Very good advice.
[Sam Johnston] Okay so we've got about five, eight minutes left. Maybe we can talk for a minute about the best practices, you know, given the situation we're in today, how many standards, there's not a great deal of transparency. There's obviously initiatives like Cloudwork working on that. And given the level of security of cloud providers today, you know, what are the best practices for minimizing the risk of that happening to you today?
Now, I guess what I'm saying.
[Ben Kepes] You go.
[Sam Johnston] Yeah, go on. I was going to say that, I would start by saying that. All right, Ben, off you go.
[Ben Kepes] Sorry. Without wanting to carry on a similar theme that I've been hacking on for a long time, it comes down to due diligence, at the end of the day shutting the stable door after the horse has bolted, to use a misquote, is no good for anyone, you know, if you haven't done your due diligence, if you haven't ascertained The, you know, the real situation behind the provider then, you know, before the event, long before the event then you're kind of screwed.
I mean if we look at, you know on Twitter there has been a bit of discussion in the past ten minutes around what more Cloud providers have gone down over the past three or four years. And if you look at the names, you know if you look at them all they are all inverted commerce. Start ups, one man bands, you know one or two people.
You know you don't have a situation where a SalSports or an Amazon or one of these well funded lateral organizations goes down. So at the end of the day I think it comes down to simply, you know. If you pay peanuts, you get monkeys. If you're paying very little money and you're going with an unproven, untested, unknown start-up then You know there might be some missing benefits to that in terms of agility and innovation but there's some significant risks.
And without doing a thorough due diligence and being honest around what that means, then you're kind of asking for problems to arise.
[Sam Johnston] So, that's one of the non-technical. Go on.
[Raymond Umerley] I just wanted to chime in and say three things. One I'm going to steal that peanuts and monkeys thing, and use that quite liberally. I'm just warning you right now. The other thing is echoing the due diligence and actually going through and tying back to the transparency the provider is very important.
But I think that the other thing that we fall into a lot, we're in an age now where a lot of what we're talking about with information security what we're talking about with recovery and continuity, we're becoming more of a datacentric model. It has to be because right now the only thing we tend to own anymore is the data.
With that said, we still have a fundamental problem where we classically fall down, trying to put value to that data. And if you notice a lot of the controls we put in place, a lot of the due diligence is directly proportional to what we value. So we do a lot around human safety, and the safety of our work force.
We do a lot around physical security. And we always have put a lot around information security per se, but a lot of times its the network and host and that kind of thing. But we need to start doing a better job in classifying the data, how important that data is to our business and then accordingly performing that level of due diligence to make sure that data is secure.
Just because it's being put into a cloud provider, don't take it for granted that its always going to be, it's always going to be available, always going to be secure. If you value that and that's critical to your business's intellectual property, it's all in your customer contacts.
Whatever it is, if it's critical to your operation that needs to be treated as such, and that ties in to how much due diligence you do. Don't just do a half-assed glance and look at a bunch of network charts or look at a flow diagram and go, " OK, this works". You need to do a deep dive, you need to get your hands dirty and you need to completely understand what you're doing there.
[Sam Johnston] Well I think that's all part of cloud governance and I think that one of the very first steps in using cloud is to identify the most appropriate tasks, if you can, even you're going with a high level strategy and say ultimately we're going to use cloud for everything, it probably makes sense to choose some tactical services to deploy immediately, and be measured about how you do it and, in particular, to keep an eye out for the shadow IT component which hasn't come up throughout this, which is where you've got your [xx] sales source and so on.
And you don't even know that they're doing that. So you need to work out how to discover that by way of surveys, by looking at property logs. You know, count what they're using to work out whether that's an acceptable level of risk, bearing in mind that if they are using it, it's probably because your existing systems aren't up to scratch.
So yeah, I definitely think that using Cloud where it's most appropriate is important If you're going to stick with legacy, some part of it, maybe you'll see previously until appreciating you know whatever mainframe equipment you've got and so on. And then of course in the middle of the road you've got the environment as well.
I think that welll see some pretty impressive hybrid Cloud architectures standing equipment, and also off premise hosted equipment and then also public Cloud services as well. So yeah, I'd say Cloud service is very important.
Anything you want to add Dave?
[Dave Asprey] I think that you guys covered that really well.
[Sam Johnston] So then how about the point of view and non-technical points? What do we think it is in terms of maintaining an online real time copy of your data.
[Dave Asprey] I think you almost have to choose to go with infrastructure as a service if you're really serious about it. Because even if you're backing up your data from a self ring. Unless there's an equivalent place where you can move that data very quickly you're going to have a very significant amount of down time.
So infrastructure as a service gives you more control of your data. And it gives you more control of your infrastructure. Which means you can choose the number of nine you want. And you can plan for geographic Those are adages. But if you go with a SAS provider, you have an awful lot of trust there, and not enough transparency.
I would say.
[Sam Johnston] It's funny, you know. I wish we had some more time to get into this. We only have a minute or two left. I would probably would have actually had the opposite problem with infrastructure of course is that You're stuck on a machine and that machine failed, where as, you know, basically you, with that kind application you build the resilience, I'm sorry, the reliability into the hardware.
You look at this like [xx] a commodity cloud that is built on commodity equipment. And it is well-known, and accepted, and understood that you have to design failure. So if you're building a cloud architecture that's fine,but then if you look at SAS application like, again, like the Google Apps example this is built on a global platform, that is designed to tolerate your individual machine.
Racks, rows, entire data centers. You know its basically a bulletproof system. I I appreciate what you mean, but I'd probably argue something slightly different.
[Dave Asprey] Your point in Google using high availability infrastructure is very well taken. They are probably the best of the high availability SASS architectures out there. But most SASS providers haven't reached that level yet. But fair point.
[Raymond Umerley] I agree. That's true. They're not, they're certainly not perfect, either.
[Dave Asprey] We're pretty good.
I said but they're pretty darn good.
[Sam Johnston] Alright, so we're up on time now, I would also just say keeping a live backup, you can get an ATI which has got push notes and so on is so you can keep a real live copy, whether they're a party provider in a different facility or on premises. I think that technically under the best premise. Thanks everybody for participating in the round table.
All the questions you posted on the event page on Focus, so the conversation can live on. All questions we weren't able to address will also be posted to the discussion. And thanks again for our experts for the lively and engaging conversation.
Recent Activity