mWise Conference 2024 | Anton Chuvakin | Google Cloud

theCUBE.net

Clips
News
More from mWise Conference 2024

Cloud security paradox: Unpacking the shared responsibility model in the age of AI and risk acceptance

With the cost of security breaches hitting a record high in 2024, customers and providers can get caught up in the blame game of cloud security, ignoring the nuances of a shared responsibility model.Addressing modern cybersecurity concerns is complex because of what Anton Chuvakin (pictured), senior staff consultant, Office of the CISO, at Google LLC, calls the cloud security paradox.“It’s a paradox, but it’s also my obsession,” he said. “There was this line that every analyst knew, cloud is secure but clients are not using it securely and that most breach[es] [are] a customer fault

play_circle_outline Cloud security paradox: customers not using cloud securely, shift blame, improve client side.

play_circle_outline Accountability in breaches: shared responsibility, blame game, third-party connections, due diligence.

play_circle_outline Challenges in measuring and testing resilience in cybersecurity

play_circle_outline Excitement about securing AI and moving towards cloud modernization in cybersecurity

play_circle_outline Overhyped nature of AI for security, need for solid use cases to deliver results

Info
Transcript

Anton Chuvakin | Google Cloud

mWISE is in Denver, Colorado discussing the importance of proper cloud security. The conversation covers the blame game in breaches, the challenge of secure cloud use, and the significance of frameworks like NIST and Woke. Endpoint protection, the evolution of security, and the gap between security and data teams are also addressed. Resilience metrics, quantifying resilience, craft, and creativity in cybersecurity are emphasized. Securing AI and the future of cybersecurity are key areas of interest. There is ongoing debate over the most overhyped aspect of cy... Read more

explore Keep Exploring

What is the cloud security paradox and how can we encourage customers to use cloud security more effectively? add

What are some of the complexities and challenges surrounding shared responsibility models in cloud security? add

What are some indicators and metrics for exploring, deploying, and expanding the scope for resilience in critical infrastructure? add

What are some of the challenges and innovations in using AI for security and securing AI? add

What is your opinion on the current use of GenAI for security purposes and its effectiveness in solving various security issues? add

bolt Powered by CUBE AI

Anton Chuvakin | Google Cloud

search

>> Good afternoon security community and welcome back to mWISE. We're here up over 5,000 feet in Denver, Colorado, midway through day one of our power-packed coverage of the event. My name's Savannah Peterson. Delighted to be joined all week by John Furrier. John, we're keeping our hands toasty in our little mugs right now.

>> I mean, it's so hot in here in cloud security, but cold temperature-wise. And our next guest is on last year.

>> Is this liquid cooling or liquid heating?

>> Liquid heating, yeah. That's for the GPU.

>> Can't help myself there.

>> Anton is a great guest. He's got a great perspective from the CISO office. And to me, he's got a good view of the landscape within Google and outside, securing by design, intentional refactoring the infrastructure and application space is really part of it. So, looking forward to this segment.

>> I know. Without further ado, Anton, welcome back to the stage.

>> Perfect, thank you.

>> A CUBE regular. You've had a very busy day. Thanks for making the time.

>> Being number two or number 17, so let's hold on with the regular label, but we'll see.

>> We're starting to develop a pattern. We now have two data points, which definitely-

>> I agree, it's regular.

>> You've had a busy day so far. You gave a presentation earlier talking about the cloud security paradox. Tell me a little bit about that.

>> It's a paradox, but it's also my obsession because we have, from my analyst days, Gartner days, there was this line that every analyst knew, cloud is secure but clients are not using it securely, and that most breach is a customer fault. There are two sort of well-researched, well-founded lines, but they're also kind of interested in kind of I want to argue with them because they're true, but they're also kind of, as somebody that's blamey, they shift correctly the fault for some breaches to customers. But why is it the case? What can we do so that customers use cloud security? We build secure infrastructure, we get that, but cloud use is not always secure. So I wanted to distill it down to a framework that people can use rather than just talk about this. We want to have something that improves the client side of the shared responsibility matrix, not just ours.

>> I think that's actually really important and I think the blame game is quick to happen when it comes to breaches and anything else that happens. How do you help customers figure out how to or who to blame?

>> So I think that it may not be a really hot take, but remember the Snowflake debacle recently. The really interesting thing about this is that the media coverage of it really split into two pretty clean buckets. One bucket basically thought it's a cloud provider breach, even though it wasn't. And the other bucket claimed that it's a customer's. But in this case, the shared responsibility model came to life because it was very clear to me that some people unambiguously attribute fault to one side, but another group attributes fault to the other side. And they almost talk past each other but it indicates that the underlying problem of responsibility and who secures what is unsolved. I build a cloud, I give you MFA, you don't use it. You get hacked, who's at fault? Well, it depends on who you ask. How about I make it very easy for you to use MFA, and you still don't. Well, maybe that shifts the fault a little bit to you. Okay, I made MFA mandatory with a very difficult way to turn it off. You still turn it off, you get hacked. To me, there's subtle currents of responsibility that are different. So we want to build a cloud in such a way that most users is secure, or as my boss Phil Venables said, inevitably secure. This is much harder than building secure cloud as a provider. Building secure cloud use, enabling secure cloud use is way more tricky. And that's what I'm trying to explore and distill into something usable.

>> I love to embarrass Phil. I sent him a note earlier because he's not on this, he was on last year, called out in keynote by Kevin. And I want to get your thoughts on what Kevin said in the keynote around that point around accountability. He said, "It's about who accepts the risk," and this is the big question about accountability. How does that translate into the cyber? Because if I read and may say I own it, I mean who owns what? I mean this becomes the question because it's a risk management at the end of the day on one hand, but data on the other and then a lot of complexity in distributed computing environment. So it's a hard question.

>> It is a hard one.

>> What's your thoughts?

>> I want to start with a somewhat related joke that I think I've tweeted a few times and maybe now it's time for another one. There's a category of security leader that has this view that they would accept the risk for as long as it doesn't happen to them. But of course, it kind of defeats the purpose and of course breaks the definition of accepting the risk. To me with cloud, the genuinely questionable part is whose risk is it to accept? How are you making it easy for the other side to manage the risk? So if I give you the product that's very, very difficult to deploy securely and you decide to use it, did you accept the risk or not? Or did I push the risk to you and wash my hands off it? Now, if I made a product very easy to secure and I provided guidance and tools and a little AI chatbot that says you do this, don't do that, yet you decide to go absolutely the opposite, clicked through five warnings, don't ever do that, don't ever do that and still did it, then you clearly accepted the risk. That part is much more unambiguous, but there are a lot of gray area where it's already clear when you accepted the risk. What a great point.

>> Taylor Lehmann brought this up on our previous segment. I want to double down on that because when I brought up the notion of supply chain, we all thought, oh, it's in the hardware. Of course, Silicon data supply chain. Now you've got agentic systems, but he brought up an interesting point of what I brought up, third-party applications. Now you have third-party connections where data's going through APIs. Kind of rolled his eyes like, okay, that's a long conversation.

>> Yes.

>> But it brings up the whole accountability. His big point was people say they're secure and they're not, or they fill out some mechanism checkbox. He was big on that and I am with him on that. So how do you talk to customers saying, well, you deal with third-party partners. Is there a due diligence? Is there a mechanism? This is a big point, this is not talked about much, but what's your reaction?

>> My reaction is while it sounds complicated, it's actually a lot more complicated. And here's the example from the, again, accepting the risk. I use a SaaS provider for some business process. There is a shared responsibility model, SaaS provider does this, I do this for security. But the SaaS provider beckons to IIS. There is actually a three-party model and the IIS may use partners, may use contract developers. You may have other things connected to an API. In many cases it's a lot harder to even point a finger and say third party, because I can say you build this application for me and data got stolen and they say, "Oh, it's stolen from the S3 Bucket." And I'm like, "You are a different company. I don't have this cloud relationship. I have relationship with you." And they say, "Not our fault, it's them." That's a much trickier one.

>> Pretty porous, the responsibility.

>> Nobody wants to hold the responsibility in that case.

>> This is the end-to-end workload arguments.

>> Yes.

>> Can you go end-to-end with observability type, maybe not specifically, but management technology. This becomes a really interesting concept.

>> Yes.

>> And this brings up the role of frameworks because we're hearing again, there's more frameworks. NIST is doing some great work, Woke is doing some great work, the Open Foundation. So you're starting to see standards bodies getting highly involved. Quantum NIST is doing some good work on that piece.

>> Oh, yeah.

>> What's your take on this? Because now we have to solve this problem. What are customers deal doing with that right now?

>> I mean to me, when... Frameworks exist for many of these things, so I'm not a Post-Quantum kind of guy. I don't really do encryption. But as far as frameworks, to me one thing that before you apply any kind of framework, whether it's supply chain or traditional kind of guidance for security, you should have at least all the parties and all the components should be on the table because it's not enough to say this is the approach between you and me. I mean I don't want to have an unknown third, fourth, fifth, whatever other parties. So to me, visibility implies you actually see all the pieces first. I mean people sometimes argue about do you know all the assets. In the cloud, you can call an API and you know all the systems, you're not going to have a server in a closet. And people say in the cloud, asset management's much easier. But at the same time, somebody can whip out a credit card and buy their own cloud. And so in your cloud, you know all the assets, but you don't know that your business actually has this other cloud. So to me, frameworks do rely on a very robust asset management. And it's not very 2024 cool security advice, but it's something that makes the rest not very workable. Unless you know what you have in the cloud and which cloud, most of the rest of the stuff can't be applied.

>> Well, and you can't build secure things on top of that. I mean, the visual that's coming to my mind right now is you get a Lego kit and you pour out all the pieces to kind of do your inventory and make sure you have four of this and seven of that or whatever. So you're not going to end up in a place where you built it and it's not going to work.

>> Or you have pieces of Lego from a bottomless box. You don't really know what would show up and you can't really finish because who knows what else is in there.

>> Yeah. So building on the Lego analogy, let's say we built our Lego kit, our creation, our Lego server for this moment, there's a big myth around set it and forget it. I can't just leave my little Lego server alone, right? There's going to be an adaptive threat landscape.

>> I mean yes, and given that most of my time I spend in areas related to detection and response, sometimes I have to argue with people who say if you build things in a more secure by default scale by design manner, everything as in infrastructure, code, everything is pipelined, verified, validated, then runtime stuff can just be left alone. And I usually recoil in horror and say, "No. Just because you do your stuff on the left shift left 10 times better than everybody else, it does not mean you have to get to drop the runtime stuff. It's like you still have to have D&R, detection and response." So to me, improvements on how you build, how you deploy, all help, all reduce risk. They're all great, but none of them removes the need for observation, for detection. To me, there's no amount you can switch your investment from a thousand bucks to a billion. You're not going to then have zero in D&R. To me, that's like a law of the universe.

>> So talk about the evolution of endpoint protection because you bring up some good points. Is that state of the art now? Is that where the action is? Because now the service area Is increased. You got training poisoning with the GenAI. You got prompting checks, which everyone talks about, but the training was even bigger. And then all this stuff around data is key. So you started see more areas getting very porous. So is there even an endpoint?

>> This is where, so I don't want boast, but some of you know that I coined the term EDR back in 2013. And this started the kind of how let's do EDR, let's deploy more EDR. And then over time, people started thinking what are the domains are there for D&R? And I mean for cloud specifically, if you do EDR, it implies you have an E, but it's debatable. It may have APIs, you may have containers where EDR sort of fit well and you have servers where there's no E, and no amount of EDRing would make you better. There's no E, undeployed. So people are trying to invent all sorts of related tech like cloud detection and response. There's somebody who showed up with data detection and response. There's also a recent movement to do ADR, application detection and response, and they're all going to try to fit in the new reality of cloud where there's no E.

>> So endpoint detection and response, EDR, makes sense when you're attaching or connecting to server. Congratulations on, I didn't know you coined the term, but that's good with good trivia and we're in honor of a legend. Thank you for sharing. But it's situational because if you take the E away, it's something else. So it's situational. That's what your point is.

>> Yes. That if it's a cloud application that doesn't run on any servers, virtual machines, EDR is NA, not applicable.

>> Okay, so what's the new turning of a coin now?

>> Oh, I'm not at Gartner anymore. So I don't really do acronym machinery anymore. But I do make fun of other people's acronyms because of course five-letter acronyms to me a big no-no. Don't do five-letter-

>> Three is the number.

>> Three, and if you really push it four, but five is to me a bit of a...

>> At that point, it's a word basically.

>> You like SASE? I'm not a big fan of SASE.

>> I'm not a big fan of SASE. But I mean-

>> I mean at least.

>> The name is very sassy and I think Neil is a great analyst who coined the term. But at the same time, SASE has confused quite a bit of people because like zero trust, sassy... There's also sassy without an A, right? There's SSE, which makes it all very fun to watch.

>> To simplify it for the people watching, how do you build the secure next-generation environment? Because when we look at the data from the keynote, they need solution strategies. They don't need another product, or they need it if they need it. So it's not like just buying what they can, even though they still do that. What are successful strategies that you prescribe or you recommend or would put on the table for customers?

>> So this question has a certain fork in the road that happens very quickly. There are customers who sort of insist on largely traditional what I would call 1990s tech stack and almost certainly 1990s processes. If you ask, can I achieve this amazing result in security while keeping this, the answer is actually no. I think it's almost like I want to transform as long as my life stays the same, not a thing. You can't do it. The answer is no. There's no answer. So the challenge is how do you transform in the way that fits your org? How do you adopt modern stack and also don't drag all processes? There's somebody, you brought up an example of containers being part of the modern tech stack and how people often SSH remote connect to containers. And I was like, no, that's from the old world. Containers are deployed through pipelines. This is how you do all this stuff. You don't connect as an admin to a container. That's not a thing. And they say, here we do in whatever environment because the old practical-

>> Legacy.

>> Yeah. The old practice and people converge with new tech, but the result is then old. So, old process split plus new tech, result is old.

>> So the foundations, built on wrong foundation.

>> But changing in tech is easier. So then you almost tell people you shifted from servers to VMs to containers, that's great. But your IT is kind of still '90s DNA IT. And so a lot of solutions we have for you won't fit.

>> What's your take on the cloud native? Because we're going to be at the Linux Foundation event. Kubernetes is getting boring and good sign like Linux. What has to happen in cloud native to bring in this next era of data-driven, threat detection, intentional design, secure-by-design platforms for security? Are we almost there? Do you see us kind of... Because there's a runtime piece there with Kubernetes. We've got pipelines, all kinds of microservices.

>> But adoption to me is not... I mean adopting the tech without adopting the modern processes to me is where it breaks in most cases. You can be, and my Kubernetes and connection example is there, but there are also many other examples where somebody adopted the tech stack but didn't adopt the process that the designers and inventors of the tech stack assumed. It's almost like you get a little bit DevOps or SRE at Google and you look at tech stack and you say tech stack I like, but I want my once a quarter change management report kind of process and they don't mix.

>> It's a disconnect.

>> The process culture part is hard and I want more evolution there. I think with tech stack we are way better than before. Culture...

>> It's like the dogma. They're used to their ways, it's hard to change. Shifting to that data analytics and the data-driven insights into threat detection brings up the question that we've been talking about all week. I wrote a research note this morning about this, the gap between security and data teams. Now you know the history was security teams are security teams, we know what they look like, we know and love them, they're doing their job within a lot of chaos, but it's really well known. Data scientists used to drive all the analytics, but now the data engineering role is emerging out of the platform DevSecOps side. So that's an infrastructure kind of thinking. So these are coming together. What's your thoughts on that? Because that creates an opportunity, but also to your point about dogma and pre-existing views. What's your take on this?

>> I think that in the past, in the old times, a security team and data team were connected maybe through DLP or through some other data security, maybe key management encryption. So they were sort of data security tech that had to be the connection tissue. But in the data security and data being processed, analyzed in a bunch of new ways, a lot of old stuff doesn't fit. So technologies that showed up that are called DSPM, data security posture management, are kind of attempts to modernize the data security to catch up with data, so like data evolved. But data security was kind of not quite fitting and right now, it's trying to catch up. That's my impression. I deal with it a bit less than before, but I feel like this is the same example of security catching up with IT and business beckoning our vein of existence.

>> I mean at the end of the day you start to see the pattern and we talked about it earlier, storage companies rebrand, call themselves cyber resilient. They go public like Rubrik. I mean security is a data challenge and risk management, it's still going on storage. Okay, I'll call myself a security company. They get better valuation. But we hear from the keynote from Kevin and also here from the experts from Google, resilience is a hard thing to measure because there's different scopes and perspectives of resilience. How do you look at the resilience equation? How do you test resilience, stress testing systems under critical scale, or how do you get that resilience? Is there a formula? Is there-

>> How do you quantify it? What's the metric? What's the metric for resilience?

>> Definition and metrics.

>> There's a kind of incredible amount of work going on in Google, and of course, Phil participated in the PCAST report on resilience, cyber physical resilience for critical infrastructure. And one of the things that came out of this report is 10 indicators. They have for kind of like exploring, deploying, expanding the scope for resilience. And we're trying to attach metrics to some of them because you're right, some of the stuff is very practical but hard to start. Like you say, I want this to be independent of internet connection failures, great goal. How do I do that? How independent am I really? You don't want to be that person, that ransomware victim whose backup relied on active directory, which was ransomware. So the result is I can restore from backups. Yes, backup server calls identity and identity is encrypted by ransomware attackers. So you kind of can do it, but you can't really do it. So to me, this is like a circle of dependency for reboot. There's a science and there's a craft for doing it not that way, but it's a lot harder to explain and measure and this is what the PCAST and similar work by various consortia is focused on.

>> You're the first person that brought the word craft, and I think that's important, this mechanism.

>> It's not all science, it's somewhat with craft.

>> It's like crafting. You got to put a little art and science into it.

>> Yes. Art isn't-

>> Not art.

>> But I mean that's why again it's a science and craft because-

>> Creativity.

>> Yes, creativity for sure. Yes.

>> I mean knowing kind of how the world my systems work, not the playbook.

>> Well, I'm glad it did.

>> Yes, correct.

>> Yeah. And with all the increase in data, you've got different sources of things coming into that ecosystem.

>> Correct.

>> Yeah, it's all can of worms. All right, you came up here and your energy was very zesty and I appreciated that right away. So I'm going to ask you two closing questions.

>> Sure.

>> What excites you the most about our security future?

>> So I'm going to give you a two-part answer, and one is kind of conventional, honest, conventional, and the one makes my PR people happy, which is of course AI. I do see a lot of fun things, a lot of innovation down both using AI for security and securing AI. A lot of my daily work connected to sort of talking to clients about securing, how I use AI for business, secure AI usage. There are certain parallels from secure cloud usage to secure AI usage. But to me, the distilling the novelty of securing AI and learning those lessons, learning the mistakes is very fun. And I think to me, this is not just about can I have the AI firewall? Yes, actually you can have an AI firewall, but you can have this other stuff that some of it is different, some of it is similar. But to me, this is very interesting, very novel. Startups, big companies, us, AI designers, customers, there's a lot of innovation and a lot of it solves genuine problems. So AI to me is fun. Some people say it's a cliche, some people say it's starting to slid off the hype cycle. Yes, very true. But there's still a lot of really interesting insightful work. And to me, the second part is actually this bit that I brought up about secure use of cloud because we still have people who have going through transformation and all that stuff and you sort of assume it is AI. But when you talk to them, you realize they're actually transforming to cloud, which was one of my moments. I was assuming they mean AI, but they actually meant cloud. They're in the previous revolution. So a lot of this is still not a solved problem. And there are enough companies that are sort of exploring how to modernize and move to cloud, modernize security, modernize security operations, modernize other things, and also move to cloud. A lot of this does call for a lot of interest in new thinking, not just, "Hey, here's some fresh new tools, version tool, or deploy them." It's not like that. A lot of these calls for change.

>> I think that's a really good point. And communicating about priorities and why that needs to happen as well, which is a big part of why people resist change. All right, last question for you. Well now I'm actually curious what you're going to say this. What do you think is the most overhyped thing in cyber security?

>> The most overhyped thing in cyber security? There's a lot of competition for this title and it's kind of more of probably a better RSA question than an mWISE question. Ultimately, I would still bring up AI because I feel like in using AI for security, we are in the use case search phase. We are looking for areas where GenAI delivers results. And as a result, when we go on a use case hunt, we collectively, we see a lot of use cases that just don't work. But people who have a very bizarre, optimistic take that GenAI would solve almost like every security problem, to me, they're wrong. They're solid, robust use cases but if you do this, not that, you're going to be disappointed. You're going to have disappointed clients. So to me, GenAI for security is probably overhyped. But at the same time, there are very good solid use cases where it delivers magic.

>> Maybe in next shoot, you could do a talk on AI by design.

>> AI security by design is kind of now, not next year. So I think it's, yeah.

>> A follow.

>> Good job.

>> Awesome. Anton, this has been a really exciting conversation. You brought the heat, we appreciate it. I'm actually physically warmer than I was sitting here 20 minutes ago.

>> This is very fun. I mean, this is the kind of why we do it, right?

>> Appreciate it.

>> We appreciate it. Thank you, John. Always insightful with your questions. And thank all of you fabulous cybersecurity community individuals who are tuning into our two days of live coverage here in Denver, Colorado at mWISE. My name's Savannah Peterson. You're watching theCUBE, the leading source for security news.