Beyond Compliance: Cloud Security in Europe

Security. Hi there. Welcome to the Cloud Security Podcast by Google. Thanks so much for joining us today. Your hosts here are myself, Tim Peacock, the product manager for threat detection here in Google Cloud, and Anton Chuvakin, a reformed analyst and member of our cloud security team here at Google. You can find this podcast wherever podcasts are sold, as well as at our website, cloud.withgoogle.com/cloudsecurity/podcast. If you like our content, please do hit that subscribe button on your podcasting app of choice. You can follow the show, get our updates as soon as they're dropped, and you can even follow us and argue with us on Twitter as well, twitter.com/cloudsecpodcast. Anton, we're talking about Europe today, aren't we?

We are. And it's been kind of interesting because we spent so much time talking about cloud migration and challenges and mistakes and approaches. And we sort of almost always assumed sort of a maybe US-centric or an approach that US CISOs would express, that US engineers would like.

Yeah.

And we kind of almost felt like we didn't pay enough attention to the different type of a challenge some of the European clients have. So it's really fascinating to look at the challenges specific to Europe or EU, basically that region where some of the challenges are quite different from what we hear from US CISOs, US security engineers, US analysts. It's just peculiar how they approach some of the things there.

It's really interesting to hear that some of these challenges are not even Europe plus cloud. They're just Europe plus go-to-market and Europe plus regulation. One of the things that John says that really tickled me was he was talking about the pace of innovation and regulation there rather than the pace of, say, innovation.

Correct, yes. And it's also interesting because sometimes you read the commentary online that Europe may become a model for some of the regulations for the digital space, for the IT. But I am really skeptical about this because how can you have innovation happening in one place and regulation for that innovation in another? I guess you can call it separation of duty, but it's also to me a little risky, right? You don't truly innovate, and then you don't understand innovation, but you want to regulate it. How can it work?

Well, I think it gets back to a little bit of what Tim Derks was saying about regulation and compliance providing the building codes or the food safety regulations that let us trust the industry at all. So maybe with that, let's welcome our guest and, and see where we go. John Stone, the chaos coordinator— a chaos coordinator. I don't know if you can have more than one chaos coordinator or if you would even want more than one chaos coordinator in Google's office of the CISO. John, thank you so much for joining us on the show today. We've had the pleasure, displeasure of working together for years. It's a true pleasure to have you on the show with us. I want to start off by talking about cloud migration. We've talked a lot on the show about the nature of lift and shift versus cloud native, but we're looking at kind of a different set of challenges in cloud migration today, doing it for Europe. Could you start us off with some of the, you know, top European-specific cloud migration security challenges? What's going on over there?

Thanks, Tim. I guess I'm the only chaos coordinator at this point in office, honestly. So probably also the chaos causer in some cases. To your question, so some of the specific things, and it's not so much around security, right? It's more around compliance and regulatory things. So if you take Europe, obviously it's a bunch of countries together. You know, as part of the European Union. Now, there's always local regulations and laws. And if you look at some of the larger enterprises, some of their bigger challenges is how do they basically apply to all these different regulations and laws in the various countries that they operate? So, I guess probably the first one that I would say is, so they already have this challenge on-premise, you know, how do I deal with all this different regulatory things on-prem? Now they're shifting it to the cloud and they're potentially crossing the borders around this. So I would say that is probably one of the biggest challenges in this scenario is to how do they maintain and keep up to date with all these regulatory legal requirements that they have to do. So that's the first part because the security element is the technical control that makes all of this possible. So it's not so much that people are around those kind of things. It's how do they make it possible? And then the flip side to that is the other big challenge that they face is if you think about it from that perspective is certain things that you would do on-premise are not necessarily fit to put in a cloud environment.

What's an example of that?

If you take, for instance, this whole concept and it'd be quite interesting to see Anton smile on this one. So if you take next generation firewalls, right?

Ah, good.

Firewalls. Yeah. So here we go. So, right. So next-generation firewalls come in because end users find ways to punch holes, you know, through your perimeter. And then we have application recognition to understand which applications those things are. Now we go to a cloud environment, and the users take that on-premise concept, and they go, let's put next-generation firewalls into the cloud. But why would you do that?

That's been a classic in my Gartner days. So yes, you're right. I will smile.

Exactly.

So why would you do that? Because in the cloud, I know this virtual machine is talking to that virtual machine and I know the application. Do I need anything that's application aware? Not for that kind of traffic. No. Maybe on the outbound traffic. Yes. There could be a use case for that. But the east-to-west traffic is less relevant from that perspective. Now that's already a different one. So that's a challenge that doesn't necessarily exist in the cloud. And then you bring that mentality into that. And then you have, how do I adopt? And that slows some of the adoption of cloud. I'd say those are kind of 3 big things today.

But so it kind of goes back to on-premise thinking, right, coming into the cloud. So in addition to the compliance bit that you mentioned, it also kind of summarizes to a lot of on-premise type approaches and thinking applied to cloud, which is pretty much what we have in the US pretty often. This was a feature of many episodes we've done on migration challenges. when people bring their on-premise playbook with them to the cloud, right? That's the same.

That is. And then we'll probably get into it a little bit later because I have some strong thoughts on this kind of scenario around that. But I think if we bring it back to the European context, a lot of that is how do you deal with the different regulations and also how things are developing quite quickly in Europe as well. So Europe is pretty fast in developing new regulations and all those kind of things, as fast as these things can be from that perspective. I guess let me make also a little bit of a side journey on this. So, it's hard enough to do it on-premise, then you're doing it in cloud, and then you're doing it in multi-cloud, which is obviously a good strategy to have because you don't want to put everything in one basket. But there's obviously the complexity from the end customer side where they have to think about, even if you have it mapped out perfectly and you know, you know, how do I meet these requirements? and here's the technical controls. Cloud A to Cloud B applies it in a different way, and then you have to think about it differently. And I guess the meta point on that would be, how do you deal with that from an organizational perspective in terms of staff and operations, right? Now you need, for instance, a person that knows Cloud A and a person that knows Cloud B, and that becomes quite challenging. And how do you retain those people and keep them interested in your organization? Because very shortly they realize, They're a very rare commodity and they leave your organization.

Yeah. The people challenge of staffing up against the clouds is a really interesting one. I've seen some organizations assign one person to each cloud. I've seen other organizations try to have people be cross-cloud. What's worked well in your experience? Because you've seen a lot of different orgs up close, what's better there?

So I would say it depends on the size of your organization, right? Because this is always the thing. There's also the law of physics. How many dollars can you actually pay to have people there, and that dictates a lot of things. But if we just say the budget's not an option, right, it's a mixture of getting people to cross-train on the clouds, because if you have it dedicated and specific to one, you're creating single points of failure and you're going to overload people. When you're training them across the clouds, it gives them a different skill set and doing a rotation of that. So one week you'll be working on cloud A, The next week you'll be working on cloud B. And that keeps it interesting for the folks as well to do those kinds of things. But there's no right or wrong answer on this one because if you have the ability to basically have enough people, yes, you can make dedicated departments. That also has its pros and cons. But that's something you've got to weigh up for the organization.

That makes sense to me. And I think that's also perhaps more acute in Europe, but I've seen similar challenges here in the US. So to kind of reorient us back to the context of Europe, broadly speaking, it sounds like a lot of what you presented may be actually a cloud adoption barrier. So some organizations look at this and say, oh, we struggle with this even on-premise across borders. We should probably not even try cloud. Are there interesting cloud adoption barriers related to security in Europe? For example, from your point of view, it sounds like many of them may be more compliance-related.

Right.

rather than security. So they're not about the threat actors, they are about regulations. So do these become adoption barriers, or is there more to it?

So I think there's a different point to this one. Rather than saying, like, security challenges, I'm going to say there's a precursor to all these, right? And by this, I mean, there's a psychological factor, right? So essentially, if you drill down to risks and all those kinds of things, one of the biggest challenges is control or the perception of control. And what I mean by this is if you take the whole encryption debate, right? So this is always, I need to hold the key because then I'm fully in control around that. Yeah.

This is why we built the EKM, right? To a very large extent, right? To make these types of people happy, right?

But if you look at it from a purely threat perspective, so whether it's default encryption or EKM, is your data encrypted?

Yes.

Is the encryption algorithms the same? They're the same, right?

Yes.

Where it comes down to is the perception of control and kind of psychological comfort levels with these kinds of things. So, if you think about it, when everything is on-premise and in my data center, it's this kind of perception. I can hug my service. This is a natural cozy thing, you know. So, for the folks listening to the podcast, I'm hugging myself, which is a weird image to have.

Yes, it's adorable.

But then if I put it into cloud, you know, I'm all of a sudden stretching out. Now, if you just stretch out your arms in front of you, stretch it as far as you can, all of a sudden it's not comfortable anymore, right? And now what I'm doing is I've taken my key that's been close to my heart here and I've put it somewhere else, right? So that, I would say, is one of the biggest challenges around it. So it's a little bit of a different take on this thing because We can go and point to this challenge, to that challenge. A lot of it is regulatory and compliance-driven. But if you look at specific security challenges, and I don't want to sound like a bit of a broken record here, but if you look, for instance, at the OWASP Top 10, those things haven't changed for years. Like, the security problems are known problems that we have. They kind of just flip around in order.

Mm-hmm.

But it's the psychological aspects of dealing with new technology and how we get comfortable with that new technology. technology, which I would say is one of the big challenges today.

That's my impression as well. So it's kind of funny that you pretty much just focus on this whole point of controlling access, controlling keys, having control. And of course, it becomes kind of psychological. When I dealt with EKM here at Google, most of my thinking in terms of presenting the story of EKM really went down this kind of psychological, emotional path, not so much about true threat assessment. It's kind of about the perceptions and about who feels comfortable with what approaches. Like somebody wanted a key under a particular mountain in Switzerland, and it's the only location they accept, that type of stuff.

Yeah. On this topic, I mean, you mentioned that we built EKM to make these people happy. My experience with compliance people is that they are never happy. Is this a case of compliance driving security around, or are we actually achieving something useful with these mountains in Switzerland that Anton is familiar with?

So I would say, It depends on why you're doing it, right?

Uh-huh.

If you're doing this for the compliance and regulatory thing, you're doing it because you actually want to comply to that and you don't want to tick a box. It's a different discussion to when you're just ticking a box and I don't want the regulator pitching up at my door and asking me why I did this thing. Those are different discussions. So it sounds almost a little bit ideological, but if you do it for the right reasons, that changes the conversations and you're doing things that are actually going to move the needle. So that makes a completely different discussion.

But the right reason is the attacker, not the regulator. I'm sorry, I'm gonna be a bad guy here. So to me, if you're doing it the right reason to approach the regulator in the right way, you're still doing it for the wrong reasons because the right reason is presumably the threat actors.

I'm with you.

So I agree with that one, Anton. But so what I would say to that one is, so the regulator is gonna say, you need to show that you are in control of your data. at all times. Now, if I flip that over to a threat perspective, well, if attackers can take my data, I'm not in control of that data. So, what measures would I put in place to make sure that attackers can't get to my data? You know, here's my layered defense. Okay, Mr. Regulator, I can show you now that I'm also in control of this because I've actually taken the threat-centric attacker approach to this, and I've tried to fix that. And by doing that, I've met the regulation. Now, the flip side of that is, and this is why I was saying doing it for the right reasons, the flip side is we normally take the regulation and we say, here's a bunch of technical controls of how we meet your regulation. But to your point, if we flipped it the other way, we would still meet the regulation and we would actually be affecting real change to the organization rather than just ticking a box.

You know, here's one way to look at it, Anton, that might make you feel better. We worry about losing data. We worry about our business, you know, having downtime. But if the regulator decides you're not doing it right, you might have downtime. So maybe the regulator is the threat actor in your model.

Correct. And I've seen people in my PCI days, I've seen a lot of this when people truly threat modeled with the PCI assessor as a threat actor. So that's definitely the case. But I also feel like there's a bit of a logical flaw. And I swear to God, I didn't mean to go into this debate here, but I think that last John's comment pretty much to me sounds like compliance equals security and it's gonna go both ways. Compliance means secure, secure means compliant. That's obviously quite wrong in most locales I've seen. So help me here because you sound like if you do it against the attacker, you'd be compliant. That's not the case. We know it.

That's a good point to clear up on that one because you can become fully compliant, and you will get breached tomorrow. In fact, if you look at a lot of breaches that have happened, all those companies have been compliant with all the things that they needed to be compliant with. That still happened. And at the same point, I can be very secure, but I could not comply to any regulation. But it's finding the balance around those things. And this is why I say I'm doing the compliance thing with the attacker in mind to achieve the compliance side of things. And finding that balance is a little bit of a tightrope kind of thing. But it's that one thing of how do I get both sides to play together? Because you need both. I can't be driven more by compliance, and I can't be driven more by security.

Mm-hmm.

And that is a seriously hard challenge to do.

Right. And I just want to say, I'm really glad that you're out there helping our clients and our users walk that tightrope, because I don't think Anton or I have the patience or skills to help them with that. We would just say, jump off the rope on the security side. So it's a good thing you're here.

There is that. And I think you're right. I mean, I have a bit of a compliance brain, but I prefer to keep it kind of in the back.

Yeah. I mean, I'm the same. I would rather dive into the Here's the technical security thing. Here's the risk, and that's not a risk at all. So why are we even doing that kind of thing? But there is a balance around that, and some of those regulations are there for good reasons. And it's understanding why those regulations were there in the beginning, not what they've become to some folks. So I think that's kind of pivoting also a little bit back to that previous question where you said like what's some of the biggest barriers. I think some of the biggest barriers is how people enter. Interpret regulations and compliance things, that this is always the challenge. The regulators do it in a broad perspective, but sometimes it's too broad, right? It's not prescriptive enough. Because if I told you, you can only color in blue pen, that's pretty prescriptive. I know exactly what I need to do. But if I tell you, hey, Anton, please go color in this picture, it's open to you and you can interpret whatever it is. You can interpret to color Color out the lines, all those kinds of things as well, because I haven't said that. I've just given you a task, color in. And I think that's a big challenge as well.

In light of this, I want to take this discussion to kind of a higher level and kind of remind everybody that true hyperscale cloud providers exist in 2 countries, US and China, right? There are many cloud providers in many countries, but the true hyperscale cloud providers exist only in those 2. So do you think Europe can make their own cloud of that same scale? Do they need to? Can they achieve this vaunted concept of data sovereignty without doing it? Walk us through the whole thing. This is really quite confusing for many people in the US, it feels like.

I'm not going to touch on the political side of things because there is obviously some politics involved in this. I'm not a politician. I'm not qualified to make those comments. So I'm going to steer away from I'm going to look at it from a purely technology perspective, right? So can they do it? Yes, anything is possible in the world, right? So if I was the person in Europe, I'm going to put myself in their shoes and go, if I was that person, how would I approach this? I would actually work with the hyperscalers around building these kind of things, you know, to get that level to where we've jointly worked on these kind of things. So we're not 100% reliant on those side of things, But we've jointly worked on these solutions together. And the reason I'm saying that, if you think about it, right? So let's say, Anton, you started a hyperscaler and you started it 5 years ago. I now walk into the market, right? My first product that I deliver is 5 years behind your product. And you haven't sat still, you're iterating now. So now you launch your next product and I launch my next product in a year later, but now you're 6 years into the journey. And I'm only one year into this journey, so it wouldn't be sensible for me to say I'm just going to build this all from scratch. But I would rather say, okay, Anton, you know, we're looking at providing services to our customers. Is there a joint market opportunity for us together to address this? How can I work with you to be able to build these kind of things around that kind of thing? And how can we have that relationship? And that's, I think, an important way to look at these kind of things. The short answer of, I guess, that is, can they do it? Yes, they can. The question is more about how should you go about doing that? And I think that's where you should actually partner up with different providers that have already gone down this journey, that actually help with this and come up with solutions that's going to meet the market. Because yes, there is sovereignty, but at the same point, you also realize we're an interconnected world, right? Enterprises don't live in one country. They live across multiple countries and they have to serve multiple customers. And how do they best serve that? Not by just having something locked in one region. That would be great if it was just one company, it's just operating in one market. But the reality of those things, and I think we've seen some of this with the corona side, we've actually seen how interconnected we've been, you know, when people have, you you know, been stuck in their homes and all these kind of things, we've realized a lot of the things are interconnected. So if you take the recent Suez Canal events, one container ship takes a little bit of a wrong turn and the whole world has a bit of a hiccup, you know. So for example, I was chatting to a local builder the other day and he was saying it's taken him 6 months to get an air conditioning unit because of the supply chain backup, because it's so interconnected. And now if you apply that principle to cloud, that same interconnectivity is there. So having this true isolationist way of thinking where it's only sovereign if it's in my country and I control everything is going to be a bit of a Suez Canal blockage and it's going to hit all these other things.

That might be the best metaphor for that.

I like that. And at least you didn't turn it to Kubernetes security. I mean, otherwise this is too stale.

You know, ships have containers, so I didn't want to go there.

No, that's excellent.

Excellent.

We're getting close to time, as we do, and I'll ask you our traditional penultimate question and Anton will take the final one. Do you have a practical tip for improving cloud security in these European organizations? Just one, like the one weird tip.

I actually want to give you 2.

We'll take 2. We'll take 2.

One bonus tip, right? I would say low barrier to adoption, and I would say a fence, as in a fence that keeps— white picket fence or a fence that keeps your yard in, whatever. Okay, so let's start with the fence first, right? So this is my own story around it. I have this picture of my fence that got blown over. So in Amsterdam, it gets really windy sometimes. And the previous homeowners, when they put up the fence, they never considered the wind direction. So the way that they put up the fence, when the wind blows, it actually blows the fence out of its screws, right? Retrofit that to cloud. When we came up with our security controls, if everybody is really honest with themselves, a lot of these things were invented before cloud was even there. And now we're trying to retrofit those things into the cloud. So I would say consider the fence and the wind direction. Like, is this actually still applicable and relevant? So that would be number one. Number 2 is low barrier to adoption. Now this one's gonna be slightly controversial. If you think about it, Cloud's easy in the sense I pull out my credit card and very shortly I could have something running in cloud and in production, right? That presents some security challenges because, ooh, how do we control this? And before we know it, it's in pod and it hasn't been properly secured. I don't wanna focus on that one. I wanna focus on the one where security goes, wow, cloud is amazing. There's a lot of automation I can do here and I can simplify all these things. The story I wanna tell for this one is there's this kids show in the Netherlands. It's called Biermann und Biermann, neighbor and neighbor is what it translates to. These dudes are the kings of over-engineering. So what happens is the one neighbor is busy mowing his lawn the one day and he cuts over the cord. In true over-engineering fashion, the other neighbor runs up onto the roof, rips off a solar panel, straps it to the lawn mower. This is amazing. Now think about it from a cloud security perspective, like, oh, we had a problem, here's automation. So now they have A panel strapped to this thing, and it's running by itself. Then it starts to hit shade areas in the garden itself, and it slows down. So, what do they do? They go and cut down the shrubs. Okay, well, you just made automation, and now you've made more work. That doesn't quite make sense. So, they carry on like this, and then, obviously, with all these stories, there's always a pesky cloud that comes in. And in this case, the cloud comes in and blocks out the sun. Now it completely stops, right? So what they do then is they take out torches and they've got their torches and they're shining it on it. Now they're walking behind it. But if your goal was automation, making less work, there's a lot more work. So they realize this is not going to scale. They get a big IKEA lamp and a car battery and they strap it to the lawnmower. Now it's got a different effect. It's so heavy, it actually starts plowing the ground and not cutting the grass. So eventually what they do, they basically take All these things off, and they find every light that they can find. And it's like the kind of cliché thing where you would see like Christmas lit up house from space. They light that place up so you could probably see it from space. Low barrier to entry, right? Like it was super simple to do all these things and it got super complex. What should you have done? Well, there's the cord. I should have just taken the cord, you know, insulation tape, put the wires together, problem fixed. And that's the other thing that I would say. That, I would say, is the nugget of advice. Consider what you're trying to do in the cloud. Even if there's shiny and cool stuff, you don't necessarily need it. Solve the problem that you need to solve.

So 3 tips. We've got a white picket fence, we've got a children's TV show about low barrier to entry, and we're making sure that we aren't distracted by shiny stuff. I think that is maybe the—

And clouds. Don't forget the clouds in there.

Don't forget the pesky clouds.

Oh, and we got clouds in there. Yeah.

Wow.

That's amazing.

So we'll take all 3. That actually works. And I think that I love your storytelling style, by the way, because I feel like I sometimes just like go too fast, like I jump to things. And I love a good story that actually gives the lesson to a client, for example. This is the ultimate question, and you promised it's a short one. So any suggested reading? I hope you wouldn't tell people to read the GDPR or some of the other stuff that's long and kind of written by bureaucrats, but any best reading you have For the topic of cloud security, hopefully in Europe?

If you're going to read that specifically, I would say go and read some of the stuff ENISA has written around it.

ENISA is more fun.

Exactly. They've written really, really good guidelines around that one. So, I would say that would be the one that I would focus on reading because they've put a lot of work into those things, and a lot of it is really good, well-thought-out things around that perspective.

Okay, excellent. Any particular documents we should link to?

There's actually a ton of stuff on that. So I would just check on the ENISA site and you'll find the things that are going to be relevant.

Okay. We'll highlight a couple of ENISA cloud security documents because frankly, I tried reading some of the stuff from EDPB and I fell asleep like 4 times. So I think ENISA documents are a lot more applicable to the operational reality.

Yeah. And it's a lot more practical as well from that perspective.

Perfect. Well, thank you very much for being on the podcast.

Yeah, that was super awesome. Thanks, guys.

John, thank you so much.

And now we are at time. Thank you very much for listening, and of course, for subscribing as well. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, and many, many other apps, pretty much wherever you get your podcasts. Also, you can find us at our website, cloud.withgoogle.com/cloudsecurity/podcast. You know, I now just say the website, and it just rolls off the tongue. I love it. Please subscribe so that you don't miss episodes. You can also follow us on Twitter, twitter.com/cloudsecpodcasts. Your hosts, Anton Chuvakin and Tim Peacock, are on Twitter as well, @anton_chuvakin and @teampeacock. Tweet at us, email us, argue with us, and if we like or hate what we hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode.

Security. Security.