In our hurry to embrace LLMs and agents, we seem to be repeating all the same mistakes we made when we rushed to the cloud. While there are no lack of startups looking to fill this security void, threat actors aren’t waiting for the next procurement cycle to take advantage. So how can we keep infrastructure secure in this interim?
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, Danny Jenkins, CEO, ThreatLocker.
Join the conversation on LinkedIn.
Huge thanks to our sponsor, ThreatLocker
verifies both user and device before granting access to specific applications. No broad
access, nothing exposed, and no reliance on credentials alone. It’s a smarter way to
control access and reduce risk. Learn more at ThreatLocker.com/CISO.
Full transcript
Intro
0:00.000
[Voiceover] What I love about cyber security, go!
[Danny Jenkins] I love winning. I love it when we manage to stop something, stop a hack, or really, really annoy somebody on a server who’s trying to take over a system. I just love winning.
[Voiceover] It’s time to begin the CISO Series Podcast.
[David Spark] Welcome to the CISO Series Podcast. My name is David Spark. I am the producer of the CISO Series. And joining me as my cohost, it’s Andy Ellis, the principal over at Duha. Andy, say hello to the audience.
[Andy Ellis] Good afternoon, folks. Or depending on when you are in the world, good morning, good evening, or goodnight.
[David Spark] We are available at ciso-dev.davidspark.dcgws.com, where you can find lots of our other wonderful programming. We have four other shows on our network. Why not explore and listen to some other wonderful programming?
[Andy Ellis] Because this is the best program.
[David Spark] At this very moment while people are listening, this is exactly what they should be listening to, nothing else.
[Andy Ellis] Yeah, only when you’re done can you go listen to the other ones.
[David Spark] Our sponsor for today’s episode, a phenomenal supporter of the CSIO Series… We adore them. They adore us. It’s a mutual love and appreciation for each other. It is Threatlocker. Meet the world’s leading zero trust platform. Allow what you need, block everything else by default including ransomware and rogue code.
That is Threatlocker. We’re going to be talking more about the cool stuff they’re doing. You’re going to want to listen to that a little bit later in the show. But before I introduce our guest, who is from Threatlocker, Andy and I just saw each other in Boston because we did a live show in Boston, which will be airing actually shortly after this episode.
And the reason I coordinated this, Andy…and I think I told you…is because I went to my high school reunion.
[Andy Ellis] That’s right, folks. If you want to sponsor a live show, all you have to do is figure out where David wants to be.
[David Spark] That helps. But this was all sort of coordinated back in November of last year. But I hadn’t stepped on campus since I was 18 years old.
[Andy Ellis] Oh, goodness.
[David Spark] I went to an all boys prep school in Boston. And I think what’s interesting… First of all, have you attended a college or a high school reunion yourself, Andy?
[Andy Ellis] Nope.
[David Spark] None?
[Andy Ellis] Nope. I left and have not been back. I mean I’ve been back on my college campus because it’s right down the street, but I didn’t do the reunions.
[David Spark] Well, I think what happens when you don’t see people for decades, the game becomes, “Who has fallen apart most?”
[Laughter]
[David Spark] And it’s just like, “Wow, I didn’t think that was going to happen to you,” kind of thing. But then there’s some people who keep it together, and it’s great.
[Andy Ellis] You know, what I think I love best about this is all the winning, David.
[David Spark] Yeah, it goes back to the winning thing. So, that becomes quite amusing. Like, “Wow, well, you were an athlete at one point. I guess that things have changed.”
[Andy Ellis] Just a little bit.
[David Spark] Anyways, it was thrilling to see everybody, but it was just sort of a shock when you don’t see people for that long. Because people change after they turn 18, I’ve noticed. It does happen.
[Andy Ellis] Just a little bit. I hope. I hope that people change after they turn 18. Let’s put it that way.
[David Spark] I would hope so. And slightly mature.
[Andy Ellis] Yes.
[David Spark] All right, let’s get to today’s show at hand, because we’re not going to be talking about my reunion. If someone wants to call and talk to me or talk to or email me about my reunion, happy to chat with them about that later. But let’s not waste any more time here.
It’s a guest we’ve had on many times before. We adore him. He supports us. We support them. It is the CEO of Threatlocker, our sponsored guest, Danny Jenkins. Danny, thank you so much for coming back.
[Danny Jenkins] Thank you for inviting me today.
Once again, we’ve got identity issues
3:52.284
[David Spark] “Authorization is not the same as appropriateness.” Apurv Garg tries to cut through the “identity is the perimeter” consensus. He points out that IAM, identity access management, can confirm an agent was allowed to access a system, query something like a salary database, and join it with performance reviews, but it can’t tell you whether it should have.
Agents need broad standing permissions to function at all, access patterns we’d never grant a human employee (or at least never admit to doing). So, I’m going to start with you, Andy. If least privilege breaks agentic workflows… And we’re talking about agentic workflows versus actual happens as identities… What does appropriate access governance even look like?
And how do you enforce policy against behavior you can’t predict in advance? Because agents don’t have predictable behaviors, do they?
[Andy Ellis] Well, humans don’t have predictable behavior. Let’s actually start from that problem.
[David Spark] Well, more than agents I would say.
[Andy Ellis] No, no, no, actually, I think agents are more predictable than humans.
[David Spark] Okay.
[Andy Ellis] Agents will take all of the permissions they have and go use them. The human challenge is humans don’t use more of their permissions because we give people way too broad permissions because we don’t understand what people do. The core of the problem is we don’t actually govern identity or authorization, however you want to look at that.
What we do is we sort of say like, “Oh, Danny has just come into the organization. Let’s just clone somebody else’s permissions and give them to Danny.” Nobody actually knows what Danny’s job is going to do. He changes from one organization to another, so we leave all of his old permissions there while he goes over, in case he gets called.
And over the course of 15 years at a company, Danny ends up with access to everything, but he’s never using it. Then Danny goes and deploys an agent, and the agent is like, “Oh, I have access to these things, and I could probably use that in answering some question, so I’m going to grab access to everything.” And that’s just a key piece of it, which is the thing we’ve never solved, which is governance over what people do because we don’t know what they do.
Authorization and permissioning is just the shadow reflection of what the business needs the person to do, but we don’t understand that. So, instead, we treat it like the ground truth. We give it lots. And then agents just abuse it. So, this is not me saying this problem isn’t worse.
This is me saying this has always actually been the worst problem we have, now it’s just gotten even worse.
[David Spark] Danny, part of the core philosophy at Threatlocker is this default deny approach. And by default, you limit privileges. Yes? Or just limit a lot of things beyond just privileges.
[Danny Jenkins] So, I think it’s really about allowing what you need and nothing else.
[Andy Ellis] Right.
[Danny Jenkins] And humans, obviously they tend to collect privilege over time, you’re right. And one of the things we often do is look at those and say, “Here is a privilege that hasn’t been used for three years. This shouldn’t be here anymore because it’s not currently being used.” The problem with agents is not they’re more or less predictable.
The problem with agents is they’re much, much faster at causing chaos. And a human, if they start stealing data or uploading data to the internet, they tend to do it quite slowly. Or if they decide they’re going to delete something, they tend to do it quite slowly, and you have some kind of chance of detecting it before it becomes bad.
Agents do it very, very quickly. And sometimes very wrongly.
[David Spark] Well, then how then does the least privileged behavior or the way you’re monitoring it, if you’re dealing with agents that are moving at a much faster speed than humans…how does this change? How does speed come into the equation I guess is my question?
[Danny Jenkins] So, I think the first thing is, just like a human, you have to start off… People have given agents more power than humans in many cases. And if you look at some of these AI tools, they’re just asking for absolutely everything out of the box.
And we shouldn’t be doing that. We should be saying, “Why does this need this permission? Why does it need access to these files? Why does it need access to the internet? What does it need access to on the internet?” So, that’s step one. And then the second step is checking what you have given access to and just reviewing it again periodically to say, “Is there still a valid reason for this agent to get access?” Part of the problem with agents as well is there’s no accountability.
So, as a human, if I hire somebody, and I bring them into my business, and they do something wrong, there is a consequence for doing something wrong. Now, the consequence may be worse for the business than it is for the individual. But in most cases, if they intentionally steal data, upload something to the internet, they’re going to go to jail, they’re going to get fired.
Something like that. With agents, they can just do things without any consequences, so you have to almost put more constraints around it. Because what you have is the most…
[David Spark] And also, the agent itself…you should also throw in there…the agent itself doesn’t have a conscience, so it’s not stopping itself or regulating itself.
[Danny Jenkins] No, it doesn’t have any conscience. It cannot be stopped. It cannot be reasoned with. And it will do whatever it thinks is the appropriate thing to do. And that could be deleting a database. It could be uploading files to the internet.
It could be encrypting files.
What about this AI security challenge?
9:21.480
[David Spark] “We just deployed more attack surface in 12 months than we built in the previous decade.” After seeing a surfeit of MCP servers with no authentication and a bevy of malicious skills in the LLM marketplaces in just a month, Caleb Sima of White Rabbit has a simple diagnosis, we’re repeating the cloud mistake.
But this makes me wonder if this is a mistake, or just the pattern? New technology deploys. Businesses wait to see if it sticks. Once it does, startups scramble to build solutions, buyers spend months evaluating vendors who are barely less green than they are.
So, meanwhile attackers don’t wait for procurement cycles. By the way, this sounds like the whole cyber security industry. So, I’m going to ask you, Danny, first. How should security leaders think about protecting infrastructure when the vendor ecosystem securing it doesn’t yet exist?
Or is as nascent as they are?
[Danny Jenkins] So, I don’t necessarily think it doesn’t exist. I think the problem is is the way we’ve looked at security for the last three decades is about finding a threat and responding to that threat. That is definitely part of security. But the reality is even when we think about going back to the early 2000s, you’ve got an email service, they were all open relay because we came up with this great technology, email.
We all wanted to make it as simple as possible, so you’d put an SMTP server on the internet, and you could allow it to send email to anyone. Very, very quickly people started abusing the service. And then we created these lists of bad email servers, and we’d start listing them on it.
And then eventually people stopped leaving their servers as open relays.
And today, if you see an open relay, it’s very, very rare. I think the problem is we go out and say, “Let’s open up this technology to the whole world.” And we want to do it as fast and simple as possible. And that is the patent. Like, “How do I get it as fast and simple as possible?” The security mechanisms haven’t really changed that much.
Blocking things, only allowing what you need… It hasn’t changed. But what happens in the interim is we stuff it with this detection and response to try and allow us to move faster. And then we go back and ultimately come to this realization, “Oh, we shouldn’t have open relays on the internet.
We do need usernames and passwords on our accounts. We do need dual factor authentication.” And in the meantime, we were just, “Oh, let’s just throw it out there with nothing. Then let’s put some security. Then let’s put some detection and response around it.
And then let’s put some real security where it’s actually affective.”
[David Spark] All right, Andy, I want to throw this to you. Do you think what we’re seeing with AI is really just an echo of what we’ve seen when new sort of technologies rise, and we’re not kind of prepared for it? Or is this a very different structural change?
[Andy Ellis] No, no, so I absolutely think this is exactly what happened with cloud. It’s what happened with internet. It’s what happened with web. And it is not a mistake. So, sorry, Caleb, I have to disagree with you very strongly. And if Caleb wants to make me agree with him, he can take me out to dinner because his wife is a fantastic cook, if you have not gone to eat at Fang.
[David Spark] It is a great restaurant.
[Andy Ellis] I did for the first time this year at RSA, and I will happily go back.
[David Spark] So, wait a second. Let me just pause there. So, the new way of engaging with Caleb is to essentially taunt him to take you to his wife’s restaurant.
[Andy Ellis] Yes, absolutely. I’m going to give that a try. It might work. So, Caleb, if you’re listening, we can argue over this at dinner. But at a high level, this is how business operates, which is a new disruptive technology comes along. Either because a previous one tanked and the space was there, or the new one is sufficiently better that people are just going to go adopt it.
This still goes back to the car. The automobile was a disruptive technology. People adopted it. And yeah, there were people complaining about, “Oh, these are not horses, and they’re going to be different.” The mistake that we make as security professionals is that we wait until the business moves, and we kvetch [Phonetic 00:13:36] about it.
And we say, “Oh, you shouldn’t move until you engage with us.” That’s never going to happen. They’re going to move. So, either you have fundamental controls in place that will be helpful in that world, or you’re playing catch up.
That’s basically your two choices. Now, conveniently, when people moved to the web and started to do ecommerce in the early days, there were people who came and helped him, and those were the folks who became the first chief information security officers.
We’re the people who got out ahead of it. So, if you want to advance your career, you should be out ahead of AI, and you should be figuring out how you’re going to help your marketing team use AI better and more safely. Because what I’m seeing at more and more companies is you have these very lean, agile marketing teams.
Sometimes only one person doing the work of six or seven. And they’re using AI for everything. So, if you’re just screaming, “No, no, no,” you can’t do it, that’s the failure mode.
[David Spark] Let me throw this back to you. I’m just kind of shifting gears a little bit, Danny. How have your staff just in terms of running Threatlocker in general…how have you guys been embracing AI?
[Danny Jenkins] So, I think there’s a few different areas. And first, there’s the business usage side of AI. We’re talking about vulnerabilities, and things are about to get much worse with these new AI models coming out. Cyber security is going to…watershed moment.
Things are going to get bad but not nearly as fast and quick enough, but AI is also helping solve those problems. I mean, we have hundreds of thousands of lines of code, and we constantly do reviews. We have security teams. We have peer reviews. But at the end of the day, even after all of that, we can throw a piece of code into an AI model and say, “Tell me potential vulnerabilities in this code,” and it will find things that the smartest people haven’t found.
Because it can look faster and quicker, and it helps you move forward as a business. We also use it in various parts of our product.
Whether it’s…and interestingly enough, is reclassifying or validating a website categorization. In the old days, we would have machine learning, and key word analysis, and image analysis to determine the type of website you’re going to. And by the way, it’s still more accurate than AI today.
But with 96% of sites classified as explicit, correctly classified, when you’re using keywords. When you use AI, it’s like 70% classified. When you combine together, you could actually get 99 point something percent accuracy. Whereas before, you could 95.
People often think AI is maybe the better technology, but sometimes it’s just supportive technology. And then, of course, we have in some respect the benefit of attacks increasing, malware increasing, phishing attacks increasing, phishing attacks getting properly written in English now.
And that allows us to deliver good security tools. So, obviously as a company we also get to benefit from, “Hey, we’re selling the shield here. We’re selling the solution.”
Sponsor – Threatlocker
16:34.892
[David Spark] Threatlocker is extending zero trust beyond end point control. With the recent release of zero trust network access and zero trust cloud access, organizations can now control how users connect to both internal systems and cloud applications.
Access isn’t based on credentials alone. It requires the right user, the right device, and the right conditions. Users are granted access only to specific applications, never entire networks or environments. Now, that matters because attackers aren’t breaking in, they’re logging in.
We’ve heard this plenty, yes. As we’ve seen in recent large scale, CRM breaches, stolen credentials, and missed configurations can expose massive amounts of sensitive data. Threatlocker’s zero trust network access ensure internal resources are never exposed and only reachable through tightly controlled policies.
Zero trust control access extends those same protections to SaaS applications. So, even if credentials are compromised, access is denied without an appropriate device. It’s a modern approach to access controls that reduces attack surface and stops unauthorized access before it even starts.
You can learn more and start your free trial today over at threatlocker.com/ciso. Do that, threatlocker.com/ciso. And do me a favor – add that /ciso. Easiest way to let Threatlocker know you heard about them through the CISO Series.
It’s time to play “What’s Worse?”
18:06.416
[David Spark] Danny, I know you’re aware of this game. You’ve played this game. I always stress that I like it when people disagree with Andy, but I make Andy answer first so you can agree or disagree. This one is an interesting one, Andy. We haven’t had one like this before, I don’t think.
So, get ready.
[Andy Ellis] Ooh.
[David Spark] It comes from Cary Johnson of Phishbusters. And here’s the scenario. Two scenarios, I’m sorry. You have metrics that show improvement, but you cannot prove why. So, it’s showing something is good, but you have no clue how it happened. Or you have metrics that show no improvement, but you know you have had improvement.
Which one is worse?
[Andy Ellis] Okay, so this one is funny because it feeds into one of my favorite conversations, which is that most metrics that are in use, especially in the security profession, are perverse metrics. They don’t actually show you what you think they show you.
[David Spark] Okay.
[Andy Ellis] And I’ll give one of my favorite examples, is the average time to patch vulnerabilities, which often has some weird denominator in it. Like is it the ones that were closed, or is the ones that were currently open or closed in the period?
And in fact, if you go look at a bunch of talks I’ve done, this is one of the examples I use like when I say how to build a security program is make sure your metrics survive against perversity. And I don’t mean perversion. Just the perversity of the world.
Like if you find new vulnerabilities, you close them immediately, but you only report once a month, nobody will ever see those vulnerabilities in your metrics. But you’re like, “Oh, but I know we did something good.” So, the underlying question here that I actually have to ask is are these metrics actually really good, high quality metrics, or are they not?
And I’m going to actually go with the…because it’s most security programs…
[David Spark] We’re going to assume they’re good.
[Andy Ellis] See, I would assume they’re not good.
[David Spark] Well, you’re assuming that you’re trying to create good metrics.
[Andy Ellis] Because one of the situations is you know you got better, and the metrics don’t show it. Therefore, it’s not a good metric. If you don’t understand how the metric got better, more likely than not, it’s not a good metric. Like I once bought from a security vendor a tool that sat on the network and detected lateral movement so that we could find things coming in.
And our IT team…
[David Spark] Well, now we’re just blaming the network, and so it doesn’t really matter.
[Andy Ellis] Yeah. No, I’m totally going to blame the metric, because I think this is a metrics problem. I think that you are worse off if your metrics tell you you’re getting better, but you have no idea how you’re getting better because you now are lulled into a sense of false confidence.
You didn’t actually get better. Your metric just tells you, you are.
[David Spark] But couldn’t this be the Mr. Magoo version of cyber security where things… You’re avoiding all the problems as everything is crashing around you?
[Andy Ellis] It’s possible that it could be. But let’s just go with what we’ve normally seen. I’ve seen reports from tools that said, “Look, everything is great,” but it turns out they weren’t looking for the right things anymore. They were based on old technology.
So, our IT team thought everything was golden, and everything was not golden. I’m saying, if your metrics claim you’re getting better and you have no idea how you’re getting better, you’re probably not actually getting better. And if you know you’re getting better and your metrics don’t show it, it’s an opportunity for you to figure out what your metrics ought to be.
[David Spark] Okay. Interesting argument there. But this is assuming that the metrics are the problem.
[Andy Ellis] I think that being the default state of the world is a reasonable assumption to start from.
[David Spark] Okay.
[Andy Ellis] Because if the metric is good, you should be able to figure out why it says it’s good.
[David Spark] Danny, you don’t have to necessarily accept his theory that the metrics are the problem to start with. What do you think here? Again, he thinks the first one is worse. Metrics that show improvement but can’t show why – he thinks that’s the worst scenario to be in versus metrics that show no improvement, but you know you’re improving.
[Danny Jenkins] Okay. I know you want us to fight, David.
[Laughter]
[Danny Jenkins] But I’m going to give a different reason.
[David Spark] Okay. That works, too. That works, too.
[Danny Jenkins] So, first of all, let’s just say we have a metric, and it’s very, very accurate. The number of successful phishing attacks has gone down in our company. And we know that it’s getting better. We don’t know if attackers have stopped attacking, or is our security better.
So, I think the latter is more important. I think you need to know that you’ve made improvement to your security in a tangible way. That’s one example. Hey, my phishing incidents have not gone down, but nobody can log into my accounts because we implemented something that does device authentication.
Or the other reason I don’t agree with the metrics being the priority is if you’re using some kind of detection and response tool, you probably have a fantastic tool saying that we’ve managed to block 50,000 new threats this month. However, when you block everything by default, we don’t know whether we’ve blocked any threats.
We just know we blocked what you don’t need. So, I always think the metrics is less important than knowing I’ve got tangible controls in place, and that’s… By the way, that’s not just…
[David Spark] So, hold on. Are you making an argument that you could survive without metrics if you just know you have the right controls?
[Danny Jenkins] If I had the choice of saying you have great metrics, great detection and response versus no metrics and no detection and response but good controls, I’m choosing good controls all the time. If you had to choose one, I’m always choosing good controls.
[David Spark] That’s a good argument right there.
[Danny Jenkins] And by the way, that’s not just in security. Every time I go to my marketing department, they want to show me a new chart. I don’t care about the chart.
[Laughter]
[Andy Ellis] Right. This is one of the things I often tell CISOs when they’re like, “We tried to go talk to the board, and we don’t know what they want to hear.” I’m like, “Only the CRO has metrics that anybody believes because at the end of the day cash in bank is the only metric that matters.
Everything else is you’re trying to tell a story.” And if you have the controls, it’s a good story. If you don’t have the controls, it’s just a story.
Please, enough! No, more!
24:00.137
[David Spark] Today’s, “Please enough! No, more!” is on authentication. Now, we’ve always been operating on a broken system of passwords. When passwords as our form of authentication was introduced, it was broken. So, we greatly improved that with MFA, which worked great at the beginning, now not so much so.
So, Andy, I’m going to start with you. What have you heard enough about authentication? And we’re talking about today, because this conversation has changed greatly. What have you heard enough about authentication today, and what would you like to hear a lot more?
[Andy Ellis] So, I just want to just point out that when passwords were first introduced they were a great system because they were designed to let you get close enough to the Roman camp for the guards to spot you and figure out who you were. That’s all that passwords were meant for was to be like, “You’re coming up…”
[David Spark] What do you mean, the Roman camp? I don’t know what the history is in that respect.
[Andy Ellis] A password was literally like the word that you would give out to your scouts and hunters…
[David Spark] Oh, right, that you would say to them. Yes.
[Andy Ellis] And this is a word of the day. So, when they were coming back in, they’d be like, “Hey, the password is whatever,” and you didn’t shoot them right away. You let them get close enough, and then you would validate a little more.
[David Spark] Yes.
[Andy Ellis] So, that was fine 2,000 years ago. We need something a little bit better. They were originally meant for groups, not individuals. But here’s I think the thing I’m really tired of hearing, which is thinking about authentication of a human.
[David Spark] Oh, definitely, yes. That is the story now. It’s not just humans.
[Andy Ellis] Most of us do not employ humans. We employ… I’m not even talking about the non-human identity problem.
[David Spark] Oh, okay.
[Andy Ellis] But the user that works for you is a user plus a set of devices. And we keep talking about authenticate the human, and what we should be talking about is how are you authenticating this set of the human and their devices. Like the devices should authenticate the human.
But over the network, I can’t authenticate the human. I can only authenticate the set, and we need to talk more about these sets. Whether we want to call them cyborgs, or centaurs, or the aircraft carrier commanded by the human. Whatever you want, that’s what I want to hear more about.
[David Spark] All right, and I throw this to you, Danny. First, tell me what you’ve heard enough about with regards to authentication. What do you want to hear a lot more? Andy wants to hear about life beyond the human.
[Danny Jenkins] Andy just stole my answer. So, I’m going to say the word “identity” though in general. And you’re right, it is about authenticating more than the human. And the idea of dual factor originally was it’s something you have, and it’s something you know.
But the bottom line is it’s still a single point. And now, just joining this meeting, just joining the Google Docs beforehand, it was such a pain in the backside to go through the code, the push notification, all of this. My password. To get in. And at the end of the day, if I’m a weak user, if I’m a human, I could have given it all away just as easy as I could have entered it into the computer.
So, I think Andy is absolutely right. I think the word is often referred to as the identity of a person. It should not be the identity of a person. It should be the identity of a person combined with the identity of a device and making sure nobody can access something if it’s not from a trusted device.
And we had… This is what makes me really, really nervous. We did a pen test a few months ago before zero trust world, and we managed to phish, which I thought was five but it was actually eight of our engineers to put their Office 365 credentials into a page, and accept the dual factor push, and put the code in.
[David Spark] Ouch.
[Danny Jenkins] And it’s embarrassing to me. Because I always thought sales people, they’re going to get phished. Finance people, they’ll get phished. Engineers don’t get phished. And engineers got phished. So, I think the most important thing is I’ve heard too much about human identity, and we should be thinking about device identity.
Something that you cannot give away to a very nice man on the phone or a webpage.
[David Spark] Well, so it’s interesting that you mention that it’s multiple points. And also, some of these points, correct me if I’m wrong, Andy, are things that are hidden in the background that are over time. Like there are typing patterns of where you’re logging in.
[Andy Ellis] Yeah, there’s lots of ways… This is the problem which that goes back to – trying to validate that it really is that human. There is a space that… Just to be very clear. Identity proofing, especially in the consumer world, very critical. But in the enterprise world… Here’s the question that I’m going to have for all of our listeners, which is really simple.
How many of your engineers ever will log in from any machine that you don’t already know which machine it is? Like they have their laptop. Maybe they also have a desktop.
[David Spark] That’s a good point.
[Andy Ellis] If you are not validating a machine credential… Like we did this at Akamai… I don’t even want to think about how many years ago now. But it was a lot. Where literally we put an X509 certificate on every device. And it had the name of the person in the certificate.
So, it had your username. So, the first thing that would happen when you tried to connect is the device authenticated and said, “Hey, this is Andy Ellis’s computer, it’s trying to connect.” Then I could do an out of channel, push it off to Andy to say, “Hey, is that really you?” This is phish proof.
Like you cannot get me to authenticate until my computer has already authenticated itself. So, my password is useless. And that’s the world we need to be in to say, “First we’ll trust the computer. Then we’ll trust the human.”
[Danny Jenkins] I completely agree. And that’s exactly what we’ve been trying to do with zero trust cloud access and zero trust network access is, “Hey, you can get my Office 365 credentials. You can get me to push a dual factor push. You can try and get me to approve a device.
But that device hasn’t been approved by the company, therefore it cannot get into my account.” Whether it’s Salesforce, or Office, or anything else. And we have to verify the device first and then verify the user. When was the last time you heard someone got phished, and their phone was stolen at the same time?
A lot less likely than someone just got phished.
[David Spark] One thing I want to mention is talking to you and Rob over at Threatlocker is… And the reason… It’s to your philosophy as well at Threatlocker is that while we think we want to have access to everything and all devices, what not, in general, as humans, we pretty much operate kind of the same way.
We use the same handful of applications on the same devices over and over again. Yes, you want to make it possible should someone need to log onto a computer that’s not theirs that they can do it.
[Andy Ellis] Why? No, no, no, I disagree right there.
[David Spark] Well, hold on. Let me just throw this out. What I’m more interested in knowing… And I don’t know if you have the stats on this. How often does that happen, Danny? Like if I have a desktop and a laptop, I almost never use another computer.
Like when you’ve identified the device and the human using it, how often are they not using that device and that human?
[Danny Jenkins] So, I think laptops and desktops, very, very rarely.
[David Spark] Yeah.
[Danny Jenkins] I think phones, obviously. But, again, it’s their phone, and their phone gets approved. And we’ve had this whole conversation internally at Threatlocker – do we allow personal phones to access. But if we do, they have to be individually approved.
Authentication tokens have to be put on them. They can’t just say, “Oh, I’m going to self approve any phone I want or give my credentials to an attacker to self approve a phone.” I think the reality is people often think about zero trust as taking…making it difficult for people, but it’s much more nuanced than that.
Even myself. Like most computers, you have access to everything. As a CEO, I’ve got a lot of access. But that doesn’t mean every program on my computer has to access everything I access, so it’s really, “Hey, you have access to these financials using Excel.
You have access to the CRM using this browser. You have access to your email from one of these devices.” User experience shouldn’t be negatively impacted by that, but security is exponentially increased.
[David Spark] But just… Do you have any numbers or any insight into if Andy is associated with this computer, this mobile phone, how often does Andy or just anybody who’s not already associated to a device try to use another device? How often does that happen?
[Danny Jenkins] I don’t have statistics, but insights is probably more relevant. And here’s an example on Threatlocker. We had…prior to ZTCA, we had more successful logins from rogue devices from attackers than we did from people themselves saying, “Oh, I want to use my home computer to log into my email.” And that’s what’s terrifying is it’s more likely that someone logging in from a device that is not authenticated or is not a device issued by the company or approved by the company is an attacker.
[David Spark] So, it’s a red flag essentially?
[Danny Jenkins] Yes.
[Andy Ellis] There’s two different things here, right? So, one is there’s a couple industries where this is not true. Where people do in fact use different computers. Healthcare is certainly one of them. Like a doctor with visiting privileges may need to log into a system at that hospital that’s not usually theirs.
[David Spark] Right, industry would change.
[Andy Ellis] But that’s a weird one. But I think Danny has pointed out a really interesting thing, and what I would encourage everybody to do is think about that use case of the user who wants to use their home computer. I think you only have two reasonable choices.
One reasonable choice is you authorize that computer for that user to log in on it, or you make it impossible for that user to use that computer. What often happens is people say, “Well, by policy you can’t do it, but we won’t support you.” But then that means you don’t actually have a good authentication system in place if you’re allowing the person to log in from an unknown computer.
I don’t even want to use the word trust. I just want to say known. Like when we first did our zero trust implementation over a decade ago, my attitude was if you’ve got 12 computers at home you’re going to log in on, I’m going to put a credential on every single one of them so that I know that they’re yours.
We’ll worry about trust later. But the first thing I want to do is say you can’t log in from an unknown device. Then we’ll worry about trust.
How can we secure new technology without creating new risks?
33:56.551
[David Spark] “Why pay a vendor $300,000 for a Software Composition Analysis tool when you can build a tailored version during your lunch break?” Ross Young, who is with the CISO Tradecraft, laid out the transformational potential. We’ve moved from SaaS to Service as Software, and LLMs have turned plain English into functional code.
Every business analyst is now potentially a (gulp) developer. So if anyone can vibe code a security tool, how does code review even begin, Andy? And if we built it by describing intent in plain English, can we secure it the same way? Can we?
[Andy Ellis] So, first of all, just as a warning to everyone who thinks they can vibe code every solution out there, almost any company you could build the basic functionality that they have in a weekend if you’re an amazing developer. Vibe coding makes that a little bit faster.
But basic functionality is not what people tend to buy. Nobody is buying Threatlocker, since I’ve got Danny here, just to do the basics of what Threatlocker can describe in 30 seconds. It’s the details and the hard work of making sure things work at scale.
Right? Why do people still use Google? Search isn’t hard. Search at high quality is. So, be careful. Like if you’re vibe coding your SCA, if you wanted really good SCA, you might not get that out of vibe coding. So, it’s just your cautionary tale. But here’s the answer, which is think of your vibe coding agent, whether it’s Claude or something else, as a new sort of fractional employee, and you should be onboarding them and teaching them how to do their job.
So, rather than trying to teach every person in the company how to code safely, what you need to be doing is handing them the onboarding guide for their agent so that when they say, “Hey, agent, go build me an X,” implicit in that is the skill of, “We need to do needs analysis.
We need to figure out exactly how we’re going to do this, how do we defensively code it, how does this interact with our zero trust platform and with our identity.” All of that should be stock and standard so that everything that you go to build meets what your company wants and is done so in a repeatable fashion.
And that can all be done with intent in plain English. But rather than trying to teach the business analysis how to do that, you just have to give them the package that gets included right into their coding agent.
[David Spark] I like that. All right, can security solutions be vibe coded, Danny?
[Danny Jenkins] I mean, look, we obviously use AI, and the answer is no. And I’ll give you another reason…a slightly different reason why. And I think AI is amazing. It’s given us the ability to research and understand things much, much faster. First of all, everything it’s creating is based on public knowledge.
I kind of liken it to a GPS solution that’s 98% right on every street. If you go and ask any AI agent right now, say, “Hey, tell me how to get to the end of the street,” it will tell you, “Point this degree north and go to the end of the street.” And then you’ll say, “Okay, I need to go three streets on, tell me how to get to here.” And it will say, “This far, this far, this far.” And you’re probably going to get it right.
Tell it to drive you to San Francisco from New York, and 98% right suddenly becomes really, really wrong over a lot of decisions. Because you’re not going to get from San Francisco to New York when you ask an AI agent which direction to go.
Because it’s going to be wrong sometimes. But also, it’s just regurgitating what it can find on public forums and discussions. When you buy a piece of software, whether it’s financial software or whether it’s security software, you’re buying a package that allows every department to interact with each other.
So, the person who creates the invoice knows nothing about deferring revenue. The person that puts the quote in the system knows about how we invoice them. So, when you have 100 people asking for individual functions, they do not fit together. So, I think large, compact pieces of software can never be done and built through AI.
Small functions can be. So, if you need something very small, even a security function, “Hey, write me a script that automatically locks the Windows lock screen after 15 minutes.” Very, very achievable through AI. “Tell me everything I need to do to secure my environment,” not very achievable via AI.
So, I think you can’t build a security solution, but you can build individual tools that will solve individual problems, but they won’t think about every component. “Write me a piece of software that will block software,” possible. But, “Write me a piece of software that understands all of the problems of blocking software,” much, much more difficult.
[David Spark] But then also… Let me just push back a little bit. Can’t you use AI and say, “Where are…?” Because this is something that I’ve used AI, which is not in security, which is, “Where are the areas that I need to be thinking about to secure this piece of software that I haven’t considered?” And can’t the AI start to answer questions like that?
[Danny Jenkins] A current piece of software, yes. But to build a security solution, no. Because it has to now go and say, “I have…” And first of all, it’s collecting this from public posts. So, you have to basically go and take all of this information, conflicting information, and someone has to make a decision.
And what makes security companies…what makes Threatlocker so good is not our ability to necessarily build software right the first time but the millions and millions of endpoints and the tens of thousands of customers that have given us feedback and shaped it.
What AI can’t do is take all that and turn it into, “Hey, I’ve come up with a perfect solution.”
If you think about the first hundred people that used Threatlocker, I can promise you it wasn’t very smooth. Most of them are still customers, thankfully. But then at a thousand people, it gets a little bit smoother. And then the ten thousand people, it gets even smoother.
And that’s the same with every single piece of software. AI is going to give you a very, very crude piece of software that doesn’t do a great job that you can then refine. If you want to get something really quick then that’s great, but you can’t build a security solution for your company.
You can build the bare bones of a software company, but so can any good developer do that in a weekend.
[David Spark] Andy, when we did the recording during BSides, this came up, and I asked both Mike Johnson, who is the CISO of Rivian, and Sara Madden, who’s the CISO of Convera, “Are you dropping solutions by creating an AI solution of your own,” and they said yes.
Are you seeing this pattern happening?
[Andy Ellis] Well, so what… I think there is a nuance here, which is there are more problems than people can afford to buy solutions for. And there’s a lot of solutions that are not good. Let’s be very honest. There is a lot of vendors out there who are selling things that might as well have just been vibe coded.
And so if you’re a CISO today, almost every CISO I know is vibe coding something. Most, when they talk about what they’re building, it’s problems that the vendors haven’t been solving for them because it’s this small niche problem. It’s an irritant.
And so it’s almost like, “Look, I’ll just go vibe code a thing to fix that irritant for me.” Or I’ve got a vendor that I hate, and their product doesn’t really work. And I can vibe code something that will give me like 60% of the functionality basically for free so that I can just get rid of that.
That’s absolutely happening. What I don’t hear anybody saying is, “I’m going to kick out every single one of my security vendors because I can vibe code it all.” That isn’t happening.
[David Spark] No, but they did say that they were kicking some. And it may be like what you described.
[Andy Ellis] Yeah, the ones I see getting kicked out are often the ones that functionally just do data analysis.
[David Spark] Yeah.
[Andy Ellis] If you’re a vendor that all you do is you take data from a bunch of sources and you’re then going to integrate that and provide a pretty dashboard, you’re ripe for being vibe coded out of existence.
[David Spark] Yeah.
[Danny Jenkins] I think code review is… I mean, I don’t know if out of existence is… code review is one of those ones that is being…
[Andy Ellis] code review is being… Nobody was doing good code review anyway. So, like vibe coding is certainly helping. You can have model go do code review for you, and it’s much better than having humans do it.
Closing
42:00.536
[David Spark] All right, we have come to the end of our recording. And I want to thank you, Danny. And I’m going to let you have the very last word. And also you, Andy, as well. But I first want to thank your company. That’d be Threatlocker. Remember – if you want to know more about Threatlocker’s zero trust network access and zero trust cloud access, go check them out at threatlocker.com/ciso.
Remember, add that /ciso. Super easy way to let them know that you heard about them from the CISO Series. I know that you’re always hiring over there at Threatlocker. Still doing that, Danny? Yes?
[Danny Jenkins] Absolutely. Just purchased a new building. Got space for another 800 people here. Maybe even more.
[David Spark] That is amazing, your growth rate. I’m quite impressed with it. Any last words about zero trust network access, or zero trust cloud access, or anything else you want to say about Threatlocker, Danny?
[Danny Jenkins] I will just say this… Threatlocker has a suite of tools that will make your life easier as a CISO, as an IT manager, and IT director to deploy least privilege in your environment. Whether… Call it zero trust, call it whatever you want.
But I think the reality is security is difficult, but it doesn’t have to be. We don’t have to chase our tail. We can put simple controls in place. We can do basic things, and we can change our environment from constantly having to fight malware and alerts to actually just being secure without interfering with users’ productivity.
[David Spark] Very, very good point, and it’s the basic philosophy of Threatlocker, and we’re very impressed with it. Thank you very much, Danny. Thank you very much, Andy. And thank to your company, Threatlocker, for sponsoring us. And to our audience, as I always say, we greatly appreciate your contributions.
By the way, send me in more “What’s Worse?” scenarios. We need lots more. 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, ciso-dev.davidspark.dcgws.com. Please join us on Fridays for our live shows, Super Cyber Friday, our virtual meet up, 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@ciso-dev.davidspark.dcgws.com.
Thank you for listening to the CISO Series Podcast.