Just because you're an expert in AWS doesn't mean that you're going to be an expert in GCP, really because the model is flipped on its head. And once you kind of get a sense of GCP, you might end up loving it. It's really hard to run into any friction when you're first creating them. Great for uptick if you really want people to use your services right away and not have any issues.
Horrible for security. It just seems like there's no way to undo that crime against service account. I'm just assuming, helpless customers that are relying on this functionality just to keep the engines of their Google projects going.
I can only imagine that there is a lot of hand-wringing internally about this awful design decision that was made. Well, I love your mention shared responsibility model. Google, they don't have the shared responsibility model or they think of it more as shared fate, which is this concept of they have skin in the game as well as far as how secure their customers are. If a customer is failing, they are failing as well.
Google Workspace, Google BigQuery, Google Analytics. You know what all of them have in common? Google Cloud.
You may not know this, but you may already be using Google Cloud, either through companies that you may have acquired that are using Google Workspaces with additional access to Google Workspace and Google Cloud, or you may already be working in the Google Cloud space where you're trying to find a great harmony of security between multiple versions of Google Cloud that you may be maintaining in your organization. Now, this episode, we had Kat Traxler, who is from Vector.ai. She's a researcher there. And we spoke about, first, how do you even get into a Google Cloud account?
What are some of the low-hanging fruits? What are some of the defaults that you can explore if you're trying to pen test a Google Cloud account? What is the methodology for approaching a Google Cloud account? What are some of the nuances of, say, maybe if you're coming from an AWS or Azure background, are there comparisons that you can do for similar attack patterns from there that can be applied over here?
We also spoke about the methodology from a perspective of... the complex structures that can exist. Like you may be really mature in AWS, but not as mature in GCP. So you might go down the path of, I'm just going to run some kind of ConfigureView. Or talking about ConfigureView, another thing we talk about is the fact that it is actually way more than a ConfigureView when you're trying to do a pen test, especially a cloud security pen test, whether it's AWS, Azure, Google Cloud, or whatever the cloud you put in, the information that you collect is you're collecting evidence, which would inform your pen test.
It's not that, oh, ConfigureView is the only thing that... cloud security penchases. So I appreciate Kat sharing a lot about how you could do this in Google Cloud and how it's more than a config review and some of the tooling and structure. She also spoke about her open source tool called DERF and other tools that are useful and other tools that can be used to have, hey, if you have an existing infrastructure, this is how I would run an attack on it.
But if you don't have an infrastructure, but you want to still form some form of infrastructure that you can learn from it, then Kat's DERF open source tool would be amazing for it. And the one that we call a DERF from Christoph as well. And the example that was called out by Kat for Christoph's open source as well, called Stratus.
And also the example of another open source repository called Stratus Red Team that was called out by Kat as well by Christoph from Datadogs. So all that and a lot more in this episode. If you know someone who's trying to do pen chats in Google Cloud, definitely share the episode with them so they can learn from this as well. And if you are someone who probably is watching it or listening to this for the second or third time, I really appreciate if you can give us a follow, subscribe if you're watching this on LinkedIn or YouTube. But if you're listening to this on Apple or Spotify, definitely give us a follow and leave us a review or rating over there.
It definitely helps more people like Kat and others who are amazing at what they do to come on the show and talk about what they love best, which is sharing knowledge on how you could be a better cloud security pen tester out there tomorrow. I hope you enjoyed this episode with Kat. This was a continuation of our offensive security month and I will see you in the next episode. Peace. By bringing developers and security together, you don't have to choose between speed and security.
Develop fast. Stay secure. Hello, welcome to another episode of Cloud Security Podcast.
We are continuing with our Offensive Security Month, and today's topic is Google Cloud. Fantastic research, we'll find out. So let me bring on my friend over here.
So she's going to be the better person to talk about this than me. So hi Kat, welcome to the show. Hi, thanks for having me again, Ashish. Thanks for coming over. I feel like it doesn't feel like that long that I saw you last week or a couple of weeks ago at Black Hat.
It was such a pleasure seeing you, and Shipley was just like magical. really. I appreciate that.
But I know a lot about you. But for people on the internet, some of them at least may not know who Kat is. Could you give us a bit more about yourself and where you are today?
Yeah, so I find myself with my feet in lots of different spaces in cloud security right now. So my day job, I work in security research, both in AWS and GCP. Okay, so I'm researching attacker techniques, trying to figure out how the bad guys are getting into cloud deployments. And so that's going to inform some detection engineering work that I'm doing, then writing detections and writing the logic, which will then prevent my actions to get into an environment.
So that's hashtag day job, right? I'm also the author of the SAN SEC 549 Enterprise Cloud Security Architecture course. So I have my life kind of squarely in that architecture realm, staying on top of all of the latest and greatest patterns of like the most secure deployments for identity architecture and network architecture.
What's the most secure patterns for doing, say, Data Lake and AWS and GCP? And then, of course, I have a background. in web app pen testing. That's kind of where I came up is doing web app pen testing. That's how I got into cloud security.
So my feet are in a couple of different streams. I think you've had me on the security architecture of month as well. It keeps me busy and I don't think I'd want it any other way.
That's pretty awesome. And I think I'll definitely recommend checking out the course that you've written as well and the previous episode we've done because you've had architecture, pen testing, and now research as well. You have an open source tool that was reached to talk about later on as well.
So. So talking about pen testing and tapping into your web app pen testing and now the cloud security testing experience, how different would you say is pen testing in AWS versus, say, Google Cloud? You know, obviously your goals are going to be the same, right? You interact with the client, you understand what they're concerned about, you understand where their crown jewels are, and then you attempt to test their controls.
But any differences between the AWS pen testing and pen testing in GCP is going to come down to the difference in... how those two clouds are constructed, right? So, you know, in AWS, you're going to be testing a lot of like role assumptions, using role assumptions to have lateral movement.
In GCP, you're going to attempt to act out service accounts for lateral movement. That's going to be a little bit different. So the difference is going to be around the construction of the clouds. And then potentially, and I hate to even say this, but potentially there might be a maturity difference, really. More people have...
been in AWS longer and more people have had time to have more mature, secure deployments. You might have a client who's had 10 years in an AWS environment, had been able to iterate and have automated security controls. So you can really push those boundaries and try to match cases.
In GCP, you might have a client who's maybe just a couple of years into their deployment or they have an acquisition. So that kind of pen test is going to look very different. You're going to actually find a lot of low-hanging fruit.
And you can't, say, pull out every trick in your bag, right? You have to meet the client where they are. I think I appreciate the nuance of people may be more mature on AWS because it's been longer, blah, blah. And do you feel like Azure would be similar as well?
Like, I think there would be the same similar spectrum because GCP kind of came almost like the third person in the already... busy cloud market with AWS and Azure to your point and I guess I was so see so for a company which all for the example that you gave acquired a company that had GCP exactly but you can't go down that path no I'm sure people start off with GCP as well there are ones out there would you say the pen test for a Google Cloud and as I said I'm gonna rub a few people off is not a config review or maybe even what is the config review for people who probably getting it for the first time because a lot of people say cloud pen testing is just a config review and they're just trying to on some kind of scanner and that's the end of the story. What's your opinion on pen testing and cloud security?
It doesn't matter if it's Google Cloud or otherwise. Well, I mean, comparing it to like a config review and pen testing, your goals are the same, right? You're trying to determine are your clients'controls sufficient and where are their gaps?
But the mechanisms that you use to answer those questions are totally there. I can think of you, you're pulling evidence, right? You're asking the system, what are all the bits and bobs, the configurations, what are all the ones and zeros, how are all the switches flipped, right?
And then you're presenting that in report form and comparing it against, say, a framework where a pen test is actually going to be attempting to exercise those controls and trying to circumvent those controls to achieve an attacker goal. So again, you're trying to say, are these controls sufficient? are these configurations sufficient? But you're going about them in two different ways.
Pen test is trying to exercise them, push them to circumvent them. And a config review is pulling evidence. Oh, I love how you've explained this because a lot of times I imagine when I talk about pen testing, or at least a traditional pen test, people just assume that I'm just going to go into an environment, run an Nmap, and Bob's your uncle after that. How would you differentiate between the cloud pen test and a traditional pen test, I guess? Right, so in a cloud...
Pentest, and we're just talking about the scope of the cloud, right? What is the cloud? What is the cloud?
These Layer 7 protocols. It's HTTP. It's these published APIs.
So what are you doing with these APIs? You're attempting to use them. for a particular goal. And your goals are like exfiltration of data, the corruption of data, DDoS.
There's a handful of attacker goals. You're trying to use and abuse those HTTP requests. That's within the cloud domain.
But the cloud domain has these edges where they butt up against other domains. So if your cloud pen test only stays within those CSP-provided HTTP APIs, you're probably missing something. Interesting.
And to your point, most applications these days that are hosted in Google Cloud go beyond that, obviously. It's not just the services that they're using in Google Cloud, whether it's an IaaS or a PaaS or a SaaS service to run the application that could require pen tests, but there could be a broader context of APIs that are probably required a bit more. Like there could be elements of application and network security that would be required that people would have to consider in this.
What's your thought process when you would explain how would you go about pen testing Google Cloud accounts? What's a good... I guess, step forward. How would you begin?
Yeah, how would you go kind of start? Like, I imagine a lot of people who come to this conversation, they want to understand the methodology, what's your thought process. If they were to start doing end testing of Google Cloud or even an assessment of Google Cloud as to what does that look like, what would be your thought process on that? Well, I always recommend people read the docs, right? Understand what you're testing.
Understand that Google Cloud is a resource-based IAM CSP. meaning that every resource can have a policy attached to it, right? So understand the CSP that you're attacking.
Just because you're an expert in EWS doesn't mean that you're going to be an expert in GCP, really have the models flipped on its head. And once you kind of get a sense of GCP, you might end up loving it. That's a sad fact. You might end up really loving how it works.
So step one, RTFM, read the docs. Yeah. Understand what you're testing.
You're going to save yourself so much time. instead of just chasing ghosts. The next one probably is understand the confluence between your web app, your application security, and your cloud security.
That's going to be a lot of your points of initial access is your web apps. You know, you're going to have your public access that's going to be your web apps, hosted on GCP compute, on Cloud Run. So understanding the confluence between maybe a web app vulnerability, like remote code execution, like SSRF.
understanding how those can then translate into a foothold in a cloud. That's going to be your first step in understanding initial access in any of the clouds, really. I love the example you had with, unlike AWS, jumping straight into GCP, you probably would not understand what's going on, especially if there's policy attached to every resource and stuff. Are there any common GCP services that people use?
Because I imagine people who are listening to this may have no context at Google Cloud. but some may do. What are some of the common services that you hear people use in GCP? I'm assuming IAM is definitely one of them because everyone uses identity. Outside of that, do you hear a lot more people using heavy compute or heavy data?
I know I'm throwing off a question, but what do you see normally people use GCP for? Cloud Run's a really distinctive service within GCP. So understanding Cloud Run is a great mechanism for deploying and hosting containers. I forget the project that it's built on, but... I would really understand what that service model looks like.
It's also primarily used for big data, right? If an organization has Google Cloud, it's not likely that they're using it for their web apps. I mean, they might have to look web apps.
It's not likely that they're using it for workloads like they are in AWS. It's more likely that they're using it for big data. So understanding BigQuery is understanding the access model around BigQuery, which is massively complicated. Understanding the mechanisms for it. exfiltrating data with BigQuery, which again is, I cannot count them on my fingers, massively complicated.
Understanding the mechanisms for data access at the table level, at the row level, at the column level, at the authorizer level, cross project, all of that is going to be key for achieving your goals of pet tester, which is demonstrating impact to your client. Interesting. And are there any low hanging fruits that people can look out for in Google Cloud? Yeah, I mean, that kind of goes back. to the maturity of your customer, of your client.
How long have they been in Google Cloud? Where are they benchmarked? There's a really great paper that Google has out. It's called the Cloud Adoption Framework.
And it benchmarks, like there's all these descriptions about where an organization might be on these different pillars along their cloud adoption and understanding where they are in that journey. If they're relatively... early on, you're going to see these markers of low hanging fruit. You're going to see a lot of use of default service accounts, particularly.
And so that's, as a pen tester, that's what you really want to focus on. You want to focus on the use and abuse of default service accounts and the excessive permissions that come with them, that they're automatically assigned the editor rule. which I forgot last time I checked had over 5,000 permissions. It might be six.
It's hard to keep track. Like I said, meet your client where they're at. If that's what you're seeing in the environment, focus on the use and abuse of the default service accounts and the permissions associated with them.
And then focus on trying to get them on a pathway to not use default service accounts, to use custom service accounts with more finally scheduled roles. And what are default service accounts for people who do not know what that is? Yeah. You know, I'd love to know who made this decision, but at some point, there's a room of very smart people at Google who decided that whenever you enable certain APIs within a Google project, automatically a service account is created. There's two default service accounts, a default compute and a default app engine.
So whenever you enable the app engine service account or the compute service account, whenever you enable the app engine API and the compute API, these two service accounts are just... automatically created within your project. And they're assigned the editor roles so that it makes uptick of Google Compute and Google App Engine really easy. You don't have to worry about the permissions associated with those pieces of infrastructure.
They're sort of automatically created for you. And really excessive permissions are created that it's really hard to run into any friction when you're first creating them. Great for uptick, right? if you really want people to use your services right away and not have any issues.
It's horrible for security. And it just seems like there's no way to undo that crime against, you know, service account humanity. It's just baked into the platform right now. And there are, I'm just assuming, countless customers that are relying on this functionality just to keep the engines of their Google projects going.
I can only imagine that there is a lot of hand-wringing internally. about this awful design decision that was made that is causing so much consternation but seems really impossible to backtrack from. So you said like the people who may not be as mature would have the default service account. I'm assuming the experienced ones are deleting them and then that's why you're going to go into a bit more kind of form of pen testing at that point in time?
Yeah, so the more mature organizations are going to enable an org policy constraint that's going to prevent the creation of these so that when you enable the APIs, they're not created at all. And then it's going to force whoever or whoever. is creating the compute and the app engine to create their own service account and then assign a more restrictive role. You could also say another level of maturity scale would be to have all of your service accounts be relatively stale.
So you can say all of your service accounts must only have this very tightly scoped role attached to it. You know, it can only have this one, you know, maybe custom role that we assigned to you. So there's a few different ways.
levels of maturity roadmap that you can do with service accounts. Interesting. And I think I find it fascinating to the point that unlike AWS, and I love the example of Google Cloud also, because it kind of helps explain the complexity of just generally how much Google is used by a lot of companies. And I think we've got, we have a mutual friend, Carl, coming in in a couple of days as well, hopefully.
So we'll talk about the whole idea behind the Azure side of things as well. The uniqueness of our... The cloud usage for Google is the fact that people have Google Workspace, Google Analytics. There's a lot of these Google other products that are almost like an octopus inside your organization already before you even know it. Is there already a direct relationship between if I have a Google Analytics account or a Google Workspace, I already have Google Cloud or do I have to still enable it?
Likely you do already have Google Cloud if you have Google Workspace. By default, Google Workspace is considered like an app. Google Cloud is considered like another app within Workspace. So you have Workspace as sort of the orchestrator.
And then there's all of these apps within the ecosystem. There's Mail, there's Calendar, there's Analytics. And some of these are kind of automatically turned on for all of your users.
And some of them you have to manually enable. And Google Cloud is one of those apps that's automatically turned on for all of your users. So automatically, if you have a Google Workspace present, all of your users can already create Google Cloud.
projects. And that's another one of those design decisions that I'm sure was created to enhance uptick and to reduce friction. It's also created a lot of headaches for organizations.
They realized that they have Google Cloud presence that they didn't know about. Yeah, I would imagine it would be even hard to identify how much of the current staff population in your organization has access to both Google Workspace and Google Cloud. I imagine that would be a challenge as well from an architecture perspective.
Well, if you have control of your Google Workspace, if you've wrangled control of it, that means you registered your domain with Google Workspace and you've gained control. From there, you can understand who has the ability to create Google Cloud projects, and then you can wrangle it in under your domain. Right, right.
But until you do that, and it's sort of invisible to you. And what about things like, so another few terminologies for people who may be new, but the whole Google project, Google organization, folders and all of that. The way I'm thinking about this is like, how do you persist your access in Google Cloud?
Because I think I'm thinking, oh, wait, so if I get access to a Google workspace or someone, a Gmail account, I should try and see if I can go into a subsequent Google Cloud account from theirs. Same with analytics or whatever, for whatever reason, my phishing attempts succeeded. And then the other way I was thinking is, oh, maybe is there a concept of, you know, how. temporary credentials can be created and how do i persist my access like is this kind of where i'm coming from so one way i thought about this was oh okay google workspace jump onto it or create myself a google workspace account no one finds out until six months later that i have an account which has access to google cloud or what are other some of the other ways that people can persist access to google cloud well let's talk about how you mean you persist access within ews like a common mechanism for persisting access in ews is say like i will use air quotes but like backdooring i am saying like updating the trust policy that says like an external entity can assume this role that would be an aws x persistence mechanism so the equivalent in gcp would be to say to take a service account and then to say an external entity can act as that service account that would be the equivalent right and so you could also assign an external entity permissions you at any level within, say, the folder, the project, or within the resources. When your eyebrow raised and this, you know, like, oh, this is very concerning, you can assign external entities access.
But there are mechanisms to prevent that within org policies. So this is probably another teaching moment for clients that if you're able to persist access with an external principle, that this is another teaching moment where you can highlight some of the controls available to them, like restricting external domains. That's a great reminder that shared responsibility is when it started as a conversation between just your CSP and the customer.
I almost feel like it's like a sandwich now where you have the CSP, the cloud service provider, who has their own sets of shared responsibility. Then there's you in the middle, sorry, right next to it, where you're consuming the services from the cloud provider. And then there is another, I guess, to finish the sandwich, you have your... attachment to third party software that'll help you with performance monitoring it and all the things with it so it's all that great sandwich that we live in and share responsibility for me it's like a great combination of as a customer i have to be responsible for my side of security and hopefully i understand that this differentiation between myself and the cloud provider but at the same time do the same for third parties as well and constantly monitor and all of that so i love that external identity example any other examples that come to mind with if you have an example of a security bug you found, or maybe just to help pitch it for people, like what would be an example of a result someone would expect from a Google Cloud pen test kind of thing, which is not just a config review. Well, I love your mention shared responsibility model because it allows me to talk about, Google talks about, you know, they don't have the shared responsibility model or they've kind of iterated beyond that.
Yeah, they think of it more as shared. fate, which is this concept of they have skin in the game as well. As far as how secure the customers are, they should think of it as if a customer is failing, they are failing as well, which I think has led them to create their whole suite of org policy constraints. Shout out to Jason Dyke.
He maintains the org policy bot, which publishes changes. to and updates to the org policies within GCP. And those are those constraints that you can apply in multiple levels of your organization to guardrail and restrict your environment. And by the way, Jason Dyke was on the show a couple of years ago, I think.
But super nice joke about Google Cloud as well. So yeah, I think I'll definitely put a link to that board as well if I can. Because do you find that any common TTPs that come to mind when that you hear from Google Cloud quite often?
I think we kind of... spoke about the external party and i guess having access we also spoke about the service account anything else that pops to mind i mean i guess ttp is tools techniques and the cps yeah that's pretty good yeah because people would be like what is ttp like sounds like a disease yeah it does sound like a disease so what would you say was the common ttps where you can think of for google cloud so google has as a team called the gcat team they put out every Well, times a year, they put out this Threat Horizons report, and there's a really good graph in there just highlighting what they called risky actions. Okay. The Google Cloud, a risky action isn't necessarily a TTP, right?
So this isn't quite apples to apples with your question, but it's a good conversation point. What they highlight in a graph is what are the risky actions that they're seeing within Google projects? Things that they know that might be indicative of a threat action. and how often they're seeing it. And by far, the biggest thing that they're seeing is cross-project service account access.
So a service account that lives in one project and is accessing resources in another. They're defining that as a potential risky action, right? And would you say, is it just a project or can it be, because I imagine at scale, where people have been using it for a long time, I mean, they have been mature. in their google cloud they started in it and now they spend three four years in it would there be like multiple organizations you know how some people have like they started with one aws structure and then suddenly they acquired another company then there's another aws structure no one combines it ever now it becomes your life security you're managing two different structures of it maybe yeah would be common in google cloud space as well absolutely yeah it all gets kind of like hodgepodge together right i just realized that i misspoke the most like most common risky action isn't a service account with permissions in another. It's a service account impersonating another service account, right?
So it's this cross-project impersonation is what they're highlighting the risky action is. And as you mentioned, if there's kind of like what we call organic growth. If there's organic growth within an organization or an acquisition that gets tacked on, you might see some of these risky actions.
Are they TTPs? Are they a threat actor? Probably not, could be.
Yeah. But at a minimum, there are things that highlight maybe not the best practices. And would you say the quote-unquote risky actions, as we're calling it? By the way, I did not know what the report says.
It's pretty awesome that they actually published it because they have a big cybersecurity action team as well. So that's pretty awesome. The team too.
Yeah. I've heard that there's rumors that they have tracksuits as well. So I want to see if they've entered their tracksuits. I might have to look that up one day. people listening i need the gcat team and tracksuits yeah well if there's one i would definitely find out for you as well because i would love to have one of those tracksuits as well we're trying to get one for cloud security podcast but haven't been able to get that yet i'm a good supplier but maybe someone in the comments can help me out with this the next question that i had was more around the enumeration part for we kind of spoke about the organic growth that people may have and i imagine that would add more complexity and so when someone's trying to pen chess would that be right if i was looking at two organically grown google structures you they have to talk to each other.
They have to straight come by the internet. They would not be within the Google network. Yeah.
I mean, there's a couple of different ways to connect them by identity, right? You can establish OIDC connection, right? So there might be a workload identity tool connecting maybe two different organizations, two different projects. And then it's just, you know, it's just another random third party.
There's nothing special about it. Or you can grant permissions from one entity into the other. And then they just use OAuth, right?
So it's all just coming over the internet by either by a... trust via OIDC or just directly writing permissions into the project. That would be how you'd connect them from an identity perspective. And I think from that point onward is basically the application itself.
And again, calling out the fact that it's not like all this while we've collected evidence about using Config Review, collected evidence about the fact that, hey, is anything misconfigured in terms of service account and third party access or anything else that looks suspicious or probably is not a risky action. then use that as a way to kind of go, okay, what's the next thing I can do to gain access to the application? We kind of touched on SSRF just before. And I think a lot of people, when they hear SSRF, they hear the old AWS CLI version of SSRF where they think, oh, it's this profile. I get access to server.
And look at that. Capital One happened after that or whatever. My understanding was that kind of SSRF does not exist in Google Cloud because of the way... their access token in keys works. Is there an SSRF like that in GCP now?
Or would SSRF be the traditional SSRF, not the one that people talk about from an AWS perspective? Yeah, there absolutely could be. It's more difficult, right? And it's more difficult to perform SSRF within Google Cloud because they use tokens, just like you could with IMDS v2 in AWS.
I would say you could. It's very difficult organizationally to move thousands and thousands of workloads to v2. So you don't see a big uptick. That's one of the places where Google Cloud made a good design decision up front.
So certainly SSRF is very much still in play, but more difficult. More likely, we're looking at remote code execution. So when you're looking at those edges where cloud security and application security meet, how can application security improve? form cloud security it's likely with remote code execution so anybody who's looking for like more information on that i love reading bug reports those are often published some of the coolest bug reports from like hacker one are published just look for ssrf or rce and look for their impact in the cloud you can really find some very creative folks in trying to increase the impact of their bugs wow oh actually that's a good word because we've been talking about the fact that the security review or doing a proper cloud pen test is a way to increase the impact of an existing bug you may find which might be traditionally a low risk or a medium risk you at least increase the risk level of the bug that you identified by making sure that you're just including something which is from the cloud security perspective i guess one more question then we kind of spoke about i guess how can people like thought process and what you can find as low-hanging fruit we also spoke about the complexity of architecture i'm also curious if there are any open source tools that i know you have one but i think a lot of people think about when they think about tools for pen testing, they almost think like straight away Nmap. And I think before the call, you kind of spoke about the fact that are there tools like that in the cloud space?
And obviously, we'd love for you to share your open source tool as well, just in what that does and everything. Yeah, there are a couple of tools specifically that are really good for pen testing. Paku from Rhino Security came out five years ago.
Still very tried and true as far as targeting infrastructure that already exists and performing, I think, maybe 30 different attacks you can choose from. That's AWS only. I think Carl has one out that's for Azure. Yeah. Microburst.
Microburst, yeah. And these tools have a couple of things in common is that they're going to be targeting infrastructure that already exists. So imagine you're a pen tester, you get dropped into an environment, you need to target what's there. Yeah. That's what these tools are doing.
I have a tool that was just released that has a little bit of a different methodology. It spins up and creates infrastructure for you. So it doesn't rely on infrastructure that's there. It'll perform actions, you know, attack techniques on infrastructure that I create, manage, destroy with Terraform.
So in that sense, it's not a great pen testing tool, right? If you're going to be dropped in an environment, you need to target what's there. You don't need to target what you're going to create. But it's a really good tool for understanding how attack techniques work.
It's a really great tool for creating detection samples. If you want to understand how... particular attack technique generates logs, this is what you want to use, right?
It's a really great tool for validating your controls. So if you have a control that should prevent an action, you can spin up my project called the DERF and attempt to test that control over and over again by, say, creating an access key against a user. Or you'd say, assigning an external user to a GCP IM policy. Things that you have controls against that should be prevented, you can attempt to test those controls kind of in a continuous manner. Okay, so the infrastructure already existing, infrastructure being created.
We kind of spoke about Strata as well. What was that about? Stratus, yeah. Yeah, Stratus. Well, Stratus is a great project from Christoph at...
ThetaDog, his project has a very similar goal. So it spins up infrastructure for the end user. And it targets more clouds than mine does actually. It targets AWS, GCP, Azure, Kubernetes, and it performs attack techniques against them. But the difference between my tool, DERF, and Stratus is his is operated kind of at the CLI by the end user.
You download Stratus, and it's a single go binary. And you perform those actions from your end. point. What the DERF does is it deploys the attack techniques as Google workflows in Google Cloud.
So it's a cloud hosted project. So I can deploy attack techniques, and I can then automate them in the cloud, or I can have other folks come by and perform attack techniques. It kind of separates me the attack from the attack execution, which might be like an automated process, or it might be some other end user.
Maybe this is a good time to talk about the fact that I would love to kind of have you and I were talking about this I think it'd be good to kind of have a walkthrough of the open source so that people can actually see what that looks like and in action and everything so I'll probably but if anyone has any questions feel free to drop them in as well while we go through the non-technical questions the last few technical questions I had but if anyone has any technical questions for Kat or we feel free to drop them in while I go to the non-technical one it's been some time since you've answered these so I wonder if the answers are any different I'm not prepared for this oh Well, you'll be fine. What if in most time, I'm not working on cloud fantastic? Oh, I'm in my garden, Ashish. Like, if you follow my LinkedIn, it's all just tomatoes right now. I was sick this weekend, but I still managed to make like a bunch of tomato paste.
Oh, nice. I had probably a bushel of tomatoes that I picked. And then I cook down all of those tomatoes down to several quarts of tomato paste over like six hours.
Just like stirring and stirring and stirring. It's like in Minnesota right now, it's like prime harvest season. So my garden felt silly.
Oh, wow. Well, harvest season sounds like a good idea as well. I was going to drop a link for the DERF cloud.
Because you can get a comparison of the entire process as well in terms of how it would look like for which of the tools you use. Only then for people to kind of... copy and see what that looks like.
The other question that I had for you, which is non-technical one, but it's something that you're proud of that is not on your social media. Tomatoes? Yeah, probably.
Oh, let me get this for you. This is my favorite tomato. Oh my God.
Every year I give a ribbon award to my favorite tomato. This is my favorite tomato this year, everybody. I've not put this on social media, so this counts.
This is exclusive. How massive is that? It's not that big.
It's maybe a pound, pound and a half. I've definitely grown larger tomatoes, but this is... winning the award for the best tomato this year for its color its consistency look very little blossom and rot look yeah wow so i did not realize there was so much detail with tomatoes as well this is a pink jazz tomato and this won the blue ribbon award this year all right okay well i thank you for sharing the exclusive last one what's your favorite cuisine or restaurant that you can share of indian food ashish like i we have a dosa restaurant less than a mile from my house if you come by i'll just like feed you those sales. I would definitely try that out as well. So I appreciate the exclusive of the tomato as well.
So thank you for sharing that. For people who want to know more about DevCard, I'll put the link on the show notes and when this goes on YouTube as well. Where can people find you otherwise on the internet? LinkedIn, I guess.
I'm on Nightmare.js on Twitter. Also, I'm on the InfoSec Exchange. I'm pretty active on the InfoSec Exchange Mastodon.
I really like it. Are there people there? I feel like there's...
Yeah, there's people there. Me. No, I mean, more than you. Because I feel like I don't hear much about it.
So I just wasn't sure if people are still hanging on there. I think so. You know, it comes in waves. Whenever there's like some controversy on Twitter, if more people show up, I'm hanging on.
I'm hanging on to Mastodon. Fair enough. But Mastodon, I imagine the company is basically going, we want more controversy with Twitter because we keep getting the people maintaining this. But I'll put that in the show notes as well.
So people can find you over there as well. But thank you so much for coming on the show. And I will make sure.
that we have another session to walk through on the whole dev cloud as well so thank you everyone else who was watching and look out for the episode when it comes out on youtube as well but otherwise we'll see you next episode thanks guys thanks everyone else see ya