EP46 Products and Solutions: Helping Our Customers Precipitate Change

Security. Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Timothy Peacock, the product manager for threat detection here at Google Cloud, and Anton Chuvakin, a reformed, tamed analyst and member of the cloud security team. Here at Google. You can find and subscribe to this podcast wherever podcasts are available, as well as at our website, which it only took us 6 months, but we did finally launch it, cloud.withgoogle.com/cloudsecurity/podcast. If you like our content and want it delivered to you piping hot every Monday afternoon Pacific time, please do hit that subscribe button. You can follow the show and argue with us on Twitter as well, twitter.com/cloudsecuritypodcast. Finally, we are getting towards the end of 2021, and we are taking a brief break for the holidays. So Anton and I will be gone, but stay tuned, episodes will come back out in January. Anton, we've got an episode about solutions today, which doesn't just mean we're dissolving things, we're solving problems, right?

Well, actually, my fear with the solutions episode was that This episode may be a little too dry.

Well, listeners do not need to get out the ethyl alcohol solution to enjoy this episode. I think there's actually a lot of really interesting content in here, particularly when it comes to the interesting question of how do you make a SOC more effective?

But it's also how do you consume products and how do you consume maybe services? How do you consume advice on, say, how to transform something? It's very easy to imagine that you buy a box, it's a product, you plug it You turn it on or you push an API call button, whatever, and you have something. But solution that involves, say, cultural change or transforming your security operations or implementing different principles or changing how your people do stuff, that's really hard. And I don't really think that's in the charter of a product.

No. Well, I don't think I often sit around as a PM and put transform my user psychology on the roadmap.

Or change the culture button. Like there's like little red button that you push in the product and it says, change culture. And once you're done, they just adopt DevOps, for example, like next morning maybe.

I'm going to talk to engineering about that. Perhaps with that, listeners, before we get too off the beaten track here, I want to welcome today's guests. We're joined today by Allison Reyes, a Director of Security Solutions, and returning podcast guest, Aman Ganazada, a Security Solutions Manager. And I think his title might've changed since the last time we talked to him. I wanted to start off just with a real, what I hope is a softball question here. What's our thinking when it comes to solutions versus products for security? Sure, like security is a process, not a product. And listeners, I'm doing air quotes there. Where do solutions fit into the story here?

Yeah, that's a great question, Tim. So, I mean, ultimately, when we think about security solutions in particular, we think about the fact that Google Cloud and any cloud for that matter is relatively complex, right? We have a plethora of capabilities. In Google Cloud Platform, we also have tens of products that one could avail themselves in on the cloud security product side. And so, piecing all of that together into expedited patterns where we know based on the best practices of working and engaging with thousands of other accounts, we can compile all that together into a core set of solutions that will accelerate customer time to value. So, it's all about ensuring that we understand how customers are using our platform securely, compliantly, and then sharing those best practices and the repeatable offerings with our customers through solutions.

I was actually a chemistry undergrad before I switched to political science. These are actually mixtures. We're not talking about a single thing dissolved in a single solvent. We're talking about a bunch of things stirred together to make it easier for users to adopt.

That's right. These are hopefully relatively complex but beautiful chemical equations, right? What we're trying to do is piece together multiple products in such a way that we know customers are going to get the most value out of them. A great example of that might be our web application and API protection solution, right? We've got 3 distinct products in the form of Cloud Armor and Apigee and reCAPTCHA, all of which are valuable unto themselves, but pieced together provide that true end-to-end web application protection. So that's a perfect example of a multi-product solution.

That's a great example. I love that.

To look at it from another position, Google is sometimes known for writing code and just giving it to clients, hoping that they figure out what to do with it. So do solutions change this dynamic, at least for security? How is this working in terms of getting our products more usable and more useful for real problems?

Yeah, Anton, so that's exactly why we piece together solutions. If you think about it, AWS established this idea of shared responsibility model when it comes to how customers and cloud providers should operate. And the reality is that I have always felt that that is necessary but insufficient in terms of helping customers, in particular when it comes to operating securely and compliantly in cloud. And so, we spend a fair amount of time with our security solutions really focused on how we actually can help customers from day zero configuration through operation of day end to ensure that they can actually configure securely and then remain secure and compliant throughout the cloud journey.

That makes a ton of sense. So Aman, one of the things I know we want to do here is, again, listeners in air quotes, transform how our users operate. And so solutions has a lot to do with that, but are we really going to transform how people operate? Like, can we really teach the world to do it the way we do it or the way we think they should do it?

That's a great call-out. I think one of the ways that we hope to influence users, I mean, take a look back at history and see how Google has made an impact in the world with containers, with the advent of SRE and Site Reliability Engineering. I mean, even if we dial down on that, what Site Reliability Engineering did to the traditional ops space really was winning the hearts and minds of all the people who work day in and day out in this field, right? So, a transformation is not simply just, hey, we bought a new product and we need to turn it on. A transformation is, hey, the organization, the execs, and the engineers are all going through this cultural evolution of how we start to revamp the way that we operate. And if you think about where we're headed from a security perspective, as more and more organizations go to these complex multi-cloud environments, the adversaries only have more data at their disposal, right? There's only more threat vectors for them to sort of manipulate to achieve their outcomes. And we've got more and more critical data that's being hosted on the cloud, more critical workloads from financial services businesses to healthcare clients. And so the battle against the adversaries is only getting more complex. And so for me, you know, I oversee the security operations solutions portfolio. What we're trying to do with— Anton, you're familiar with this, right? Autonomic security operations.

Yeah.

Is really helping organizations see a path that they can pursue that'll help them achieve this inside-out transformation of how they leverage their people, how they challenge the way that their people operate in their existing technology landscape, how they leverage tools to their advantage, right? Cutting-edge technologies like Chronicle and such, and how we can really drive a multi-year journey where we help organizations really see a path to like, hey, we've got a couple amazing products on the roadmap, but how do we actually take advantage of this whole stack and drive it through so that we're maximizing our ROI?

To further on that theme, you mentioned the ASO solution. I mean, obviously, this is quite dear to my heart. And of course, when you were building the solution, And I was helping out, we kind of mentioned that we're going to 10x the SOC. And of course, 10x thinking is kind of an old tradition at Google. So, is this 10x real? Can we really transform somebody's security operations center and make it better 10 times in some dimension? Like, what is this 10x thing, and how does it work here?

I'm actually going to turn that question around to you because you wrote a blog post on this, right? So, what are your thoughts on how we can actually drive A 10x improvement, what does that actually mean? Because we hear a lot of people that are like, whoa, it's impossible to 10x. I can't even imagine what I'm going to do in a year to think that it's going to be 10 times better than what I do today.

So funny enough, when I was studying this history of this whole 10x thinking, I found a piece by Astro Teller from Google X where he said that sometimes it's easier to improve things 10x than by 10%. To me, the same thought applies to SOC. Imagine improving your SOC by 10% every year for 10 years and still not quite measuring up. That's hard work. So sometimes if we change the culture, like change the practices, infuse SOC with some of the lessons from SRE, from DevOps, we actually have a chance of changing things dramatically and immediately when people start using detection as code more, people start automating more rather than just toiling in the SOC. So to me, we haven't really done the measurements. Is it really 10x for everybody? So we don't guarantee 10x improvement, but we certainly see areas where we If you think about what DevOps did, development and operations space, right?

It has radicalized an entire industry of people who are so excited, almost cult-like in a way, to rally behind this philosophy, this approach of how we do development and operations in today's complex environments. And if you think about security and the SOC, we have like the same issues where we've got the leading companies, the Netflixes and Googles and Snaps of the world who, you know, have the best security teams in the world, but then you have the rest of the world who highly motivated, highly inspired, and highly disciplined workforces.

We do.

Tim, I think you're one of them. Yeah, I would have to imagine.

I want to pick at something here though. What does 10x mean in this context? Are we going to handle 10x more tickets? Are we going to be 10x happier, 10x more secure? How do you measure this? What are you actually 10xing? Is it my bank account? Because I'd like that.

So when we look at the ASO framework, when we started writing this white paper, we thought about, you know, all the different elements in a SOC. We went back to sort of the people, process, tech, and we added a 4th dimension, which was influence. Influence is the ability for the SOC to have influence to be able to drive change upstream, which is probably one of the more critical factors of building a highly effective security operations team. Oftentimes, you know, we always hear the results. Most security incidents happen due to something that happened upstream, and then, you know, the SOC is there just to clean up the dirty work. Influence is really the concept that SOC analysts should be empowered as they're closest to the attacker to be able to help drive change that'll help make their workloads lighter and then also help solve significant challenges for the businesses. But when we look at those 4 constructs and those elements, we then break them down into, okay, so what is actually going to be a significant improvement over the way we do our triage in the SOC today from traditional tier-based organizations that have a level 1, 2, and 3 SOC? versus, you know, migrating to a skills-based SOC. How does that sort of impact not just the triage process, but how does that also drive a magnitude of impact to all the surrounding elements of the SOC, from how inspired the team is to how they're challenging problems and so on and so forth? Anton, I know you had a couple other thoughts here that you had outlined in the blog, so I'll pass it off to you.

Wait, Anton, you better pick up the slack here, though, bud, because all I heard was we're going to 10x the influence, and I still don't know how to measure influence, although maybe the PM promo committees here The point about influence is actually interesting because, in fact, I made the same point when I was speaking on this recently when I said that sometimes we 10x the SOC by changing things outside of a SOC.

And the example I usually bring up is really not about influence but about phishing. If SOC manages to influence how IT and other security teams deal with phishing, SOC may have half of the work. Many traditional SOCs I encounter deal maybe 40%, 50% of time with phishing. But companies like Google essentially fixed phishing. Like, we don't really have phishing. So our SOC equivalent doesn't spend any time on phishing because we don't have it. If you fix phishing, which is what you do outside of a SOC, you kind of 2x the SOC because you remove half of your workload. So that's an example I usually give. But how can SOC fix things that are outside of a SOC? By growing influence. We don't have a full influence manual. Influence operations manual sounds even more ominous. than an ASIL paper, but we do give some advice on how SOC can change how companies do security hygiene, for example, so that you can almost immediately 2x the SOC without changing anything in the SOC. That to me is one example that I like to give. Sorry for hijacking the story here.

I agree that if you do a lot of the things that we do, you can cut out the pain of phishing, but in that case, you've still only 2x the SOC and we're off by a factor now of 5. from 10x-ing the SOC. I think I remain skeptical on this goal of 10x-ing the SOC, if only because I'm not sure we've measured the SOC yet.

I'm sure Iman has stories from customers who reported dramatic improvements about how they do things. Like, even service providers who follow the model, like some of the Chronicle partners, can definitely report dramatic changes, not just slight improvement, right, Iman?

Yeah, so we definitely have been seeing the ASO philosophy saturating in the hearts and minds of not just analysts, but a lot of executives. I mean, the solution story is really a CISO-led approach. We've got CISOs who need to solve business challenges. We've got highly motivated CISOs in cloud-native companies, but then traditional enterprises, they're thinking of things like, how do I actually inspire my workforce to solve bigger and better problems? How do I get them to take on more work, right? How do I get them to drive a more engineering-centric approach to work? So, the ASO story as a philosophy, you know, we're starting to see a lot of traction with industry executives who are reading the paper, who are coming back and saying, like, this is exactly where we want to go. And then we have other executives from, you know, some of the leading companies that are saying, this is exactly what we think we do today, but we've never actually had a name or a brand associated with it. So, we often see it's kind of like we're trying to do what DevOps did to the world. With ASO. We're trying to formalize this approach and this idea so that we can actually help those organizations and those execs who are struggling with threat management to sort of transform the way that they do their work. And then, for our partners, this has been a story that has really landed well with our partners, especially our Chronicle partners. Our Chronicle partners have looked at the ASO narrative, and they said, this is exactly where we see our value proposition. You can buy Chronicle as a product, but if you don't know how to actually turn it on and leverage it in the best capacity and leverage your dashboards, leverage the rules engine in Chronicle, and sort of harmonize all the different data you have together, then you're not actually going to drive value from it. And how many organizations do we see that are like, they use Splunk and then they're also POCing another product and they're always in between this flux, right? So, for our partners, they really like this idea Because it helps them take this story of actually driving customers through the maturity, through the phases to actually drive this transformation, and actually owning that because they're most equipped to be there on the ground, in the field, in the trenches with customers, whether it's from an engineering standpoint, whether it's from, you know, a staff augmentation standpoint, or whether it's from really being that trusted advisor for our customers.

I don't think you can get away from the fact that this is a giant change management exercise. Cloud transformation implies security transformation. That implies organizational change as well. And so, I think it's really important that we not lose sight of that part, especially when we think in the order of SOC transformation, because there are humans involved who are deeply skilled in technologies that are actually becoming out of date. And so, those need to actually modernize. They need to become more efficient, the tools themselves, but also the people. And the ASO solution is about enabling that transformation. Not just at the technology layer, but at the human level as well, which is incredibly important. And I just wanted to circle back, Tim, really quickly on the 10x piece.

Oh yeah, please.

There was one example that we talked about, right, about the, what I would consider to be adjacencies, you know, the upstream and the downstream activities in security that so often influence what happens in the SOC. But there are so many others. And so, if we start to add those up, then you'll start to inch towards that 10x number. So, for example, locking down your software supply chains is another one, right? So, when I am, managing application development, or if I'm managing like the infrastructure as code that's actually configuring my cloud instances, right? Each of those things can be managed through software development pipeline with DevSecOps that allows me to confirm the validity of my code. That's another example of where, you know, that you can have assurances in place, which of course we will all verify, but assurances that we're not going to be deploying terrible malicious code inside of the environment. We could probably talk all day about 5 or 10 other instances of this, but I think as you add those things up, you realize that the SOC influence is actually deeply important in the story.

I think that makes a ton of sense. And the SOC definitely embodies the John Donne thing of no organization is an island unto itself. It needs to have that upstream and downstream influence in order to, you know, not just be the dumping ground of sadness.

You know, it's funny, I actually observed something earlier today. I was looking at our internal DFIR team, and I noticed that a lot of these folks, all good friends of ours, obviously, But a lot of them have been here for 8 years, 10 years, 6 years. The security operations industry is notorious for high turnover, for exhausting roles and on-calls. And CISOs, apparently the average tenure for CISOs is like a year and 8 months, right? But at Google, the ops folks here have been here for so long. And it's like, how do we get to win the hearts of analysts and incident responders to the point where they love doing their job? Yeah. Because if they don't love doing their job, then we're just going to be in this turmoil of being a high burnout industry. And if we really want to get people excited for this change, then yeah, it starts here. It starts with how we look at the problem, how we approach the problem. And ideally, what happens is we start to get those traditional tiered-based SOCs out of this model and driving more towards this place where they've got highly motivated and disciplined workforce.

That makes sense. And funny enough, we do bring up that theme in the paper. My conversations with the same team revealed that they treat this lack of burnout, of work-life balance, as kind of one of the tenets for SOC success, which to me struck me as somewhat illogical first. Like, give me some magic tools, give me some secret Google processes. Why are you telling me that your people are happier? But to me, maybe it is one of the secrets that our people are happier, and how we made them happier is kind of the secret.

So.

Yeah.

That sounds a little rambling, but we do give some advice in the paper on this. We're starting to run out of time, and I wanted to get to the final question to sort of connect this whole solution story and ESO story to the bigger announcement that Google made around Google Cybersecurity Action Team. So how do solutions fit with this whole announcement? Do we need more action figures now? How do we approach this, Alison?

First of all, I'm at the top of the list when it comes to the Anton action figure.

We're getting an Anton action figure?

On board for that one, for sure.

Wow. As long as it's not an Anton voodoo doll.

No.

It depends on the day, right?

I think it depends on what the analyst opinion of your startup is and where you landed on the Magic Quadrant, really, on whether it's the bobblehead or the voodoo doll.

Seriously, going back to the Cybersecurity Action Team, you know, there are all these different pieces to it. I'm sure you've spoken about the trust and advisory services and threat intelligence and so forth. Solutions engineering is indeed a critical part of the GCAT. Why? Because we look at ourselves as sort of the activation team, where we're actually distilling and distributing these repeatable best practices that Google Cloud is coming up with day in and day out. Through our experience with customers, through joint development efforts, through our own internal learnings and expertise on the products, we can then turn around and release these solutions that we know are actually going to be meaningful and impactful In, like I said, accelerating and simplifying the cloud transformation for customers, while also ensuring that we've got some real integrity around the solutions process. So, an example of that is, you know, the Secure Solution Design Review process that we have internally, where we actually go around and we review solutions across the portfolio to ensure that we're aligning those with Google Cloud best practices. That is part and parcel to GCAD. It's something that actually didn't exist prior to, and is super important for ensuring that when customers actually interact with us and leverage our solutions, they know that certain security checks have gone into those.

That makes a ton of sense. Allison, Iman, I want to thank you two so much, not only for joining us today, but also for putting up with my line of questioning on the 10x thing. It's always nice when we get podcast guests who are game to get picked on a little bit and, you know, really get deep on something. Listeners, thank you for joining us today.

Tim, you might pick on me today, but tomorrow I'll pick on you.

I bet you will.

Turnabout is fair play.

Yeah.

It is a multi-round game for sure.

Thanks, everyone.

Take care, everyone.

And now we are at time. Thank you very much for listening to us for the entire year. Of course, thanks for subscribing as well. This is our last episode for 2021. You can find this podcast and listen to all the episodes while we're on the break at Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts. Of course, you have to visit our website, Multiple times while we're away. cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss future episodes in 2022. You can also follow us on Twitter at twitter.com/cloudsecpodcast. I will try to keep some lively discussion there. You can also find us on Twitter, Anton_Chuvaikin and _TimPeacock. Tweet at us, email us, argue with us. And if you like or hate what you hear, we can invite you to the next episode. Next year. Finally, don't despair. We're gonna come back in January with a lot of fun episodes. See you on the next Cloud Security Podcast episode in 2022.

Thank you, Roni.