David Spark (2:38)

Andy. Yes, some People care about this. I will agree that some people care, but I'm trying to hit more people that care about this.

Andy Ellis (2:46)

But I think the challenge is if your definition is everybody has to care about it.

David Spark (2:51)

Not everybody. The greater majority.

Andy Ellis (2:54)

Now, you're not going to find anything the majority cares about. The goal is to create micro inclusions, lots of little places that as long as somebody cares about one of them, then they feel included. But if you try the one thing that a majority cares about, well, what you're really saying is that a near majority will not care or be outreached at all.

Tim Lahee (3:12)

I just wanna.

David Spark (3:13)

Tim's jumping in as our guest. Go ahead.

Tim Lahee (3:14)

I just wanna say. Yeah. If the audience doesn't know I did in fact hear these knuckleheads argue about this before the show.

Andy Ellis (3:25)

I would like to say there's only one knucklehead here. The other one's a pinky head. You can decide which is which.

David Spark (3:30)

All right, let me just point something out. This is something we debate about all the time. By the way, being the producer, I always pull rank and say, we're gonna talk about this. But this was the first time Andy truly went over and says, why don't we talk about this debate? We constantly have.

Andy Ellis (3:45)

Yeah. So folks, if you're actually listening and you care one way or another, drop us a comment. Either LinkedIn, the CISO series.

David Spark (3:54)

We actually have a feedbackisoseries.com feedback message.

Andy Ellis (3:59)

Lots of places where we will listen. Tell us what you think. Do you enjoy that we banter about Pablum or do you want us to banter about things that you might not care about but are still relevant?

David Spark (4:08)

Well, this is dropping just a few weeks before rsa and I was going to bring up something about RSA and swag, which I thought it would be more relevant for everybody here.

Andy Ellis (4:17)

Oh, could have. But you didn't mention that in our pre. Banter. Banter. You just said nobody wants to hear about Purim, which is today as it drops, or the super bowl, which we're happened to be recording this right before

David Spark (4:28)

and he's going to it as well.

Andy Ellis (4:30)

And I'm going to the super bowl again.

David Spark (4:31)

They're all interesting, but the greater majority would care about about SWAG at rha. My main comment about that maybe, but

Andy Ellis (4:40)

sometimes we banter about pinball. And so I'm not convinced that you can say it's about the majority.

David Spark (4:45)

That was just leverage on you because we had a guest on who's also pinball nerd like me. Let's bring on our Guest, who you just heard moments ago, he hasn't been introduced yet. All right. He called us knuckleheads. I don't know how.

Andy Ellis (5:01)

I'm happy. He's welcome back with that.

David Spark (5:04)

All right. Our sponsor, Guest. He is the VP of Corporate Strategy and Operations over at our sponsor, Strike 48. So thrilled that he's here. Tim Lahee. Tim, thank you so much for joining us.

Tim Lahee (5:14)

It is wonderful to be here. Thank you for having me. Despite the knuckleheads, I do in fact enjoy the banter.

Andy Ellis (5:22)

I got a question, Tim. Are you the VP of Corporate Strategy plus the VP of Operations? Are you the VP of Corporate Strategy and the VP of Corporate Operations?

Tim Lahee (5:32)

I am too old to care, my friend. They came in, they asked me a year ago to join the company and sort of re pivot the company. So it was sort of the strategy. And then over time, I've really. We've been successful and so I've assumed more and more of the org.

Andy Ellis (5:49)

There you go.

Tim Lahee (5:49)

But at one point they asked me if I wanted to be a senior VP or vp and I was like, I'm too senior to care about either

David Spark (5:57)

of those two things. Would it change your salary? No. Yeah. So what does it matter?

Andy Ellis (6:04)

My general answer is if it's not going to change the salary, you take the lower pay grade. So by the time HR gets formalized, you can be like, oh, I need a promotion and a salary raise. Whereas if you already have the promotion, you can't get the salary raise with it.

Narrator/Intro Voice (6:19)

Are we creating more problems.

David Spark (6:25)

When everything is labeled high priority? The system forces a trade that nobody wants to admit out loud. Speed competes with quality, while the demand for perfection stays absolute. Now, unlike security teams responding to incidents in real time, forensic examiners, we rarely talk about this. Face a different hell, argued Eric Waldrip of the Waldrip company. Their work must be 100% correct because opposing experts will retest everything and small mistakes cascade into major legal consequences. They're operating in a moving ecosystem where OS updates and AI generated evidence shift what artifacts mean, all while being told every case is urgent. Andy is demanding perfection from forensics teams. Realistic. And how many security leaders understand the legal weight their forensics teams carry when an incident moves for from response to litigation. What say you, Andy?

Andy Ellis (7:24)

So I think the first thing to note is that most forensic investigations do not go to litigation.

David Spark (7:30)

That's good.

Andy Ellis (7:30)

And maybe that's a misuse of the term forensics, but there's a lot of forensics professionals that are really just amazing incident responders and they don't need that level of perfection. We need to know what happened. We don't need to prove it in a court of law. We need to prove it to ourselves. Much lower standard for perfection. When you're going to go to litigation, it is going to be very different at that point. And I think it is reasonable to demand a type of perfection. But people often ask for the wrong one. Right. The perfection you need is the perfection of defensibility. Everything you say must be defensible. It is not that you have perfect knowledge of what happened. It is that you make no argument that is indefensible. And that's really hard for a lot of people to wrap their heads around and is that you're basically, you're a witness and you have to say only the things that you can prove are true. And so if you can't prove it's true, you have to put that caveat to say, well, I might think this. I had this picture, but I don't know that the picture was really there. In what way might I be wrong?

David Spark (8:30)

Good point. All right, Tim, I throw this to you. First of all, have you dealt with forensics? I think you have a long history of this.

Tim Lahee (8:37)

Yes, I have a lifetime in forensics.

David Spark (8:40)

So did you feel this level of pressure that I described here?

Tim Lahee (8:44)

Well, so it's funny, I think you go in with that assumption of that level of pressure, but actually, after you've been in the ring so many times, you sort of realize when a jab is coming versus a haymaker and if you adjust accordingly. Right. Perfect example would be any given piece of evidence on the computer is, you know, it just is what it is. You produce it. Fine. But opposing counsel will often go after the procedures you utilized, the approach you took, the documentation. And it's so funny because you as a forensic practitioner, you're worried about, hey, did I do the memory parsing correctly or did I do this right, or did it? And that is very much over the head generally of opposing counsel and not the sweet spot they're coming after. So oftentimes it's not that you don't have that level of pressure and that they won't get you or they won't come after you for it. But you have to put yourself in the mind of opposing counsel, and they will come at you where they think they're strong, and that's in procedures, in logistical stuff, generally in the stuff you as a technologist aren't even paying attention to. And that's when sort of like at access data, which company I ran for a long time in the training courses. We would hope it focus heavily on that type of stuff because that's what gets really attacked.

Andy Ellis (10:13)

Yeah, I think a great way to look at it is opposing counsel is attacking your credibility, not your conclusion. Because they don't have the credibility to defeat your conclusion until they defeat your credibility first.

Narrator/Intro Voice (10:28)

Managing Security Changes for business Optimization.

David Spark (10:33)

Your firewall isn't the problem. Your sim isn't the problem. That shiny new EDR tool you just bought, also not the problem. End quote. Culture eats your security posture for lunch and the proof is in every exception request you approve, argued Maman Ibrahim and Gavriel Schneider in a CSO online piece. Executives get device exceptions. Developers turn off security controls because they slow deployments. There's an unspoken rule that senior enough people can over overrule security. The list goes on. All this shows that you've got an anti security culture actively working against you. With all those exemptions, is that a failure of your security awareness program or is your approach just wrong when you've built friction that your existing business culture can't accept? You're always walking into a business culture in motion and your job is figuring out how security fits within it. And I'm going to start with you Tim. How do you know when to push back on culture versus when to redesign your controls around the culture you've got?

Tim Lahee (11:41)

Yeah, I mean my guiding rule here is security needs to be an enabler of business.

David Spark (11:48)

Right?

Tim Lahee (11:49)

Right. And too often professionals sort of come into a security profile and they know how security is supposed to be done, how it's correct, how to protect the business best. But if you're not enabling the business particularly I've lived my whole life in small tech and you're just trying to run fast. Do you know what I mean? And security is critically important, don't get me wrong. But so are the market forces that are coming after you. So if you're security professional and you come into an organization that has to run fast to survive, then you have to understand that exceptions are going to be a part of the security profile and how do you work around them? You shouldn't build this rigorous profile and then have these exceptions sort of just bleed out. They need to be part of the pre thought out solution. That's the only way you survive.

David Spark (12:43)

That's a good point. That if you do have exceptions, don't think this is a hole in my security. This is something that is expected and I have to build around it.

Andy Ellis (12:52)

Yeah, I think that the challenge is like the Question was like, do you have an anti security culture? And I think you have the opposite, which is you have an anti business security culture. Okay, Right. If you have a set of executives. And I remember when blackberries were all the rage, like before the iPhone and every sales rep wanted a BlackBerry. And I got into a fight with our head of it and the head of IT is like, we can't support these, so they're not secure. And I said, the business needs them, we have to figure it out. This is the difference in those two cultures. It would be like saying, let's say your first job was inside a skiff, inside a salt mine buried under a mountain. Like, imagine the most insane level of security controls you could put around a building. It'd be amazing. Right? And you walked and said, that is how I'm going to secure everything I do from now on. And then you went open to McDonald's franchise.

David Spark (13:41)

Mm.

Andy Ellis (13:42)

Right? You can't run a McDonald's franchise that way. Like, this is not the security model for that business. A very different one. And that's what you have to do. You have to start from first principles. When you walk into new business and say, what is the culture of this business? What is the pace at which they operate? What is the risk they're willing to take? And now I'm gonna have to figure out how to secure that. And that might require some really ugly trade offs.

Tim Lahee (14:04)

Can I give a great example of that?

David Spark (14:06)

Yes.

Tim Lahee (14:06)

I had a security professional that came out of the army and really talented, super smart guy. But the first thing he wanted to do in our small sort of startup mentality company was disable all the USBs. And he told stories about in the army how they went through with a glue gun back in the day before they had security and they glued them shut. And I'm like, that is just not gonna fly here. Get your glue gun at home. We have to sort of adjust your brilliance to the way we need to do business. He was able to adapt and we were successful. But the mentality was not appropriate for that business.

David Spark (14:45)

Before I go on any further, I do wanna tell you about our fantastic sponsor. And that would be strike 48. So everyone's talking about AI for security. You hear this on all our shows. Co pilots, assistants, chatbots, the list goes on. However, it's no secret that AI is only as effective as the data it can access. So how much time is AI really saving you? Can it query the data it needs or just a few isolated silos? Can you trust it to do Real reliable security work. This is where strike48 enters. The first agentic log intelligence platform that gives AI agents the visibility needed to take a load off your team. Now if your SIEM costs force you to drop logs or put them in cold storage, any existing AI you deploy will have blind spots. Not anymore. Now you can maximize log visibility without blowing the budget. Plus the platform connects to your logs wherever they live. So you can keep the technology you already have. With Strike 48 you can deploy pre built agent clusters or build your own agents and workflows covering phishing, threat, intel alert, triage and more. Go ahead. Try strike 48 for free. You can do it. Just go to their website, strike48.com, it's spelled the way it sounds. S T R I K E. The number four. The number eight. The number strike48.com security and start deploying log intelligence agents today. Remember, that's strike48.com security.

Narrator/Intro Voice (16:27)

It's time to play what's worse.

David Spark (16:32)

Tim, are you familiar with this game?

Tim Lahee (16:33)

I've never played it before, but let's

David Spark (16:35)

give it a go. All right. It is very simple concept. I'm gonna give you two scenarios. They both stink. You have to determine from a risk management exercise which one is riskier will cause more problems. Now this comes from Joseph Carson of Segura and we did a recording earlier and he came up with what Andy believes the best. What's worse comparison? Because Andy truly struggled because it was something that could have been a big nothing or a big giant problem. Yep, this one is definitely a problem. But definitely, I think one side would definitely be a problem no matter what. I think the other side could conceivably be no problem. Conceivably. So here you go. Here are your two bad scenarios. Scenario number one, a temp worker with domain admin.

Andy Ellis (17:27)

That alone is pretty problematic. Okay.

David Spark (17:29)

All right, hold on. You haven't heard the other one.

Andy Ellis (17:31)

What do they do with it?

David Spark (17:32)

It's pretty bad. I know it's pretty bad. A good one or. No one has domain admin access when production is down. Oh, just so you know, Tim, don't answer first. We make Andy answer first. So hold tight.

Andy Ellis (17:49)

I have to answer yes and you

David Spark (17:51)

have to agree or disagree with Andy. And I always love it when people disagree with Andy.

Andy Ellis (17:54)

So I'm assuming implicit in this that we're a Microsoft shop. So I can't just go with the easy out of find that nobody has domain admin access because we have root access on all our Linux machines machines. And that's Production. Yeah.

David Spark (18:05)

Or Microsoft.

Andy Ellis (18:05)

Yes, that would be the cop out. We're disregarding that because that violates the near rule. I think this one actually as much as we. I laughed right up front and said okay, domain admin with. With, you know, this attempt employee is bad. I think nobody with domain admin. When you need domain admin, that's presumed in the everything is down. I think not having anybody with domain admin is actually worse than.

David Spark (18:29)

But let me argue with you, that is definitely bad when it's down. But that wouldn't necessarily cause the havoc that a temp worker could do.

Andy Ellis (18:44)

You just had to do such a massive caveat. Wouldn't necessarily cause the thing that could maybe happen in this other scenario.

David Spark (18:51)

No, but the domain admin. Here's the thing. Not having domain admin when production is down doesn't mean you've had a hack or anything like that.

Andy Ellis (19:00)

No, but it means that I can't necessarily get back from it, Right?

David Spark (19:03)

Correct. Correct.

Andy Ellis (19:04)

Because otherwise it's not a bad scenario. So I'm presuming that the not having a domain admin while production is down is impacting my recovery.

David Spark (19:11)

Yes.

Andy Ellis (19:12)

When if it's impacting it, it's in a big way for not having a domain admin.

David Spark (19:16)

Yes, it is, but I'm just throwing out. It's not a hack where things are being stolen. It doesn't have sort of that extended concern to it.

Andy Ellis (19:26)

I know people. So I've been a temp worker before. In fact I am a temp worker now. Like I work for several companies on temporary contracts. Like so I think that one of the things.

David Spark (19:39)

But I just want to point out that the first one where before we talked in a previous episode, it could be a big nothing or it could cause serious havoc.

Andy Ellis (19:49)

In this case it could cause which is a little bit different than it will cause.

David Spark (19:53)

No, it's not a will, it's a could.

Andy Ellis (19:55)

Yeah, yeah. So I think this one's going to come down to. There's what we define as a temp employee. Do we assume all temp employees are malicious? If we do, why do we have temp employees? There's a lot of challenges around that.

David Spark (20:07)

Well, they all take post it notes. Right.

Andy Ellis (20:11)

But that said, sometimes you are going to hire like this is what VCSOs are. Right. They're temp employees that have domain admin access often because they're the person at the root of your security. So I can't arbitrarily say that is bad.

David Spark (20:23)

Well, we say temp worker. We're not talking about a vc, so

Andy Ellis (20:26)

it wasn't specified here.

David Spark (20:28)

And maybe for the purpose of this, we're talking a low level peon. It's a Kelly girl.

Andy Ellis (20:35)

Well, I was a Kelly girl, so maybe it was me.

David Spark (20:37)

You're a beautiful Kelly girl. By the way, they don't still use that term, do they?

Andy Ellis (20:42)

When I worked for Kelly Services, I was a Kelly girl, so I will still use that term. Okay.

David Spark (20:46)

All right, so who you get. What are you picking here? It's worse.

Andy Ellis (20:49)

I'm saying the second one is worse because it is demonstrable and real problem impacting the business. And that impact came from our inability to have redundant domain admins.

David Spark (21:00)

All right, Tim, we throw this to you. Agree or disagree with Andy?

Tim Lahee (21:04)

I'm going to agree with him under the premise he's using. That said, I think the nature of the question actually assuming you have an admin that has domain access, I think that's the essence of the question. Some random person has domain access and I live in a world where with the mindset that if it could happen, it will happen. I have lived both of these scenarios. The.

David Spark (21:29)

Hold it, wait, wait. So could happen will happen then. And you're not leaning towards the first one being worse?

Tim Lahee (21:35)

No, I. I only lean toward. I said Andy is right. Using the premise he did, which is maybe it's a CISO that has temp access or whatever. He sort of grabbed onto the temp. But in my mind, if the question is really, They've been so casual they gave a random assistant domain access.

David Spark (21:55)

That's the implied intent.

Andy Ellis (21:56)

No, it was not specified. And the near rule is very clear on this one.

David Spark (22:00)

When we say temporary, we don't consider a VC so that we have in our mind what a temp worker is.

Andy Ellis (22:06)

Wait, okay, I want to ask the audience to reach out to us. Do you consider a vciso on a time limited contract to be a temp worker or not?

David Spark (22:16)

Yes, technically. Yes, you're right. And you don't need to ask the audience.

Tim Lahee (22:20)

It's not the nature of the question

David Spark (22:21)

though that's technically correct. But in the spirit of this question, it is not considering a vc. So go ahead, Tim.

Tim Lahee (22:29)

Let me tell you that the two scenarios I've lived through. Okay, I have routinely lived through the second scenario in which I have been involved in a group where we didn't have the access we needed. Maybe it wasn't domain, maybe it was ever whatever. We didn't have the access we needed and a customer needed us to have that access to get them back up and running. It is like I've pulled so many all nighters, I can't even tell you what related to issues like that. It is painful. You have to report it immediately to the CEO. You get punched, but you did everything you could. Eventually someone domain access rolls in and everything gets better, right? I've lived that. It is awful and I've lived it a good number of times. The other situation I lived only once. I was an investor in a company that was casual with its security. It was rolling, it was doing about 20 to 30 grand a month. It was a small company, it was a virtual desktop. And I got a call out of the blue from the CEO. We've been completely encrypted. Company shut down the next day. So if it's gonna happen, if you're casual security, it just does happen. It was like three years.

David Spark (23:44)

Well, that sounds a lot worse. I would think you lean towards the first one.

Andy Ellis (23:48)

Wait, but was that breach caused by a temp worker with.

Tim Lahee (23:53)

No, but my point is if you're

Andy Ellis (23:56)

that casual, you're just saying that that's an indicator of sloppy security, which I might agree with, but that's definitely outside the realm of this scenario.

David Spark (24:07)

I think you are both arguing the first one, but picking the second one. This is what I think's happening.

Tim Lahee (24:12)

I mean again, it's sort of definition of question. But I would say if you are truly as casual as to give domain access to to some random person that walked in your network, that's worse because you will eventually get completely owned.

David Spark (24:24)

Then you're picking the first and you're disagreeing.

Tim Lahee (24:26)

Yeah, again, it was under how the premise, how Andy was sort of viewing the question.

Andy Ellis (24:30)

Yeah, but he's changed to a completely different premise. It's not Carson's question.

David Spark (24:34)

No, it is Carson. You know what, Joseph Carson's gonna respond. He's gonna tell us what his intention, which I'm thinking is what I'm thinking, I'm gonna make sure that he lets us know.

Andy Ellis (24:45)

So yeah, you make sure that you can put words right in his mouth, essentially.

David Spark (24:50)

So if I have this right, Tim, under Andy's premise where the quote temp worker could be a vc, so it's no big deal, you pick, the second is worse. But if the temp worker is a rando, like you were saying earlier, then yes, the first one's worse, 100%. Okay.

Andy Ellis (25:05)

Like if the scenario was roll D100 and that employee has domain admin, I might have felt a little bit differently about it. But that was not. And just to Be clear, I don't think having a temp worker with domain admin access is good. I just don't think it's bad. Is the demonstrable incident of we are down and cannot recover because we don't have anybody who has admin access.

David Spark (25:24)

Yes, but what you're saying is that is a known entity of being bad where the other one could be catastrophic. Like the company shut down in Tim's example.

Andy Ellis (25:34)

Yeah, but I've lived that. I've lived that one where it required me to hop in a Humvee, drive across the desert and reboot scarecrow systems from, like, master floppies to recover the admin access that we had lost.

Tim Lahee (25:49)

Yeah, I mean, listen, I've lived the second one so many times, it's just not uncommon. But I've also lived the first one, which I only lived once, and it was way worse than all the second ones put together.

Narrator/Intro Voice (26:04)

Please Enough, no More.

David Spark (26:09)

Today on Please Enough, no more, we're talking about the sim. You're familiar with the sim, right, Andy? Have you seen one before?

Andy Ellis (26:17)

Maybe just a little bit.

David Spark (26:19)

Andy, we've heard a lot about the sim and we're hearing a lot more about it now that there's AI. So what have you heard enough about with the sim and what would you like to hear a lot more?

Andy Ellis (26:30)

So it's hard to say what one thing I've heard a lot about because it feels like every other day I see another startup that's either they're doing AI threat hunting or AI detection engineering or AI sim optimization or AI soc or AI this or AI that. They all have the word AI in it. And so I guess what I'm tired of hearing is how is AI going to make yesterday's log management world better? And how is the future of incident management and event management going to be built on top of an AI model rather than just trying to replace the people who aren't doing the job with AIs that can do the job. Like, what's the new things we get? That's what I want to hear about.

David Spark (27:11)

I like that. All right. This leans into you, I think, a little bit, Tim, and I know you have a long history with sims as well, so tell me what you've heard enough about with sims and what you'd like to hear a lot more.

Tim Lahee (27:23)

Yeah, I mean, I couldn't lean more into what Andy just sort of talked about. The reality is sort of the. The copilot on top of the sim, if you will. It's cool. It's got a Big gee whiz factor to it, but it's just sort of more of the same. Okay, now I've got an agentic sim versus a not agentic sim. And it didn't sort of broaden my view of the overall security architecture or the overall security profile. And I like to sort of think about how AI is changing even the place of the SIM in the Org. Right. If you stop thinking of it as a siloed tool within security and you do AI and agents correctly, like sort of we're trying to do at strike 48, the Sim can become a whole lot more than just the place you go to throw alerts and do first pass investigations.

David Spark (28:16)

This is what I want to lead into right here. So explain what Strike 48 is doing. That is not the traditional SIM.

Tim Lahee (28:24)

Yeah, I mean, we took the sim as the starting place, but we didn't go to just agenticize it. The moment we sort of stepped into the AI micro agent agent workflow world, we started to say, hey, actually there's a whole lot more than just simple security we can do here. We can, sure, we can automate what an L1 is doing, what an L2 is doing. Root cause analysis. That's all cool. That's really phenomenal gee whiz factor. But we don't need to stop there. You can do observability workflows now. You can do an agentic knock. You can take the SIEM if you will, and stop viewing it as a siloed security tool and view it as the central hub for your sort of agentic log management, if you will, and start to try to extract all the value that the logs bring, not just the tiny little sliver of alert profile information they can give you instead. Hey, what can they tell me about my business? What can they tell me about my applications, about so on so forth?

David Spark (29:35)

So let's get into some actual hard examples because I'm having a hard time understanding, well, what can I do with all the data versus just a sliver of data? Explain.

Tim Lahee (29:43)

Yeah, so I can use a perfect example. We got involved in a company that was interested in agentixock. That is usually how we get involved. We have a SIM history. We've got this phenomenal agentic layer now. So agentic SOC is a good starting place. It took about two weeks before they were far more interested in agentic fraud management. So they are a finance organization and they use logs as a way of first pass detecting fraud in their org. Two weeks into this, we were building bots and workflows and agents to agenticize that problem. A more common example is we'll get in under agentic soc and before we know it we're talking. Because if you think about a normal NOC workflow, it's looking for some set of alerts, right? And then assessing whether the alert is valid or not and then filing some ticket in a ServiceNow or Salesforce or JIRA or whatever. That's like a layup for an agentic solution. Agents do that kind of stuff so well. But yeah, it's not the purview of the security org, right? It's an adjacent org and there are compliance use cases. In my view we should stop thinking of the SIEM as sort of this particular Gartner magic quadrant space and start to look at it as the hub for log based intelligence. And that is the agentic approach we have taken and it's really paying dividends.

David Spark (31:21)

Coming up next, how to Handle Exposure Management as a Business Continuity Discipline.

Narrator/Intro Voice (31:31)

Today's exposure management tip is sponsored by Qualys.

David Spark (31:39)

Picture this. A nationwide retailer suffers a large scale outage due to ransomware. The initial exposure was known about but had to be deprioritized because quote it wasn't critical in this attack. The exploited systems supported logistics or point of sale synchronization which are seldom prioritized as crown jewel databases and the attack shut down stores nationwide. The failure wasn't due to lack of detection, it was due to a lack of understanding around business dependency. Exposure management is more than security hygiene, it must also tackle business continuity issues in a well tuned security organization. The most mature programs don't ask how bad is this vulnerability, they ask what stops working if this gets exploited. When exposures are mapped to revenue flows, safety systems, customer trust or regulatory obligations, remediation stops being a technical argument and becomes an operational decision. This is where exposure management programs level up. Instead of chasing severity scores, teams set their priorities based on what would actually disrupt the business. This kind of shift changes executive conversations from abstract security risks to real world consequences. And this often makes the difference between fixing what's simply loud and fixing what truly matters.

Narrator/Intro Voice (33:03)

Want to go beyond exposure visibility and actually reduce risk? Find out how to by visiting qualys.com roc. Surprising research just in

David Spark (33:25)

the lone wolf is often part of a pack, but a very specific temporary kind of pack. New research presented at Black Hat 2025 analyzed over a third thousand insider threat cases revealing nearly a third involved collusion, but not the way we think. These aren't lifelong conspirators or close friends they're temporary heist crews who are there for that job, then immediately go their separate ways. Two employees with complementary access rights align just long enough to bypass controls, then they sever ties. They this creates a nightmare for detection because we're hunting for lone wolves while missing these temporary packs forming right under our noses. So, Andy, I'm going to start with you. When you catch an insider threat, how do you determine if they acted alone? And how do you start to know how deep to dig? Because this seems really tough.

Andy Ellis (34:22)

Oh, one of the very first insider cases I had to deal with was very much not a lone wolf.

David Spark (34:28)

But was it like a. Like the way they described it met and then dispersed or. It was a long term thing?

Andy Ellis (34:34)

Actually, it was worse than that. The people who started it knew what they were doing was bad and they were really careful, but they left an email to each other about how bad this was. Oh, my God, it'll ruin our employer. They'll go out of business if it ever comes out that we did this. They were just trying to basically grift off of our service in a fashion I don't want to leak sort of too much. And then one of them shared what they were doing with a friend also inside the company without all of the detail about it, without everything just like, oh, hey, here you can go do this thing. And so what happened was this small grift grew and grew and grew. And how it finally came out was a brand new employee to the company during onboarding got told by his manager, here's a perk of being an employee. You get to steal in this fashion. They didn't use the word steal, but let's just be very honest. It was a form of theft and was like, oh, totally cool. And shared it with his brother in law who shared it with the Internet. And we had a very unhappy customer who was stolen from for a lot of money. I had to go do the investigation starting from the very end from these people who'd just gotten this like, oh, they got briefed by a manager. Okay, I gotta go figure out who briefed them and then who that. So I did. And it basically was two years of communications that I went through to go back to find the original people who had done this. So absolutely, I think the myth of the complete lone wolf, I mean, the 31% surprises me. I haven't looked at this research, so that feels like a really, really big number.

David Spark (36:06)

Okay.

Andy Ellis (36:06)

But absolutely, like this idea that only one person in your company is willing to screw you over is, I think A blind spot companies might have. I think you create a lot of people who might want to screw you over and might bitch about it over coffee.

David Spark (36:21)

But I also don't get the sense that the other conspirator is technically an insider. Like it may be an insider threat and some other support.

Andy Ellis (36:31)

But I think in this one they had the 240 cases of the 313, so more than two thirds were groups of two or three employees acting in concert versus an employee with somebody outside.

David Spark (36:44)

Tim, going to you, since you have a long background in forensics, I'm sure you've seen this stuff, but have you seen these blips of oh, information was passed or there were more than one and then they disappeared and there's only one acting alone at some point, all the time. And are you able to catch that moment though where you see more than one happening?

Tim Lahee (37:05)

So in the forensics world it is almost. I was surprised. I actually thought 31 was low, to be honest. Because in forensics world it's almost always the case that if you find one, there's one or two more that are involved. They like to share. They think they're sort of getting away with something and they've outsmarted the system and they almost invariably want to share that and want to pull in at least one co conspirator. The place that I have found that not to be the case is in crimes in finance, crimes where you're altering checks or where you're altering routing numbers or stuff like that, then it's almost. In my experience, it's almost always been lone wolf, but more sophisticated, more like IP theft related things. When I roll in, I almost always expect for there to be at least one co conspirator.

Andy Ellis (38:01)

You've seen the same thing in finance and I'm very curious if that says that people who work in finance know what they're doing is wrong and are ashamed and are going to hide it or whether it says they just don't want to share.

Tim Lahee (38:12)

I feel like in the finance they know they're committing financial fraud, right?

Andy Ellis (38:17)

Yeah. There's a much higher standard and they know they're falling short of it and

Tim Lahee (38:20)

there's actual money going to wrong accounts. Right. And they're like, I'm not telling anyone. Whereas in IT or an IP they're like, I'm getting away with something but I'm going to need help to monetize this. And so let me pull in my buddy. And like I remember in the I was involved in the Bratz investigation, Mattel Bratz investigation and they literally, they had a bunch of co conspirators and they had folders that they called things to take. Do you know what I mean? And there was this whole sort of temporary pack that was robbing and then they got successful and they hired them all over and then of course the lawsuit came. But yeah, so I generally when I roll into a situation, if it's finance, I'm expecting one. If it's anything else, I'm expecting more than one.

David Spark (39:06)

Excellent. Well, that brings us to the end of the show. And so if you think you've got an insider threat problem, you've got a multiple insider threat problem according to Tim, our guest for today's episode. Thank you very much, Tim. I'm going to let you have the very last word. I want to thank your company, Strike 48. Remember, go to strike48.com security to get to test it out yourself. It's the agentic log platform without blind spots. And I'm assuming, Tim, people can reach out to you if they have questions.

Tim Lahee (39:38)

Yes, absolutely. I would love it.

David Spark (39:40)

Please make a plug for strike 48. If you have any special offer you want to give to our audience and I want to ask, are you hiring over at strike 48? Let us know.

Tim Lahee (39:48)

Yeah. So for the plug, listen, come to strike48.com I think we are doing, doing something very interesting, very unique. Not just your generic no code agent builder. We've got micro agents and workflows delivering really sophisticated IT use cases and you can play with it yourself. You don't have to believe anything I said. There's a very full functionality solution on the website. You can just sign up for an account and go to town and I think get a good sense of what we're doing and yeah, we are, absolutely. And if you're interested in being in a really exciting new AI world, send us your resume. We'd love to read it.

David Spark (40:26)

Awesome. Thank you very much, Tim. Thank you very much, Andy. And thank you to our audience. As I always say and truly, truly mean it. See, I get, I get more earnest as I talk like this. I really appreciate your contributions. And for listening to the CISO series

Narrator/Intro Voice (40:42)

podcast that wraps wraps up another episode. If you haven't subscribed to the podcast, please do. We have lots more shows on our website, cisoseries.com Please join us on Fridays for our live shows, Super Cyber Friday, our virtual meetup and cybersecurity headlines Week in review. This show thrives on your input. Go to the participate menu on our site for plenty of ways to get involved, including recording a question or a comment for the show. If you're interested in sponsoring the podcast, contact David Spark directly@Davidisoseries.com thank you for listening to the CISO Series podcast.