EP183 Cloud Security Journeys: Improve, Evolve, Transform with Cloud Customers

Security running.

Hi there.

Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here, as ever, are myself, Timothy Peacock, the Senior PM for Risk Analytics and Cloud Threat in Google SecOps, and Anton Chuvakin, a reformed analyst and senior staff in Google Cloud's Office of the CISO. You can find and subscribe to this podcast wherever you get your podcasts. as well as at our website, cloud.google.com/podcasts. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. You can follow the show, argue with us, and the rest of our Cloud Security Podcast listeners all on the Google Cloud Security Community page. Anton, this is another one in our ever-growing repertoire of Voices episodes, and we are chatting with 2 women who have awesome backgrounds, doing really cool work in cloud consulting.

Yes, correct. And I think that in addition to it being a Voices episode, it's also one of the ever-growing stable of episodes about cloud migration.

Yes.

It's not the only topic that you'd hear, but ultimately it's quite fascinating to me that cloud has existed for—

A decade?

However, no more than it— oh, wait a second. We are pushing on the decade and a half at this point, right?

Okay, but this question requires us to define cloud, which listeners, you might remember when Anton And I could not define cloud.

Yes, correct. So, that's why I'm hedging and fudging on the cloud birthdate. But the point is that it's definitely more than 10 years ago and it's less than 20. So, the point is that at this point, we should have pretty robust best practices. And by the way, you've heard me ramble about how you can't have best practices unless you practice for a bit. And I feel like we practiced to know what works best. Seems very logical. You practice, practice, practice. You look at how you practice and you say, these things are best, these things are okay, these things are going to toss, right?

But you know what my music teacher when I was a kid told me is, it's not that practice makes perfect, it's that perfect practice makes perfect. And so, it's not enough to practice, you have to practice well.

I think you practice intentionally. You don't know what's well unless you have best practices. So, well here doesn't quite cut it.

There seems to be a circular dependency in the quality of practices. And maybe before Tim and Anton spiral off, into this problem, let's turn things over to today's guests. And with that, I'm delighted to introduce today's guests. Today, we're joined by 2 members of the Google Cloud Security Consulting Practice. We're joined by Jaffa Edwards, a Senior Security Manager there, and Laika Segura, a Cloud Security Engineer, obviously also here at Google in our Cloud Security Consulting Practice. Laika, Jaffa, tell us real quick about how you got here at Google and what it is that you work on here. Super stoked to have you both on the show, by the way. Thank you for joining us.

Awesome.

I can kick it off. So, hi, everyone. My name is Joffa Edwards. I'm also super stoked to be here. In terms of how I got to Google, I'd had a long journey in terms of IT, in terms of working with computers. I went through a rotational program where you rotate and you look at different areas of IT, and then one of them was in security, and that is just where I fell in love. I think I fell in love because somebody told me that I could just fight this cyber warfare for a job and someone would pay me. So that sounds perfect. So I went through some big companies, some small companies, and I finally got lucky enough to land at Google and I'm super happy to be part of the security practice. How about you, Laika?

Hi everyone. My name is Laika Segura and also very excited to be here. And I think my journey started back in college. When I was in college, I wanted to be in security. Like that was my focus. But then I joined a consulting firm where most of what I did was focus on infrastructure and DevOps. and thought I was going to spend my career doing just that.

Hmm.

And then I moved to London for 2 years and Google reached out and I got a job at Google with the infrastructure team, actually. And then 10 months into it, I think I reached out to one of the managers in our team and talked to a lot of the people on our team. And I was very interested in merging the 2 interests together and going back into that security part of it, which is awesome. And so that's how I ended up being back here and doing this.

I love that. We desperately need more DevOps influence in security, and some of my favorite cloud security podcast episodes have actually been about that topic.

It comes up all the time, and especially as a challenge. And by the way, for many organizations, moving to that is not just a change, but it's a transformation. And what I observed in doing security for some time is that change is hard, but transformation is actually harder. So, a lot of what you do during the day is security transformation. So, what are these secret tricks and magical methods to actually make it happen? Can you give us a few examples?

Yeah, I think— so, I don't know if it's a secret or people just forget, but security transformation is not just about technology. It's actually about restructuring your organization, restructuring how you operate. So, like any business transformation, it's about people, it's about process, it's about technology. So, some of the tips I could put into those buckets would be, for people, leadership is super important, being able to influence how you're going to build your operating having to drive that change, and then also giving your opportunities to your team members to upskill from a technical perspective and also on the new way of working. From a process, we just talked about DevOps. You talk about it on your podcast all the time. How can you shift security closer to your app development, into your deployment pipelines? One recommendation that we always work with our customers on is building approved security patterns. So, different reference architectures, having different services that build in preventative and detective controls so that teams can just easily adopt them.

that.

And then finally, on technology, try as much as possible to use cloud-native technologies. On-prem does not work. So, I'll leave it with that.

I think that the topic of on-prem doesn't work in the modern world comes up all of the time, and we still see people who are basically just flat-out not convinced. And they say, yes, we understand you in theory, but we are so mired and connected to the old world that we can't really do it. So, I think that I wanna very gently kind of question that maybe you've saved a couple of magic tricks for yourself or something? Because I still see people who focus on people and process and they try to transform, but the pull of the past is so strong. And what they do is they lift and shift, they copy their entire security stack to cloud. Like, they do things that are sort of inspired by the past. Inspired maybe even is too strong. How do you stop them? Or how do you evolve them, rather? How do you transform if they want to transform but without changing anything?

You want to start, Lync?

I think—

Nobody wants to answer that question, Anton.

That's a tough one.

I kind of like this question as you don't often see it now, at least from where we come in in the engagement, but it's often because of the misunderstanding of the cloud's unique advantages, right? This can usually be addressed through, as cliché as this sounds and you'd hear this a million times, education and gentle guidance with a dose of tough love when needed. So I always start by acknowledging that, yeah, like there is some thought to the cloud is just someone else's computer analogy, but it overlooks the cloud's dynamic nature and enhanced security features, like for example automated patching or threat detection, right? Then we emphasize on the shared responsibility model, clarifying their role in securing their data and applications in the cloud. And sometimes, and I think this is my favorite, it's letting them learn from their own mistakes is the most effective.

Mm-hmm.

I.e., when they incidentally Sometimes we guide them through proof of concepts showcasing what the cloud can do and comparing it to what they have. And this firsthand experience usually helps overcome resistance. And the goal is eventually to empower the customers to embrace the cloud's full potential, right? While understanding its nuances as well. It's a balance of education, guidance, and allowing them to stumble so they discover the value of a cloud-centric approach. I think.

That is a magic trick, and you were saving one for yourself. Yes, this is— yes, now it's actually— I think that was the missing piece. Yes.

I really like that approach of let them learn from their own mistakes. I feel like that was kind of my parents' approach with me as a child. It's a good approach. I learned a lot from my own mistakes.

Yeah.

No, one thing that comes to mind for me is you can't change people who are not willing to change themselves. So, it's very important that, especially in leadership, that they recognize that change needs to happen when they're transforming from on-prem to the cloud. So, like, to point, failure, you know, sometimes drives change. So, a lot of people, our customers, come to us, and they may have tried this 2 or 3 times and haven't quite got it right yet, but they've learned from each of them.

So, maybe we can make this more concrete. Could you, maybe one of the two of you, tell us a story about a time that you really did change people's minds? Like, show us the power of consulting. Show us how you got people into the cloud mindset, because it's hard.

I can. I have a cool example. I've been working with this customer for the past 18 months. Just to set the stage, when we started, they were very excited about the potential of the cloud, but they needed help navigating its initial hurdles. So the initial expectation for us was to only deploy one application, one full suite of applications within one year, right? That's it. That's all the leadership wants from this team. And so they reached out to Google Cloud Consulting, or GCC, and together we started our journey. So instead of starting entirely from scratch, we leveraged a combination of established security patterns, and developed a few tailored ones of our own. So this approach gave us a flexible foundation to build upon and allowed us to rapidly iterate as new technologies emerge. The good thing about this client is that they're very flexible and very adaptable and were willing to just follow whatever our recommendations were. And by automating a lot of these security checks, getting pre-approval for these patterns, we were able to significantly speed up development. If you remember, I mentioned one application within 12 months. In 18 months as of today, we were able to develop 3 fully functional applications with the added complexity of third-party dependencies. So it's, it's been remarkable, like, just seeing this change as they've gone from cloud newcomers to confident practitioners who make security the top priority.

Right.

And I think it's a testament to the impact that a well-defined security strategy coupled with a commitment to continuous improvement can have on an organization's cloud journey.

I think that makes sense. But also, if people expect that a one-page white paper read by their boss would magically transform them by Monday, it's misplaced. It's kind of good news, bad news. What you're describing to me is good news, but it took work. If somebody expects it to happen instantaneously because you have the magic words, sorry, no. It's hard work.

Which I think is the good thing about the GCC or Google Cloud Consulting coming in. So, we can iterate through those patterns and make it tailored to the specific needs of the customer itself.

That makes sense. I think I want to also point at the starting point of the engagement because what I've observed in my consulting/Gartner days is that sometimes you want to start working with a customer and you need certain critical information, whether it's about their approach, and they're just not sharing it, whether they think you don't need to know or they actually don't know themselves. The popular example in the good old days was, Give me a list of critical assets. Well, we wish we had that. Like, it's not like they're trying to hide it from a consultant. They don't have it. So, what's your approach for starting the engagement, and how do you deal with people who don't share enough for their own success?

Yeah, well, in terms of starting the engagement, of course, consulting answer, it depends. But typically, what it is, is we want to educate. So, we want to help customers to understand how security works on GCP. And this becomes super important because once we get to discovery and understanding what their objectives are, that they're able to really make informed decisions in terms of how they want to architect a solution, or be able to really understand how they wanna create that operating process. It also really comes down to trust, especially for the individual, the customers that are not willing to share. You know, our approach to trust, I think, is really our goal within GCC is to make our customers secure on Google Cloud. So with that, we are direct and honest with them. We want to build opinionated approaches and solutions. And if a customer just doesn't know how, I think that's where the advantage of our experience, being able to bring our industry knowledge of how we've seen it done in the past, so that they can, you know, perhaps make a decision how they want to do it in the future.

I like that. Something else I liked recently is Anton didn't come out with a list of top AI risks. He came out with a list of fun AI risks. And I wanna ask you two—

I love that.

Yeah, I know, right? Imagine a fun AI risk. I wanna ask you two, what are some fun security mistakes you've seen people make when coming to cloud?

And I think let's make sure lift and shift is off the list because you can probably talk about that for an hour.

No, that's not fun.

That's not fun. And it's not fun. Thank you, Tim. Appreciate it. Yeah. Top number one, just not fun.

Yeah.

Okay.

I don't know if any of them are fun. Maybe Laika has some fun ones, but I think one that is a super common mistake is organizations are super excited about the cloud. You know, logically, they say, I'm gonna start small. I'm just gonna start with a single team, and we're gonna scale it after. But really, what happens with that is it ends up creating a fragmented environment, a lot of times creating more technical debt because you're really just using that siloed team. What I've seen more successful when it comes to security transformations is full organization, top-down restructuring of understanding how you wanna do security, how do you wanna do your business, what your objective is, all of that to really drive that change. And one more that—

So, you're saying don't start small? You're saying go for the big bang?

I am. I am.

Wow.

Yeah, it's, it may be different, but with structure, with understanding, from an objective standpoint, how you want to look like from a planned phased approach from a program. As Laiken mentioned, this is, this is years of approach to get to that end state.

Okay, so it's not do it all at once, it's do it, but do it with a plan and top-down buy-in and objectives and structure and thinking about where you want the roads to be, even if you're letting people have walking trails to start with.

Yes, exactly. It's not the 2 people who get access to Google Cloud and try to figure out how to build, deploy, and secure it all at the same time.

Yeah. Start small doesn't mean you have one person go wandering in the forest, and then 2, and then 4. It means you survey the forest and have a notion of where things are gonna go.

Yes, exactly.

Because actually, the start small part— I've actually, funny enough, I came to the same realization fairly recently about start small being not always right, because I've seen people who lift and shift, and they say, we're gonna go do almost everything the same, and then we'll transfer. When they'll go further, but the go further never happens. So they start small as a step 1, but 3 years later they are at step 1.

1.

They started small and they're still there. So this, which initially I was like, no, don't do that. And it's like, well, yeah, sure, you can say that, but like, people do do that. So maybe figure it out and then go right as opposed to start small. Hmm. That probably pays for the episode on its own, right? By the way, that pays for it.

You're welcome.

Yeah.

Well done.

Congratulations.

Olenka, what's your answer for fun security mistakes?

See, if lift and shift isn't fun, then what is fun?

No, not fun.

So, I need an example of what's fun. But I think for me, it's organizations underestimating the power of cloud-native security tools and being dependent on what they're used to, i.e., third-party and then bringing that in and all of that. I think major cloud providers offer a treasure trove of services designed explicitly for their platforms, and failing to leverage these tools can result in fragmented or inefficient security approach that is just difficult to maintain and leaves security gaps. I also want to add, the DevOps person in me just want to say automation. Automation is key in today's landscape, and by automating tasks like vulnerability scanning and threat detection and incident response, we can dramatically enhance the security posture and responsiveness and also frees up the risk for human error and valuable time for strategic initiatives rather than this manual repetitive tasks.

Well, as somebody who spent 5 years of his life building cloud-native security technology, I can't tell you how much I love that answer.

Let's see, I don't want to go on a fun and long tangent, but it actually comes up a lot with people who say that They want to keep on-premise-style tools on-premise because they're either nervous of the cloud and stuff, and they sort of expect that the cloud tools are a little bit better. And then they don't really realize that they are not a little bit better. At some point, they may not be talking about the 1950s car and 1960s car. They may be talking about the horse and buggy and a flying car. But that difference doesn't get conceptualized. Like, I had this debate with somebody literally yesterday on social media who was like, oh, yeah, I'll just use the on-premise SIEM. It's like, sure, okay, but you do realize the cloud-native one is better? And he says, yes, I realize it is better, but I'm okay with this because I know it. But at which point I wanted to make an argument, but do you realize it's 10 times better? And they don't, and they didn't. It was very clear that they assumed it's kind of almost the same. The new one's better a little bit, but so what? But the likest point is quite profound, is that they're dramatically a lot better in many cases.

You know what happened to me the other day? This is the first time this has happened to me. I was talking to a customer about some of our cloud-native security capability, and they were engaged. They were asking good, sharp questions. And then they said to me, okay, but what about, can you do that for me on-prem? And I was like, no, no, I can't.

Confused face.

I thought it was so interesting though. Like, they totally bought the 10x better thing to the point of, could you do that for me in my data center?

I think that's a win.

Yeah, well, yeah, kind of. It was a weird win.

Yes. But now I want everything that is just as good except in this box. It's a 1U appliance.

Can you do that?

I plan to keep it under my bed. Like, that's the line of thinking that is just like, no.

How about AI?

Can I have AI as good as yours?

AI, but in a 1U box.

Yeah, I'll put vMTD in a box. Just needs a SPAN port.

So, let's go talk more about the path because this actually comes up quite a bit. So, we talked about people who wanna lift and shift, maybe stay with the familiar, but you also see people, I'm sure, who wanna practice in the cloud the way they practiced on-premise. I'm talking about paying lip service to DevOps, essentially doing this slower. This is, I'm an auditor, I check for things every year. Like, how do you deal with people who kind of transition to cloud, but they want to practice, practice security, practice IT in largely the 1990s way? Like, what do you tell them? Like, how do you teach them apart from, yes, let them make mistakes their own way?

Yeah, I think that's, you know, part of the— I hate to say educational part of it, but it is. It's really teaching them, you know, the difference between doing it on-prem and doing it within the cloud, especially around when you see controls Teaching them about the deployment pipelines, about preventative controls that you can put in there in terms of policy as code. Those things are really powerful tools that I think a lot of people in that mindset just maybe are unaware of or not familiar with that technology. So showing the power of it helps drive that change.

I think also demonstrating the capabilities of the cloud and allowing them to see that in action really, really helps in changing that mindset. Because sometimes you can talk a lot about things and then do a lot of presentations about certain things, and it's just going to going to go out of the other ear, right? They don't absorb that kind of information. But then once you show them and you demo it to them, you POC, if you provide a proof of concept, then it just makes it easier to digest essentially.

What's an example of a particularly compelling demo that you've done that shows people the light? Like what's the light bulb moment demo for people? Hmm.

That's a good question.

That is a good one.

I think Chronicle for me. This is not like an example of— I was not part of the demo, but the customer was using a different SIEM before, an on-prem SIEM, and Just using like a whole set of tools for their logging and monitoring. And then our Chronicle team came, and it was a span of like 6 months of just constantly like educating them and demoing this capability within Google Cloud. And eventually, they decided to abandon everything that they believed in and then transition to Chronicle, which was amazing to see. But I think that's one of the wins I've seen so far with POCs being the way to convince them.

It does demo really nicely, doesn't it?

Right.

Chronicle, even in the early days when people— like all the jokes about how You run a query, you go on vacation. No, no, no, this team is fast. You go take a coffee break, not a vacation. It's fine. And then you get exposed to Chronicle, and it's like a quarter of a second. It's like you don't even have a chance to sip coffee, much less go for coffee, and the results are already there. So, that part is quite magical. Sorry, Chronicle ad.

Yeah, we're gonna make Anton wear the marketing hat for the rest of the show today. So, we're getting towards time, but I wanna ask at least one more question here. I wanna ask you for your advice of what you would tell an org that was starting their journey to the cloud, or starting their journey maybe to a new cloud. Say somebody is coming to GCP, they've been in the cloud before, but they've got a chance to get it right from the foundation this time. What would you tell them of how to get GCP right from the foundation if they're new to it?

I'll start.

I'll give you kind of more of an organizational perspective, and, like, maybe you can think of it more from, like, a technical perspective. foundational. So, this goes back to the mistakes. I know we didn't talk about this, but one thing I see a lot is customers who don't have a really clear business objective of what they want to do in the cloud. You know, do you want to do lift and shift? Do you want to innovate? Do you want to scale? What is your first workload mover? So, I think that is step one, is understanding what do you want to do on Google Cloud, and that obviously is going to help you understand how you want to protect it. So, that's number one. I think number 2 is to really understand your current organization, look at your tech stack in terms of how you're doing it on-prem, so that you can understand maybe what changes that you want to make, maybe doing things like looking at Chronicle or SCC or other cloud-native technologies that we have that are available and seeing, is this something we may want to shift to within the cloud, and having that overall process in terms of what you want to change from your processes and technology. And then we talked about this earlier, but it's so important, is building out that long-term plan of how you want to transition there into that multi-phased approach, starting with that first workload to what your desired and state is, and then working backward from what that is. And I have to say, you know, asking for advice, potentially from Google Cloud Consulting, from people who've been there before, who have experience, who can help advise on the best steps.

So, don't take this the wrong way. That seems kind of obvious.

It does.

Is it not obvious to tell an organization, to be successful changing, you gotta know where you are and know where you wanna go?

You know, I agree with you, and I think that what happens is the complexities of an organization, you know, how they have so many different leadership, have different understanding of what they wanna do from objective standpoint. So, part of that is coming to one consistent understanding to be able to get to those steps, which is so much harder in practice than it is when you say it in a 2-minute podcast.

Yeah, that makes sense. Okay.

Actually, let me ask you one more thing in light of this that's been bugging me lately. And so, I'm just gonna use my free Google Cloud consulting time.

Anton bugged by something questions are always good.

I'm scared.

Yes. So, in this case, we've been struggling a lot with people who inherit an environment where security was either not done at all or done in some utterly incompetent ways. And I think that it's— I'm not sure what's worse. Let's just assume that it wasn't done. It was just like they can't spell IDS. And so, what would be the first 3 things you would recommend to somebody who inherited the environment of that sort? Like, it's a cloud environment, it's prod, it's built up, it does something for business, but security never showed up within miles of that.

What should they do? I'm gonna say one thing, I'm gonna pass it off to Laika, but my first thing would be, like, can we just rebuild? Like, this is the cloud, right?

Yes. Burn, brush, or nuke from an iron cannon from orbit is very much a legitimate technique.

Nuke from orbit.

Nuke from orbit, very much a legitimate technique. Except for when it's the entire business.

Yes.

Which is what the comment when I had this debate, aka fight, on social media, pretty much everybody who said nuke from orbit, destroy it with fire, and similar answers. I mean, there may be cases when this is the entirety of the business.

Okay. So, first thing, if you can engage with Google Cloud Consulting and run a cloud security posture review, and that would give you an overview of how your cloud environment looks like. But I think the Second thing is, I think it's the same as starting fresh, right? Even if it's an inherited organization, in my opinion, it feels like it's starting fresh. It's just that you have a few more hurdles to go through, i.e., fraud stuff. But I think first step is just understanding your org structure again, and then your responsibility model, essentially. And then you go through IAM. Like, I think IAM is the cornerstone of cloud security, and then just ensuring that that portion is intact. I think is a good start to rebuilding your environment if you can't delete it and try again.

Yeah, that makes sense.

I think I would ask the superpower question. So, now that we wanted clients to be realistic and not engage in magical thinking, but imagine that you do want to engage in magical thinking and you have some kind of a superpower or magic wand, this kind of pick your sci-fi metaphor of the moment, and to help you with your client security work. What sort of superpower would you want? Like, make every application least privileged. I don't know, something. I'm not putting words in your mouth.

I would want mental reconstruction, just the ability to replay everything in my mind like I'm watching a movie, just so I can— so a lot of times, you know, you're asked, why did you make decision A versus decision B? Why did you go this route versus this route? And just being able to replay that whole conversation in my head with the right people and not missing a single context would be amazing.

I love that.

Hmm, I love that, actually.

I'm gonna say 2 things. My first one, I feel like it's super obvious, but it would be needed. So the Superman super reading, like, it's just impossible to keep up with everything. Being able to quickly read and understand all the new technologies, everything that's coming out. And then I have to say this before we close, because this is Security Voices episode. If we could promote more and be able to get into the classrooms with women to understand and promote their technology, be able to show them what we're doing, if there's a superpower out there that does that, I would love to have it.

That would be a great superpower.

Yes.

Yeah. Okay. So, I hate to do it because it's been such a fun discussion where we've like blown everybody's mind in one way or another, but we have to ask our traditional closing questions. One, if you could tell people only one tip to help them work better at doing security better, what would it be? And 2, do you have recommended reading? And that recommended reading could be anything except Anton's blog. It can be Mary Oliver, it could be The Art of War, it could be a blog that's not Anton's, whatever you want.

I think for recommended reading, just keeping up with the news. I have this thing where I have created an RSS feed of TL;DR. Just security stuff that's going on around you and changes to the technology that we have right now. So, improvements of Google Cloud, for example, from Google Next, what has changed and what can we do with these changes? I think those are some good readings. So, Google Cloud Blog is probably my answer to that one.

Nice.

And the question in terms of what is the one thing that you should do?

One piece of advice. If you could only tell them one thing, what would you tell them?

I think my one piece of advice would be to test things out. Don't just read about them, but also, you know, open it in your environment and try it out, deploy things, try things, and learn from that way.

That sounds eerily similar to learn from your own mistakes. I like that advice.

Okay.

All right.

Well, with that, thank you two so much for joining us today. I think this has been a ton of fun. I've learned something. I think you blew Anton's mind. So, this was well done. Thank you.

Thank you so much. Thank you.

And now we are at time. Thank you very much for listening, and of course for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts. Also, you can find us at our website cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can follow us on Twitter, twitter.com/cloudsecpodcast. Your hosts are also on Twitter at Anton_Juvaikinen. Tweet at us, email us, argue with us, and if you like or hate what we hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode.

Security.