EP167 Stolen Cards and Fake Accounts: Defending Google Cloud Against Abuse

Security.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Tim Peacock, the Senior PM for Cloud and UEBA in Chronicle 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 listeners on our community page. You find the link to that as well as to our YouTube channel where the digital video version of this is hosted in our show notes. Anton, this is another one in our Voices series. Delighted to have on the show with us today somebody I've worked with closely Nearly my entire time at Google. Somebody with a fascinating background. And for those who join us on the video, we got to see you do an analyst dance, which was to me just delightful.

There was a little bit of an analyst dance. Yeah, there was at least a little bit. Like a mini dance.

A mini dance. A mini dance. Yeah, that was great. But what are we talking about today aside from dunk tanks?

Yeah, dunk tanks would make an appearance. Unfortunately, no pictures, as I was told in no ambiguous terms. We are actually talking about abuse. And this is way more fascinating than people assume because, well, you'd know the reasons in a few moments.

Well, I'd assume it's pretty fascinating. I mean, imagine all the abuse that must go on to a major cloud platform.

Correct, correct. But I think the whole difference between security and abuse is very hard.

Yes, yes, that is very hard.

And the relationship is not obvious.

Not obvious at all. And I think we got into a lot of places where that's quite a nuanced discussion.

Yes.

And so maybe without any further ado, listeners, let's welcome today's guest. Today we're joined by Maria Riaz, an engineering lead for counterabuse here at Google Cloud. And we have joining us as a special co-host today, Mohammed Khan, a senior engineering manager here at Google Cloud. Maria, real softball question. And listeners, I say softball question because Maria is the only person to join us on the podcast who has Sunk me in a dunk tank with a softball. Maria, could you give us answer to the softball question, please? What do you do here, and what does Counter-Abuse Lead even mean?

Yeah, that's a good question. And I think that we made a good team because you were in the seat for dunking, but then you were also encouraging me, like really giving me the incentive to take the right aim at you.

You guys have to post pictures, by the way. You do know that, right? So in the show notes—

No, there won't be any pictures of me in the dunk tank, I promise.

Okay.

So aside from our teamwork there, we've also worked together in our real work. And why don't you tell the audience about that?

Yeah, so me and Tim, we have worked closely on a number of efforts over the last couple of years. My initial interaction was in the context of Cloud Security Center, and we provided one of the signal to Security Center related to service account leak credentials. And there are many other things that we do in the space of cloud abuse, which have a good overlap with cloud security. And some of the things that we do in Cloud Abuse is essentially protecting Google systems and users from different types of security and abuse vectors. So essentially, when we think about what does abuse mean, when we are building products as engineers, we are building with all the great and amazing use cases in mind. Like, you know, there'll be these awesome features. In GCP context, we have computational resources, we have network, storage, APIs.

Mm-hmm.

And we're always thinking that these are going to be used as intended, but a lot of the time there are users who use our systems in the ways which we didn't even think about. And in fact, these are the ways we don't want them to use our systems. Essentially, these are against the terms of service or acceptable use policies for our systems. So this is what we mean in the broad sense of counterabuse. And I lead the engineering team at Google for counterabuse. We have a good partnership with many other teams in capacity, trust and safety, payments risk, security teams, and a lot of the policy and compliance folks as well.

I do have to give our users credit for their endless creativity in finding ways we didn't intend for them to use our systems.

But let me— I am puzzled. And I don't want to use a 3:00 AM metaphor again. But if somebody asks you, is this cybersecurity or not? What is your answer? Like, how do you think in terms of counter-abuse versus cybersecurity? Like, are they peers? One includes another? There's a Venn diagram?

I think the Venn diagram might be a good analogy because there are things which are in the intersection of security and abuse, and then there are things which we just purely made for abuse. For example, let's say, let's think about the incentives for the users. Somebody wants to use GCP capabilities without ever having to pay for using those resources and capabilities. So one way to do that is that you create a lot of accounts and each account gets some free resources or some access to resources, and then you just keep creating more and more accounts and you keep getting access to a lot of more resources. So essentially you scale horizontally across a lot of projects and a lot of user accounts.

That's a very natural way to use cloud, horizontal scaling. I love it.

Yes, at least that's where we can maybe agree on, on the use case with the abusers. So that's one way you are intentionally using the platform in a way that it's against the allowed usage policies. So that's kind of different from typical security. There's nobody getting compromised. There is no security vulnerability that is being exploited. It's just that people are trying to bypass some of our quota controls, try to bypass some of our preventative controls and so on. But we also see overlap with security where for good customers, sometimes if we see that they are doing abuse or they are starting to use resources way beyond they usually use, then maybe there's something going on. Maybe they accidentally leaked their credentials in some public repository and then somebody got hold of that and now they're trying to use a good customer's resource and then all the bill and all the charges will go to the good customer. So essentially the idea is to get access to resources for free without having to pay. That's a lot of the typical abuse use cases we see. There are other types of nefarious activities, but resource abuse is one of the most common things that we see. Yeah.

So the Venn diagram is obvious, right? If I compromise an account, your account, and I use it, I am both in the cyber realm, but also I'm in the abuse realm, right?

Yes.

It almost sounds like abuse is a motivation more than a separate set of techniques, but I'm sure that's not true because surely these guys do things that traditional threat actors would never do. One thing you didn't talk about, Maria, in your intro is your background. One of the things I think is so interesting about it is the academic side of it. Can you talk about that a little bit?

Yeah. My experience before Google is mostly in academics. I did internship during my grad school at Google, and then I switched over to industry. But before that, I was teaching undergrad courses in my country back home. And then I also did research in security and privacy requirements engineering. I have some background and research in access policies, context-aware access, and those type of things. So it gives me a good mental model to understand security and understand abuse from that perspective. And one other thing which really helps coming from an academic and teaching background is when you're teaching, you are interacting with hundreds of students at a time and they have like, it's a very important and foundational part of their lives as well. Like. You are really stepping into which career you are going to go into. You're learning new skills. Your paths usually diverge from your friends. Up till high school, a lot of the life routine and things are very similar, but once you get into undergrad, then you are taking different courses. You're all carving your own path. And it taught me, kind of gave me a crash course of dealing with a lot of people, learning different styles, different working styles. And also different life circumstances. A lot of the time you have to be fair, but you also have to give reasonable accommodations to somebody who is, you know, whose life circumstances necessitate that. So I think that was something which I tried to bring into my work at Google, building with users in mind, building and trying to understand what somebody is trying to accomplish, how they're using technology. A lot of the services that Google provides, like Search, Gmail. Believe me, I still use Google Maps every day navigating to office. I know the way to office, but just for traffic conditions, you know, am I going to make it in time for my meeting and so on. So, I think that a lot of that perspective, like diverse perspective, looking at things from different people's perspective, that really helps me at my work at Google as well.

So, can we delve deeper into the abuse though? Not that abuse is more exciting, I guess for us, minds corrupted by cybersecurity, the types of badness the attackers are doing is kind of always interesting. So is there such a thing as popular abuse types? And of course, don't reveal any secrets that would help the bad guys, the bad side, but what are the things people are doing? I mean, I would assume crypto mining sits in both the cyber realm and abuse realm because it shows up in all the threat reports. Do they cryptomine? What else do they do? What are the top 5?

Anton, you're suggesting that our minds were corrupted by working in security, but I would propose that perhaps it is our corrupt minds that got us into security in the first place.

Or biased, right?

You would have to deal with this when you have a child because it's a nature versus nurture question. It's kind of like, did you select the right skill or did you become that way because you're in that skill? I have no idea. So, and I should stop rambling.

Maria, please.

Yeah, I think there are interesting discussion points in there. I'll start with the first question, which is like, what are the most popular abuse types? You mentioned coin mining, and I think coin mining is also something which we see a lot happening as one of the primary motivator, because that's a way to make money without having to pay for your usage. If you can, you know, get access to that horizontal scaling, vertical scaling factors, as we were talking about earlier. But it's not just one variety of coin mining. And I would like to call out that our trust and safety security engineering team has built a lot of expertise in detecting coin mining on GCP. So you will see coin mining on every and any product that abusers can, you know, get their hands on. And sometimes it's very strange. Like, we are wondering, like, how are they doing mining on this product? Like, this product is just meant for querying some data. So how are they doing mining here?

Yeah.

Or this product is meant for, you know, building something and how are they doing mining here? So they, they get really creative. And in the historically mining was an issue for compute engine or computational resources.

Mm-hmm.

Because that's what you needed to do mining. But with other type of mining coming in, like Chia mining, we are seeing that now you can use storage resources to do mining. So traditionally mining was a problem we would mostly see in GCP, but with Chia, any product that provides storage capabilities. has encountered this type of mining issue. So this is something which we saw in not only cloud, but also on Workspace and other products as well.

That's exciting in an innovation, but not in hacking compromise intrusion innovation, but in it is genuinely abuse innovation, right? Which sounds kind of like a weird combination that doesn't quite fit into my brain, but it is a way to use somebody else's service for free without hacking it. Without compromising it.

Yeah.

Well, I guess they are compromising it. Okay, so I know what's going on. I'm trying to shove it into the cybersecurity model, but it's different, and that's insightful.

Yeah, and that's the overlap part where there is some abuse due to compromise, but then there's also abuse without any compromise. And there's also overlap with fraud sometimes that, you know, there's no compromise, but there's something else going on, some use of fraudulent instrument or Usage without ever intending to pay. So there's like a Venn diagram with security, abuse, payment fraud, those type of things.

Are we seeing attacks also on AI systems yet? Has that reached the consciousness?

Yeah, I think that AI is an interesting discussion point, and we are seeing those type of trends in abuse space as well. For instance, we recently launched Gemini AI Studio, and that's been very exciting. A lot of people are wanting to build their own technologies on top of it and try to see the capabilities that this offers. And abusers are also trying to use some of these offerings and capabilities in that sense. So for instance, trying to circumvent quota and trying to circumvent the resource usage that you can get for free. So they're always good at testing out some of the new capabilities that we are offering.

That's such a positive framing of what they're up to. Oh, they're helping us test. That's very— it's a very Google-y way to see it. I appreciate that.

Yeah, I mean, challenges help you grow, right?

That's right. That's right. I like to see things as another opportunity for growth. It's my favorite way to put something. I brought up Googliness. Mohammed, you had a question you wanted to ask about Googliness, right?

Yeah, you know, that's a good segue. Actually, I have a couple of questions that I've been writing down as we've been going through. But let's start off with that Googliness one. You know, one of the aspects of the Google interview is measuring Googliness. Now, if you go to Google and type preparing for the Google interview, it says one of the first things that comes up in the search is a Medium article on how to prepare for the Googliness aspect. What is Googliness? Tim said, hey, that's very Googly of you. What does it mean? What does it mean to be Googly? How do I be Googly? How do other people be Googly?

Yeah, I think that— and we were talking about diversity. So I would say that there are many ways to be Googly. Essentially, but the way I look at Googliness is having a problem-solving mindset and a desire to figure things out. So essentially asking questions, challenging assumptions so that we can all get to a better understanding, never taking anything for granted or for given, making your own mind about it, learning from other people's experience and perspective. So essentially focusing on understanding and then a solution-oriented problem-solving mindset. That's what it means to me. And another aspect of it is that when you're solving problems, are you solving the right problems? Are you solving things which create value for our users, which create values for broader technical and social contexts? So that's something which is, which also comes to mind. And a lot of the time we think about making it easy to get things done, but in the space of counter-abuse, sometimes it's also about making it hard to get things done for the bad actor. So, depending on the context, try to make things easier or harder. These are some of the things which I think about when I think about Googliness.

What about ambiguity? Isn't ambiguity kind of— because in my mind, that's the second thing that comes to mind is that there's— if you are thrown in a sea of chaos and you're supposed to sort of like do something valuable, I think ambiguity— I'm not trying to put words in your mouth, but like I'm sort of surprised you didn't mention ambiguity. because ambiguity to me is there.

No, that's a good point. And when I was talking about problem-solving mindset and desire to figure things out, that kind of implicitly implied that there is some ambiguity involved, right? The things that we are solving at Google are not doing the same thing over and over. They're always something new. Either you are doing something at a larger scale or you are applying something to a new problem space, or you are doing something differently. And ambiguity is definitely a big part of the equation. And that's also something which I kind of helped me make that decision to switch from academia to industry, that at Google as well, there's a very research-oriented culture. There are a lot of things that we are doing, a lot of the problems we are solving, which can be considered as, you know, applied research because you are, you have to figure something new out or you get good at doing one thing and then the dynamics change, the threat landscape changes, the abuse problems change. And then you have to kind of change your approaches as well. And then now you have to tackle those. It's never like, okay, now we are done. Now this product is secure. Now there is going to be no more abuse here. We do try to solve those classes of problems, but then there's also the changing landscape. You fix one thing, the abusers move to a different product. You fix that, they change their tactics. So I think that's another overlap with security where you always have to keep on your toes and think ahead and anticipate.

So, I think that aspect is so interesting about your work. Can we pick at that a little bit? How do you actually, at Google scale, successfully stay on top of the scale and the variety and the pace of innovation from bad guys? How do you do it? What's the magic there?

I think you have to kind of identify similarities and common patterns. And if we think about GCP and we think about like all hundreds of different products, then we are never going to be able to tackle this problem. But we can think about classes of problems. We can think about, okay, what type of abuse vectors apply to computational resources or what type of abuse or risk apply to storage resources or network-based attacks or API-based attacks. So trying to group things into similar or logical kind of buckets and then trying to figure out what are the attack classes, what are the top abuse vectors for each type of resource category, and then how do you tackle those? So there's a lot of kind of housekeeping that goes on and kind of putting your thought behind that and not looking at each problem in its own uniqueness. Like we can appreciate all the products for their own uniqueness, but then also trying to see what type of similarities that we can abstract out and solve for.

That's a very academic answer there. I like that. Like each thing is unique, but there are abstract ways that they're similar and we can then scale our approach that way. I see how this fits.

Yeah, and then it's also not possible to solve all the problems, right? So you definitely have to prioritize and there is such a concept of, you know, there is, if you try to remove all abuse from platform, there's a very easy way to do it, right? Just like, you know, you can make the system—

You turn it off. Yes.

Yeah.

I think that's the same as in cybersecurity and in abuse, right? Like absolutely secure system, absolutely resilient to abuse system is the same system. Yes.

Yes. That's the same answer there. That's another overlap. So we do have to think about good users. Like, as much as we fight abuse on GCP, we are always thinking about the good users first and foremost, that we don't impact their experience because they are trying to do some— build their businesses, do something meaningful and useful on GCP. So that's always our number one priority. We don't want them to be impacted in any way. And in fact, if they are facing abuse due to compromise, how do we support them? If there is a good user, but some of their users, downstream users, are misusing their capabilities, how do we notify them? So it's kind of finding that balance, thinking about the good users, but then how do we protect them? How do we protect our own infrastructure and system?

Actually, that brought up an interesting point that was kind of nagging at me a little bit. If you have a company that is a GCP customer, but their customers downstream are abusing their platform, which then puts stress on our platform, Is that also in your charter? Because that sounds really hard to solve, right? Is that also in the domain?

Yeah, that's where we rely on the security folks, right? Like, you are helping our customers remain safe, and then there's less chance of abuse due to compromise and security risks. But there's always other type of scenarios, right? For instance, hosting provider is an example where the hosting provider themselves are good customers, but some of the content hosted by their users might be violative. So in that case, the problems become how can we get to the right contacts for those customers in a timely manner so that we can let them know that, hey, this is what we are noticing, we are letting you know, and then let's, you know, work together and figure out how to secure your platform or how to help you kind of design in a way that you can isolate some of these type of problems.

I like that answer. I want to shift gears again and go back to something that we were talking about earlier, which is your path into Google. I certainly had a weird path into technology. I was a political science major who started out at a think tank, ended up here. It was a long and winding road for me. What advice would you give people with a background like yours or whatever kind of background about coming to work at Google or a company like Google?

I think that in Google, we are solving many different types of problems and really interesting challenges. And one thing I heard recently which really resonated with me is that, you know, when you're faced with a challenge, don't get upset, get excited.

Hmm.

So I think that's what I try to do, and that's what I would encourage people to do. It's easier said than done, but having that mindset that, okay, this is an opportunity to learn, this is an opportunity to figure something new out or solve— look at the problem in a different way. I think that always helps. And another thing I want to call out is that I lead an engineering team, but I work with many cross-functional teams. I work with data scientists, analysts, security engineers, lawyers, privacy experts, policy experts. So it's a very dynamic and interesting problem space. So you don't need to be just interested in coding or just interested in engineering to think of a career at Google. You can be interested in any of these problem spaces, or if you are like a stakeholder, right? Because I feel like security, safety, it's at the intersection of society and technology, and it's really at the heart of user trust. So if you care about these problem spaces, there's definitely some overlap or some interesting career path you can find. And yeah, not to forget product managers and program managers as well. They all bring useful perspectives, useful skillset, and it's all needed to kind of solve the problem. It's like, you know, everyone brings a piece of the puzzle and then together we can solve that problem.

I really like that answer, and I hate to ask this, but we're getting to the point where I have to ask our traditional closing questions. One, do you have recommended advice for people that are working in the abuse space to better scale their operations? And 2, do you have recommended reading for our listeners?

I think the recommended advice is just to try to look at it as classes of problem that you can solve. And then another thing which I would say is to do something beyond yourself which is not directly for your benefit. Outside of Google, I also lead a nonprofit organization which is focused on mentoring and career coaching and scholarships for students from underserved areas. So that's something which kind of keeps me grounded and motivated as well. So find something like that that resonates with you.

What is the organization called? Can we plug it on the show just now? What is it? How can people help?

It's called Nastian, and it's an alumni volunteer-run organization, and it's a 501 registered nonprofit as well. So yeah, if you're interested in mentoring or coaching, providing career guidance and you want to partner, please feel free to reach out.

That's awesome. And then recommended reading?

Yeah, recommended reading. That's interesting. And I was thinking like, there are a lot of books that I've been reading lately, but one thing which I kind of, I really like it is The Art of War. And it's kind of interesting because we are talking about counter abuse. So there are interesting life lessons there. There are interesting lessons you can apply in security and abuse space as well.

I really like that answer. Well, Maria, Mohamed, thank you both so much for joining us today. Listeners, thank you for joining us for another episode in the Security Voices series.

Thank you for having me. Nice talking to you all.

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_Chuvaikin and Tim Pico. 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. Thank you, buddy. You're welcome.