How do you perform incident response on a Kubernetes cluster when you're not even on the same network? In this episode, Damien Burks, Senior Security engineer breaks down the immense challenges of container security and why most commercial tools are failing at automated response.While many CNAPPs provide runtime detection, they lack a "sophisticated approach to automating incident response or containment" in complex environments like private EKS . He shares his hands-on experience building a platform that uses a dynamically deployed Lambda function to achieve containment of a compromised EKS node in just 10 minutes, a process that would otherwise take hours of manual work and approvals .This is a guide for any DevSecOps or cloud security professional tasked with securing containerized workloads. The conversation also covers a layered prevention strategy, the evolving role of the cloud security engineer, and career advice for those looking to enter the field.
Questions asked:
00:00 Introduction
02:15 Who is Damien Burks?
03:20 The State of Cloud Incident Response in 2025
05:15 Why There is No Sophisticated, Automated IR for Kubernetes
06:20 A Deep Dive into Kubernetes Incident Response
07:30 The Unique Challenge of a Private EKS Cluster
12:15 A Layered Approach to Prevention in a DevSecOps Culture
17:00 How to Automate Containment in a Private EKS Cluster
17:40 From Hours to 10 Minutes: The Impact of Automation
22:00 The Evolving & Complex Role of the Cloud Security Engineer
25:40 Do We Have Too Much Visibility or Not Enough?
29:00 Career Path: The Value of Learning to Code for DevSecOps
35:00 Damien's Hot Take: "Multi-Cloud Just Means Chaos"
44:20 Career Advice for Traditional IR Professionals Moving to Cloud
47:50 Final Questions: Video Games, Life's Journey, and Gumbo
Damien Burks
Damien Burks: [00:00:00] Without the automation, it was within a regulated environment. It's gonna take you hours. Okay. I was able to contain an EKS, no, within about 10 minutes time.
Ashish Rajan: What does it look like when we are doing a incident response for a containerized workload? A Kubernetes workload?
Damien Burks: Let's say for instance, you have a private cluster in EKS.
Right? Okay.
Ashish Rajan: Already complicated.
Damien Burks: You have to be in the same networking configuration in order for you to be able to interact with the Kubernetes cluster. Yeah. The majority of what I see is. There isn't a sophisticated approach to automating incident response or containment inside of those type of complex environments.
Do we have too much visibility now? I would say that because sometimes the tooling that is being used can be a bit too noisy. More noise is better than no noise. Yeah. Multi-cloud to me just means chaos. I don't see that being, that's, to me, that's not realistic.
Ashish Rajan: If you have tried doing incident response to a Kubernetes or a container workload, perhaps I've missed out on the complexity of just.
How can he even plan a [00:01:00] playbook when you are not even in the same network? I had a great conversation with Damien Burke, who is a repeat guest of Cloud Security podcast, has been in the financial and regular industry building automation for incident response, and over time he's kind of understood a few things that work and that don't work.
So in this conversation, we spoke about some of the things that work and don't work. What can you do from a dev cycles perspective to prevent some of these things? And if you are trying to look for a new job as a senior cloud person, what are some of the real challenges out there and how, what kind of path you can take, even if you're starting for the first time.
All that a lot more in this episode of Cloud Security Podcast. If you are watching or listening to an episode of Cloud Security Podcast for a second and third time, I would really appreciate if you can double check that you are subscribed and following us on the platform you listen to us on, whether it's on Apple or Spotify, or if you watch it on YouTube or LinkedIn.
I hope you enjoy this episode and I'll talk to you soon. Peace. Hello. Welcome to another episode of Cloud Security Podcast. I've got Jamie with me. Hey, man, thanks for coming on the show. Hey, happy to be here. Oh, man, I mean, I love repeat guests, so I'm excited for this [00:02:00] conversation. Could you give a bit, uh.
Could you give us a bit of background about yourself, cybersecurity, professional life and all of that?
Damien Burks: Yeah, absolutely. So, hey everybody. Um, I'm Damien. I've been in the cybersecurity industry for a little bit over six years, I would say. Well over six years now. Uh, started out in application security as a security software engineer.
Um, building out tools for, you know, incident response, um, and application security engineers. And then, uh, somehow some way. Found my way into the cloud, um, and then transitioned into Cloud DevSecOps engineering. Um, where I basically built a incident response platform from the ground up in the financial services world, and then pivoted into a senior cybersecurity engineering role.
Uh, I would say like a FinTech company. Yeah. Um, and here I'm basically, I just started a couple weeks ago, so don't have too much to say about it, but my overall experience has really just been in the cybersecurity and the, uh, sec, uh, security development world. Um, also I'm a content creator, um, have a YouTube channel, and then I [00:03:00] also run an open source project called the Devs SEC Blueprint, which is basically helping people get into DevSecOps.
Yeah. Um, and providing them like that paved roadmap with all the recommendations and even. Projects that you can do. So yeah.
Ashish Rajan: Awesome. Now, and thank you for sharing that as well. We, the last time you came in, we spoke about incident response and uh, you obviously participated in the advent of cloud security as well, where we spoke about some of the Kubernetes pieces.
Container workload is still definitely top of mind for a lot of people. Kubernetes is top of mind. How much has incident response changed in 2025? I think obviously there was a, I feel like a lot of things are evolving, uh, whether it's cloud and throw some AI in there if you want to. Mm-hmm. How much has it evolved today?
If, uh, you were to define incident response in cloud, how would you define that today?
Damien Burks: It's become more sophisticated. Um, and the reason why I say is because. Now I'm gonna throw AI in because it's, you know. Oh, of course. It's one of those things. Yeah. But you know, now we have AI workloads being added into the picture.
Mm-hmm. Um, and with those, you have like, you know, those [00:04:00] data lakes and you have those agent models and all those different things running in the cloud and. Incident response. Like you have to look at it, not from just the, the top level, but you have to go a little deeper. It's just like, okay, if it's running on these workloads, like I have to understand like all these servers that it's running on.
And then I also have to understand the configurations and how not to break things. Or if I need to break 'em, I have to. Right. Yeah. Yeah. Yeah. When it comes to the security, uh, the container aspect of it, the container security aspect, I believe that it has become a bit more nuanced, um, because.
Kubernetes is a ever evolving platform, and there's always something new coming out. There's always this new technology to support, like all of the various different aspects of it. Yeah, so it's like it's own cloud. Yeah. And you can take it and throw it into a CSP or you can build your own cloud with Kubernetes and.
When I look at some of the platforms that they have that's coming out right, like all the [00:05:00] CSPs and Synaps and all the various different type of runtime scanning solutions and stuff like that the majority of what I see is there isn't a sophisticated approach to automating incident response or containment act activities and actions inside of.
Those type of complex environments. Interesting. A lot of it is manual. You have to build it yourself. They may have, you know, like runtime detection and be like, oh, well we detected that. Like something happened in your network. Yeah. Groups or whatever in Kubernetes. And it's like, oh. Okay, well can you respond to it?
It's like, whoa, that's quite complex to do. So in short, yeah, incident response has evolved quite a bit, but the thing is, the automation part I feel is still lacking and I think that's gonna be a, a much bigger problem if no one jumps onto it. Interesting.
Ashish Rajan: Because you've obviously worked in regulator industry to what you were saying as well, which comes with its own regulatory challenges.
Yes. Infant response. How is it? I guess maybe let's talk about how is [00:06:00] that one approaches incident response to a container workload? Mm-hmm. If you can describe that. Uh, obviously we spoke about containment, so I'll definitely encourage people to check out the episode, but if you were to describe what does it look like when we are doing a incident response for a containerized workload, a Kubernetes workload.
Where are the logs? What am I looking at? Uh, what, what is actually available? Right? So people have some idea, and then maybe we can add the layer for where do you find yourself doing the automation part?
Damien Burks: Yeah, absolutely. So if I were to look at this, right, um, and let's say like some, one of the pods and the Kubernetes cluster is exposed or something like that.
Yeah. Um, if you're looking at it in AWS, of course. You'll have, you know, your CloudWatch logs. Yeah. Hopefully mapped to some of the, some of the things that you're got working on. And the thing is, Kubernetes and AWS is so complex because whatever role that you're using, yeah. You gotta make sure that you can act.
That role is mapped to the config map that's attached to an rback role within the Kubernetes cluster. If you don't have that there, then of course it's not going to give you the permissions or access that [00:07:00] you need. Yeah. So performing a reconnaissance require permission upfront.
Then you look into the pod, you inspect the node, you look at the logs in the Kubernetes cluster.
And then from there, you, that's two CloudWatch. All, all of that is by basically using a co kube ccu. Yeah. Okay. Yeah. Keep going.
Ashish Rajan: Yeah. Yeah. How, how, however people wanna say it. Qt. Yeah. Right. I've been our pure over here, so Yeah. I'll, I'll take whatever you to gimme. Yeah, yeah,
Damien Burks: yeah. And you can look at all of that and.
You have to make sure that, like, of course you update your kube config with the Ks in order for you to be able to do it. And then once you've identify like what the pain points and the gaps are within your cluster,
Ashish Rajan: yeah,
Damien Burks: then the automation is actually gonna be the hardest part.
Ashish Rajan: Okay.
Damien Burks: And I'm speaking from experience because there's a time where I had to write an automation, uh, automated job to basically go in and contain a ku EKS node.
That's been compromised and the issue. Is let's say for instance, you have a private cluster in EKS. Right? Okay.
Ashish Rajan: Already complicated. Exactly right. [00:08:00] Yeah, yeah,
Damien Burks: because you can't you cannot reach out. To, you have to be in the same networking configuration. Yep. Same VPC, subnet and Security Group in order for you to be able to interact with the Kubernetes cluster.
Yeah. Yeah. So what that means is that somehow, some way your automation, you have to have something that you can deploy to attach to the cluster inside of The network. Yeah. Same networking configuration. Yeah. And then run those commands. Yeah. In a scripted form. Right? Yeah.
Ashish Rajan: And hopefully not break the chain as well in the meanwhile.
Exactly. Yeah, exactly.
Damien Burks: I can tell you many a times I've broken that cluster.
Ashish Rajan: Yeah. But
Damien Burks: that is, to that point, I've evaluated several solutions already.
Ashish Rajan: Yeah.
Damien Burks: You know, CSPMs and CNAPPs to even go that deep, and none of them so far have gone that deep. To be able to say like, oh, well yeah, you have all these complex issues and these complexities, like how do you manage to contain something if inside of Kubernetes, if it happens?
Ashish Rajan: Yeah.
Damien Burks: Or it's just like, oh, well we can just deploy some rundown stuff in there and and [00:09:00] call a day. I'm just like, no, but what if it gets like deeper than that?
Ashish Rajan: Yeah.
Damien Burks: There's so many different areas that you have to cover. You have to think about.
Ashish Rajan: Yeah.
Damien Burks: And. When you add cloud onto it, it becomes way more complex.
Ashish Rajan: Yeah. 'cause you lost access to the Yeah. The work, sorry, the main order anyways. Yeah. Yeah. So the work order is the only thing you can work with and Oh, okay. So I see what you mean. 'cause to your point is when you evaluated the CSPs and CNAPPs to look at automation. Did you find the how? How close can they, 'cause I feel like runtime is more still detection.
It's not really, it's
Damien Burks: not, it's not automated response. Like,
Ashish Rajan: yeah, like I think I'm thinking like that just gives me the fact that, well, if it was to happen again, we'll be able to detect it. I mean, it's not that, hey, incident has happened right now.
Damien Burks: Yeah.
Ashish Rajan: And Damien needs to go in and do something about this.
It doesn't help in that context.
Damien Burks: No. You have to go through it manually. And the thing is, it's like. Having, it takes hours, right? You don't have as incident [00:10:00] responder, you don't have hours Yeah. To go in and do things. Yeah. And then if you're in a highly regulated environment, you're probably going, you have different layers of approvals that you have to go through to get access first, and you gotta go and you have to go through the different channels.
You don't have God level access right off the bat, just to be able to take care of your jobs. Yeah, yeah. So you can imagine the amount of time that it would take. Yeah. Right. For. The attacker to be able to pivot into so many different things.
Ashish Rajan: Yeah. To your point. Mm-hmm. This is where containment is even more complex because, wait, so wouldn't containment in this context mean that the person is already, or sorry, the entity I'm sound like mission impossible entity watching way too much mission impossible.
So whoever the attacker is also running like a sidecar in the same cluster. If, wouldn't they have, wouldn't they have to be in the same cluster? Or is, would it be more like the pod? So the port is compromised. Mm-hmm. Also, they're in, in the pod. They're already just, but they can't come out. Right. 'cause they're already in a private network.
Damien Burks: Depends on how you configure it. And that's the thing is just [00:11:00] like actually, because Port Now has
Ashish Rajan: IAM roles as well, so you like rback roles and all that stuff.
Damien Burks: Service accounts attached to it. So it's just like they can get away with some things if you're, if you're pod allows it.
Ashish Rajan: Yeah. And your pod has access to a S3 bucket.
Next thing you know, you have the data flowing out as well. Pretty much,
Damien Burks: and it's, and that, and I think that happens if I'm not wrong, if I'm not mistaken, that can happen at the no level too. Like your node has the, the role attached to it. Yeah. So it's just like all the pods made. Indirectly have access to that at Street Bucket.
So it's just, it gets really complex. So you have to really understand like how your EKS environment is configured to begin with, so, ah, interesting.
Ashish Rajan: Wait, so now, I mean, how does we need approach this? 'cause to your point, you don't have hours. Yeah, but at the same time, I'm thinking for people who are maybe listening or watching to this going.
Uh, I mean, 'cause there's one thing with servers, which are easy to instance and all of that. I think it's still understood. We've done that with on-premise. So you can apply a similar model maybe with some cloud sprinkles in there. [00:12:00] In a container world, there's ones of your inside a worker node and you've made sure you have deployed a part of yourself so you can run the commands.
Mm-hmm. You still haven't contained anything yet. Yeah. You, you're just basically collecting data points. And possibly, uh, getting rid of the, the kill chain. Also not kill chain. You've broken the chain of custody. Yeah. Uh, in a way because now you have entered a new parameter inside this sacred environment.
Now, quote unquote sacred. How did you approach it? I'm curious as to, and maybe if you pay, if you paint a simple scenario for Yeah. What would your simplest use case? Yeah. I imagine that it can get quite complex.
Damien Burks: Yeah. My, the way I approach it, when I, when I was writing, I was building the, the, the platform and, and tooling for it was, yeah.
I was like, I need to understand Kubernetes first. I need to understand how it works internally. And then from there I look at the cluster. I see how it's configured. Yeah. At the very like top level, like looking at the AWS configuration. So I started the roles that are associated with the nodes start at, you know, like, [00:13:00] um, the control playing role and all those different things.
Understanding the identity and access management landscape first. Yeah. Yeah. Then the networking components. 'cause that's the key thing. It's just like, okay, well. Which nodes are allowed to access the web versus which ones aren't, or if it's just completely private, right. Yeah. If it's completely private, then I mean, that's good.
Um, but then like, how do I get access to it? Yeah. And then now that's the, that's the big thing. So. Automation basically failed Right there. Right there. Yeah. Yeah. Because networking, I mean like even when you call like on the back plane, like bottle three API calls, like you can definitely do that.
Ashish Rajan: Yeah.
Damien Burks: Um, but it's when you're trying to run this kube control commands to do administrative things on the cluster,
Ashish Rajan: yeah.
Damien Burks: That's when it's gonna become a problem. I think
Ashish Rajan: worthwhile explaining that layer for people who probably don't even understand Kubernetes. 'cause I think they're like, what are, what does Jamie on about, you can just run API calls and get any information by S3 bucket, right? Yeah. Like what? And I think, I think, uh, maybe it's a bias because you and I probably know Kubernetes, [00:14:00] that people just assume that, I mean, I can make an API call to EKS cluster. What's, what's missing there? And I think I would love for you to explain why is that differentiation of I have an API access to Amazon versus I have an access inside the cluster.
Why, why is that differentiation important here?
Damien Burks: The reason why is because Kubernetes in itself is pretty much thing I, I, I, the way I look at Kubernetes is, it's like it's own, it's a container orchestration platform, right? Yeah. It's
Ashish Rajan: a self-contained.
Damien Burks: Self-contained, yeah. And EKS is elastic Kubernetes service.
It's a service that runs Kubernetes on the backend.
Ashish Rajan: Yep.
Damien Burks: So it's like Amazon has provided you this service, but you still need to be able to run the commands native to. To administrate it,
Ashish Rajan: right? Yeah. Inside the cluster. Inside
Damien Burks: the cluster. Yeah. But in order for you to get inside of it, you have to make sure that your Amazon networking configurations and all of that allows you to be able, yeah.
Okay. Yeah. So yeah. Yeah. It, it's, uh, the way I look at it, [00:15:00] it's um, there's the Amazon identity
Ashish Rajan: Yeah.
Damien Burks: And access management or, you know, all of that. There's the Amazon networking stuff. Yeah. And then after you get to that point. Then there's the link between the Kubernetes R back rolls, and then your Amazon Im roll.
Yeah. Or users, yeah. Yeah. And then there's the Amazon networking component. Yeah. Which have to, is is there federation
Ashish Rajan: in there as well, outta curiosity? Can you federate into an EKS cluster? Um, I haven't seen that myself. I
Damien Burks: haven't seen that.
Ashish Rajan: Yeah. 'cause I. The reason I call that out is because a lot of people may even think, oh, I've got federated access to my AWS account 'cause that should be fine for us.
I'm like, no, you're still only getting access to just the EKS cluster outside layer, if that makes sense. Yeah. You can find out how many ports do I have, and perhaps what node am I running from API calls. But you're not going in, you're not getting like the, the deeper nuance of what's running inside and.
Can the logs be pulled out into CloudWatch? I believe you can. Yeah. Okay. So at least the logs can be pulled out. Yeah. And you can use CloudWatch to investigate the log and [00:16:00] everything, but you're not, you're still not inside the machine. Yeah, you're still basically trying to see from the logs and maybe, and actually so what, sorry, I didn't wanna stop your containment thing.
I just wanted to explain the differentiation between the surface level and the deeper level uhhuh. So you were telling me about the containment. How did you automate that thing? So what was your approach?
Damien Burks: So my approach was, um, looking at that because at this time, I was basically create, I had a privatized cluster.
Ashish Rajan: Okay.
Damien Burks: I had to create a Lambda function.
Um, and basically automate the creation of the Lambda function to throw itself into the clusters, VPC
oh subnet, and then also the security group, and. With that, I had to also put like the, um, I remember the Kube CTO commands inside of the Lambda function.
Mm. To execute, to run like all the different things to interact with the cluster in an automated fashion.
Ashish Rajan: Oh. Um,
Damien Burks: because when you're, when you have a private cluster, unless you're, [00:17:00] um, in the network, the bbc, the network Yeah. Or your IP is whitelisted in the security groups and stuff, you can't And private link and stuff.
Yeah, exactly. You
Ashish Rajan: can't access
Damien Burks: it. You can't. You can even if you tried.
Ashish Rajan: Yeah.
Damien Burks: And that was my, that was my approach to be able to automating that. It's not the best of course, at the time, but it was something that, it was a way forward without having like a bastion host. Mm. Because the bastion host isn't really automated, if you want me to be honest.
Like you still have to ssh into it. I mean, dam Damon, I will turn that bastion box off when I'm done with it.
Ashish Rajan: Exactly. I'm not gonna walk away thinking, I'll, I'll do this tomorrow. Like, because it's not, that incident is a resolved in a couple of hours, sometimes. Takes days. Exactly. And you leave the passion box open 'cause you wanna recreate that tomorrow.
Yeah, exactly. But to your point. In a, in a regular environment, uh, with Lambdas being included inside of EPC, uh, being able to pull the information from, how far could you get with the containment part with Lambdas? Like as in, in terms of what would have happened without the automation and what were we able to achieve with the Lambda functions?[00:18:00]
Damien Burks: Uh, so without the automation, it was within a regulated environment. Um, it's gonna take you hours. Mm-hmm. Like, it's probably gonna take you hours. 'Cause there's level of permissions and access that you would need to go through. Yeah. But if you look at the Lambda function and you have something that automatically provisions and adds, it does all the dynamic lookups that you need.
Matter of minutes.
Ashish Rajan: Oh, right. Okay. Yeah.
Damien Burks: Oh, right. Okay. I was able to contain a EKS snow within about 10 minutes time.
Ashish Rajan: So from the moment you were notified that there's an incident in this particular
Damien Burks: to the incident response plan to creating a lambda function and all of that? Yeah, roughly about 10 minutes to take care of everything.
Ashish Rajan: And you have the logs, the backup and everything. Oh, wow. Okay. That's pretty good, man. Yeah. And wait, so is this, and to kind of scale that up as well. Large organizations would have multiple incidents running because you were able to scale this across multiple as well. So you at least had it dot down to the point that you could just deploy multiple land functions across the, in and across the organizations.
Oh, right. Yeah. Interesting. So, wait in terms [00:19:00] of, I guess how, I also wanna talk about prevention as well, I guess. Mm-hmm. There is, there is a side of obviously trying to do the dev stack printout, oh, sorry. The dev stack. Dev Blueprint.
Damien Burks: Uh, Devex. Devs. SEC Blueprint.
Ashish Rajan: Devs SEC Blueprint. Yeah. Yeah. So I know you're trying to do the devs SEC blueprint, trying to pave a road towards how can people be DevSecOps more or more DevSecOps.
I'm wondering with the incident specifically when it comes to Kubernetes clusters mm-hmm. Uh, what are some of the, um, I guess quote unquote, is it more AppSec? Is it more the cloud security side? What are some of the components in that particular thing that people have to think about? Uh, especially for people who are looking at a dev ecology where.
Everyone's been told, Hey, we need to do DevSecOps. What would that look like? And how much of it is achievable in a regulator environment?
Damien Burks: That is a good question. Um, so I will say this, it's layered from an application security side. Yeah. Of course whatever applications that you have running on it, you have to think about [00:20:00] how, what type of.
Entry points that you'll have. Right? So secure coding is definitely recommended. I mean, like it's enforced Yeah. In a heavily regulated environment. I'll say that. Yeah. Um, you also have to think about, um, once you've gotten taken, you've taken care of the secure coding, make sure you know, like your app that's running isn't susceptible to SQL injection across high scripting then.
You get into the container security portion.
Which I believe kind of falls in that scope of application security. And not to mention also the dependency scanning. Okay. Um, because everybody, when you, most people, when you're developing an application, you're gonna end up using someone's dependencies.
Imports, like open source projects. Yeah. Photo three, for example, is a dependency. You import all of that.
Ashish Rajan: Yeah.
Damien Burks: And you gotta scan that, make sure that's not vulnerable. Now you've packaged up your application. Now you gotta get the container taken care of. And that is the big part. Yeah. Because if something does happen and let's say the [00:21:00] attacker gets into your pod, they hack your application, they get into running your pod locally.
Yeah. You do realize that like there's still commands that they may be able to execute to make things happen. Container hardening is important. And when you look at the container hardening aspect, because that's what's gonna be running, that's what your pod is gonna be running is your docker image that's been on container, right?
Yeah, yeah. Containerized. Then it's just like, okay, that's secure now then we look at the C cluster configuration. Mm.
Ashish Rajan: Okay.
Damien Burks: And that's where you have to understand Kubernetes as a whole. Um, you know how to configure your network properly, how to configure your service counts, what are some of the best practices from a Kubernetes standpoint.
And then once you've learned that. You now have, okay, Kubernetes as a service. Now let's look at the Amazon best practices and let's see how we can align everything that we've just done to the Amazon EKS best practices. Mm-hmm. And then the, of course, [00:22:00] from an incident response standpoint, yeah, there is, you know, the Amazon EKS incident response best practices.
Uh, so end to end, that's what that would look like. And. Does that answer your question? Because I think no one It does. It
Ashish Rajan: does. It does. Because I, I was, I was gonna also add how much AppSec, 'cause we were talking about this before we started recording. Uh, the whole cloud security role is quite complex these days as well.
I'd love to hear your perspective on how much has it changed? What are you seeing? 'cause obviously. I think the, the general belief for cloud security people is just that we are just looking at cloud security alerts and responding to it, but there's so much more to that one role. So how do you, a, how do you see that role today?
Why is there so much complexity around it?
Damien Burks: I, I think the way I see the role today is that maybe a couple years ago, most of the cloud security engineers were basically heavily focused on security infrastructure.
Ashish Rajan: Yep.
Damien Burks: Yeah, it's all about security infrastructure. You got compute, you got all these different things.
It's great. In most of the cases they're, you know, like if I'm thinking of AWS, [00:23:00] like the popular AWS services is what people mostly are focused
Ashish Rajan: on. Yeah. Yeah. Make sure there's logging. Yeah. Make sure I'm looking at the misconfiguration, all of that. Yeah,
Damien Burks: yeah, yeah. Now it's like, okay, we're actually running production workloads.
Mm-hmm. And. We also add in, you know, now this AI into it. And we have these data lakes. We're using SageMaker, we using all these different things. How do we effectively secure those type of attacks, right? Mm-hmm. Or those type of services that are being used in that way. Yeah. And there is more of an emphasis on automation now because of how.
Complex cloud environments are becoming mm-hmm. You have to automate as much as security as possible in the cloud. Detection, preventive detection, detective guardrails, proactive guardrails, preventative guardrails, like all those things have become paramount. Um, when defining your cloud environment and making sure it's secure.
And there is to me, [00:24:00] as a cloud security engineer. You're, there's gonna be different pathways for you to be able to solve that. 'cause not every cloud environment is gonna be the same.
Ashish Rajan: Yeah. Yeah. You walk into new places, it's a completely new environment.
Damien Burks: Yeah. They're just like, one place may be using AWS config is a detective thing, you know what I'm saying?
To detect all the misconfigurations. Another place's just like, well, we're not using that. We have like this whole nother CSPM that we're using. Yeah, yeah. To do everything.
Ashish Rajan: Yeah.
Damien Burks: And we actually require you to learn Python, to be able to build out those custom remediation, those cuts of detecting that are missing.
Ashish Rajan: Yeah.
Damien Burks: And then in another sense, they're just like, oh, well. We're actually using, one single CNAPP to handle it all. Mm-hmm. You don't have to do anything. You just gotta write rego policies at this point. Yeah. So it's just like. It looks very different. Yeah. No matter where you go. Yeah. And your role and responsibility is gonna defer based on what the company actually needs from you.
Ashish Rajan: Yeah.
Damien Burks: Um, but I'm seeing it's becoming a sliding scale across application security, infrastructure security, maybe container security. 'cause there are some roles [00:25:00] that I'm seeing that it just like, oh yeah, you're a cloud security engineer, but your focus is really just gonna be Kubernetes in the cloud.
Yep.
Ashish Rajan: Yep.
Damien Burks: And then. There's also like, oh, well now we got this AI cloud security engineer. Yeah. And your focus is gonna be securing AI related workloads in the cloud. Yep. You know what I'm saying? Yeah. So it's so many different roles now. It's Yeah. And I it's become much more mature.
Ashish Rajan: Yeah. Yeah. Oh yeah. We are not talking about like, I think, uh, how to install a CNAPP, I guess anymore.
Yeah. That we've gone way past that. Yeah. Actually do you know how I was talking about this for the past couple of days, the entire industry started on the foundation that we don't have visibility. Do you feel we have solved visibility? Do we have too much visibility now?
Damien Burks: I think we have solved, I think we are halfway there with visibility.
Ashish Rajan: Oh, okay.
Damien Burks: I would say that because not, and the reason why I'm saying that is because sometimes the tooling that is being used can be a bit too noisy.
Ashish Rajan: Oh, right. So I
Damien Burks: think you mean the
Ashish Rajan: right [00:26:00] kind of visibility. Yeah. Right, right. Kind
Damien Burks: of visibility.
Ashish Rajan: Yeah.
Damien Burks: But I think that, to be honest with you, more noise is better than no noise.
Ashish Rajan: You know? You might as well know I could detect it if I wanted to. Yes, exactly. Yeah, exactly.
Damien Burks: So I think that like we're on track because there's so many different. Ways to increase or enhance the visibility of your cloud environment and your posture, of course, with the CSPM tools and stuff like that.
Ashish Rajan: Yeah.
Damien Burks: But I think that there needs to be a bit more emphasis put onto like. Helping out, helping filtering out the noise and actually aligning them the, no, the detections and whatnot to, you know, like those frameworks that are out there and really like making action get, providing you actionable insights and metrics on what you need to look into.
Ashish Rajan: Mm-hmm. Because
Damien Burks: I feel that. A lot of the visibility that, you know, like a lot of these schools that are scanning and stuff like that, they're providing you insights on Misconfigurations. Yeah. [00:27:00] But like, what about the, like, how can we assess that? Oh, well this misconfigured resource, like this bucket is actually something that we need to action.
Mm. And I think that's something that. We probably should look into from a, you know, visibility standpoint.
Ashish Rajan: Yeah.
Damien Burks: Or maybe that gets into like a more sophisticated detection engineering approach.
Ashish Rajan: Yeah. So to your point then. Because cloud security is, and I'll probably add something to the, the cloud security roles you mentioned as well.
I definitely agree. It's a sliding scale. I've also spoken to people who do AppSec and CloudSec in one particular role because it's a small startup and they want someone who's a jack of all trades. And I'm going, how can you like, I mean, I'm a. I would in no way would describe myself as a programmer ever.
Like, so I'm not gonna be sitting, sitting there and saying, Hey, I can do SaaS. Yeah. And I know exactly No Chad g Bt, or no, Chad, GBD, I don't know that shit. Right? Like, so, so I'm like, I'm not, I'm gonna raise my hand and go, I'm not the [00:28:00] guy for this. And, uh, the funny, the, I mean, maybe not so funny story 'cause I, I, I started as a ciso.
I've tried DevSecOps programs twice. First I miserably failed and the reason for that was I actually went down the path of doing a DevSecOps program, starting with SAST, with team members who were cloud security people first. 'cause we all thought, how difficult can this should be? Like I just need to find out.
I had the right tool, I bought the tool, and now I have visibility into it. I take that shit to the developers. It should be solved. Yeah. And then they ask you the question for, oh, you tell me how it needs to be solved. Because I don't know this myself. Now you're in this, uh, in, in a bit of a pickle now.
'cause you've raised the problem.
Damien Burks: Yep.
Ashish Rajan: And somehow you don't even know if this is a false positive because you have no clue how this thing works. Yep. So now you're trying to stand there trying to validate, I, let me work on that and come back to you. And you never to go back to the person again. The person like, yeah.
What happened? Every time the person sees you, like, Hey, what happened to that issue? And like, [00:29:00] yeah, we, we moved on. I think we found out it was like not needed or whatever you guys Yeah. Anyway. I think so that was the first time it failed. Second time round I was a bit more smarter, and we walked on the path of doing lead credential as the first one.
Mm-hmm. To identify, Hey, is there any credentials being leaked into GitHub or wherever? Yes. That I, it was an example where I found that everyone understood it. Whether you are cloud, AI, whatever, it doesn't really matter. Insert, everyone knows you should not put your username password anywhere. Absolutely.
Yeah. So that was the easiest milestone to people, for people to be onboarded onto a death calls program. Yes. Obviously story continued, but I think I definitely find that these days. Are you finding that because there's complexity in the cloud security pieces people have started building platforms to what you were saying earlier, that you go into a company, there's a Kubernetes platform that is dedicated just for Kubernetes building.
Mm-hmm. And your ES engineer for that. So with the blueprints that you're working on mm-hmm. The roadmaps and the payroll you're [00:30:00] building on, how are you guiding people to even. Navigate this thing. 'cause it sounds like there's a lot of information, I mean, obvious the, the reason you and I and a lot of other people are in this field.
Yeah. Is basically all the years you've spent trying to understand Amazon, Microsoft, Google, all of that. Or at least one of them. We have got the grays for it as well. Yeah, exactly. The gray hairs I
Damien Burks: was pointing to one as coming out right now. Yeah.
Ashish Rajan: So how does one, uh, what's a good starting point? Are you finding that people can walk?
Because you're obviously doing mentoring as well. Yes. So I'm thinking more from that perspective as well. People are coming into this now. They obviously have on one side, people are telling, Hey, AI is solving all the problems, use AI and all of that. And on the flip side of it, people like you and I and others who have been in this field for a while, they're like depends on the company you go to.
Just because you get an AWS certification doesn't really mean you're walking into like a easy job. Yes. Right? Yeah. So how are you advising people on this to approach this problem?
Damien Burks: So there's a few things. Number one, I. Don't believe that AI is here to [00:31:00] replace people. If anything, I think AI is here to compliment you.
Ashish Rajan: Yeah. Um,
Damien Burks: you use it to help you get better at what you do. You use it to help you learn different things, and then you also talk back to it and say, that's wrong. And then you tell it what the reason is so you trust but verify. So get used to that. But I also wanna say that like, from my perspective, 'cause I've, I've again gotten this question a lot, right?
I had one guy, uh, had a networking call on my Discord a couple of weeks ago and he was just like, how? Do we approach DevSecOps from the very beginning and then now that AI's involved, like what does it look like? And I told him, I was like, well, from the very, let's start at the very beginning.
When you look at DevSecOps as a whole, you look at cloud security. Yeah. And you look at like, you know, some roles are very different in a sense. You the, the very beginning is really to understand basic cybersecurity fundamentals. Yeah. You start there first, you understand what the various different attack vectors are.
You learn the history of social engineering, and then once you kind of start adopting that mindset, you start to change it a [00:32:00] little bit.
Ashish Rajan: Yeah. Yeah.
Damien Burks: Then you start getting into coding. Now, here's the thing about coding versus programming, because I believe they're totally different things, and if people want to argue with me, that's fine.
I'll die on that heel.
Programming is something that a DevSecOps engineer can benefit from.
And the reason why is because you have to sit there and you have to put yourself in a developer's shoes.
Ashish Rajan: Yeah.
Damien Burks: These SaaS scanning tools are there to help them be better at securing their infrastructure.
But they're not the experts at this stuff. You are.
Ashish Rajan: Yeah.
Damien Burks: So you have to understand, like if they're coming to me and they're saying like, I have broken authentication, I don't understand why it's scanning that. Yeah. You have to go and look at your, look at their code and be like, oh, well the reason why you're scanning this is because you know, you have this line here that just.
Doesn't look right or it is basically flagging because of this parameter. Right? Yeah. But in order for you to understand that, you have to be the person that have built it in the past.
Ashish Rajan: Yeah.
Damien Burks: And it doesn't necessarily mean that you have to be an expert at a, at Java to understand it. You could be an expert at Python [00:33:00] and understand that some of the concepts that you've learned translate to the Java.
Ashish Rajan: Yeah. Yeah.
Damien Burks: So the next thing is get really good at one programming language and you'll know more.
Ashish Rajan: That's the one thing I tell. I agree. Yeah. Yeah.
Damien Burks: Makes sense. And then the tooling in itself, you learn, you learn how, you know false positives work. You learn das SaaS, rasp, all these different concepts. Yep. All these different tooling and frameworks.
Yeah. Yeah. And then from there, that's where you really start to understand you. Then you start, you basically build, I. I'm the type of person where I'll tell you like this is all the theory and the concepts, but like you're really not gonna know how to do this until you go through and you implement it.
You apply what it is that you've learned in theory. Yeah. It's like taking a studying for a certification like you study for the AWS Solutions architect. You can't just study and just like go write the exam. Like you actually have to go do the labs.
Ashish Rajan: Yeah.
Damien Burks: So that's how I've been guiding people. That's how I've been mentoring people, is just like, these are the resources that you should do.
This is the order.
Ashish Rajan: Yeah.
Damien Burks: Cloud should be pretty much, I would [00:34:00] say the second to last thing that you learn once, if you're trying to be a DevSecOps engineer.
Ashish Rajan: Yeah.
Damien Burks: Learn the basics and fundamentals first, and then step into the cloud once you've kind of gotten a good understanding of them. I'm not saying master it.
Because it takes years to master something.
Ashish Rajan: Yeah.
Damien Burks: Yeah. Especially if you're entry level when you're starting.
Ashish Rajan: Yeah. Yeah. So I mean, even without fundamentals, you basically have no clue what you're even talking about. Yeah, yeah. I, I think I always go back to the example of, uh, there's only so much YouTube we can watch about for swimming.
It's only when you get into the water then you realize that how, what really is life swimming. Mm-hmm. Right. I think that, uh, and it's funny, I think, uh, obviously 'cause I've been trying to learn swimming for, in open water and I definitely find that it is very different. I watch a YouTube video, oh yeah, I can do that.
You like go in like, and you just basically shitting yourself and then like, I, I'm gonna drown here. I'm gonna die. Right? So the reality is very different and I think, um. I wonder if it's any different for people who are experienced because you, you said you recently changed your job as well. What was your thinking?
Well, I, I find [00:35:00] that in terms of is it still possible for someone just to focus on one cloud provider and find being like there is this. And I don't know how true is it. Like I obviously hear multiple data points. Some of them actually say, Hey, you need to be like a jack of all trades. You're not just enough about Azure.
Just enough about Google. Just enough about Amazon. But one of them you should be really good at. But you need to know there are other two as well. Because everyone's multi-cloud. Yeah, but I'm like, if you're multi-cloud, in my mind you already enterprise. So you already had a scale of people. So where, where do you stand on that?
I, I guess,
Damien Burks: Ooh I'm probably about to piss a lot of people off when I say this, but, uh, here's, here's where I see it. Multi-cloud to me just means chaos, right? Yeah.
Ashish Rajan: I mean, chaos. You're far. Yeah.
Damien Burks: And when I look at it like this, like. My perspective, when I tell people who ask me, it was just like, Hey, if I were to look at a cloud service provider, like which one would you learn?
I was like, well, I'm biased, so I'm gonna say AWS, obviously. Yeah. But if it were me, it depends on your industry [00:36:00] first. Mm-hmm. Right? Like private sector, you and your company or the type of company that you want to target. Yeah. Um, I have people who say like, you know what? I know that I'm in private sec, uh, public sector, like government, federal, and like I've seen a lot of Azure.
I'm just like, if that's where you want to be, just go learn Azure. Yeah. Don't focus on learning AWS or Google Cloud. Yeah. Just focus on that. Yeah. Don't even try to sit there and say, 'cause like AWS like, we both know AWS comes out where releases features like at least like multiple times a day. Yeah. Yeah.
Ashish Rajan: I mean, wait for reinvent, reinforce. Yeah. In between that as well.
Damien Burks: Yeah. So. If you sit down and you look at that, what the amount of time that you have to take care of yourself, your family, your kids. Yeah. Anything life, right?
Ashish Rajan: Yeah. Life in general.
Damien Burks: How can you focus your time across multiple different call service providers and stay up to date with everything?
Ashish Rajan: Yeah. Yeah.
Damien Burks: I don't see that being, that's, to me, that's not realistic.
Ashish Rajan: No. I
Damien Burks: think that you get good at one. You specialize in that one. Yeah. And you lock into that one. And if you want to explore the other ones, that's fine, but to me, growth is T-shaped. You specialize and then spread after the fact. Yeah.
Yeah. But [00:37:00] you always wanna make sure that you're still specializing in that one because you, you're gonna become a master at that. Yeah. And I think that as we become more mature, I mean like there's every cloud service environment, like they're going to have different services and they're gonna keep coming out with more.
Yeah. And more and more. How are you gonna keep up with the hundreds of AWS services that are coming out and the 25 services that Google Cloud is coming out and all the features?
Ashish Rajan: Yeah. Yeah. That's
Damien Burks: the questions that I have for people who, who believe in it. So I don't believe in it. I'm very much a specialize in one.
Stay in one. Yeah. And then maybe just understand the, the differences between. Some of the others, but make sure you have that one that you're really good at. Yeah. And stay good at it.
Ashish Rajan: Funny enough one of the reasons we started cloud security newsletter was this exact thing because people were talking about how do I keep up?
And, um, so I helped Shilpi, uh, and the team write that newsletter every week, the amount of updates that come in. And you're almost like, this is in a weekly [00:38:00] basis. And you almost have to filter through, is this service something we are using? Do I even care about this service? But because if you do care about the service, you probably should read that as to what the update is.
Exactly. And potentially would be, update would be used by your developers or someone in the organization. So you need to be able to answer the question for, how do I secure this? Oh, looks like, turns out they don't enable CloudWatch on it yet. So great. So yeah. So you almost like looking at that going, oh wait, so there's no logging for this.
Yeah, but people are gonna use it. I definitely find, uh, the more deeper you go into one cloud. I definitely lean more on that as well because there are nuances. Uh, the more time you spent on it, there are nuances to the fact that a new service gets announced. How would you secure it? Sometimes there's no security best practice like the SageMaker, Bedrock are great example.
Yeah, because AI was running so fast. That people decided, Hey let's use, let's do some, uh, security for this. They have logging. Uh, we did an episode with Kyler and uh, Sai on about comparing the [00:39:00] AI services between Amazon and Azure. Mm-hmm. Turns out logging is not great in Bedrock as well as your, on the Azure side.
At this point in time when the, at the time of the recording, Azure was better from a prevention perspective. Interesting. But detection perspective. Mm-hmm. AWS was just basically it. The way we, at least the way I, what I took away was it was a startup project. Let's get this shipped. Yeah. I don't really care.
I just want this to be available for people so I can talk, go and talk about this to customers that, Hey, this is what we have for you start building it. But the moment you start adding the layers for security, there was not many services available and I, I don't know, I don't even know how many, how long it took before your CSPMs or CNAPPs caught onto the idea we should include the service because they're designed for whatever the popular service we'll cover for that. So if you are this obscure company that happens to want to build a, I don't know, satellite or a 5G on your AWS account, right? Sorry, that's not common. So to going back to your programming piece. And you have to build it yourself. [00:40:00] Exactly. Yeah. So, exactly.
I'm with you, man. I think I'm, I'm, I was, as much as I feel, uh, the argument for multi-cloud, yeah, everyone's multi-cloud, but if they are multi-cloud, they most likely have multiple people looking at that thing as well. Otherwise they're crazy.
Damien Burks: But the thing is, is just like when you introduce multicloud, like I still stand on this hill.
You have to have. A expert for each CSPU onboard. Yeah. And what I've, my experience over time I've seen is that some organizations, what they'll do is they'll have, they'll introduce the cloud, but they don't have the people. Yeah. So now you have Azure engineers working on AWS and it's just like how that that, how does that even translate?
Yeah. You get into that and I'm pretty sure there's a lot of companies that are probably had that, and that's where you, you get into, get into bad practices architecturally, because that's when you have to understand the nuances of the CSPs. Yeah. Because the best practices in Azure is not the same in aw WS.
It's
Ashish Rajan: not the best
Damien Burks: architect. It's not the same. It's not, yeah, it's not.
Ashish Rajan: Yeah. Funny. I've got a story there as well. So my, one of my companies that I was CSO [00:41:00] for. Uh, the, the company acquired a few companies, so we were an AWS shop To begin. End-to-end, we are looking at Everyone's an expert. Yeah. Loved it.
Large team. And, uh, we decided, uh, at least when I say we, the company, decided to buy m and a companies across US Europe to expand into those countries. And the companies that were being acquired, one of them was in Google Cloud. One of them was in Azure. These are big companies being acquired.
So it's not that there's only one subscription or one account, it's like multiple accounts. Yeah. But they were small enough that they, they, they only had a security person to look after compliance, not for cloud security.
Damien Burks: Whoa.
Ashish Rajan: Right. So now what that means is it's automatically come on the parent company to take on this responsibility 'cause they have A-C-S-P-M or whatever.
And now you're on this path for how do you convince someone from dropping their knowledge of a Ws where they're spending years to just go, Hey, you would you, do you wanna learn GCP man? Would you, would you be excited about learning GCP? And you're like, uh, but no one [00:42:00] cares about GCP or Azure. Not at least in my friend circle.
Yeah. So there is that dilemma. So, I mean, I'm, I'm with you, man, but where, where are you finding that? Where is this going then, do you find that. Are you recommending people to just stick with one cloud? That t the T shape you mentioned, that is still the way forward?
Damien Burks: Yeah, that's still the way forward.
Um, and I think that the thing is that theoretical aspects of cloud
Ashish Rajan: Yeah.
Damien Burks: Is going to apply in every CSP. Mm-hmm. But it's like learning a program language, right? Like. I would compare AWS to Java, Python and Google Cloud. I, I, yeah. Python is Google Cloud. Yeah. And then, uh, let's do Azure as TypeScript. Yeah.
While the concepts of like parallelism and concurrency, recursion o, object oriented programming may apply, may be the same. Yeah. The implementation very different. How you do it, yeah. Is very different. And sometimes it's opinionated. Mm-hmm.
Ashish Rajan: Mm-hmm. [00:43:00] Yep. Yep. In addition's, a thing, uhhuh. Mm-hmm. Yeah.
Damien Burks: So it's just like, you gotta look at it like that.
And that's why I say it's just like specialize in one CSP. Get really good at it. Find a community. For the CSP and build that network. Because I like my experience, like I've worked in AWS and I've worked in Google Cloud, and it's a very different experience between the two, especially identity access management.
Yeah. Like I have my opinions that I'm not gonna speak about, but I would say that like even documentation wise in troubleshooting how you, how you figure out and debug solutions. Logging is different and the way it's implemented is different. So it's just like, yeah, just specialize in one. Save yourself the pain.
Save yourself the trouble. Specialize in one.
Ashish Rajan: Yeah. But be aware that that's the path you're taking. Exactly. So that's the only jobs you can do after that.
Damien Burks: Exactly.
Ashish Rajan: Yeah. Fair.
Damien Burks: And if you wish to [00:44:00] transition into something else, do understand that there's gonna be a massive time commitment upfront to get to that same skill level?
Yeah, but most importantly, it's just like. You it may be a lot, you may be able to learn a lot faster because you have this experience in one. Some concepts may translate over to the other.
Ashish Rajan: Yeah. Yeah. I was gonna say, um, now that we've covered the transition, specifically talking about people who are in the incident response and forensic team as well.
Mm-hmm. A lot of them may not be from a cloud background. A lot of them come from a traditional data center background. They're mm-hmm. Super awesome at zero days and data centers and all of that. And that's kind of one of the reasons why I wanted to ask you a question about the dev psychos piece and where, how does one kind of walk down that path?
Would it be the same recommendation for people who are in an incident response role today, or the forensic role today for, uh, if cloud has been added as a remit for the security operation team? And you have to respond to those incidents. Would that be the same way for them [00:45:00] to start building detections?
Like how would they go about learning skills to be able to build detections?
Damien Burks: Oh yeah. Um, well, I think most important piece is like, an incident responder is doing things in on-prem, um, most likely is. Hopefully got experience and exposure to containerized environments, right? Yeah.
You may have in highly regulated environments, you may have like Red Hat OpenShift running and stuff like that. Yeah. Which is basically like a bastardized version of Kubernetes. We wanna be honest. Some of those concepts of like private cloud does apply in the cloud. Yeah. But I think that from an incident response standpoint, you have the knowledge and you have the background, the piece, you just have to understand how the cloud services all work together.
Mm. And how they can be architected. Yeah. So, when I had a couple of buddies who were incident responders that wanted to transition into cloud incident response, my main recommendation was. Go get the cloud certifications and learn the theoretical aspects of it. And then some CSPs have, you know, those incident response practices, um, and they have guys to help you [00:46:00] get through and navigate those things.
Yeah. So I'm gonna stay with AWS, AWS solutions Architect associate, then double back, get the the security specialty. Yeah. And then start playing around in your own project. Mm-hmm. And then from there you keep moving forward. Um, and then coding scripting is gonna be very important because you have to be able to build those detections and whatnot.
Yeah. Um, or if you're building like automated responsive capabilities and stuff, if you haven't done it on-prem, you can do it in the cloud and make, make your job a lot easier. Yeah. So you have to have that coding background.
Ashish Rajan: Yeah.
Damien Burks: And then the last thing is preventative. In a lot of cases I've noticed that.
Incident responders can help on the preventative side of the house by working with the DevOps engineers to kind of bake in. Those controls to stop people from doing things.
Ashish Rajan: Yeah.
Damien Burks: And a lot of cases, like the misconfigurations that happen in the [00:47:00] cloud open up the can of worms to begin with.
So it's just like if you got that taken care of on the, on the front end, then you can just focus more on the automated portion, which is a automating some of the p the key pieces Yeah. Of your job. Yeah. That's how I would recommend it to start. Yeah, because you have the knowledge already.
Ashish Rajan: Yeah.
Damien Burks: Yeah, yeah.
Ashish Rajan: Yeah. And I'm glad you mentioned it 'cause I allowed the, at least the, one of the takeaways for me from the episode is that you had a clear advice for people who are starting their career fresh to start with fundamentals. You didn't mention certification there, which is awesome. Also for experience, people who are in incident response, that's, then it makes sense for you to go for a certification.
Yeah. Although it's not marketed like that. None of the cloud providers marketed as like, Hey, you should have some experience. I think they say that for security, and they say that for solution architect, I think, but for associate, they're like, yeah, well take anyone you want. There's the, I'm like, which is fair, but it kind of gives people false assumption that you get a job from it.
Damien Burks: Yes. Yeah. You do not.
Ashish Rajan: Yeah, you do not. You
Damien Burks: do not.
Ashish Rajan: Yeah. But those are all the technical questions I had. I've got three fun questions for you as well.
Damien Burks: Okay, cool.
Ashish Rajan: Uh, [00:48:00] first one being, what do you spend most time on when you're not trying to solve incident response problems of the world?
Damien Burks: I honestly spend a lot of my time, um, of course spending time with my cats.
Yeah. And then playing video games. That's literally me. Ooh. Yeah. Oh, what, what
Ashish Rajan: gives you on? So right
Damien Burks: now, I literally just brought, uh, the Demon Slayer video game, the Hin Kami Car Chronicle Stew.
Ashish Rajan: Yeah.
Damien Burks: But I've been wasting my life and Persona three Reloaded. And if you guys are any, if you have any PC gamers out there, like, and you, and you have any persona fans that watch your channel, like.
Persona is the game that it, it is like Boulder's gate where you can spend hundreds of hours in and you just enjoy it because it's so immersive. Really? Oh my God. And the soundtrack top tier, because it's like jazz fusion and it's so good. Oh, really? Yes, yes. Oh, it's so good. So it's like you're in a bar while you like Yeah, and it's literal, like you're playing a game and then you have like the soundtrack just like keeping you going, so Yeah.
Ashish Rajan: Yeah. Awesome. That's great. And the second question, what is something that you are proud of that is not on your social media?
Damien Burks: Oh my goodness.
Ashish Rajan: [00:49:00] Honestly,
I'm proud of
Damien Burks: the results of my choices have allowed me to be able to live a freeing lifestyle. Mm-hmm. I would say, i'm very happy with the way that my life has turned out considering, you know, like me coming from a, you know, a lower income household and moving up. Yeah. I'm proud of the journey and I think that I'm proud of the friends that I have, the connections that I've made, but also just being able to just live life.
Openly. So I'm, that's what I'm most proud of. That's something that I don't really, I don't post much. Yeah. About how proud I am and happy I am in my life, because it's just, I want to continue to live it.
Ashish Rajan: Yeah. Awesome, man. Now thank you for sharing that. Third question. What's your favorite cuisine or restaurant you can share with us?
Damien Burks: Ooh, that's tough, man. Favorite cuisine. I have to go with gumbo.
Ashish Rajan: Oh, really?
Damien Burks: I'm a, I'm a raised occasion. Oh. [00:50:00] Um, I'm new Orleans raised. Uh, so gumbo is always gonna be my favorite.
Ashish Rajan: Fair.
Damien Burks: Uh, do you make
Ashish Rajan: gumbo at home as well? I do. I do. I don't wanna say very hard to make gumbos. Is it? It can be, yeah.
Yeah, yeah. It can. Quite a intense process.
Damien Burks: Yeah, you have to stand over the stove. You gotta stir the room. Or
Ashish Rajan: school, then it's like, there's, there's no insta port helping that, that like, there's no, there's nothing incidently happening there yet.
Damien Burks: Yeah. Yeah. And um, I would say like, aside from, you know, gumbo like related restaurants, 'cause I live in Texas.
Oh yeah. There's not that many. My favorite restaurant in Texas right now. Is a ramen shop. It's called Hanabi Ramen. Okay. And there's like, it's like a little chain in the DFW Metroplex. Right. But it's really good if you're like a great Ramen person. And there's also Makoto Ramen, which is in South Lake.
Yeah.
Ashish Rajan: Okay.
Damien Burks: You gotta go there as well if you're big into ramen, because I love ramen too.
Ashish Rajan: Alright. I mean, I think the next time I come over to Dallas side I'm definitely gonna check that out. And I'll hit you. I'll hit you up anyways. Yes. But like, awesome. Where can people find more about the work you're doing and how can they connect with you?
Damien Burks: [00:51:00] Absolutely. Uh, you guys can connect with me on LinkedIn, Damien Burkes follow me on YouTube at Damien j Burkes. And then also if you're interested in learning about how to get into DevSecOps and soon to be cloud security development dev sec blueprint.com. Yeah, you can go there and it basically just has the entire layout.
We also built like guides for building pipelines in AWS Google Cloud. Um, we also have one for GitHub using GitHub action. So like there's a lot of DevSecOps examples out there for you guys and , the Dev Stack Blueprint has everything. So yeah. So just go straight to the dev stack blueprint.
Ashish Rajan: Yeah. Fair. No, I'll, I'll put that in. But dude, thanks so much on the show. Thank you so much for having me. No, dude. And thank you everyone for tuning in as well. Thanks, Tim. Thank you for listening or watching this episode of Cloud Security Podcast. This was brought to you by. Tech riot.io. If you are enjoying episodes on cloud security, you can find more episodes like these on Cloud Security podcast tv, our website, or on social media platforms like YouTube, LinkedIn, and Apple, Spotify, in case you are interested [00:52:00] in learning about AI security as well.
To check out a sister podcast called AI Security Podcast, which is available on YouTube, LinkedIn, Spotify, apple as well, where we talk. To other CISOs and practitioners about what's the latest in the world of AI security. Finally, if you're after a newsletter, it just gives you top news and insight from all the experts we talk to at Cloud Security Podcast.
You can check that out on cloud security newsletter.com. I'll see you in the next episode, please.