William Bengtson: [00:00:00] I think we're getting to a place where you can jump in day one and start being more successful than starting from scratch. I think we think the most awesome thing about the cloud is the API. The most dangerous thing about the cloud is the API. Not just from I don't know what I'm doing, but if you think about a skilled threat actor stumbles upon some privileged credentials.

They can do a lot of damage in a short amount of time. Yeah.

Ashish Rajan: Welcome to another episode of Cloud Security Podcast. We are talking to Will today, who is a return guest. Thanks for coming in for the show, man.

William Bengtson: Thanks for having me back.

Ashish Rajan: Oh, well,

William Bengtson: I'm super excited. It took a while for this to happen, but I'm so glad this happened as well.

No, this is great. I'm glad timing worked out.

Ashish Rajan: Yeah, I'm so happy as well. For people who may not have heard your first episode, could you give us a brief intro about yourself, your professional journey? Where you are these days,

William Bengtson: Will Bengtson. Today, I'm the vice president of security operations. Our engineering and operations.

Okay. And yeah, I started my journey while back now. Long ago started as a software person. Found my way to security wanting to break things, got [00:01:00] really deep into cloud. And that's where I think we originally met was when I was doing a lot of cloud security work and Netflix.

And during that time is always figuring out, I was really focused on detection and I really found a love for it. And that's what eventually led me to HashiCorp started at the detection engineering side building on that. And this point I've touched a lot of industries.

I love cloud and I feel like I just I don't know I love the blue team side of security.

Ashish Rajan: Yeah.

William Bengtson: More so than the old school penetration testing, red team that I used to do. Yeah. Because I just find it so much more. And that's what's led me to really, being in my role today at HashiCorp owning security engineering.

Ashish Rajan: Awesome. And you had some stint in Capital One briefly as well.

William Bengtson: Yeah, brief stint at Capital One, which was awesome. Great experience. Got me back to my home state of Texas. I love and thankful for. Met a lot of great people, worked with Houston Hopkins. Oh, nice. And really just, yeah, it was a great time.

Yeah. Very brief stint, but don't regret it one bit.

Ashish Rajan: Cool. And I'm so glad because you have some, the offensive side and you might've moved on to the blue team side, at least top of [00:02:00] mind for us here in cloud security podcast has been incident response at least for 2024 and I believe it will continue in 2025 as well.

And you've been in the space for a while as well. What was incident response in the beginning when you started in the cloud space? And what is it now? How would you describe that to people?

William Bengtson: Yeah, I think in the beginning, people didn't really know, right? Yeah, what they were moving into the cloud, expecting to have the exact same thing that they had with, on prem or data center, and realizing rather quickly that, crap, where am I, where my network logs, right?

NSM was not a thing. And I think that was the biggest surprise to a lot of folks. Misconfigurations, not secure by default, those were all the problems that people were running into.

Ashish Rajan: Yeah.

William Bengtson: And from an incident response and detection standpoint. Having to adapt really fast right and it's very similar to bring an application from on prem into the cloud Lift and shift can work, but it's not the recommended approach, right?

I think it's very similar when you think about threat detection response. You can lift and shift processes

Ashish Rajan: Yeah, [00:03:00]

William Bengtson: but you've got to learn and you got to adapt and you've got to start figuring out the cloud native or hybrid solution

Ashish Rajan: Yeah

William Bengtson: for that and that's where I think like early on we were stumbling, trying to figure it out, trying to understand what do these logs mean, what is actually logged or not, why when I click this button did these other eight calls get made, right?

And I think we're even still trying to solve some of those problems. Oh, yeah. Yeah. But, I think early on that's where it was, if you think about way back in the day, first AWS.

Ashish Rajan: Yep.

William Bengtson: Everyone was using root credentials, right? And if you wanted to deploy an application and have the credentials be able to call APIs, you're putting your root creds on every box, it's the same credential everywhere.

And then finally IAM service comes, STS. Yep. And same thing, right? This has evolved and now it operates this way. Now we need to change our thinking. Yeah. And how we do this detection where we used to do it, right?

Ashish Rajan: Yeah. I love the eight service example as well because traditionally incident response was there's either an application log or a system log you're looking at, you're never looking at events, [00:04:00] right?

Whereas I still remember the first time I came out. What do you mean? So I think someone said, Oh, cloud is an event based architecture. What does that mean?

William Bengtson: Yep.

Ashish Rajan: Yeah, and I'm like, I'm trying to figure, but then you look at your auditing service, like CloudTrail and everything you, oh, so every click that I do is an event triggering, and then the whole concept was like, oh wow, this is like a event that I'm tracking. I'm not tracking logs anymore. I'm tracking event. And that's where the detection response, for me, that was the most fascinating part. Wait, so it's not just about me looking through logs for making a query of some sort in my SIEM.

It's more about now what's an event being triggered? Can I pick the event up as it happens? So it never even makes to the SIEM, right? And then is that a good thing? Or is it a bad thing? If I put that in my cloud service provider, how do I validate it's still running? Yeah. And I'm like, there's so many questions unanswered.

And I'm glad you put the eight service example as well for one click, there's eight things that happening, figuring out what have you,

William Bengtson: is that normal? Especially if you think about to your point, is it still logging? Yeah, [00:05:00] it's what is normal? Yeah should I be receiving more volume of traffic or of logs today?

That's right. Yesterday? Yeah, it's just, it's fun. And people, I think, similarly to everything else, folks are trying to figure out how to abuse the system.

Ashish Rajan: Yeah.

William Bengtson: Or, abuse the gap in thought, right? Yeah. It's oh, I've enabled CloudTrail. Didn't realize that you could actually filter CloudTrail as well. and someone went in here and just filtered out all the logs. , right? Yeah. From a CSPM perspective, I still see that CloudTrail is enabled, but is it actually logging? Yeah. What is it configured to log anymore, right?

Ashish Rajan: Yeah. I'm still getting logs. I guess that's everything, right?

Like I don't, I'm not missing my data events. We can go into detail of this as well. So today do you feel there's a lot more maturity in incident response? I guess maybe to set the scene, what we were saying, the whole concept of event based architecture and doing threat detection event based was like a whole another, I guess it wasn't even like a thing.

People did not even realize that's what was going on to transition from on premise to cloud. Today, when there's a lot more of, is there a lot more awareness on incident response in cloud to [00:06:00] be different?

William Bengtson: I think we're getting more and more. Okay. And that's why Rich and I set out on this journey long ago, right?

Yeah. To try to bring that awareness, get more people hands on training, really try to level up and bring the same processes that we use on on prem data center into the cloud and just learn how to use the tools to our advantage. I think when Rich teaches the class. He always relates incident response process with his time as a paramedic.

Oh yeah. Crisis management. It's all the same thing that we're doing. Rapid response, I think, was it as well? Yeah. Yeah, it's just the target is different.

Ashish Rajan: Yeah. You want to get to the problem as quickly as possible and find the quickest solution to stop the bleeding or whatever I think you use the word he uses and I love the analogy I think because for context for people so that's Rich Mogul.

He's been on the episode before with Chris Farris. So definitely check out the episode as well so to your point then now that there is a bit more awareness, is there a lot more I guess tooling and by tooling native services that are different because I mean, we're talking about [00:07:00] a time before when there was no Security Hub, no GuardDuty, none of that.

We're trying to figure out what that world is. For context, for people who are thinking about 2025, I want to build an incident response practice for cloud. We've always noticed that it's not something people talk about a lot because there's a knowledge gap and we'll cover that as well. In terms of someone building incident response capability in their organization today, are there native options available or are we looking down the path of building something custom in a SIEM?

William Bengtson: I think it depends on like your model, right? Are you all in on AWS? Are you Azure and AWS, Azure and GCP? What is it? So I'd say if you're in AWS, that's where GuardDuty has come from, Security Hub. And that's where they're really trying to get you a place to start such that you can get the detections.

You can surface them in a single place. I think AWS announced incident response service this week.

Ashish Rajan: That's right, yeah.

William Bengtson: And so now you can do case management and pull from experts if you don't have that expertise, right? Yeah. I think we're getting to a place where you can jump in day one and start being more successful than starting from scratch, right?

I think if we [00:08:00] think five years ago, ten years ago, you've got the base services and you're just trying to piece things together. Yeah. You've got more and more companies offering cloud native solutions. And you're not having to try to adapt, right? How do I use Splunk for this? How do I use Sumo for this, right?

How do I scale my service or the SIEM, right? And then most importantly, it's when you're just getting started, what do I even, where do I begin? What detections do I start with? And that's where leaning on some of the native solutions or some of the open source software and get you that zero to 50.

Yeah, maybe not zero to 100 kind of deal, but it really transport you and get you started off on the right step.

Ashish Rajan: For someone who's building the incident response capability to today, there might be native capabilities. In terms of what an example that really differentiates and doesn't have to be a complicated example, to paint the picture for how different detection or what an incident looks like in cloud versus on premise is an example that is top of mind for you where people get that [00:09:00] clear picture.

Oh, on premise, this used to be normal, but that maybe it's not normal in cloud. The new normal in cloud is something else.

William Bengtson: Yeah, I always like to use the example of server side request forgery, right? I'm sure folks from AWS and other cloud providers are like, Ah, not again. But I think it's a perfect example, right?

If you think about the vulnerability as what it is, it's tricking a server to make a request on your behalf. If you think about data centers, old school, on prem, getting an ability into the network the real attack was like discovery of internal resources, potentially what ports are open, maybe you had an API that didn't have authentication.

So maybe they could leverage that.

Ashish Rajan: Yeah.

William Bengtson: In the cloud, it became such a more dangerous vulnerability. Because all of a sudden you got to pivot to the metadata service, which was unauthenticated originally, unprotected, right? And you could get credentials that were much more damaging than potentially the network discovery that you could have done in a traditional [00:10:00] SSRF in a data center, right?

Yeah. So I think that's the biggest difference is, some of these older vulnerabilities that might have been seen maybe mediums or something on the severity list all of a sudden high criticals now

Ashish Rajan: Yeah,

William Bengtson: and I think the biggest change in vulnerability and detection in the cloud compared to on prem.

Ashish Rajan: Yeah,

William Bengtson: it's how fast you have to move how fast you have to discover, right? I've said in previous talks that I've given the most awesome thing about the cloud is the API The most dangerous thing about the cloud is the API, not just from I don't know what I'm doing, but if you think about a skilled threat actor stumbles upon some privileged credentials, they can do a lot of damage in a short amount of time. And I think from what we're used to when it comes to detection on prem, you might be looking for things every hour. Yeah.

Ashish Rajan: Every 24 hours, right?

William Bengtson: Cloud is forcing us to really decrease the mean time to detection,

Ashish Rajan: and

William Bengtson: then [00:11:00] also mean time to response.

Ashish Rajan: Yeah.

William Bengtson: Because it's just, you've got to move, right? Yeah. Most likely, and I think where we're potentially maturing in incident response is there are a lot more breaches These days in the cloud than we've ever had and it's partly because more people are operating in the cloud than ever And maybe the SEC guidelines forcing people to disclose as well.

Yeah is raising it to everyone's attention.

Ashish Rajan: Yeah,

William Bengtson: Mostly it's by the time you've detected it. It's too late. You're switching into response mode. You're investigating trying to figure out what happened. How did it happen? What did they take? And might not have been a thing in the past, but I think it's also really awesome from a cloud perspective.

Similarly. You can do things like be very dynamic, move much faster, rotate your infrastructure to make it much harder on the traditional threat actors that are used to low and slow kind of hide.

They're going to have to move faster these days.

Ashish Rajan: If someone's building an incident response capability today in the cloud space, that is a good example, the [00:12:00] whole mean time to direction and response being faster.

So if I'm thinking about setting a program for incident response, and you've done one as you came into HashiCorp. What were some of the initial things people can look at and probably some low hanging fruits or what are critical things that I mean, tactical things people can go for in the beginning to get some wins, because you have to show to the to everyone in the business that it's not like a lost cause for lack of a better word.

William Bengtson: At the basis, it's getting your processes together, right? Actually defining what does it mean to declare an incident? What are your severities? Who are the stakeholders you should involve? What's the process for communication? Are you offering a service to customers that you're going to have to notify them?

I think first and foremost, until you get that solidified, anything with detection is, what do you do when you detect it, right?

Ashish Rajan: Yeah, I don't even know if it's a high versus a low. Because I guess worthwhile calling out, even though you may already have an on premise version of what that is, Can I use that in cloud?

William Bengtson: I think you can, right? Especially if you're moving your [00:13:00] business from on prem into cloud. You've already defined, potentially, how many customers have to be impacted for it to be a medium, or a high, or a critical. Is it one? Is it a hundred? A thousand? Is it any time customer data is inadvertently accessed?

Those kind of definitions, likely, if you've been running on prem, you can bring that right into the cloud, right? And then you can just transition, if you're building the detection program completely from scratch, not just from scratch in the cloud, then it's, how do I document? What's the timeline? Do I have a template, right?

Yeah. What are the roles in the process? And those are, I think, key to the beginning, and then you can start building out, okay, what do we actually want to detect? And that's, I think, a lot of the problems is, people that have started out, they don't know what to look at. And that's where, lean on vendors, lean on knowledge from expertise, watch your podcast, because people are talking about all the things that they care about, and that can give you some ideas.

Ashish Rajan: Yeah.

William Bengtson: You know, threat detection, I think one of the unfortunate things is, [00:14:00] they want threat detection engineers to be able to write detections for everything. And unfortunately, it's a job where you have to be very collaborative, right?

You need to go speak to your cloud security team and ask them, What do you worry about?

They should be the ones that actually know more about the cloud and misconfigurations, or does this actually mean a bad thing or a good thing? Lean on your corporate security team as far as like third party SaaS. How should this normally be used right? And if you just lean on your detection engineering team to build out all the detections for the entire surface, you're just never gonna get through that backlog.

So you really have to build out that program. Understand roles and responsibilities across the board.

Ashish Rajan: Yep

William Bengtson: And you'll push that out. And I think the same thing goes with response. Once you get a detection, is it the threat detection team or the response team that's always doing it? That's another level, right?

Do you want to build a SOC?

Are there multiple levels of the sOC?

Or do you want to go SOC less like we did at Netflix, right? Oh, Netflix is a SOC. They didn't have a SOC. When I was there, at least. I don't know how it is today, Alex, [00:15:00] my strutting team. We're really focused on, let's be SOCless let's write a detection, and when there's a result, have some automated response, right?

So security monkey back in the day, if you remember the tool. Oh yeah, that's right, yeah. Patrick Kelly had written some great things that when an S3 bucket was opened publicly. Yeah, it just automatically went and removed the policy that made a public. Oh, that was one of the automated remediations, right?

We really wanted to be able to once again move fast and not necessarily raise it to the on call wait for the other engineer to respond about it. But unfortunately sometimes that's what you have to do, right?, so like when I'm sure we'll get into it as well. But when we run incidents. We're really command.

Yeah, pulling in the right teams.

Ashish Rajan: Yeah

William Bengtson: until it like, oh, we need to actually get into the log. But once again, like it's your application, the logs better than me. Yeah, that's right. Let me Pair with you and go alongside and tell you the kind of things to look for it's infeasible to think that everybody on your response side would be able to understand every log across your entire enterprise.

Ashish Rajan: Have [00:16:00] you figured out what's a good place to start? Because to your point, maybe one thing people should take away is that they probably, you cannot boil the ocean with the threat detection. You have to start somewhere. Have you found in the work that you were doing, what are some of the metrics you found are easier to create detection on, for lack of a better word, which is, because we haven't even spoken about the skill set required for this, because that's a whole other gamut as well.

Let's just assume for the moment they know a bit of cloud, they've been asked to build detection for it. What do you think are easier tactical things people can start with so they feel, oh, they get a feel for it before they suddenly just land in this world of 100, 000 alerts and everything.

William Bengtson: I was just about to say the first thing you don't do is turn on the hose, come up with that plan.

But if you're just starting in detection in the cloud, some of the basic things I think are, is the root credential being used? Yeah. Things are coming that, we'll eventually get away from that, right? Where are our EC2 instance credentials being used?

Ashish Rajan: Yeah. [00:17:00] Do we still have IMDSv1 being used anywhere?

Yeah. To your point, SSRF example, are we exploited by it or potentially?

William Bengtson: Yeah, exactly. And even in CloudTrail today, you can tell whether their credential came from in IMDSv1. Yeah, wow. That's a great first step, right? And that leads to the proactiveness or of preventing.

Ashish Rajan: Yeah.

William Bengtson: Cause you're going to get tired of detecting and responding. And it's Hey, how do we change the patterns that we have? I think it's just the handful of things that people have yelled and screamed about. Those are a great place to start.

Ashish Rajan: Like these days, no one just has one AWS account.

And people have hundreds something, thousands of AWS account. As we're talking about the tactical things we can approach, we spoke about root account, EC2 instances, IMDSv1. What does scaling look like across multiple accounts in terms of detection? Start with one account, multiply that across multiple accounts or start at org.

Is there some thought around that as well? More native or should you just keep everything in a GitHub repository yourself?

William Bengtson: From a log perspective, with CloudTrail, it's turn it on for the organization. Yeah. And you're scaling automatically [00:18:00] there, right? If you're doing it account by account, then, yeah, as you grow your accounts, go turn it on more.

Make sure you centralize it. That used to be a thing before the organizational CloudTrail feature existed. And so anything that you can do at the org level, I'm always recommending at turn that on. Yeah You'd be surprised how many companies start with a single account though, they're running Dev in one VPC and product another Oh, wow, I think it's when you get to SOC2 from a compliance perspective that they start going Oh, we actually have to start separating these things out But I think a lot of people tell some compelling stories of no we can actually maintain access To only the prod assets versus the dev. Okay.

I've seen people do it, or at least try to do it. Yeah. Yeah. Wow. So I don't recommend it. Yeah. Yeah. I was gonna say, but yeah, I think like what you're detecting in one, as you scale out, the types of detections that you can build differ. If you think about prod and dev in a single account versus prod and dev in two different accounts,

Ashish Rajan: yeah.

William Bengtson: You can start doing things by. Is this alert coming from Dev or Prod? If it's from Prod, maybe it's something critical. If it's from Dev, maybe we can [00:19:00] wait till tomorrow, right? And so that's a trick from a once again, don't turn the fire hose on, but I think preventing burnout is super important when starting down this journey of detection and response.

And that's the thing I worry about with, just flipping Guard Duty on.

All of a sudden you might get a ton of noise, right? And Palantir did some really great public, blogging about how they approach things back in the day, which we adopted at Netflix. I brought that over to HashiCorp.

Yeah. An alerting and detection strategy of what are the things we want to alert on? What do we do when we learn on them? What logs told us about it? What is the false positive? That could happen? Is there a gap? Or do I have full coverage with this one detection? And most importantly, what do I do when it fires, right?

What is that runbook? So is it root access being used? Is it an AMI being shared publicly or shared outside of your account? How are we sharing resources in the cloud? One of the things that we like to think about when we do detections is, you've got dev, prod, int, test, all the different [00:20:00] environments.

The last thing you want is a dev credential or dev access leading to production access. And so if you see an assume role and you're switching across account, If the originating ARN was a dev account, that's probably not something you want to see from a pattern.

It might not necessarily mean maliciousness, but it's something you should detect just because it could lead to something long term.

And so I think that's the scaling piece too, is it changes your mindset of what are the kind of things that I can detect that can talk about patterns. But also potentially could be malicious if someone's poking around and you might think, Oh, this dev environment's not that bad. It might be the thing that we're not going to page you and wake you up till the morning.

Ashish Rajan: Yeah.

William Bengtson: But if that leads to a pivot into production maybe that's the detection that pages.

Ashish Rajan: And would you say I guess that's the scaling in terms of maturity as well. As you mature your practice to a point, you may start with the easy detections and perhaps you may look at the defaults that you're getting from GuardDuty or you may purchase a third party [00:21:00] product or whatever.

It gets to a point where people may start finding that actually that's not my entire list . That's not everything that I want to find, because I'll still get incidents which are being reported by other people. Is there a way for me to measure, hey, what could maturity look like at, I don't know, if I were to give five levels or whatever, what's level one in your mind that is an easy win, people can get to it and go, okay, at least you've covered your level 100, right? Let's talk about level 200 of this have you got some thoughts on that as well in terms of maturity?

William Bengtson: It's not something I thought about a ton, but I know folks on my team have,

Ashish Rajan: yeah,

William Bengtson: and when I think about like level 100, the basics, it's, some of the stuff that we've mentioned, are we collecting the logs?

What logs are we collecting? Because I think that leads to maturity as well. And as to your point of scaling, as your teams and the cloud is maturing and cloud security is maturing.

Ashish Rajan: Yeah.

William Bengtson: From a detection standpoint, you have to mature alongside.

Ashish Rajan: Yeah.

William Bengtson: And so are you collecting the right logs? Do you have detections being written?

Are they working? And then, do you have playbooks being written by with something [00:22:00] that, when they actually fire? And so I think a base level would maybe be, we covered the really bad root credential usage. We have a playbook that exists for if that usage happens. And if it were to be a bad thing, like an incident, and not a false positive or something expected, we have a process in place for what we do after.

That process could just be pick up the phone and call, FireEye or something. Yeah, fair. Or Mandiant. Yeah. And then evolve from there. Level 200 could be like, okay we've got the basics covered. Now we want to be sharing AMIs outside of our accounts. Not just public.

So the public one's easy. Sharing them outside the accounts. Now you need to know context of all your accounts. And so from a maturity on the cloud side, do we actually have a full visibility? Yeah. Do we have a metadata system ahead? That tells us these are all the accounts.

Ashish Rajan: Yeah.

William Bengtson: Are you sure? It's one go, just use their email and spin up an AWS account and all of a sudden hosting thing.

Is there a spreadsheet floating around with all the account names? Even if there is, do we have visibility into it and is that being fed into [00:23:00] the detection or with an alert is the analyst looking at that to go. Yep. This is fine.

Ashish Rajan: Yeah

William Bengtson: And I think as you build more detections and as you grow and mature and as your applications move faster and faster in the cloud That's what's going to continue to force the maturity and detection response. Because if you think about anytime an AMI is shared, right that's not our shared not publicly but to another account.

Ashish Rajan: Yeah

William Bengtson: Bar that alert and put it in the queue if you get a maturity and you start building AMI sharing them across account from you've through this dev int prod perspective.

Ashish Rajan: Yeah,

William Bengtson: those alerts are gonna grow. Yeah, and so as analysts gonna go check everyone and then you're gonna end up in a situation where it's yeah Let me just clear up my backlog.

Yeah, and then you actually miss that signal.

Ashish Rajan: Yeah

William Bengtson: That's how I think about it is, log coverage, types of detection, are we covering the basics, are we responding well to the ones that we have, or do we have the documentation in place, and then from there you can start moving into the [00:24:00] more, advanced detection techniques, right on host monitoring, very similar to the data center, right?

Yeah. I want to detect. Backdoors might look a little differently in the cloud. Most likely, you know a lot of the like host based monitoring stays the same I think the biggest difference is potentially instance size, how much how much memory you can consume, performance do you have coverage, right?

Before it was, I need to deploy my application, you give it to the person that goes and deploys the application, so you can check all the boxes. Now any developer can deploy applications, and you really have to mature everything alongside as you mature in detection.

Ashish Rajan: I love the analogy of the level 100, 200, 300 as well.

In the beginning, is it too early to be doing threat hunting? Because a lot of people get excited about threat hunting, and perhaps some of the CSPMs and GuardDuty rules are to be blamed for it because you get a lot of defaults. Once you clear that your point select all and suppress, I guess I've got to clean everything.

They feel that they're ready for threat hunting in the [00:25:00] cloud space. Have you guys had to, or have you had some experience working on the threat hunting side? Is it too early to think apart from day one? Or should they build that practice as they grow that capability?

William Bengtson: I would say too early to have a threat hunting team.

Yeah, okay, yeah. Not too early to be like flexing that muscle, right?

If you think about when you detect something that actually turns out to be malicious, what do you go do? You have to go hunt. And ensure in the investigation, you need to go make sure that what all did they do, right? And so if you're not flexing that muscle from time to time, when it comes time to searching through logs to understand what happened, maybe it takes you too long.

Maybe the threat actor is still inside. And if you had flexed that muscle, you could have eradicated it. Or, kicked them outta the environment faster. Yeah. Or when you see other companies being breached, in their publishing IOCs, use those IOCs and just double check. Even if you don't think, and you're the most confident engineer or security person, you'd be a fool to not just go run that IP across your logs.

Yeah. [00:26:00]

Ashish Rajan: And see and,

William Bengtson: and cross your fingers, right? Yeah. And so that's, flexing that muscle, right? Yeah. And then I think it's up. To you and how you want to prioritize time and skillset as you mentioned earlier. Yeah. But also I think there's an element of hunting when you're building out the detection, especially if it's a brand new log.

Understanding the log and what means what is the hunting.

Ashish Rajan: Or even new service as well. I'm sure there'll be plenty of services being announced at re:Invent and other places as well. Yep. Even if it new service, you're that everything is new about it.

William Bengtson: Yeah, we talked about a pre show is understanding the log before you can actually build a detection on it, right?

And that's where, a lot of teams lean on vendors. Yeah, fair. You go be the expert. You go understand how this works. Or in a lot of cases, GuardDuty, AWS, they're the experts, or should be, right?

Ashish Rajan: Yeah.

William Bengtson: And yeah, I think that all points back to an element of threat hunting.

Ashish Rajan: Yeah.

William Bengtson: Versus just looking specifically, your sole job is just to go troll through logs and figure out what, if something looks bad, right? Because you're going to miss something, and that's where you've got to figure out, understand [00:27:00] the logs, what is normal? Yeah. What is good, and what are the things that are bad, right?

And I think The way I typically like to approach it is, let me look at the application. Here's how a user normally uses it. How would I abuse that? And that's what I loved about and then I think why I've stayed on the blue team side so long is. Using that like red team mentality.

Ashish Rajan: Yeah

William Bengtson: on the detection can be, makes you very dangerous You're thinking how would I move if I were to break in yeah, if I was gonna break in the studio today, how would I have come and done that?

Yeah, and then that leads you to know where should I start looking to see? Is there a log source? There's a log source. Is there an is there a log or an audit event in that source that tells me that I opened the front door.

Ashish Rajan: Yeah,

William Bengtson: right Or I typed the alarm code wrong the first time right?

Ashish Rajan: I guess would you say I love the threat hunting piece.

These days another thing that's common is multi cloud as well. There's hybrid cloud as well And I'm sure there's multi hybrid, whatever the next acronym would be. Yeah. Do these things scale across other [00:28:00] cloud providers? Because to your point, the larger the organization, the likelihood you're in multiple clouds these days.

It's it's almost, yeah, it's almost unheard that you are a large enterprise and don't have multi cloud. You probably have some of the clouds that people don't even hear about in the background somewhere as well. So do these practices of people building capabilities and some of the things you called out about starting with the process and everything, does that still apply across from that?

Doesn't matter which new cloud comes in tomorrow?

William Bengtson: I think it does and it doesn't, right? And I think ideally there's similar log sources in the other cloud providers that are popping up. Ideally the content within the log source is the same, but I feel like that's the biggest discrepancy, right?

Is, is an IP logged or not?

Ashish Rajan: Yeah.

William Bengtson: Is the identity, can I actually trace it well? Do I know how to trace the assume role to this, to that, right?

Ashish Rajan: Yeah.

William Bengtson: And I think that ties back to the threat hunting as well as like when you have to learn how these logs work and like you were saying, it's an event thing now, not just a log thing.

You got to hunt through the logs and see, can I do this thing if I actually wanted. But when you think about. [00:29:00] Multicloud or hybrid, once again, log sources may be different. The SLAs around them might be different. And then content of said log might be different, right?

I think, when I was presenting at Black Hat in 2018, one of the things I really wanted to do was understand what all was logged in CloudTrail. There's no one source that tells you. And so I wrote a tool called Trailblazer. Oh, yeah. Yeah. I tried to, using Python, execute every API call.

Yeah. To see what was actually logged. I learned a lot about what was logged from that standpoint, the list that I knew about grew much larger, but I also found out a lot of things, some services don't log things unless you made a valid request. And so it still doesn't get you everything.

Ashish Rajan: Yeah.

William Bengtson: It was a question of I don't know if I can detect this or not. And that's where someone goes and tries it. You go look at the logs and say, can I even see what this is? And that's how it works. And so when you go from AWS to Azure to GCP, It's the same thing.

Turn on all the logs you can that you want. Go try the things that you think you want to [00:30:00] detect. See if you can detect them,

Ashish Rajan: right? Yeah,

William Bengtson: yeah. There were early on log sources that don't have IPs, right? I think they now do. I'm not going to mention what providers, right?

Ashish Rajan: Yeah. I

William Bengtson: think when talking about.

Driving down time to detection. There's a lot of services out there that don't give you login events for up to an hour later.

Ashish Rajan: Yeah.

William Bengtson: If you're tracking down a stolen credential, like once again, an hour might be too late.

Ashish Rajan: Too late, yeah. And I think it's a good segway into some of the BlackHat Training that you and Rich run as well.

I think definitely, I'll put a link for it as well because I think it's worthwhile calling about. You guys have pivoted slightly in terms of what it used to be and what it is now. To kind of set the scene for people a lot of the organization these days who have been in the cloud for some time building cloud security capabilities.

Initially, cloud security engineers were looking at the logs and everything. And obviously now we're talking about SOC people looking at the logs, which is the next transition that's happening. Where even in the training that we do and you guys are doing, we're both seeing this [00:31:00] that it's happening where the cloud logs are being sent more to the SOC people.

What was the training before and where are you taking the training now? Maybe we'll just go there. Where are you guys taking the training now?

William Bengtson: Yeah, real quick, the training before was really trying to get that hands-on experience for folks that have never done it in the cloud, right? Yeah.

Teaching them what are the sources, what kind of attacks exist, and what do they actually look like, right? So what we found, both through that, as well as experience at HashiCorp and talking to other security professionals, is you might have folks that come with some detection experience.

They're used to doing it in whatever platform they had before. Yeah. Be it Splunk, be it Sumo, be it Elastic, be it just native Athena. Yeah. But when it goes beyond in scaling and detecting, you want them to go build something or transform a log. What I'm finding is not everyone actually has the hands on experience to build in the cloud.

Right, and so we're pivoting it slightly or trying to, we'll see if it gets accepted, right? is, let's teach people what does a log pipeline and detection pipeline look like.

Ashish Rajan: [00:32:00] Yeah.

William Bengtson: So still actually getting into the incident response and detection perspective. Let's walk them through setting it up. So to your point earlier is like, where do you start?

Yeah. That's where we're starting as well is, you're starting with nothing.

Ashish Rajan: Yeah.

William Bengtson: Let's turn on CloudTrail.

Ashish Rajan: Yeah.

William Bengtson: Let's centralize it to an S3 bucket.

Ashish Rajan: Yep.

William Bengtson: Let's look at that. Let's look at what a simple detection would look like. How long did it take to detect? Okay, now let's hook it up to CloudWatch events and our event bridge, and let's see, can we detect it faster?

And then, now what do we do once we detect it? Is there some automation that we can do to like auto close down the S3 bucket as an example? Do I just run a runbook? How do we do the analysis? And so we're really going back to in our previous training, folks came and the environment was set up, we're launching attacks, we're teaching them how does SSRF work, what does brute force SSH look like, how does it work with GuardDuty and Security Hub.

And now we're just taking you back to square zero. Day one, you've got nothing, let's turn on [00:33:00] some logs, and let's start analyzing it, right? And we're going to show also, primarily we're going to focus on AWS, but we're going to have Azure components in there as well.

But hands on, primarily, likely will be mostly AWS with some Azure.

And then at some point we'll probably branch into GCP, but yeah, we're trying to keep it today to a two day course and not just necessarily go to four from the beginning. But yeah, so that's what we're saying is, folks are lacking the experience or understanding of how does the plumbing behind the scenes work and if I were to need to go modify or create more plumbing, where do I even start?

And so that's the experience that we're hoping to give people that go through this course.

Ashish Rajan: It kind of ties in well to what you were saying earlier for threat detection when people are starting off as well. Over time, whether it's through the plethora of SIEM solutions we've had, a lot of people have had the luxury to already get a lot of detection by default.

And people may assume they have covered everything with that because I already have 10, 000 detections. [00:34:00] Why do I need 20 more? Whatever these are talking about oh, I need more S3 buckets. I feel it's worthwhile calling out. And I don't know if you agree with me on this, but those defaults are for majority of things they have seen across other customers, but that doesn't necessarily mean it's for the applications you host in your own organization, you may have compliance requirements for whatever industry you're in, you may have services that they have are just not popular, but somehow are popular in your industry, right?

That may not even log into CloudTrail. And you don't have no idea because you didn't listen to the episode and did this thing that Will said. Is it even logging? Is that the check? How do I find out if this thing is running in the first place? I don't know. Do you find that there is a bit of a gap in there as well?

And that's why it's important for people to understand how to build something and maybe, get their hands dirty in the cloud as well.

William Bengtson: Yeah, I think so. Because you can go buy detections, right? Yeah. And bring something in.

Ashish Rajan: Yeah.

William Bengtson: The problem with that is, it's missing the context of how your environment works.

What do you allow? What [00:35:00] don't you allow? What's a standard pattern, right? And so that's where I think getting your hands down and dirty, getting into the logs, figuring out how that all works, helps you understand how can you tweak a detection that you built?

Ashish Rajan: Yeah.

William Bengtson: Or a bot? Yeah,

Ashish Rajan: yeah.

William Bengtson: Where you get for free with whatever platform you bought?

Ashish Rajan: Yeah.

William Bengtson: And how do you enrich it? How do you, what's the next step?

Ashish Rajan: Yeah.

William Bengtson: But I think also, it's the same thing from when I talked about the Red Team mentality. With hands on building and understanding kind of the plumbing behind helps you actually understand how developers are deploying, infrastructure.

Yeah, how things actually work.

Ashish Rajan: Yeah.

William Bengtson: And I think it gets you closer to that so that when you are looking at the log source, the logs for detection to respond to them, you can think back Oh, yeah, this is what that actually means. Yeah. Or, I understand what a assume role actually means now, right?

Those kind of things that. If all you're doing is responding to things in Splunk or building things out there, you might not actually understand. And I think that's how I've gotten at least to where I am today with my understanding of cloud was early on when I joined that startup back in [00:36:00] 2015.

Ashish Rajan: Yeah.

William Bengtson: I was just clicking in.

I was just, I was like, oh, an AWS account I can play with. I don't have to pay for. Let me learn yeah, and from there. It's like I gained an understanding of how cloud worked now I want to build detections for it. Yeah, let me build those detections.

Ashish Rajan: Yeah,

William Bengtson: That's the same thing too with you know really understand the context of things and not just turning on the hose or you know i bought all these detections from this vendor

Ashish Rajan: Yeah,

William Bengtson: is there's gonna be false positives.

You're gonna have to figure out how to scale yourself as you scale from a cloud perspective

Ashish Rajan: Yeah,

William Bengtson: part of that is understanding. What is good and what's bad in your environment?

Ashish Rajan: In some of the training that I was running for SOC people, I came across this question and I think, I'm curious to know your answer.

The blurry line between if I see a cloud alert and I may think it's a high or a medium. I still have to reach out to the application team to figure out, hey, is this a high or a medium? Because I have no context for this. But the idea of tinkering around in a cloud environment is sometimes foreign, because it almost [00:37:00] is mistaken for I'm expecting a XSS, I'm expecting a SQL injection, but if you put your eyes across what happens in cloud is usually misconfiguration, which can lead to a vulnerability, right?

So the question that becomes wait, so am I not looking at security alerts? I'm looking at misconfiguration alerts. Isn't that a developer's job? I struggle to answer that sometimes because I'm like no, it can lead to, but have you come across that challenge as well in your?

William Bengtson: Definitely if you think back to what's the source of a detection?

Is it a leak credential? Is it a misconfiguration to your point?

Ashish Rajan: Yeah,

William Bengtson: They had to have gotten in somehow

Ashish Rajan: Yeah,

William Bengtson: right. And I think the biggest thing with burnout is too many alerts the biggest thing with burnout and animosity is to your point. Isn't that a developers job, right? If the security team is always responding to a misconfiguration that they believe the application team should have not done.

Yeah. You're gonna get some, headbutt and things, right? And it's how do you solve that?

Ashish Rajan: Yeah.

William Bengtson: Do you even understand [00:38:00] what that alert means? And, or the application logs, right? Yeah. You're going to be working with the different teams regardless, but yeah, I can totally see, and to your point, misconfiguration is how it happened, right?

Unless it's the leaked secrets, phishing, vulnerability would be the only other thing I could think of that's not misconfiguration. Yeah, and most of the That could lead to things, but Yeah. A lot of what we're seeing, especially in like our, what we call our sandbox environment, where we allow users to play and discover, is, oh, let me just deploy this database.

Postgres, let me just go, I'll username, password, Postgres, you go.

Ashish Rajan: Actually cause you mentioned secret detection as well. Would you say, in terms of examples of what's a good place to start, building detection for capability, what are your thoughts on using secret detection as like a starting point for those kind of things, especially in a cloud native world, perhaps you guys are using it as well.

William Bengtson: It's a great place to start, I think. I think it's a good place to start flexing that threat hunting, if you will, from a maturity of your security program, maturity of your [00:39:00] SDLC program.

Ashish Rajan: Yeah.

William Bengtson: Secrets Management Program. If you think about, I've loved what AWS has done, and I hope other cloud providers listening follow suit is, when a credential now is leaked in GitHub.

Ashish Rajan: Yeah.

William Bengtson: Publicly, if it's an AWS credential, they tell AWS, AWS nukes it. Oh, okay. Yeah. They put that policy on it that says this doesn't work anymore.

Ashish Rajan: Yeah.

William Bengtson: And it's for the customer's protection, right? If you remember back in the day, it was lots of crypto mining, right?

And nowadays, it's lots of crypto mining that lead to very large bills.

Ashish Rajan: Yep.

William Bengtson: That customers are gonna get stuck paying or you know paying at the end of the day, right? I think AWS might be forgiving the first time. Yeah, but when it happens the second and third,

Ashish Rajan: yeah

William Bengtson: What do you do? I forget the stats but at one point, you know that the crypto mining folks that are listening to the public event stream are faster than a lot of the other tools sometimes.

Which is crazy to think about. I think it's within seconds.

Ashish Rajan: Oh wow, so it's not half an hour anymore.

William Bengtson: I [00:40:00] don't think it's within half an hour that these crypto miners can pick up things. I think it's something like on the order of 30 seconds or something.

Ashish Rajan: Oh my gosh, they're scanning all public repositories.

William Bengtson: Yeah, so GitHub now has a public event stream. And so for every commit, every commit they're just running looking for this. It's a certain kind of secret. Oh my God. And so luckily, like with GitHub, I don't know how GitLab or others do it. They've got the token scanning project, which, hashCorp we're part of as well.

Okay, nice. Anytime a Terraform cloud token or HTTP Terraform token gets leaked, we're notified and we remediate. Similar to how AWS gets notified with credentials. Yeah. And then they remediate.

Ashish Rajan: Yeah. Okay.

William Bengtson: Which I think is super cool, but there's all the other credentials that exist, and it is not, developers may be doing it on purpose because there's not a better solution.

They need to put their secret somewhere.

Ashish Rajan: Yeah.

William Bengtson: There could be a, oops, I didn't realize that when I did a Git add all.

Ashish Rajan: Yeah.

William Bengtson: Or

Ashish Rajan: a Git

William Bengtson: add dot. Yeah. That it actually added these files that had all my secrets in it.

Ashish Rajan: Yeah.

William Bengtson: And then you push it up not knowing.

Ashish Rajan: Yeah.

William Bengtson: But yeah, you might have secrets out there that could be problematic if someone happened [00:41:00] on them publicly.

Ashish Rajan: Yeah.

William Bengtson: Or you might not think it's a problem because everything is a private repo or internal repo. But what happens if someone gets access to the GitHub, right? What happens if someone deploys a misconfigured box that has GitHub credentials on it, and all of a sudden now they can see your source code? I think detecting secrets to your original question is a great place to start.

Ashish Rajan: Because I guess these days, you're probably using some kind of secret manager, like a HashiCorp Vault or something. What are some of the components that people may interact with ? Because I guess you guys have Vault, Boundary and a few of those for security lifecycle.

William Bengtson: Yeah, like detecting secrets since you brought it up. Yeah, Hashicorp Vault Radar is our, solution where we're trying to detect secrets in source code, initially and branching out to other things. Slack, JIRA. Wherever else you might paste things that you don't want, really tying that back to if you think about how do we do better from that if we have a problem is, our vault product is allowing you to store those secrets.

Securely and push those out [00:42:00] into the environments that you want them to be in or allow those applications to query in the Vault and read them and then boundaries, our solution for really giving you that secure access to manage targets. So

Ashish Rajan: yeah,

William Bengtson: SSH without having to fumble certs, remote RDP, things like that

Ashish Rajan: Because I guess Vault is open source, it's very popular as well. The reason I bring the secret management part is only because I feel sometimes it could be overwhelming to look at the detection space. And look at the 10, 000 alerts that come in, which place to start. I think I personally found secret scanning was like the easier one.

But I also feel for people who are starting off in this career as well. I think we were talking about this briefly earlier. For anyone who's starting today and want to get into cloud detection response, probably I think I'll probably add let you add the flavor. How do you see the market of talent that's coming into the space?

William Bengtson: Yeah, I think there's a ton of interest which I think is great, because you always see the stats of, we need this many security people. And then you're like why aren't people hiring? And I think first and foremost, that's a problem, right? [00:43:00] With the economy and market and things. But secondly, you've got folks that are switching careers, just getting out of school.

Maybe they don't know what they want, and so they need to go find or ask people, how did you get into security? Maybe go read a book or something, and see how other people got into security. And I find that a lot of people think, and rightly and a lot of companies are willing to give or bet on someone with no experience as a SOC analyst, as someone that can come in and feel those alerts, gain some experience, decide if that's an area they want to stay or then pivot.

And so I know a couple of people that are still looking, unfortunately, for jobs. And, those are the kind of things that I'm leading them to is hey, maybe go look here. And see if that's something you like.

Ashish Rajan: Is there a space where you say that you don't, is the bar lower to get into a SOC analyst for cloud detection response role?

I don't know if the bar is lower. And I don't think in the context of not lack of knowledge, but [00:44:00] more in the context of that. If I don't have a lot of experience on premise, but I've been working on, I don't know, cloud security projects, building detection, probably got a GitHub repository, build a project portfolio, I don't know, have a few medium articles on it or whatever, for getting into the cloud space, specifically if it's a cloud first kind of company, I imagine would the bar be low for that in terms of, oh, I don't have to prove 18 years experience in on premise detection response, because it's a cloud first world we are moving in.

And I've done a lot of work in cloud where I can prove to people that I've done this. I think I meant more bar is lower in that context where I don't have to prove my 18 years of experience in on premise I go into like apply for a job in cloud.

William Bengtson: I think so. And I think, folks can go self study and get some of the basic certifications.

Which proved they have some knowledge.

And that might be enough to get them that first, or the foot in the door.

Ashish Rajan: Yeah.

William Bengtson: And then from there, mature, soak up knowledge from other people.

Yeah. Pivot into other areas.

Ashish Rajan: Yeah.

William Bengtson: And when I started out, it was like code security because I came from a [00:45:00] software background.

Ashish Rajan: Yeah.

William Bengtson: And then it became penetration testing because it was, how can I think about how you write an API and how I can abuse it?

Ashish Rajan: Yeah.

William Bengtson: And it just snowballed from there. into detection and, now building out security teams and things, right? And yeah, I could see that with the cloud, especially with all the public resources and training, like when you and I came up, it's like, where do we go learn, right?

IRC who's going to teach me? It's I'll teach you to hack. I want to learn how to defend, right? But yeah, now all the different resources online.

Ashish Rajan: Yeah, there's a lot more events

William Bengtson: like this, even Black Hat, I think so does scholarships for students. Oh, wow. Wow. ShmooCon does it as well.

Yeah. Are really helping people network, get that experience, but to your point, no longer do you have to be like, Oh, I was managing network security for 15 years in order to just get, in the door over here. Yeah, fair. Which I think is good.

Ashish Rajan: Yeah, but I think, I don't want to undermine the fact that you still need to [00:46:00] understand the fundamentals, though.

You still need to understand how networks work. of works and VPC and one of that as well. That doesn't go away. It just that you don't have to sit there and go into a data center and figure out which plug to what firewall is a which netgear firewall or whatever. I remember that these used to be a whole CCNA certification used to be so popular at a point that if you have a CCNA certification, you're definitely getting a job kind of a thing.

Because I came from a more infra kind of background, right? And in that space, there was a Microsoft certified service professional or something MCSP used to be very popular CCNA was popular, but now

William Bengtson: I remember back going through school I wanted to go get my Cisco cert. So I could at least prove that I had some knowledge Yeah,

I

Ashish Rajan: mean, I'm sure there's value in there as well.

So no, it's not that everyone's on cloud. It's just that If you are specifically thinking of working in the cloud space, the bar could be lower depending on who you talk to. But as long as you're proving that you know what you're talking about, whether it's through public projects and other things as well.

But one thing that I've been talking a lot more recently about is that when you and I [00:47:00] started, the number of services were not that many. So we had a lot more, without feeling overwhelmed. It was new technology, so it was a bit more overwhelming. But it wasn't that I have 400 services to look at.

Yeah. And figure out which one of these 400 we wanted to figure out detection for or response for. Do you find that the bar may be lower to get in, but the bar to be an expert is higher now? Oh, definitely.

William Bengtson: I think it's, to your point, I don't even know how many services there are in it. Yeah. A ton, right?

And no one's going to be an expert, right? You might be an expert in one area.

Ashish Rajan: Yeah, yeah.

William Bengtson: You might have a broad knowledge across the board. Back to what we started with like on prem to cloud. Some of those skill sets transfer when it comes to like host based monitoring and those kind of things.

But when it comes to cloud detection, it's all brand new to everyone.

Ashish Rajan: Yeah.

William Bengtson: And every cloud security engineer dreads the product launch, right? Yep. Because it's once again, tying it back to looking at the log, understanding it, it's looking at the service. Understanding what could go wrong.

Ashish Rajan: Yeah.

William Bengtson: That translates into the things that you might want [00:48:00] to detect.

Ashish Rajan: Yeah, oh my god, yes.

William Bengtson: And I think back to your like barrier of entry, the one thing I love about like detection and SOC and things like that is you don't necessarily have to know everything to get in.

You're gonna reach out to the experts anyway, when a problem happens.

Or maybe you're mature enough that you have really good runbooks, that when you see this, do this. Or, when you see this, these are how you tell if it's false positive or not. And if it's not a false positive, or you don't know. Escalate it to that next tier when you do that, maybe you can go look over their shoulder while they're doing it.

Yeah. Yeah. But yeah, service launch is all that we used to dread that day.

Ashish Rajan: Yeah, I'm pretty sure people still do. Yeah, I'm sure people walking away, especially with

William Bengtson: I'm pretty sure there were some Amazon Q announcements this week. Yeah,

Ashish Rajan: yeah, they had a few services, AI in the cloud. Yeah. What does that even mean? Networking has changed quite a bit.

Quite a bit as well. I think some of the conversations I was having about earlier to what we were saying, people started in the beginning, one VPC for test one [00:49:00] VPC for prod. Now, the idea is there's a central account for hosting your one VPC that you extend the subnet to multiple accounts.

William Bengtson: Yeah, it's not even physically there.

Ashish Rajan: I'm like, what is this world? It's not even physically there anymore. But somehow it appears in your network. And I think I'm curious also from a perspective of how would detection change in that context as well when it's just an object and you're trying to figure out where is this object in the large cloud footprint that I have and but then is that going to be a rich enough information that both me and an attacker can figure out really quickly?

Oh, there's more here. It's not just this because earlier, in a way, security through obscurity, oh, this is the only VPC. I guess they don't have any more accounts. Yeah. But now I know there are more accounts because I see there's a resource that is from another account. So now I know where I need to pivot.

I know what account number shall we're trying. I'm not gonna, I'm not gonna stop ranting, but it has changed quite a bit.

William Bengtson: I mean, yeah, I think it ties back to the do you have the list [00:50:00] of all your accounts?

Ashish Rajan: Yeah.

William Bengtson: And now it's, do you have a list of all your resources? Because to your point, that resource might actually be from a different account.

Yeah. And so it really speaks to asset inventory. Yeah. And then, you think about the what if you do have an attacker on the inside? Do they have access to that asset inventory? So you didn't bridge into identity problems and all of things, right? Oh God, yes. Yeah. Yeah. We were talking about identity access management before as well.

It's all just coming together and it's the, I would say the one good thing is as cloud is evolving and companies are really embracing it and going both feet in

Ashish Rajan: Yeah.

William Bengtson: It's forcing everyone to mature alongside.

Ashish Rajan: Yeah. Yeah.

William Bengtson: And if you're not maturing, and if you're not prioritizing, yeah.

You're gonna be left behind and you're gonna be the next one on the SEC conversation, announcing

Ashish Rajan: yourself as we made a boo . Those are most of the questions. I've got three fun questions. Sure. You I think we had them the last time you were here, so I wonder if the answers have changed.

First one being, what do you spend your time on when you're not working on threat detection of the world?

William Bengtson: So professionally, Rich and I spend a lot of time figuring out like, what trainings can we do, , one of the things we, I didn't mention that we always try to do [00:51:00] is, if a student left our class, would we hire them?

And that's our bare bar is we want people to walk away with the skill set where they would be someone we consider. And so I've spent a ton of time thinking about that. I've got some side projects going on with some ex-colleagues that I've worked with were just toying with business ideas that maybe one day.

Yeah. My wife and I were building a house and so that's taking up all my time. Oh, wait, actually, are you involved

Ashish Rajan: in like building the roof or anything? Oh no, we're not building it. Oh yeah. I'm

William Bengtson: like, wow. That is a project? No, we're designing a house and a builder build it.

Ashish Rajan: Oh yeah.

Okay. Yeah,

William Bengtson: we've been in that process for 10 months now.

Ashish Rajan: Oh, wow. Okay. Yeah.

William Bengtson: Nearing the end, but that's taken up a ton of my time and then, yeah. I'm still, I think. Can't remember if last time I was as, as into bourbon as I am now, but big avid connoisseur and collector of bourbon. Usually if you find me at these conferences, I'm like, Hey let's go find a bourbon that we like, which I think is, I don't know if it's unfortunate or fortunate that it seems to be something tied with security industry is, people like bourbon.

[00:52:00] Yeah. So it's been great to network and things share memories over a glass of bourbon with folks, but. That's where I spend a ton of my time, right? Perfect. I think since last time I was on, I got married. Yeah. My priorities outside of work have changed a lot. Fair. I used to, after work, switch to my side project and just do that every day.

Yeah. Now, it's after work, I need to go in, see the family. I've got two puppies now. Two, yeah, I guess they're still puppies. Yeah, fair. They're about two years old. Oh, wow. Okay. Life is different. .

Ashish Rajan: If the two dogs, you're definitely busier than normal as well. Second question, what is something that you're proud of that is not on your social media?

William Bengtson: I'm proud of my wife, first of foremost. Oh yeah. No, ill send the recording to her yeah. She would never watch it. , with 4 0 4, she's never watched an episode. Oh, really? . Yeah. And it, she's you're welcome. I think back to like my career, I don't know if you ever do this. I do what? Ifs a lot. I yeah.

I would do what if. What if I would have married that girl? What if I would have taken that job? What if, right? And I reflect back on that [00:53:00] quite frequently. And so I'm quite proud that even in switches that I've had, That I've always landed well, I've learned and tried to make the most out of any situation.

And I got some advice back early days when I was working at Raytheon, which is taking a step sideways or even backwards isn't setting you back from a career perspective, and I've tried to think about that as I make different moves.

Ashish Rajan: Yeah.

William Bengtson: And so I've been quite happy with my, what if I think I've made the right decisions.

Ashish Rajan: Yeah.

William Bengtson: Haven't regretted any of them one bit.

Ashish Rajan: Yeah.

William Bengtson: And I'm proud to, I know you said what's not on your LinkedIn, but I'm proud to where I've gotten to, yeah. I'm proud of who I've become as a human proud that I'm building a family. Yeah. And then, what's most importantly proud of my career as well.

Ashish Rajan: Would you say it's also following your gut as well? Cause to what you said, you started in software development, then you switched over to pentesting, which kind of seems like a natural transition, but then you switch to detection, which is like no, you go up because a lot of traditional path might have been go to manager level then there, but you do take sidesteps, but you [00:54:00] follow the gut for what felt right at that point in time.

William Bengtson: And so followed gut, found the things that I liked. Yeah, it took advantage of opportunities given to me. Yeah. Advice I'd give listeners is if someone offers to collaborate or to go grab a coffee or a bourbon, take them up on it, right? Yeah. If Ashish ever asks you to come be on the podcast, figure out how to make it work.

That's right.

Ashish Rajan: Even if it means coming finding out one hour before your flight leaves. I love that because, I relate to your point about my what ifs is having more around seasons, I feel, is how I describe it. What feels positive right now, what makes me happy and it could be different like I think different things for different people and people can reflect back.

I reflect back on the concept of what I'm doing right now does it make me happy. If it doesn't, then I need to change something. And the same way as you are thinking as well. Man, thank you for sharing that. Third one, which is final question. Favorite cuisine or restaurant is well used be the question.

Now we switched it over to, if you're stuck in an island and you can only get one dish. One dish. Or a cuisine. A cuisine, what would that be? Can be from [00:55:00] any restaurant, by the way, that dish?

William Bengtson: So I love Italian food. Oh, nice. So the cuisine would be Italian. We spent our honeymoon in Italy. Oh, nice. I just, yeah, I love it.

It would be that, and it'd probably be like. Tagliatelle Ragu. Oh, wow. Or a lasagna or something. I'd have to, the island would need to be big, and I'd have to do a lot of exercise. But otherwise, I'd be as big as this table. But yeah, that would probably be it. Better always say I can't survive without chicken.

Oh, yeah. You definitely need some chicken.

Ashish Rajan: That's awesome. Now, thank you for sharing that. For people who are wanting to get in touch with you, to talk more about threat detection response, where can people find you on the internet, we can connect with you.

William Bengtson: I'm on LinkedIn I think it's William Bengtson.

Yeah,

Ashish Rajan: I'll put the link.

William Bengtson: Or yeah, I'm still on X. Oh, no! I just downloaded Blue Sky the other day. Oh, nice. Okay, yeah, fair. I'm just slow to do the whole thing. It's more just I don't want to have to manage another thing. So I'm slowly transitioning over. I'm glad I I don't know. Is Mastodon still?

Ashish Rajan: Yeah, apparently. Yeah. Thank it is still, but I'm glad

William Bengtson: I've [00:56:00] missed that boat 'cause it seems to be everyone's going to Blue Sky now, yeah.

Ashish Rajan: Oh, that seems to

William Bengtson: be the

Ashish Rajan: hottest thing at the moment. Yes.

William Bengtson: Yeah. And yeah, I'm still online. Yeah. But LinkedIn's probably the best place to reach.

Ashish Rajan: I will leave the link.

William Bengtson: I'd say if you connect, send me a message and let me know. Yeah. 'cause I get so many connections these days and I can't tell. Yeah. Fair. I think that hurt. Bugs me the most about LinkedIn is the business development people that put in their headers if they're actually an IC.

Yeah. I had security. And you're like, solving secrets management, whatever. And I'm like, Oh, cool. And then I look, I'm like, Oh, you want to sell me something? Send me a message and let me know. You don't want to sell me something. You just want to chat.

Ashish Rajan: I will leave the links in the show note only for your LinkedIn.

Thank you so much for coming in.

William Bengtson: Thanks for having me. This has been awesome.

Ashish Rajan: Thank you so much for listening and watching this episode of Cloud Security Podcast. If you've been enjoying content like this, you can find more episodes like these on www. cloudsecuritypodcast. tv. We are also publishing these episodes on social media as well.

So you can definitely find these episodes there. Oh, by the way, just in case there was interest in learning about AI cybersecurity, we also have a sister podcast called AI cybersecurity podcast, which may be of interest as well. I'll leave the links in the description for you to check them out. And [00:57:00] also for our weekly newsletter, where we do in depth analysis of different topics in cloud security, ranging from identity, endpoint to what is a CNAPP or whatever the new acronym that comes out tomorrow. Thank you so much for listening and watching. I'll see you next time.

‍