Hero culture is still distressingly common in cybersecurity. While it’s good to have people you can count on when the going gets tough, building up heroes inherently creates single points of failure. How can we build resilience across our entire staff?
This week’s episode is hosted by me, David Spark, producer of CISO Series and Andy Ellis, principal of Duha. Joining us is our sponsored guest, Rob Allen, chief product officer, ThreatLocker.
Got feedback? Join the conversation on LinkedIn.
Huge thanks to our sponsor, ThreatLocker
ThreatLocker makes Zero Trust practical. With Default Deny, Ringfencing, and Elevation Control, CISOs get real control that’s easy to manage and built to scale. Stop threats before they execute and reduce operational noise without adding complexity. See how simple prevention can be at ThreatLocker.com/CISO.
Security tip of the week – Qualys
Jump to the full tip here.
Head over to qualys.com to learn more.
Full Transcript
Intro
0:00.000
[Voiceover] Best advice for a CISO, go!
[Rob Allen] I’ve got two pieces of best advice for a CISO. One, listen to this podcast. It’s essential. Two, buy ThreatLocker. It’s equally essential.
[Voiceover] It’s time to begin the CISO Series Podcast.
[David Spark] Welcome to the CISO Series Podcast. My name is David Spark, I’m the producer of the CISO Series. And my co-host for this episode, I know you all love him. He’s the principal over at Duha. It’s none other than Andy Ellis. Andy, say hello to the audience.
[Andy Ellis] Hey, folks, and happy springtime.
[David Spark] Happy springtime it is. We are available all year round, 24-7, 365 at CISOseries.com, except when the site goes down, but that doesn’t happen. The site is fine.
[Andy Ellis] Only when your AWS fails or something.
[David Spark] Yeah. Something like that. It used to be problems, but we have some protections in place that we did not have before. So, things are much, much better now. Go check out all of our shows. Our sponsor for today’s episode, a spectacular sponsor of the CISO Series.
We love having them. It’s none other than ThreatLocker. Allow what you need. Block everything else by default, including ransomware and rogue code. That is ThreatLocker. We’ll have lots of new cool things to tell you about ThreatLocker a little bit later in the show.
But Andy, before we were on mic, we were talking about the whole buying process, and I just want to set this up, and this I’ve learned through my whole life. People can say yes a thousand times, but they only need to say no once, and that is one of the things that I’ve learned.
People can string you along, string you along, string you along with yes, yes, yes, yes, and it only comes down to a single no can end everything, and that is a sad reality of life. You’ve run into this, yes?
[Andy Ellis] I absolutely have. And organizationally, the challenge sometimes is the person who’s talking to the vendor doesn’t have buying authority, so they’ll say yes. All through this process, they bring a vendor in, they string them along. They’re excited because they think that all they have to do is prove this would be incremental value and money will magically appear.
[David Spark] And by the way, people like to say yes because you’re happy, they’re happy, everyone’s happy.
[Andy Ellis] Right. It’s non-confrontational. And then all of a sudden, the vendor sends over the contract. It’s like, “We did the proof of concept or proof of value. We hit all the milestones that we wrote for you, and now we would like you to pay us.” And then the CISO gets involved and the CISO’s like, “What are you talking about?” So, this is my advice for you as a vendor is ask the question, “Hey, assuming that we pass technical validation, we’ve succeeded the POV, what does the purchasing process look like?
Who needs to sign off on it?” And then the second thing, if you are a CISO and you have people on your team who are doing this, you need to have serious conversations with them because they’re seriously damaging your brand.
[David Spark] Yeah. You don’t want misalignment of someone saying, “Yes, we’ll buy,” when the person who does have purchasing authority’s saying, “No, we’re not buying. You don’t need that.” Because…
[Andy Ellis] Or it just wasn’t in the budget yet.
[David Spark] And Andy, you say, you’ve seen this a lot. You’ve been stuck in the middle of these things and you’re trying to…
[Andy Ellis] Yeah. I’ll get a call from a vendor that I know that I’ve either invested in or advised, and they’re like, “Hey, this process seems to have gone astray. I see you know the CISO. Can you just have a back channel call? And I’ll reach out to the CISO.” And sometimes they’re even surprised there’s a contract.
They’re like, “I haven’t seen a contract. There shouldn’t be one issued. This isn’t in the budget for right now. Like, I knew my guy was off investigating this area.” And so, the mismatch is all often happening inside the company. It’s not between the company and the vendor, but the vendor ends up burning a lot of resources trying to land a deal that’s never going to happen.
[Rob Allen] Can I just add a small programming note?
[David Spark] That is Rob Allen. Please jump in, yes.
[Rob Allen] Yeah, no, there was you as a vendor referenced in that last conversation, and I just want to say that that wasn’t me as a vendor. [Laughter]
[David Spark] No, it was definitely not Rob. And in fact, let me introduce Rob. Rob has been a frequent sponsor guest with the CISO Series. We love ThreatLocker. We love Rob, even with all the gentle, kindhearted abuse that Rob gives me. And in fact, that’s a running joke that we have.
But for those of you who don’t know him, he is the chief…
[Rob Allen] Abuse is such a strong word.
[Andy Ellis] He’s just like a hedgehog. If you read him the wrong way, it doesn’t feel so comfortable.
[Rob Allen] [Laughter]
[David Spark] A hedgehog?! Why are you insulting him?
[Rob Allen] Yes. Like if you give me grief about my audio setup or you say I’m a little hot there or I can’t hear you, then I prickle.
[David Spark] We have some sound bites of Rob that could be great extortion material, essentially.
[Laughter]
[Rob Allen] You wouldn’t dream of it.
[David Spark] Rob is the chief product officer over ThreatLocker. Everyone, please welcome Rob Allen. Rob, we love having you back. Thank you for coming back.
[Rob Allen] It’s a pleasure to be here, David.
If you haven’t made this mistake, you’re not in security.
5:03.036
[David Spark] “The insider threat isn’t always malicious. Sometimes it’s your best employee.” Joshua Copeland of Crescendo argues that the most dangerous insider threat is often the person who keeps things running. This is the key thing we’re talking about here.
They’re effective and rewarded for it, but access expands, oversight shrinks, documentation becomes optional, and eventually nobody knows what they – you know, the person who keeps things running – has access to, including them sometimes. When they make a mistake or burn out, the blast radius is massive and you realize you didn’t have resilience, you had dependency.
As Copeland puts it, “If your culture celebrates heroics over repeatable process, you are quietly manufacturing insider risk.” I like that quote.
So, herein lies the rub – there are critical people doing critical jobs that desperately need redundancy and double-checks. Andy, how do you build those safeguards without killing the thing that made them heroes in the first place? Or does building up this kind of hero culture always introduce risk?
I like this take. What’s your take on this?
[Andy Ellis] So, I 90% agree with Joshua here. The one caveat I want to say is I dislike using the term insider threat to talk about this great employee here. If you must use the insider threat, it’s their management, not the employee, right? There is a hazard, which is the over-reliance.
[David Spark] So, you’re manufacturing hazardous environments, not insider threat.
[Andy Ellis] Right. You’re manufacturing hazardous environments and the hazard is this single point of failure, which is often an amazing employee who basically like whenever there’s an issue and you’re like, “Well, to fix this will take five engineers four months,” and you’ve got this superhero who walks in and solves it over the weekend with a tool that only they know how to use.
And this happens a lot in companies, and one of the big challenges is they don’t bother making their tools usable by other people because they have been burned by spending that energy before, but nobody ever uses their tool anyway. So, why would they invest energy in trying to make it halfway safe when nobody’s going to meet them the other half of the way, right?
You’re not willing to invest the operations and QA and software development resources. They’re, of course, going to be incentivized to do the least amount of work to solve the problem because any work they do above that has no value, and they’re making the right choice.
So, pause on that one and think about what should this person do differently? What you should do differently as a manager is you should force the issue. First of all, this person probably is not happy maintaining all of these processes and tools that they keep building.
They want people to take it away from them, but in a graceful way. So, hire somebody whose job is you’re going to back up this person. Every time they build a new tool, you’ll go in, you’ll learn how to use it. You’ll write the documentation. You’ll operationalize it.
Also force the person to take vacation.
[David Spark] Mm-hmm.
[Andy Ellis] I had one of these employees on my team. He got engaged and he let us know over a year in advance. He’s like, “This is the day I’m getting married and I’m taking a honeymoon and I don’t want to be contacted.” So, we said, “Okay, we’ll start sending you on free vacations.
We’re not going to pay for your vacation, but it’s free vacation time, and the first time you go out, we want you to have your cell phone and your laptop handy. And we’re trying not to call you, but any call, the first thing you’re going to do is call your manager and say, “Hey, I need somebody to document what I’m doing.” The next time you go on vacation, you don’t have your laptop.
You can only talk to people through issues. The next time? No phone. And we just kept progressing…
[David Spark] Ah.
[Andy Ellis] …until we felt confident this person could be gone for the two weeks of their honeymoon without us needing to call them. And we actually managed to build a whole bunch of stable processes around the problems this person had solved.
[David Spark] So, that’s interesting. You sort of stepped yourself through sort of weaning yourself off of the hero.
[Andy Ellis] Right. Because we were the problem, not them. The culture is the problem, not the person who is solving your problems.
[David Spark] I love that. All right, Rob, I’ve actually met many of the people over there at ThreatLocker and actually kind of the theme of your company is this sort of hero theme, but hero can have a negative backlash when the hero’s not available.
Like, I don’t know, you put up the bat signal and Batman’s not available. So, what can you do to sort of – as you say, it’s not an insider threat, it’s a culture issue – what can you do and have you done to sort of deal with this issue?
[Rob Allen] Well, first of all, I’m going to surprise you, David, because I’m going to agree wholeheartedly with both Joshua and Andy.
[David Spark] Okay.
[Rob Allen] So, that may come as a surprise to you. And the other thing I would say is, yes, we very much do embrace cyber heroes. Our support team are Cyber Heroes. I mean, effectively, we are all cyber heroes. I think maybe one hero is not a good thing. Many heroes is a good thing.
[David Spark] Yes.
[Rob Allen] Might be a good way of looking at it because as Andy said, dependency on one individual is not good in any environment. And obviously, burnout is one thing, just is somebody available is something else. But I, as I said, cannot disagree with that in any way, shape, or form.
So, not having one hero and instead having many heroes like the Cyber Heroes could be the opposite of not a good thing.
[Andy Ellis] I know I really like that take because there’s this way of looking at organizational maturity, right? Like the capability maturities model that SEI uses, where you see like level one is hero culture. And the real problem we have is organizations that think they’re level three but are not, and so it’s only held up by a couple of level one heroes who are showing up and saving you from the fact that your processes don’t actually work.
If you’re entirely a level one organization, that actually can be very healthy for your organization. It has a lot of downside risk. No stability. If all of a sudden half your people leave, training up new people is really hard. There’s huge issues.
But if what you’ve got is a lot of heroes, that’s great. As you move up level two and level three, what you want is a consistent level of heroism, where when there’s a problem, people will swarm on fix it but then maintain it at the level your organization’s supposed to be.
Having one person you rely on to patch your organization, that’s the real problem.
[David Spark] Well, and I also think, I think what you have, Rob, with ThreatLocker is quite unusual that you can have so many sort of top tier people because not only that, you also train them too. You have like a training program for them.
[Rob Allen] Absolutely.
[David Spark] But I’ve actually worked, very early on, I worked in an organization, there was definitely one guy who was keeping the house of cards together. When he’s not available, we were all screwed. And sadly, and I’m sure you’ve seen it, there are many organizations like that.
Yes?
[Rob Allen] Undoubtedly. I mean, look, I’ve got examples I can think of in my head. I mean, we’ve got a guy who’s now our director of infrastructure, incredibly clever guy, absolutely incredible. I mean, he basically talked me through setting up a data center in Dublin in 2021 in the height of COVID, like pretty much talked me through it.
[David Spark] Mm-hmm.
[Rob Allen] Guy’s an absolute genius. And at that point, if you’d told me that we would have a team of six or seven or eight infrastructure people who basically you can go to just as confidently as you can go to him then, I wouldn’t have believed you.
But it takes time. It takes effort. As you said, it takes training as well, it’s super important. It takes having trust in people as well. It’s for people like me to not only go to the main guy in the department, to go to any of the other people who are there as well and have the same level of confidence in them as I would in him to be able to do the thing that I’m looking for them to do.
So, there is a lot to it, but as I said, from my perspective, having been with the company for the length of time I have been, seeing that development from one guy who’s basically going to fix everything or sort everything out to me to there being any number of people I can go to if that one guy isn’t available is invaluable and phenomenal.
What works? What’s not working?
13:13.359
[David Spark] “Fifty-seven percent of significant cyber incidents involve attacks the cybersecurity team has not prepared for.” So, that’s according to the Cytactic 2025 State of Cyber Incident Response Management Report. So, in a CSO Online piece, Evan Schuman argues we over-index on dramatic breaches instead of the subtle lateral movement attackers actually use, while many organizations run tabletops once a year purely as a compliance checkbox.
There’s always inherent randomness in attacks that no tabletop can fully predict. Cybersecurity is not alone. The military teaches the same principle. We’ve heard this again and again, that tabletops reveal the communications and approvals structure.
So, here’s my thought on this, Rob. Should we just be quizzing our staff on that, on who do you go to in an incident, in this instance or this case, rather than relying so heavily on trying to guess the next big or small attack? Like should we just like reflex reaction just know the communication structure?
Because it seems that’s kind of the core of everything here. Yes or no on my theory?
[Rob Allen] Well, I’m going to surprise you now. I’m going to revert to type.
[David Spark] Okay.
[Rob Allen] Which is the 57%. I’m really interested in that 57% of cyber incidents involving attacks that cybersecurity had not prepared for. I would wager that 100% of cyber attacks involve…
[David Spark] [Laughter]
[Rob Allen] …attacks that the cybersecurity team had not prepared for. But anyway, that’s beside the point. Look, tabletops in some instances do have value, and it’s not something that I would completely rule out. I mean, we had something similar ourselves not too long ago from a risk management perspective, and a couple of things were brought up, and it basically made our CTO not sleep for a couple of nights because he realized, “Oh, this is something that we really need to concern ourselves with, and this is how we solve it.”
So, there is certainly value to that kind of exercise in that, I mean, as with many things, if you get clever people together talking about potential outcomes and what can happen, then good ideas will invariably fall out of that. So, there is value to that, and I wouldn’t say that organizations should not do that.
But as you said, proper planning involves more than just, well, if this happens, then we do that because realistically, that’s probably not going to take care of every eventuality. I mean, there’s been so many good examples of organizations who have a ransomware response plan, and the ransomware response plan is stored in somewhere that just got ransomwared.
So, what do we then do?
[David Spark] But the thing is shouldn’t you know who the next call needs to make? Like, “I now know this, I need to talk to somebody. I don’t know who to talk to.” Like, shouldn’t that be the plan that everybody knows, just who the next person to talk to?
[Andy Ellis] So, I think, David, that we’re in sort of two different places here.
[David Spark] Okay.
[Andy Ellis] And first of all, you’re absolutely correct. If you’re doing incident response, having a generic incident response plan, like here is how we respond to incidents, is basically like you’ve got to do this, right? And everybody who’s done one incident, the first thing they’ll do is, “Okay, I have to write down who I’m supposed to call.” And over time, you’ll evolve that, you’ll grow it.
So, that’s like table stakes, and I think that’s one of the reasons Rob wasn’t really responsive to that is I think we all assume that exists. Like, if you have not done that, you shouldn’t be worrying about scenarios. You should be worrying about who do I call.
[David Spark] But I hear again and again, the reason for the tabletop is to figure that out, I hear it all the time. A lot of people don’t know that until they do the tabletop.
[Andy Ellis] Well, if you’ve never done a tabletop, you don’t know what you don’t know.
[David Spark] Mm-hmm.
[Andy Ellis] Like, it’s nice for you to say, “Oh, who’s the next person you call?” My incident response template when I was a CISO was 90 pages.
[David Spark] Yikes.
[Andy Ellis] Right? But we are not always referencing it, and we actually got to a point that you literally had a person whose job was to keep track of the template that is separate from the person running the incident because they would be the ones who’d have to remember something like, “Oh, someone mentioned PII, which means we now have to call these seven other people.” Because it’s not just one person.
Like I’ve got to go call somebody in my investor relations team, which is not something most people have thought about until it comes up. Because if I’m going to have to disclose a breach, then I need the IR team to be prepared for what happens after a breach gets disclosed.
So, yes, this is necessary.
If you don’t have any incident response plan, go run a tabletop simply because it will teach you that you don’t know anything, and there’s a lot of things that are obvious. Often better, get somebody who’s done this before to come in and at least give you that starter.
I think the real question here is 57%, it’s a scenario they hadn’t practiced. I can argue that one in either way. One of the challenges of surveys is they’re very vague, and so people are going to answer that one differently. Like was this that we had a scenario and there was one component that exposed a hazard we hadn’t known about?
Like, “Oh, we practiced ransomware, but we didn’t practice ransomware that started with we had one machine in our network that was not running the coolest anti-ransomware vendor that’s out there.” Maybe that’s the scenario that we didn’t bother practicing, but that’s what actually hit us.
[Rob Allen] Can I just say, Andy, kudos for the low-level Donald Rumsfeld reference there with the known unknowns and things we know and things we don’t know.
[Andy Ellis] [Laughter] Yeah.
[Rob Allen] And by the way, David, you did also quote the IRA earlier in the episode.
[David Spark] What did I say?
[Rob Allen] It was the thousands of things, or sorry, thousands of yeses and one no. It only takes one no.
[David Spark] Oh, that’s an IRA quote?
[Andy Ellis] Yeah.
[Rob Allen] Yeah, they…
[Andy Ellis] I mean, it’s a standard quote that the IRA definitely did use a lot.
[Rob Allen] I think the IRA, you’ll find the IRA were first. It was when they tried to blow up Maggie Thatcher in 1984. They said, “We only have to be lucky once. You have to be lucky every time.”
[David Spark] Yeah.
[Rob Allen] And it’s very applicable from a cybersecurity perspective as well.
Sponsor – ThreatLocker
19:26.709
[David Spark] Before I go on any further, I do want to tell you about our spectacular sponsor, and that would be who? ThreatLocker. Yes. Now, most security tools assume a very simple model. Just let everything run and just try to catch what goes wrong.
The problem is attackers already know that model. ThreatLocker flips the script with a deny-by-default approach that gives organizations control over what can run, what can access data, and what can elevate privileges before an attack happens. Instead of chasing alerts after malware executes, ThreatLocker helps teams define what should be allowed in their environment and blocks everything else by default.
Now that includes applications, scripts, DLLs, and even which apps are allowed to access sensitive data, all without relying on signatures or behavioral guessing.
Now for CISOs, this means fewer unknowns, fewer emergency escalations, and a security posture that’s based on certainty, not detection hope. ThreatLocker is used by organizations that want to reduce attack surface without breaking the business – through visibility-first deployment, stage enforcement, and real human support.If you’re rethinking endpoint security, ransomware resilience, or least privilege, ThreatLocker is worth a serious look.
It’s time to play “What’s Worse?”
20:44.442
[David Spark] All right, we all know how to play the “What’s Worse?” game. Andy’s going to answer first. Rob, you’re either going to agree or disagree. This comes from one of our absolute favorite contributors, Dr. Dustin Sachs, who has a new company called PsyberCog Labs, and here is his two scenarios.
This is a short one. What is worse, a board that only wants a yes or no answer to the question, “Are we secure?” or a board that wants deep technical detail and then misinterprets all of it? [Laughter] This is a good one.
[Andy Ellis] Man, Dustin, that’s a really good one. I like that. Because the challenge of the first one is that they’re really just trying to create a scapegoat here, right?
[David Spark] Mm-hmm.
[Andy Ellis] They want you to be on record saying, “Of course we’re secure,” or they want you to say no, in which case you’ve just created this internal disaster. Like, why are you the CISO? Like, the CEO’s going to be yelling at you. Like, your career is being sabotaged.
By the way, just as an aside, if you get asked that question…
[David Spark] And I remember years ago asking you this question on camera.
[Andy Ellis] Yeah. The common variant of this is like is there enough budget? Is security getting the right prioritization? And you want to be able to hedge, you want to say, “Yeah, kind of.” The correct answer is, “Look, we could always do more, but I’m sure all of my peers believe they could also do more with increased prioritization and budget.” And there, we always have to make the trade-off as to, are we over-investing on security versus sales?
Because we want to ensure there’s still a revenue flow, and that’s really the context in which I operate. Some variant of that.
So, now let’s take that second one of the board that wants you to go into detail, and is going to just completely misinterpret things. Honestly, I think that one gives you more opportunity. It’s a bad scenario, just to be very clear, because now you’re going to be dealing with the fact that the CEO’s going to come to you and be like, “Hey, this board member said this thing, and why did you make them believe that?” And now you’re going to have to deal with those kerfuffles.
But at some point, you actually become a benefit to the rest of the company. If your board is doing that to you, they’re probably doing it to other parts of the business as well. And so, if you can take some of that distraction away from the marketing team, away from the head of revenue, you might be able to serve your company better there.
I’m not saying this is a good outcome. I’m merely saying that there’s…
[David Spark] But at least it’s more revealed, and you’re not the scapegoat in this case.
[Andy Ellis] Right. You’re not the scapegoat here. It’s not simplistic. You’re going to get them very involved with you, and you might find allies among the other executive suite who are like, “Oh, thank God that they’re abusing you this quarter because last quarter that was me.”
[David Spark] And also, when you did do the technical dive, at least you were saying some accurate information.
[Andy Ellis] Right. You were saying accurate things because remember, you’re not just presenting to the board, you’re presenting to all the other executives who are in the room and who helped you review. And so, as long as you maintain that level of honesty there, you’ll build some sympathy.
So, these both are problematic, but I would say the first one is worse because nobody’s actually engaged on cybersecurity in that company.
[David Spark] All right. This is a tough one. Rob, I throw it to you. Do you agree or disagree with Andy? Same or different reasons? What’s your thoughts?
[Rob Allen] I agree wholeheartedly with Andy…
[David Spark] Okay.
[Rob Allen] …it will surprise you to hear. No, look, as he said, both are not great.
[David Spark] [Laughter] Politely saying it.
[Rob Allen] But the second option is definitely the least bad. Detail is good, even if that detail is going to be misinterpreted because at least you can then educate. You’re opening a conversation, rather than just yes or no, which is basically the end of a conversation.
[David Spark] Hold it. Let me just throw in this shoehorn here.
[Rob Allen] Uh-oh.
[David Spark] The board is making decisions.
[Andy Ellis] The board does not make decisions. You’re wrong, David. Sorry.
[David Spark] Okay.
[Andy Ellis] I got to step in here.
[David Spark] They’re misinterpreting, but then they’re approving things. They’re approving things, aren’t they?
[Andy Ellis] No, no. And every CISO needs to understand this. The job of your board is two things. There’s only two things the board does, and one of them is not run the company.
[David Spark] I know that. They do not make decisions.
[Andy Ellis] What the board does, number one, ensure proper governance is in place. They represent the shareholders. Their job is to evaluate, is management doing okay or not? That’s it. They don’t tell management what to do. Now, they might tell the CEO, “Hey, that CISO’s a loser, fire them,” but they don’t have hire/fire authority.
That’s up to the CEO. The second thing they do is ensure there is a CEO succession plan. That’s it. That’s the only thing boards do. They may provide advice, they may provide help. But you are not trying to get the board to make decisions about how you do security.
That is the fastest way to finding the door on your way out.
[David Spark] Okay. So, that makes a good point. So, here’s my question. Would your answer change, and I’m sorry that I cut you off, but would your answer change if it wasn’t the board that wants technical detail, but the C-suite that wants deep technical detail?
Would that change?
[Rob Allen] Okay. Andy’s nodding very much here. [Laughter]
[Andy Ellis] I would much rather, if this is my CEO who basically controls my budget, I would much rather have them ask a very simple question and let me go run my security program than attempt to micromanage it wrongly because they have management authority.
[David Spark] Yeah.
[Rob Allen] And again, I don’t disagree with that, but I still think the yes or no question is a time bomb. The yes or no question is a trap.
[Andy Ellis] Oh, it’s a time bomb, but the other one’s a bomb.
[David Spark] Yeah.
[Rob Allen] Well, possibly, possibly. But again, I’m all for transparency, I’m all for conversation, I’m all for discussion rather than, as I said, a yes or no is the end of a conversation. Well, mind you, a no is probably the beginning of a much bigger conversation, but realistically speaking, who’s going to say, “No, we’re not secure, I’m the CISO”?
Because the answer is going to be, “What the hell are you doing then? Why do I employ you?”
[David Spark] All right, so we have agreement here in both cases.
Please, enough! No, more!
26:54.290
[David Spark] We’ve seen a rush of companies looking to integrate AI into security solutions, leading some to wonder if we’re already starting to overtrust the value of AI. I would say a big fat yes to that. Andy, when it comes to AI being integrated into cybersecurity, everybody’s doing it, whether you like it or not, but what have you heard enough about with AI integration, and what would you like to hear a lot more?
[Andy Ellis] So, when I think about AI, I think about three different areas, and most people only think of one of these, right? And the three areas are functionally data analytics pattern matching. Can I figure out if this is an adversary by just looking at a lot of data?
We’ve been doing machine learning in that space for a long time. People stopped talking about it. Really key, I want to hear a little bit more about that. The second thing that we hear a lot about, which is the generative AI, which is, oh, I have a prompt, which might be some data, might be other things, generate for me an answer.
I’m tired of hearing about that, and here’s the reason why.
The third thing we need to be talking about is repeatable automations. I do not want to have a generative AI taking the same set of inputs and providing me unpredictable outputs. If the problem that I have is ransomware is on this machine, I should have a playbook of things we’re going to go now do.
I want that playbook followed every single time. I’m tired of hearing about how, “Oh, we’re just going to use LLMs everywhere to solve everything.” Like maybe you have an LLM, write the playbook, but now you should have a playbook that is repeatable and automatable that does not involve generating new outcomes until you get to the end of it.
[David Spark] All right. Very good. I throw this now to you, Rob. What have you heard enough about with AI integration in security tools specifically, and what would you like to hear a lot more?
[Rob Allen] I mean, if I’m brutally honest here, David, I think the words AI in general, in terms of security, is something that does somewhat grind my gears.
[David Spark] Mm-hmm.
[Rob Allen] Primarily because of the overuse and the fact that everything and everyone seems to now think that they must be AI powered or infused by AI. It is quite tiring. The last place we met in person was RSA, and you literally could not take 10 steps at RSA without being accosted by some…
[David Spark] Same with Black Hat.
[Rob Allen] Yeah, monstrous booth with something-something AI plastered all over it.
[David Spark] Andy, didn’t you count the booths that didn’t have AI in them or something?
[Andy Ellis] I did, in fact, count everything. So, at Black Hat of the 359 booths I saw, 85 of them had the word AI on them, 26 said agent. So, I mean, it wasn’t like everybody, but…
[David Spark] It was a lot.
[Andy Ellis] That’s still like 30%.
[Rob Allen] That’s less than I would have expected, quite frankly, because I would have expected it to be 90% because that was my perception.
[David Spark] So, it’s over-indexing on it, but you know what? The way I see it is you go back many years ago when everyone was moving to the cloud, and they led with the concept of the cloud. Nobody really leads with the cloud now. I mean, it’s kind of assumed most of us are in the cloud of some sort.
[Andy Ellis] I hope so.
[David Spark] Yes, hope so. So, I see kind of a similar transition that everyone’s going to be using it just like they’re using electricity at some point. Yes, Rob?
[Rob Allen] Hmm, perhaps. I’m going to sit on the fence slightly about that one.
[David Spark] Okay.
[Rob Allen] I mean, look, we have a fairly simple way of looking at it. And again, to Andy’s point that there are absolutely uses of AI that are extremely valuable. So, taking large amounts of data and finding conclusions from them is a perfectly valid and perfectly reasonable and perfectly useful way of using it.
Where we draw the line fundamentally is having AI making decisions on the fly about what’s good or what’s bad because invariably some of those decisions are going to be wrong. And to our point from earlier about bad guys only having to be lucky once, it only takes one wrong decision about something’s goodness or badness for it to be game over for any organization.
That’s where we kind of draw the line. I mean, there are very limited areas within our platform that we use AI. So, we use it for like website classification and stuff, for things we’ve never seen before. But in terms of actual decisions about what’s good and what’s bad, that is not something we would countenance.
Now, the reason for that is quite simple, which is because our approach is to block by default, so we don’t need to make decisions on the fly about whether something’s good or something’s bad. If we see something we’d never seen before, it’s just going to get blocked.
It’s going to get denied. We don’t need to figure out if it’s good or it’s bad. So, we don’t need AI to inform decisions. Our decision by default is block.
So, that is one of the benefits of the approach that we take is we’re not dependent on making AI or anything else making decisions on our behalf. It’s very binary decisions. It’s yes or no. Is it explicitly allowed? Cool. Off you go. If it’s not, no.
But yeah, it’s a long-winded way of saying that there are certain uses that are perfectly valid and absolutely should be encouraged, and there are some uses which because of the approach that we take, we don’t feel that we need to do.
Security tip of the week – Qualys
32:12.355
[David Spark] Coming up next, can you measure your time to exposure, not just time to remediation?
[Voiceover] Today’s exposure management tip is sponsored by Qualys.
[David Spark] Several major cloud breaches in the past started with misconfigurations introduced during routine deployments that sometimes remained exposed for weeks. Post-incident reviews revealed that patch SLAs were met, but the exposure itself wasn’t detected quickly enough.
The breach window existed not because fixes were slow, but because exposure awareness lagged behind operational change.
Most organizations obsess over how fast they can fix vulnerabilities, but not many of them measure how fast new exposures are created. Cloud changes, identity sprawl, SaaS integrations, and configuration drift often introduce risk faster than teams can remediate it.
Mature exposure management programs track time to exposure, taking the time to identify a vulnerability and then stepping back to determine the likelihood of it being exploitable within the company, along with the options that exist to monitor the situation and remediate, as necessary.
The next step, material exploitability, applies an even longer lens, monitoring an exploited vulnerability to the point where it uncovers a material exploitability that can do sufficient damage. The key is to not just react to symptoms, but instead focus resources where exploitability is real, not theoretical.
[Voiceover] Want to go beyond exposure visibility and actually reduce risk? Find out how by visiting qualys.com/ROC.
Unexpected outcomes or failures?
34:07.703
[David Spark] “Seventy percent of employees admit to bypassing security controls, not out of malice, but simply to get their jobs done more efficiently.” Dr. Dustin Sachs of PsyberCog, the one who gave us our “What’s Worse?” scenario – PsyberCog Labs, actually – he shared that stat on a CISO Tradecraft blog post arguing we’ve spent decades treating cybersecurity as a technical problem when it’s really a behavioral one.
Security leaders must meet people where they are rather than forcing compliance. For instance, don’t make developers sit and watch SAST/DAST tests run, automate them in the background so results are ready when they return – being the developers. His, Dustin’s, six recommendations focus on auditing for friction rather than just compliance, harnessing neurodiversity as a security asset, and aligning talent to natural behaviors.
What’s wrong with our security programs or compliance in general if nearly three quarters of employees are bypassing security controls, Andy? It sounds like blaming the audience is no longer the answer here. What have we screwed up?
[Andy Ellis] So, I agree with the premise, but I would actually frame it the exact opposite way, which is we have been treating cybersecurity like a behavioral problem instead of a technical problem, right?
[David Spark] Okay.
[Andy Ellis] We have been treating humans as if they’re eusocial insects, like that there’s a bee at the top and all the other bees do exactly what they’re told to do. They follow all directions. That is technically not how humans operate. And so, you tried to assume that you could institute an organization that was rigid, would absolutely follow rules.
That’s not a behavioral problem. That’s a technical problem. Your policy doesn’t work. Your organization doesn’t work because the elements are what the elements are. There’s nothing wrong with humans. There’s a reason we are the dominant species on the planet and not bees.
Stop trying to build your security controls for bees. This is a different way of framing the same problem Dustin sees.
Just to be very clear, I’m not in fundamental disagreement about his recommendations. I am saying you can’t say this is a behavioral problem because behavior is what it is. You’re not going to adjust it. The moment you talk about a behavioral problem, you think you can solve for the humans.
Stop trying to solve the humans and solve the actual problems. And his recommendations, some of these are fantastic, but stop trying to say we’re just going to do security awareness training and get ourselves out of this because security awareness training is an anti-Goldilocks solution.
It is the worst of all possible worlds. It tells the security team, “Hey, we did our job. We did the bare bones minimum to tell people.” It tells the people, “Hey, we did our job. We sat there for 30 minutes, and we clicked a couple of links and now we’re golden,” and you have actually made the problem worse because everybody thinks the problem should be better, but it’s not going to be.
It’s kind of like consumer recycling. Like we make people sort their recycling in their home, despite the fact that it provides no meaningful benefit, and we’d be way better off with single stream recycling systems. But instead we’re doing stupid things, blaming the users.
Stop blaming the users. That’s because you’re treating it like a behavioral problem. It’s a technical problem if your systems just don’t work right.
[David Spark] Interesting take, taking in reverse that we should solve many of these things that we’re solving behaviorally through technical solutions. What do you see, Rob?
[Rob Allen] I’m sort of intrigued. I’m actually looking at this question again, and I think there may be a comma missing between security controls and not out of malice. Because the question as presented is 70% of employees admit to bypassing security controls not out of malice.
Does that mean that 30% are bypassing security controls out of malice?
[David Spark] [Laughter]
[Rob Allen] I don’t know. I’m wondering who those 30% are.
[Andy Ellis] Well, I think it’s at 70. I think that 70% admit to bypassing security controls.
[David Spark] Period.
[Andy Ellis] That’s the statement.
[David Spark] Yeah. Yeah.
[Andy Ellis] Not out of malice.
[Rob Allen] Okay. That’s fine. Yes. As I said, there is, there’s a comma missing there.
[Andy Ellis] But I like that, you know, Dustin be a little more precise or whoever copied and pasted this for us.
[Rob Allen] Commas matter. Let’s eat, grandma and let’s eat grandma are…
[Andy Ellis] Are slightly different.
[Rob Allen] …two very different things. Sorry, I got completely distracted by that.
[Andy Ellis] Nerd sniping Rob.
[Rob Allen] [Laughter] I am a pedant. I confess. So, yeah, so three quarters of employees are bypassing security controls. I mean, to be honest, it’s not a tremendous surprise. As Andy said, I mean, employee training is the least good solution to that problem because it doesn’t matter how well you train people, they’re still going to click on that link.
[David Spark] Yes.
[Andy Ellis] Well, to be clear, clicking links is what we pay people to do.
[David Spark] Right.
[Andy Ellis] The moment you try to say… Actually, technically, clicking links is how they get paid because if they didn’t click the link from HR or finance, they’re not getting paid.
[Rob Allen] Yeah. And it’s always going to fall down. I mean, I don’t know if I gave this example before, but it was a kind of impromptu exercise at one point where Danny Jenkins, our CEO, posted a link to our general team’s chat, basically saying, “Hey, everybody, need you to download and run this thing right now.” Now, we’re a really well-trained, really well-educated cybersecurity company.
We do quarterly training. “Everybody, don’t do this. Don’t do that. Don’t click on the link. Don’t do whatever.” And still nearly 20% of our company clicked on that file and tried to run it because ostensibly Danny, our CEO, had said they needed to do so.
[David Spark] Mm-hmm.
[Andy Ellis] So, here’s my question, though, for you because I want to dig in on this one.
[Rob Allen] Yes.
[Andy Ellis] It was on your internal Microsoft Teams chat from his legitimate account?
[Rob Allen] Yes.
[Andy Ellis] Okay, so why did 80% of the people not comply with the request from management?
[Rob Allen] Um…
[Andy Ellis] That’s your, “No, no.” Like, this is the problem, which is there is no good choice for an employee to make here. Either do what management asks you to do…
[Laughter]
[Andy Ellis] …or don’t do what management asks you to do.
[Rob Allen] Those people who know Danny would know the things that Danny wants to be done to be done. So, there’s a valid argument.
[Andy Ellis] Right. We want to test this new thing we just deployed and we’re testing it with ThreatLocker, and we don’t want to have to push it out. This is completely legitimate. Here’s the thing.
[Rob Allen] Yeah.
[Andy Ellis] This is because we don’t treat it like a technical problem. Why is clicking links unsafe? Solve that problem. Don’t solve that users click links.
[Rob Allen] Well, the interesting thing was that even though, as I said, 20% of our organization clicked on the thing, tried to download it, tried to run it, none of them were able to do so because ThreatLocker blocked it. Because, again, blocking things is what we do.
[Andy Ellis] Right. So, those 20% should all get bonuses of some form. They should all be recognized.
[David Spark] [Laughter]
[Andy Ellis] They did what Danny did in a safe environment.
[Rob Allen] Yeah. Well, now, how did they know it was Danny that was saying it?
[David Spark] Oh, by the way, you know what’s happening right now? Someone is pulling that quote of yours and sending it to Danny. That’s what’s happened.
[Rob Allen] Oh, yeah, 100%. Undoubtedly, yeah.
[Andy Ellis] No. They get to trust. You have deployed a secure chat environment, at least we hope Microsoft Teams is remotely secure.
[Rob Allen] Now, there is a big “but” in this, which is that first of all, Danny’s not always sitting at his desk, Danny’s not always in the office. Danny is very often on stage. What Danny will do invariably when he’s on stage is he will take his phone and he’ll leave it down somewhere or he’ll give it to somebody, say, “Hold on to that.”
[Andy Ellis] Yep.
[Rob Allen] So, there is no guarantee that the person who has just posted this thing to download this thing is actually Danny. It may have come from his phone, but that doesn’t mean it was him that posted it.
[Andy Ellis] I’m just going to say it was a safe environment to follow what Danny said to do. They acted safely and with alacrity. Now, if somebody reached out to Danny and said, “Hey, Danny, is this really you?” They should like get extra kudos.
[David Spark] Yes.
[Rob Allen] Absolutely. So, confirmation would have been a very…
[David Spark] But you can’t have the entire staff reaching out to [Laughter] Danny and asking you that very question.
[Andy Ellis] Yes, but again, I just think this was…
[Andy Ellis] Yeah, reach out to your best and say, “Hey,” like there’s lots of ways to solve that one. But this is one of the things that just gets me, which is either we’re going to use electronic communications to run our organizations or we’re not.
We can’t selectively say, “Oh, when security didn’t like that you did it, then you did something inappropriate.” But if Danny is always telling people what to do over Microsoft Teams, then the one time we want to retroactively say, “Well, maybe you shouldn’t have listened then,” it’s BS.
[David Spark] But hold it. No, but maybe… Hold on. Let me clarify. So, maybe what Danny’s communication should be is everybody should log into their Teams account with no link in the email. And we know that Danny doesn’t put things, I mean, I’m just suggesting something here.
[Andy Ellis] Yeah. If you want to make that the standard. Look, we did things like that. Like I had got our marketing team to stop giving out USB drives to new hires so that we could say, “Stop using USBs. We will never give you a USB drive. We don’t want you to stick one into anything.” We made that the norm, and that’s fine.
But you can’t say that the norm is not follow instructions from senior management that come through the company’s communication channel only when there’s a security issue.
[David Spark] All right. I need Rob to close this up.
[Rob Allen] I know, but to that point, Andy, saying that whatever our chosen communications method is is assumed to be secure is a recipe for failure, I’m sorry, and that there is no confirmation involved is how your accounts department sending a half a million dollars to Timbuktu because they got a Teams message from Danny saying they should do so.
[Andy Ellis] It’s either trustworthy or it’s not. Be consistent on that is all I’m asking, which is if every time they get asked to do a thing, they’re supposed to challenge it, then that’s fine.
[Rob Allen] That’s fair. That’s fair.
[David Spark] Have we come…
[Rob Allen] David, you expect me to disagree?
[David Spark] Disagree.
[Rob Allen] I’m not.
[Andy Ellis] Good job, Dustin, on this one because like…
[Rob Allen] In this particular circumstance, it wasn’t a “this is something that happens all the time.” It was an out of the blue. It was a, “Hey, everybody run this, please.” As a test. It wasn’t, as I said, something that would often happen. So, I mean, realistically speaking, from my perspective, it’s the 80% of people.
[David Spark] No, but I think what happened sounds like you learned something from it, didn’t you? It sounds like, yeah.
[Rob Allen] Oh, absolutely. Yeah. It was tremendously illustrative.
[David Spark] Yes.
[Rob Allen] And again, I’m not quite sure about the 80% should be rewarded. I think I might disagree with Andy on that.
[David Spark] First of all, it all depends on the culture that you’re building at your company and how you…
[Andy Ellis] Right.
[David Spark] Exactly. All right. So, all that 80%, they can contact Andy, and he’ll give you a bonus. Correct, Andy?
[Andy Ellis] I will say you did an amazing job. And yeah, actually, if ThreatLocker will give me budget authority…
[David Spark] [Laughter]
[Andy Ellis] …to spend bonus money, then I will absolutely pass on a bonus.
[David Spark] Well, our audience can go ahead and work on that if they would like to, and all the ThreatLocker employees listening can work on that as well.
Closing
45:13.792
[David Spark] We’ve come to the end of our show, and I want to thank Andy, and I want to thank Rob, and I want to thank ThreatLocker. Remember, you can go to their website, ThreatLocker.com/CISO. Throw in the /CISO. Just do me that favor. It’s an easy way to let them know that you heard about them through the CISO Series.
Just go to ThreatLocker.com/CISO. But remember, ThreatLocker, allow what you need, block everything else by default, including ransomware and rogue code. More about that, ThreatLocker.com/CISO. Please go check it out. Andy, as always, thank you so much.
And Rob, I’m going to ask you a question I ask, and I think I already know the answer to it is are you hiring over there at ThreatLocker?
[Rob Allen] We are very much and always hiring over at ThreatLocker.
[David Spark] Especially if you live near Orlando, in or near Orlando?
[Rob Allen] Not only, but mostly if you live in Orlando, yes, or the surrounding areas or would like to live in Orlando.
[David Spark] Not a bad place to be.
[Rob Allen] It’s not a bad place to be.
[Andy Ellis] Except in July and August. [Laughter]
[Rob Allen] But yeah, it’s not great for golf in high summer. I will completely agree on that. But at this time of the year, March, April, it is beautiful around here. So, as one who has moved to Orlando and very much likes Orlando, it is a great place to be, and ThreatLocker’s a great place to work.
So, yes, we are hiring. We’re always hiring. We have just moved into a much bigger building than we were in previously. So, we’ve got lots of room for new people now, and we are hiring furiously to try and fill that room.
[David Spark] Do you have any events coming up related to hiring at ThreatLocker?
[Rob Allen] It’s funny you should mention it, Dave. We absolutely do. We’ve got a hiring event on site here in Orlando, April the 15th.
[David Spark] Ah.
[Rob Allen] I’m sure there will be information about it on our website, ThreatLocker.com/careers. So, yeah, anybody who is in the area, we’ve had phenomenal success with these hiring events heretofore. We do them pretty much every month or two months, and it’s been incredibly successful.
So, yeah, April the 15th here in Orlando, keep an eye out on our careers page and you’ll probably get information and details about it. I think if you’re driving around Orlando, you will also probably see billboards everywhere to that effect, too, because we found that that’s a really useful way of getting people’s attention and getting to come to said hiring events.
So, yeah, April 15th in Orlando. Come along.
[David Spark] Excellent. Thank you very much, Rob. Thank you very much, Andy. Thank you so much, ThreatLocker. And thank you, our audience. We greatly appreciate your contributions and for listening to the CISO Series Podcast.
[Voiceover] That 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 Cyber Security 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 at David@CISOseries.com.
Thank you for listening to the CISO Series Podcast.