PANEL: How to Secure Data in the Cloud - Is Encryption Enough?

Okay, so maybe we should start with any panel discussion. Could you please introduce yourselves and state what your cloud and affiliation with the industry is?

Okay, so I'm Mike Small, I'm a senior analyst with KuppingerCole and I've spent 15 years researching cloud security. Yes, my name is Sadrick, I'm part of the cidaas management team, we're a cloud identity and access management provider, so we offer a security solution and on the other side we have to tackle security every day.

Right, Ingo Schubert, field CTO from RSA, 23 years at RSA and I started as the system engineer for the cryptographic toolkits that RSA had at that time. We no longer have that, but I have a cryptographic and PKI background.

Hi, I'm Jerry Rembeck, responsible for cloud and security technology for EMEA and APJ regions at Rubrik. Okay, awesome.

So yeah, just as a reminder, the original subject of this panel is how to secure data in the cloud. Is encryption enough?

Well, obviously the easy way would be to say no, encryption isn't enough. Thank you, goodbye. But let's do it in a more difficult way and say so yes, obviously encryption isn't enough. We have heard and seen so many scenarios where encryption can be easily just walked around and as we've heard so many times, most attackers just log in and work normally. So where do you start tackling all those issues? So for example, the obvious number one threat is ransomware. Ransomware doesn't care about encryption, just destroys your data anyway. How would you tackle that issue?

And again, maybe let's start from the right. Well, so encryption is like a hammer and a hammer is good if you have a nail. And so the place to start is to understand what data you actually have. And if you don't have an understanding of your data, you're not going to know what to do with it. And the second thing is access to that data. The sensitivity determines the access. And so identity and access management is one of the critical areas.

Then if you want to prevent unauthorized access, you want to look at encryption and then you have to think of all the other things to do with resilience by backing it and being able to recover it. So if you will, there's a multi-step plan, perhaps.

Yeah, I think to tackle it in general, I think the multi-step plan is one thing. What we also have in all the cases, there's no easy answer to ransomware or any security threat. It's always a multi-layer approach, how you protect any security scenario, be it ransomware, be it anything else. If there would be an easier answer, we would all implement the same thing and it would be solved. That would be great. I would be happy about that. But I think it's a multi-layered approach.

It starts with encryption on one side, it starts with access on the other side, but it also starts with proper disaster recovery plans. So on our side, what we implement on our side is basically a multi-layer approach and security that hands on ransomware, but also other things where we start to control the exit on the one side, encrypt, intransit, unrest, all that have proper detection mechanisms in place and then also proper disaster recovery or disaster plans in place, I would say.

Yeah, I think especially for ransomware now, encryption doesn't help against ransomware, right? It does not. Ransomware doesn't care if it encrypts clear data or if it encrypts encrypted data. It becomes unavailable to you, which is what counts.

So yeah, encryption is not the right tool for that. I mean, yeah, it's a hammer, but in this case, that's not a nail and neither a screw that you can just hammer in. In this case, an intelligent backup solution and recovery plan is what is better suited. It detects that, hey, there are too many files which changed immediately, so that might be an attack, there might be a ransomware encrypting files. This is then the right tool. Encryption itself, in this case, is more the tool, the hammer that is used by the attacker, right?

Yeah, and if I can add one thing to that, you know, of course, the answer is no to that question, but I love the question when I got the invite for the panel because three years ago, I was talking to a customer and I was explaining everything about ransomware attacks and their vulnerabilities and that was a see-saw that Libby said, but we encrypt everything, so we should be fine. That was three years ago.

I'm glad that was the last person that ever spoke those words, but we now know that this is real and the threat of encryption and ransomware, it's probably likely it will happen to you, maybe in a small form, maybe in a big form, but you need to take it a step further and be resilient, right? Make sure that you're ready for it, that you have your plans, that you know how to respond. Just a quick reminder, I mean, ransomware does encrypt your data, so you might end up on the wrong end and you would have to decrypt your own data.

So, to avoid that, yes, obviously disaster recovery is an important part of the scenario, but should it be like the beginning of your strategy, the end? Are there any other priorities you have to probably start considering before or after the disaster recovery? And kind of going back to your imagined scenario, Ingo, what if your backups are down with the rest of the cloud?

Yeah, so, of course, if everything is in the cloud and the cloud is unavailable and there's no recovery, you have an issue. In this case, that needs to be taken into consideration as well in your overall plans, that the recovery part, at least, should be mirrored on premise together with everything else, potentially.

But yes, that's something where, again, encryption is used against you, not for you. So, yeah, recovery plan does include, you know, planning around what happens if that recovery system or that service I use is unavailable, absolutely. And by the way, yeah, so, of course, if everything's working, my cloud-based backup solution should use encryption, of course, to encrypt my data. But then again, that in itself is not protecting against ransomware.

Yeah, I think in regard to disaster recovery, a proper plan is needed and also training the plan. Because you're in a disaster, it's like a chaos. If something like that happens, no one is like sitting there, okay, what did we do? What do we need to do? Let's have a quick look all up in panic.

So, before that, I think the most important thing is to have a proper plan, to have the proper training. And that's not only for ransomware.

It's, I think, for many cases, you have to, all the security mechanisms that you have to have in place, you need to train them or live them, at least. And afterwards, obviously, that's also part of the plan. What do you need to do afterwards? That might be to verify if all your backups are not compromised. And you just, two weeks later, get out of the backup again, recovered ransomware.

So, basically, there are many steps afterwards. And that's what you need to consider in disaster recovery plan. And that's also training.

So, the plan of your disaster recovery setup should cover preparation, follow up on that, and also how you train that. And then it's just basically the plan itself in the incident, it's a smaller part, the overall setup, I think, is more complicated. And that's what you need to live and train.

Yes, well, I think this session was started with an introduction by the young lady over there, Eleni, who talked about resilience. And what all of these discussion has been about is about resilience. And you defined it as being the ability to recover quickly from unexpected and unwanted events. And that actually can involve both architectural perspectives, that you can architect systems to be more resilient, like you were describing in with your RSA thing. And you can also have plans, which can help you to accelerate the approach.

And you really need to take a wider view of resilience, than just simply sort of being able to say, I've got a backup, a backup is part of a potential way of getting resilience. But look at the architectures that Eleni has been describing for the past several conferences to help you with that area.

Yeah, I think it's important to realize that your backup, especially in the case of ransomware attacks, backups are one of the primary targets that they're trying to get to. Because once you lose your backups, you know, they know that your, you know, your options are very limited. So it is a primary target, you need things like immutability, account separation, to have your backup safe, even if everything else goes down, all your admin accounts are compromised, and everything is broken, that your backups are stored somewhere safely, because they will go after them.

Yeah, first priority. And the backup process.

Yeah, especially if you're running, you know, many companies are running the same backup procedures and software for over 20 years. If that's you, it's probably the right time to start looking at those processes and software. Right.

Well, even when the business is, as usual, there is no ransomware, you don't need to think about backups, you're just working with your data, you're just using your business apps. And your CTO has promised you that everything is always encrypted. But is it? Probably not, because encryption in use, for example, is still an open research academic subject. We've heard a lot of homomorphic encryption, confidential computing, and so on. What's your opinion on those technologies?

Oh, it's a big question there. First of all, I think the one thing you have to consider, if you have a cloud provider, and the cloud provider promises, I always encrypt data. If they use encrypted hard drives, they're not lying. Right. But that's probably like, yeah, on database level, file system level, application level, the data is not in clear text.

So, not really useful. So, it's like, where do you actually protect, where you apply encryption is important. Not just that you encrypt, but where.

Yes, we have transport encryption, but of course, like I encrypt on, again, hard drive, file system, database, application layer, maybe end-to-end at the client itself. The higher up you go, the more complex it gets, the more expensive usually it gets.

And so, that's something to keep in mind. Like, you know, where do you encrypt?

Then, of course, the whole key management, there's a whole can of worms on its own. Like, how do you do proper key management? Does your cloud provider that you use, if you're actually providing cloud services, use one key for everybody? Technically, that's encrypting. Yeah. And you never rotate that key. But if you do, probably, you should have like, you know, tenant-specific keys, maybe, you know, database-specific keys and so on.

So, I think, you know, and you often see that in offerings and websites, yeah, we encrypt data. It's like, yeah, that's almost meaningless.

It's like, everybody does that, right? It's like brushing your teeth, washing your hands. That's like basic stuff. It's how you do it. And I think this is where there are really differences. And more exotic things like homomorphic encryption, they are nice on paper.

I mean, they're like from the 80s, where you can actually, you know, add encrypted data and, you know, it's fine. But there's a reason why we're not seeing this right now.

Yes, a lot of access spreadsheets are just adding up numbers, but there are plenty of access spreadsheets with just not just adding up numbers, where homomorphic encryption don't work. And fully homomorphic encryption is relatively new. And then the question is like, yeah, maybe you solve something with homomorphic encryption, but the actual protection of the homomorphic encryption is lower than classical encryption. So you might actually solve one problem and introduce another. Yeah. So that's the other thing to keep in mind.

So it's not something that can be solved in a panel, like, you know, in 50 minutes. Yeah. And I think also what you outlined, the costing perspective, it's not it, you have a certain number of, I would call it budget, but resources, what you can invest into security. And you basically, you can never solve 100%. That's also what you outlined, right? You will never achieve that. So basically you should think about all your use case and then define proper protection mechanisms, be it in encryption, be it in any other use case, and then figure out what to do and how to protect that.

And then you can see, okay, if I introduce whatever encryption mechanism for my data and rest, that gives me 80% protection. And then I can do 10% more with investing like two times the budget, but I can invest or increase the security by even 15% by just spending the same amount again. So it's more like the balance between usage or benefit and the costing and the resource itself, because we are also a software product company. I can tell you, you have a certain number of budget resources, timing and all that. And you need to, the most important thing is to invest that most efficiently.

And that helps you not increase the best encryption or best authentication or whatever. It's the efficiency, which basically protects you best. What is the risk? That is the question. And the different approaches to encryption deal with different perspectives of risk. And there are a lot of things, the cloud service providers, as you say, will say, we encrypt the data. So that's good. If somebody steals a drive from the cloud service provider, your data is protected, but it doesn't protect against other risks.

If your concern is going to be that the cloud service provider or a government is going to intervene to demand your data, if they have the keys, then they can give you that data. Some give you, bring your own key encryption with hardware security managers, which again is good, but it doesn't necessarily protect the data while it's being processed. Are you really worried if it's being processed? Are you prepared to pay for homomorphic? I don't know, but there are other solutions which involve encryption, for example, enclaves.

And within Europe, the ENISA pseudonymization solutions are considered to be adequate to protect against some of those things. So again, it comes back to what is the problem you're trying to solve? And what is the price that you're prepared to pay in order to solve that problem?

Yeah, I mean, the one thing I would add to that is that utilize tools like DSPM, posture management, where you can actually verify that all your data, your tables, your file systems, et cetera, are indeed encrypting because we do a lot of pilots and tests with that. And there are always too many surprises on that one system that was forgotten or that one database that was a copy of a copy of a copy. There's data floating around in most every environment that was, oops, forgot that one. I think that's an excellent point.

There's a lot of, a lot of data sort of migrates into the development environment and it shouldn't, but it doesn't. It's so easy. Because it's good data. This is what you want to test against. The copy of yesterday's production.

Yeah, absolutely. So kind of going back to the magic word Mike just mentioned, it's all about risks. So obviously in the last three months or so, we were introduced to a lot of really new, interesting risks. And we've learned in some of the earlier presentations, like the one from Mike Schrems, that those risks, although kind of non-technical on the surface, will actually have a profound impact on cloud computing industry in general, especially here in Europe in particular.

So are there any things we should have kind of anticipated in advance or are there any new controls, new technologies, new processes we could introduce now to kind of at least partially mitigate, partially address those new risks? If I can, I have a lot of discussions about this topic and I always say risk is basically the sum of likelihood times impact, right? And I think we now know what likelihood is going to be. We know ourselves what our impact would be if that does happen to our environment.

I think you're now at the point where you have to accept that it will happen and you have to be prepared for it. I think that resilience, the word that we've been, for the last 18 months, been seeing every single day, I think that is the key.

How we, I mean, we'll probably never get out of this situation, but this is the way we're going to handle this situation with a foreseeable future. You need to be resilient. You need to accept anyone in the organization that is telling within the organization, like it's probably not going to happen to us or they probably won't be able to get us. That's where things break and that's where things go wrong. Everybody needs to have that mindset that it will happen and the likelihood is very big and the impact is what we need to minimize. It's not if, it's when and how often, yeah.

And I think also instead of like looking at the next shiny toy and imagine what that is, I would be so happy if people just do what they're supposed to do the last 10 years or so, right. Proper governance, zero trust, least privilege, yeah. So often we see that this is not probably implemented, yeah. So instead of like, you know, there's that new shiny toys, like do the basic stuff right. Because if you do that right, that protects a lot, again, also some newer attacks as well, yeah, or limits the exposure, right.

So yeah, new stuff is always nice, but don't get distracted. Do the basic stuff right, yeah. That's the important part, I think.

Yeah, I think one important thing what we recognized the last month is that resilience doesn't only mean technical. Resilience is like an organizational topic, what you have to, and that's in many of the topics what we see nowadays. It's resilience, it's sustainability and all that. It always has multiple dimensions. You need to be resilient technically, security wise, financially, you need to consider the political perspective and all that.

And that's for each company, not only for providers, it's for each consumer company, it's important to consider all the different perspectives, which comes back to risk. So you basically, and that's also not new, if you do any ISO certification, you will have your risk metrics where you write down all your risks, which fall into different categories. And there's not only a risk like ransomware or something, there's a risk of what happens if a new regulation comes into game, which stops the complete business. And then you calculate the probability and the impact.

And if there's low probability, low impact, then you maybe don't put it to your agenda. High probability, high impact, you will put it to your agenda. So basically, that's again, basic stuff. The only thing what happened in the last month is that you have like, you really get back to the topic. It's not only writing down my IT security risk for resilience, it's I have to consider all the perspectives. I think that's the only thing what sticks out again. Resilience costs a little bit more in the short term. And if you want to be resilient, you have to be prepared to pay that price.

And that's really all there is to it. And the electricity networks, for example, are an example of this, that the economy of scale that you get from being able to centrally generate and distribute to where it's needed, as it's needed, costs a great deal less than trying to generate it everywhere. But it also introduces a risk. And that's the cloud computing is, if you will, the exact analog of this in the information technology world, that it's potentially a lot more effective and cheaper to do it in very powerful blocks. But the trouble is that that also leads to other kinds of risks.

And resilience costs money. I think that's a great summary for this panel. And we've just kind of arrived to the end of our track, security track.