Ashish Rajan: I’m sure a lot of people know you already from your SANS talk, but for people that don’t know Kat, can you tell us a bit about Kat and how you got to where you are today?

Kat Traxler: Yeah. So I’ve been working in security for about five years now. Cloud security specifically for about three years. I started out like a lot of people do, a traditional path. A common path we see from, from cloud into cloud security is from application security. Right? And you know, cloud security is such a a shiny toy it’s it’s the road less traveled, right?

If you want to break new ground, , if you want to go into a space that, you know, Not many problems have been solved yet. That’s where you navigate into. And I started out in AWS, like a lot of people do, and then eventually switch over to GCP, it’s not like I woke up one day, and said, I’m going to be a GCP security expert, I work for a large organization that needed that expertise and I was tapped on the shoulder to say, go figure that out. So when I was given the time and space to do that interestingly enough once I got into the space I found that [00:01:00] there wasn’t very many of us.

Yeah, there’s just a handful of people, you know, poking at GCP. So it was just, fertile ground to learn new things, try new things and then teach them.

Ashish Rajan: That’s pretty awesome. And I’m glad you did some research as well, because I definitely find this. Not enough information about Google Cloud, specifically bug bounty.

So I’m glad you brought that up,

All right, switching gears again. I think first of all, application security, then moving into Hey, how do I improve Google cloud specifically?

Because the employer wanted it. But I’m curious to know from your part so bug bounty kind of fit into this of bug hunting, right? Life.

Kat Traxler: Yeah. It stands out to me. What a difference a bug is in the cloud versus say in an application you might be testing a suite of APIs and you find a flaw in that API.

That might be like a syntactical error that could be catched by code static code scan or something like that. But in the cloud, what we’re really talking about is like unintended behaviors. So. Or unintended consequences. So , what a bug [00:02:00] is, like super subjective. In fact, you know, there’s lots of things that I’ve submitted to Google, or I said, Hey, this, this shouldn’t happen.

This shouldn’t be, and the response is working as intended. And then I think there’s some other people who can attest to having to then convince them that their threat model, is incorrect.

Ashish Rajan: Interesting. Wait, I guess technically this is still part ofcloud security, though, right?Like when you define cloud security.

Do you include.

Kat Traxler: Oh, absolutely. You know, cloud security, cloud security engineering, I typically think of as, all of those classic, like preventative controls that we do in any other system, just like modified and morphed. To fit in with like the ephemeral nature of the cloud to fit in an agile way to fit like in line with infrastructure’s code pipeline.

So cloud security engineering is not that different from traditional preventative controls. And then threat hunting is also. A core part or should be a core part of cloud security. And it’s, exactly the [00:03:00] same as your, know, threat hunting and on prem network, you’re just looking at different log sources and you have to recognize how malicious behavior is going to show up differently.

But it’s the same principles and it’s all ended up the same umbrella.

Ashish Rajan: Right. I’m curious to know about your bug hunting process as well, then how would you define that? Like what, what’s your process for starting to do some, I guess, bug hunting? Is that the right word for it?

Like what’s the technology.

Kat Traxler: Yeah, I mean, I think bug hunting is a good shorthand. You know, sometimes I would just use like surface tear down, , taking a service and melting it down to its core parts. I think when you start to look at any of the, the past services in any of the clouds, you.

Have to have this really crisp mental model for what you’re looking at. And that’s first by acknowledging that you’re always dealing with a server, whether or not that past service, you know, is showing you that server whether or not you could interact with it or not. Whether or not it’s kind of behind the curtains, that API you’re interacting with.

To represent the past service is always [00:04:00] going to be on a server somewhere. So that’s going to inform how you want to then tear down the service to how it’s actually working.

Ashish Rajan: Oh, wait. So , we spoke with a couple of times about PaaS as well. I’m curious to know from your side, when people talk about bug hunting and Google Cloud and we’re trying to cover for people who may be starting new, and maybe, I guess we’ll go into bit more layer deeper.

So for people who maybe come in kind of like how you started in the AWS world and landing in GCP, What were some of the obvious things that you saw differently? I mean, I guess IAM Ibelieve there’s an, I am kind of like a instance role, but whatever the client is. So what are some of these terms like, cause you mentioned API and that made me think, oh, I’m pretty sure there’s something else that’s valid, which may be almost like a cross-pollination of what people may know from AWS world or a cloud world was so service accounts.

IAM credentials I guess at least part of that.

Kat Traxler: Yeah. I mean, I, that’s one thing that really struck me quite a bit coming from the AWS world, just the GCP worlds is just how different they look at access controls. And I one of the things that struck me the most [00:05:00] was how user identity and group identity was not a concern of GCP where an AWS.

I know you have a confused look on your face as she’s. Yeah, I know. You’re like what. Yeah. So it makes sense. If you think about GCP as just an arm or just an offshoot of one of the many businesses that Google has, Google has the G suite, which is now renamed workspaces, who will has this maps product.

They have Android, they have all of these services and one of them just happens to be this cloud. And the cloud doesn’t store any of your user data, it doesn’t store any of its any of your identity, or any of your group information that’s all housed in G suite. So everything that you do in G cloud, Is your it’s an authorized application to G suite.

So that was one weird thing. Was that like users and groups just aren’t don’t exist in GCP. They don’t exist. They’re in G suite. That was interesting to me. That is interesting. Yeah. Yeah. The concept of [00:06:00] service accounts is completely unique. And NGCP, I think that in AWS, you find a lot of people kind of hacking surface accounts in where you create like a local user to do a thing, but it’s a user, it’s not a surface account.

In Google, they have a specific like object and identity for that. And then the whole concept of the hierarchy in Google, you have hierarchical policies that inherit, that’s not a concept in AWS either. So, I joke that the more I’ve learned about GCP, the dumber I’ve gotten about AWS, there’s just so much you have to unlearn.

There’s so many concepts. You have to unlearn to get in the mindset of, Of what IAM means in Google.

Ashish Rajan: Interesting. And I think I’m glad you mentioned it because it’s worthwhile identifying, as long as doing bug bounty or bug hunting in a google cloud context, it does make sense for them to understand that the layout maybe a bit different just because you’ve done something in AWS, doesn’t really mean that we’re working.

GCP as well, even though there may be a metadata API. So coming back to our regular flow in terms of. [00:07:00] How people look at PaaS as aservice, you know, there’s a whole and I was, I find it fascinating. When you mentioned in one of your talks about the different kinds of PaaS, Old School PaaS and new school PaaS I mean, let’s just, just demystify. What is PaaS according to you and then lets go what is new school and what is ol d school?

Kat Traxler: Let’s be clear. I have done certain things, old school and new school. These are not official terms. So PaaS you can think of as you know, any type of service that’s an additional abstraction layer on top of your raw compute and top of your, your IIS.

So. The first generation of PaaS that you’re going to see from Google are a lot of open source products that Google will have an installation script that they made that will automatically install it and Apache product onto a VM. And then, they’ll expose some APIs to you to allow you to configure that.

The real mark of it is that compute [00:08:00] instance is going to be live in your project. You’re going to be able to see it and interact with it as a compute instance. Not unlike any other compute instance that you might stand up. And a lot of these older school products are going to be a lot of data science projects, a lot of the things that Google was into and became known for from the beginning, like being really data scientists, friendly researcher, friendly.

Yeah, I think I’m thinking like Jupiter notebooks and cloud composer data flow. These are all just like open source Apache products that are really used for like big data stuff. And you know, oftentimes these products, They suffer from a little bit of disinvestment, I would say.

Well, it’s convenient to have like a script that will automatically set that stuff up for you. Some of the drawbacks are like the underlying infrastructure that’s, it’s stood up on. They’re not always going to be compatible with the latest and greatest options for a compute instance, specifically thinking about like shielded identities and shielded nodes.

That’s a feature in Google cloud to protect your [00:09:00] compute instance. And it’s not going to be compatible with a lot of these old school products, right? The newer school ones. You know, the, the PaaS 2.0, they’ve moved that infrastructure to their side. So you’re not going to be able to see it as a physical object or as an object in your, in your project.

Ashish Rajan: Oh, wait. If I’m doing say some kind of bug hunting in Google Cloud, and then I come across a PaaS service, as you mentioned. So depending on whether it’s an open source one, which is, I mean, they put on the lipstick of Hey, this is a managed service, but at the end of the day, it’s like, there’s a compute service under running underneath those compute services that someone can access and.

I guess investigate them as well for any bugs or. They they’re kind of like the AWS side of the world where you have a quote unquote, a PaaS service, like I’m going to elastic Beanstalk. I think that that creates an EC2 instance or like some kind of a compute service and I don’t think you’re able to access it.

You still define security around it. Is that similar in this console? Would that be classified as the old school? One way you actually have, you can see the computer instance that occurred. [00:10:00] Explanation of it.

Kat Traxler: Yeah. I guess I’m not familiar with the AWSPaaS that you’re referring to, but yeah, the old school ones are definitely ones where, let’s say you hit the button that says I would like one cloud composer instance bleeds, and you’ll be able to like interact with all of that via the cloud composer API, but that’s running on some compute instances and you can also interact with those compute instances via the API for compute. So, now the compete will be kind of like automatically set up for you. And that’s what I’m highlighting is that the way that it’s automatically set up is not always in accordance with best practices.

Ashish Rajan: Interesting. Oh, wow. I kind of came around a rounded way, but I think that’s exactly I took it out so great point. So how would this be different to the new school because it’s new school. One where you don’t see compute, but it’s quote unquote server less in the background.

Is that why. Yeah,

Kat Traxler: I think like they call it server less. Yeah, probably because they probably call it because you don’t see the server. But it it’ll generally end up being some process, running in [00:11:00] a container, running in a cluster, in a project in GSP. So while you have , Ashish’s awesome project.

Google will have Google’s project for Ashish, and those would be this like mirror project. On the other side, that’s handling all of your past services or, sorry, the specific one that you created, the specific one that you press your button for.

Ashish Rajan: Oh, right. And I think I’ve got a comment here from Darpan as well.

You can consider those resources as subordinate resources.

Kat Traxler: I don’t know about the term subordinate resources. They are resources that are under, they live in a Google managed project hierarchy.

Ashish Rajan: All right. Okay. So, so that’s where the hierarchy comes in, but I think you, I guess what I’m trying to get to is it’s really interesting.

Now, what would your approach be to kind of finding bugs in aPaaS situation? Like say weather. Or at old school or new school, old school sounds like you have some instances or you have computer instances, which may not be configured to the best of its ability for security, best practice.

So maybe that could be one avenue in the new school world where you don’t see compute. [00:12:00] What’s the, what’s your approach there?

Kat Traxler: It kind of all starts with the recognition that whenever you’re interacting with an API, you’re interacting with a process on a compute instance or a container.

There’s a server there somewhere. And so, if you follow this kind of like, This like vision of like, if this, then that, if there’s a server, then there’s a metadata API. If, if there’s a metadata API, maybe you can query it. If you can query it, can you return the credentials from it? And, and if you can return the credentials from it, what does those credentials have access to?

Ashish Rajan: Right. So IAM plays a very big part in all this.

Kat Traxler: There’s no way of getting around it. It’s IAM all of the turtles down.

Ashish Rajan: Oh, right. Okay. So if someone was doing so I guess if identity is the. Key. And in the cloud context, which seems to be for all cloud service providers , what’s the equivalent of keys that I’m getting? What’s the secret keys that I’m going. That when I see them like, oh, [00:13:00] that’s, that could potentially be a way to communicate , with the metadata API that you were talking about earlier. So is there a name for it

Kat Traxler: yeah, I mean, surface accounts can be provisioned with these kind of durable credentials where you can say like, Generate an export me a private key to authenticate as the surface account. And then like you could hard-code it places and then people could find it and that can be bad. Or, you can rely on generating access tokens for a service.

So when we were talking about like querying the metadata API, what we’re talking about is we’re calling the Google API APIs and asking for the short-lived access token for the service account, and then that’s what can be taken to then, you know, all of the other API APIs to authenticate to.

Ashish Rajan: Right. And why do you, while we’re on the topic about the Google API as well?

One common question that I get asked and love to hear your thought on this as well. It doesn’t just mean that your Google [00:14:00] infrastructure, as in Google themselves arevulnerable as well. If you find something, is that like, because it’s, you know, I’m sure it’s an API shared by them as well. So what, where do you want me to respond to that?

Kat Traxler: I respond by saying, I think they’re smart enough. That it doesn’t, it means that they are not vulnerable. I don’t know this for a fact, in every case and I would certainly allow, the Google trust and safety team to make that evaluation, but, you know, should one be able to access an access token from.

From a, for service account, revisiting one of their projects. You know, what that architecture has looked like to me is that. The permissions assigned to the access token are really only for your project. They’re not for any Google project. So just because you have the ability to authenticate as the service account and you have the access token doesn’t and that that surface account is a Google service account living in a Google project.

It doesn’t necessarily mean that it’s really. Affecting them, because it might not have permission to do anything in a Google project. And [00:15:00] so far, that’s what I’ve always seen.

Ashish Rajan: All right. So, oh, actually that reminds me because I remember when we were talking about this, we actually spoke about P4 service agent.

And so what’s the P4 service agent and why can’t I find them on a console?

Kat Traxler: You need to click the button Ashish. There’s a button. Oh yeah. They hit them. They hit him.

Ashish Rajan: I mean, why? I mean, yeah, I was going to go why they hide this, but,

Kat Traxler: so I was calling them the sacrificial lambs. I think that was my joke.

The P four it stands for per product per project. Right. So P for various, very clever they are surface accounts that are identities that live in Google projects. So just like you can have a service account, they can have a service account. When you enable aPaaS service and you say like, I would like this PaaSservice.

This P for service agent is created. On your behalf and it’s given permissions into your project to like, do different things, to basically support the service and all of the integrations it needs. And those are the ones that that are interesting to look at from a bug hunting perspective.

Ashish Rajan: Interesting. And it got talking about bug [00:16:00] hunting. We have a couple of comments coming in as well. So Darpan wa has had this thing. He had was VVC controls is another effective way to control doors. Yeah. Project permissions.

Kat Traxler: , I applaud you if you can get them running , in a real life situation. I think there’s a so long way to go with having all of the services that Google offers to work with APC service controls, and then being able to actually enable access through that kind of like IAM firewall.

And like effective ways is a lot of challenge. So I’ve never known anybody to actually get to work in a real life scenario. It’s lovely to think about,

Ashish Rajan: . I’ve got a question here from Gerald interesting to know what part of bug hunting process does.

Can’t find the most.

Kat Traxler: Okay. I think for always and forever, it’s knowing when are you done looking at a surface? When are you kind of like I’ve covered every angle. And you know, the score is Google one Kat , zero. It’s hard to make that call.

I think what I usually say is not, not goodbye, but see you later, to services.

Ashish Rajan: And I think that, that makes me also think, yeah. Probably [00:17:00] one of the hardest thing to realize is that, is this how far I can go with is how deep this Rabbithole will be based on the key that you get.

Like, whether I’m sure there’s a concept where you can not, it’s not just about your project, but can I access someone else’s project as well? Is that, is that a concept that exists in Google cloud where I can almost go also Kat has a bunch of Google accounts that she has a few projects in, and I have a few.

Google cloud accounts that I have a few projects in. Is there like a, for lack of better word identity that traverses across both of them that can have those come up as vulnerable as well ever. I mean, I guess with, I mean, obviously coming from a permission perspective, but I’m sure there are other ways to do that as well.

Kat Traxler: Yeah. If you think about it, like all identity is cross project because identity doesn’t live in GCP identity lives in this thing called G. And then you have an identity here and then it’ll have permission to do things in an organization, in a project. But the fact that you own the G suite and you own the GCP project, that’s just a convention you have thought of, you can certainly, I [00:18:00] can assign you a sheesh permissions in my project and you would never know.

Ashish Rajan: Oh wait. So if that’s the case, then, project for a full project and services. And we were talking about that. We don’t see. And it sounds like there are a few more things that we don’t really see as well. So apart from identity and these things that we cannot see in the Google cloud console, which, which could potentially, could be a wonderful, we had Dylan a couple of weeks ago, and it was really interesting to hear what the perspective yeah.

Oh I think him and Alison I think the copy pasted, like created a copy of an existing role to see what Google was giving us a role permission, which is quite extensive to begin with. These are there other threat factors that we could be exploring? Cause it sounds like identity is definitely the key, but sounds like there’s an opportunity on something that Google provides as well as a possible threat factor. Would that be? Yeah.

Kat Traxler: Yeah. I just love their research to let it Alison they’re so great. Yeah. The trick that they came up with was to, you know, basically the ability to like clone a role, create a custom role, [00:19:00] but like reference an existing role.

And based off of that, you were able to. Grab all of the permissions and they’re able to like really enumerate what does the cloud build service account have access to? Since then Google has become a little bit more transparent and has some documentation on like, what are we actually assigning this thing?

But I think when they were doing their research, it was just like, you had no idea. And, and to your point, you know, you said, why can’t I see these services? That you used to be able to see them in your projects. IAM console. But maybe about six months ago they changed it. So they’re hidden now and you have to click this box to actually see them.

So yeah, I think that. There’s definitely a Pandora’s box. IAM a hundred percent. And I think that they’re not maybe doing themselves a great service by, by hiding things from people and not being like extremely transparent. I think that. It’s the same line as like cryptography, like the best cryptography should be not via on like secret code.

The best cryptography is, should be publicly available. And I [00:20:00] look at the services is the same way. Like there’s a way to mitigate the risk for everybody, but transparency is the key.

Ashish Rajan: Wait. And I’m glad there is research that helps us say shape some of these conversations as well. And do you feel like there are.

Some things like, you know, I think we got burned into impersonation for, for lack of a better word as well. Is, is that something that you find happens still happen? I guess with God, once people have access to keys and it, cause I’m trying to comment more from both of blue team perspective as well.

Cause you’re doing the blue team part as well, where you’ve identified. And all right, so at least the conversation that we’ve had so far, I’m looking at this going, okay, so clearly identity and the kind of permission play a huge part. When you’re looking at bug hunting from a GCP PaaS perspective. And if you’re looking at this and from another layer, Are there

things that the blue team could be doing to say, pick up on these things. Like what are some of the experiences that you can share from a blue team perspective that people can listen to this? Okay. So I know what [00:21:00] the two kinds of GCP PaaSes are. And potentially I may have access to compute that there is a Pandora’s box doesn’t compute, but maybe we can focus just on the new school part where you don’t really see the columns.

I’m keen to know what is the Blue team supposed to do in this?

Kat Traxler: Well, it’s really hard. And I acknowledged the difficulty because. A lot of what, an attacker might too is also what a software engineer might do depending on the practices of an organization.

You mentioned a personation, right? So that’s, you know, that’s just one ability from like one identity to then. Assume and obtain the permissions of another identity and that chain can go on and on and on or not. What would it look like , to always alert in your organization for any type of impersonation any organization that might be like crazy noisy, because that might be how you do business.

You might have set up your your role is in permission so that like everybody has a surface account and you’re always in Percy that serves account to get work done. Or maybe like as a kind of like shoe horn just in time, permissioning [00:22:00] situation. So following the track of impersonation, if you don’t have like very rigid architectural patterns is very hard.

I will say that the other path to following, malicious behavior is Honing in on, what a service account typically is doing. And then what is this outlier? Right. So I talked about like service accounts, being able to beyond being personated , they did, you can also, you know, hijack an access token for it.

By the metadata API, maybe that’s surface a couch that P for surface account, it’s always doing builds for you. And then all of a sudden, one day it’s creating some storage buckets. For me that would tell me that , something sneaky has happened to that service account. We haven’t seen it being a person he did.

But we know that the cloud build service account is is vulnerable to being able to be hijacked. And then it does something completely outside of its normal behavior.

Ashish Rajan: Interesting. And how would you map out a [00:23:00] behavior? Are there like tools in Google cloud already? Which map are, Hey, this service account is primarily used for, I don’t know, just to your point, just as a Cron job with the background, is there I guess out of the box things in Google cloud that allows you to track this or manage this, or is this like a, become like a thing you have to find externally or open source?

Build it yourself.

Kat Traxler: They have a couple of built-in API APIs that allow you to analyze policy. It’s called, IAM recommender where if you give it like 90 days, it’ll analyze the role bindings at your project level and say, , Ashish has been granted all of these permissions, but it’s only using these permissions.

There’s a different role. You could give it. That doesn’t really close the gap before. Here’s one of the P four service agents doing something completely. Whackadoodle right. So I guess to answer your question, no, there’s really not a tool to do that. They’re these little helpful APIs to help you get down to a least privilege on role bindings.

Yep. And I guess another really good [00:24:00] point is, these P for service agents you know, under punishment of death, you are not allowed to touch the role bindings for them. Google assigns those role permissions and, do not touch them unless you want to be yelled at, by a, person in Texas.

They assign them. They’ve determined that that’s what they need to enable and support that service. And if you think it’s excessive Too bad

Ashish Rajan: really? Oh, wow. Sorry. We just started a big year exited permission because we wanted to, so thank you. Wow. So, and I think so if it was a job with the blue team, is sounds a bit difficult in doing, I guess, identifying this.

So what are some of the. I was going to say low hanging fruit. I know bug bounty can be one side completely what I wanted to kind of shed some light on the blue team side of things as well. So is this kind of where a lot of people talk about preventative? And have having some kind of detection controls or preventative controls, like, I mean, is that your approach as well?

Or do you recommend? Cause I imagine that is all about being continuous as well, that there might not be a service account that may exist right now, but then suddenly two minutes [00:25:00] later after you stopped doing the investigation, someone just decided to create a service account. So our approach to almost like a holistic.

For a, for a blue team.

Kat Traxler: On the preventative side, there’s too much to care about all of it, I’ve seen some like very, very large networks and there’s too much in a sense to really, to yeah. To care that much about all of it.

You have to have. Dialed in on, what are your most critical assets? Where is your data? Where are the things you care about? And then from there you can hone in on, what’s normal access activity and what are the normal IAM role bindings associated with accessing that data? Because you know, nothing in the cloud happens without authorization.

Probably nobody’s breaking into the Google API APIs and accessing your storage bucket without explicit permission to do so what happened how were the,IAM roles findings changed? And if you can like monitor what, you know, the access should look like, and you can monitor if that ever changes.

That’s when like really important step is to, know where your data is [00:26:00] and then hone in on monitoring the access, instead of trying to tackle like all of it.

Ashish Rajan: Yeah. Actually that’s a good point because that also makes me realize that one way to kind of make sure you’re doing the right things is to define identity the right way in the first place.

So that’s when your comment on. I’m defined Ashish can only do these three things, but you have detection while your detection really is. If there’s a change in Ashish’s permission, someone should be able to do like, Hey, is this required? Or is it excessive Bart? Because she wants to be admin. And we use,IAM recommended to find out, are you really using all these services that you have under your belt?

So that would definitely be going a long way. So I think, it’s almost towards the tail end for concessions. But I’m curious to know from your side, is the bar too high to get into bug bounty in the GCP space? Cause I feel like there’s a learning angle that people can take away from this as well.

Is, is the bar too high for. For this getting into bug hunting in GCP.

[00:27:00] Kat Traxler: Absolutely not. And I am proof, I am living proof that the bar is not too high. Look like the space is so new. It’s not like you’re going to be walking into like 20 years of research and you’re going to have to spend years reading through dissertations on the matter.

There’s a handful of public talks out there. There’s handful of, blog posts and articles. And then open yourself up a cloud account, maybe with a gift card. So you don’t incur those excessive charges. You know, the points of my talks are to inspire people to go and look for bugs because I am most definitely not the smartest person in the room.

And whenever I walk away from a surface that I haven’t been able to break it. I think maybe somebody else can, maybe if I bring these concepts to the masses, somebody else will be able to figure this one out. So, so please look at the resources out there. There’s not many. Hmm. And then opening yourself up

Ashish Rajan: so that’s a great rule to start learning this as well, cloud a cloud account and start is there I guess I was going to say low hanging fruit sounds like the identity space, but are there [00:28:00] scenarios where just access keys laying on GitHub kind of scenario as well for Google cloud usually, or that’s not heard of?

Kat Traxler: Yeah, I mean, there are, I mean, Google definitely has a problem with durable credentials, not in the same way that AWS has. But with service accounts, you can generate that durable credential or private key for a surface account. And some people are still doing it for for not necessarily reasons.

And then putting them in and publicly accessible places. Google has made it actually very easy not to do that. You can use service accounts without access keys, as long as you’re in that Google ecosystem. They have federated workload identity, so you can federate your identities across clouds. So, I think if you ever at that point where you want to generate a private key for your surface account, maybe go take a walk and think about it.

Like I really want to do this. Is it really necessary? The keys are out there. But they’re not not as big of a problem. Is there an AWS?

Ashish Rajan: Cool. All right. And probably a good place for people to start as well. Awesome. All right. I know we’ve been talking [00:29:00] about with cloud for some time, and this is kind of like the tail end of our conversation as well, where we were kind of like some of the fun questions I want to got three.

So I was kind of a surprise for you. Its just for people to know you a bit better so first one, what do you spend most time on when you’re not working on bug hunting and GCP or technical?

Kat Traxler: This is easy growing tomatoes and gardening, and walking in the woods and, and generally being kind of a Luddite.

I spend a lot of time on a computer and then when I’m not on it on a computer, I Out and out into nature. Yeah. I try not to wear shoes all summer. I kind of thing.

Ashish Rajan: Yeah. Oh right. There you go. Cool. You and I have something in common there as well. Next question. What is something that you’re proud of, but is not on your social media?

Kat Traxler: I suppose that. I did have a whole other career before security and this is a whole other conversation. But I did have a very successful career working in the architectural drafting space. So this is a whole other career before security. Not in my, none of my Twitter up at LinkedIn.

If you want to look at it. I was president of a couple, a couple of,

Ashish Rajan: oh wait. So could that show drop as like you were making [00:30:00] buildings?

Kat Traxler: Yeah,

Ashish Rajan: exactly. Wow. So there are buildings that you can point at and say, Hey, I did the drawing.

Kat Traxler: Yes. A lot of them driving around to the area. I, I know the layouts and everything.

Ashish Rajan: Wow. Okay. There you go. So that’s definitely gone dead. Last question. What’s your favorite cuisine or restaurant that you can share with us?

Kat Traxler: Favorite cuisine? There’s a really great, like counter surface, Mexican restaurant, just a few blocks away. And I’m there a couple, two, three days a week? Yeah, nothing fancy.

Just like. Counter for counter service, cheap Mexican food. Every time I go to Europe and I come back, all I want is Mexican food. Don’t eat the Mexican food in

Ashish Rajan: Europe. Yeah, I, that, that’s definitely not the real Mexican foolish and with that note I think where can people find you? I’m sure they’ll have questions that are exploring and going down the path of Google, flowered, bug hunting, where can people find you online?

What was one of the handles on Twitter or wherever that they can find?

Kat Traxler: Yeah. LinkedIn Kat Traxler I’m pretty active on the, cloud security forum, slack, and then I’m on Twitter, as a nightmare JS. So you can hit me up on [00:31:00] there. The handle is kind of a throwback to my my JavaScript day.

Ashish Rajan: Awesome. And I’ll make sure I include that in the show notes as well, but thank you. Thank you so much for coming in. And I really appreciate you having in having shed, some light on this emerging conversation about how bug bounty should become more popular in specifically GCP and not just in like the non-cloud world.

So I do appreciate spending time and sharing what you’ve learned with us as well. Thanks for having

Kat Traxler: me. It was

Ashish Rajan: really fun. No problem. And for everyone else who’s tuning in I think next week we have a bit of a collaboration going on. So someone else is taking over the cultural report cards. Well, are you for people who follow the clarity report podcast on, on the social medias as well on Twitter or LinkedIn?

You probably get to know this, but otherwise for everyone else with dunes in, we’ll all see you next weekend. Enjoy the rest of your weekend and we’ll see you next week and I guess, yep. All right. See you next weekend. Fear factor.