Mike Johnson (3:15)

I had no idea. I had no idea. That's really cool.

David Spark (3:18)

So there's my sort of footprint in tech media history. I don't think I have access to that 30 minutes because it was on it. Like, I had a copy of it on DV pro tape.

Mike Johnson (3:29)

Oh, my gosh.

David Spark (3:30)

Which I don't know if anyone who had a DV pro deck or camera wasn't digitized.

Mike Johnson (3:35)

You should get it digitized. Get it digitized if you still have it.

David Spark (3:38)

You know what? I wouldn't be surprised. I should search on YouTube. I wouldn't be surprised if someone put the first half hour of ZDTV on YouTube somewhere.

Mike Johnson (3:45)

It's probably there. Everything else is on YouTube.

David Spark (3:48)

Well, the first songs from MTV are up somewhere on YouTube. Although ZDTV doesn't have quite the legend that MTV has.

Mike Johnson (3:59)

Not. Not quite in the same category, but for certain, you know, for certain, folks.

David Spark (4:03)

Being that it's not still around and mtv is still around.

Mike Johnson (4:06)

Well, is it, though? Is MTV really still around?

David Spark (4:09)

Not what it was when we watched it back in the day.

Mike Johnson (4:13)

Yeah, there's a thing called mtv, but it's not mtv.

David Spark (4:16)

Let me tell you something. Can I tell you the moment that I knew I was turning into an old man? Here's the moment. I was watching mtv. Honest to God, these words came out of my mouth. I'm watching mtv and I said to myself, what are these stupid kids doing? I'm an old man now.

Mike Johnson (4:33)

I mean, that's basically the kids these.

David Spark (4:35)

Days that is the indicator.

Mike Johnson (4:38)

Yep, done.

David Spark (4:39)

All right, let's bring out our guest. Thrilled to have our guest. Don, good friend of yours. I know, I know. You know him very well for quite some time. He's the CISO of the SLAC national accelerator laboratory. None other than Erwin Lopez. Irwin, thank you so much for joining us.

Erwin Lopez (4:54)

Thank you for having me. It's a pleasure to be here. Good to see you both. And again, I remember the good old days of tech tv and I remember watching you. So this is a big deal for me.

Show Announcer (5:06)

Is AI going to help us or hurt us?

David Spark (5:12)

LLMs and machine learning are merely the conduit through which benefits to the customer are delivered. Justin Warren from Pivot9 tried to cut through the AI hype, highlighting the advances in cyber are incremental, such as using Copilot for documentation or Krogle for better incident response policies. But. But GitHub's MCP server was recently exploited through basic prompt poisoning. Essentially, AI makes it easy for anything good or bad to suddenly hit scale. And that's kind of the history of the Internet. So the question isn't whether AI helps or hurts, it's how do we separate those selling expensive ways to do the same old things from those actually solving valuable problems, which I don't know if expensive ways to do same old things. It might be same old things just at scale too as well. Mike. Yes.

Mike Johnson (6:06)

Yeah, I think really we're in the early days right now. This is the experimentation phase and that's really kind of where we need to live for a while. It's the same thing that we've done with cloud computing, the same thing with mobile devices. We're really experimenting right now and some of the things that we find will be step level improvements in our capabilities. The scale that you're talking about, some of these things are going to fail spectacularly. Most are going to be somewhere in there be in between huge improvements and spectacular failures. But I really think the thing that we need to get comfortable with is the idea of experimentation. It's great to call out, hey, that failed. Hey, there was a vulnerability in the GitHub MCP service. We are going to see those as time go on. But we need to not let that stop the experimentation. We need to continue to try. Otherwise we don't know how these things will be used. Like it took a long time to figure out how to use a hammer for you.

David Spark (7:08)

It took a long time, Mike.

Mike Johnson (7:10)

I hit myself like it hurt a few times when I was learning how to use a hammer. So we're kind of in the hammer stage.

David Spark (7:18)

Let's throw this to Erwin. Erwin, There are a lot of pros and cons. Yes. Interest to know if like you see yourselves creating more sandboxes to essentially uncover the pros and cons.

Erwin Lopez (7:30)

Yes, I would agree with you. Yes. I mean from our perspective, really, AI is a force multiplier. At the end of the day, it really, for us, it represents the evolution of what new security operations teams are going to be utilizing in terms of technologies, helping to not only synthesize data, looking at disparate data sets and just trying to find that needle in the haystack right but it also comes with the downside at the end of the day, right? I mean, bad guys are going to utilizing the same tools that we're trying to use against us, we open up our own ATT and CK service to new types of vulnerabilities that are out there. Just because we might not have the experience of being able to test these new AI capabilities. Right. Kind of like the GitHub MCP server and so forth. And also our user base utilizing things and entering more data than they should be entering into these public entities and so forth. So that makes it kind of hard for us. But let me share kind of a quick story about something that is near and dear to my heart. So this is not in cybersecurity realm specifically, but it has to do with disparate data sets and so forth. I'm going through some health issues and so forth, and I ended up getting recently a CT scan and a PET scan and I've been entering all my data, utilizing ChatGPT just to analyze the test results, imaging and so forth. Again at an anonymous level. I'm not entering my name or anything like that, just sheer information and so forth. And in the last PET scan that was identified, they came out and said that there was what they call an attenuation error where they found something, but when they took out the filter, it wasn't there anymore. So they labeled it as maybe system error in terms of the imaging itself. But when I ended up putting into ChatGPT, it gave me a lot of different options based on the disparate data sets that were out there. And it said, hey, you know what, there could be a blood clot somewhere in your liver. Okay. That ended up giving me the option to basically talk to my doctor and say, hey, guess what, could I get a liver mri? Which actually led to a real diagnosis that I did have a blood clot in my liver.

Mike Johnson (9:26)

Oh, wow.

Erwin Lopez (9:27)

Yeah, so this was critical for us.

David Spark (9:30)

Wow. So you used AIM LLMs to self diagnose and find something the doctor could not find.

Erwin Lopez (9:39)

Correct.

David Spark (9:40)

That's unbelievable.

Erwin Lopez (9:42)

And that was just to ask to just have the right conversation with the doctor to be able to get that test done. Otherwise I would have had to wait.

David Spark (9:48)

It and also get ahold of that data yourself. No one thinks to literally take the data from a report and stick it into a computer to give it any answer whatsoever.

Erwin Lopez (10:00)

Correct.

David Spark (10:00)

That's amazing you even thought to do that.

Erwin Lopez (10:03)

So I've been utilizing it to keep track of all of my tests from now on, you know, and I'M not saying, you know, we're not trying to go towards the Google doctor of the future or anything like that.

Mike Johnson (10:12)

Right.

Erwin Lopez (10:12)

But these are just gives us the ability to have good conversations with the doctor and openness.

David Spark (10:17)

Right. And that's a really good point to make because one of the jokes I make about using the Internet to try to self diagnose is what you use it. You really just search for things and they give you a laundry list of issues and all of a sudden your paranoia, you know, sets off, but you were taking your own data and trying to understand it, which is very, very different than the way most people use the Internet for health purposes.

Show Announcer (10:46)

Why are CISOs leaving the profession?

David Spark (10:51)

Cybersecurity is a dynamic, challenging field. But what happens when you've done it all and the biggest challenge becomes convincing your own organization to care? I got tired of convincing people on the importance of security. That's from a CISO in the cybersecurity subreddit who's tired of constantly having to sell security's value to people who don't want to hear it. I'm sure neither of you have ever run into that problem. Now, some commenters didn't want to hear it, calling it a first world problem and to retire, telling the person to retire. But other commenters gave them more grace with one saying, you will only know when you are in that situation. It's not arrogance or ignorance, it's a disappointment, frustration, identity crisis and burnout. So is CISO boredom? I don't know if I'd call it boredom, although irritation actually. The work itself. Or is it about endlessly repeating the same conversations with people who do not want to listen, Which I know is kind of a core part of the job of being a ciso. Rn, right.

Erwin Lopez (11:55)

I would agree with you. I mean, the constant need to sell security and translate risk for the business is exhausting sometimes, you know, because you're having to repeat yourself multiple times and it's just iterative scale of just the same thing over and over and over again. But I see this as only one part of the job. There's still a lot other things that really kind of motivate me personally as a ciso.

Mike Johnson (12:16)

Right.

Erwin Lopez (12:17)

Being able not only to improve the program itself, build it, right. Also stand up, maybe some a new research capability within our own team to be able to kind of harness all these new technologies that are coming up at the same time for me personally, staying connected to the technical expertise that I came from. Right. Being able to maybe at times help out on incidents When I do have time, which is rarely available, but whenever I can, I do and, you know, kind of clench that hunger that I have for that technical capability and that really what keeps me motivated to continue to move forward. But I would agree with you. I see why people are burning out because they're having to have that same conversation over and over and over again. They feel that it's not moving any forward as such.

David Spark (13:02)

All right, Mike, I know one of the things that you've said to get people to care is to make it as personal as possible. Does that always work or I'm going to assume some people still don't care.

Mike Johnson (13:13)

At the end of the day, it is our job to care about cybersecurity. That is the role that we take. And absolutely, it's frustrating to talk to people and keep telling them the same thing and keep telling them that, hey, this behavior, it's going to lead to a bad outcome. But we're not the only ones who face that. Like this is not a unique problem to cybersecurity doctors. That's very much what they're doing.

David Spark (13:41)

Oh, my dad used to complain all the time, my dad, who was a doctor, about his patients who wouldn't take their medicine. Drove him crazy.

Mike Johnson (13:49)

Exactly. And so that's the exact same thing that we're dealing with here. And so this isn't unique to cybersecurity. This is something that I understand burnout and I understand how challenging that can be to go through. But we're not going to change human nature. So we need to find our mechanisms to cope with it. We need to take a step back, take a vacation, recognize that this is just how humans are. And we need to figure out how to work with that not continuing to beat our head against the wall and being mad that people aren't doing what we tell them to. So I appreciate burnout, I appreciate that it happens. It sucks that it happens. But what I would encourage everyone to do is just some self care, figure out how to deal with it, because you're not going to change it.

David Spark (14:40)

Before we go on any further, I do want to tell you about our spectacular sponsor, and that is Threat Locker. Now let me tell you, even the most reliable employees make mistakes. You know, an unauthorized USB device or an accidental click can actually expose sensitive data and create serious risk. It can be that simple. Now traditional user based access controls rely on trust. But trust isn't security. So Threadlocker takes a different approach in securing your environment. They do it by enforcing program based policies. It ensures only approved Applications can access, read, or copy data. Sensitive files stay locked down while approved software continues to run without disruption. And when exceptions are necessary, administrators can approve them in seconds, keeping productivity high without sacrificing protection. Also with ThreatLocker, every action is logged in a detailed audit to capture the exact user file, application, and device serial number. This is actually zero trust in action. This is how it works. It's precise, it's enforceable, and it's simple to manage. Discover how ThreatLocker can help you gain more control over your environment. Just go to their website and check it out. Go to this website, threatlocker.com, easy to spell. Threatlocker.com, spelled the way it sounds. Threatlocker.com CISO do me a favor. Add the CISO. It's the simplest way to let them know that you heard about ThreatLocker from us. The CISO series threatlocker.com CISO.

Show Announcer (16:20)

It'S time to play what's Worse.

David Spark (16:25)

All right, Erwin, you know how this game is played, right? Yes. Two bad scenarios. You have to pick which one's worse. But I will make Mike answer first, and you can agree or do disagree with them. It comes from Jason Kirsted, who's currently working over at Symbian. And here are the two scenarios. Scenario number one, Mike. Okay. You find out your product team has been using an AI provider that your team did not vet. What's more, that provider just had a breach. You don't know what if any confidential data was sent to the provider, nor how they protected.

Mike Johnson (16:58)

Okay.

David Spark (16:59)

All right. So who knows what happens? That's scenario A. Scenario B, you find out your product team has rolled out your own AI feature. The bad news, you found this out because it looks like the AI was breached through a prompt injection attack. You don't know yet what if any confidential data was exposed. All right. I want to point out that usually you go for the thing that you know more about, but in both cases, you don't know what what was exposed. So you can't lean on that Mike for this one.

Mike Johnson (17:31)

At the same time, it's all relative, right?

David Spark (17:34)

Yes.

Mike Johnson (17:35)

So one is just again, to make sure that I understand the scenario and to also think it through. One is your company is using a third party LLM.

David Spark (17:45)

Correct. And you don't know how data is being handled.

Mike Johnson (17:48)

People are sending something to it.

David Spark (17:49)

Yes.

Mike Johnson (17:50)

And then a breach happened and Correct. So on and so forth. The other is you've developed one yourself.

David Spark (17:55)

Right.

Mike Johnson (17:57)

And it has been breached, and you don't know what's been exposed.

David Spark (18:02)

It's more or less breach within your four walls or outside of your four walls.

Mike Johnson (18:05)

Exactly. And so the way that I think about this is what is the potential reputation impact of this? Again, bad scenarios, like great examples, Jason, like these both suck. But if I think about it's somebody else's breach or it's my breach, while the data might be the same, the reputation impact is going to be greater if it's my breach. And that's what makes the headlines is my company is breached versus this other company was breached.

David Spark (18:39)

Now, let me also. I think there's a good argument against that too. Erwin, do you agree or disagree with Mike?

Erwin Lopez (18:45)

I agree to a certain point. I think there's a little bit more to it. Specifically given the fact that if it's my breach, it could lead to other nefarious activities like lateral movement and so forth, depending on what the capabilities were for the LLM and how it was cordoned off. So one could be worse than the other.

David Spark (19:03)

Well, hold it now. I'm going to throw this out. If it's your breach, yes, that's a reputation impact. But at the same time, it's your four walls, you conceivably could manage it better. If it's outside of your four walls, it's out of your hands. Who the heck knows? Or you could look at it. It's a breach. A breach. It's out of our hands anyways here.

Mike Johnson (19:23)

Well, again, if we're back to we don't know what data is within either.

David Spark (19:27)

Right. In both situations.

Mike Johnson (19:30)

In both situations, then the impact to data is the same at the end of the day because it's basically everything for all that, you know. But I really think Erwin makes a really great point and it's not one that I thought of. If it's within your own four walls, it could be even greater than just the prompt injection because it could spread within your environment and become an even bigger breach than just the information that the LLM had access to.

David Spark (20:00)

Good point. So agreement, but disagreement on how bad it is, I think is what it is. But you come to agree with them now? I was just thinking we've been doing what's worse scenarios for more than seven years. Have you actually had an incident in the last seven years that mimicked one of the what's worse scenarios we've had?

Mike Johnson (20:20)

I can't think of any.

David Spark (20:22)

I know it'd be hard to catalog, you know, because there's been literally hundreds of them.

Mike Johnson (20:26)

Yeah, there's literally hundreds of what's worse that we've been through. But part of that is because these tend to intentionally be extreme.

David Spark (20:34)

Although every now and then we get one who goes, oh, yeah, this happens all the time. Kind of a thing like, yeah, and.

Mike Johnson (20:39)

Those are the ones that are more likely, but the majority of them are intentionally extreme so that we can really have a nuanced debate. Because if one is extreme and the other one isn't, then it becomes easy. So.

David Spark (20:55)

Yes, well, that's true. That's the thing. If you send them in, by the way, please send in more what's worse scenarios. We're always looking for good ones, please. Yeah, you're always looking back. And they could be balanced week long or balanced extreme. They don't have to both be extreme. Two balanced, quote, weak ones. I'm using that relative is also still a very good what's worse scenario.

Mike Johnson (21:16)

Yeah, I think those are actually the ones that make us squirm more because it's. Oh, that hits a little bit too close to home. That actually could happen. Now we have to have a real debate about it versus the extremes.

David Spark (21:28)

Erwin, in times that you've listened, have you ever heard of what's worse scenario? And goes, yep, that happened to me in the past.

Erwin Lopez (21:35)

Yes.

David Spark (21:36)

Can you recall anything?

Erwin Lopez (21:37)

Not at the top of my head, but I remember, I think a few times that it actually kind of came up that I was like, oh, great. Yeah, I think we've gone through that. I mean, we've all gone through big incidents in the past where somebody's clicked on something and things moved laterally as such and took us a little bit of time to. To identify before we actually ended remediating.

David Spark (21:58)

So I remember years ago, Mike, we had a scenario that a woman sent in that was an actual incident that she dealt with, and they were faced with two issues, and one of them was letting the attacker keep going on so the FBI could track them. And the other one was to shut them down to stop the bleeding. And it was one of those what's worse scenarios. And I would love it if our audience have some of these locked and ready to send to us. But it was one of those what's worse scenarios where I could tell the answer to the story at the end. Like, you got to pick which one to go with. And I said, and the end of the story is this. And by the way, the end of the story in that case was they did let the attacker go on so the FBI could track them. And I remember you and Sunil, you was on that and you gave each other a High five. Because we recorded in my house. I remember that.

Mike Johnson (22:54)

Well, you've got a better memory than I do, David, but absolutely, absolutely. That is something that if ever you're dealing with a real adversary, that is a decision you have to make.

David Spark (23:05)

It's a tough one. I mean, like, that's a real one you don't want them to keep. But, I mean, I will just say, I'm sure that hurts. By the way, Andy Ellis had a similar experience where he was working with the FBI. He had an adversary that was working for him. He had to keep putting him on the payroll so the FBI could track him. But it's even worse. Yep, that's painful that you got to look at the person every day.

Mike Johnson (23:28)

Yeah.

David Spark (23:30)

Oh, that's. By the way, that's a serious poker face you need to hold on to.

Mike Johnson (23:35)

I don't want to play poker with Andy.

Show Announcer (23:39)

Once again, we've got identity issues.

David Spark (23:45)

Quote, threat actors aren't hacking in anymore. They're logging in. That's by Tom Etheridge from CrowdStrike in a recent CSO online piece. By the way, he's not the first one to say that. Many have said that, but we've heard it many times. Yet attackers can establish a foothold and start moving laterally through networks before most secure teams even know they're there. That is a major problem. So traditional static defenses like regular passwords and perimeter firewalls just aren't effective as they used to be. If attackers are walking through the front door with stolen credentials. What's the new playbook look like, Erwin?

Erwin Lopez (24:26)

So we use the assume breach high fidelity surveillance to start out with. I mean, basically we understand that the traditional hardened perimeter, where hardencrussing on the outside, soft and chew on the inside no longer works.

David Spark (24:40)

Right.

Erwin Lopez (24:40)

I mean, basically bad guys are coming in fairly simple. So utilizing a multi factor authentication that's phish resistant, utilizing our specific tool sets internally to be able to identify. So like for example, our EDR capability plus identity protection and our honeypots that we have set up to kind of detect that lateral movement as such are things that are really kind of come to help us quite a bit. In addition to that, having our specific business rule sets that we have set up to identify abnormal behavior from users is something that we have been concentrating on for the last couple of years. But again, it's really the focus has now become the insight. And how do we protect from a zero trust capability? Right? Assume basically breach, verify everything that's going on from the inside itself.

David Spark (25:31)

All right, Mike, I throw it to you? It seems this kind of new playbook is not so new anymore. It's pretty well known. Yes.

Mike Johnson (25:40)

All right. There's basically these actors out there that they're called initial access brokers. And all they do is go around and collect credentials. They collect credentials, they collect session tokens, what have you, and then they sell them. And that's been going on for years now. And there have been so many breaches who've happened because of somebody bought a credential from one of these. So this is not at all new.

David Spark (26:07)

By the way, are those initial access brokers, are they ever taken down? Because it seems they're very much removed from the actual attack.

Mike Johnson (26:16)

They are usually somebody who has a strain of malware that they've managed to get spreading. And quite often those particular types of malware will be taken down.

David Spark (26:27)

Well, more I was thinking like cybercrime is kind of a low risk, high reward type venture. But I was thinking people who are in that aspect of cybercrimes selling the credentials are often probably kind of removed from any sort of, I guess, criminal prosecution. Yes or no? I don't know.

Mike Johnson (26:48)

I don't think they're the ones that law enforcement goes after first.

David Spark (26:51)

No, but it would just be a good. This is like going to the source.

Mike Johnson (26:55)

Yes.

David Spark (26:55)

Let's find out who's making the drugs. Let's start with them, then getting the dealer on the street.

Mike Johnson (27:01)

How do you deal with your precursors rather than the actual drug manufacturers themselves? There have absolutely been some takedowns of them.

David Spark (27:09)

Okay, all right.

Mike Johnson (27:09)

But I think they are generally harder to get to.

David Spark (27:14)

I would assume so, for the exact.

Mike Johnson (27:15)

Reason that you're saying is they're not the ones who are doing the actions on objectives and therefore they're not as loud and as visible to law enforcement and leaving as much of a trail.

Show Announcer (27:29)

Are we creating more problems?

David Spark (27:34)

We build, we bond, and we can't bear to let go. That's a good summation of the IKEA effect from Steve Thompson of TJX companies. We tend to overvalue things we've created ourselves, even to our detriment. Ross Halle Luke of Venture and Security noted that security professionals often fall in love with their custom siem rules, soar playbooks and detection logic they spend months crafting even when better off the shelf solutions emerge. Thompson lived this firsthand, spending three years trying to move his organization off a creaking on prem splunk deployment. The problem was the emotional investment in all those custom configurations made change feel impossible. Letting go felt like admitting Their work was worthless. So, Mike, as someone I know who likes to engineer first, you are very much in a build yourself when it comes to build versus buy. How do you determine when you need to reevaluate your decision to build? And have you ever ripped out something you and your team spent forever developing?

Mike Johnson (28:42)

Absolutely. You have to make the reasoned decision of in a build versus buy scenario, I'm not going to go and write my own edr. That doesn't make a whole lot of sense. But at the same time, there are other areas where I get value. That it is first build the thing, and then that pays off for years down the road. And those are the ones where we make the. Yeah, we should go build this scenario.

David Spark (29:09)

No, but have you literally taken something down that you built yourself?

Mike Johnson (29:13)

Oh, yeah. You have to. You have to say, hey, this thing is outlived its usefulness.

David Spark (29:18)

And does it hurt? No, because it's like you watch your child grow up and like, oh, okay.

Mike Johnson (29:23)

Well, so you mentioned Sunil Yu earlier.

David Spark (29:26)

Yeah.

Mike Johnson (29:26)

And years ago, he introduced me to this term of pets versus cattle.

David Spark (29:33)

We did this on our show. I think he reintroduced to both of us at the same time on the show.

Mike Johnson (29:37)

Yes. And that's something that has always stuck with me. And these things that we go and build internally, we have to think of them as cattle. When they outlive their usefulness, it's time to move on. We shouldn't be attached to them.

David Spark (29:52)

I think the term you want to use is slaughter.

Mike Johnson (29:55)

I did not want to use that term. But going back to the scenario of the rules within Splunk, that's not an example of build. That is an example of lock in to a vendor that you bought. Like, that is actually one of the downsides of buy, that you have to go into those decisions being very clear on. If those rules had been written in a portable fashion that were easy to move on, they wouldn't have been stuck on that on prem splunk environment. So sometimes buy actually is the one that's more difficult to move on from than a build scenario.

David Spark (30:36)

All right, Erwin, I'm sure you faced this problem yourself. And did you ever feel pain getting rid of something you and your team built?

Erwin Lopez (30:45)

Sometimes it's hard. I mean, I'll be honest. You've put a lot of love and emotion and time into this. Right. I mean, these are solutions that have gone through battle scars, right. From past incidents, business intelligence, you've added to it and so forth. And then when it really starts to become a problem is when you start to have to pay the maintenance tax on it? How long is it taking to upgrade or keep up? What is the total cost of ownership of this? And then lastly, do we have a single point of failure, meaning how many people are actually managing the system? Do we only have one person or two people? And that's really where for us, we make that decision to say, okay, well, maybe it might be time for us to look at an external solution that we might be able to basically move our rule sets and so forth. But during that timeframe, it can be very painful. And I've had lots of experience going through that.

David Spark (31:39)

And I want to talk about this just in general about rip and replace, because I was having this conversation over at Black Hat. We've all faced a moment of rip and replacement, and you see a better solution. But sometimes you think to yourself, is it really that much better? Would it really make it? And you sort of hold out. You hold out and then you realize the sort of the getting better and how bad is sort of that gap is widening even more. And you're like, okay, well, now we have to do it. And then you also have the fear of making that leap because you know how much work it's going to take to do it. But once you get onto the other side, you've done the work, you get to the other side, you. You've replaced the thing that was kludgy that wasn't allowing you to do it. You look back and you think, why didn't I do this earlier? Yes. Irwin, have you had that feeling? Well, we have.

Erwin Lopez (32:28)

We have there been times that, you know, we've gone through it. I mean, good example, we had a great SIM capability that we had created that we had gone through. You know, that it's gone through multiple different iterations. And we've basically kept that up for years. And just because it was just. It took a lot to keep this up and running, we ended up moving into, for example, a splunk capability.

Mike Johnson (32:48)

Right.

Erwin Lopez (32:48)

That made a lot easier.

Mike Johnson (32:49)

Right.

Erwin Lopez (32:50)

And gave us greater visibility to be able to not only search, but also utilize it as a preseum tool.

David Spark (32:56)

Well, excellent. Well, that brings us to the very end of this episode. I want to thank you. Irwin Lopez, who's the CISO over at the SLAC National Accelerator Laboratory, joined us. That was fantastic. Erwin, we love to have you back again.

Erwin Lopez (33:09)

I'd love to be back. And again, thank you for the invitation.

David Spark (33:12)

Of course. And Mike, thanks for making the introduction to Irwin as well. And I want to thank our sponsor that would be Threat Locker. They've been a phenomenal sponsor the ciso series delivering zero trust in action. Remember, go to their website threatlocker.com CISO remember to add that/ciso easiest way to let them know that you found out about Threat Locker from the CISO series. Thank you again Mike. Thank you Erwin and thank you to our audience. We greatly appreciate your contributions. Keep them coming more what's Worse Scenarios and listening to the CISO series that.

Show Announcer (33:46)

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.